[응집도] 응집도의 종류와 예제 한눈에 보기
응집도(Cohesion)
응집도(Cohesion)는 소프트웨어 설계에서 모듈이 하나의 작업에 집중하는 정도를 나타내는 중요한 개념입니다. 간단히 말하면, 하나의 모듈이 얼마나 "관련 있는 기능들"만 포함하고 있느냐를 측정하는 지표입니다. 응집도가 높을수록 모듈의 책임이 명확하고 변경에 강하며, 유지보수가 쉬운 구조가 됩니다. 반대로 응집도가 낮은 모듈은 다양한 목적의 기능이 섞여 있어 코드가 복잡하고 버그가 발생하기 쉬워집니다.
소프트웨어 공학에서는 응집도를 일곱 단계로 분류하며, 낮은 응집도에서 높은 응집도로 갈수록 더 좋은 설계로 간주됩니다. 각 단계는 모듈의 목적 일관성에 따라 구분되며, 이를 이해하면 더 나은 모듈 설계를 할 수 있습니다.
이 글에서는 응집도의 정의와 함께 일곱 가지 종류를 상세히 설명하고, 좋은 응집도를 가진 예시와 그렇지 않은 예시를 비교하여 이해를 돕습니다.
1. 응집도(Cohesion)란?
응집도는 모듈 내부 구성 요소 간의 기능적 관련성을 의미합니다. 즉, 하나의 모듈이 얼마나 하나의 목적을 중심으로 구성되어 있는가를 판단하는 기준입니다.
- 높은 응집도(High Cohesion) : 모듈이 하나의 책임 또는 기능에 집중되어 있습니다.
- 낮은 응집도(Low Cohesion) : 모듈에 여러 가지 책임이나 기능이 뒤섞여 있습니다.
좋은 소프트웨어는 가능한 한 높은 응집도를 유지하는 것이 바람직하며, SOLID 원칙의 단일 책임 원칙(SRP)과도 깊은 연관이 있습니다.
2. 응집도의 종류 (7단계)
응집도는 일반적으로 다음과 같이 낮은 단계에서 높은 단계까지 총 7단계로 분류됩니다.
| 응집도 종류 | 설명 | 예시 | 응집도 수준 |
| 1. 우연적 응집 (Coincidental Cohesion) |
관련 없는 작업이 모여 있는 상태 | 다양한 유틸 함수가 뒤섞인 모듈 | 가장 낮음 |
| 2. 논리적 응집 (Logical Cohesion) |
유사한 분류의 작업을 하나의 모듈에서 조건문으로 선택 수행 |
파일 입출력 작업을 조건에 따라 처리 | 낮음 |
| 3. 시간적 응집 (Temporal Cohesion) |
특정 시점에 같이 실행되는 작업이 모임 | 프로그램 시작 시 초기화 작업 묶음 | 낮음 |
| 4. 절차적 응집 (Procedural Cohesion) |
절차적으로 순서가 있는 작업이 모임 | 회원 가입 → 이메일 발송 → 로그 기록 | 중간 |
| 5. 통신적 응집 (Communicational Cohesion) |
동일한 데이터를 사용하는 작업이 모임 | 같은 DB 테이블을 조회하고 가공 | 중간 이상 |
| 6. 순차적 응집 (Sequential Cohesion) |
한 작업의 출력이 다음 작업의 입력이 됨 | 데이터 파싱 → 필터링 → 저장 | 높음 |
| 7. 기능적 응집 (Functional Cohesion) |
하나의 잘 정의된 기능을 수행 | 사용자 인증 기능 모듈 | 가장 높음 |
3. 각 응집도의 예시와 분석
a. 우연적 응집 (Coincidental)
def do_stuff():
clean_temp_files()
send_email()
generate_report()- 관련 없는 기능들이 하나의 함수에 모여 있음 → 유지보수 어려움
b. 논리적 응집 (Logical)
def handle_input(type, data):
if type == "keyboard":
handle_keyboard(data)
elif type == "mouse":
handle_mouse(data)- 입력 처리라는 공통점은 있지만 실제 작업은 서로 무관함 → 조건문이 많아짐
c. 시간적 응집 (Temporal)
def init_app():
load_config()
init_logger()
connect_to_db()- 모두 앱 시작 시 실행되지만 기능상 직접적 연관은 없음 → 변경이 전이됨
d. 절차적 응집 (Procedural)
def user_registration_flow():
validate_input()
save_user()
send_welcome_email()- 순서상 유기적이지만 각 작업은 서로 독립적 → 절차는 있지만 데이터 공유는 적음
e. 통신적 응집 (Communicational)
def process_customer_data(customer_id):
data = fetch_data(customer_id)
summary = analyze_data(data)
log_summary(summary)- 동일한 데이터를 중심으로 구성됨 → 목적이 꽤 밀접함
f. 순차적 응집 (Sequential)
def process_data_pipeline(raw_data):
cleaned = clean_data(raw_data)
transformed = transform_data(cleaned)
store(transformed)- 각 단계가 이전 단계 결과에 의존 → 강한 연속성과 목적 일관성
g. 기능적 응집 (Functional)
def authenticate_user(credentials):
user = find_user(credentials.username)
if verify_password(user, credentials.password):
return generate_token(user)
else:
raise AuthenticationError()- 명확하게 하나의 기능을 수행 → 유지보수 및 테스트 용이
4. 좋은 응집도를 위한 설계 팁
- 함수나 클래스가 하나의 책임만 가지도록 설계한다.
- SRP(단일 책임 원칙)를 지켜서 하나의 변경 이유만 가지게 한다.
- 이름만 보고 해당 모듈의 역할이 떠오르게 구성한다.
- 관련 없는 로직은 별도의 모듈로 분리하여 응집도를 높인다.
5. 마무리
응집도는 모듈 내부 요소들이 얼마나 밀접하게 관련되어 있는지를 판단하는 기준으로, 높은 응집도는 좋은 소프트웨어 구조의 핵심입니다. 응집도는 우연적 → 기능적 응집으로 갈수록 좋으며, 각 응집도의 특성을 이해하고 설계에 반영하는 것이 중요합니다. 특히 기능적 응집은 유지보수성과 확장성이 뛰어나기 때문에 지향해야 할 이상적인 구조입니다. 이를 위해 단일 책임 원칙을 지키고, 모듈을 명확하게 역할 중심으로 나누는 습관이 중요합니다.