2nd/10_Wiki/Topics/DevOps_and_Security/결합도 (Coupling).md

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-결합도-coupling	결합도 (Coupling)	10_Wiki/Topics	needs_review	self	P-Reinforce-AUTO-1DFEC5	none	A	0.9	auto-reinforced		2026-04-20	[P-Reinforce] Continuous Worker - 결합도 (Coupling)	Claude Opus 4.7 (auto-normalize 2026-05-08)	language framework unspecified unspecified

결합도 (Coupling)

📌 한 줄 통찰 (The Karpathy Summary)

결합도(Coupling)는 소프트웨어 설계에서 모듈 간의 상호 의존성 정도를 나타내는 척도입니다 [1, 2]. 결합도가 낮다는 것은 모듈 간의 의존성이 적어 각 모듈이 독립적으로 동작할 수 있음을 의미하며, 반대로 결합도가 높으면 하나의 모듈을 변경할 때 다른 모듈에도 연쇄적인 영향을 미치게 됩니다 [2]. 성공적인 소프트웨어 아키텍처를 구현하기 위해서는 시스템의 복잡성을 줄이고 유지보수성을 높일 수 있도록 낮은 결합도를 지향해야 합니다 [2, 3].

📖 구조화된 지식 (Synthesized Content)

• 결합도의 유형 [2] 결합도는 의존성의 수준에 따라 다음과 같이 분류되며, 아래로 갈수록 결합도가 낮아져 이상적인 소프트웨어 설계 형태가 됩니다.

  • 내용 결합(Content Coupling): 한 모듈이 다른 모듈의 내부 내용을 직접 참조하거나 수정하는 가장 강하고 바람직하지 않은 형태입니다.
  • 공통 결합(Common Coupling): 두 개 이상의 모듈이 전역(Global) 데이터를 공유하는 상태로, 데이터의 상태 변화가 모든 관련 모듈에 영향을 미칩니다.
  • 외부 결합(External Coupling): 하드웨어나 운영체제와 같은 특정 외부 시스템이나 인터페이스를 통해 데이터를 공유합니다.
  • 제어 결합(Control Coupling): 한 모듈이 특정 플래그나 상태 값을 전달하여 다른 모듈의 동작 방식이나 제어 흐름을 변경하게 만드는 결합입니다.
  • 스탬프 결합(Stamp Coupling): 두 모듈이 복잡한 데이터 구조체를 공유하지만, 그중 일부의 데이터만 사용하는 형태입니다.
  • 자료 결합(Data Coupling): 모듈 간에 단순한 데이터 값(정수, 문자열 등)만을 전달하는 형태로, 모듈 간 의존성이 최소화되는 가장 낮은 결합도입니다.

• 낮은 결합도의 장점 및 높은 결합도의 문제점 결합도가 낮은 시스템은 한 모듈의 변경이 타 모듈에 미치는 영향이 적어 유지보수와 확장이 쉬워집니다 [4]. 또한 각 모듈이 독립적으로 동작할 수 있어 다른 프로젝트에서의 재사용성이 높아지며, 격리된 환경에서 독립적인 테스트가 가능해집니다 [4]. 반대로 결합도가 높으면 변경 시 예상치 못한 부작용(Side effect)이 발생할 위험이 커지고, 모듈 간의 강한 의존성 때문에 재사용이 어려우며 여러 모듈을 함께 테스트해야 하므로 복잡성이 증가합니다 [4].

• 결합도를 낮추기 위한 주요 전략 [5]

  • 인터페이스 사용: 구체적인 구현 대신 인터페이스를 통해 상호작용을 정의하여 모듈 간의 직접적인 의존성을 제거합니다.
  • 의존성 주입(Dependency Injection): 모듈 내부에서 필요한 다른 모듈을 직접 생성하지 않고 외부에서 제공(주입)받도록 설계합니다.
  • 이벤트 기반 아키텍처: 모듈이 서로 직접 호출하는 대신 이벤트를 발행하고 구독하는 방식으로 간접적인 상호작용을 처리합니다.
  • 캡슐화 및 데이터 구조 단순화: 내부 구현 데이터를 외부에서 접근할 수 없도록 캡슐화하고, 전달하는 데이터 구조를 단순화하여 불필요한 결합을 줄입니다.

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

• 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
• 정책 변화: Programming & Language 분야의 자동 자산화 수행.

🔗 지식 연결 (Graph)

• Related Topics: 응집도 (Cohesion), 관심사의 분리 (Separation of Concerns), 의존성 주입 (Dependency Injection), 단일 책임 원칙 (Single Responsibility Principle)
• Projects/Contexts: 소프트웨어 아키텍처 설계, 마이크로서비스 아키텍처, 이벤트 기반 아키텍처
• Contradictions/Notes: 모듈 간 결합도를 낮추기 위해 관심사를 엄격하게 분리하는 것은 유지보수성을 크게 향상하지만, 추상화 레이어가 지나치게 많아지면 시스템 내 구성요소 간의 상호작용을 파악하기 힘들어지거나 통신 오버헤드가 발생하여 전체적인 시스템의 복잡성이 오히려 증가할 수 있다는 단점도 수반됩니다 [6, 7].

---

Last updated: 2026-04-18

---

🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)