기능 분해 방식 모듈과 컴포넌트

위키에서는 기능 분해(functional decomposition)에 대해 원초적인 기능을 기능 분해한 각 부분들로 재구성될 수 있는 방식으로 기능적인 관계를 구성 요소로 해결하는 절차라고 소개하고 있다. 일반적으로 분해의 과정에서 구성 컴포넌트(여기서는 하나의 구성 요소로 판단됨)를 식별하는 식견을 얻는 목적으로 진행한다고 되어 있다. 이러한 분해 과정을 거쳐서 최종적으로 특정 수준의 모듈화(modularity)를 식별하게 되는데, 여기서의 모듈은 독립적이거나 서로 상호관계가 없는 것이다.

그 하단에서는 이러한 분해 방식이 나오게 된 원리에 대해서 소개되어 있는데, 어느 한 기능이 5개의 요소로 나뉘는 경우, 이들의 관계는 4의 5승이 되어 총 1024가지의 관계를 갖게 된다. 하지만, 이를 적절한 형태로 그룹핑을 한다면, 그룹핑 내에서의 관계만을 생각해볼 수 있기 때문에 이러한 경우의 수는 크게 줄어들게 된다. 위키에서 소개한 대로 어느 한 기능이 3개의 그룹으로 나뉘고 첫번째 그룹은 1개의 요소, 두번째 그룹은 3개의 요소, 세번째 그룹은 1개의 요소로 나뉘면 전체 경우의 수는 총 72가지가 되어서 그룹핑을 하지 않은 경우의 수보다도 훨씬 줄어들게 된다.

즉, 기능 분해 방식은 복잡한 시스템을 가능한 최소의 구성 요소로 나누어서 최소 단위에서부터 더 큰 단위로 구성하는 방식이다. 이는 객체지향 방식 이전의 절차적인 방식에서 추구하던 방식이며, 현실적으로 사람이 이해하거나 분석하기 아주 좋은 형태이다. 프로젝트를 계획하는 WBS 역시 이러한 기능 분해 방식을 취하고 있다.

하지만, 이러한 기능 분해 방식은 가장 상위의 요소들이 너무나 많은 책임을 가지게 된다는 것이다. 즉, 하위의 요소들은 상위에서 절차적으로 관계를 구성해야만 이를 수행할 수 있기 때문에 하위의 요소보다 상위의 요소가 책임을 더 갖게 된다. 또한, 어떠한 기능 변경이나 변이가 발생시 이를 어디에 위치하면 좋을지를 결정하기가 어렵다. 최초의 기능 분해 방식의 기준으로 추가 기능이나 변경 기능을 매핑해야 하기 때문이다.

또한, 결정적으로 기능 분해 방식은 각 그룹이 서로 연관되지 않는다는 것이다. 즉, 어떤 한 그룹에 속하게 된 요소는 다른 그룹과 관계를 가질 수가 없다. 이러한 방식은 요새와 같이 비즈니스 자체가 복잡한 시스템에서 적용하는데는 한계가 있다. 특히, 재사용성에 대한 한계로 인해서 여러 요소에서 유사하거나 동일한 기능이 반복적으로 나타날 수도 있으며, 최소 단위의 요소까지 분해하기까지 상당한 시간이 걸릴 수도 있다. (분해 기준 역시 하위 요소로 갈수록 모호해질 수도 있다.)

이러한 기능 분해 방식의 모듈화를 통해 만들어진 컴포넌트(엄격하게 말하자면 컴포넌트라고 말할 수는 없을 것이다)들은 상하 수직적인 관계만으로 구성되며, 그 만큼 작은 단위로 형성된다.

기능 분해 방식과 가장 대변되는 개념이 객체지향 개념으로 이는 요소들의 계층적인 형태보다  개별 요소를 독립적인 형태로 구성하여 이들에게 적절한 책임과 역할을 분배하는 형식이다. 이와 같이 책임과 역할을 동등하게 가지는 객체들이 연합하여 loosely coupling, tight cohesion의 원칙에 따라서 그룹핑된 개념이 컴포넌트이다. 즉, 기능 분해 방식의 모듈과 컴포넌트는 책임의 정도가 상하 관계인가 동등 관계인가로도 구분해볼 수 있다.

따라서, 기능 분해 방식의 상호 관계(의존관계)는 주로 어느 한 지점에서 출발하여 어느 한방향으로 퍼지는 형태라면, 컴포넌트는 방향성이 존재하지 않고 서로 얽힌 것과 같은 형태를 취하게 된다. 이는 마치 인터넷 상에서 시스템과 시스템의 관계가 컴포넌트와의 컴포넌트와의 관계라고 한다면, 해당 시스템 내의 서브시스템의 구성도가 기능 분해 방식의 모듈과 같은 개념이라고 할 수 있다.

하지만, 극적으로 서로 얽혀있는 컴포넌트 관계는 유지보수나 배포에 문제가 되기 때문에 이들 간의 의존관계는 어느 정도 관리할 필요가 있다. (어느 정도가 아니라 아주 엄격하게 관리할 필요가 있다.) 주로 컴포넌트의 유형을 식별하고, 이들 간의 관계를 맺는 원칙을 정하게 되며, 이러한 원칙에 위배되는 관계에 대해서는 별도의 설계 방식으로 해결해야 한다.

아무튼 기능 분해 방식의 모듈과 컴포넌트는 그 출발점 자체가 다르며, 두 가지 방식이 가지는 장단점이 상호 보완적인 되기도 한다. 하지만, 이러한 두가지 개념은 같이 사용하여 시스템을 구성하는 것은 어렵다. 기능 분해 방식의 경우, 그 결과는 어느 특정 시점의 시스템을 바라보는 기능의 구분 방식이지만, 컴포넌트로 구성된 시스템은 독립젹인 컴포넌트 간의 상호작용을 통한 해당 기능을 제공하기 때문에 두가지를 혼용하는 개념은 힘들다. 하지만, 기능 분해를 단지 시스템이 제공하는 기능의 분류 체계로만 사용하고, 이를 컴포넌트가 제공하는 기능과의 매핑은 가능할 수도 있다. 그렇지만, 이러한 기능 분해 방식은 시간이 흐르면서 그준이 바뀌고 기존의 정의했던 개념이 모호해지기 때문에 결국 이를 관리하기가 힘들 수도 있다. 시스템을 구성하기 전에 기능 분해 방식(절차지향 방식)으로 접근할 것인지, 컴포넌트 방식으로 접근할 것인지에 따라 그 구현 방식도 많은 차이가 난다.

요사이 기능 분해의 개념이 EA(Enterprise Architecture)의 AA(Application Architecture)에 적용되면서 이를 Software Architecture까지 적용하려는 방식들을 간혹 경험한다. 기능 분해는 divide and conquer 라는 형태로 복잡성을 좀 더 작은 단위로 나누어서 그 구성요소를 식별하는 용도로 사용할 수 있지만, 소프트웨어 내부로 그 개념이 들어오게 되면 객체지향 언어를 사용해서 절차지향적 프로그래밍을 하는 이상한 결과를 얻게 된다. 요즘의 시스템들은 그리 단순하게 구성되기에는 너무나 많은 복잡한 비즈니스를 그 안에 품고 있다. divide and conquer 방식을 식별의 한 방법으로 사용하고(식별 단계 이후에는 사실 이러한 결과도 충분히 바뀔 수 있다), 그 내부의 구성은 재사용/확장성 등의 여러 특징들을 잘 지원할 수 있는 컴포넌트 접근 방식을 취하는게 제일 바람직한 방법이라고 본다.