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

10_Wiki/Topics/Architecture/Test Automation Pyramid.md

@@ -1,22 +1,41 @@
+---
+id: wiki-2026-0508-test-automation-pyramid
+title: Test Automation Pyramid
+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
+---
+
 # [[Test Automation Pyramid]]
 
 ## 📌 Brief 마이크 요약
 Test Automation Pyramid(테스트 자동화 피라미드)는 소프트웨어 테스트를 입도(Granularity)에 따라 여러 계층으로 그룹화하고, 각 계층에서 얼마나 많은 테스트를 작성해야 하는지를 시각적으로 나타낸 메타포입니다 [1]. 이 원칙은 가장 빠르고 독립적인 단위 테스트(Unit Tests)를 피라미드의 하단에 가장 많이 배치하고, 상위 수준인 통합 테스트와 엔드 투 엔드(E2E) 테스트로 갈수록 그 수를 줄일 것을 권장합니다 [2, 3]. 이를 통해 리팩토링과 같은 코드 구조 변경 시 즉각적이고 신뢰할 수 있는 피드백을 제공하는 빠르고 유지보수 가능한 테스트 스위트를 구축할 수 있습니다 [3, 4].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 *   **개념의 기원 및 기본 원칙:** 마이크 콘(Mike Cohn)이 고안한 이 개념은 테스트를 다양한 입도로 작성하되, 상위 수준(High-level)으로 갈수록 테스트의 수를 적게 유지하라는 두 가지 핵심 원칙을 제시합니다 [1, 3].
 *   **단위 테스트 (Unit Tests - 피라미드 하단):** 전체 자동화 테스트의 약 70%를 차지해야 하는 기반 계층입니다 [5]. 밀리초 단위로 매우 빠르게 실행되며, 개별 컴포넌트나 함수 수준의 동작을 격리하여 검증합니다 [5]. 리팩토링 중 실수가 발생했을 때 가장 빠르고 정확한 피드백 루프를 제공합니다 [4, 6].
 *   **통합 테스트 (Integration Tests - 피라미드 중간):** 약 20%를 차지하며, 단위 테스트로는 잡을 수 없는 컴포넌트 간의 상호작용(데이터베이스, 외부 API 등)의 결함을 찾아냅니다 [7-9].
 *   **엔드 투 엔드 테스트 (End-to-End Tests - 피라미드 상단):** 10% 정도로 유지해야 합니다 [10]. 사용자 인터페이스부터 백엔드 서비스까지 전체 워크플로우를 실제 사용자 여정에 맞춰 검증하지만, 구축 비용이 가장 비싸고, 실행 속도가 매우 느리며, 유지보수가 까다롭습니다(brittle) [4, 10].
 *   **테스트 중복 제거와 하향 이동 (Push Tests Down):** 테스트 스위트의 비대화를 막기 위해, 상위 수준 테스트에서 오류를 발견했는데 하위 수준 테스트가 실패하지 않았다면 반드시 하위 수준(단위 테스트 등)에 테스트를 추가해야 합니다 [11]. 가능한 한 모든 테스트는 피라미드의 가장 아래 계층에서 검증하도록 내려보내야 합니다 [11].
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 *   **역 피라미드 및 아이스크림 콘 안티 패턴 (Inverted Pyramid / Ice-Cream Cone):** UI 기반의 E2E 테스트 위주로 하향식(Top-down) 자동화를 시도하면 '역 테스트 피라미드'가 형성됩니다 [3, 10]. 이 경우 테스트 스위트 실행에 수 시간이 걸리고 거짓 실패(False failures)가 잦아져, 팀이 자동화 테스트를 불신하고 결과를 무시하게 되는 부작용이 발생합니다 [10, 12].
 *   **계층 명칭의 모호성과 시대적 한계:** 원본 피라미드가 제시한 'Service Test'나 'UI Test'라는 명칭은 현대 개발 환경(예: React, Angular 등 SPA 프레임워크)에서는 오해를 살 수 있습니다 [3]. SPA 환경에서는 UI 자체도 최상단이 아닌 단위 테스트 수준에서 검증할 수 있기 때문입니다 [3].
 *   **신뢰성과 실행 속도의 트레이드오프:** 피라미드 상단으로 갈수록 사용자의 실제 사용 환경과 유사해져 비즈니스적 확신(Confidence)은 높아지지만, 실행 시간(Speed)과 유지보수(Maintainability) 비용이 급증합니다 [10, 13]. 따라서 커버리지, 속도, 신뢰성의 균형을 시스템 전체 관점에서 조율해야 합니다 [14].
 
-## 🔗 Knowledge Connections
-
+## 🔗 지식 연결 (Graph)
 ### Related Concepts
 
 #### [구현/테스트 전략]
@@ -54,4 +73,57 @@ Test Automation Pyramid(테스트 자동화 피라미드)는 소프트웨어 테
   - 확장 방향: 마이크로서비스 환경에서 통합 테스트의 비용을 줄이고, 서비스 간 API 인터페이스(계약)가 깨지지 않았는지 독립적으로 검증하는 기법으로 테스트 피라미드 전략을 확장할 수 있습니다 [25, 26].
 
 ---
-*Last updated: 2026-05-03*
+*Last updated: 2026-05-03*
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+
+> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
+
+## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*