결합도

작성자

익명

작성일

2026.08.01

조회수

버전

결합도 소프트웨어 공학 낮은 결합도 의존성 주입 SOLID 원칙 디자인 패턴 이벤트 기반 아키텍처 기술 부채 중급

📋 문서 버전

이 문서는 3개의 버전이 있습니다. 현재 최신 버전을 보고 있습니다.

결합도

개요

결합도(Coupling)는 소프트웨어 공학에서 모듈 간의 상호 의존성 정도를 나타내는 척도입니다. 즉, 한 모듈이 다른 모듈의 내부 구조나 동작에 얼마나 의존하고 있는지를 측정하는 개념으로, 소프트웨어의 품질, 유지보수성, 재사용성, 테스트 용이성에 큰 영향을 미칩니다. 일반적으로 결합도가 낮을수록(즉, 모듈 간 의존성이 적을수록) 소프트웨어 시스템은 더 유연하고 변경에 강하며, 오류 전파가 적어지는 장점이 있습니다.

결합도는 응집도(Cohesion)와 함께 소프트웨어 모듈의 설계 품질을 평가하는 핵심 요소로, 두 개념은 종종 함께 고려됩니다. 이상적인 소프트웨어 설계는 낮은 결합도(low coupling)와 높은 응집도(high cohesion)를 동시에 추구합니다.

결합도의 중요성

결합도는 소프트웨어 아키텍처와 설계의 핵심 원칙 중 하나로, 다음과 같은 이유로 중요합니다:

유지보수성 향상: 모듈 간 의존성이 낮으면 한 모듈의 수정이 다른 모듈에 미치는 영향이 적어져, 유지보수가 용이해집니다.
재사용성 증가: 독립적인 모듈은 다른 시스템에서도 쉽게 재사용할 수 있습니다.
테스트 용이성: 결합도가 낮은 모듈은 단위 테스트(Unit Test)를 수행하기 쉬우며, Mock 객체 등을 활용한 격리된 테스트가 가능합니다.
병렬 개발 가능: 팀원들이 서로 의존하지 않는 모듈을 독립적으로 개발할 수 있어 개발 속도가 향상됩니다.
오류 격리: 오류가 발생하더라도 특정 모듈에 국한되어 시스템 전체에 파급되는 것을 방지할 수 있습니다.

결합도의 유형

결합도는 그 정도에 따라 여러 등급으로 분류할 수 있으며, 일반적으로 아래와 같은 순서로 낮은 결합도에서 높은 결합도로 나뉩니다.

1. 비결합도 (No Coupling)

모듈 간에 전혀 의존성이 없는 상태.
현실적으로 거의 불가능하며, 시스템 전체가 하나의 기능도 수행할 수 없습니다.

2. 데이터 결합도 (Data Coupling)

모듈 간에 기본 자료형(예: 정수, 문자열)이나 단순 구조체를 매개변수로 전달하는 정도의 의존성.
가장 이상적인 결합도 수준 중 하나로, 정보 은닉이 잘 지켜진 경우입니다.

3. 스탬프 결합도 (Stamp Coupling)

모듈이 레코드나 구조체 전체를 전달받지만, 그 중 일부 필드만 사용하는 경우.
불필요한 정보를 공유하므로 결합도가 다소 높아집니다.
예: User 객체 전체를 전달하지만, 이름만 사용하는 경우.

4. 제어 결합도 (Control Coupling)

한 모듈이 다른 모듈의 실행 흐름을 제어하는 정보(예: 플래그, 타입 코드)를 전달하는 경우.
예: type 매개변수에 따라 다른 동작을 수행하는 함수.
이는 모듈의 내부 로직이 외부에 노출되므로 결합도가 높아집니다.

5. 외부 결합도 (External Coupling)

공통된 외부 제약사항(예: 데이터 포맷, 통신 프로토콜, 하드웨어 인터페이스)에 의해 결합된 경우.
예: 두 모듈이 모두 JSON 형식을 사용해야 하므로 결합됨.

6. 공통 결합도 (Common Coupling)

여러 모듈이 전역 변수나 공유 데이터 공간을 참조하거나 수정하는 경우.
한 모듈의 변경이 다른 모듈에 예측할 수 없는 영향을 미칠 수 있어 위험합니다.

7. 내용 결합도 (Content Coupling)

한 모듈이 다른 모듈의 내부 코드나 데이터를 직접 접근하는 경우.
가장 높은 결합도이며, 설계상 심각한 결함으로 간주됩니다.
예: 함수 내부의 지역 변수를 외부에서 수정하는 경우.

낮은 결합도를 위한 설계 원칙

낮은 결합도를 달성하기 위해 다음과 같은 소프트웨어 설계 원칙과 패턴을 활용할 수 있습니다.

1. 의존성 역전 원칙 (Dependency Inversion Principle, DIP)

고수준 모듈이 저수준 모듈에 의존하지 않도록, 추상화된 인터페이스를 통해 결합도를 낮춥니다.
예: PaymentService가 CreditCardProcessor에 직접 의존하지 않고, PaymentProcessor 인터페이스를 통해 결합.

2. 의존성 주입 (Dependency Injection, DI)

객체의 의존성을 외부에서 주입함으로써, 하드코딩된 의존성을 제거합니다.
스프링 프레임워크 등에서 널리 사용됩니다.

public class OrderService {
    private PaymentProcessor processor;

    // 의존성 주입
    public OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }
}

3. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

클라이언트가 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 작게 분리합니다.
불필요한 결합을 방지합니다.

4. 관측자 패턴, 전략 패턴 등 디자인 패턴 활용

디자인 패턴은 결합도를 낮추고 유연성을 높이는 데 효과적입니다.
예: 전략 패턴을 사용하면 알고리즘을 런타임에 교체할 수 있어 결합도를 줄입니다.

결합도 측정 방법

결합도는 정량적으로 측정할 수 있는 지표로, 다음과 같은 방법들이 사용됩니다:

측정 지표	설명
CBO (Coupling Between Objects)	한 클래스가 다른 클래스를 참조하는 횟수. 값이 높을수록 결합도가 높음.
Fan-in / Fan-out	한 모듈이 얼마나 많은 모듈에 의존하는지(Fan-out), 얼마나 많은 모듈이 자신을 의존하는지(Fan-in)를 측정.
정적 분석 도구	SonarQube, PMD, Checkstyle 등은 결합도 관련 메트릭을 자동으로 계산합니다.

결론

결합도는 소프트웨어 품질을 결정짓는 핵심 요소 중 하나입니다. 낮은 결합도는 시스템의 유연성과 유지보수성을 극대화하며, 장기적인 개발 비용 절감에 기여합니다. 설계 단계에서부터 결합도를 고려하고, 적절한 설계 원칙과 패턴을 적용함으로써 견고하고 확장 가능한 소프트웨어를 구축할 수 있습니다.

강한 결합도의 특성과 위험성

강한 결합도는 모듈 간의 의존성이 과도하여, 하나의 모듈을 변경했을 때 그 영향이 시스템 전체로 빠르게 퍼지는 상태를 의미합니다. 이는 다음과 같은 세 가지 주요 위험성을 초래합니다.

경직성 (Rigidity): 작은 변경 사항 하나를 적용하기 위해 수많은 관련 모듈을 함께 수정해야 하므로, 시스템이 변화에 매우 둔감해집니다.
취약성 (Fragility): 한 곳을 수정했는데 전혀 상관없어 보이는 다른 곳에서 예상치 못한 버그가 발생하는 현상입니다.
부동성 (Immobility): 특정 모듈이 너무 많은 다른 모듈과 얽혀 있어, 해당 기능을 다른 프로젝트나 시스템으로 떼어내어 재사용하는 것이 사실상 불가능합니다.

변경의 연쇄 반응 (Ripple Effect)

강한 결합도 환경에서는 리플 이펙트(Ripple Effect)가 발생합니다. 이는 마치 호수에 돌을 던지면 파동이 퍼져나가는 것처럼, 하나의 수정 사항이 연쇄적으로 다른 모듈의 수정을 강제하는 현상입니다.

[리플 이펙트 시각적 다이어그램] 수정 발생 (Module A) $\rightarrow$ 의존성 전파 (Module B 수정 필요) $\rightarrow$ 추가 전파 (Module C 수정 필요) $\rightarrow$ 예상치 못한 오류 (Module D 장애 발생)

강한 결합도의 사례와 징후

코드 수준에서 다음과 같은 현상이 빈번하게 나타난다면 강한 결합도를 의심해야 합니다.

1. 코드 수준의 징후

수정 범위의 폭발: 클래스 하나를 수정했는데, 컴파일 에러를 해결하기 위해 수십 개의 파일을 함께 수정해야 하는 경우.
테스트 불가능성: 특정 모듈을 테스트하려는데, 그 모듈이 의존하는 거대한 외부 시스템이나 데이터베이스가 없으면 단위 테스트 자체가 불가능한 경우.
과도한 지식 공유: A 클래스가 B 클래스의 내부 구현 상세(private 필드에 가까운 접근이나 내부 로직 순서)를 너무 잘 알고 있어, B의 내부 로직을 바꾸면 A가 즉시 고장 나는 경우.

2. 전후 비교 코드 예제

[강한 결합도: 구체 클래스에 직접 의존]

// 결합도가 높은 설계: OrderService가 구체적인 KakaoPay 클래스에 직접 의존
public class OrderService {
    private KakaoPay kakaoPay = new KakaoPay(); // 강한 결합

    public void processOrder() {
        kakaoPay.pay(); 
    }
}
// 문제점: NaverPay로 변경하려면 OrderService의 코드를 직접 수정해야 함.

[낮은 결합도: 인터페이스를 통한 추상화]

// 결합도가 낮은 설계: 인터페이스(Payment)를 통해 의존성 분리
public interface Payment {
    void pay();
}

public class OrderService {
    private Payment payment;

    public OrderService(Payment payment) { // 의존성 주입 (DI)
        this.payment = payment;
    }

    public void processOrder() {
        payment.pay();
    }
}
// 장점: OrderService 수정 없이 KakaoPay, NaverPay 등 어떤 결제 수단으로든 교체 가능.

기술 부채와 생산성 저하

낮은 결합도가 주는 이점의 반대편에는 강한 결합도로 인한 심각한 기술 부채(Technical Debt)가 존재합니다.

개발 속도의 기하급수적 저하: 초기 개발 단계에서는 빠르게 기능을 구현할 수 있으나, 시스템이 커질수록 '수정 $\rightarrow$ 사이드 이펙트 발생 $\rightarrow$ 수정'의 반복 굴레에 빠져 기능 하나를 추가하는 데 드는 시간이 점점 늘어납니다.
심리적 저항과 공포: 개발자가 "여기 하나 고쳤다가 어디서 터질지 모른다"는 공포감을 느끼게 되어, 과감한 리팩토링을 기피하고 기존의 나쁜 코드를 계속 덧붙이는 악순환이 발생합니다.
품질 관리 비용 증가: 영향 범위 파악이 어렵기 때문에, 작은 수정 후에도 시스템 전체를 다시 테스트해야 하는 전수 회귀 테스트(Full Regression Test) 비용이 증가합니다.

결합도 유형별 유지보수 문제 사례

각 결합도 유형이 강해졌을 때 발생하는 구체적인 유지보수 문제는 다음과 같습니다.

결합도 유형	유지보수 문제 사례	구체적인 영향
데이터 결합도	매개변수 타입 변경	전달하는 기본 자료형이 변경되면 호출하는 모든 모듈의 시그니처를 수정해야 함.
스탬프 결합도	데이터 구조(DTO) 변경	사용하지 않는 필드를 삭제하거나 구조를 변경했을 때, 해당 객체를 받는 모든 모듈에서 컴파일 에러 발생.
제어 결합도	제어 플래그 추가	새로운 동작 모드를 추가하기 위해 `if-else`나 `switch` 문이 포함된 모든 모듈의 로직을 수정해야 함.
외부 결합도	외부 API/포맷 변경	외부 라이브러리 버전 업데이트나 JSON 스키마 변경 시, 이를 사용하는 모든 모듈이 동시에 마비됨.
공통 결합도	전역 변수 값 변경	특정 모듈에서 전역 변수 값을 바꿨는데, 전혀 상관없는 다른 모듈에서 런타임 오류가 발생하며 원인 추적이 매우 어려움.
내용 결합도	내부 구현 변경	다른 모듈의 내부 변수나 로직을 직접 참조하고 있어, 내부 최적화나 리팩토링을 수행하는 순간 시스템이 붕괴됨.

결합도의 관점 보완: 적정 결합도의 필요성

결합도는 단순히 '낮을수록 좋은 것'이 아니라, 시스템의 목적과 복잡도에 따라 적절한 수준의 연결이 필요합니다. 모든 모듈을 완전히 분리하려고 시도하면 모듈 간의 상호작용을 정의하는 인터페이스가 지나치게 많아지고, 전체적인 시스템 흐름을 파악하기 어려워지는 '파편화' 현상이 발생합니다. 따라서 설계의 핵심은 무조건적인 분리가 아니라, 변경 가능성이 높은 부분은 낮게 결합하고, 함께 변경되어야 하는 논 적절한 수준의 결합을 유지하는 전략적 결합 관리에 있습니다.

비동기 결합과 현대적 분리 기법

전통적인 동기식 호출(Synchronous Call)은 호출자가 응답을 기다려야 하므로 실행 흐름과 가용성 측면에서 강하게 결합됩니다. 이를 해결하기 위해 현대적인 아키텍처에서는 다음과 같은 비동기 결합(Asynchronous Coupling) 기법을 사용합니다.

이벤트 기반 아키텍처 (Event-Driven Architecture): 모듈이 직접 다른 모듈을 호출하는 대신, 특정 상태 변경을 '이벤트'로 발행(Publish)하고 관심 있는 모듈이 이를 구독(Subscribe)하는 방식입니다. 발행자는 구독자가 누구인지, 몇 명인지 알 필요가 없으므로 결합도가 극도로 낮아집니다.
메시지 큐 (Message Queue) 활용: RabbitMQ, Apache Kafka와 같은 메시지 브로커를 중간에 두어 송신자와 수신자를 물리적·시간적으로 분리합니다. 이를 통해 수신 시스템이 일시적으로 다운되더라도 송신 시스템은 영향을 받지 않는 '시간적 디커플링(Temporal Decoupling)'을 달성할 수 있습니다.

결합도와 아키텍처 스타일

시스템 구조 수준에서 결합도를 관리하는 방식은 아키텍처 스타일에 따라 다릅니다.

계층형 아키텍처 (Layered Architecture): 상위 계층이 하위 계층에만 의존하도록 단방향 의존성을 강제하여 결합도를 제어합니다. 특히 '서비스 계층'과 '데이터 액세스 계층' 사이에 인터페이스를 두어 DB 구현체 변경이 비즈니스 로직에 영향을 주지 않도록 설계합니다.
마이크로서비스 아키텍처 (MSA): 서비스 간의 직접적인 HTTP 호출은 런타임 결합도를 높입니다. 이를 해결하기 위해 API 게이트웨이(API Gateway)를 활용합니다.
- API 게이트웨이 활용 사례: 클라이언트는 개별 마이크로서비스의 주소를 알 필요 없이 게이트웨이의 단일 엔드포인트만 호출합니다. 게이트웨이가 요청을 적절한 서비스로 라우팅함으로써, 내부 서비스의 위치 변경이나 서비스 분할/통합이 일어나도 클라이언트와의 결합도는 유지되지 않고 격리됩니다.

결합도의 트레이드오프 (Trade-off)

낮은 결합도를 추구하는 과정에서 발생하는 부작용과 실무적 균형점은 다음과 같습니다.

과도한 추상화 비용: 모든 의존성을 인터페이스로 분리하고 DI(의존성 주입)를 적용하면, 실제 로직을 찾기 위해 여러 클래스를 옮겨 다녀야 하는 '코드 추적의 어려움'이 발생하며, 단순한 기능 구현에도 많은 보일러플레이트 코드가 필요하게 됩니다.
성능 저하 사례:
- 간접 호출 오버헤드: 과도한 추상화 계층(Proxy, Wrapper, Adapter 등)을 거치면서 함수 호출 스택이 깊어지고, 이는 CPU 캐시 효율 저하 및 런타임 오버헤드로 이어질 수 있습니다.
- 네트워크 홉(Hop) 증가: MSA에서 결합도를 낮추기 위해 서비스를 너무 세밀하게 쪼개면, 하나의 요청을 처리하기 위해 수많은 네트워크 통신이 발생하여 응답 속도가 급격히 느려지는 현상이 발생합니다.

변경 전파 분석 (Change Propagation Analysis)

정적 분석 지표 외에, 실제 코드 변경 시 수정되는 범위의 상관관계를 통해 결합도를 측정하는 방법입니다.

변경 전파 지수 (Propagation Cost)

특정 모듈 $M_i$를 수정했을 때, 그 영향으로 인해 함께 수정되어야 하는 모듈들의 비율을 측정합니다.

$$ \text{Propagation Cost} = \frac{\sum_{i=1}^{n} \text{Affected Modules}(M_i)}{n^2} $$

$n$: 시스템 내 전체 모듈의 수
$\text{Affected Modules}(M_i)$: 모듈 $M_i$ 변경 시 영향을 받는 모듈의 수 (자기 자신 포함)

이 수치가 높을수록 시스템의 전반적인 결합도가 높으며, 작은 변경이 시스템 전체로 퍼지는 '리플 이펙트'가 강하게 나타나고 있음을 의미합니다. 실무에서는 Git 커밋 로그를 분석하여 "함께 수정되는 파일들의 빈도(Co-change frequency)"를 측정함으로써 잠재적인 강결합 지점을 찾아낼 수 있습니다.

📝 마크다운 원본

이 문서의 마크다운 원본 내용입니다.

# 결합도

## 개요

**결합도**(Coupling)는 소프트웨어 공학에서 모듈 간의 상호 의존성 정도를 나타내는 척도입니다. 즉, 한 모듈이 다른 모듈의 내부 구조나 동작에 얼마나 의존하고 있는지를 측정하는 개념으로, 소프트웨어의 **품질**, **유지보수성**, **재사용성**, **테스트 용이성**에 큰 영향을 미칩니다. 일반적으로 결합도가 낮을수록(즉, 모듈 간 의존성이 적을수록) 소프트웨어 시스템은 더 유연하고 변경에 강하며, 오류 전파가 적어지는 장점이 있습니다.

결합도는 **응집도**(Cohesion)와 함께 소프트웨어 모듈의 설계 품질을 평가하는 핵심 요소로, 두 개념은 종종 함께 고려됩니다. 이상적인 소프트웨어 설계는 **낮은 결합도**(low coupling)와 **높은 응집도**(high cohesion)를 동시에 추구합니다.

---

## 결합도의 중요성

결합도는 소프트웨어 아키텍처와 설계의 핵심 원칙 중 하나로, 다음과 같은 이유로 중요합니다:

- **유지보수성 향상**: 모듈 간 의존성이 낮으면 한 모듈의 수정이 다른 모듈에 미치는 영향이 적어져, 유지보수가 용이해집니다.
- **재사용성 증가**: 독립적인 모듈은 다른 시스템에서도 쉽게 재사용할 수 있습니다.
- **테스트 용이성**: 결합도가 낮은 모듈은 단위 테스트(Unit Test)를 수행하기 쉬우며, Mock 객체 등을 활용한 격리된 테스트가 가능합니다.
- **병렬 개발 가능**: 팀원들이 서로 의존하지 않는 모듈을 독립적으로 개발할 수 있어 개발 속도가 향상됩니다.
- **오류 격리**: 오류가 발생하더라도 특정 모듈에 국한되어 시스템 전체에 파급되는 것을 방지할 수 있습니다.

---

## 결합도의 유형

결합도는 그 정도에 따라 여러 등급으로 분류할 수 있으며, 일반적으로 아래와 같은 순서로 낮은 결합도에서 높은 결합도로 나뉩니다.

### 1. 비결합도 (No Coupling)
- 모듈 간에 전혀 의존성이 없는 상태.
- 현실적으로 거의 불가능하며, 시스템 전체가 하나의 기능도 수행할 수 없습니다.

### 2. 데이터 결합도 (Data Coupling)
- 모듈 간에 **기본 자료형**(예: 정수, 문자열)이나 **단순 구조체**를 매개변수로 전달하는 정도의 의존성.
- 가장 이상적인 결합도 수준 중 하나로, 정보 은닉이 잘 지켜진 경우입니다.

### 3. 스탬프 결합도 (Stamp Coupling)
- 모듈이 **레코드나 구조체 전체**를 전달받지만, 그 중 일부 필드만 사용하는 경우.
- 불필요한 정보를 공유하므로 결합도가 다소 높아집니다.
- 예: `User` 객체 전체를 전달하지만, 이름만 사용하는 경우.

### 4. 제어 결합도 (Control Coupling)
- 한 모듈이 다른 모듈의 **실행 흐름을 제어**하는 정보(예: 플래그, 타입 코드)를 전달하는 경우.
- 예: `type` 매개변수에 따라 다른 동작을 수행하는 함수.
- 이는 모듈의 내부 로직이 외부에 노출되므로 결합도가 높아집니다.

### 5. 외부 결합도 (External Coupling)
- 공통된 **외부 제약사항**(예: 데이터 포맷, 통신 프로토콜, 하드웨어 인터페이스)에 의해 결합된 경우.
- 예: 두 모듈이 모두 JSON 형식을 사용해야 하므로 결합됨.

### 6. 공통 결합도 (Common Coupling)
- 여러 모듈이 **전역 변수**나 공유 데이터 공간을 참조하거나 수정하는 경우.
- 한 모듈의 변경이 다른 모듈에 예측할 수 없는 영향을 미칠 수 있어 위험합니다.

### 7. 내용 결합도 (Content Coupling)
- 한 모듈이 다른 모듈의 **내부 코드나 데이터를 직접 접근**하는 경우.
- 가장 높은 결합도이며, 설계상 심각한 결함으로 간주됩니다.
- 예: 함수 내부의 지역 변수를 외부에서 수정하는 경우.

---

## 낮은 결합도를 위한 설계 원칙

낮은 결합도를 달성하기 위해 다음과 같은 소프트웨어 설계 원칙과 패턴을 활용할 수 있습니다.

### 1. 의존성 역전 원칙 (Dependency Inversion Principle, DIP)
- 고수준 모듈이 저수준 모듈에 의존하지 않도록, **추상화된 인터페이스**를 통해 결합도를 낮춥니다.
- 예: `PaymentService`가 `CreditCardProcessor`에 직접 의존하지 않고, `PaymentProcessor` 인터페이스를 통해 결합.

### 2. 의존성 주입 (Dependency Injection, DI)
- 객체의 의존성을 외부에서 주입함으로써, 하드코딩된 의존성을 제거합니다.
- 스프링 프레임워크 등에서 널리 사용됩니다.

```java
public class OrderService {
    private PaymentProcessor processor;

    // 의존성 주입
    public OrderService(PaymentProcessor processor) {
        this.processor = processor;
    }
}
```

### 3. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)
- 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 작게 분리합니다.
- 불필요한 결합을 방지합니다.

### 4. 관측자 패턴, 전략 패턴 등 디자인 패턴 활용
- 디자인 패턴은 결합도를 낮추고 유연성을 높이는 데 효과적입니다.
- 예: 전략 패턴을 사용하면 알고리즘을 런타임에 교체할 수 있어 결합도를 줄입니다.

---

## 결합도 측정 방법

결합도는 정량적으로 측정할 수 있는 지표로, 다음과 같은 방법들이 사용됩니다:

| 측정 지표 | 설명 |
|----------|------|
| **CBO (Coupling Between Objects)** | 한 클래스가 다른 클래스를 참조하는 횟수. 값이 높을수록 결합도가 높음. |
| **Fan-in / Fan-out** | 한 모듈이 얼마나 많은 모듈에 의존하는지(Fan-out), 얼마나 많은 모듈이 자신을 의존하는지(Fan-in)를 측정. |
| 정적 분석 도구 | SonarQube, PMD, Checkstyle 등은 결합도 관련 메트릭을 자동으로 계산합니다. |

---

## 결론

결합도는 소프트웨어 품질을 결정짓는 핵심 요소 중 하나입니다. 낮은 결합도는 시스템의 유연성과 유지보수성을 극대화하며, 장기적인 개발 비용 절감에 기여합니다. 설계 단계에서부터 결합도를 고려하고, 적절한 설계 원칙과 패턴을 적용함으로써 견고하고 확장 가능한 소프트웨어를 구축할 수 있습니다.

---

## 관련 문서 및 참고 자료

- [SOLID 원칙](https://ko.wikipedia.org/wiki/SOLID)
- [응집도 (Cohesion)](https://ko.wikipedia.org/wiki/응집도)
- Martin, R. C. (2002). *Agile Software Development, Principles, Patterns, and Practices*.
- SonarQube 공식 문서: [https://www.sonarqube.org/](https://www.sonarqube.org/)

## 강한 결합도의 특성과 위험성

강한 결합도는 모듈 간의 의존성이 과도하여, 하나의 모듈을 변경했을 때 그 영향이 시스템 전체로 빠르게 퍼지는 상태를 의미합니다. 이는 다음과 같은 세 가지 주요 위험성을 초래합니다.

*   **경직성 (Rigidity)**: 작은 변경 사항 하나를 적용하기 위해 수많은 관련 모듈을 함께 수정해야 하므로, 시스템이 변화에 매우 둔감해집니다.
*   **취약성 (Fragility)**: 한 곳을 수정했는데 전혀 상관없어 보이는 다른 곳에서 예상치 못한 버그가 발생하는 현상입니다.
*   **부동성 (Immobility)**: 특정 모듈이 너무 많은 다른 모듈과 얽혀 있어, 해당 기능을 다른 프로젝트나 시스템으로 떼어내어 재사용하는 것이 사실상 불가능합니다.

### 변경의 연쇄 반응 (Ripple Effect)
강한 결합도 환경에서는 **리플 이펙트(Ripple Effect)**가 발생합니다. 이는 마치 호수에 돌을 던지면 파동이 퍼져나가는 것처럼, 하나의 수정 사항이 연쇄적으로 다른 모듈의 수정을 강제하는 현상입니다.

**[리플 이펙트 시각적 다이어그램]**
`수정 발생 (Module A)` $\rightarrow$ `의존성 전파 (Module B 수정 필요)` $\rightarrow$ `추가 전파 (Module C 수정 필요)` $\rightarrow$ `예상치 못한 오류 (Module D 장애 발생)`

---

## 강한 결합도의 사례와 징후

코드 수준에서 다음과 같은 현상이 빈번하게 나타난다면 강한 결합도를 의심해야 합니다.

### 1. 코드 수준의 징후
*   **수정 범위의 폭발**: 클래스 하나를 수정했는데, 컴파일 에러를 해결하기 위해 수십 개의 파일을 함께 수정해야 하는 경우.
*   **테스트 불가능성**: 특정 모듈을 테스트하려는데, 그 모듈이 의존하는 거대한 외부 시스템이나 데이터베이스가 없으면 단위 테스트 자체가 불가능한 경우.
*   **과도한 지식 공유**: A 클래스가 B 클래스의 내부 구현 상세(private 필드에 가까운 접근이나 내부 로직 순서)를 너무 잘 알고 있어, B의 내부 로직을 바꾸면 A가 즉시 고장 나는 경우.

### 2. 전후 비교 코드 예제

**[강한 결합도: 구체 클래스에 직접 의존]**
```java
// 결합도가 높은 설계: OrderService가 구체적인 KakaoPay 클래스에 직접 의존
public class OrderService {
    private KakaoPay kakaoPay = new KakaoPay(); // 강한 결합

    public void processOrder() {
        kakaoPay.pay(); 
    }
}
// 문제점: NaverPay로 변경하려면 OrderService의 코드를 직접 수정해야 함.
```

**[낮은 결합도: 인터페이스를 통한 추상화]**
```java
// 결합도가 낮은 설계: 인터페이스(Payment)를 통해 의존성 분리
public interface Payment {
    void pay();
}

public class OrderService {
    private Payment payment;

    public OrderService(Payment payment) { // 의존성 주입 (DI)
        this.payment = payment;
    }

    public void processOrder() {
        payment.pay();
    }
}
// 장점: OrderService 수정 없이 KakaoPay, NaverPay 등 어떤 결제 수단으로든 교체 가능.
```

---

## 기술 부채와 생산성 저하

낮은 결합도가 주는 이점의 반대편에는 강한 결합도로 인한 심각한 **기술 부채(Technical Debt)**가 존재합니다.

*   **개발 속도의 기하급수적 저하**: 초기 개발 단계에서는 빠르게 기능을 구현할 수 있으나, 시스템이 커질수록 '수정 $\rightarrow$ 사이드 이펙트 발생 $\rightarrow$ 수정'의 반복 굴레에 빠져 기능 하나를 추가하는 데 드는 시간이 점점 늘어납니다.
*   **심리적 저항과 공포**: 개발자가 "여기 하나 고쳤다가 어디서 터질지 모른다"는 공포감을 느끼게 되어, 과감한 리팩토링을 기피하고 기존의 나쁜 코드를 계속 덧붙이는 악순환이 발생합니다.
*   **품질 관리 비용 증가**: 영향 범위 파악이 어렵기 때문에, 작은 수정 후에도 시스템 전체를 다시 테스트해야 하는 전수 회귀 테스트(Full Regression Test) 비용이 증가합니다.

---

## 결합도 유형별 유지보수 문제 사례

각 결합도 유형이 강해졌을 때 발생하는 구체적인 유지보수 문제는 다음과 같습니다.

| 결합도 유형 | 유지보수 문제 사례 | 구체적인 영향 |
| :--- | :--- | :--- |
| **데이터 결합도** | 매개변수 타입 변경 | 전달하는 기본 자료형이 변경되면 호출하는 모든 모듈의 시그니처를 수정해야 함. |
| **스탬프 결합도** | 데이터 구조(DTO) 변경 | 사용하지 않는 필드를 삭제하거나 구조를 변경했을 때, 해당 객체를 받는 모든 모듈에서 컴파일 에러 발생. |
| **제어 결합도** | 제어 플래그 추가 | 새로운 동작 모드를 추가하기 위해 `if-else`나 `switch` 문이 포함된 모든 모듈의 로직을 수정해야 함. |
| **외부 결합도** | 외부 API/포맷 변경 | 외부 라이브러리 버전 업데이트나 JSON 스키마 변경 시, 이를 사용하는 모든 모듈이 동시에 마비됨. |
| **공통 결합도** | 전역 변수 값 변경 | 특정 모듈에서 전역 변수 값을 바꿨는데, 전혀 상관없는 다른 모듈에서 런타임 오류가 발생하며 원인 추적이 매우 어려움. |
| **내용 결합도** | 내부 구현 변경 | 다른 모듈의 내부 변수나 로직을 직접 참조하고 있어, 내부 최적화나 리팩토링을 수행하는 순간 시스템이 붕괴됨. |

## 결합도의 관점 보완: 적정 결합도의 필요성

결합도는 단순히 '낮을수록 좋은 것'이 아니라, 시스템의 목적과 복잡도에 따라 **적절한 수준의 연결**이 필요합니다. 모든 모듈을 완전히 분리하려고 시도하면 모듈 간의 상호작용을 정의하는 인터페이스가 지나치게 많아지고, 전체적인 시스템 흐름을 파악하기 어려워지는 '파편화' 현상이 발생합니다. 따라서 설계의 핵심은 무조건적인 분리가 아니라, 변경 가능성이 높은 부분은 낮게 결합하고, 함께 변경되어야 하는 논 적절한 수준의 결합을 유지하는 **전략적 결합 관리**에 있습니다.

## 비동기 결합과 현대적 분리 기법

전통적인 동기식 호출(Synchronous Call)은 호출자가 응답을 기다려야 하므로 실행 흐름과 가용성 측면에서 강하게 결합됩니다. 이를 해결하기 위해 현대적인 아키텍처에서는 다음과 같은 **비동기 결합(Asynchronous Coupling)** 기법을 사용합니다.

*   **이벤트 기반 아키텍처 (Event-Driven Architecture)**: 모듈이 직접 다른 모듈을 호출하는 대신, 특정 상태 변경을 '이벤트'로 발행(Publish)하고 관심 있는 모듈이 이를 구독(Subscribe)하는 방식입니다. 발행자는 구독자가 누구인지, 몇 명인지 알 필요가 없으므로 결합도가 극도로 낮아집니다.
*   **메시지 큐 (Message Queue) 활용**: RabbitMQ, Apache Kafka와 같은 메시지 브로커를 중간에 두어 송신자와 수신자를 물리적·시간적으로 분리합니다. 이를 통해 수신 시스템이 일시적으로 다운되더라도 송신 시스템은 영향을 받지 않는 '시간적 디커플링(Temporal Decoupling)'을 달성할 수 있습니다.

## 결합도와 아키텍처 스타일

시스템 구조 수준에서 결합도를 관리하는 방식은 아키텍처 스타일에 따라 다릅니다.

*   **계층형 아키텍처 (Layered Architecture)**: 상위 계층이 하위 계층에만 의존하도록 단방향 의존성을 강제하여 결합도를 제어합니다. 특히 '서비스 계층'과 '데이터 액세스 계층' 사이에 인터페이스를 두어 DB 구현체 변경이 비즈니스 로직에 영향을 주지 않도록 설계합니다.
*   **마이크로서비스 아키텍처 (MSA)**: 서비스 간의 직접적인 HTTP 호출은 런타임 결합도를 높입니다. 이를 해결하기 위해 **API 게이트웨이(API Gateway)**를 활용합니다.
    *   **API 게이트웨이 활용 사례**: 클라이언트는 개별 마이크로서비스의 주소를 알 필요 없이 게이트웨이의 단일 엔드포인트만 호출합니다. 게이트웨이가 요청을 적절한 서비스로 라우팅함으로써, 내부 서비스의 위치 변경이나 서비스 분할/통합이 일어나도 클라이언트와의 결합도는 유지되지 않고 격리됩니다.

## 결합도의 트레이드오프 (Trade-off)

낮은 결합도를 추구하는 과정에서 발생하는 부작용과 실무적 균형점은 다음과 같습니다.

*   **과도한 추상화 비용**: 모든 의존성을 인터페이스로 분리하고 DI(의존성 주입)를 적용하면, 실제 로직을 찾기 위해 여러 클래스를 옮겨 다녀야 하는 '코드 추적의 어려움'이 발생하며, 단순한 기능 구현에도 많은 보일러플레이트 코드가 필요하게 됩니다.
*   **성능 저하 사례**: 
    *   **간접 호출 오버헤드**: 과도한 추상화 계층(Proxy, Wrapper, Adapter 등)을 거치면서 함수 호출 스택이 깊어지고, 이는 CPU 캐시 효율 저하 및 런타임 오버헤드로 이어질 수 있습니다.
    *   **네트워크 홉(Hop) 증가**: MSA에서 결합도를 낮추기 위해 서비스를 너무 세밀하게 쪼개면, 하나의 요청을 처리하기 위해 수많은 네트워크 통신이 발생하여 응답 속도가 급격히 느려지는 현상이 발생합니다.

## 변경 전파 분석 (Change Propagation Analysis)

정적 분석 지표 외에, 실제 코드 변경 시 수정되는 범위의 상관관계를 통해 결합도를 측정하는 방법입니다.

### 변경 전파 지수 (Propagation Cost)
특정 모듈 $M_i$를 수정했을 때, 그 영향으로 인해 함께 수정되어야 하는 모듈들의 비율을 측정합니다.

$$ \text{Propagation Cost} = \frac{\sum_{i=1}^{n} \text{Affected Modules}(M_i)}{n^2} $$

*   $n$: 시스템 내 전체 모듈의 수
*   $\text{Affected Modules}(M_i)$: 모듈 $M_i$ 변경 시 영향을 받는 모듈의 수 (자기 자신 포함)

이 수치가 높을수록 시스템의 전반적인 결합도가 높으며, 작은 변경이 시스템 전체로 퍼지는 '리플 이펙트'가 강하게 나타나고 있음을 의미합니다. 실무에서는 Git 커밋 로그를 분석하여 **"함께 수정되는 파일들의 빈도(Co-change frequency)"**를 측정함으로써 잠재적인 강결합 지점을 찾아낼 수 있습니다.

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

위키너와나

결합도