🧬 응집력(Cohesion)
응집력이란 하나의 모듈을 구성하는 내부 요소들이 얼마나 밀접하게 관련되어 있는지를 나타내는 척도입니다.
응집력이 높을수록, 모듈의 목적이 명확하고, 하나의 책임에 집중된 설계가 이루어졌다고 볼 수 있습니다.
📈 응집력의 종류 (좋은 → 나쁜)
기능 응집 > 순차 응집 > 교환 응집 > 절차 응집 > 시간 응집 > 논리 응집 > 우연 응집
🟢 기능 응집 (Functional Cohesion) – 가장 높은 응집력
모듈의 모든 요소가 하나의 명확한 기능 수행만을 위해 구성된 경우입니다.
모듈의 책임이 명확하고 단일하며, 변경이 발생해도 해당 기능에만 집중할 수 있어 유지보수에 매우 유리합니다.
💡 예시
- 코사인 값을 계산하는 수학 함수
- 승객 좌석 배정 기능
- 이메일을 전송하는 서비스 모듈
🟢 순차 응집 (Sequential Cohesion)
모듈 내 요소들이 일련의 처리 과정으로 연결되어 있으며,
한 작업의 결과가 다음 작업의 입력이 되는 구조입니다.
💡 예시
- 사용자 입력을 받아 파싱 → DB에 저장
- 데이터를 정렬하고 → 출력
⚠️ 단, 이 흐름 안의 개별 요소들이 각각 별개 책임을 가진다면 기능 응집으로 보긴 어렵습니다.
🟡 교환 응집 (Communicational Cohesion)
모듈의 구성 요소들이 공통된 입력 또는 출력을 공유하는 경우입니다.
데이터는 같지만 처리 목적이 다를 수도 있어 응집력이 다소 낮습니다.
💡 예시
- 하나의 고객 정보로 이메일 발송, 포인트 적립, 통계 업데이트를 모두 처리하는 모듈
🟠 절차 응집 (Procedural Cohesion)
모듈 내 요소들이 일정한 실행 순서를 따르지만, 기능적으로는 서로 관련 없는 작업을 수행합니다.
💡 예시
- 사용자를 등록하고, 그 직후 통계를 초기화하는 함수
(등록과 통계는 무관한 작업)
🟠 시간 응집 (Temporal Cohesion)
모듈의 구성 요소들이 특정 시점에서 동시에 수행되기 때문에 묶인 경우입니다.
작업 간의 기능적 연관은 없고, 시점만 공유합니다.
💡 예시
- 프로그램 시작 시: 변수 초기화, 로그 파일 오픈, 리소스 로드
- 앱 종료 시: 로그 기록, 리소스 해제, 연결 종료
🔴 논리 응집 (Logical Cohesion)
유사한 범주의 작업을 하나의 모듈에서 처리하지만,
어떤 작업을 수행할지는 외부 조건(flag 등)에 따라 결정되는 경우입니다.
중복을 줄이려다 오히려 혼란과 의존성을 증가시킬 수 있습니다.
💡 예시
process(flag)함수가 flag에 따라 이메일을 보내거나, 문서를 저장하거나, 로그를 찍는 경우
🔴 우연 응집 (Coincidental Cohesion) – 가장 낮은 응집력
모듈 구성 요소들이 아무 연관 없이 우연히 하나로 묶인 경우입니다.
유지보수성과 재사용성이 최악이며, 반드시 리팩토링이 필요한 구조입니다.
💡 예시
- 로그 초기화 + 사용자 저장 + 통계 출력 기능이 하나의 모듈에 들어 있는 경우
✅ 결론
- 응집력은 높을수록 좋고, 결합력은 낮을수록 좋습니다.
- 높은 응집력은 단일 책임 원칙(SRP)을 충족하며, 테스트/변경/확장에 유리합니다.
- 설계 시 모듈은 하나의 책임, 하나의 기능에 집중되도록 구성하는 것이 중요합니다.
작은 문제를 하나하나 해결하며, 누군가의 하루에 선물이 되는 코드를 작성해 갑니다.