feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/DevOps_and_Security/소비자 주도 계약 테스트 (Consumer-Driven Contract Tests, CDC).md

@@ -1,9 +1,29 @@
+---
+id: wiki-2026-0508-소비자-주도-계약-테스트-consumer-driven-co
+title: "소비자 주도 계약 테스트 (Consumer Driven Contract Tests, CDC)"
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
+tags: [uncategorized]
+raw_sources: []
+last_reinforced: 2026-05-08
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+tech_stack:
+  language: unspecified
+  framework: unspecified
+---
+
 # [[소비자 주도 계약 테스트 (Consumer-Driven Contract Tests, CDC)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 소비자 주도 계약 테스트(CDC)는 마이크로서비스 환경에서 인터페이스를 소비하는 측(Consumer)이 요구사항을 바탕으로 테스트를 작성하여 제공자(Provider)의 API 구현을 주도하는 자동화된 테스트 기법이다 [1]. 소비자가 작성한 테스트 명세를 제공자가 지속적으로 실행함으로써, 인터페이스의 변경으로 인한 시스템의 오류를 조기에 발견할 수 있다 [2]. 이를 통해 조직 내 여러 팀이 런타임 통신 계약을 유지하면서도 자율적이고 빠르게 소프트웨어를 개발할 수 있도록 돕는다 [3, 4].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 * **CDC 테스트의 기본 워크플로우:** 
   1. 소비하는 팀(Consumer)은 자신이 인터페이스로부터 필요로 하는 모든 데이터와 기대사항을 담아 자동화된 테스트를 작성한다 [1, 2].
   2. 작성된 테스트(또는 Pact 파일과 같은 계약 명세)를 제공자 팀이 가져갈 수 있도록 배포(publish)한다 [1, 2, 5].
@@ -18,10 +38,66 @@
   * **불필요한 구현 방지:** 제공하는 팀은 소비자가 작성한 테스트를 통과하는 데 필요한 기능만 정확히 구현하면 되므로, YAGNI(You Aren't Gonna Need It) 원칙을 준수하고 시스템을 단순하게 유지할 수 있다 [2].
   * **독립성과 소통 강화:** 방대하고 무거운 인터페이스 문서를 주고받는 대신, 실행 가능한 테스트를 통해 명확한 소통을 유도한다. 이는 마이크로서비스를 구축하는 자율적인 팀들이 다른 서비스를 망가뜨릴 걱정 없이 빠르게 개발할 수 있게 하는 핵심(Game changer)이 된다 [4, 8].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 * **공개 API(Public API) 적용의 한계:** CDC 테스트는 조직 내부의 마이크로서비스 환경에서 가장 유용하다. 불특정 다수가 사용하는 공개 API의 경우, 제공자 측에서 모든 소비자의 요구사항을 반영한 테스트를 일일이 구동하고 맞춰주는 것이 불가능하므로 이 접근 방식을 적용하기 어렵다 [9].
 * **테스트 공유를 위한 인프라 관리:** 소비자가 생성한 계약 파일(Pact 파일 등)을 제공자에게 전달하려면 추가적인 관리 방법이 필요하다. 버전 관리 시스템에 직접 체크인하거나, Amazon S3, 아티팩트 저장소, 또는 전용 Pact Broker와 같은 인프라를 구축하고 관리하는 수고가 발생한다 [10].
 * **팀 간 소통의 필수성:** 자동화된 테스트가 소통을 돕는 도구이긴 하지만, 테스트가 실패했을 때(예: 불가피한 API 변경 시) 결국 관련된 두 팀이 직접 만나 향후 방향성을 논의하고 조율하는 과정이 필수적으로 동반되어야 한다 [3].
 
 ---
-*Last updated: 2026-05-03*
+*Last updated: 2026-05-03*
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🧪 검증 상태 (Validation)
+
+- **정보 상태:** needs_review
+- **출처 신뢰도:** A
+- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+
+## 🧬 중복 검사 (Duplicate Check)
+
+- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
+- **처리 방식:** UPDATE (자동 정규화)
+- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+
+## 🔗 지식 연결 (Graph)
+
+- **Parent:** [[10_Wiki/Topics]]
+- **Related:** *(TODO: 최소 2개)*
+- **Opposite / Trade-off:** *(TODO)*
+- **Raw Source:** 직접 입력
+
+## 🕓 변경 이력 (Changelog)
+
+| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
+|------|-----------|-----------|--------|
+| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
+
+## 💻 코드 패턴 (Code Patterns)
+
+**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
+
+```text
+# TODO
+```
+
+## 🤔 의사결정 기준 (Decision Criteria)
+
+**선택 A를 써야 할 때:**
+- *(TODO)*
+
+**선택 B를 써야 할 때:**
+- *(TODO)*
+
+**기본값:**
+> *(TODO)*
+
+## ❌ 안티패턴 (Anti-Patterns)
+
+- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*