193. 응집도 (Cohesion) - 모듈 내부 요소들의 연관 정도

핵심 인사이트: 훌륭한 모듈은 '만능칼(맥가이버칼)'이 아니라 '수술용 메스'여야 한다. 하나의 모듈(클래스/함수) 안에 있는 기능들이 오직 '하나의 목적'만을 위해 얼마나 똘똘 뭉쳐 있는지를 나타내는 척도가 응집도다. 응집도는 무조건 "높을수록 좋다(High Cohesion)".

Ⅰ. 응집도(Cohesion)의 개념

소프트웨어 설계에서 하나의 모듈 내부에 존재하는 명령어, 데이터, 함수들이 서로 얼마나 밀접하게 연관되어 있는지를 나타내는 응집의 정도입니다. 객체지향 설계 원칙(SOLID)의 '단일 책임 원칙(SRP, Single Responsibility Principle)' 과 완벽하게 결을 같이 하는 개념입니다.

Ⅱ. 높은 응집도의 장점

응집도가 높은 모듈은 딱 한 가지 일만 잘하는 모듈입니다.

재사용성 향상: 결제 모듈이 딱 '결제 로직'만 들고 있으면 다른 쇼핑몰 프로젝트에 그대로 복사해서 쓸 수 있습니다.
유지보수 용이: 결제에 에러가 나면 무조건 '결제 모듈' 하나만 열어보면 되므로 버그 추적이 매우 쉽습니다.

Ⅲ. 나쁜 응집도 (낮은 응집도)의 문제점

응집도가 낮은 모듈은 '로그인'도 하고, '이메일'도 보내고, '주문'도 처리하는 만물상 같은 모듈입니다.

이메일 로직을 고쳤는데, 같은 모듈 안에 있는 주문 로직이 에러를 뿜는 치명적인 사이드 이펙트(Spaghetti Code)가 발생합니다.

Ⅳ. 응집도의 7단계 (나쁜 것 ➔ 좋은 것 순서)

정보처리기사 시험에 단골로 출제되는 스티븐스(Stevens)의 7단계입니다. 위로 갈수록 나쁘고, 밑으로 내려갈수록 훌륭한 설계입니다.

우연적 (Coincidental) 응집도 - [최악 💩]
- 아무런 관계도 없는 함수들을 그냥 귀찮아서 파일 하나에 몽땅 다 때려 넣은 상태입니다. (예: Utils.java 안에 로그찍기, 결제하기, 날짜계산이 다 섞여 있음)
논리적 (Logical) 응집도
- 유사한 성격의 기능들을 논리적으로 묶어둔 상태입니다. (예: 육로 배송, 해상 배송, 항공 배송 함수를 하나로 묶고 if문으로 분기)
시간적 (Temporal) 응집도
- 연관성은 없지만, 단순히 같은 시간에 실행되어야 한다는 이유로 묶인 상태입니다. (예: 시스템_시작() 함수 안에 DB 초기화, 로그 설정, 캐시 정리가 다 섞임)
절차적 (Procedural) 응집도
- 함수들이 실행되는 '순서'가 있어서 묶어놓은 상태입니다.
통신적 (Communicational) 응집도
- 동일한 입력 데이터나 출력 데이터를 다루는 기능들을 묶은 상태입니다. (예: 게시글 데이터를 가지고 '게시글 저장', '게시글 수정' 함수가 묶임)
순차적 (Sequential) 응집도
- 앞 함수의 출력 결과가 바로 다음 함수의 입력 데이터로 물고 들어가는 상태입니다.
기능적 (Functional) 응집도 - [최고 🌟]
- 모듈 내부의 모든 요소가 오직 단일한 하나의 목적(기능) 만을 수행하기 위해 완벽하게 뭉친 상태입니다. (예: 카드결제승인() 함수는 오직 카드 결제 로직만 가짐)

📢 섹션 요약 비유: 우연적 응집도(최악)는 양말, 연필, 칫솔을 그냥 귀찮아서 서랍 한 칸에 다 쑤셔 넣은 잡동사니 서랍장이고, 기능적 응집도(최고)는 '겨울용 양말'만 예쁘게 접어서 딱 한 칸에 모아둔 완벽한 정리 정돈입니다.