Files
2nd/10_Wiki/Topics/Domain_Programming/DevOps_and_Security/응집도와 결합도 (Cohesion and Coupling).md
T
Antigravity Agent c24165b8bc refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게
[공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류.
문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인).

- Topic_Programming → Domain_Programming (내부 구조 보존)
- Topic_Graphic → Domain_Design
- Topic_Business → Domain_Product
- Topic_General → Domain_General
- _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning),
  Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing)
- 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서)
- 빈 폴더 정리 (memory/procedures)
- 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-11 11:05:56 +09:00

5.3 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-응집도와-결합도-cohesion-and-coupling 응집도와 결합도 (Cohesion and Coupling) 10_Wiki/Topics verified self
Cohesion and Coupling
응집도와 결합도
High Cohesion Low Coupling
none A 0.9 applied
software-design
modularity
architecture
fundamentals
2026-05-10 pending
language framework
any 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 예

# 매 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)

# 매 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)

# 매 Good — primitive params
def discount(price: Decimal, rate: Decimal) -> Decimal:
    return price * (1 - rate)

매 Content Coupling (worst)

# 매 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

# Before: stamp coupling
def ship(order: Order):  # 매 Order 전체 의존
    address = order.customer.address
    ...

# After: data coupling
def ship(address: Address):
    ...

매 Control Coupling 의 split

# Before
def process(data, mode):
    if mode == "A": ...
    elif mode == "B": ...

# After
def process_a(data): ...
def process_b(data): ...

매 Microservice boundary 의 cohesion

# 매 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

🤖 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