docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,166 @@
|
||||
---
|
||||
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
|
||||
- 변형: [[응집도 (Cohesion)]]
|
||||
- 응용: [[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 |
|
||||
Reference in New Issue
Block a user