Feature, Component and Module

많은 개발자들이 이 3가지에 대해 종종 혼돈을 일으키는 경우가 있다. 그래서, 이 부분에 대해 좀 더 명확히 하고자 한다. 물론 구글링을 하면 많은 답변을 얻을 수 있다. 그렇지만 서로 답변이 다르기도 하고 애매모호하게 말하는 경우가 있어 여기서 정리를 하고자 하는 것이다. 그렇다면 이제 자세히 알아보자.
Feature 에 대해서 영어사전을 찾아보면 다음과 같은 답변을 얻을 수 있다. 특징, 출연하다, 기능 등등이다. 그렇다면 software에서는 feature를 무엇이라고 말할 수 있을까? 기능에 가깝다. 정확하게 말하자면 어떤 대상체가 무엇을 하는지를 말하는 것이다. 즉, 대상체의 특징은 대상체가 무엇을 하는지를 통해 규정이 된다. 즉, feature는 이것을 내포하고 있다. 대상체가 왜 존재하는지에 대한 것을 규명해주는 것이다. 대상체가 무엇을 하는지에 대한 것을 feature라고 할 수 있다. 그래서, 보통 software에서는 feature를 서술형으로 표현한다. 예를 들어보자 image를 디스플레이 해야 한다. 이것 또한 feature가 될 수 있다. 그렇다고 무조건 고객요구사항을 통하여 feature를 정의하면 되는 것인가? 그렇지 않다. feature와 component는 상관관계가 있기 때문에 반드시 feature를 만들 때는 어떤 component가 필요한지 구상하며 feature를 정확하게 표현해주어야 한다. 즉, component 때문에 feature가 변경되어야 하는 경우도 있다는 것이다. 그렇다면 component는 무엇인가?
component는 feature를 수행하는 대상체 인것이다. 즉, 어떤 component를 말할 때 component 의 특징을 규정할 수 있는 것이 바로 feature이다. 우리는 보통 feature가 없이도 component의 이름만 가지고도 대충 무슨 일을 해야할지를 알기는 한다. 하지만 이건 feature를 통해서 이름을 지은 것일 뿐이다. 만약 feature의 내용과 component의 이름이 다르다면 여러분은 파악하지 못할 수도 있다. 예를 들어보자 online media 즉, online radio를 재생해야 한다라는 고객요구사항을 생각해보자. online radio를 재생해야 한다라는 하나의 요구사항에 여러 feature가 나올 수 있지만 여기서는 심플하게 생각해보자. 그냥 이 요구사항 자체가 feature라고 생각해보면 여기에 맞는 component를 우리는 radio라고 이름지어보자. 그리고, 모르는 사람이 처음 radio라는 component를 보면 무슨일을 하는 component라고 생각할 수 있을까? 아 FM 또는 AM라디오를 재생하게 하는 component구나라고 셍각할 수 있다. feature를 보기전까지는 ...... 바로 이거다. component의 특징을 부여하는 것이 바로 feature인 것이다. component는 feature를 수행하기 위한 도구라고 생각하면 된다.
그럼 이제 module을 파악해야 한다. 그런데 이전에 component를 보면서 보통의 개발자들은 어떤 생각을 하게 될까? 머리속에 이미 구조를 생각하게 된다. radio라는 process를 만들면 되겠지라고 보통 생각하게 된다. 이러한 생각의 발전 때문에 혼선을 겪게 된다. 계속 나아가 보자. 그럼 radio라는 process로(process는 dynamic behavior 상태를 말하니 앞으로는 executable binary라고 표현하겠다.) 만들면 되겠네. 그렇게 되면 radio 라는 executable binary는 component가 되겠네. 이렇게 하고 개발하다 보니 어랏? 받은 data를 decoding하려고 보니 codec 라이브러리가 있어야 하네. 그래, 그럼 codec은 라이브러리이니 이건 module이라고 표현하자.
여기서부터 문제가 발생한다. 개발자와의 간단한 대화형식으로 문제점을 찾아보자.

'feature에 맵핑되는 component는 무엇인가요?'

'radio라는 component입니다.'

'그럼 codec은 무엇인가요? 라이브러리 입니다. '
'그럼 codec은 이 feature를 수행하기 위해 필요한 것이 아닌가요?'
'아니요 당연히 필요하죠'
'그런데 왜 feature에 mapping이 되어 있지 않죠?'
'아 그건 radio component에 mapping 이 되어 있습니다. '
'그럼 radio executable binary는 component가 되고 codec는 무엇인가요?
'codec은 module입니다. '
'그럼 예를 들어볼께요. 하나의 feature를 수행하기 위해 두개의 executable binary와 3개의 module이 필요하면 이건 어떻게 설명이 되나요? 3개의 component 에 하나의 feature가 연결되는 것인가요?'
'음 그건 feature를 더 자세히 분해하지 못해서 발생되는 문제입니다. '
'그렇다면 feature를 executable binary단위로 분해되어야 하는 건가요?
'네 그렇다고 할 수 있죠'
'그렇다면 feature에 의해 library만 나오는 경우는 없다는 건가요?'
'네 그럴 수 있습니다. '
'그렇다면 open source로 제공되는 많은 library는 그 자체로는 특징을 주어질 수 있는 feature를 할당 할 수 없다는 건가요? feature가 없는 산출물이 있을 수 있나요?'
'.......'
논리의 오류가 발생합니다.
우리가 보통 component에 대해서 바로 executable binary를 만들다 보니 범하는 오류입니다. 틀린말은 아니지만 충분조건이지 필요조건이 아니라는 것입니다. ( coponent = executable binary, executable binary!= component)
즉, component 는 대명사를 지칭하는 것입니다. 예를 들은 radio를 보자면 radio라는 component는 실체가 어떻게 구성될지는 확정을 지은 것이 아닙니다. group의 이름을 지은 것입니다. component의 구성품이 module이 되는 것입니다. module은 한마디로 physical하면서도 독립실행 가능한 것을 말합니다. executable binary(process), library 작게는 폴더 단위, 파일단위, 클래스 단위를 말할 수 있습니다.
그렇게 되면 아까전에 만든 radio executable binary, codec 은 바로 radio component의 module이 되는 것입니다. 즉, radio component는 feature를 구현하기위해 radio executable binary와 codec module두개를 만들어 구성되는 것입니다. 많은 경우 component 에 하나의 executable binary 가 나오기 때문에 흔히들 하는 실수인 것입니다. 

그럼 다시 정리해보겠습니다. feature 에는 하나의 component 가 mapping 되어야 하고 만약 여러개의 component 가 나오게 되면 그땐 feature 를 더 잘게 분리해야 합니다. 그리고, component 에는 하나이상의 module이 나오게 되는 것입니다. 이 내용을 UML로 표현하면 아래와 같이 되겠죠.