핵심 인사이트 (3줄 요약)
- 응집도는 하나의 모듈 내부 요소들이 하나의 목적을 위해 얼마나 단단히 모여 있는지를 보여 주는 품질 지표다.
- 높은 응집도는 읽기 쉬운 책임 경계, 쉬운 테스트, 안정적인 변경 범위를 만든다.
- 기능적 응집도에 가까울수록 SRP와 모듈화가 자연스럽게 실현되고, 갓 클래스 위험은 줄어든다.
Ⅰ. 개요 및 필요성
응집도는 "이 클래스가 왜 존재하는가"에 대한 답을 얼마나 선명하게 해 주는지를 측정한다. 하나의 모듈에 계산, 저장, 출력, 인증, 통계 같은 이질적 책임이 섞이면 수정 이유가 많아지고 장애 분석이 어려워진다. 그래서 아키텍처 설계에서는 모듈 내부의 책임 집중도를 먼저 높여야 전체 구조도 건강해진다.
┌───────────────────────┐ ┌───────────────────────┐
│ 낮은 응집도 │ │ 높은 응집도 │
├───────────────────────┤ ├───────────────────────┤
│ 주문 계산 │ │ 주문 금액 계산 │
│ 이메일 발송 │ │ 할인 적용 │
│ 로그 파일 삭제 │ │ 가격 검증 │
│ 사용자 권한 확인 │ │ 세 항목이 한 목적 공유 │
└───────────────────────┘ └───────────────────────┘
높은 응집도는 단순히 "짧은 클래스"를 의미하지 않는다. 관련된 데이터와 행위가 한곳에 모여 있고, 그 모듈의 존재 이유가 하나로 설명될 수 있는 상태를 뜻한다.
- 📢 섹션 요약 비유: 필통 안에 연필과 지우개가 있는 건 자연스럽지만, 숟가락과 양말까지 들어 있으면 무엇을 위한 통인지 헷갈립니다.
Ⅱ. 아키텍처 및 핵심 원리
응집도는 모듈 분해의 기준이 된다. 관련된 데이터와 메서드를 함께 두고, 관련 없는 책임은 밖으로 밀어낼수록 기능적 응집도에 가까워진다.
┌──────────────┐ 분리 ┌──────────────┐ ┌──────────────┐
│ God Class │──────────────▶│ PricingSvc │ │ MailSender │
│ 계산/저장/통지│ │ 금액·할인·검증│ │ 발송 책임만 │
└──────────────┘ └──────────────┘ └──────────────┘
| 응집 수준 | 의미 | 설계 판단 |
|---|---|---|
| 기능적 응집도 | 모든 요소가 단 하나의 기능을 위해 협력한다. | 가장 바람직한 상태 |
| 순차적 응집도 | 한 단계의 출력이 다음 단계 입력으로 이어진다. | 파이프라인 성격이 강함 |
| 통신적 응집도 | 같은 데이터 집합을 다루는 기능들이 모인다. | 데이터 중심 묶음 |
| 논리적 응집도 | 비슷해 보이는 기능을 한곳에 모아 둔다. | 분리 후보가 많음 |
| 우연적 응집도 | 관련 없는 기능이 우연히 함께 있다. | 즉시 리팩터링 대상 |
응집도 평가는 메서드들이 같은 필드와 같은 비즈니스 목적을 공유하는지 보면 빠르게 감이 온다. 메서드 대부분이 서로 다른 데이터만 만진다면 이미 책임이 갈라져 있다는 뜻이다.
- 📢 섹션 요약 비유: 같은 반 친구끼리 줄 서면 이동이 빠르지만, 학년이 뒤섞여 서 있으면 출석도 이동도 계속 꼬입니다.
Ⅲ. 비교 및 연결
| 관점 | 높은 응집도 | 낮은 응집도 | 연결 원칙 |
|---|---|---|---|
| 책임 경계 | 존재 이유가 하나로 설명된다. | 수정 이유가 여러 개다. | SRP |
| 재사용성 | 필요한 기능만 독립적으로 가져다 쓸 수 있다. | 불필요한 기능이 함께 딸려온다. | Modularity |
| 테스트성 | 입력과 결과가 명확해 단위 테스트가 쉽다. | 환경 의존과 분기 수가 커져 테스트가 무거워진다. | Testability |
| 결합 관계 | 내부 집중이 높아 외부 의존을 줄이기 쉽다. | 외부에 많은 일을 떠넘기며 결합도가 높아진다. | Loose Coupling |
응집도는 결합도와 동전의 양면이다. 내부가 단단할수록 외부와의 연결점은 줄어들고, 그만큼 시스템 전체도 더 이해하기 쉬워진다.
- 📢 섹션 요약 비유: 서랍마다 용도를 나눠 두면 찾기 쉽고, 아무거나 한 칸에 몰아 넣으면 매번 다 꺼내 봐야 합니다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서는 클래스 이름이 Manager, Common, Util처럼 뭉뚱그려져 있고, 메서드마다 쓰는 필드가 제각각이면 낮은 응집도를 의심해야 한다. 기술사 판단에서는 단순히 클래스 개수보다, 하나의 모듈이 한 가지 변경 이유만 갖는지와 비즈니스 경계가 선명한지를 본다.
서비스 분리, 마이크로서비스 경계 설정, 배치 단계 분해에서도 응집도는 핵심 기준이다. 응집도가 낮은 채로 시스템을 쪼개면 분산만 되고 책임은 여전히 얽혀 운영 난이도만 올라간다.
판단 체크리스트
-
이 모듈의 존재 이유를 한 문장으로 설명할 수 있는가?
-
메서드 대부분이 공통 데이터와 공통 규칙을 공유하고 있는가?
-
클래스명과 메서드명이 한 가지 업무 영역을 가리키고 있는가?
-
관련 없는 입출력, 배치, 통계, 알림 기능이 한 모듈에 섞여 있지 않은가?
-
분리 시 외부 인터페이스가 더 명확해지고 테스트가 쉬워지는가?
-
📢 섹션 요약 비유: 문구점 진열대가 연필 코너, 공책 코너로 나뉘어 있으면 쇼핑이 쉬운데, 전부 한 바구니에 섞여 있으면 매번 뒤적여야 합니다.
Ⅴ. 기대효과 및 결론
응집도를 높이면 모듈 이해 속도가 빨라지고, 변경 영향 범위가 줄며, 단위 테스트와 코드 리뷰 품질이 함께 올라간다. 특히 기능적 응집도에 가까운 구조는 조직 간 책임 분리와 서비스 경계 정의에도 큰 도움을 준다.
결론적으로 응집도는 "깔끔해 보이는 코드"를 넘어 아키텍처 생존성을 좌우하는 척도다. 내부 목적이 분명한 모듈이 많을수록 시스템은 더 작게 이해되고 더 오래 유지된다.
- 📢 섹션 요약 비유: 도시락 반찬이 칸마다 잘 나뉘어 있으면 먹기 편하지만, 전부 한데 섞이면 맛도 찾기 어렵고 정리도 힘듭니다.
📌 관련 개념 맵
- SRP: 하나의 변경 이유만 가지게 하여 응집도를 높인다.
- 모듈화: 관련 기능을 같은 경계 안에 배치한다.
- 갓 클래스 방지: 이질적 책임 집중을 해소한다.
- 결합도 저감: 내부 집중이 높을수록 외부 연결은 단순해진다.
📈 관련 키워드 및 발전 흐름도
기능 혼재와 God Class 증가
│
▼
변경 이유 다중화와 테스트 복잡화
│
▼
응집도 중심 책임 재분해
│
▼
SRP·모듈화·경계 명확화
│
▼
유지보수성과 재사용성 향상
👶 어린이를 위한 3줄 비유 설명
- 필통에는 공부할 때 쓰는 물건만 모여 있어야 찾기 쉬워요.
- 그런데 필통 안에 장난감, 양말, 과자까지 들어 있으면 필요한 걸 빨리 못 찾아요.
- 응집도는 "비슷한 일끼리 잘 모여 있나"를 보는 기준이에요.