113. 결합도 (Coupling)

핵심 인사이트 (3줄 요약)

본질: 결합도 (Coupling)는 서로 다른 모듈(클래스·컴포넌트·서비스)이 상호 의존하는 정도를 측정하는 척도로, 낮을수록 모듈이 독립적이고 변경 파급이 제한되어 유지보수가 용이하다.

가치: 결합도를 낮추면 한 모듈의 변경이 다른 모듈에 미치는 영향을 최소화할 수 있어, 대규모 시스템에서의 병렬 개발·독립 배포·단위 테스트가 가능해진다.

판단 포인트: 콘스탄틴의 6단계 결합도 중 데이터 결합도(Data Coupling)가 최선이며, 내용 결합도(Content Coupling)가 최악이다. 실무에서는 "모듈 A를 수정할 때 반드시 B도 수정해야 하는가?"로 결합도를 판단한다.

Ⅰ. 개요 및 필요성

결합도는 응집도(Cohesion)와 함께 1974년 콘스탄틴의 연구에서 정립된 소프트웨어 모듈 설계 품질 지표다. 높은 결합도(tight coupling)는 분산된 코드 변경(shotgun surgery), 연쇄적 테스트 실패, 독립 배포 불가라는 3가지 유지보수 재앙을 유발한다.

마이크로서비스 아키텍처(MSA)의 핵심 목표 중 하나가 서비스 간 결합도를 최소화하여 독립적 배포를 달성하는 것이다. 반대로 모놀리식(Monolithic) 시스템에서 결합도가 높아지면 어느 한 부분의 배포가 전체 시스템 재시작을 필요로 하게 된다.

┌─────────────────────────────────────────────────────────────┐
│        결합도 6단계: 최악 → 최선                             │
├─────────────────────────────────────────────────────────────┤
│  1. 내용 결합도 (Content Coupling) ← 가장 나쁨              │
│     └─ 다른 모듈의 내부 데이터·코드에 직접 접근             │
│  2. 공통 결합도 (Common Coupling)                           │
│     └─ 전역 변수(global variable) 공유                      │
│  3. 외부 결합도 (External Coupling)                         │
│     └─ 외부 데이터 형식·통신 프로토콜 공유                  │
│  4. 제어 결합도 (Control Coupling)                          │
│     └─ 제어 플래그(flag)를 전달하여 실행 흐름 제어          │
│  5. 스탬프 결합도 (Stamp Coupling)                          │
│     └─ 필요 이상의 데이터 구조(객체 전체)를 전달             │
│  6. 데이터 결합도 (Data Coupling) ← 가장 좋음               │
│     └─ 필요한 데이터만 매개변수로 전달                       │
└─────────────────────────────────────────────────────────────┘

결합도 개념 없이 설계하면 "스파게티 코드(spaghetti code)"가 형성되어, 어디서 어디가 의존하는지 파악할 수 없는 상태가 된다. 이는 새 기능 추가 시 어디를 건드려야 할지 모르는 상황으로 이어진다.

📢 섹션 요약 비유: 기차 객차들이 너무 단단히 연결되어 있으면 하나가 고장 나도 전체를 정지해야 한다. 적절히 느슨한 연결고리가 있어야 특정 객차만 교체할 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

결합도를 낮추는 핵심 기법은 인터페이스(interface)를 통한 간접 참조, 이벤트 기반 비동기 통신, 메시지 브로커(message broker)를 통한 중간자 삽입이다. 직접 메서드 호출 대신 이벤트를 발행(publish)하고 구독(subscribe)하면 발행자와 구독자가 서로를 알 필요가 없어진다.

항목	설명	포인트
인터페이스 추상화	클래스 수준	DIP, 팩토리 패턴
이벤트 기반 통신	컴포넌트 수준	옵저버 패턴, 이벤트 버스
메시지 브로커	서비스 수준	Kafka, RabbitMQ
API 게이트웨이	네트워크 수준	REST, gRPC 표준 인터페이스

┌─────────────────────────────────────────────────────────────┐
│      이벤트 기반 결합도 감소: 직접 호출 → 이벤트 발행       │
├─────────────────────────────────────────────────────────────┤
│ [강결합 - 직접 호출]                                        │
│  OrderService ──▶ InventoryService (직접 의존)              │
│  OrderService ──▶ NotificationService (직접 의존)           │
│                                                             │
│ [약결합 - 이벤트 발행]                                      │
│  OrderService ──▶ EventBus ◀── InventoryService (구독)      │
│                       ◀── NotificationService (구독)        │
│                                                             │
│  결과: OrderService는 다른 서비스를 전혀 알지 못함           │
└─────────────────────────────────────────────────────────────┘

측정 지표로 구심성(Afferent Coupling, Ca)과 원심성(Efferent Coupling, Ce)이 있다. Ca는 해당 모듈을 의존하는 외부 모듈 수, Ce는 해당 모듈이 의존하는 외부 모듈 수다. 불안정도(Instability) = Ce / (Ca + Ce) 공식으로 모듈의 변경 취약성을 정량화할 수 있다.

📢 섹션 요약 비유: 음악 앙상블에서 각 악기 연주자가 악보(인터페이스)만 보고 연주하면, 특정 연주자가 바뀌어도 전체 연주는 계속된다. 하지만 연주자들이 서로의 손 동작을 보며 실시간으로 맞추면 한 명이 빠질 때 전체가 멈춘다.

Ⅲ. 비교 및 연결

결합도는 응집도(Cohesion)와 반드시 함께 검토해야 하며, 이 둘의 관계는 단순히 "결합도 낮추기 = 응집도 높이기"가 아니다. 둘 다 최적화해야 하는 독립적인 두 차원이다.

비교 축	A	B
관찰 대상	모듈 간 연결	모듈 내부 요소들
목표 방향	낮을수록 좋음	높을수록 좋음
위반 증상	한 수정이 여러 모듈 변경을 강제	한 모듈이 여러 이유로 변경됨
개선 기법	인터페이스, 이벤트, 메시지 브로커	SRP, 기능별 클래스 분리

MSA에서 서비스 결합도의 형태는 두 가지다. 데이터베이스를 공유하는 "DB 공유 결합(Shared Database Coupling)"이 가장 나쁜 패턴이고, 각 서비스가 독립 DB를 가지며 이벤트로만 데이터를 동기화하는 "이벤트 결합"이 MSA에서 권장되는 형태다.

📢 섹션 요약 비유: 도미노는 하나가 쓰러지면 전부 쓰러지는 최악의 결합 구조다. 반면 각자 독립적으로 세워진 조각품들은 하나가 쓰러져도 나머지에 영향을 주지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

결합도 감사(audit)는 감리 현장에서 응용 시스템 영역 감리의 핵심 점검 항목이다. 감리인은 클래스 의존성 다이어그램(class dependency diagram), 패키지 의존성 순환(circular dependency), 서비스 간 동기 호출 체인(synchronous call chain) 깊이를 점검한다.

판단 체크리스트

모듈 A를 수정할 때 모듈 B도 반드시 수정해야 하는 경우가 있는가?
단위 테스트 시 다른 클래스나 서비스의 실제 구현이 없으면 테스트가 안 되는가?
전역 변수(global state) 또는 공유 데이터베이스를 통한 통신이 존재하는가?
패키지 간 순환 의존성(A → B → A)이 발생하는가?
서비스 간 동기 REST 호출 깊이가 3단계를 초과하는가?

📢 섹션 요약 비유: 전기 콘센트에 멀티탭 하나가 연결되고, 그 멀티탭에 또 멀티탭이, 그 안에 또 멀티탭이 꽂혀 있으면 하나가 차단기를 내려도 전체 가전이 꺼진다. 결합을 분산하고 독립적 회로를 구성해야 한다.

Ⅴ. 기대효과 및 결론

결합도를 체계적으로 관리하면 각 모듈을 독립적으로 배포할 수 있는 CD (Continuous Delivery, 지속적 배포) 파이프라인이 현실화된다. 특히 MSA 환경에서 팀 A가 서비스 A를 팀 B 승인 없이 독립 배포할 수 있는 조직적 이점(Conway의 법칙 역활용)이 생긴다. 장애 격리(fault isolation)도 강화되어 한 서비스의 장애가 전체 시스템 다운으로 이어지지 않는다.

한계는 결합도를 낮출수록 시스템 전체의 데이터 일관성(consistency) 관리가 어려워진다는 점이다. 이벤트 기반 비동기 통신은 최종 일관성(eventual consistency)을 수용해야 하며, 이는 트랜잭션 보장이 필수인 금융 거래 같은 도메인에서 설계 트레이드오프를 요구한다.

미래 방향으로는 ① 서비스 메시(Service Mesh)를 통한 런타임 결합도 가시화, ② eBPF(extended Berkeley Packet Filter) 기반 실시간 의존성 추적, ③ DDD의 바운디드 컨텍스트 자동 경계 도출 도구가 발전하고 있다.

결합도는 "변경할 수 있는 자유도"의 척도다. 낮은 결합도는 팀이 두려움 없이 코드를 변경할 수 있는 환경을 만들며, 이것이 소프트웨어 진화 속도를 결정한다.

📢 섹션 요약 비유: 모듈식 가구는 각 부품이 표준 나사 하나로 연결되어 있어 원하는 부분만 교체하거나 재배치할 수 있다. 모든 부품이 용접된 가구는 하나가 망가지면 전체를 버려야 한다.

📌 관련 개념 맵

[스파게티 코드] → [결합도 측정] → [인터페이스 추상화·이벤트] → [낮은 결합도] → [MSA 독립 배포]

개념	연결 포인트
응집도 (Cohesion)	결합도와 함께 모듈 설계 품질의 양대 축
DIP (의존성 역전 원칙)	결합도를 낮추기 위한 인터페이스 기반 설계 원칙
EDA (이벤트 주도 아키텍처)	서비스 간 결합도를 이벤트로 낮추는 아키텍처
바운디드 컨텍스트	DDD의 서비스 간 결합도 경계 설계 기준

📈 관련 키워드 및 발전 흐름도

[강결합 스파게티 코드] → [결합도 6단계 정립] → [인터페이스·DI 도입] → [이벤트 기반 비동기 통신] → [MSA 서비스 독립 배포] → [서비스 메시 결합도 가시화]

👶 어린이를 위한 3줄 비유 설명

레고 블록은 똑같은 모양의 구멍으로 연결되어 있어서 원하는 블록만 빼고 다른 것을 끼울 수 있어요.
만약 모든 블록이 접착제로 붙어 있다면 하나를 바꾸려면 다 뜯어야 해요.
결합도가 낮다는 건 레고처럼 쉽게 끼우고 뺄 수 있는 구조를 뜻해요!