195. 결합도 (Coupling) - 모듈 간 상호 의존 정도

핵심 인사이트: 수술실에서 의사와 간호사는 환자의 '상태(데이터)'만 주고받아야 수술이 빠르다. 의사가 간호사의 뇌 속 깊은 기억(내부 로직)까지 간섭하려 들면 수술실은 마비된다. 모듈끼리도 엮인 끈이 적고 오직 데이터만 주고받아야(Low Coupling) 나중에 수정하기가 쉽다.

Ⅰ. 결합도(Coupling)의 개념

소프트웨어 공학에서 어떤 모듈이 다른 모듈에 의존하는 정도(연관성), 혹은 모듈 간에 데이터를 주고받는 끈끈함의 정도를 의미합니다. 응집도(Cohesion)가 모듈 '내부'의 똘똘 뭉친 정도라면, 결합도는 모듈 '외부(모듈과 모듈 사이)'의 연결 고리를 나타냅니다.

Ⅱ. 결합도의 절대 원칙: 낮을수록 좋다 (Low Coupling)

모듈 A와 모듈 B의 결합도가 너무 높으면, A 코드를 한 줄 고쳤는데 전혀 상관없는 B 모듈에서 에러가 터지는 대참사(사이드 이펙트) 가 발생합니다. 반대로 결합도가 낮으면(느슨하면), B 모듈을 통째로 덜어내고 다른 모듈로 교체하더라도 A 모듈은 자신이 하던 일을 아무런 영향 없이 계속할 수 있습니다. 이것이 객체지향 설계의 핵심인 '유연성(Flexibility)'입니다.

Ⅲ. 결합도의 5단계 (나쁜 것 ➔ 좋은 것 순서)

정보처리기사 단골 문제이며, 응집도와 마찬가지로 순서를 외우는 것이 중요합니다. (나쁨) 내-공-제-스-자 (좋음)

1. 내용 (Content) 결합도 - [최악 💩]
   • 모듈 A가 모듈 B의 내부 변수나 코드를 직접 가져다 쓰거나 수정하는 상태입니다. B가 변수를 바꾸면 A도 무조건 죽습니다. (예: goto 문으로 다른 모듈 내부로 침투)
2. 공통 (Common) 결합도
   • 두 모듈이 외부에 있는 글로벌(전역) 변수를 공유하여 사용하는 상태입니다. 전역 변수의 값이 바뀌면 이 변수를 쓰는 수백 개의 모듈이 동시에 영향을 받습니다.
3. 제어 (Control) 결합도
   • 모듈 A가 모듈 B에게 단순히 데이터를 넘기는 게 아니라, "너 이쪽 분기 타라"고 제어 신호(Flag, Boolean 등)를 보내어 B의 내부 로직 흐름을 직접 통제하는 상태입니다. (B의 자율성이 침해됨)
4. 스탬프 (Stamp / 검인) 결합도
   • 모듈 간에 데이터를 주고받을 때 배열이나 객체(Object), 데이터 구조체(Record) 등 복잡한 포장지 통째로 넘기는 상태입니다. 실제로는 그 객체 안의 변수 1개만 필요한데 구조체 전체를 의존하게 되는 부작용이 있습니다.
5. 자료 (Data) 결합도 - [최고 🌟]
   • 모듈끼리 오직 꼭 필요한 단순 데이터(파라미터, 숫자, 문자열)만 매개변수로 주고받는 가장 느슨하고 완벽한 상태입니다. B 모듈이 내부적으로 어떻게 돌아가든 A는 파라미터만 넘겨주면 그만입니다.

Ⅳ. 결합도를 낮추는 설계 원칙 (의존성 주입, DI)

현대 소프트웨어에서는 제어 결합도나 내용 결합도를 끊어내기 위해 인터페이스(Interface) 를 두고 통신하거나, Spring 프레임워크처럼 외부에서 모듈을 끼워 넣어주는 의존성 주입(Dependency Injection, DI) 기법을 사용하여 결합도를 강제로 낮춥니다.

📢 섹션 요약 비유: 회사 동료에게 일을 시킬 때, 그 직원의 다이어리(내부 변수)를 내가 맘대로 훔쳐보고 고치면 내용 결합도(최악)입니다. 대신 깔끔한 회사 양식(인터페이스)에 '이름'과 '금액'(자료 결합도)만 딱 적어서 넘겨주고 그 직원이 알아서 일하게 냅두는 것이 최고의 업무 효율(최저 결합도)을 냅니다.