(명저 중의 명저 코드 컴플리트)

왜 우리는 항상 '모듈화'가 중요하다는 소리를 듣는데

거기서 모듈화의 핵심을 제대로 이해하지 못하는 사람들은 종종 이런 소리를 한다

'코드를 나누면 좋다'라고 말이다

그런데 이상하게도 코드를 더 잘게 쪼갰는데도 더 복잡해지는 경우가 많다.

예를들어서 서비스 클래스를 분명히 도메인별로 나눴지만, 하나의 데이터 흐름이 여러 클래스를 오가며 오히려 파편화되어 추적이 어려워진다라거나 말이다.

이 글은 왜 그런가에 대한 이야기이다.

(1974년 Yourdon & Constantine의 구조적 설계 논문)

구조적 설계(Structured Design)는 복잡성을 줄임으로써 코드 작성, 디버깅, 수정 작업을 더 쉽게, 더 빠르게, 더 저렴하게 만들기 위한 일반적인 프로그램

설계 고려사항과 기법들의 집합이다.

이 주요 아이디어들은 거의 10년에 걸친 콘스탄타인(Mr. Constantine)의 연구 결과이다.

이 논문에서는 그 결과들을 소개하지만, 이론과 유도 과정 자체는 다루지 않는다.

이러한 아이디어들은 마이어스(Mr. Myers)에 의해 복합 설계(Composite Design)라고도 불렸다.

저자들은 이러한 프로그램 설계 기법이 HIPO6의 문서화 기법이나 구조적 프로그래밍의 코딩 기법과 호환되며 상호 보완적이라고 믿는다.

이러한 비용 절감형 설계 기법들은 항상 시스템의 다른 제약 조건들과 균형을 맞춰야 한다.

하지만 프로그래머의 시간 비용이 계속 상승함에 따라, 단순하고 변경이 쉬운 프로그램을 만드는 능력은 점점 더 중요해질 것이다.

-1974년 Yourdon & Constantine의 구조 디자인 논문

---

결합도와 응집도는 무엇이고 어째서 시작되었는가?

1960년대~1970년대 초반 모듈화(Modularity)에 대한 논의는 존재했다. 

역사적으로는 다익스트라가 구조적 프로그래밍을 주장하며 모듈식 설계의 중요성을 강조했고, 그의 논문에서도 강조했다

그리고 1968년 데이비드 파나스의 기념비적 논문 "On the Criteria To Be Used in Decomposing Systems into Modules" (1972) 에서 정보은닉과 모듈 경계 설계를 제안했다

즉 이제 거대한 시스템을 만들기 위한 초기단계에 프로그래머들은 들어서게 되고, 모듈화라는 것이 그 도구가 될 것이 분명했다.

1971년 니클라우스 비르트(Niklaus Wirth)는 모듈화를 점진적 정제(Stepwise Refinement)과정으로 설명했다.

여기서 모듈화는 점진적 문제(Stepwise Refinement)란 무엇인가?

복잡한 문제를 해결하기위해서 하향식 설계(탑 다운)를 이야기한다.

1. 추상적인 수준에서 시작: 가장 먼저 해결 해야할 문제를 매우 높은 수준에서 정의한다. 즉 문제의 큰 그림을 그린다

2. 점진적인 구체화를 시작한다. 

3. 이후 문제의 세부사항을 추가한다

4. 구현을 반복한다.

비르트는 이러한 과정이 자연스레 모듈화로 이어진다고 말했다

각 정제단계에서 도출되는 하위 문제들이 결국에는 독립적인 기능 단위 '모듈'이 되는 것이다.

-모듈은 특정 하위 문제를 해결할 것이며

-모듈간의 인터페이스는 각 단계에서 정의된 데이터와 제어 흐름에 따라 결정 된다.

따라서 높은 수준의 추상화에서 구체적인 구현으로가는 과정자체가 시스템을 명확한 책임과 인터페이스를 가진 독립적 모듈로 구성하는 방법이라는 것이다.

그럼 모듈의 경계 설계와 모듈식 설계가 중요하는 것은 알겠다

그러면 자연스레 우리는 이 질문 앞에 다시 선다.

그럼 어떻게 모듈화의 품질은 어떻게 평가할 것인가?

그리고 1974년 Yourdon & Constantine의 구조적 설계 논문에서 이것을 정량 평가하는 기준을 마련한다.

그 기준이

응집도(Cohesion)

결합도(Coupling)

이다.

이것을 바탕으로 '모듈화'는 단순한 코드 분할을 넘어 일종의 시스템 복잡도 관리의 핵심도구가 된다.

그리고 이것들을 바탕으로 엘런케이의 OOP가 나오고

IEEE 표준과 SEI-CMMI에서 구체화되고

그리고 명저중의 명저 '코드 컴플리트'에서 이를 설명하고 일반 프로그래머에게 알려졌다.

응집도와 결합도는 무엇인가?

결합도와 함께 구조적 설계에서 비롯된 응집성은 일반적으로 같은 맥락에서 논의됩니다. 

응집성은 클래스 내의 모든 루틴 또는 루틴 내의 모든 코드가 중심 목적을 얼마나 잘 지원하는지, 즉 클래스가 얼마나 집중되어 있는지를 나타냅니다. 

강력하게 관련된 기능을 포함하는 클래스는 강한 응집성을 갖는다고 설명되며, 경험적 목표는 응집성을 가능한 한 강하게 만드는 것입니다.

 응집성은 복잡성을 관리하는 데 유용한 도구인데, 클래스 내의 코드가 중심 목적을 더 많이 지원할수록 뇌가 해당 코드가 수행하는 모든 작업을 더 쉽게 기억할 수 있기 때문입니다. 루틴 수준에서의 응집성에 대한 사고는 수십 년 동안 유용한 경험적 방법이었으며 오늘날에도 여전히 유용합니다. 클래스 수준에서는 응집성의 경험적 방법이 이 장의 앞부분과 6장에서 논의된 더 넓은 경험적 방법인 잘 정의된 추상화에 의해 크게 포괄되었습니다. 

추상화는 루틴 수준에서도 유용하지만, 그 세부 수준에서는 응집성과 더 동등한 위치에 있습니다.

-Code Complete 2nd Edition,  Aim for Strong Cohesion  부분

결론부터 이야기하자면 응집도는 높게, 결합도는 낮추게 하는 것이 유리하다.

응집도(Cohesion)

-모듈 내부 요소들의 기능적 연관성을 계층적 분류

결합도(Coupling)

-모듈간의 의존성 강도

그리고 이 응집도와 결합도를 판단하는 지표를 알아보자

바로 Code Complete와  Yourdon & Constantine의 논문을 바탕으로 말이다.

전통적 응집도의 분류( Yourdon & Constantine)-1974

코드 컴플리트에서는 모듈 또는 루틴에 대해서 응집도를 말하는데 여기서 루틴은

'특정 작업을 수행하는 독립적 코드 블록'을 의미한다.

응집도-클래스 또는 루틴의 요소들이 얼마나 잘 서로 어울리는지를 말한다.

모듈과 루틴에 대해서 평가할때

우연적 응집을 가장 비판하고 아래로 갈수록 기능적 응집에 도달할수록 가장 이상적이라고 했다.

기능적 응집도를 가장 이상적으로 생각하고 

일반적으로 논리적 응집을 부분적으로 허용, 통신적 응집에 대해서도 목적 분산을 경계하면서도 사용하라고 하지만,

시간적 응집부터는 리팩토링의 대상임과 동시에 비판적으로 설명한다.

코드 컴플리트는 여기서 기능적 응집도를 이상으로 하면서

'한 루틴이 "한 가지" 작업만 수행할대 디버깅이 쉬워지고, 응집도의 저하의 징후로 루틴 이름에 and와 or가 포함되면, 너무 많은 매개 변수 또는 복자반 제어 흐름이 있다고 이야기한다.

코드 컴플리트에서 말하는 좋은 응집도를 만들면

'코드가 하나의 일에 집중'

'루틴 명이 설명을 대신함'

'수정이 국지적인 부분으로 국한됨'

'루틴 내 코드 라인들 간에 맥락성이 높다' 라고 이야기한다.

이제 결합도를 알아보자.

(Structured Design 1979년 책)

(코드 컴플리트에서 결합도)

전통적 결합도의 분류

 Code Complete 기반의 결합도 유형 정리

결합도- 모듈간 의존성의 강도를 말한다

하지만 결합도는 1974년 Structured Design 논문에도 1979년  Structured Design 책에서도 나오지 않는다

왜일까? 결합도는 논문이 아니라 보완연구에서 분류 체계를 갖추었기때문이다

또한 코드 컴플리트에서는 결합도를 다르게 이야기한다.

왜?

코드 컴플리트가 쓰인 시기는 OOP가 메인이 되던 시기이기때문에, 

'맥락(Context) 기반의 결합도가 더 현실적이라고 여겨졌고, 객체간 협력의과 인터페이스 오용등 새로운 방법의 결합도가 도입됐다.

이러한 차이로 인해서 결합도의 분류 방법을 실전 중심으로 바꾼것이다.

전통적 결합도가 설계의 이론적 척도였다면

McConnell이 분류한 결합도는 실제 OOP 지향 개발에서 마주치는 코드간 잘못된 상호작용을 더 잘보여준다.

그리고 이 응집도와 결합도는 서로 상호작용하며, 우리의 코드 품질을 이해하는 도구가 된다.

가령 논리적 응집을 가진 모듈은 제어 결합(Control Coupling)을 유발할 가능성이 높다는 등 서로가 상호 보완적인 관점을 가진다.

“프로그래머는 시인처럼, 순수한 사유(思考)의 재료 근처에서 일한다.
프로그래머는 허공에, 상상력의 힘으로 허공의 성을 짓는다."

― 프레더릭 P. 브룩스 주니어, 『맨먼스 신화: 소프트웨어 공학에 대한 에세이』

끝맺으며

소프트웨어 설계의 역사는 모듈화 원칙의 진화사라고 할 수 있다.

1974년 Yourdon & Constantine이 제시한 응집도/결합도는 단순한 이론이 아니라, 거대 시스템 시대를 연 엔지니어들이 피땀으로 얻은 통찰이다.

코드를 분할한다는 것은 분해(decomposition)가 아니라, 새로운 추상화 계층을 창조하는 행위이다.

《Code Complete》이 강조하듯, 모듈화의 성패는

->"한 루틴이 한 문장으로 설명되는가?"(기능적 응집력)

->"변경 시 얼마나 적은 파일을 건드리는가?"(낮은 결합도)

라는 현실적 질문으로 환원된다.

그리고 이 개념들은 마이크로 서비스 아키텍쳐와 도커까지 수많은 곳으로 깊이 파고들어 곳곳에 퍼졌다. 

70년대 선구자들이 남긴 유산은 변하지 않았다.

모듈화는 여전히 소프트웨어 설계의 가장 강력한 무기이고,

우리는 선배 프로그래머의 지혜를 이어받아서 당시로썬 거대한 아키텍쳐를 다룰 수 있게 되었다.

그리고 프로그래머로써 선배 프로그래머의 말 한마디에 짧은 글귀를 하나 덧붙인다

우리는 허공에 코드를 짓는다. 하지만 그 허공은, 남이 이해할 수 있어야만 한다.