Files
2nd/10_Wiki/Topics/Architecture/High-Cohesion-Low-Coupling.md
T

4.0 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit inferred_by tech_stack
wiki-2026-0508-high-cohesion-low-coupling High Cohesion Low Coupling 10_Wiki/Topics needs_review self
P-Reinforce-AUTO-HCLC-001
none A 0.98
auto-reinforced
software-craftsmanship
Modularity
Architecture
cohesion
coupling
design-patterns
2026-04-20 pending Claude Opus 4.7 (auto-normalize 2026-05-08)
language framework
unspecified unspecified

High-Cohesion-Low-Coupling

📌 한 줄 통찰 (The Karpathy Summary)

"단단한 블록, 느슨한 연결: 하나의 모듈은 오직 하나의 목적에만 집중하여 내부를 꽉 채우고(Cohesion), 다른 모듈과는 최소한의 접점만 유지하여(Coupling) 하나가 고장 나도 전체가 무너지지 않게 만드는 설계의 성배."

📖 구조화된 지식 (Synthesized Content)

고응집 저결합(High-Cohesion-Low-Coupling)은 소프트웨어 설계의 품질을 결정하는 가장 고전적이면서 강력한 원칙입니다.

  1. High Cohesion (고응집):
    • 모듈 내부의 요소들이 하나의 책임(Single Responsibility)을 위해 얼마나 밀접하게 협력하는가. (DDD-Type-Safety와 연결)
    • 장점: 가독성 향상, 재사용성 증가.
  2. Low Coupling (저결합):
    • 서로 다른 모듈 간의 의존성 강도.
    • 장점: 한 곳의 변경 정책이 다른 곳에 미치는 영향 정책 최소화 (Side-effect 방지). (Reliability와 연결)
  3. 왜 중요한가?:
    • 복잡한 시스템 정책의 유지보수 비용 정책을 결정하며, 대규모 팀 협업 시 코드 충돌 정책을 방지하는 구조적 방패이기 때문임. (Modularity와 연결)

⚠️ 모순 및 업데이트 (Contradictions & Updates)

  • 과거 데이터와의 충돌: 과거에는 모든 기능을 한 곳에 모으는 'Monolithic' 정책이 성능 면에서 우수하다고 믿었으나, 현대 정책은 코드베이스가 커짐에 따라 발생하는 'Dirty code 정책'의 비용 정책이 훨씬 커짐을 인지하고 마이크로서비스(MSA) 정책처럼 극단적인 저결합 정책을 지향함(RL Update).
  • 정책 변화(RL Update): 이제는 단순 코드 설계 정책을 넘어, 조직 구조 정책까지도 소프트웨어 아키텍처 정책과 일치시켜야 한다는 'Conway's Law'를 기반으로 팀 빌딩 정책에도 이 원칙 정책이 적용됨.

🔗 지식 연결 (Graph)


🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

  • (TODO)

언제 쓰면 안 되는가:

  • (TODO)

🧪 검증 상태 (Validation)

  • 정보 상태: needs_review
  • 출처 신뢰도: A
  • 검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

  • 기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
  • 처리 방식: UPDATE (자동 정규화)
  • 처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🕓 변경 이력 (Changelog)

날짜 변경 내용 처리 방식 신뢰도
2026-05-08 P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) UPDATE A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

  • (TODO)

선택 B를 써야 할 때:

  • (TODO)

기본값:

(TODO)

안티패턴 (Anti-Patterns)

  • [안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)