Files
2nd/10_Wiki/Topics/DevOps_and_Security/응집도와 결합도 (Cohesion and Coupling).md
T
2026-05-10 22:08:15 +09:00

168 lines
5.4 KiB
Markdown

---
id: wiki-2026-0508-응집도와-결합도-cohesion-and-coupling
title: 응집도와 결합도 (Cohesion and Coupling)
category: 10_Wiki/Topics
status: verified
canonical_id: self
aliases: [Cohesion and Coupling, 응집도와 결합도, High Cohesion Low Coupling]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [software-design, modularity, architecture, fundamentals]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
language: any
framework: any
---
# 응집도와 결합도 (Cohesion and Coupling)
## 매 한 줄
> **"매 high cohesion, low coupling"**. 1974년 Larry Constantine 의 structured design 으로 도입된 매 module quality metric 의 두 axis — module 내부 element 의 relatedness (cohesion) 와 module 간 dependency strength (coupling). 매 2026 microservice / domain-driven design 의 기본 vocabulary.
## 매 핵심
### 매 Cohesion (응집도) — 매 within
- 매 single module element 가 매 single purpose 를 향하는 정도.
- 매 Higher = better. 매 module 의 reason to change 의 한 가지로 수렴.
- 매 SRP (Single Responsibility Principle) 의 quantitative cousin.
### 매 Coupling (결합도) — 매 between
- 매 두 module 간 dependency strength.
- 매 Lower = better. 매 한 module 의 변경 의 다른 module 의 영향 의 최소화.
- 매 inter-module knowledge 의 minimization.
### 매 Cohesion 의 7 levels (low → high)
1. **Coincidental** — 매 unrelated, grouped randomly.
2. **Logical** — 매 same category 만 (e.g., all I/O).
3. **Temporal** — 매 same time 의 execution (e.g., init).
4. **Procedural** — 매 same control flow.
5. **Communicational** — 매 same data 의 작업.
6. **Sequential** — 매 output → next input.
7. **Functional** — 매 single well-defined task. **매 best**.
### 매 Coupling 의 6 levels (high → low)
1. **Content** — 매 internal 의 직접 access. **매 worst**.
2. **Common** — 매 global state 공유.
3. **External** — 매 external format 공유.
4. **Control** — 매 flag 로 behavior 제어.
5. **Stamp** — 매 struct 전체 전달 (subset 만 사용).
6. **Data** — 매 primitive parameter 만. **매 best**.
## 💻 패턴
### 매 Functional Cohesion 예
```python
# 매 Good — single purpose
class OrderTotalCalculator:
def calculate(self, items: list[OrderItem]) -> Money:
subtotal = sum(item.price * item.qty for item in items)
tax = subtotal * Decimal("0.10")
return Money(subtotal + tax, "USD")
```
### 매 Coincidental Cohesion (anti)
```python
# 매 Bad — utility kitchen sink
class Helpers:
def format_date(self, d): ...
def hash_password(self, pw): ...
def parse_json(self, s): ...
def send_email(self, to): ...
```
### 매 Data Coupling (best)
```python
# 매 Good — primitive params
def discount(price: Decimal, rate: Decimal) -> Decimal:
return price * (1 - rate)
```
### 매 Content Coupling (worst)
```python
# 매 Bad — reaching into internals
class A:
def __init__(self):
self._cache = {}
class B:
def use(self, a: A):
a._cache["secret"] = 1 # 매 violation
```
### 매 Stamp → Data 의 refactor
```python
# Before: stamp coupling
def ship(order: Order): # 매 Order 전체 의존
address = order.customer.address
...
# After: data coupling
def ship(address: Address):
...
```
### 매 Control Coupling 의 split
```python
# Before
def process(data, mode):
if mode == "A": ...
elif mode == "B": ...
# After
def process_a(data): ...
def process_b(data): ...
```
### 매 Microservice boundary 의 cohesion
```yaml
# 매 Bounded context 별 service
services:
order-service: # 매 functional cohesion
responsibility: order lifecycle
payment-service:
responsibility: payment processing
shipping-service:
responsibility: fulfillment
```
## 매 결정 기준
| 상황 | Approach |
|---|---|
| 매 module 의 reason to change 의 multiple | 매 Split — cohesion 향상 |
| 매 cross-module call 의 빈번 | 매 Merge or 의 facade — coupling 감소 |
| 매 global state 의존 | 매 Inject as dependency |
| 매 flag parameter | 매 Polymorphism / strategy 로 split |
| 매 internal field 의 access | 매 Encapsulation — getter/method |
**기본값**: 매 high cohesion (functional) + 매 low coupling (data) 의 추구.
## 🔗 Graph
- 부모: [[소프트웨어 설계 원칙]] · [[Structured Design]]
- 변형: [[응집도 (Cohesion)]] · [[Connascence]]
- 응용: [[SOLID]] · [[Domain-Driven Design]] · [[Microservices]]
- Adjacent: [[모듈성]] · [[Bounded Context]]
## 🤖 LLM 활용
**언제**: 매 module / class / service boundary 결정 시. 매 refactoring trigger 의 식별.
**언제 X**: 매 single-file script. 매 prototype throwaway code.
## ❌ 안티패턴
- **God class**: 매 모든 의 처리 → 매 low cohesion.
- **Shotgun surgery**: 매 한 변경 의 N module 의 touch → 매 high coupling.
- **Feature envy**: 매 method 의 다른 class 의 data 의 과다 access.
- **Inappropriate intimacy**: 매 두 class 의 internals 의 share.
## 🧪 검증 / 중복
- Verified — Constantine & Yourdon, *Structured Design* (1979); Meilir Page-Jones, *Practical Guide to Structured Systems Design*.
- 신뢰도 A.
## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — cohesion/coupling levels + refactor patterns |