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

10_Wiki/Topics/Architecture/Mock Objects (가짜 객체).md

@@ -1,6 +1,26 @@
+---
+id: wiki-2026-0508-mock-objects-가짜-객체
+title: Mock Objects (가짜 객체)
+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
+---
+
 # [[Mock Objects (가짜 객체)]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 Mock Objects(가짜 객체)는 단위 테스트(Unit Test)를 수행할 때 완벽한 격리(Isolation)를 달성하고 사이드 이펙트를 방지하기 위해 실제 협력 객체(Collaborator)를 대체하는 테스트 대역(Test Double)의 일종입니다 [1, 2]. 테스트를 위해 실제 시스템의 구성 요소처럼 보이게 만들고, 테스트 작성자가 미리 정의해 둔 응답(canned responses)을 반환하도록 설정됩니다 [2]. 리팩토링의 맥락에서는 특히 레거시 코드에서 복잡한 외부 자원(DB, 네트워크 등)의 의존성을 끊어내고 안전한 테스트 환경을 구축하는 데 핵심적인 역할을 수행합니다 [3, 4].
 
 ## 📖 기Core Content
@@ -16,7 +36,7 @@ Mock Objects(가짜 객체)는 단위 테스트(Unit Test)를 수행할 때 완
 * **AI 기반 테스트 생성에서의 활용**
   최근 LLM(거대언어모델)을 통한 자동 테스트 생성 시에도 Mock 객체가 중요하게 다뤄집니다. 연구에 따르면 모델이 공통의 설정 로직, 표준화된 Mocking 패턴, 그리고 테스트 데이터와 로직의 분리를 적절히 활용하는 인프라를 자가 생성하기도 하며, 요청 가로채기에 기반한 API Mocking 계층을 구성하여 코드의 재사용성을 높인 사례가 있습니다 [6, 7].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 * **구현 세부 사항과의 과도한 결합 (Brittleness)**
   단위 테스트가 프로덕션 코드의 내부 구현에 너무 밀접하게 연관되면(예: 지나치게 많은 Mocking 사용), 코드를 리팩토링할 때마다 테스트가 깨지는 취약성이 발생할 수 있어 유지보수가 번거로워집니다 [8].
 * **Mock과 Stub의 용어 혼용**
@@ -24,8 +44,7 @@ Mock Objects(가짜 객체)는 단위 테스트(Unit Test)를 수행할 때 완
 * **AI 테스트 생성 시의 한계**
   LLM을 활용해 자동화된 테스트를 작성할 때 모델이 충분한 Mocking 능력을 보이지 못하는(insufficient mocking capabilities) 문제점이 보고된 바 있습니다 [9]. 이를 방지하기 위해 내부 훅(internal hooks)에 대한 Mocking을 금지하는 등의 명시적인 프롬프트 및 규칙(rule file) 설정이 필요할 수 있습니다 [10].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [테스트 및 품질 관리 아키텍처]
@@ -67,4 +86,61 @@ Mock Objects(가짜 객체)는 단위 테스트(Unit Test)를 수행할 때 완
   - 확장 방향: 테스트 없이 작성되어 의존성이 엉켜있는 레거시 코드가 시스템의 유지보수성을 어떻게 떨어뜨리는지(엔트로피 증가), 이를 리팩토링으로 상환하는 개념에 대한 탐구 [15].
 
 ---
-*Last updated: 2026-05-03*
+*Last updated: 2026-05-03*
+
+## 📖 구조화된 지식 (Synthesized Content)
+
+**추출된 패턴:**
+> *(TODO)*
+
+**세부 내용:**
+- *(TODO)*
+
+## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
+
+```text
+# TODO
+```
+
+## 🤔 의사결정 기준 (Decision Criteria)
+
+**선택 A를 써야 할 때:**
+- *(TODO)*
+
+**선택 B를 써야 할 때:**
+- *(TODO)*
+
+**기본값:**
+> *(TODO)*
+
+## ❌ 안티패턴 (Anti-Patterns)
+
+- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*