결합도는 소프트웨어 공학에서 모듈이나 시스템의 구성 요소들이 서로 얼마나 강하게 의존하는지를 나타내는 설계 지표이다.[1] 한 부분의 변경이 다른 부분으로 얼마나 쉽게 전파되는지를 보여 주며, 설계 품질을 판단할 때 자주 함께 보는 응집과 짝을 이룬다.[4] 일반적으로 결합도가 낮을수록 각 구성 요소를 독립적으로 이해하고 수정하기 쉬워진다.[4][5]
1. 개요
결합도는 단순히 "서로 연결되어 있다"는 뜻이 아니라, 연결의 형태와 깊이를 함께 본다. 예를 들어 어떤 모듈이 다른 모듈의 공개 인터페이스에만 의존하는지, 아니면 내부 데이터 구조와 제어 흐름까지 알고 있는지에 따라 결합도의 수준이 달라진다.[2][3] 그래서 결합도는 설계 초기의 추상화 수준부터 구현의 세부 경계까지 모두 포괄하는 개념으로 다뤄진다.
결합도는 의존성을 줄이는 설계와 직접 연결되며, 모듈의 경계를 어떻게 나눌지 결정하는 데 중요한 기준이 된다.[1] 같은 기능을 구현하더라도 외부에 노출되는 정보의 양과 호출 방식에 따라 시스템의 유지보수성, 교체 가능성, 테스트 용이성이 크게 달라진다.[4]
2. 결합도와 응집도
결합도와 응집은 서로 반대 방향의 품질 지표처럼 사용되지만, 실제로는 함께 봐야 한다.[4] 이상적인 설계는 한 모듈 안에서는 관련된 책임이 잘 묶여 높은 응집을 보이면서, 모듈 사이에서는 필요한 정보만 주고받아 낮은 결합도를 유지하는 구조이다.[5] 이런 구조에서는 변경 범위가 줄어들고, 각 모듈의 역할이 분명해지며, 문제의 원인도 좁혀서 찾기 쉬워진다.[4]
반대로 응집이 낮고 결합도까지 높으면 설계의 경계가 흐려진다. 이 경우 한 기능을 수정할 때 여러 모듈을 동시에 건드려야 하고, 어느 부분이 실제 원인인지 파악하는 데 시간이 오래 걸린다.[4] 따라서 결합도는 단독으로만 평가하기보다 응집, 모듈화, 책임 분리와 함께 읽어야 한다.[5]
3. 결합도의 종류
전통적인 구조적 설계에서는 결합도를 보통 낮은 수준에서 높은 수준으로 나눈다. 일반적인 순서는 데이터 결합도, 스탬프 결합도, 제어 결합도, 공통 결합도, 내용 결합도이다.[2][3] 이 구분은 데이터와 제어가 설계 경계를 얼마나 침범하는지를 판단하는 데 유용하다.
- 데이터 결합도: 필요한 데이터만 인자로 전달하는 방식이다. 호출자는 받는 쪽의 내부 구조를 거의 모른다.
- 스탬프 결합도: 구조체나 객체처럼 묶인 데이터를 통째로 전달하지만, 받는 쪽은 그중 일부만 사용한다. 인터페이스가 필요 이상으로 넓어지기 쉽다.[3]
- 제어 결합도: 어떤 제어값을 넘겨서 받는 쪽의 동작을 직접 바꾸는 방식이다. 호출자가 수신자의 제어 논리까지 신경 써야 한다.[2]
- 공통 결합도: 여러 모듈이 같은 전역 데이터나 공유 상태를 함께 사용하는 방식이다. 한 곳의 변경이 다른 곳으로 쉽게 번진다.[3]
- 내용 결합도: 한 모듈이 다른 모듈의 내부 구현이나 지역 데이터에 직접 의존하는 가장 강한 결합이다. 변경 비용과 위험이 가장 크다.[2]
이 분류에서 핵심은 "많이 주고받는다"보다 "상대의 내부를 얼마나 알아야 하는가"이다. 같은 데이터 교환이라도 공개된 값만 주고받는지, 내부 구조나 제어 논리까지 침범하는지에 따라 결합도의 성격이 달라진다.[1][3]
4. 결합도를 낮추는 방법
결합도를 낮추려면 모듈의 경계를 분명히 하고, 외부에는 꼭 필요한 정보만 노출해야 한다.[1] 공개 인터페이스를 작게 유지하고, 구현 세부 사항은 숨기면 유지보수성과 아키텍처 안정성이 높아지고 변경이 한쪽에 국한되기 쉽다.[5] 이런 정보 은닉은 모듈화된 설계를 독립적으로 이해하고 교체할 수 있게 만든다.[5]
또한 한 모듈이 다른 모듈의 제어 흐름을 대신 결정하지 않도록 해야 한다. 플래그 값으로 행동을 바꾸는 대신 의미가 분명한 함수나 인터페이스로 분리하면 결합이 완화된다.[2] 공유 상태를 줄이고, 필요한 경우에도 읽기 전용 데이터나 명시적 메시지로 협력 범위를 제한하는 편이 낫다.[3]
설계 관점에서 낮은 결합도는 유지보수성과 확장성을 동시에 돕는다. 연결이 느슨할수록 특정 기능을 바꾸어도 파급 범위가 작아지고, 시스템을 부분적으로 교체하거나 재사용하기도 쉬워진다.[4][5] 그래서 실무에서는 결합도를 "무조건 0에 가깝게" 만드는 것이 아니라, 책임 분리와 운영 복잡성 사이의 균형을 맞추는 문제로 다룬다.[4]