소프트웨어를 개발하다보면 언제나 변화라는 문제에 봉착하게 됩니다.  그리고, 요구사항의 변화는 소프트웨어가 제공하는 기능에 대한 변화, 추가 및 삭제로 이어지게 됩니다.  이때, 기능 중심으로 개발 된 시스템은, 부분의 변화가 전체를 위협하기 쉬운 상태가 됩니다.  마치 젠가 게임을 하다가 보면 어느 순간 한 조각의 변화가 전체를 쓰러트리는 것과 같은 현상이 일어납니다.


작은 시스템의 경우에는 "기능 중심"의 개발이 그다지 문제가 되지 않습니다.
높이가 낮은 젠가는 쓰러트리기가 오히려 어려운 것처럼...


하나의 시스템을 구성하는 기능이 서로 전혀 연관이 없다면 문제가 없겠지만, 실무에서 그러한 시스템이 존재할 가능성은 거의 없습니다.


[그림 1]


OOP 중심의 개발에서는 이러한 기능을 박스로 분리합니다.  기능들을 묶어서 서로 다른 박스에 넣어 둡니다.  묶는 기준은 개발자(설계자) 마다 다를 수가 있으며, 무엇이 반드시 옳고 무엇이 반드시 틀렸다고 하기는 어렵습니다.  따라서, 우리는 "보편적인 아름다움"을 추구해야 합니다.  일반적으로 좀 더 타당한 해결책을 찾아야 한다는 의미입니다.


다만, 잘못 묶은 경우라면 [그림 2]와 같은 "나쁜 냄새"가 납니다.  왼쪽 박스에 있는 기능 하나가, 자신의 박스에 있는 기능들 보다 오른쪽 박스에 있는 기능들과 친합니다.  이런 경우라면, 해당 기능이 오른쪽 박스에 분류되어야 한다는 의미가 됩니다.  (기능은 동그라미로 표현했습니다)


[그림2]


이렇게 박스에 기능들이 담겨진 경우라면, 각각의 기능이 변화를 겪는다고 해도 전체를 위협하는 경우는 잘 일어나지 않습니다.  (젠가 조각을 박스에 담고, 그 박스를 쌓아 올린 경우입니다)  결국, 부분적인 변화가 전체를 위협하지 않는 상태가 되는 것 입니다.


  • 기능이 "서로 친하다"라는 것은 의존성이라고 표현합니다.  어떤 기능이 실행되는데 영향을 받는 경우를 뜻 합니다.  기능이 서로 영향을 주는 경우는, 다음과 같이 나눌 수 있습니다.
    • 특정 기능이 실행되는데 함께 실행된다.
    • 특정 기능이 실행 된 결과가 다른 기능에게 영향을 준다.
    • 특정 기능이 다른 기능의 실행 결과에 영향을 받는다.


물론 기능 변화가 심하거나 해서 박스가 변경되어야 하는 상황이 되면, 부분적인 변화가 다시 전체를 위협하게 됩니다.  OOP는 박스의 변화에 대해서도 좀 더 유연한 대응을 할 수 있는 것이 장점이며, 이에 대해서는 다음에 다루도록 하겠습니다.


Posted by 류종택