'추상화'에 해당하는 글 1건

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
소프트웨어 개발에는 여러 가지 중요한 원리들이 존재합니다. 그중에서도 소프트웨어 컨플릭트2.0에서 언급되었던 '단일 지점 제어'는 매우 중요한 원리입니다. 단일 지점 제어의 중요함에 비해 개념은 비교적 간단합니다. 중복되는 부분은 한 곳에서 해결하고 필요한 곳에서 참조 되어야 한다는 것입니다. 많이 사용하는 모듈화, 추상화 등이 단일 지점 제어의 대표적인 예입니다.

이러한 단일 지점 제어의 반대편에 '격리'가 있습니다. 격리는 단일 지점 제어와는 반대로 중복되는 부분이라 할지라도 각자 자신의 영역안에서 해결하여 닫힌 형태로 사용하는 구조를 지향합니다. 예를 들어 보겠습니다. 중복되는 부분 DUP를 C에서 해결한 후에 Function A,B,C에서 C를 참조하게 하는 것은 단일 지점 제어입니다. 반면에 중복되는 부분 DUP를 C1,C2에서 각자 해결하고 Function A,B는 C1을 Function C는 C2를 참조하게 하는 것은 격리라고 볼 수 있습니다.
사용자 삽입 이미지
그림1. 단일 지점 제어.

사용자 삽입 이미지
그림2. 격리. C2와 기능C가 전체 애플리케이션에서 격리되어 있는 것을 볼 수 있음.

유지보수 관점에서 이 둘의 차이점은 중복되는 부분 DUP에 변경 사항이 생길 때 발생합니다. 단일 지점 제어의 경우에는 C만 수정하면 됩니다. C만 수정하면 C를 참조하고 있는 Function A,B,C에 영향이 전파 됩니다. 이것이 바로 단일 지점 제어가 가지는 장점입니다. 그렇지만 격리의 경우 C1 혹은 C2를 별도로 수정해줘야 합니다. C1은 Function A,B에만 영향을 미치고 C2는 Function C에만 영향을 미치기 때문입니다.

보편적인 경우 우리는 격리보다는 단일 지점 제어를 사용해야 합니다. 그렇지만 특별한 경우가 있을 수 있습니다.
저는 얼마전 통합 테스트를 하기가 무척 어렵고, 사소하고 작은 문제라도 큰 위험으로 발전 할 가능성이 높은 기능을 개발한 적이 있습니다. 저는 앞으로 얘기 할 격리로 인해 발생하는 유익함에 대해 알지는 못했지만 몇가지 다른 이유로 해당 부분을 전체 애플리케이션으로부터 최대한 격리시켰습니다. 그런데 얼마 후 애플리케이션 전반에 영향을 미치는 부분에 대해 수정이 필요한 상황이 발생하였습니다. 수정 작업 자체는 문제가 아니였습니다. 진짜 어려운 문제는 위에서 얘기했던 위험한 기능에 대해 테스트하고 동작을 보장하는 것이였습니다. 조금만 잘못 수정해도 큰 사건이 일어날 수 있다는 것을 잘 알기 때문에 손대는 것 자체가 매우 힘들게 느껴졌습니다.
바로 이 때 격리가 빛을 발했습니다. 다행히 위험한 기능은 전체 애플리케이션으로부터 격리되어 있었기 때문에 공통 부분을 수정해도 영향 받지 않았습니다. 따라서 저는 가벼운 마음으로 수정작업을 마칠 수 있었습니다. 만약 격리가 되어 있지 않았다면 매우 힘든 작업이 되었을 것입니다.

이렇듯 격리는 몇몇 특별한 상황에서 좋은 선택이 될 수 있을 것이라 생각합니다. 혹시 격리가 필요하다고 생각되는 부분이 있나요? 그렇다면 격리로 인해 발생하는 '유지보수의 어려움'과, 단일 지점 제어를 함으로 발생될 수 있는 '위험도의 증가'를 검토하는 것이 도움이 될 것입니다. 검토 후 유지보수의 어려움이 크다고 판단 되면 단일 지점 제어를, 특정 부분의 위험도를 낮추는 것이 중요하다면 해당 부분에 대한 격리를 선택하는 것이 좋은 결과를 낼 수 있을 것이라 생각합니다.

EP님 덧글에 대한 답변 - 위험도의 분리를 위한 격리
EP님의 덧글

윗 글의 마지막 의문에서도 드러나듯, 어려운 점은 "단일 지점 제어"와 "격리"를 언제 써야 할지 모른다는 것이죠. 언제 써야할지 모른다기 보다는 요구사항의 변화에 따라 "단일 지점 제어"가 더 적당했는데 "격리"할 필요가 생기고 "격리"가 더 적당했는데 "단일 지점 제어"가 되게 바꾸어할 상황이 생겨서 어렵습니다.

어떤 서비스의 하위 서비스 A와 B가 있습니다. A의 파일 업로드 제한이 1MBytes고 B의 파일 업로드 제한이 1MBytes입니다. 이 때 1MBytes라는 상수를 하나를 정의하고 써야할까요? 아니면 A와 B 따로 정의하고 써야할까요? 이 경우 그나마 쉬운 편이라 격리 쪽으로 기울지만 미래의 요구사항에 따라 이 선택이 좋을 수도 나쁠 수도 있습니다. A와 B가 항상 같은 업로드 제한을 두게 되면 단일 지점 제어가 적당했을 것이고 다르게 가게 되면 격리가 적당했었겠죠. 근본적인 문제는 A의 업로드 제한과 B의 업로드 제한을 같은 의미로 보느냐 의미로 보느냐죠.

하나의 의미로 다루어야 하나 두 가지 다른 의미로 다루어야 하나? 자주 하게 되는 어려운 질문 중 하나죠.
EP님 좋은 의견 감사드립니다. EP님 글을 읽어보니 의미의 모호함이 있을 때도 격리가 필요할 때가 있을 것으로 보입니다. 결론 부분에 '몇몇 특별한 상황'이라고 써놓고도 사실 한 가지 경우밖에 생각을 못해서 글을 좀 고쳐야 하나라고 생각했는데 정말 다행입니다. ㅋㅋ 사실 제가 이번에 글을 쓰면서 집중했던 부분은 '위험성의 분리 측면'이였습니다. 그래서 이 부분에 대해서 좀더 추가 설명을 하려고 합니다.

중복되는 곳, 즉 대표적 예로 공통 모듈이라 할지라도 완전한 원자성을 갖는 경우는 드뭅니다. 이 말은 하나의 공통 모듈이 여러 가지 갈래와 여러 가지 복합적인 기능으로 구성되어 있는 경우가 많다는 뜻입니다. 그리고 이러한 형태의 모듈이 변경 되었을 때, 그 변경이 해당 모듈을 참조하고 있는 모든 하위 참조자에게 반드시 필요한 변경이 아닌 경우도 있을 것이라고 생각합니다. 이러한 상황은 모듈이 복합성을 가지고 있기 때문에 발생할 수 있는 일입니다.

그런데 문제는 이러한 수정이라도 일단 발생하면 하위 참조자들은 모두 스스로의 동작을 검증해야 한다는 점입니다. 왜냐하면 자신이 필요로 하든 안하든 일단 참조하고 있는 모듈이 바뀐것은 사실이기 때문입니다. 예를 들어 자바의 경우에는 아무리 자신과 관계 없는 수정이고 테스트를 안한다 하더라도 최소한 컴파일 레벨에서 에러가 안나는지에 대해서는 검토가 필요할 것입니다. 이 부분에 대해서는 여러 가지 상황이 있을 것 같습니다.

저는 이러한 일이 매우 비생산적일 수 있다는 점에 주목했습니다. 위에 제가 겪은 사례와 같이 변경에 따른 위험도가 높은 부분이라면 비생산적일 뿐만 아니라 위험 부담도 커집니다. 따라서 자신이 필요로 하지도 않는 변경에 대해 단지 함께 참고하고 있다는 이유만으로 영향받지 않았으면 좋겠다고 생각했습니다. 그리고 그 해결책은 바로 격리가 되겠지요.

수정 이력
- 2007/12/01 이미지 추가, 이미지에 맞게 내용 수정
- 2007/12/02 EP 덧글에 대해 '위험도의 분리를 위한 격리' 추가


WRITTEN BY
차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!

,