응집도와 결합도, 좋은 설계의 기준
소프트웨어 설계의 품질을 평가하는 가장 근본적인 두 기준이 있다. 응집도(Cohesion)와 결합도(Coupling)이다. 이 두 개념은 1979년 래리 콘스탄틴(Larry Constantine)과 에드워드 요던(Edward Yourdon)이 정립한 구조적 설계 이론의 핵심으로, 오늘날 객체지향 설계와 마이크로서비스 아키텍처에 이르기까지 모든 현대 설계 패러다임의 기반이 되고 있다. 잘 만들어진 모듈은 응집도가 높고 결합도가 낮아야 한다는 원칙은 시대를 초월한 설계 철학으로 자리 잡았다. 정보처리기사 시험에서도 매회 출제되는 단골 주제이며, 실무에서도 코드 리뷰의 가장 기본적인 평가 척도로 활용된다.
응집도란 무엇인가
응집도란 하나의 모듈 내부에 포함된 구성 요소들이 얼마나 서로 밀접하게 관련되어 있는지를 측정하는 척도이다. 다시 말해, 한 모듈이 단일한 목적이나 책임에 얼마나 집중하고 있는가를 평가하는 지표라고 정리할 수 있다. 응집도가 높을수록 해당 모듈은 한 가지 일에만 충실하게 되고, 이는 곧 모듈의 독립성과 재사용성을 향상시키는 결과로 직결된다. 반대로 응집도가 낮은 모듈은 서로 관련 없는 기능들이 뒤섞여 있어 수정 시 예측하지 못한 부작용을 유발할 위험이 크다.
응집도는 일반적으로 일곱 단계로 구분되며, 약한 단계부터 강한 단계로 정리하면 다음과 같다. 가장 낮은 단계인 우연적 응집도(Coincidental Cohesion)는 모듈 내부 요소들 사이에 어떠한 의미 있는 관련성도 없는 경우를 가리킨다. 그 다음 논리적 응집도(Logical Cohesion)는 비슷한 종류의 기능들이 한 모듈에 묶여 있지만 호출 시점에 따라 매개변수로 어떤 기능이 수행될지 결정되는 형태이다. 시간적 응집도(Temporal Cohesion)는 특정 시점에 함께 실행되어야 하는 기능들이 묶인 경우로, 시스템 초기화 루틴이 대표적인 예시이다.
이어지는 절차적 응집도(Procedural Cohesion)는 정해진 순서에 따라 수행되는 기능들이 모인 형태이다. 통신적 응집도(Communicational Cohesion)는 동일한 입력 자료를 사용하거나 동일한 출력 자료를 생성하는 기능들의 집합을 의미한다. 순차적 응집도(Sequential Cohesion)는 한 기능의 출력이 곧바로 다음 기능의 입력으로 연결되는 흐름 구조이다. 가장 이상적인 형태인 기능적 응집도(Functional Cohesion)는 모듈 내 모든 요소가 단 하나의 명확한 기능 수행에만 기여하는 상태를 말한다. 설계자는 항상 기능적 응집도에 가깝게 모듈을 구성하는 것을 목표로 삼아야 하며, 이것이 모듈성의 가장 높은 수준이다.
결합도의 종류와 특징
결합도란 서로 다른 모듈들 사이에 존재하는 상호 의존성의 정도를 측정하는 지표이다. 결합도가 높다는 것은 한 모듈을 변경했을 때 그 변경이 다른 모듈에까지 파급될 가능성이 크다는 것을 의미한다. 따라서 결합도는 가능한 한 낮게 유지하는 것이 바람직하며, 이는 모듈의 독립성과 시스템 전체의 유지보수성을 결정짓는 핵심 요인이 된다. 결합도가 높은 시스템은 작은 변경에도 광범위한 회귀 테스트가 필요하고, 시간이 흐를수록 변경 비용이 기하급수적으로 증가하는 경향을 보인다.
결합도는 일반적으로 여섯 단계로 분류된다. 가장 결합도가 낮고 이상적인 형태인 자료 결합도(Data Coupling)는 모듈 간에 단순한 매개변수만 주고받는 경우이다. 다음 단계인 스탬프 결합도(Stamp Coupling)는 자료구조 전체를 매개변수로 전달하면서 그중 일부 필드만 사용하는 형태로, 불필요한 데이터까지 노출되는 단점이 있다. 제어 결합도(Control Coupling)는 한 모듈이 다른 모듈의 내부 흐름을 제어하기 위한 플래그나 신호를 매개변수로 전달하는 경우이다. 이 경우 호출하는 측이 호출되는 측의 내부 동작을 알아야 하므로 캡슐화가 약화된다.
외부 결합도(External Coupling)는 외부 환경이나 외부 인터페이스, 통신 프로토콜을 공유할 때 발생한다. 공통 결합도(Common Coupling)는 여러 모듈이 전역 변수와 같은 공통 데이터 영역을 함께 사용할 때 발생하며, 한 모듈에서의 변경이 그 영역을 참조하는 모든 모듈에 파급 효과를 미칠 위험을 안고 있다. 가장 결합도가 높고 절대적으로 피해야 할 형태인 내용 결합도(Content Coupling)는 한 모듈이 다른 모듈의 내부 구조나 데이터를 직접 참조하거나 수정하는 경우를 가리킨다. 이러한 결합은 캡슐화 원칙을 정면으로 위반하며, 코드의 유지보수를 매우 어렵게 만들고 버그의 온상이 되는 주범이다.
좋은 설계로 이어지는 실전 적용법
응집도와 결합도의 이론을 실무에 적용하기 위해서는 구체적인 설계 원칙으로 변환해야 한다. 첫째, 단일 책임 원칙(Single Responsibility Principle)을 준수하는 것이 가장 직접적인 실천 방법이다. 한 클래스나 모듈은 오직 하나의 변경 이유만을 가져야 하며, 이는 곧 기능적 응집도를 달성하는 길이 된다. 클래스를 설계할 때 "이 클래스가 무엇을 하는가"라는 질문에 한 문장으로 답할 수 없다면, 책임이 분리되지 않았다는 강력한 신호로 받아들여야 한다.
둘째, 모듈 간 통신은 명확하게 정의된 인터페이스를 통해서만 이루어져야 한다. 전역 변수나 공유 상태를 통한 데이터 교환은 공통 결합도를 유발하므로 가급적 회피해야 한다. 매개변수를 전달할 때도 필요한 데이터만 정확히 명시해 자료 결합도 수준을 유지해야 하며, 자료구조 전체를 무분별하게 넘기는 스탬프 결합도는 지양하는 것이 좋다. 또한 다른 모듈의 내부 필드를 직접 참조하거나 수정하는 행위는 내용 결합도를 야기하므로 절대 허용해서는 안 된다.
셋째, 의존성 주입(Dependency Injection)과 인터페이스 분리 같은 기법을 적극적으로 활용해야 결합도를 낮출 수 있다. 구체적인 구현체에 직접 의존하는 대신 추상화된 인터페이스에 의존하도록 설계하면, 구현체가 변경되더라도 사용 측 코드를 수정할 필요가 없어진다. 이는 객체지향 설계 원칙 중 의존 역전 원칙(Dependency Inversion Principle)의 핵심 사상이기도 하며, 스프링 프레임워크와 같은 현대적인 도구들이 기본 철학으로 채택하고 있다.
넷째, 정기적인 코드 리뷰와 리팩토링을 통해 응집도와 결합도를 지속적으로 점검해야 한다. 한 메서드의 길이가 비정상적으로 길거나, 한 클래스가 지나치게 많은 다른 클래스를 임포트하고 있다면 이는 응집도 저하와 결합도 상승의 명백한 신호로 해석해야 한다. 이러한 신호를 조기에 발견하고 모듈을 분리하거나 책임을 재배치하는 작업이 누적되면, 시스템 전체의 설계 품질은 시간이 지남에 따라 지속적으로 향상되는 선순환 구조를 만들어낼 수 있다. 결국 좋은 설계란 단번에 완성되는 것이 아니라, 응집도와 결합도라는 두 나침반을 따라 끊임없이 다듬어가는 과정이라는 점을 기억해야 한다.
메타 디스크립션: 소프트웨어 설계의 핵심 평가 기준인 응집도(7단계)와 결합도(6단계)의 정의, 분류, 실전 적용법을 정보처리기사 출제 기준에 맞춰 정리합니다.