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

10_Wiki/Topics/AI_and_ML/Startup Projects.md

@@ -1,7 +1,24 @@
-## 📌 Brief Summary
+---
+id: wiki-2026-0508-startup-projects
+title: Startup Projects
+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)
+---
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
 스타트업 프로젝트(Startup Projects)는 제한된 리소스와 시간 내에 빠른 시장 검증(MVP)을 목표로 하는 고속 개발 환경이다. 요구사항이 수시로 변하는 특성에 맞춰, 단순하면서도 확장성 있는 기술 스택(Zustand 등)과 실용적인 개발 원칙(YAGNI, 단순 브랜치 전략)을 채택하여 민첩성을 확보하는 것이 핵심이다.
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 1. **상태 관리 도구의 실용적 선택**
    - 초기부터 복잡한 Redux를 도입하기보다, 보일러플레이트가 적고 빠른 배포가 가능한 **Zustand**를 활용하여 MVP를 신속히 구축한다.
 2. **YAGNI 원칙의 철저한 준수**
@@ -12,12 +29,12 @@
    - 복잡한 Git Flow 대신 단순한 **Feature-branch workflow**를 사용하여 코드 리뷰 속도를 높이고 병합 충돌을 최소화한다.
    - 짧은 수명의 브랜치와 Squash Merge를 통해 깨끗한 main 이력을 유지한다.
 
-## ⚖️ Trade-offs & Caveats
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
 - **기술적 부채의 축적**: 빠른 배포를 위한 단순한 설계가 서비스 성장 시점에서 성능이나 확장성 병목을 유발할 수 있으므로, 적절한 시기의 리팩토링 계획이 병행되어야 한다.
 - **도구의 한계**: Zustand와 같은 가벼운 도구는 규모가 커질 때 엄격한 구조적 제약이 부족하여 상태 관리가 파편화될 위험이 있다.
 - **오버엔지니어링의 유혹**: 최신 기술이나 복잡한 아키텍처(FSD 등)를 무분별하게 도입할 경우 스타트업의 최대 자산인 '속도'를 잃을 수 있다.
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 ### Related Concepts (Auto-Linked)
 * [[Agile Development]]
 * [[Management]]
@@ -46,3 +63,29 @@
 - **Agile Development & Scrum**
 - **Minimum Viable Product (MVP) Strategy**
 - **Technical Debt Management**
+
+## 🤖 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 |