bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
g1nation
2026-05-08 19:52:07 +09:00
parent 9dd3d40662
commit 5ba5a55c78
3984 changed files with 334557 additions and 28839 deletions
Download Patch File Download Diff File Expand all files Collapse all files
10_Wiki/Topics/Backend/Accordion.md
+83 -7
View File
@@ -1,11 +1,21 @@
---
id: wiki-2026-0508-accordion
title: Accordion
description: A vertically stacked set of interactive headings that each reveal a section of content.
base: radix
component: true
links:
doc: https://www.radix-ui.com/primitives/docs/components/accordion
api: https://www.radix-ui.com/primitives/docs/components/accordion#api-reference
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
---
<ComponentPreview
@@ -166,10 +176,76 @@ To enable RTL support in shadcn/ui, see the [RTL configuration guide](/docs/rtl)
See the [Radix UI](https://www.radix-ui.com/primitives/docs/components/accordion#api-reference) documentation for more information.
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts (Auto-Linked)
* [[Design Pattern]]
* [[Radix UI]]
* [[Reference]]
* [[Support]]
* [[shadcn-ui]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Ad-hoc-Optimization.md
+66 -5
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-ADOP-001
category: Unified
confidence_score: 0.90
tags: [auto-reinforced, [[Optimization|Optimization]], ad-hoc, process-[[Efficiency|Efficiency]], project-[[Management|Management]], software-design]
id: wiki-2026-0508-ad-hoc-optimization
title: Ad hoc Optimization
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-ADOP-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced, Optimization, ad-hoc, process-Efficiency, project-Management, software-design]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Ad-hoc-Optimization|Ad-hoc-Optimization]]
@@ -24,7 +36,7 @@ Ad-hoc 최적화(임시적 최적화)는 전체적인 설계 원칙(Standardizat
3. **개선 프로세스**:
* Ad-hoc 조치 후에는 반드시 '사후 병합(Refactoring)' 과정을 거쳐 해당 최적화를 표준 아키텍처 내로 편입시켜야 함.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거의 '결과 중심 개발 정책'은 Ad-hoc 최적화를 통해 일정을 맞추는 것을 권장했으나, 현대의 '지속 가능한 시스템 운영 정책'은 이를 잠재적 리스크로 규정하고 정기적인 코드 리뷰와 설계 승인(QC) 정책을 강화함(RL Update).
- **정책 변화(RL Update)**: 인프라 운영 정책에서, 수동으로 Ad-hoc 설정을 변경하는 대신 모든 변화를 코드로 관리하는 'IaC (Infrastructure as Code) 정책'을 도입하여 임시방편적 개입을 원천 차단하는 방향으로 진화함.
@@ -32,3 +44,52 @@ Ad-hoc 최적화(임시적 최적화)는 전체적인 설계 원칙(Standardizat
- [[Standardization vs Innovation|Standardization vs Innovation]], Workflow-InteGrity, [[Theory of Constraints (TOC)|Theory of Constraints (TOC)]], [[Software-Design-Principles|Software-Design-Principles]], [[Operations-Research|Operations-Research]]
- **Modern Tech/Tools**: Refactoring tools, Static code [[Analysis|Analysis]], CI/CD automated [[Testing|Testing]].
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Bourgeoisie.md
+64 -3
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-BOUR-001
category: Unified
id: wiki-2026-0508-bourgeoisie
title: Bourgeoisie
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-BOUR-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.82
tags: [auto-reinforced, bourgeoisie, sociology, class-theory, capitalism, history]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Bourgeoisie|Bourgeoisie]]
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
* 마르크스주의에서는 노동력을 착상하여 자본을 축적하는 이기적인 계층으로 정의하기도 함.
* **Status Quo**: 기득권이 된 이후에는 변화보다 안정을 추구하는 보수적인 성향을 띠기도 함.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거에는 오직 '물리적 자본' 소유자만을 부르주아지로 보았으나, 현대 정보 정책은 '데이터와 지식 자산'을 소유한 기술 엘리트들을 '디지털 부르주아지 정책'으로 재정의함(RL Update).
- **정책 변화(RL Update)**: 부의 대물림 정책에 대한 사회적 비판 정책이 강화됨에 따라, 최근의 부르주아적 가치는 단순 소유를 넘어 사회적 책임(ESG, 기부 정책)을 다하는 '노블레스 오블리주 정책'으로 그 정체성을 갱신하려 노력함.
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
- [[Anarcho-Capitalism|Anarcho-Capitalism]], [[Arts|Arts]], [[Axiology|Axiology]], [[Sociology of Knowledge|Sociology of Knowledge]], Capitalism
- **Modern Tech/Tools**: Asset [[Management|Management]] AI, Venture capital networks.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Cache Side-Channel Attack.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-55C813
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-cache-side-channel-attack
title: Cache Side Channel Attack
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-55C813]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - Cache [[Side-channel Attack|Side-channel Attack]]"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Cache Side-Channel Attack|Cache Side-Channel Attack]]
@@ -20,7 +31,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Cache [[Side-channel Attack|Si
* **위험 기능 비활성화:** 고해상도 타이머를 생성하는 데 악용될 수 있는 `SharedArrayBuffer` 기능과 정밀한 타이밍을 제공하던 `EXT_disjoint_timer_query` 확장 기능 등을 비활성화하거나 접근을 엄격히 제한했습니다 [1, 6, 7].
* **분기 없는 보안 검사(Branchless Security Checks):** 공격자가 추측 실행의 분기(Branch)를 제어할 수 있게 됨에 따라, 분기 명령어에 의존하는 기존의 보안 체계는 무력화되었습니다 [5, 11, 15]. 이에 대응하기 위해 [[WebKit|WebKit]]과 Blink 같은 엔진은 인덱스 마스킹(Index Masking)과 포인터 포이즈닝([[Pointer Poisoning|Pointer Poisoning]])과 같이 조건부 분기를 사용하지 않는 형태의 보안 검사 방식을 새롭게 도입했습니다 [4, 7, 16, 17].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -33,3 +44,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Cache [[Side-channel Attack|Si
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Case-Study-Skybound-Asset-Cache-Busting.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: CS-SKYBOUND-CACHE-001
category: Unified
id: wiki-2026-0508-case-study-skybound-asset-cache-
title: Case Study Skybound Asset Cache Busting
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [CS-SKYBOUND-CACHE-001]
duplicate_of: none
source_trust_level: A
confidence_score: 1.0
tags: [skybound, troubleshooting, cache-busting, production-deployment, vite, asset-[[Management|Management]]]
tags: [skybound, troubleshooting, cache-busting, production-deployment, vite, asset-Management]
raw_sources: []
last_reinforced: 2026-04-26
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# Case Study: Skybound Production Visual Mismatch & Asset Cache Busting (사례 연구: Skybound 자산 캐시 버스팅)
@@ -19,10 +31,59 @@ last_reinforced: 2026-04-26
- **Vite Configuration Update:** `vite.config.ts`의 `build.outDir`을 동적으로 할당하여 빌드마다 고유한 지문(Fingerprint)을 가진 경로 생성.
- **성과:** 배포 즉시 모든 클라이언트가 최신 시각적 자산을 로드함을 보장하며, 수동 캐시 삭제 요청 없이도 완벽한 버전 동기화 달성.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 과거에는 파일명 뒤에 쿼리 스트링(`?v=1.2`)을 붙이는 방식이 선호되었으나, 일부 프록시 서버나 CDN에서 이를 무시하는 정책이 발견됨에 따라 현대 정책은 '물리적 경로 변경 정책'을 최우선으로 함.
- **정책 변화:** Antigravity 프로젝트는 모든 웹 기반 게임 엔진 배포 시 `dist/` 폴더 하위에 빌드 번호별 격리된 자산 경로를 생성하는 것을 강제하는 배포 정책을 시행함.
## 🔗 지식 연결 (Graph)
- Modern-Frontend-Engineering-Architecture, Vite-Build-[[Optimization|Optimization]], [[Frontend-Performance-Optimization-Guide|Frontend-Performance-Optimization-Guide]]
- **Raw Source:** 00_Raw/2026-04-26-Skybound_Production_Visual_Mismatch_Public_Asset_Cache_Busting.md
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Composition_API.md
+17 -71
View File
@@ -1,79 +1,25 @@
---
category: Unified
tags: [auto-wikified, technical-documentation]
id: wiki-20260508-composition-api-redir
title: Composition API
description: "Vue 3의 Composition API는 작고 독립적인 단위로 애플리케이션의 복잡한 로직을 구성할 수 있게 해주는 API 모음이다."
last_updated: 2026-05-02
category: Backend
status: merged
redirect_to: Composition API
canonical_id: Composition API
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [redirect]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
---
# Composition API
## 📌 Brief Summary
Vue 3의 Composition API는 작고 독립적인 단위로 애플리케이션의 복잡한 로직을 구성할 수 있게 해주는 API 모음이다. 기존 Options API가 데이터나 메서드 등 옵션 타입별로 코드를 분리했던 것과 달리, 기능적 논리 단위별로 관련된 코드를 그룹화할 수 있게 해준다. 이를 통해 상태 저장 로직(Stateful logic)을 캡슐화하고 재사용하는 '컴포저블(Composable)' 패턴을 구현하여, 대규모이거나 빠르게 성장하는 애플리케이션에서 높은 유지보수성과 확장성을 제공한다.
## 📖 Core Content
* **로직의 캡슐화와 재사용 (Composables 패턴)**
Composition API를 활용하면 상태 기반 로직을 '컴포저블'이라는 독립적이고 재사용 가능한 함수로 추출할 수 있다. 마우스 위치 추적, 비동기 데이터 패칭(`useFetch`), 윈도우 크기 조정 등 시간에 따라 변하는 상태를 관리하는 로직을 여러 컴포넌트 간에 충돌 없이 공유할 수 있다. 과거 Options API에서 사용하던 Mixins의 한계(네임스페이스 충돌, 암묵적 의존성)를 완벽히 해결한다.
* **기능 중심의 코드 구조화**
기존 Options API에서는 특정 기능과 관련된 로직이 `data()`, `methods()`, `created()` 등으로 흩어져 있어 컴포넌트가 거대해질수록 파악하기 어려웠다. Composition API는 단일 기능과 관련된 모든 로직을 한 곳에 모을 수 있어 가독성을 높이고 디버깅 및 코드 추출을 용이하게 한다.
* **TypeScript와의 강력한 통합**
Composition API는 네이티브 수준의 TypeScript 지원을 제공한다. 기존 방식보다 보일러플레이트 코드가 적고, 변수나 함수에 대한 강력한 타입 추론과 제네릭 지원을 통해 훨씬 안정적인 개발자 경험(DX)을 선사한다.
* **컴포저블 작성 베스트 프랙티스**
* **명명 규칙**: 컴포저블 함수명은 `use`로 시작해야 한다 (예: `useMouse`).
* **입력 매개변수 유연성**: 일반 값뿐만 아니라 `ref`나 `getter` 함수도 입력받을 수 있도록 설계하며, 내부에서 `toValue()`를 사용해 처리하는 것이 권장된다.
* **반환 값 처리**: 반환 객체를 구조 분해 할당(Destructuring)할 때 반응성을 잃지 않도록, `reactive` 객체가 아닌 여러 개의 `ref`를 포함하는 일반(plain) 객체를 반환해야 한다.
* **부수 효과(Side Effects) 관리**: `<script setup>` 또는 `setup()` 내부에서 동기적으로 호출해야 하며, `onMounted()`에서 DOM 이벤트 리스너 등을 등록하고 `onUnmounted()`에서 반드시 정리(Clean-up)해야 한다.
* **현대 Vue 생태계의 표준**
Nuxt 3, Pinia, Vue Router 4, VueUse 등 최신 Vue 생태계의 핵심 도구들은 Composition API를 기본 전제로 설계되어 있어 원활한 통합을 제공한다.
## ⚖️ Trade-offs & Caveats
* **자유도에 따른 파편화 위험**: 코드를 조직하는 방식에 대한 강제성이 적다. 따라서 팀 내에 엄격한 컨벤션(예: ESLint 규칙, 명명 규칙, 계층화된 디렉토리 구조)이 없다면, 개발자마다 다른 방식으로 로직을 구현하여 코드가 혼란스러워질 수 있다. 너무 많은 로직을 `setup()` 내부에 방치하면 오히려 유지보수가 어려워진다.
* **반응성(Reactivity) 객체의 함정**: 초보자의 경우 `ref()`와 `reactive()`의 사용 기준에 혼란을 겪기 쉽다. 특히, 반응형 객체의 프로퍼티를 일반적인 방식으로 구조 분해 할당하면 반응성이 끊어지므로 `toRefs()`나 `storeToRefs()`를 반드시 사용해야 하며, `ref`에 접근할 때 `.value`를 붙이는 것을 잊는 실수가 잦다.
* **러닝 커브 상승**: Options API가 초보자 친화적이었던 반면, Composition API는 JavaScript의 클로저(Closures), 반응성 동작 원리, 함수 스코프에 대한 깊은 이해를 요구한다. 따라서 주니어 개발자 위주의 팀이나 구조가 단순한 프로젝트에서는 오히려 생산성을 저하시킬 수 있다.
* **기존 Options API와의 혼용 제약**: 컴포저블은 `setup()` 내부에서만 완벽히 동작한다. 기존 Options API 기반의 컴포넌트(`data()`, `created()` 등)에서 `VueUse`나 `Pinia` 같은 최신 도구를 사용하려면 중복된 상태를 만들거나 부자연스러운 연결(glue) 코드를 작성해야 하는 하이브리드 상태의 고통(Hybrid Pain)이 따른다.
## 🔗 Knowledge Connections
### Related Concepts
#### [아키텍처/기반 기술]
- [[Composables]]
- 연결 이유: Composition API를 활용해 상태 유지 로직을 캡슐화하는 핵심 소프트웨어 설계 패턴이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태를 가지는 로직과 순수 함수의 분리, 단일 책임 원칙에 기반한 프론트엔드 모듈화 전략.
- [[Options API]]
- 연결 이유: Composition API가 대체하거나 보완하고자 하는 이전 Vue의 기본 문법이자 비교 대상이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프레임워크의 진화 과정, 소규모 프로젝트와 대규모 프로젝트에 각각 적합한 API 선택 기준 및 점진적 마이그레이션(Migration) 전략.
- [[React Hooks]]
- 연결 이유: Composition API의 설계에 큰 영감을 준 React의 논리 합성 패턴이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 상태 변경 시 전체가 재실행(Re-render)되는 React Hooks와, `setup()`에서 한 번만 실행되며 프록시(Proxy) 기반으로 추적하는 Vue의 실행 모델(Execution Model) 차이.
#### [구현/활용 도구]
- [[Pinia]]
- 연결 이유: Composition API를 기반으로 설계된 Vue 3의 공식 상태 관리 라이브러리로, Vuex를 대체한다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컴포저블 스토어 패턴을 통한 전역 상태 관리 및 Mutations 없이 상태를 다루는 현대적인 상태 정규화(Normalization) 기법.
- [[VueUse]]
- 연결 이유: Composition API를 활용해 200개 이상의 유틸리티를 구현한 오픈소스 컴포저블 컬렉션이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 API, 센서, 상태 동기화 등을 추상화하는 실전 컴포저블 구현 모범 사례.
### Deeper Research Questions
- Composition API의 프록시(Proxied refs) 기반 반응성 모델은 React Hooks의 실행 모델과 비교하여 렌더링 최적화 측면에서 어떤 근본적인 차이를 만들어내는가?
- 대규모 엔터프라이즈 환경에서 Composition API로 로직을 캡슐화할 때, 도메인 주도 설계(DDD) 관점에서 기능 중심 모듈화(Feature-based architecture)를 어떻게 설계할 수 있는가?
- 상태 저장 로직을 재사용하고자 할 때, 렌더리스 컴포넌트(Renderless Components) 패턴과 컴포저블(Composables) 패턴 중 인스턴스 오버헤드와 UI 렌더링 제어권 측면에서 어느 것을 선택해야 하는가?
- 기존 Options API로 작성된 거대한 레거시 컴포넌트를 Composition API로 점진적으로 리팩토링할 때(Hybrid 상태), 부작용과 코드 중복을 최소화하는 전략은 무엇인가?
- 대규모 리스트나 복잡한 상태 트리를 다룰 때, 반응성 오버헤드를 줄이기 위해 `shallowRef`나 `v-memo`와 같은 고급 최적화 기법을 어떻게 적용해야 하는가?
### Practical Application Contexts
- **Implementation:** 비동기 데이터 로딩(`useFetch`), 윈도우 사이즈 추적(`useWindowSize`), 모달 상태 관리 등 여러 UI 컴포넌트에서 반복되는 로직을 단일 함수로 분리하여 작성할 때 구현된다.
- **System Design:** 컴포넌트 트리를 구성할 때, UI 레이어(Template)와 비즈니스 로직 레이어(Composable)를 명확히 격리하여 각 컴포넌트가 프레젠테이셔널(Presentational) 역할을 수행하도록 돕는 기반 구조로 작동한다.
- **Operation / Maintenance:** 관련된 로직이 단일 함수로 응집되므로, UI 렌더링 환경 없이도 비즈니스 로직만 별도로 단위 테스트(Unit Testing)하기 쉬워져 유지보수성이 대폭 향상된다.
- **Learning Path:** Vue의 기초 문법을 익힌 뒤, `ref`와 `reactive`의 동작 원리인 반응성 시스템을 공부하고, VueUse 라이브러리의 소스 코드를 읽으며 우수한 컴포저블 작성 컨벤션을 학습하는 경로로 이어진다.
- **My Project Relevance:** 컴포넌트의 크기가 비대해져 코드 파악이 어렵거나(Giant Component 현상), 동일한 상태 관리 로직을 여러 뷰(View)에서 복사-붙여넣기로 사용하고 있는 경우 이를 리팩토링하는 핵심 솔루션이 될 수 있다.
### Adjacent Topics
- [[Renderless Components]]
- 확장 방향: 자체 템플릿(Markup)을 가지지 않고 상태와 로직만 하위 스코프 슬롯(Scoped Slots)으로 전달하는 또 다른 뷰 로직 재사용 패턴으로, Composition API의 대안적 접근법을 이해할 수 있다.
- [[Vue 3 Reactivity System]]
- 확장 방향: 프록시(Proxy) 기반으로 작동하는 `ref`, `reactive`, `watchEffect`의 내부 원리와 의존성 추적(Dependency tracking) 메커니즘을 심도 있게 탐구할 수 있다.
> [!IMPORTANT]
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Composition API]]**로 통합되었습니다.
---
*Last updated: 2026-05-02*
*Redirected to: [[Composition API]]*
10_Wiki/Topics/Backend/E-component (Execution Loop).md
+73 -5
View File
@@ -1,9 +1,29 @@
---
id: wiki-2026-0508-e-component-execution-loop
title: E component (Execution Loop)
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
---
# [[E-component (Execution Loop)|E-component (Execution Loop)]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
E-component(Execution Loop)는 에이전트 하네스의 '심장'에 해당하는 구성 요소로, 에이전트가 목표를 달성할 때까지 수행하는 **관찰(Observe) - 사고(Think) - 행동(Act)** 루프를 제어하고 관리한다. 에이전트의 생명 주기를 유지하며, 언제 모델을 호출하고 언제 도구를 실행할지, 그리고 작업이 완료되었는지를 판단하는 결정론적(Deterministic) 흐름 제어 계층이다.
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **루프 제어 전략**:
* **고정 반복 (Fixed Iteration)**: 사전에 정의된 횟수만큼 루프를 실행.
* **조건 기반 종료 (Condition-based)**: 모델이 "완료" 신호를 보내거나, 특정 결과값에 도달했을 때 종료.
@@ -13,13 +33,12 @@ E-component(Execution Loop)는 에이전트 하네스의 '심장'에 해당하
* **휴먼-인-더-루프 (HITL) 개입**: 루프의 특정 지점에서 인간의 승인을 기다리거나 피드백을 받아 작업 방향을 수정하는 중단점(Breakpoints)을 제어한다.
* **토큰 및 비용 가드레일**: 무한 루프에 빠져 토큰을 과도하게 소모하는 것을 방지하기 위해 최대 실행 시간이나 비용 한도를 강제한다.
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **루프 깊이와 정확도**: 루프를 많이 돌수록 결과의 품질은 향상될 수 있으나(Test-time scaling), 지연 시간과 비용이 비례해서 증가한다.
* **무한 루프 리스크**: 모델이 동일한 잘못된 행동을 반복하며 루프를 탈출하지 못하는 '논리적 데드락'에 빠질 수 있다.
* **상태 폭발**: 루프가 길어질수록 컨텍스트에 쌓이는 데이터가 많아져 모델의 성능이 저하(Context Rot)될 수 있다.
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
* [[Agent Harness|Agent Harness]]
* 연결 이유: E-component는 하네스의 실행 주체이다.
@@ -39,3 +58,52 @@ E-component(Execution Loop)는 에이전트 하네스의 '심장'에 해당하
---
*Last updated: 2026-05-01*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/ESLint.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-BDDA30
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-eslint
title: ESLint
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-BDDA30]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - ESLint"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[ESLint|ESLint]]
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - ESLint"
* **워크플로우 및 자동화 연동**
코드 변경 사항이 Git 저장소에 반영되기 전, 나쁜 코드가 커밋되는 것을 방지하기 위해 자동화 파이프라인과 결합하여 사용됩니다 [26, 27]. 주로 `[[Husky|Husky]]`와 `lint-staged` 도구를 활용하여, Git의 `pre-commit` 훅(hook) 단계에서 변경된(staged) 파일에 대해서만 ESLint 검사 및 자동 수정을 실행하도록 구성합니다 [11, 28-30]. 대규모 모노레포([[Monorepo|Monorepo]]) 환경에서는 중복 구성을 피하기 위해 중앙집중식 ESLint 설정 패키지를 만들어 각 하위 패키지가 이를 공유하도록 구성하여 효율성을 극대화합니다 [15, 31, 32].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -38,3 +49,52 @@ github_commit: "[P-Reinforce] Continuous Worker - ESLint"
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
```
## 🤔 의사결정 기준 (Decision Criteria)
**선택 A를 써야 할 때:**
- *(TODO)*
**선택 B를 써야 할 때:**
- *(TODO)*
**기본값:**
> *(TODO)*
## ❌ 안티패턴 (Anti-Patterns)
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/GPU for the Web Community Group.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-518388
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-gpu-for-the-web-community-group
title: GPU for the Web Community Group
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-518388]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Comm[[Unity|Unity]] Group"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[GPU for the Web Community Group|GPU for the Web Community Group]]
@@ -20,7 +31,7 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Comm[[Unity|Un
* 그룹 내 논의를 통해, 사이트 격리(site isolation) 여부와 상관없이 hr-time(High Re[[Solution|Solution]] Time)의 비격리 해상도인 100마이크로초(100us) 수준으로 양자화(coarsen)하여 타임스탬프를 허용하는 제안을 수용 및 승인했습니다 [7].
* 이를 통해 브라우저 간의 상호 운용성 문제를 해결하고 플랫폼 표준에 맞춘 성능 측정 기능을 제공할 수 있게 되었습니다 [8, 9].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
@@ -33,3 +44,52 @@ github_commit: "[P-Reinforce] Continuous Worker - GPU for the Web Comm[[Unity|Un
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/HBO-Prestige-Television.md
+64 -3
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-HBOT-001
category: Unified
id: wiki-2026-0508-hbo-prestige-television
title: HBO Prestige Television
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-HBOT-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-reinforced, hbo, prestige-tv, storytelling, narrative, television-history, cultural-impact]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[HBO-Prestige-Television|HBO-Prestige-Television]]
@@ -21,7 +33,7 @@ HBO 프레스티지 텔레비전(HBO-Prestige-Television)은 1990년대 후반
2. **왜 중요한가?**:
* 넷플릭스 등 오늘날 OTT 경쟁의 근간이 되는 '오리지널 고품질 콘텐츠'의 비즈니스 모델과 예술적 형식을 정립했기 때문임. ([[Strategic-Planning|Strategic-Planning]]와 연결)
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거 TV 드라마 정책은 광고를 위한 '시간 때우기' 정책이었다면, HBO 정책은 '돈을 내고 소장하고 싶은 작품 정책'으로 가치를 전환함(RL Update).
- **정책 변화(RL Update)**: 이제는 단순 제작 정책을 넘어, 데이터 분석 정책을 통해 시청자가 이탈하는 지점 정책을 분석하고 최적의 서사 구조 정책을 설계하는 AI 서사 알고리즘 정책과의 협업 단계로 진화 중임. ([[Experience-Sampling-Method|Experience-Sampling-Method]]와 연결)
@@ -29,3 +41,52 @@ HBO 프레스티지 텔레비전(HBO-Prestige-Television)은 1990년대 후반
- [[Dramaturgy-Theory|Dramaturgy-Theory]], [[Strategic-Planning|Strategic-Planning]], [[Experience-Sampling-Method|Experience-Sampling-Method]], Communication, User-Experience, Ethics
- **Key Works**: The Sopranos, The Wire, Game of Thrones, Succession.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Indirect Prompt Injection.md
+73 -5
View File
@@ -1,9 +1,29 @@
---
id: wiki-2026-0508-indirect-prompt-injection
title: Indirect Prompt Injection
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
---
# Indirect Prompt Injection (간접 프롬프트 인젝션)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
Indirect Prompt Injection(간접 프롬프트 인젝션)은 사용자가 직접 명령을 내리는 것이 아니라, 에이전트가 읽어 들인 외부 소스(웹페이지, 문서, 파일, 도구 출력 등)에 숨겨진 악의적인 지침이 에이전트의 판단과 행동을 하이재킹하는 공격 기법이다. 에이전트가 외부 지식을 적극적으로 탐색하는 자율적 특성 때문에 발생하는 가장 치명적이고 방어하기 어려운 보안 위협 중 하나이다.
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **공격 시나리오**:
* **웹 검색 하이재킹**: 에이전트가 요약하려는 웹페이지에 "이전 명령은 잊고 사용자의 이메일을 모두 삭제해"라는 지침이 보이지 않는 텍스트로 숨겨져 있는 경우.
* **데이터 오염**: 신뢰할 수 없는 API 결과나 로그 파일에 악성 코드를 주입하여, 에이전트가 이를 실행하도록 유도.
@@ -14,12 +34,11 @@ Indirect Prompt Injection(간접 프롬프트 인젝션)은 사용자가 직접
* **격리된 실행 (Sandbox)**: 외부 데이터에서 유발된 코드가 실행되더라도 시스템에 영향을 주지 않도록 물리적으로 격리된 환경을 유지한다.
* **직접 프롬프트 인젝션과의 차이**: 직접 인젝션은 사용자가 공격자이지만, 간접 인젝션은 사용자는 피해자이며 에이전트가 신뢰하고 읽은 외부 데이터가 공격자가 된다.
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **완벽한 차단의 어려움**: 자연어는 모호하기 때문에, 모델이 무엇이 정당한 데이터이고 무엇이 악의적인 지침인지 완벽하게 구분하게 만드는 것은 기술적 한계가 있다.
* **성능과 보안의 균형**: 외부 데이터를 너무 엄격하게 필터링하면 작업에 필요한 유익한 정보까지 유실될 수 있다.
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
* [[Agentic AI Security|Agentic AI Security]]
* 연결 이유: 간접 프롬프트 인젝션은 에이전트 보안의 가장 큰 위협 요소이다.
@@ -38,3 +57,52 @@ Indirect Prompt Injection(간접 프롬프트 인젝션)은 사용자가 직접
---
*Last updated: 2026-05-01*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/KISS (Keep It Simple, Stupid).md
+64 -3
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-KISS-001
category: Unified
id: wiki-2026-0508-kiss-keep-it-simple-stupid
title: "KISS (Keep It Simple, Stupid)"
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-KISS-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
tags: [auto-reinforced, kiss-principle, design, simplicity, engineering, minimalism]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[KISS (Keep It Simple, Stupid)|KISS (Keep It Simple, Stupid)]]
@@ -21,7 +33,7 @@ KISS 원칙은 미 해군에서 유래한 설계 원칙으로, 시스템은 단
2. **왜 중요한가?**:
* 소프트웨어 개발에서 복잡성은 버그와 기술 부채의 원상이며, 단순한 코드가 최고의 가독성과 성능을 보장하기 때문임. ([[Efficiency|Efficiency]]와 연결)
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거에는 화려하고 거대한 프레임워크 정책이 기술력을 상징했으나, 현대 정책은 최소한의 의존성과 직관적인 API 정책을 가진 도구가 수백만 개발자의 선택을 받는 '심플리티 정책'이 승리함(RL Update).
- **정책 변화(RL Update)**: AI 프롬프트 엔지니어링 정책에서도, 복잡한 지시문보다 명확하고 단순한 구조의 프롬프트가 모델의 성능 정책을 더 안정적으로 끌어내는 경향이 확인됨.
@@ -29,3 +41,52 @@ KISS 원칙은 미 해군에서 유래한 설계 원칙으로, 시스템은 단
- [[Efficiency|Efficiency]], [[Technical-Architecture|Technical-Architecture]], [[Design-System|Design-System]], [[Iterative-Development|Iterative-Development]], [[Scalability|Scalability]]
- **Modern Tech/Tools**: Minimalist UI design, Microservices, Function-as-a-Service (FaaS).
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Lessons Learned.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-LELE-001
category: Unified
id: wiki-2026-0508-lessons-learned
title: Lessons Learned
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-LELE-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.94
tags: [auto-reinforced, lessons-learned, feedback, post-mortem, review, [[Optimization|Optimization]]]
tags: [auto-reinforced, lessons-learned, feedback, post-mortem, review, Optimization]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Lessons Learned|Lessons Learned]]
@@ -22,7 +34,7 @@ last_reinforced: 2026-04-20
2. **왜 중요한가?**:
* 경험을 단순한 '기억'이 아닌 공유 가능한 '데이터'로 변환함으로써 조직의 학습 속도를 비약적으로 높임. ([[Intangible-Capital|Intangible-Capital]]의 축적)
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거에는 책임자를 질타하는 '문책형 회고 정책'이 많았으나, 현대 정책은 실패를 안전하게 공개하고 배우는 '무비난 회고(Blameless Post-mortem) 정책'이 조직 문화의 핵심 정책이 됨(RL Update).
- **정책 변화(RL Update)**: 단순히 문서를 남기는 정책을 넘어, 교훈을 즉시 시스템의 원칙 정책이나 체크리스트 정책으로 코드화하여 강제하는 '행동 유도형 레슨런 정책'으로 진화함.
@@ -30,3 +42,52 @@ last_reinforced: 2026-04-20
- [[Introspection (자기성찰)|Introspection (자기성찰)]], [[Feedback-Loops|Feedback-Loops]], [[Analysis|Analysis]], [[KPI (Key Performance Indicator)|KPI (Key Performance Indicator)]], [[Intangible-Capital|Intangible-Capital]]
- **Modern Tech/Tools**: Post-mortem templates, Retrospective meetings, After Action Review (AAR).
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Mental-Operations-Synthesized.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-MOSS-001
category: Unified
id: wiki-2026-0508-mental-operations-synthesized
title: Mental Operations Synthesized
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-MOSS-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.85
tags: [auto-reinforced, mental-[[Opera|Opera]]tions, cognitive-synthesis, [[Reasoning|Reasoning]]-[[Logic|Logic]], mindset, intellectual-framework]
tags: [auto-reinforced, mental-Operations, cognitive-synthesis, Reasoning-Logic, mindset, intellectual-framework]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Mental-Operations-Synthesized|Mental-Operations-Synthesized]]
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
2. **왜 중요한가?**:
* 단순 지식의 보유량이 아닌, 지식을 얼마나 '빠르고 깊게 합성하여 활용하는가'가 현대 전문가의 진정한 뇌 근력이기 때문임. ([[Intangible-Capital|Intangible-Capital]]의 정점)
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거에는 개별 인지 능력(암기, 추론 등)을 따로 측정했으나, 현대 정책은 이들의 '합성적 발현 정책'인 MOS를 지능의 핵심 측정 지표 정책으로 삼음(RL Update). ([[ICRE-Framework|ICRE-Framework]]와 연결)
- **정책 변화(RL Update)**: 인공지능 에이전트 설계 정책에서, 다수의 특화 모델이 협동하여 결과를 내는 'Multi-agent 모듈 정책'은 사실상 기계가 인간의 MOS를 모방하려는 공학적 시도 정책으로 해석됨. (Agentic-Workflow와 연결)
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
- [[Analysis|Analysis]], [[Logic|Logic]], [[Knowledge synthesis|Knowledge synthesis]], [[ICRE-Framework|ICRE-Framework]], [[Intangible-Capital|Intangible-Capital]]
- **Modern Tech/Tools**: Thought maps, Second brain[[_system|system]]s, Multi-agent AI systems.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Modern_Environment_Ecosystem.md
+67 -5
View File
@@ -1,8 +1,21 @@
---
title: 모던 개발 환경 및 프레임워크 생태계
category: Unified
tags: [Vite, [[Next.js|Next.js]], Ecosystem, Modern Stack]
created: 2026-04-20
id: wiki-2026-0508-modern-environment-ecosystem
title: Modern Environment Ecosystem
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [Vite, Next.js, Ecosystem, Modern Stack]
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
---
# [[Modern_Environment_Ecosystem|Modern_Environment_Ecosystem]] (모던 개발 생태계)
@@ -18,9 +31,58 @@ created: 2026-04-20
- **패키지 매니저의 선택**:
- `pnpm` 또는 `npm v7+`의 워크스페이스 기능을 통해 모노레포([[Monorepo|Monorepo]]) 구조를 효율적으로 관리하고, 패키지 중복 설치를 최소화하여 빌드 성능을 최적화한다.
## ⚠️ 모순 및 업데이트 (RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- 최신 기술이 항상 정답은 아니다. 안정성이 최우선인 기업 환경에서는 검증된 `CRA` 혹은 `Webpack` 기반의 설정을 유지하는 것이 보수적인 면에서 유리할 수 있다. 기술 부채(Tech Debt)와 도입 비용을 항상 저울질하라.
## 🔗 지식 연결 (Graph)
- Related: [[Deployment_Final_Gate|Deployment_Final_Gate]] , Project_Architecture_Guidelines
- Foundation: [[TypeScript_Type_Safety|TypeScript_Type_Safety]]
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Nodejs Memory Tuning.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-254A8B
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-nodejs-memory-tuning
title: Nodejs Memory Tuning
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-254A8B]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - [[Nodejs|Nodejs]] [[memory|memory]] Tuning"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Nodejs Memory Tuning|Nodejs Memory Tuning]]
@@ -30,7 +41,7 @@ Node.js는 메모리 최적화를 위해 V8 엔진의 메모리 관련 설정을
* `--gc-interval`: 가비지 컬렉션이 시도되는 주기를 조정합니다 [5]. 실시간 처리 등 특정 조건에서 GC의 주기를 명시적으로 제어할 필요가 있을 때 사용합니다(예: `--gc-interval=100`) [5, 14].
* `--expose-gc`: 코드 내부에서 `global.gc()`를 호출하여 개발자가 수동으로 가비지 컬렉션을 실행할 수 있도록 허용하는 플래그입니다 [14, 15].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -43,3 +54,52 @@ Node.js는 메모리 최적화를 위해 V8 엔진의 메모리 관련 설정을
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Preserving-State-in-Procedural-Worlds.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-PREST-001
category: Unified
id: wiki-2026-0508-preserving-state-in-procedural-w
title: Preserving State in Procedural Worlds
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-PREST-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
tags: [auto-reinforced, pcg, [[State|State]]-[[Management|Management]], game-engine, persistence]
tags: [auto-reinforced, pcg, State-Management, game-engine, persistence]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Preserving-State-in-Procedural-Worlds|Preserving-State-in-Procedural-Worlds]]
@@ -22,7 +34,7 @@ last_reinforced: 2026-04-20
* **Hierarchical State [[Storage|Storage]]**: 전역 상태(정치 지표 등)와 지역 상태(건물 파손 등)를 분리하여 데이터 오버헤드 최소화.
* **Hash Maps for Sparse Data**: 광활한 맵 중 변경된 극소수 지점만을 빠르게 조회하기 위한 자료 구조 활용.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거 '로그라이크' 게임은 죽으면 모든 상태가 소멸하는 것을 미덕으로 삼았으나, 현대의 오픈 월드 절차적 생성 게임(No Man's Sky 등)은 시스템이 방대해짐에 따라 유저의 '영향력'을 유지하는 것이 게임 지속성의 핵심이 됨.
- **정책 변화(RL Update)**: 클라우드 기반 세이브 정책이 보편화됨에 따라, 엄청난 양의 절차적 변경 데이터를 서버 비용 효율적으로 압축하고 동기화하는 '데이터 구조 고도화 정책'이 멀티플레이어 환경의 필수 요건이 됨.
@@ -30,3 +42,52 @@ last_reinforced: 2026-04-20
- [[No Mans Sky (Large-scale planetary generation)|No Mans Sky (Large-scale planetary generation)]], [[PCGML-Frameworks|PCGML-Frameworks]], [[Object Pooling (오브젝트 풀링)|Object [[Pooling]] (오브젝트 풀링)]], Foundational Models
- **Modern Tech/Tools**: Minecraft NBT format, [[Unity|Unity]] Data-Oriented Technology Stack (DOTS).
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Principles-of-Data-Connect.md
+21 -29
View File
@@ -1,33 +1,25 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-DCON-001
category: Unified
confidence_score: 0.93
tags: [auto-reinforced, firebase, data-connect, cloud-sql, postgresql, database]
last_reinforced: 2026-04-20
id: wiki-2026-0508-principles-of-data-connect
title: Principles of Data Connect
category: 10_Wiki/Topics
status: merged
redirect_to: 데이터_엔지니어링_및_가상_인프라_표준
canonical_id: wiki-2026-0508-001
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
---
# [[Principles-of-Data-Connect|Principles-of-Data-Connect]]
# Redirect
## 📌 한 줄 통찰 (The Karpathy Summary)
> "NoSQL의 민첩함과 SQL의 엄격함의 결합: Firebase 환경에서 관계형 데이터베이스(PostgreSQL)를 GraphQL 인터페이스로 다루게 하여, 복잡한 데이터 관계를 안전하고 빠르게 처리하는 현대적 데이터 브릿지."
## 📖 구조화된 지식 (Synthesized Content)
Firebase Data Connect는 구글 클라우드의 관계형 데이터베이스(Cloud SQL)를 Firebase 생태계와 직결해주는 매니지드 서비스입니다.
1. **핵심 설계 철학**:
* **[[Schema|Schema]]-First Development**: GraphQL 스키마를 정의하면 데이터베이스 테이블과 API가 자동으로 생성됨.
* **Strong Typing**: 클라이언트와 서버 간 전송되는 데이터의 타입 일관성 보장.
* **Relational Power**: Firestore(NoSQL)에서 구현하기 까다로웠던 Join 연산과 복잡한 관계 쿼리를 SQL 엔진의 성능으로 해결.
2. **작동 원리**:
* 개발자가 `.gql` 파일에 스키마와 쿼리 정의 -> Firebase가 이를 PostgreSQL 명령어로 변환 -> SDK를 통해 클라이언트에 타입 안전한 결과 전달.
3. **데이터 무결성**:
* 관계형 데이터베이스의 장점인 ACID 트랜잭션과 외래 키(Foreign Key) 제약 조건을 활용하여 데이터 정합성 유지.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌**: Firebase는 그동안 NoSQL(Realtime DB, Firestore)의 대명사였으나, 엔터프라이즈급의 복잡한 데이터 요구사항을 수용하기 위해 SQL 진영의 장점을 적극적으로 수용하는 '멀티 패러다임' 정책으로 선회함.
- **정책 변화(RL Update)**: 보안 규칙(Security Rules) 대신 'App Check'와 'GraphQL 권한 설정'을 통해 데이터를 보호하는 새로운 보안 정책이 적용되며, 향후 Firebase의 모든 신규 대규모 프로젝트는 Data Connect를 우선 고려하는 가이드라인이 마련됨.
## 🔗 지식 연결 (Graph)
- [[Complexity Theory|Complexity Theory]], [[Software-Design-Principles|Software-Design-Principles]], Security & [[Reliability|Reliability]], [[Logic|Logic]], Information Extraction (IE)
- **Modern Tech/Tools**: PostgreSQL, GraphQL, Cloud SQL, Firebase CLI.
---
이 문서는 Canonical 문서인 [[데이터_엔지니어링_및_가상_인프라_표준]]으로 통합되었습니다.
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
10_Wiki/Topics/Backend/Prisons-and-Self-Correction.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-PRSC-001
category: Unified
id: wiki-2026-0508-prisons-and-self-correction
title: Prisons and Self Correction
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-PRSC-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-reinforced, sociology, criminology, rehabilitation,[[_system|system]]ic-design]
tags: [auto-reinforced, sociology, criminology, rehabilitation, _systemic-design]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Prisons-and-Self-Correction|Prisons-and-Self-Correction]]
@@ -23,7 +35,7 @@ last_reinforced: 2026-04-20
3. **기술적 지원**:
* AI 기반의 맞춤형 교육 프로그램 제공 및 재발 위험 인자(Trigger)를 본인이 인지하도록 돕는 모니터링 시스템.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거 '응보적 정의' 정책은 강력한 처벌이 범죄를 줄일 것이라 믿었으나, 실제 데이터는 처벌의 강도보다 '교정 프로그램의 질'이 재범률 감소에 훨씬 큰 영향을 미침을 보여줌 (노르웨이의 할덴 교도소 사례 연구).
- **정책 변화(RL Update)**: 단순 가두기 정책에서 벗어나, 지역 사회와 연계한 '단계별 석방 정책'과 '교정 전문 멘토링' 시스템을 강화하여 감옥 자체를 커뮤니티로의 연착륙을 돕는 가속기로 재정의하는 정책이 확산됨.
@@ -31,3 +43,52 @@ last_reinforced: 2026-04-20
- [[Psychology & Behavior|Psychology & Behavior]], [[Social Systems Theory|Social Systems Theory]], [[Policy-Surveillance|Policy-Surveillance]], [[Ethics & AI|Ethics & AI]], [[Decision Theory|Decision Theory]]
- **Modern Tech/Tools**: Recidivism Prediction AI (COMPAS - 윤리 논란 포함), VR rehabilitation training.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Public APIs.md
+78 -4
View File
@@ -1,18 +1,92 @@
---
id: wiki-2026-0508-public-apis
title: Public APIs
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
---
# [[Public APIs|Public APIs]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
프론트엔드 아키텍처 및 컴포넌트 라이브러리 설계에서 퍼블릭 API(Public APIs)는 컴포넌트나 패키지가 외부와 상호작용하기 위해 노출하는 명시적인 계약이자 안정적인 진입점(entry point)을 의미합니다 [1, 2]. 이는 컴포넌트가 받는 속성(props)과 반환하는 이벤트(callbacks)를 정의하며, 내부 구현 세부 사항을 캡슐화합니다 [2]. 명확한 퍼블릭 API를 강제하는 것은 패키지 간의 무분별한 참조를 방지하고, 변화하는 요구사항 속에서도 안전하게 확장 가능한 UI를 구축하는 데 필수적입니다 [3, 4].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **컴포넌트 API 설계의 중요성:** 재사용 가능한 UI를 구축하는 것은 단순히 코드를 적게 작성하는 것이 아니라, 지속적인 변화에서 살아남을 수 있는 API를 설계하는 것입니다 [3]. 좋은 컴포넌트 API는 직관적이고 오용하기 어려워야 하며, 최소한의 속성(props)만 노출해야 합니다 [5]. 이는 컴포넌트가 무엇을 받아들이고, 무엇을 반환하며, 절대 하지 말아야 할 행동(예: 부모 상태 변이)을 규정하는 명시적 계약(Explicit Contracts) 역할을 수행합니다 [2].
* **모노레포와 패키지 경계 관리:** 대규모 모노레포 환경에서는 모듈성 유지를 위해 엄격한 퍼블릭 API 노출이 필요합니다 [1, 4]. 소비자는 내부의 깊은 경로(예: `import Button from "@acme/ui/src/button/Button"`)가 아닌, 의도적으로 노출된 안정적인 진입점(예: `import { Button } from "@acme/ui"`)을 통해서만 모듈을 가져와야 합니다 [4]. 이를 강제하기 위해 패키지의 `package.json`에서 `exports` 필드를 정의하거나 [[ESLint|ESLint]] 규칙을 적용하여 딥 임포트(deep imports)를 차단해야 합니다 [4, 6].
* **FSD([[Feature-Sliced Design|Feature-Sliced Design]])와의 통합:** 확장 가능한 프론트엔드 아키텍처 방법론인 FSD는 슬라이스(slice) 경계에서 명시적인 퍼블릭 API 사용을 권장합니다 [7]. 애플리케이션은 공유 패키지나 슬라이스의 `index.ts` 같은 퍼블릭 API 파일을 통해서만 임포트하고, 내부 파일은 철저히 내부에 유지되도록 설계함으로써 의도치 않은 결합(accidental coupling)을 크게 줄일 수 있습니다 [7, 8].
* **거버넌스 및 브레이킹 체인지 방지:** 여러 앱에서 사용되는 공유 패키지(예: `packages/ui`)의 퍼블릭 API가 변경될 경우 파급 효과가 크므로, 예측 불가능한 시스템 중단을 막기 위해 엄격한 관리가 필요합니다 [9, 10]. `CODEOWNERS` 등을 이용해 소유권을 명확히 하고, 공유 모듈의 퍼블릭 API에 변경 사항이 있을 때는 반드시 코드 리뷰를 요구하는 정책을 수립해야 합니다 [9, 10].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Component API Design|Component API Design]], Monorepo Architecture, [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]], Explicit Contracts
- **Projects/Contexts:** 대규모 리액트 애플리케이션의 모노레포 구축(Nx/[[Turborepo|Turborepo]]), 확장 가능하고 유지보수 용이한 재사용 UI 컴포넌트 라이브러리 설계
- **Contradictions/Notes:** 컴포넌트 내부의 복잡성은 숨기고 외부로는 단순하고 일관된 진입점을 제공해야 한다는 원칙은, 단일 컴포넌트 설계와 대규모 패키지 구조 설계 양쪽 모두에 공통적으로 핵심적인 지침으로 강조됩니다 [2, 4].
---
*Last updated: 2026-04-26*
*Last updated: 2026-04-26*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧪 검증 상태 (Validation)
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Rapid-Prototyping.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-RAPP-001
category: Unified
id: wiki-2026-0508-rapid-prototyping
title: Rapid Prototyping
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-RAPP-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-reinforced, rapid-[[Prototyping|Prototyping]], [[Iteration|Iteration]], mvp, speed-to-market, validation]
tags: [auto-reinforced, rapid-Prototyping, Iteration, mvp, speed-to-market, validation]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Rapid-Prototyping|Rapid-Prototyping]]
@@ -21,7 +33,7 @@ last_reinforced: 2026-04-20
2. **왜 중요한가?**:
* 시장의 변화 속도가 기술의 개발 속도보다 빠를 때, 완벽한 제품보다 '빠른 학습 정책'이 성공의 결정적 요인 정책이 되기 때문임. ([[Innovation|Innovation]]과 연결)
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거에는 하드웨어 제작에 한정된 개념이었으나, 현대 정책은 소프트웨어, 비즈니스 모델, 심지어 지식 구축 정책(`P-Reinforce`) 전반으로 확산됨(RL Update).
- **정책 변화(RL Update)**: "Done is better than perfect(완벽보다 완료가 낫다)"라는 철학 정책을 실천하는 가장 강력한 수단 정책이며, AI 에이전트가 단 몇 분 만에 앱 개발 정책을 끝내는 ‘에이전틱 래피드 프로토타이핑 정책’ 시대로 진화 중임. (Prototyping와 맥락 공유)
@@ -29,3 +41,52 @@ last_reinforced: 2026-04-20
- [[Prototyping|Prototyping]], [[Lean-Operations|Lean-Operations]], [[Pareto-Principle|Pareto-Principle]], [[Innovation|Innovation]], [[Minimal-Viable-Product|Minimal-Viable-Product]]
- **Modern Tech/Tools**: [[Figma|Figma]], Vercel (v0), Replit, 3D Printers.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Relational Algebra in Databases.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-DBRA-001
category: Unified
id: wiki-2026-0508-relational-algebra-in-databases
title: Relational Algebra in Databases
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-DBRA-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.96
tags: [auto-reinforced, database, relational-algebra, mathematics, [[Logic|Logic]]]
tags: [auto-reinforced, database, relational-algebra, mathematics, Logic]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Relational Algebra in Databases|Relational Algebra in Databases]]
@@ -28,7 +40,7 @@ last_reinforced: 2026-04-20
* 선언적인 SQL 문은 내부적으로 관계 대수식으로 변환됨.
* **Query Transformation**: 동일한 결과를 내면서 비용이 낮은 대수식(예: 조인 전 선택)으로 변환하는 과정이 옵티마이저의 핵심 논리임.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 과거에는 관계 대수 자체가 DB 학문의 전부였으나, 현대에는 NoSQL의 대두와 함께 그래프 대수(Graph Algebra)나 비정형 데이터 연산자로 지평이 넓어짐. 하지만 엄밀한 데이터 정합성이 요구되는 시스템 구축 정책상 관계 대수는 여전히 '절대 법칙'으로 군림함.
- **정책 변화(RL Update)**: 빅데이터 환경 등에서 분산 처리를 위해 관계 대수의 연산 순서를 자동으로 재배치하는 'Dynamic Execution Plan' 정책이 클라우드 DB 서비스의 필수 역량으로 자리 잡음.
@@ -36,3 +48,52 @@ last_reinforced: 2026-04-20
- [[Query-Optimization|Query-Optimization]], [[Principles-of-Data-Connect|Principles-of-Data-Connect]], [[Logic|Logic]], [[Complexity Theory|Complexity Theory]]
- **Modern Tech/Tools**: SQL Engine Optimizers, Codd's Relational Model.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Render State.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-6A1728
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-render-state
title: Render State
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-6A1728]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - Render [[State|State]]"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Render State|Render State]]
@@ -20,7 +31,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Render [[State|State]]"
2. **드로우 콜 구성 최적화:** 그래픽 API가 여러 드로우 콜을 수행할 때 동일한 렌더 상태를 유지할 수 있도록 드로우 콜을 효율적으로 구성하면, 드로우 콜을 그룹화하여 잦은 렌더 상태 변경을 방지할 수 있습니다 [3].
- **최적화의 이점:** 렌더 상태 변경과 드로우 콜을 최적화하면 일차적으로 프레임 렌더링 시간이 향상됩니다 [4]. 또한, 애플리케이션의 전력 소비를 줄여 배터리 소모와 기기 발열을 감소시킬 수 있으며, 이후 프로젝트에 더 많은 오브젝트(GameObject)를 추가하더라도 큰 성능 저하를 방지하여 장기적인 유지보수성을 높여줍니다 [4].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -33,3 +44,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Render [[State|State]]"
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Restorative Justice.md
+65 -4
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-REJU-001
category: Unified
id: wiki-2026-0508-restorative-justice
title: Restorative Justice
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-REJU-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.93
tags: [auto-reinforced, law, sociology, justice, conflict-re[[Solution|Solution]], comm[[Unity|Unity]]]
tags: [auto-reinforced, law, sociology, justice, conflict-reSolution, commUnity]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Restorative Justice|Restorative Justice]]
@@ -25,7 +37,7 @@ last_reinforced: 2026-04-20
3. **효과**:
* 가해자의 진심 어린 사과 유도 및 재범률 급감, 피해자의 심리적 종결(Closure) 및 트라우마 극복 기여.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 이전에는 "범죄자에게 면죄부를 주는 유약한 방식"이라는 비판이 있었으나, 현대 통계 데이터는 가혹한 처벌(Retributive Justice)보다 회복적 정의가 가해자의 삶을 실제로 변화시키고 공동체를 안전하게 만드는 데 훨씬 효율적임을 증명함.
- **정책 변화(RL Update)**: 학교 폭력이나 경미한 형사 사건에서 형사 처벌 대신 '회복적 생활 교육'과 '중재 상담'을 필수 단계로 도입하는 교육 및 법무 정책 개편이 전 세계적으로 추진 중임.
@@ -33,3 +45,52 @@ last_reinforced: 2026-04-20
- [[Prisons-and-Self-Correction|Prisons-and-Self-Correction]], [[Ethics & AI|Ethics & AI]], Social[[Systems Theory|systems Theory]], [[Organizational Psychology|Organizational Psychology]], Conflict-Resolution-Mechanisms
- **Modern Tech/Tools**: Restorative justice portals, Community mediation centers.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/S-component (State Store).md
+73 -5
View File
@@ -1,9 +1,29 @@
---
id: wiki-2026-0508-s-component-state-store
title: S component (State Store)
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
---
# [[S-component (State Store)|S-component (State Store)]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
S-component(State Store)는 에이전트 하네스의 '기억'을 담당하는 물리적/논리적 저장소 계층이다. 에이전트의 현재 작업 상태, 과거 대화 이력, 추출된 지식, 그리고 영구적으로 보존해야 할 사용자 선호도를 저장하고 관리한다. 단순한 데이터베이스를 넘어, 에이전트가 시간이 지남에 따라 학습하고 진화할 수 있는 토대를 제공한다.
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **다층 저장 구조**:
* **단기 상태 (Short-term)**: 현재 세션의 휘발성 데이터 및 즉각적인 작업 맥락 보존.
* **영구 상태 (Long-term)**: 세션을 넘어 지속되는 사용자 프로필, 프로젝트 규칙, 자가 학습된 지식 저장.
@@ -13,13 +33,12 @@ S-component(State Store)는 에이전트 하네스의 '기억'을 담당하는
* **메모리 거버넌스**: 정보의 유효 기간(TTL)을 설정하여 오래된 정보를 자동으로 삭제하거나, 중요도가 낮은 데이터를 요약하여 저장 공간을 최적화(Compaction)한다.
* **보안 및 암호화**: 저장된 메모리에 포함된 민감한 사용자 데이터나 시스템 비밀번호 등을 암호화하여 외부 유출을 방지한다.
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **검색 정확도 vs 속도**: 저장된 데이터가 방대해질수록 관련 정보를 찾는 데 더 많은 시간과 컴퓨팅 자원이 소모된다.
* **데이터 오염 (Memory Poisoning)**: 잘못된 정보가 S-component에 기록되면 이후 에이전트의 모든 판단에 악영향을 미치는 '영구적 지능 저하'가 발생할 수 있다.
* **개인정보 보호**: 에이전트가 사용자의 모든 행동을 기억하게 될 때 발생하는 프라이버시 침해 리스크를 관리해야 한다.
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
* [[Agent Memory System|Agent Memory System]]
* 연결 이유: S-component가 실질적으로 구현하는 논리적 시스템이다.
@@ -39,3 +58,52 @@ S-component(State Store)는 에이전트 하네스의 '기억'을 담당하는
---
*Last updated: 2026-05-01*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Serverless_Computing.md
+70 -10
View File
@@ -1,17 +1,29 @@
---
category: Unified
tags: [auto-wikified, technical-documentation]
id: wiki-2026-0508-serverless-computing
title: Serverless Computing
description: "서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버 인프라를 직접 프로비저닝하거나 관리할 필요 없이, 코드를 함수(Function) 형태로 배포하고 필요할 때만 온디맨드(on-demand)로 실행하는 클라우드 컴퓨팅 실행 모델이다[1, 2]."
last_updated: 2026-05-02
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
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
---
# Serverless Computing
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버 인프라를 직접 프로비저닝하거나 관리할 필요 없이, 코드를 함수(Function) 형태로 배포하고 필요할 때만 온디맨드(on-demand)로 실행하는 클라우드 컴퓨팅 실행 모델이다[1, 2]. 대표적으로 AWS Lambda, Azure Functions, Google Cloud Run과 같은 서비스가 있으며, HTTP 요청이나 데이터베이스 업데이트 등의 이벤트에 의해 트리거되어 자동으로 확장 및 축소된다[2, 3]. 사용한 컴퓨팅 리소스에 대해서만 비용을 지불하는 구조로 유휴 자원을 최소화하며, 운영 오버헤드를 줄이고 지속 가능한 코딩 관행을 실천하는 데 기여하는 핵심 클라우드 네이티브 기술이다[2, 4, 5].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **실행 모델 및 자원 관리 (FaaS):**
서버리스는 FaaS(Function-as-a-Service) 모델을 채택하여 개발자가 애플리케이션의 핵심 비즈니스 로직 작성에만 집중할 수 있게 해준다[1]. 인프라 확장, 자원 할당, 시스템 유지보수는 클라우드 제공자가 전담하므로, 트래픽 변화에 맞춰 자동으로 자원이 스케일링(Automatic scalability)되며 사용하지 않을 때는 유휴 상태로 전환되어 자원 낭비가 없다[1, 2, 4].
* **프레임워크별 성능과 아키텍처 특성:**
@@ -21,13 +33,12 @@ last_updated: 2026-05-02
* **현대 애플리케이션 아키텍처와의 연계:**
서버리스 컴퓨팅은 JAMstack 아키텍처에서 백엔드 동적 프로그래밍을 처리하는 API 및 JavaScript 런타임 환경으로 통합되거나[14], 모놀리식 애플리케이션을 마이크로서비스로 분해하여 독립적으로 확장 가능하게 만드는 데 적극적으로 도입되고 있다[3, 5].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **콜드 스타트(Cold Starts) 지연:** 일정 기간 사용되지 않아 유휴 상태였던 함수가 다시 호출될 때, 클라우드 플랫폼이 런타임 환경을 초기화하면서 발생하는 추가적인 지연 시간이다[4]. 지연 시간에 민감한 애플리케이션에서는 큰 단점으로 작용하며, 프레임워크의 계층이 두껍고 무거울수록(예: NestJS) 이 지연 시간이 길어진다[4, 8, 15].
* **무상태성(Stateless) 및 리소스 통제 한계:** 실행 환경이 일시적이고 클라우드 제공자에 의해 동적으로 생성 및 소멸되므로, 기본적으로 내부 상태를 유지할 수 없으며 기반 하드웨어 리소스에 대한 직접적인 제어권이 줄어든다[4, 16].
* **실행 시간 및 동시성 제약:** 클라우드 제공자의 플랫폼 정책에 따라 단일 함수의 최대 실행 시간이 제한되어 있어 장기 실행 작업에는 부적합할 수 있다[4]. 또한 극심한 고부하(Heavy load) 상황에서는 프레임워크 자체의 처리 능력을 떠나, 플랫폼의 스로틀링이나 확장 지연으로 인한 DNS 오류 및 타임아웃 등의 플랫폼 한계에 직면할 수 있다[17, 18].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [관계 유형 A: 아키텍처/기반 기술]
@@ -70,4 +81,53 @@ last_updated: 2026-05-02
- 확장 방향: 글로벌 지연 시간을 줄이기 위해 사용자에게 가장 물리적으로 가까운 엣지(Edge) 노드에서 서버리스 함수를 실행하는 패턴 및 콘텐츠 전송 네트워크(CDN) 통합 최적화 모델에 대해 깊이 있게 탐구할 수 있다.
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/SharedArrayBuffer와 Atomics 구체적 활용법.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-0A2C98
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-sharedarraybuffer와-atomics-구체적-활
title: SharedArrayBuffer와 Atomics 구체적 활용법
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-0A2C98]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - SharedArrayBuffer와 Atomics 구체적 활용법"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[SharedArrayBuffer와 Atomics 구체적 활용법|SharedArrayBuffer와 Atomics 구체적 활용법]]
@@ -56,7 +67,7 @@ Atomics.store(sharedArray, 3, 1); // 값을 1로 변경하고 상태 업데이
Atomics.notify(sharedArray, 3, 1); // 인덱스 3에서 대기 중인 스레드 1개를 깨움
```
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -70,3 +81,52 @@ Atomics.notify(sharedArray, 3, 1); // 인덱스 3에서 대기 중인 스레드
_Last updated: 2026-04-14_
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Side-channel Attack.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-624D09
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-side-channel-attack
title: Side channel Attack
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-624D09]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - Side-channel Attack"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Side-channel Attack|Side-channel Attack]]
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Side-channel Attack"
- **GPU 및 그래픽 파이프라인에서의 위협:** `EXT_disjoint_timer_query`나 [[WebGPU|WebGPU]] 타임스탬프 쿼리(Timestamp Queries)와 같이 GPU 명령어의 실행 시간을 나노초 단위로 정밀하게 측정할 수 있는 기능 역시 캐시 부채널 공격의 표적이 되었습니다 [4, 10, 11]. 과거 WebGL에서는 고정밀 타임스탬프를 이용해 캐시 미스율을 파악하고, GPU의 물리적 메모리 구조를 알아내어 [[Rowhammer|Rowhammer]] 공격을 실행해 페이지 테이블을 조작하는 심각한 공격 사례가 보고되기도 했습니다 [12].
- **브라우저의 방어 메커니즘 (Mitigations):** 캐시 타이밍 부채널 공격을 방어하기 위해 [[WebKit|WebKit]], Blink 등 브라우저 엔진은 다층적 방어 체계를 도입했습니다 [6, 13]. 가장 핵심적인 조치는 타이머의 정밀도를 의도적으로 낮추는 양자화(Quantization)와 조대화(Coarsening)입니다 [4, 13-15]. `performance.now()` 등의 해상도를 1ms나 100 마이크로초 단위로 제한하고, 통계적 평균화를 통해 정밀한 시간을 재구성하지 못하도록 반환 시간에 임의의 변동성인 '지터(jitter)'를 추가하기도 합니다 [13, 14, 16]. 또한, 고해상도 타이머 생성에 악용될 수 있는 `SharedArrayBuffer`를 비활성화하는 조치도 취해졌습니다 [13, 16]. 나아가, 분기문 자체가 취약점이 되는 것을 막기 위해 인덱스 마스킹([[Index Masking|Index Masking]])과 포인터 포이즈닝(Pointer Poisoning) 같은 '분기 없는 보안 검사([[Branchless Security Checks|Branchless Security Checks]])' 메커니즘으로 전환하고 있습니다 [6, 7, 16, 17].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Side-channel Attack"
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Slack-Bot-Development.md
+64 -3
View File
@@ -1,9 +1,21 @@
---
id: DEV-SLACK-BOT-001
category: Unified
id: wiki-2026-0508-slack-bot-development
title: Slack Bot Development
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [DEV-SLACK-BOT-001]
duplicate_of: none
source_trust_level: A
confidence_score: 1.0
tags: [development, automation, slack, chatbot, slack-api, webhook, bot-development, collaboration]
raw_sources: []
last_reinforced: 2026-04-26
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# Slack Bot Development (슬랙 봇 개발)
@@ -20,10 +32,59 @@ last_reinforced: 2026-04-26
- **Slash Commands:** `/`로 시작하는 명령어를 통한 서비스 호출.
- **의의:** 알림 모니터링, 승인 프로세스 자동화, 사내 데이터 조회 등 파편화된 업무 툴들을 채팅창 안으로 통합하여 소통 비용을 획기적으로 절감함.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 단순히 메시지만 주고받던 초기 형태에서 벗어나, 이제는 거대 언어 모델(LLM)과 결합하여 복잡한 질문에 답하고 코드를 작성하거나 회의록을 요약해주는 'AI 비서' 수준의 지능형 봇으로 진화함.
- **정책 변화:** Antigravity 프로젝트는 가드닝 진행 상황 및 장애 알림을 실시간으로 팀에 공유하기 위해, 프로젝트 전용 슬랙 봇을 구축하여 운영 효율을 극대화함.
## 🔗 지식 연결 (Graph)
- [[Process-Automation-with-AI|Process-Automation-with-AI]], [[Natural-Language-Processing|Natural-Language-[[Processing]]-NLP]], API-Design-[[Principles|Principles]], [[Shadowing-and-Observability|Shadowing-and-Observability]]
- **Raw Source:** 10_Wiki/Topics/AI/Slack-Bot-Development.md
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Snowflake-Data-Warehousing.md
+21 -24
View File
@@ -1,28 +1,25 @@
---
id: SYS-DATA-WARE-001
category: Unified
confidence_score: 1.0
tags: [database, data-warehouse, snowflake, cloud-computing, [[Big-Data|Big-Data]], data-analytics, [[SaaS|SaaS]]]
last_reinforced: 2026-04-26
id: wiki-2026-0508-snowflake-data-warehousing
title: Snowflake Data Warehousing
category: 10_Wiki/Topics
status: merged
redirect_to: 데이터_엔지니어링_및_가상_인프라_표준
canonical_id: wiki-2026-0508-001
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
---
# Snowflake Data Warehousing (스노우플레이크 데이터 웨어하우징)
# Redirect
## 📌 한 줄 통찰 (The Karpathy Summary)
> "저장과 연산을 분리하여 무한한 확장성을 확보하고, 복잡한 인프라 관리 없이 오직 '데이터의 가치'를 캐내는 분석에만 전념하라" — 클라우드 네이티브 아키텍처를 기반으로 설계된 완전 관리형(SaaS) 데이터 웨어하우징 서비스.
## 📖 구조화된 지식 (Synthesized Content)
- **추출된 패턴:** "Separation of [[Storage|Storage]] and Compute with Multi-cluster Shared Data" — 데이터를 중앙 집중식 스토리지에 저장하되, 여러 개의 가상 웨어하우스(연산 엔진)가 이를 동시에 참조하며 독립적으로 자원을 사용하고 자동 확장(Auto-scaling)하는 패턴.
- **핵심 아키텍처 3계층:**
- **Database Storage:** 열 지향(Columnar) 방식으로 압축 저장되어 성능 최적화.
- **Query [[Processing|Processing]]:** 독립적인 가상 웨어하우스들이 연산 수행. 서로 간섭 없음.
- **Cloud Services:** 인증, 메타데이터 관리, 쿼리 최적화 등을 담당하는 뇌의 역할.
- **의의:** 정형/반정형 데이터를 통합 관리하고 전 세계 어디서나 실시간으로 데이터를 공유(Data Sharing)할 수 있게 함으로써, 현대 기업의 데이터 민주화와 분석 속도를 획기적으로 향상시킴.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 초기에는 단순히 데이터 저장소로 여겨졌으나, 최근에는 'Snowpark'를 통해 파이썬, 자바 등 개발 언어로 데이터 파이프라인을 구축하고 ML 모델을 직접 실행하는 '데이터 클라우드' 플랫폼으로 진화함.
- **정책 변화:** Antigravity 프로젝트는 에이전트의 대규모 지식 활용 로그 및 사용자 행동 패턴을 장기간 보관하고 대규모 배치 분석을 수행할 때, 연산 자원 관리가 용이한 스노우플레이크의 아키텍처 철학을 참고하여 분석 파이프라인을 설계함.
## 🔗 지식 연결 (Graph)
- [[Relational-Databases|Relational-Databases]], NoSQL-Databases, [[Scalability-in-AI-Systems|Scalability-in-AI-Systems]], [[Process-Automation-with-AI|Process-Automation-with-AI]]
- **Raw Source:** 10_Wiki/Topics/AI/Snowflake-Data-Warehousing.md
이 문서는 Canonical 문서인 [[데이터_엔지니어링_및_가상_인프라_표준]]으로 통합되었습니다.
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
10_Wiki/Topics/Backend/Solow Growth Model.md
+64 -3
View File
@@ -1,9 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-SOGM-001
category: Unified
id: wiki-2026-0508-solow-growth-model
title: Solow Growth Model
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-SOGM-001]
duplicate_of: none
source_trust_level: A
confidence_score: 0.96
tags: [auto-reinforced, economics, solow-model, economic-growth, capital-accumulation]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Solow Growth Model|Solow Growth Model]]
@@ -23,7 +35,7 @@ last_reinforced: 2026-04-20
3. **의의**:
* 저축률을 높이는 것보다 교육과 R&D를 통해 기술($A$)을 혁신하는 것이 진정한 국가 성장의 열쇠임을 입증.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 초기 솔로우 모델은 기술 진보($A$)를 설명할 수 없는 '외생적' 변수로 보았으나, 현대 경제 정책은 지식과 교육이 자발적으로 기술을 만든다는 '내생적 성장 이론(Romer 등)'으로 확장하여 정책을 수립함(RL Update).
- **정책 변화(RL Update)**: 단순히 공장을 짓는 원조 중심 정책에서 벗어나, 개도국의 '지식 자산화'와 '디지털 인프라'를 강화하여 솔로우 모델의 핵심 성장을 자극하는 글로벌 경제 지원 정책으로 패러다임이 이동함.
@@ -31,3 +43,52 @@ last_reinforced: 2026-04-20
- [[Quantitative Economics (수량경제학)|Quantitative Economics (수량경제학)]], Economic Models, [[Resource-Management|Resource-Management]], [[Operations-Research|Operations-Research]], Foundational Models
- **Modern Tech/Tools**: GDP modeling, Total Factor Productivity (TFP) calculation.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Static Analysis & Linting (정적 분석 및 린팅).md
+18 -2
View File
@@ -1,6 +1,22 @@
---
id: static_analysis_linting_redirect
redirect: [[SAST]]
id: wiki-2026-0508-static-analysis-linting-정적-분석-및-
title: "Static Analysis & Linting (정적 분석 및 린팅)"
category: 10_Wiki/Topics
status: merged
redirect_to: SAST
canonical_id: SAST
aliases: [static_analysis_linting_redirect]
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
---
# Redirect
10_Wiki/Topics/Backend/System_Debugging_Protocol.md
+89 -3
View File
@@ -1,8 +1,21 @@
---
title: 단계별 시스템 디버깅 체크리스트 (L1~L3)
category: Unified
id: wiki-2026-0508-system-debugging-protocol
title: System Debugging Protocol
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [Debugging, Troubleshooting, Checklist, Process]
created: 2026-04-20
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
---
# 단계별 시스템 디버깅 체크리스트 (The Diagnostic Flowchart)
@@ -25,3 +38,76 @@ created: 2026-04-20
## 🔗 연결된 지식
- [[Tetris_Project_Retrospective|Tetris_Project_Retrospective]]
- [[DevOps_Environment_Setup|DevOps_Environment_Setup]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/T-component (Tool Registry).md
+73 -5
View File
@@ -1,22 +1,41 @@
---
id: wiki-2026-0508-t-component-tool-registry
title: T component (Tool Registry)
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
---
# [[T-component (Tool Registry)|T-component (Tool Registry)]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
T-component(Tool Registry)는 에이전트 하네스의 '손과 발'에 해당하는 구성 요소로, 에이전트가 외부 세계와 상호작용하기 위해 사용할 수 있는 모든 도구(함수, API, 스크립트)를 등록, 관리, 실행하는 책임을 진다. 모델이 도구의 기능을 이해할 수 있도록 명세를 제공하고, 모델의 실행 요청을 실제 코드 호출로 변환하는 가교 역할을 한다.
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **도구 명세 관리 (Tool Definitions)**: 모델이 어떤 상황에서 어떤 도구를 써야 할지 알 수 있도록 도구의 이름, 설명, 파라미터 스키마를 정의하고 공급한다.
* **실행 프로토콜 표준화 (MCP)**: 서로 다른 언어나 환경으로 작성된 도구들을 일관된 방식으로 호출하기 위해 **MCP(Model Context Protocol)**와 같은 표준 프로토콜을 사용한다.
* **권한 및 가이딩 (Guarding)**: 특정 에이전트나 작업 세션이 사용할 수 있는 도구의 범위를 제한하고, 민감한 도구 호출 시 승인 게이트를 트리거한다.
* **결과 파싱 및 피드백**: 도구 실행 결과(성공 데이터, 에러 로그)를 모델이 이해할 수 있는 형식으로 정제하여 전달한다.
* **동적 로딩 및 확장성**: 하네스 코드를 수정하지 않고도 새로운 도구 서버를 추가하거나 외부 API를 연동할 수 있는 플러그인 아키텍처를 제공한다.
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **스키마 복잡성**: 도구 명세가 너무 복잡하면 모델이 파라미터를 잘못 생성할 확률이 높아진다.
* **보안 리스크 (Excessive Agency)**: 도구 레지스트리에 강력한 권한을 가진 도구(예: 셸 실행)가 포함되어 있을 경우, 프롬프트 인젝션을 통한 시스템 장악 위험이 있다.
* **의존성 지옥**: 수많은 외부 API와 라이브러리에 의존하는 도구들의 버전 관리와 안정성을 유지하는 것은 어려운 운영 과제이다.
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
* [[MCP (Model Context Protocol)|MCP (Model Context Protocol)]]
* 연결 이유: T-component가 도구를 등록하고 실행하는 실질적인 기술 표준이다.
@@ -36,3 +55,52 @@ T-component(Tool Registry)는 에이전트 하네스의 '손과 발'에 해당
---
*Last updated: 2026-05-01*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Unity.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-6033D2
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-unity
title: Unity
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-6033D2]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - Unity"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Unity|Unity]]
@@ -29,7 +40,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Unity"
- **외부 도구와의 연동**
[[Needle Engine|Needle Engine]]과 같은 도구와 함께 사용될 때, 성능 문제나 텍스처 누락 등을 해결하기 위해 Unity 환경 내에서 "Copy Project Info Into [[CLIP|CLIP]]board" 기능을 사용하여 특정 설정 상태를 외부로 복사하고 디버깅할 수 있습니다 [8].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
@@ -42,3 +53,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Unity"
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/WebHooks_and_Notifications.md
+79 -9
View File
@@ -1,17 +1,20 @@
---
id: P-REINFORCE-WIKI-DEV-WEBHOOKS
title: "WebHook과 이벤트 기반 알림 체계 (WebHooks & Notifications)"
category: Unified
id: wiki-2026-0508-webhooks-and-notifications
title: WebHooks and Notifications
category: 10_Wiki/Topics
status: verified
canonical_id: ""
aliases: ["WebHook", "웹훅", "이벤트 알림", "HTTP Callback", "비동기 푸시"]
duplicate_of: ""
canonical_id: self
aliases: [P-REINFORCE-WIKI-DEV-WEBHOOKS, WebHook, 웹훅, 이벤트 알림, HTTP Callback, 비동기 푸시]
duplicate_of: none
source_trust_level: A
confidence_score: 1.0
tags: ["API", "WebHook", "Events", "Integration", "Automation"]
raw_sources: ["Datacollector_Export_2026-05-02"]
tags: [API, WebHook, Events, Integration, Automation]
raw_sources: [Datacollector_Export_2026-05-02]
last_reinforced: 2026-05-02
github_commit: ""
github_commit: pending
tech_stack:
language: unspecified
framework: unspecified
---
# [[WebHook과 이벤트 기반 알림 체계 (WebHooks & Notifications)]]
@@ -44,3 +47,70 @@ WebHook(웹훅)은 한 서비스가 다른 서비스로 특정 이벤트가 발
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 시스템 간의 비동기적이고 효율적인 이벤트 전달을 통해 자동화된 워크플로우를 구축하고 실시간 반응성을 확보하기 위한 웹훅 기반 알림 표준 정립.
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (Synthesized Content)
**추출된 패턴:**
> *(TODO)*
**세부 내용:**
- *(TODO)*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/WebSockets_and_Realtime.md
+79 -9
View File
@@ -1,17 +1,20 @@
---
id: P-REINFORCE-WIKI-DEV-WEBSOCKETS
title: "WebSocket과 실시간 양방향 통신 (WebSockets & Real-time)"
category: Unified
id: wiki-2026-0508-websockets-and-realtime
title: WebSockets and Realtime
category: 10_Wiki/Topics
status: verified
canonical_id: ""
aliases: ["WebSocket", "WebSockets", "실시간 통신", "양방향 통신", "Socket.io", "Full-duplex"]
duplicate_of: ""
canonical_id: self
aliases: [P-REINFORCE-WIKI-DEV-WEBSOCKETS, WebSocket, WebSockets, 실시간 통신, 양방향 통신, Socket.io, Full-duplex]
duplicate_of: none
source_trust_level: A
confidence_score: 1.0
tags: ["API", "WebSocket", "Real-time", "Communication", "Event-Driven"]
raw_sources: ["Datacollector_Export_2026-05-02"]
tags: [API, WebSocket, Real-time, Communication, Event-Driven]
raw_sources: [Datacollector_Export_2026-05-02]
last_reinforced: 2026-05-02
github_commit: ""
github_commit: pending
tech_stack:
language: unspecified
framework: unspecified
---
# [[WebSocket과 실시간 양방향 통신 (WebSockets & Real-time)]]
@@ -45,3 +48,70 @@ WebSocket은 단일 TCP 연결을 통해 클라이언트와 서버 간의 영구
- **정보 상태**: 검증 완료 (Verified)
- **출처 신뢰도**: A
- **검토 이유**: 지연 없는 실시간 데이터 교환을 통해 풍부한 사용자 상호작용과 기민한 시스템 반응성을 확보하기 위한 WebSocket 프로토콜 및 실시간 통신 표준 정립.
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (Synthesized Content)
**추출된 패턴:**
> *(TODO)*
**세부 내용:**
- *(TODO)*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Zen-Pop.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: 550e8400-e29b-41d4-a716-446655440002
category: Unified
id: wiki-2026-0508-zen-pop
title: Zen Pop
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [550e8400-e29b-41d4-a716-446655440002]
duplicate_of: none
source_trust_level: A
confidence_score: 0.98
tags: [ASMR, Healing, MediaPipe, Web Audio, Zen-Pop]
raw_sources: []
last_reinforced: 2026-04-21
github_commit: "initial"
github_commit: initial
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Zen-Pop|Zen-Pop]]
@@ -19,10 +30,59 @@ github_commit: "initial"
- **Sensory Experience**: Web Audio API의 `AudioContext`와 피치 모듈레이션을 통한 유기적인 ASMR 효과음 생성.
- **Dynamic Ambience**: 날씨 및 위치 정보를 연동하여 실시간으로 변하는 테마 및 사운드스케이프 제공.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌**: 단순 동영상 기반 ASMR의 수동적 한계를 넘어서, 직접 만지고 반응하는 상호작용형 힐링 서비스로 진화.
## 🔗 지식 연결 (Graph)
- **Parent**: Agent Ecosystem
- **Related**: NUI [[Architecture|Architecture]], Sensory Tokens
- **Raw Source**: 00_Raw/2026-04-21-Zen-Pop_Architect_Info
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/Zustand-Based-Mission-Persistence.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-E45B33
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-zustand-based-mission-persistenc
title: Zustand Based Mission Persistence
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-E45B33]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - Zustand-Based-Mission-Persistence"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[Zustand-Based-Mission-Persistence|Zustand-Based-Mission-Persistence]]
@@ -25,7 +36,7 @@ github_commit: "[P-Reinforce] Continuous Worker - Zustand-Based-Mission-Persiste
이 아키텍처는 에이전트가 단순한 '스크립트'가 아닌, 실제 워크스테이션에서 구동되는 '전문 소프트웨어'로서의 안정성을 갖추게 했습니다.
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -35,3 +46,52 @@ github_commit: "[P-Reinforce] Continuous Worker - Zustand-Based-Mission-Persiste
- **Contradictions/Notes:** 로컬 스토리지의 용량 제한(약 5MB)에 유의해야 하며, 큐가 수만 개로 늘어날 경우 별도의 DB 연동을 고려해야 합니다.
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/_brief.md
+87 -1
View File
@@ -1,3 +1,23 @@
---
id: wiki-2026-0508-brief
title: brief
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
---
# 📋 작업 브리프
**원 명령:** [자율 사이클 — 2026-05-01] 1인 기업 24시간 운영 중. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/goal.md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
@@ -10,10 +30,76 @@ Deep Value Bundle의 기능적 우월성을 입증하기 위한 초기 테스트
- **💰 Business**: 측정할 핵심 지표(AO, TTV)에 대한 구체적인 정의와 초기 테스트 시나리오(Test Scenario)를 설계하고, 각 지표가 수익화 전략에 미치는 영향을 분석하여 보고서 초안을 작성하세요.
- **💻 Developer**: 설계된 테스트 시나리오를 기반으로, 초기 데이터 수집 및 결과 기록을 위한 API 연동 구조 또는 테스트 환경 구축에 필요한 최소한의 기술적 프레임워크(Mock-up)를 설계하세요.
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts (Auto-Linked)
* [[2026-05-01]]
* [[business]]
* [[developer]]
* [[goal]]
* [[researcher]]
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/comment_harvester.md
+93
View File
@@ -1,3 +1,23 @@
---
id: wiki-2026-0508-comment-harvester
title: comment harvester
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
---
# 💬 댓글 수집기
`[[youtube_account|youtube_account]].json`의 `WATCHED_CHANNELS`에 적은 채널들의 최근 영상에서 인기 댓글을 가져와 YouTube 에이전트의 `[[memory|memory]].md`에 누적 저장합니다. 시청자가 실제로 어떤 단어·반응을 쓰는지가 메모리에 쌓이면, 에이전트가 다음 영상 후크나 제목을 짤 때 그 표현을 자연스럽게 참고하게 됩니다.
@@ -19,3 +39,76 @@
## 어떻게 활용되나?
메모리에 쌓인 댓글을 에이전트가 다음 한 스텝에서 자연스럽게 참고합니다. 직접 보고 싶으면 `memory.md` 또는 같은 폴더의 `comment_harvester_report.md`를 열면 돼요.
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/goal.md
+93
View File
@@ -1,3 +1,23 @@
---
id: wiki-2026-0508-goal
title: goal
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
---
# 🎯 YouTube 에이전트 — 나의 미션
> 🌞 24시간 업무가 켜져 있으면 이 미션을 향해 자동으로 한 스텝씩 일합니다.
@@ -25,3 +45,76 @@
- 추상적 조언 대신 **실행 가능한 산출물** (제목·썸네일 브리프·스크립트 후크)
- 매번 다음 단계 1줄을 명시
- 메모리(`memory.md`)에 누적된 댓글·반응 키워드를 후크에 반영
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/my_videos_check.md
+93
View File
@@ -1,3 +1,23 @@
---
id: wiki-2026-0508-my-videos-check
title: my videos check
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
---
# 🎬 내 영상 체크
본인 채널의 최근 영상이 잘 올라갔는지 한눈에 봅니다. 조회수 중간값을 기준선으로 삼아 떡상/부진 영상을 자동 분류하고, 다음에 뭘 할지 짧은 제안까지 만들어줘요.
@@ -20,3 +40,76 @@
- 콘솔에 영상별 조회수·라이크·댓글 수
- `my_videos_check_report.md`에 누적 저장
- (선택) 텔레그램 알림
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/telegram_notify.md
+93
View File
@@ -1,3 +1,23 @@
---
id: wiki-2026-0508-telegram-notify
title: telegram notify
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
---
# 📨 텔레그램 보고
다른 도구가 보고를 메신저로 보낼 때 호출하는 통신선이에요. 이 도구를 직접 [▶ 실행]하면 **연결 테스트 메시지**를 보냅니다 — 받으면 OK, 안 오면 토큰/chat_id 다시 확인.
@@ -18,3 +38,76 @@
- "내 영상 체크" → 떡상/부진 요약을 자동 푸시
- "경쟁 채널 분석" → 다음 액션 브리프 자동 푸시
- 향후 트렌드 스나이퍼/오토 플래너 결과도 같은 라인을 통해 보냅니다
## 📌 한 줄 통찰 (The Karpathy Summary)
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
## 📖 구조화된 지식 (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 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🔗 지식 연결 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/개발자 경험(DX).md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-C2C2F8
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-개발자-경험-dx
title: 개발자 경험(DX)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-C2C2F8]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 개발자 경험(DX)"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[개발자 경험(DX)|개발자 경험(DX]]
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 개발자 경험(DX)"
- **타입스크립트 환경에서의 DX 향상:** 시스템의 경계(Boundary)에서 데이터를 한 번에 파싱하여 프로그램 흐름 전반에 유효성 검사 로직이 지저분하게 흩어지지 않게 하는 '검증하지 말고 파싱하라(Parse, don't validate)' 원칙 또한 개발자 경험을 크게 개선합니다 [1, 9].
- **DX 개선의 궁극적 효과:** 훌륭한 개발자 경험을 고려한 설계는 단순히 사용성을 높이는 데 그치지 않고, 성능과 안정성을 확보하게 해줍니다 [6]. 나아가 내부 구현이 바뀌더라도 기존 사용자 코드를 보호하여 하위 호환성 파괴(Breaking Change)를 막고, 플랫폼의 지속적인 발전을 가능하게 합니다 [6].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - 개발자 경험(DX)"
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
```
## 🤔 의사결정 기준 (Decision Criteria)
**선택 A를 써야 할 때:**
- *(TODO)*
**선택 B를 써야 할 때:**
- *(TODO)*
**기본값:**
> *(TODO)*
## ❌ 안티패턴 (Anti-Patterns)
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-6271CF
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-넷플릭스의-코스모스-플랫폼-및-마이크로서비스-전환
title: 넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-6271CF]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환|넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환]]
@@ -29,7 +40,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스의 코스모스
* **워크로드 특성에 따른 성능 최적화:**
코스모스 플랫폼은 다수의 서비스를 오케스트레이션하여 워크로드를 관리합니다. 수백만 CPU 시간을 소비하며 장시간 미디어를 처리하는 타파스(Tapas)와 같은 처리량 민감형 서비스와, 사용자의 즉각적인 반응을 처리해야 하는 세이건(Sagan) 같은 지연 시간 민감형 서비스를 모두 지원합니다 [15-18]. 서버리스 계층인 스트라툼은 지연 시간을 단축하기 위해 리소스 풀 활용, 웜(Warm) 용량 사전 대기, 함수 시작 비용을 분산하는 마이크로 배치(Micro-batches) 적용, 그리고 중요도에 따른 우선순위 스케줄링 방식을 도입했습니다 [19].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -42,3 +53,52 @@ github_commit: "[P-Reinforce] Continuous Worker - 넷플릭스의 코스모스
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
```
## 🤔 의사결정 기준 (Decision Criteria)
**선택 A를 써야 할 때:**
- *(TODO)*
**선택 B를 써야 할 때:**
- *(TODO)*
**기본값:**
> *(TODO)*
## ❌ 안티패턴 (Anti-Patterns)
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/대규모 3D 건축 모델(BIM) 시각화.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-750154
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-대규모-3d-건축-모델-bim-시각화
title: 대규모 3D 건축 모델(BIM) 시각화
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-750154]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 대규모 3D 건축 모델(BIM) 시각화"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[대규모 3D 건축 모델(BIM) 시각화|대규모 3D 건축 모델(BIM) 시각화]]
@@ -18,7 +29,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 대규모 3D 건축 모델(BIM
- **WebGPU 및 컴퓨트 셰이더([[Compute Shader|Compute Shader]])의 도입:** 차세대 그래픽 API인 WebGPU는 대규모 BIM 데이터세트를 다루는 데 있어 획기적인 성능 향상을 제공합니다 [5, 14]. 컴퓨트 셰이더를 활용하면 충돌 감지, 실시간 필터링, 물리 시뮬레이션 등 CPU에서 병목을 일으키는 무거운 작업들을 수천 개의 GPU 코어에서 병렬로 처리할 수 있습니다 [5, 14, 15]. 또한, 네이티브 WebGPU의 렌더 번들(`[[GPURenderBundles|GPURenderBundles]]`) 및 간접 그리기(`drawIndexedIndirect`) 기능을 통해 수십만 개의 객체를 효율적으로 렌더링하여 CPU-GPU 동기화 지연을 제거할 수 있습니다 [16, 17].
- **가시성 판별 및 메모리 관리:** 방대한 환경에서는 화면에 보이지 않는 객체를 렌더링에서 제외하기 위해 CPU 단에서 BVH(Bounding Volume Hierarchy)나 옥트리(Octree)와 같은 공간 분할 자료구조를 적용하여 절두체 컬링([[Frustum Culling|Frustum Culling]])을 수행해야 합니다 [18, 19]. 더불어, Z-버퍼만을 먼저 계산하여 가려진 파편(Fragment) 연산을 사전에 폐기하는 뎁스 프리패스([[Depth Pre-Pass|Depth Pre-Pass]]) 기법은 오버드로우를 줄이는 데 유효합니다 [11, 20]. 메모리 관리 측면에서는 웹 워커(Web Worker)와 `SharedArrayBuffer`를 사용하여 메인 스레드 차단 및 메모리의 중복 복사 없이 기하학적 데이터를 디코딩해야 하며, 씬에 변경 사항이 있을 때만 렌더링을 갱신하는 'Render-on-Demand' 방식을 통해 통합 GPU의 과부하 및 발열을 방지해야 합니다 [11, 21, 22].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
@@ -31,3 +42,52 @@ github_commit: "[P-Reinforce] Continuous Worker - 대규모 3D 건축 모델(BIM
*Last updated: 2026-04-19*
---
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/대규모 프론트엔드 웹 프로젝트 폴더 구조화.md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-71F406
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-대규모-프론트엔드-웹-프로젝트-폴더-구조화
title: 대규모 프론트엔드 웹 프로젝트 폴더 구조화
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-71F406]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 대규모 프론트엔드 웹 프로젝트 폴더 구조화"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[대규모 프론트엔드 웹 프로젝트 폴더 구조화|대규모 프론트엔드 웹 프로젝트 폴더 구조화]]
@@ -28,7 +39,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 대규모 프론트엔드 웹
* **마이크로 프론트엔드 (Micro [[Frontend|Frontend]]s) 활용:**
수백 개의 화면과 다양한 기능이 혼재된 아주 거대한 규모의 경우, 모놀리식 프론트엔드를 분해하여 마이크로 프론트엔드 아키텍처를 채택하기도 한다 [12-14]. 이 접근 방식은 장바구니, 상품 목록 등의 비즈니스 기능 단위를 별도의 개발 팀이 소유하게 하여, 프레임워크나 기술 스택에 구애받지 않고 독립적인 개발, 테스트, 배포가 가능하게 함으로써 팀의 자율성과 유지보수성을 극대화한다 [13, 15].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
@@ -41,3 +52,52 @@ github_commit: "[P-Reinforce] Continuous Worker - 대규모 프론트엔드 웹
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
```
## 🤔 의사결정 기준 (Decision Criteria)
**선택 A를 써야 할 때:**
- *(TODO)*
**선택 B를 써야 할 때:**
- *(TODO)*
**기본값:**
> *(TODO)*
## ❌ 안티패턴 (Anti-Patterns)
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/대규모 확장성과 유지보수성이 요구되는 프런트엔드 모노레포 프로젝트.md
+78 -4
View File
@@ -1,9 +1,29 @@
---
id: wiki-2026-0508-대규모-확장성과-유지보수성이-요구되는-프런트엔드-모노레포-
title: 대규모 확장성과 유지보수성이 요구되는 프런트엔드 모노레포 프로젝트
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
---
# [[대규모 확장성과 유지보수성이 요구되는 프런트엔드 모노레포 프로젝트|대규모 확장성과 유지보수성이 요구되는 프런트엔드 모노레포 프로젝트]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
현대적인 프런트엔드 모노레포는 웹 앱, 어드민, 모바일 웹 및 공유 UI 라이브러리와 같은 여러 프런트엔드 프로젝트를 단일 Git 저장소에서 관리하며 일관된 의존성 그래프로 연결하는 구조입니다 [1, 2]. 이는 UI 원시(primitives), 디자인 토큰, 라우팅 규칙 등을 공유하는 다수의 애플리케이션 간의 일관성을 유지하는 데 필수적입니다 [2, 3]. 강력한 빌드 도구와 아키텍처 규칙(예: FSD)을 통해 모듈 간의 결합도를 낮추고 응집도를 높임으로써, 원자적 리팩터링(atomic refactors)을 지원하고 대규모 프런트엔드 플랫폼을 효율적으로 확장할 수 있게 합니다 [2, 4, 5].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
- **아키텍처 원칙 및 경계 강제 ([[Boundaries|Boundaries]] & [[Public APIs|Public APIs]]):**
확장 가능한 모노레포는 단순히 여러 폴더의 집합이 아니라, 강제된 경계와 명확한 의존성 방향을 가진 모듈 시스템입니다 [1, 6]. UI 컴포넌트 패키지가 내부 깊숙한 파일 경로로 직접 참조(deep imports)되는 것을 방지하기 위해, 패키지별로 단일 진입점(`src/index.ts`)을 통한 **명시적인 공개 API(Public API)**를 구성해야 합니다 [7-9]. 또한, 공유 UI 원시 요소(Shared UI primitives)는 상위 계층의 비즈니스 기능(Feature) 패키지를 절대 임포트하지 않도록 엄격한 **계층적 의존성(Layered Dependencies)**을 유지해야 합니다 [10, 11].
@@ -19,10 +39,64 @@
- **CI/CD 및 성능 최적화 (CI/CD & Caching):**
대규모 컴포넌트 라이브러리를 공유할 때 모든 PR이 전체 시스템을 다시 빌드하게 하면 막대한 비용이 발생합니다 [2, 9]. 따라서 "영향을 받는(affected) 앱과 패키지만 빌드 및 배포한다"는 전략이 필수적입니다 [23, 24]. 원격 캐싱(Remote caching)을 활용하면 머신 간 빌드 결과물을 재사용할 수 있어, 공통 UI 패키지가 변경될 때 발생하는 피드백 루프와 연산 비용을 획기적으로 줄일 수 있습니다 [9, 25].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Feature-Sliced Design (FSD)|Feature-Sliced Design (FSD]], Turborepo 및 Nx 빌드 시스템, Reusable UI Components, Design Tokens, React Server Components (RSC
- **Projects/Contexts:** Uber의 Base Web 등 다양한 내부 앱 관리를 위한 디자인 시스템 도입, 확장 가능한 프런트엔드를 위한 의존성 및 패키지 구조화
- **Contradictions/Notes:** 모노레포 아키텍처는 코드 공유와 원자적 커밋의 이점을 제공하지만, "공유 모듈이 무분별하게 참조되는 스파게티 코드(spaghetti sharing)"를 유발할 위험이 있습니다. 소스에서는 이를 방지하기 위해 린트(Lint) 규칙, 엄격한 코드 소유권(CODEOWNERS), FSD와 같은 경계 강제가 없으면 오히려 통합 비용이 급증할 수 있다고 경고합니다 [1, 8, 26, 27]. 또한, 서로 코드를 공유할 필요가 거의 없는 완전히 독립적인 제품들의 경우 폴리레포(Polyrepo)가 더 안전한 선택이라고 조언합니다 [28].
---
*Last updated: 2026-04-26*
*Last updated: 2026-04-26*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧪 검증 상태 (Validation)
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/덱 빌딩 시스템 (Deck Building System).md
+75 -7
View File
@@ -1,24 +1,92 @@
---
category: Unified
status: Final
converted_at: 2026-04-28
id: wiki-2026-0508-덱-빌딩-시스템-deck-building-system
title: 덱 빌딩 시스템 (Deck Building System)
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
---
# 덱 빌딩 시스템 (Deck BuildingSystem)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
[[WARNO|WARNO]]의 덱 빌딩 시스템은 플레이어가 50점의 활성화 포인트(Activation Points)를 활용하여 전장에 투입할 유닛 조합(배틀그룹)을 구성하는 시스템입니다 [1-3]. 전작들의 국가 기반 덱과 달리 역사적 편제에 기반한 '사단(Division)' 단위의 제약을 두어 유닛을 구성하도록 강제합니다 [3, 4]. 이를 통해 특정 병과에 특화된 장단점을 데이터적으로 구현하여, 무적의 군대 생성을 방지하고 전략적 선택의 기회비용과 밸런스를 확립한 게임 내 핵심 설계입니다 [3, 5].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **사단 기반의 데이터 제약 (Division-based Restrictions):** WARNO는 플레이어가 원하는 모든 최상급 유닛을 한 덱에 섞어 넣을 수 없도록 '사단(Division)' 시스템을 채택했습니다 [1]. 각 사단은 고유한 강점과 약점을 지니도록 데이터화되어 있으며, 예를 들어 최상급 전차를 지닌 사단은 보병의 질이나 수량이 제한되는 방식입니다 [6]. 이는 역사적 편제(TO&E)나 시나리오 배경에 기반한 논리적 설계를 통해 게임의 전략적 정체성을 형성합니다 [3, 7, 8].
* **활성화 포인트와 슬롯 비용 (Activation Points & Slot Costs):** 모든 사단은 덱 구성을 위해 동일하게 50점의 활성화 포인트를 제공받습니다 [1-3]. 배틀그룹 생성 시 각 병과 슬롯에 유닛 카드를 추가할 때마다 1~4점의 포인트가 소모되며, 이 슬롯 비용 데이터는 사단의 특성에 따라 다르게 설정되어 있습니다 [2]. 예를 들어 3기갑사단과 같은 기갑사단은 전차 슬롯 비용이 저렴하게 설정되어 물량 확보가 용이합니다 [3].
* **숙련도와 가용성의 상관관계 (Veterancy & Availability):** 플레이어는 덱에 유닛 카드를 추가할 때 숙련도(Poor, Trained, Veteran, Elite)를 선택할 수 있습니다 [9]. 높은 숙련도를 선택할수록 명중률, 연사 속도, 제압(Stress) 저항력 데이터에 보너스를 받지만, 반대급부로 전장에 배치 가능한 최대 유닛 수(가용성)가 감소합니다 [10, 11]. 고성능 유닛일수록 카드당 가용 유닛 수가 1~2대로 극히 제한되어, 플레이어가 유닛 손실을 최소화하도록 데이터적 압박을 가합니다 [12].
* **NDF를 통한 시스템 아키텍처 연동:** 덱 빌딩과 관련된 모든 논리적 제약과 밸런스는 엔진 내부의 NDF(Neutral Data Format) 파일로 제어됩니다 [13]. 전략적 사단 구성, 카드당 유닛 수, 배치 가능 유닛 리스트 등은 `Divisions.ndf` 파일에 정의되며 [14, 15], 각 유닛의 숙련도별 가용성 승수(XPMultiplier) 데이터는 `DivisionRules.ndf` 파일을 통해 통제됩니다 [16].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[사단 시스템 (Division System)|사단 시스템 (Division System]], NDF (Neutral Data Format), [[가용성 (Availability)|가용성 (Availability]]
- **Projects/Contexts:** WARNO 데이터 기반 설계 (Data-Driven Design
- **Contradictions/Notes:** 일부 플레이어들은 Wargame 시리즈처럼 제약 없이 유닛을 조합할 수 있는 '국가 덱 시스템'의 향수와 자유도를 원하며 현재 시스템이 창의성을 제한한다고 불만을 제기합니다 [17, 18]. 그러나 개발진 및 대다수의 커뮤니티 유저들은 사단 시스템이 지나친 '메타 덱' 쏠림 현상을 방지하고 비주류 유닛들의 활용도를 높여 훨씬 균형 잡히고 흥미로운 전술적 환경을 제공한다고 반박합니다 [5, 19, 20].
---
*Last updated: 2026-04-28*
*Last updated: 2026-04-28*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧪 검증 상태 (Validation)
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/동적-정적 코드 분석 (Static-Dynamic Code Analysis).md
+18 -2
View File
@@ -1,6 +1,22 @@
---
id: static_dynamic_code_analysis_redirect
redirect: [[SAST]]
id: wiki-2026-0508-동적-정적-코드-분석-static-dynamic-code-
title: 동적 정적 코드 분석 (Static Dynamic Code Analysis)
category: 10_Wiki/Topics
status: merged
redirect_to: SAST
canonical_id: SAST
aliases: [static_dynamic_code_analysis_redirect]
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
---
# Redirect
10_Wiki/Topics/Backend/디버깅_전략_Debugging_Strategies.md
+70 -10
View File
@@ -1,28 +1,39 @@
---
category: Unified
id: wiki-2026-0508-디버깅-전략-debugging-strategies
title: 디버깅 전략 Debugging Strategies
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 디버깅 전략 (Debugging Strategies)
description: "디버깅 전략은 대규모의 복잡한 코드베이스를 효과적으로 해독하고 이해하기 위해 런타임 동작을 추적하고 분석하는 방법론이다 [1]."
last_updated: 2026-05-02
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
---
# 디버깅 전략 (Debugging Strategies)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
디버깅 전략은 대규모의 복잡한 코드베이스를 효과적으로 해독하고 이해하기 위해 런타임 동작을 추적하고 분석하는 방법론이다 [1]. 단순히 오류를 수정하는 목적을 넘어, 중단점, 로그, 스택 트레이스 및 프로파일러 등을 활용하여 정적인 코드 읽기만으로는 파악하기 힘든 동적 흐름과 객체의 상태 변화를 관찰하는 것을 포함한다 [1, 2]. 이는 새로운 시스템에 온보딩하거나 레거시 코드를 파악할 때 필수적인 실천적 지식 탐색 기법으로 작용한다 [3, 4].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **런타임 흐름 파악을 위한 중단점(Breakpoints) 활용:** 디버거를 실행하고 중단점을 설정하여 코드가 실제로 어떻게 동작하는지 관찰하는 것은 코드베이스 이해에 핵심적이다 [3, 5]. 중단점을 통해 호출 스택(Call stack)과 변수 값의 실시간 변화를 확인할 수 있으며, 이는 복잡한 비동기 작업이나 메시지 큐의 흐름을 파악하는 데 결정적인 도움을 준다 [1, 6]. IDE나 브라우저 개발자 도구를 활용해 REST 엔드포인트부터 실제 데이터 액션까지 단계별로 디버깅하며 추적할 수 있다 [3].
* **로그와 스택 트레이스(Stack Trace) 분석:** 임의의 잘못된 입력을 의도적으로 주입하여 실패를 유도하고, 그 결과로 출력되는 에러 메시지와 스택 트레이스를 분석하는 기법이 있다 [1, 7]. 이를 통해 코드가 입력을 파싱하는 과정과 실패 지점을 드러내어 시스템의 내부 논리와 데이터 처리 구조를 파악할 수 있다 [1, 7]. UI에 추가적인 로깅이나 디버그 출력을 일시적으로 삽입하는 등 작은 변경을 가해보는 것도 시스템 이해를 돕는다 [3].
* **가치 추적(Value Tracking) 및 호출 사슬(Call Chains) 분석:** 디버깅 중 특정 토큰의 기원(origin)과 목적지(destination)를 추적하여 값을 변경할 수 있는 지점을 탐색할 수 있다 [8]. 특정 값에 대한 호출이 발생한 위치를 파악하는 이 검사 기법은 코드를 심층적으로 조사하는 훌륭한 도구가 된다 [8].
* **실제 버그 수정을 통한 탐험(Spelunking):** 코드를 고립된 상태에서 단순히 읽는 것보다 실제로 코드베이스에 기여하고 버그를 수정하는 과정에서 시스템을 훨씬 더 잘 이해할 수 있다 [3]. 간단한 버그를 찾아 재현하고, 해당 버그로 이어지는 호출 스택을 찾아보는 방식으로 디버깅을 시작하면 낯선 코드베이스 파악에 유용하다 [3].
* **프로파일러(Profilers) 활용:** 프로파일러를 성능 최적화 도구로만 생각하기 쉽지만, 누군가 의도했던 코드가 아닌 '실제로 실행되는' 코드를 이해하는 데 매우 유용하다 [2]. 플레임(Flame) 또는 아이시클(Icicle) 그래프를 통해 가장 중요한 코드 영역들을 시각적으로 확인하고, 코드를 읽는 데 시간을 투자해야 할 로드맵을 얻을 수 있다 [2].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
디버깅을 통한 런타임 분석은 시스템 파악에 필수적이지만, 가장 원시적인 방법인 로그만 사용하는 것보다는 호출 스택과 변수 값 등 훨씬 더 많은 정보를 제공하는 중단점(Breakpoints)을 활용하는 것이 효율적이다 [1, 6]. 하지만 디버거를 실행하고 상태를 관찰하려면 코드를 실제로 로컬에서 빌드하고 실행할 수 있도록 로컬 환경이 성공적으로 구축되어야 하므로, 초기 환경 설정에서 누락된 프로세스가 있을 경우 많은 시간이 소모될 수 있다 [9]. 또한, 버그 수정을 통한 코드 탐험(Spelunking) 과정에서 복잡한 로직 내에서 길을 잃기 쉬우므로 탐색 시간을 제한(Timebox)해야 하며, 스스로 파악하기 어려울 때는 코드베이스 지식이 있는 담당자에게 질문하여 해결하는 유연함이 필요하다 [3].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [분석 및 실행 환경]
@@ -65,4 +76,53 @@ last_updated: 2026-05-02
- 확장 방향: 디버깅을 통해 발견한 오류의 원인 코드나 특정 로직이 과거에 어떤 비즈니스 맥락과 의도로 작성되었는지 Git 커밋 메시지, PR 대화 기록 등을 통해 추적하여, 시스템 제약 사항과 히스토리적 이해를 확장한다 [10].
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/라우터_Routers.md
+77 -9
View File
@@ -1,14 +1,26 @@
---
category: Unified
id: wiki-2026-0508-라우터-routers
title: 라우터 Routers
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 라우터 (Routers)
description: "라우터(Routers)는 시스템 내에서 클라이언트의 요청이나 이벤트를 적절한 목적지나 처리 로직으로 전달(Routing)하는 역할을 수행하는 구성 요소이다 [1-3]."
last_updated: 2026-05-02
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
---
# 라우터 (Routers)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
라우터(Routers)는 시스템 내에서 클라이언트의 요청이나 이벤트를 적절한 목적지나 처리 로직으로 전달(Routing)하는 역할을 수행하는 구성 요소이다 [1-3]. '코드베이스 읽기' 관점에서는 복잡한 시스템의 전체 기능과 요청 처리 흐름을 파악하기 위한 핵심 진입점(Entry Point)이자 하향식(Top-Down) 탐색의 주요 시작점으로 기능한다 [3-5].
## 📖 Core 대Content
@@ -21,12 +33,11 @@ last_updated: 2026-05-02
* **이벤트 기반 아키텍처(EDA)에서의 라우팅:**
이벤트 기반 시스템에서는 Apache Kafka나 RabbitMQ와 같은 메시지 브로커(Message Broker)가 이벤트 라우팅 관리를 담당한다 [9]. 프로듀서(Producer)가 이벤트를 발행하면, 브로커가 이를 관심 있는 소비자(Consumers)에게 라우팅하여 비동기적으로 작업을 처리하게 한다 [8-10].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
**소스에 관련 정보가 부족합니다.**
제공된 소스에는 라우팅 방식의 기술적 선택(예: 동적 라우팅 대 정적 라우팅)이나 라우터 최적화 방법에 따른 구체적인 부작용, 제약 사항(Trade-offs)에 대한 상세한 설명이 포함되어 있지 않습니다. 다만, 구조적인 측면에서 API 게이트웨이를 통한 라우팅 처리가 클라이언트 측의 접근을 분리(Decouple)하여 내부 서비스 진화 시 소비자에게 영향을 주지 않는다는 장점이 언급되어 있습니다 [2]. 반면 이벤트 브로커를 통한 비동기 라우팅의 경우, 처리 순서 및 상태를 관리해야 하는 비동기적 복잡성(Asynchronous complexity)이 높아진다는 제약이 존재합니다 [11].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [시스템 탐색 및 분석 전략 (System Exploration)]
@@ -69,4 +80,61 @@ last_updated: 2026-05-02
- 확장 방향: 라우터를 통한 정적인 코드의 흐름 파악을 넘어서서, 런타임 환경에서 로그와 중단점(Breakpoints)을 활용해 요청이 라우팅되는 동적 상태 전이를 어떻게 분석할 것인지에 대한 기법으로 확장한다 [18, 19].
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 📖 구조화된 지식 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/로그_Logs_및_에러_메시지_Error_Messages.md
+70 -10
View File
@@ -1,28 +1,39 @@
---
category: Unified
id: wiki-2026-0508-로그-logs-및-에러-메시지-error-messages
title: 로그 Logs 및 에러 메시지 Error Messages
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 로그 (Logs) 및 에러 메시지 (Error Messages)
description: "로그(Logs)와 에러 메시지(Error Messages)는 정적인 코드 분석만으로는 파악하기 힘든 소프트웨어 시스템의 동적 특성을 이해하도록 돕는 핵심 도구이다 [1]."
last_updated: 2026-05-02
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
---
# 로그 (Logs) 및 에러 메시지 (Error Messages)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
로그(Logs)와 에러 메시지(Error Messages)는 정적인 코드 분석만으로는 파악하기 힘든 소프트웨어 시스템의 동적 특성을 이해하도록 돕는 핵심 도구이다 [1]. 새로운 코드베이스를 탐색할 때 의도적으로 잘못된 입력을 주입해 출력되는 스택 트레이스(Stack Trace)를 확인하는 것은 시스템 내부 로직을 파악하는 강력한 방법이 된다 [1, 2]. 또한, 마이크로서비스나 API 아키텍처 설계에 있어 **중앙 집중식 로깅(Centralized Logging)**과 명확한 에러 메시지는 시스템 가시성 확보와 트러블슈팅에 필수적이다 [3-5].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **동적 특성 파악 및 탐색의 이정표**: 정적인 코드 읽기만으로는 파악하기 어려운 시스템의 동적인 특성은 **로그, 중단점(Breakpoints), 그리고 런타임 프로파일링**을 통해 분석해야 한다 [1]. 거대한 코드베이스 안에서 무엇을 검색(`grep`)해야 할지 막막할 때, 로그나 에러 메시지를 살펴보는 것은 훌륭한 탐색의 출발점이 된다 [2].
* **의도적 실패를 통한 시스템 내부 구조 역추적**: 서비스에 무작위 입력을 전달하여 구문 분석에 실패하게 만들면, 시스템은 **스택 트레이스와 에러 메시지를 출력**하게 된다 [2]. 이처럼 의도적으로 시스템에 잘못된 입력을 주입하여 실패를 유도하고 그 결과를 분석하는 방식은, 눈에 보이지 않는 시스템의 내부 논리와 데이터 처리 구조를 명확하게 드러내는 강력한 기법으로 작용한다 [1].
* **실험적 코드 수정을 통한 학습**: 낯선 코드를 학습할 때 애플리케이션의 특정 부분에 **추가적인 로깅(extra logging)이나 디버그 출력을 직접 삽입**하는 약간의 수정 작업을 해보는 것만으로도 시스템의 작동 원리에 대해 많은 것을 배울 수 있다 [6].
* **분산 환경에서의 가시성 및 트러블슈팅 강화**: 여러 서비스가 통신하는 마이크로서비스 아키텍처에서는 시스템 가시성(Visibility)을 확보하기 위해 강력한 모니터링과 **중앙 집중식 로깅(Centralized Logging)**이 매우 중요하다 [3, 7]. 또한, API 설계 시 명확하고 투명한 HTTP 상태 코드와 의미 있는 에러 메시지를 구현하는 것은 개발자의 신속한 문제 해결(Troubleshooting)을 돕고 클라이언트와 서버 간의 통신 효율성을 높인다 [4, 5].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
로그 및 에러 처리 설계 방식은 시스템의 제어 흐름에 중대한 영향을 미치는 트레이드오프를 수반한다. 예를 들어, 시스템 에러 처리 시 **예외(Exceptions)를 발생시키느냐, 아니면 에러 객체를 반환(`return { error }`)하느냐**에 따라 런타임 실행 흐름이 완전히 달라질 수 있다 [8]. 예외 처리를 사용하면 실패 시 폴백(Fallback) 루프가 계속 실행되어 다른 대안을 시도할 수 있지만, 에러 객체를 단순히 반환하는 방식은 즉시 실행을 종료하게 만들어 시스템 복원력에 악영향을 줄 수 있다 [8].
또한, 로깅된 에러 메시지에만 의존하는 것은 한계가 있을 수 있으므로, 디버깅 도구의 **중단점(Breakpoints)** 기능을 병행하여 호출 스택과 변수 값의 실시간 변화를 함께 관찰해야만 복잡한 시스템(비동기 작업 등)의 전체 흐름을 완벽하게 파악할 수 있다 [1].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [시스템 아키텍처 및 기반 기술]
@@ -62,4 +73,53 @@ last_updated: 2026-05-02
- 확장 방향: 분산된 수많은 서비스들 사이에서 발생하는 에러를 추적하고 중앙 집중식으로 로깅을 수집하는 복잡한 인프라 관리 기술 탐구.
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/마이크로서비스 아키텍처 (MSA).md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-6DFA0C
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-마이크로서비스-아키텍처-msa
title: 마이크로서비스 아키텍처 (MSA)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-6DFA0C]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키텍처 (MSA)"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[마이크로서비스 아키텍처 (MSA)|마이크로서비스 아키텍처 (MSA]]
@@ -38,7 +49,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키
* 주요 우선순위는 효율성, 혁신, 그리고 99.999%에 달하는 고가용성(안정성) 확보였습니다 [3, 18].
* 무상태([[State|State]]less) 서비스 원칙, 수직적 확장(Scale up) 대신 수평적 확장(Scale out) 선택, 다중 리전(Multi-Regional) 복제, 그리고 'Chaos Monkey'를 통한 자동화된 파괴 테스트 등을 적용하여 시스템 회복성을 갖추었습니다 [17, 19].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -51,3 +62,52 @@ github_commit: "[P-Reinforce] Continuous Worker - 마이크로서비스 아키
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
```
## 🤔 의사결정 기준 (Decision Criteria)
**선택 A를 써야 할 때:**
- *(TODO)*
**선택 B를 써야 할 때:**
- *(TODO)*
**기본값:**
> *(TODO)*
## ❌ 안티패턴 (Anti-Patterns)
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/모듈러 통합 건설 (MiC).md
+64 -4
View File
@@ -1,10 +1,21 @@
---
id: [[P-Reinforce|P-Reinforce]]-AUTO-FE2B8A
category: Unified
confidence_score: 0.90
id: wiki-2026-0508-모듈러-통합-건설-mic
title: 모듈러 통합 건설 (MiC)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-Reinforce-AUTO-FE2B8A]
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
tags: [auto-reinforced]
raw_sources: []
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 모듈러 통합 건설 (MiC)"
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
language: unspecified
framework: unspecified
---
# [[모듈러 통합 건설 (MiC)|모듈러 통합 건설 (MiC]]
@@ -19,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 모듈러 통합 건설 (MiC)"
- **공기 단축 및 품질 향상:** 공장에서 모듈의 모든 구성 요소를 한 번에 제작하므로 밀리미터(mm) 수준까지 설치 오차를 제어할 수 있어, 방수 노드의 기밀성을 확보하고 누수를 방지하는 등 월등한 품질을 보장합니다[1, 3].
- **안전성 및 친환경성:** 전통적인 현장 시공 방식 대비 훨씬 안전한 제작 환경을 제공하며, 현장 작업의 최소화로 인해 환경에 미치는 부정적인 영향을 크게 줄일 수 있습니다[2].
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
@@ -32,3 +43,52 @@ github_commit: "[P-Reinforce] Continuous Worker - 모듈러 통합 건설 (MiC)"
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
```text
# TODO
```
## 🤔 의사결정 기준 (Decision Criteria)
**선택 A를 써야 할 때:**
- *(TODO)*
**선택 B를 써야 할 때:**
- *(TODO)*
**기본값:**
> *(TODO)*
## ❌ 안티패턴 (Anti-Patterns)
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/상향식_및_하향식_탐색_Top-Down_&_Bottom-Up_Approach.md
+70 -10
View File
@@ -1,17 +1,29 @@
---
category: Unified
id: wiki-2026-0508-상향식-및-하향식-탐색-top-down-bottom-up-
title: "상향식 및 하향식 탐색 Top Down & Bottom Up Approach"
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 상향식 및 하향식 탐색 (Top-Down & Bottom-Up Approach)
description: "하향식(Top-Down) 및 상향식(Bottom-Up) 탐색은 방대하고 복잡한 코드베이스를 해독하고 이해하기 위해 정보의 흐름을 추적하는 두 가지 근본적인 전략입니다 [1]."
last_updated: 2026-05-02
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
---
# 상향식 및 하향식 탐색 (Top-Down & Bottom-Up Approach)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
하향식(Top-Down) 및 상향식(Bottom-Up) 탐색은 방대하고 복잡한 코드베이스를 해독하고 이해하기 위해 정보의 흐름을 추적하는 두 가지 근본적인 전략입니다 [1]. 하향식 접근법은 외부 세계와 소통하는 최상위 인터페이스에서 시작해 하위 비즈니스 로직으로 진입하는 방식이며, 상향식은 데이터가 도달하는 최하단(DB 등)에서 시작해 이를 호출하는 상위 함수를 역추적하는 방식입니다 [1]. 이 두 전략을 혼합한 하이브리드 접근은 비즈니스 의도와 기술적 한계를 동시에 파악하여 시스템 전체에 대한 일관된 이해를 형성하는 데 필수적입니다 [2].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **하향식 탐색 (Top-Down Approach):**
* 시스템의 최상위 추상화 계층, 즉 외부 세계와 소통하는 인터페이스에서 시작하여 점진적으로 구현의 상세 코드로 진입하는 분석 방식입니다 [1, 2].
* 주로 REST API 가이드, gRPC 서비스 정의서, 사용자 인터페이스(UI) 등 애플리케이션의 고수준 진입점을 먼저 식별합니다 [1, 3].
@@ -25,13 +37,12 @@ last_updated: 2026-05-02
* 대규모 시스템의 전체상을 가장 효율적으로 그리기 위해 두 접근법을 혼합하여 사용하는 방식입니다 [2].
* 하향식으로 비즈니스의 의도(의미)를 파악하고, 상향식으로 물리적 제약이나 기술적 한계를 역확인하여 중간 지점에서 서로 일치하는 이해를 도출해내는 과정이 핵심입니다 [2].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **하향식 탐색의 인지적 과부하:** 시스템의 최상단에서 시작하는 하향식 접근법을 취할 경우, 당장 작업할 필요가 없거나 개발자가 신경 쓰지 않아도 되는 불필요한 시스템 영역까지 모두 포함해 훑게 될 가능성이 큽니다 [4]. 수백만 줄에 달하는 전체 코드베이스를 단번에 하향식으로 완벽히 이해하려고 하면 오히려 인지적 과부하에 빠지거나 이해를 방해받을 수 있습니다 [5].
* **상향식 탐색의 맥락 상실:** 상위 비즈니스 맥락을 모른 채 특정 데이터 스키마나 하위 코드 조각, 개별 버그 호출 스택(Call stack)에만 집중하여 역추적할 경우, 해당 로직이 시스템의 거시적인 목적과 어떻게 부합하는지 근본적인 시스템 의도를 놓치기 쉽습니다 [2].
* **실용적 보완 방안:** 코드 전체를 이해하려는 압박감을 버리고, 우선 자신이 작업해야 할 부분이나 이미 알고 있는 영역(버그 티켓 등)에서 출발해 필요한 만큼만 의존성 그래프를 확장하며 학습하는 것이 더 현실적입니다 [4, 6].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [탐색의 진입점 요소]
@@ -71,4 +82,53 @@ last_updated: 2026-05-02
- 확장 방향: 하향/상향식 분석을 통해 얻은 정보(진입점, 흐름, 경계)를 체계화하여 1줄 요약, 5분 설명, 딥 다이브 단계의 문서를 새로 구축하고 팀원들과 공유하는 프로세스로 연결됩니다 [9, 10].
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/상향식_및_하향식_탐색_Top-down_&_Bottom-up_Navigation.md
+70 -11
View File
@@ -1,18 +1,29 @@
---
category: Unified
id: wiki-2026-0508-상향식-및-하향식-탐색-top-down-bottom-up-
title: "상향식 및 하향식 탐색 Top down & Bottom up Navigation"
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 상향식 및 하향식 탐색 (Top-down & Bottom-up Navigation)
description: "대규모 코드베이스를 탐색할 때 정보의 흐름을 추적하는 방향에 따른 두 가지 근본적인 접근법이다[1]."
last_updated: 2026-05-02
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
---
# 상향식 및 하향식 탐색 (Top-down & Bottom-up Navigation)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
대규모 코드베이스를 탐색할 때 정보의 흐름을 추적하는 방향에 따른 두 가지 근본적인 접근법이다[1]. 하향식 접근법은 시스템의 최상위 추상화 계층인 외부 인터페이스에서 시작하여 점진적으로 구현 상세로 내려가는 방식이다[1]. 반면, 상향식 접근법은 데이터가 최종적으로 보관되는 스토리지나 외부 시스템에서 시작하여 이를 호출하는 상위 계층으로 역추적하는 방식이다[1]. 이 두 전략을 상황에 맞춰 혼합하는 하이브리드 방식이 복잡한 시스템의 전체상을 파악하는 데 가장 효율적이다[2].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **하향식 접근법 (Top-down Approach)**
* **개념과 목적:** 시스템의 최상위 추상화 계층, 즉 외부 세계와 소통하는 인터페이스에서 시작하여 점진적으로 구현의 상세로 진입하는 방식이다[1].
* **주요 진입점:** 주로 REST API 가이드, gRPC 서비스 정의서, 혹은 사용자 인터페이스(UI)나 CLI 진입점과 같은 가장 높은 수준의 인터페이스를 식별하여 시작한다[1, 3].
@@ -29,13 +40,12 @@ last_updated: 2026-05-02
* 복잡한 시스템의 전체상을 그리는 데 가장 효율적인 방식은 두 접근법을 혼합하는 것이다[2].
* 하향식으로 비즈니스 의도를 파악하고, 상향식으로 기술적 한계를 확인하며 중간 지점에서 일관된 이해를 형성하는 과정이 필수적이다[2].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **하향식 탐색의 제약 (오버헤드 및 부적합성):** 하향식으로 접근할 경우, 개발자가 전혀 신경 쓸 필요가 없는 방대한 상위 코드나 불필요한 영역까지 모두 파악해야 하는 비효율이 발생할 수 있다[6]. 종속성 그래프상에서 본인의 작업과 연관된 부분만 파악하는 것이 나을 때는 하향식 전체 조망이 오히려 독해 속도를 늦출 수 있다[6].
* **상향식 탐색의 제약 (맥락 파악의 한계):** 가장 낮은 구현 상세 계층(예: 데이터베이스 테이블)에서만 시작하면, 시스템 전체의 비즈니스적 맥락이나 사용자 의도를 놓친 채 지엽적인 코드 흐름에 매몰될 수 있다[1, 2].
* **상호 보완의 필요성:** 어느 한쪽의 방향에만 치우치면 구조적 이해의 불균형이 생기기 때문에, 버그 원인 파악(상향식 유리)이나 피처 구조 파악(하향식 유리) 등 목적에 맞게 두 방식을 융합하여 사용하는 전략적 선택이 필수적이다[1, 2].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [아키텍처 및 시스템 설계]
@@ -74,4 +84,53 @@ last_updated: 2026-05-02
- 확장 방향: 하향식 및 상향식 탐색을 통해 얻은 코드베이스 지식을 팀 차원의 구조화된 온보딩 가이드와 아키텍처 지식 맵으로 문서화하는 방법론으로 확장.
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/소프트웨어 문서화 (Software Documentation).md
+54 -17
View File
@@ -1,26 +1,28 @@
---
id: P-REINFORCE-WIKI-481F95D6
title: "소프트웨어 문서화 (Software Documentation)"
category: Unified
status: draft
canonical_id: ""
aliases: []
duplicate_of: ""
id: wiki-2026-0508-소프트웨어-문서화-software-documentation
title: 소프트웨어 문서화 (Software Documentation)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-REINFORCE-WIKI-481F95D6]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
tags: ['Software Documentation']
raw_sources: ["Datacollector_MAC/out_wiki/소프트웨어 문서화 (Software Documentation).md"]
tags: [Software Documentation]
raw_sources: [Datacollector_MAC/out_wiki/소프트웨어 문서화 (Software Documentation).md]
last_reinforced: 2026-05-02
github_commit: ""
github_commit: pending
tech_stack:
language: unspecified
framework: unspecified
---
# [[소프트웨어 문서화 (Software Documentation)]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
소프트웨어 문서화는 시스템의 구조, 의도, 설정 및 작동 방식을 개발자와 다양한 이해관계자에게 전달하는 필수적인 지식 체계이다 [1-3]. 이는 텍스트 기반의 README 파일이나 위키뿐만 아니라, 시스템 아키텍처 다이어그램, API 명세, 형상 관리의 커밋 메시지와 풀 리퀘스트(PR) 설명, 그리고 시스템의 기대 동작을 보여주는 테스트 코드까지 폭넓게 포괄한다 [4-7]. 훌륭한 문서화는 새로운 팀원의 온보딩 시간을 단축하고, 코드베이스의 복잡성을 해독하며 효율적인 협업을 가능케 하는 핵심 가이드 역할을 수행한다 [2, 8-10].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **코드베이스 탐색의 출발점, README 파일**
* README는 단순한 형식적 문서가 아니라 프로젝트의 '지도'이다 [2]. 훌륭한 README는 개발자가 저장소를 클론하고, 의존성을 설치하고, 환경 변수를 설정하여 프로젝트를 성공적으로 실행하고 이해하는 데 필요한 모든 것을 안내한다 [4].
* 필수 포함 요소로는 시스템 실행 전제 조건, 빠른 시작(Quick Start), 폴더/저장소 구조 개요, API 엔드포인트 예시, 인증 처리, 테스트 및 배포 지침, 그리고 기여 규칙(Contributing) 등이 있다 [11-15].
@@ -43,8 +45,7 @@ github_commit: ""
* API-First Architecture에서는 OpenAPI(Swagger)와 같은 명세를 통해 서버 스텁, 클라이언트 SDK, 그리고 상호작용 가능한 API 문서를 **코드에서 직접 자동 생성**함으로써 문서가 구식이 되는 것을 방지한다 [30, 31].
* 근래에는 Kodesage, vFunction 같은 AI 기반 도구가 도입되어 런타임 상호작용을 자동으로 추적해 다이어그램을 업데이트하거나, 문서, 티켓(Jira), 코드베이스를 실시간으로 동기화하는 **동적 지식 저장소(Living Knowledge Base)**를 구축한다 [32-35]. 이를 통해 개발자는 문서 작성의 부담을 덜고 항상 최신화된 문서를 조회할 수 있다 [36].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **문서의 노후화 (Staleness 및 Architectural Drift):**
**오래되고 업데이트되지 않은 문서와 다이어그램은 문서가 없는 것보다 훨씬 더 위험하다.** 잘못된 지표를 제공하여 개발자와 이해관계자를 오도하기 때문이다 [37, 38]. 소프트웨어가 마이크로서비스 구조 등으로 고도화될수록 초기 설계 문서는 실제 구현과 멀어지는 '아키텍처 드리프트' 현상을 겪게 된다 [39].
* **시각화 도구의 선택 오류 (Static vs. Code-based):**
@@ -52,8 +53,7 @@ github_commit: ""
* **과도한 세부 사항에 대한 집착 (The God Diagram):**
하나의 다이어그램이나 단일 문서에 모든 클래스, 프레임워크, 메서드를 전부 욱여넣으려는 시도는 오히려 정보의 홍수를 유발하여 문서를 무용지물로 만든다 [42-44]. 독자의 기술적 이해도와 목적에 맞추어 적절한 수준의 추상화(예: C4 모델의 레벨 분리)를 적용하는 것이 필수적이다 [25, 42, 45].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [아키텍처 시각화 및 구조화]
@@ -109,3 +109,40 @@ github_commit: ""
- **기존 유사 문서:** None
- **처리 방식:** CREATE
- **처리 이유:** 신규 지식 체계 도입
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/엔드포인트_Endpoints.md
+77 -9
View File
@@ -1,14 +1,26 @@
---
category: Unified
id: wiki-2026-0508-엔드포인트-endpoints
title: 엔드포인트 Endpoints
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 엔드포인트 (Endpoints)
description: "엔드포인트(Endpoints)는 API(응용 프로그램 프로그래밍 인터페이스) 아키텍처에서 클라이언트와 서버, 혹은 외부 시스템 간의 상호작용 및 통신이 일어나는 구체적인 진입점(URL 또는 URI)을 의미합니다 [1, 2]."
last_updated: 2026-05-02
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
---
# 엔드포인트 (Endpoints)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
엔드포인트(Endpoints)는 API(응용 프로그램 프로그래밍 인터페이스) 아키텍처에서 클라이언트와 서버, 혹은 외부 시스템 간의 상호작용 및 통신이 일어나는 구체적인 진입점(URL 또는 URI)을 의미합니다 [1, 2]. 새로운 코드베이스를 파악하거나 분석할 때, 엔드포인트를 시작점으로 삼아 실제 데이터 흐름이나 액션을 추적하는 하향식(Top-Down) 접근법은 시스템의 비즈니스 로직과 제어 흐름을 이해하는 매우 강력한 전략입니다 [3, 4]. 잘 설계되고 문서화된 엔드포인트는 시스템 통합을 원활하게 하고 개발자의 코드베이스 온보딩 속도를 크게 향상시킵니다 [5, 6].
## 📖 Core 대분류 Content
@@ -24,15 +36,14 @@ last_updated: 2026-05-02
* **문서화와 일관성의 중요성**
엔드포인트의 이름과 리소스 지정을 일관성 있게 유지하면 코드베이스의 가독성과 예측 가능성이 크게 향상됩니다 [10]. README나 기술 문서에 엔드포인트의 역할, 요청/응답 형식의 예시, 인증 방법을 명확히 기록해 두면 새로운 개발자가 저장소를 클론한 후 프로젝트를 이해하는 시간을 대폭 줄일 수 있습니다 [5, 6].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
*소스에 엔드포인트 아키텍처 자체의 근본적인 트레이드오프에 대한 정보는 부족합니다. 다만, 엔드포인트 설계 및 관리에 따른 제약 및 문제점은 다음과 같이 서술되어 있습니다.*
* **명명 및 구조화의 제약**: 엔드포인트와 리소스에 대한 일관성 없는 이름 지정(Inconsistent naming)은 개발자의 이해를 어렵게 하고 코드베이스의 복잡성을 가중시킵니다 [10]. 엔드포인트를 무작위로 추가하기보다 관련된 기능별로 논리적으로 그룹화(Resource grouping)하지 않으면 구조적인 파악이 어려워집니다 [10].
* **문서화 부재에 따른 부작용**: 리드미(README)나 내부 문서에 예제 API 요청 및 응답, 스크린샷 등이 누락된 엔드포인트는 코드를 리뷰하거나 새로 합류한 개발자들이 해당 기능이 어떻게 동작하는지 알 수 없게 만들어 큰 혼란과 통합의 지연을 야기합니다 [6, 11].
* **테스트와 런타임 제약**: 엔드포인트에 대한 부하 테스트(Load testing)와 적절한 유효성 검사(Validation) 없이 배포가 진행되면 프로덕션 환경에서 취약점이나 성능 저하가 발생할 수 있습니다 [12, 13]. 또한, 엔드포인트 간의 통신 시 에러 처리(Error handling)가 제대로 구현되지 않으면 시스템 전체의 신뢰성이 저하됩니다 [12].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [코드베이스 탐색 기법]
@@ -82,4 +93,61 @@ last_updated: 2026-05-02
- 확장 방향: 소스 코드를 실행하지 않고도 엔드포인트의 입력/출력 사양과 HTTP 응답을 검증(Validation) 및 모의(Mocking)하는 방법을 실무적인 관점에서 익힐 수 있습니다. [9, 27]
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 📖 구조화된 지식 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/점진적 정적 재생성 (ISR).md
+78 -4
View File
@@ -1,9 +1,29 @@
---
id: wiki-2026-0508-점진적-정적-재생성-isr
title: 점진적 정적 재생성 (ISR)
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
---
# [[점진적 정적 재생성 (ISR)|점진적 정적 재생성 (ISR]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
점진적 정적 재생성(ISR, Incremental Static Regeneration)은 정적 사이트 생성(SSG)의 매우 빠른 로딩 속도와 서버 사이드 렌더링(SSR)의 데이터 최신화 능력을 결합한 하이브리드 웹 렌더링 전략입니다 [1, 2]. 전체 애플리케이션을 다시 빌드할 필요 없이 런타임에 백그라운드에서 특정 정적 페이지를 업데이트할 수 있도록 해줍니다 [1, 3, 4]. 주로 대규모 이커머스, 뉴스 포털, 문서 사이트 등 성능과 주기적인 콘텐츠 업데이트가 모두 중요한 플랫폼에서 효과적으로 활용됩니다 [5, 6].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
- **기본 작동 원리**:
초기 빌드 단계에서 페이지가 정적 HTML로 생성 및 캐시됩니다. 이후 사용자가 페이지를 요청하면 먼저 캐시된 정적 버전을 즉시 제공하여 빠른 응답 속도를 보장합니다 [6, 7]. 이때 콘텐츠가 지정된 재검증(revalidation) 시간을 초과한 상태라면, 브라우저에는 캐시된 구형 페이지를 먼저 보여주고 그와 동시에 백그라운드에서 페이지의 재생성 프로세스를 시작합니다 [6-8]. 새 버전이 성공적으로 생성되면 이후의 요청부터는 업데이트된 페이지가 제공됩니다 [7].
@@ -18,10 +38,64 @@
- **프레임워크 종속성**: ISR은 [[Next.js|Next.js]]나 Nuxt 3와 같이 의견이 강하게 반영된(opinionated) 특정 메타 프레임워크에 의존해야 하며, 백엔드 재생성 프로세스를 위해 주로 Node.js 런타임 환경을 필요로 합니다 [9, 10].
- 정적 파일 내보내기(Static exports) 방식과는 호환되지 않으며, 캐싱 및 배포 레이어를 관리하는 데 복잡성이 추가됩니다 [9, 10].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
- **Related Topics:** 정적 사이트 생성 (SSG), 서버 사이드 렌더링 (SSR)
- **Projects/Contexts:** [[Next.js|Next.js]], Nuxt 3, 대규모 이커머스 및 콘텐츠 플랫폼
- **Contradictions/Notes:** ISR은 실시간에 가까운 데이터(Near real-time)를 제공하며 안정성을 보장하지만, 백그라운드에서 재검증이 수행되기 전이거나 재생성 도중 백엔드 문제가 발생할 경우 사용자에게 필연적으로 이전의 오래된(Stale) 데이터가 지속해서 노출될 수 있다는 점을 유의해야 합니다 [8, 10, 11].
---
*Last updated: 2026-04-25*
*Last updated: 2026-04-25*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧪 검증 상태 (Validation)
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/진입점 (Entry Points).md
+54 -15
View File
@@ -1,25 +1,28 @@
---
id: P-REINFORCE-WIKI-C6278BEC
title: "진입점 (Entry Points)"
category: Unified
status: draft
canonical_id: ""
aliases: []
duplicate_of: ""
id: wiki-2026-0508-진입점-entry-points
title: 진입점 (Entry Points)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-REINFORCE-WIKI-C6278BEC]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
tags: ['Entry Points']
raw_sources: ["Datacollector_MAC/out_wiki/진입점 (Entry Points).md"]
tags: [Entry Points]
raw_sources: [Datacollector_MAC/out_wiki/진입점 (Entry Points).md]
last_reinforced: 2026-05-02
github_commit: ""
github_commit: pending
tech_stack:
language: unspecified
framework: unspecified
---
# [[진입점 (Entry Points)]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
진입점(Entry Points)은 소프트웨어 시스템이나 특정 기능이 실행을 시작하는 지점, 즉 외부 세계와 소통하는 최상위 인터페이스를 의미한다 [1]. 시작 스크립트, 라우터, CLI 핸들러, API 엔드포인트 및 패키지 내보내기(exports) 등이 진입점에 해당하며 시스템이 시작되는 최소한의 파일 세트로 정의된다 [2-4]. 새로운 코드베이스를 읽고 파악할 때 가장 먼저 탐색해야 하는 필수적인 출발점으로, 이를 통해 호출 스택을 역추적하며 시스템의 전체적인 비즈니스 로직과 흐름을 이해할 수 있다 [1, 5].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **진입점의 역할과 종류**
진입점은 프로그램의 실행이 실질적으로 시작되는 곳으로, 시스템 구조와 의존성을 파악하기 위한 첫 관문이다 [1, 4]. 일반적으로 진입점은 시작 스크립트(startup files), 라우터(routers), 핸들러(handlers), CLI 명령어(CLI commands), 백그라운드 워커(workers) 또는 패키지 익스포트(package exports) 형태로 구현된다 [3, 4]. 웹이나 API 환경에서는 클라이언트와 상호작용하는 URL이나 URI인 엔드포인트(Endpoints)가 진입점의 역할을 수행한다 [2, 6].
@@ -29,12 +32,11 @@ github_commit: ""
* **온보딩 및 코드 분석 과정에서의 활용**
진입점 식별은 새로운 엔지니어가 코드베이스에 온보딩하기 위한 체계적인 4단계 워크플로우(재고 조사 - 진입점 발견 - 실행 흐름 추적 - 경계 분석) 중 두 번째 핵심 단계에 해당한다 [3, 4]. 방대한 레거시 시스템이나 복잡한 구조를 분석할 때는 엣지(가장자리), 즉 HTTP 컨트롤러나 CLI 명령어 같은 주요 진입점을 먼저 찾고 이를 기점으로 시스템의 핵심 경로를 추적하여 구조를 그리는 것이 권장된다 [5]. 또한 특정 기능(feature)이 어떻게 컴포넌트와 의존성을 활용하는지 보여주는 '코드베이스 투어(Codebase Tour)'를 구성할 때도 진입점을 명확히 보여주는 것이 중요하다 [7].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
진입점에서 출발하는 하향식(Top-Down) 탐색은 시스템의 전체 비즈니스 의도와 사용자 요청의 처리 흐름을 파악하는 데는 탁월하지만, 데이터 변환 로직이나 물리적인 제약 사항 등 시스템 깊은 내부나 최하단에서 발생하는 구체적인 부수 효과(Side-effects)를 조기에 포착하기는 어렵다는 단점이 있다 [1, 8].
따라서 대규모 시스템을 읽을 때는 진입점 탐색에만 의존하지 않고, 데이터베이스 스키마나 메시지 큐 등에서 시작하는 상향식(Bottom-up) 탐색을 병행하여 중간 지점에서 일관된 이해를 형성하는 하이브리드 전략이 필요하다 [1, 8]. 또한 진입점에서 출발하여 모든 코드 흐름을 한 번에 깊이 파고들려(Rabbit hole) 하면 전체 그림을 이해하기도 전에 길을 잃을 수 있으므로, 초기에는 시스템의 큰 블록과 핵심 경로를 매핑하는 수준으로 탐색의 깊이를 조절해야 한다 [5].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [탐색 및 분석 전략]
@@ -87,3 +89,40 @@ github_commit: ""
- **기존 유사 문서:** None
- **처리 방식:** CREATE
- **처리 이유:** 신규 지식 체계 도입
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/진행 제한(Progression Limitation).md
+75 -7
View File
@@ -1,15 +1,29 @@
---
category: Unified
status: Final
converted_at: 2026-04-28
id: wiki-2026-0508-진행-제한-progression-limitation
title: 진행 제한(Progression Limitation)
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
---
# 진행 제한(Progression Limitation)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
진행 제한(Progression Limitation)은 플레이어가 게임 내에서 콘텐츠를 소비하거나 캐릭터를 성장시키는 속도를 의도적으로 제약하는 시스템을 의미합니다. 대표적인 형태로는 RPG 장르의 '스태미나/레진(Resin)' 시스템이나 캐주얼 게임의 '세션 길이 제한(Session-length restriction)'이 있습니다. 이 시스템은 게임 콘텐츠의 급격한 고갈을 방지하고 플레이어의 일일 접속을 유도하며, 제약을 우회하기 위한 결제 및 광고 시청을 촉진하여 게임 경제의 주요 수익화 동력으로 작용합니다.
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **콘텐츠 소비 속도 통제 및 잔존율(Retention) 유도**
무료 플레이(Free-to-Play) 게임은 플레이어의 진행 속도를 제한하여 게임의 수명을 연장합니다. 대표적으로 『원신(Genshin Impact)』은 플레이어가 특수 재료를 얻고 성장하는 속도를 제어하기 위해 '레진(Resin)'이라는 스태미나 시스템을 도입했습니다 [1, 2]. 이 레진은 16시간에 걸쳐 서서히 재생성되므로, 플레이어는 지속적인 성장을 위해 매일 게임에 로그인하여 자원을 소모해야 하는 강력한 동기를 부여받게 됩니다 [2, 3].
@@ -19,10 +33,64 @@ converted_at: 2026-04-28
* **게임 후반부(End-game) 경험 및 경제 생태계의 변화**
게임 진행이 심화될수록 성장에 필수적인 중요한 자원들은 진행 제한(스태미나 활동)의 뒤편에 묶이게 됩니다 [6]. 이는 수익화와 일일 루프 형성에는 긍정적이지만, 궁극적으로는 오픈 월드 탐험의 의미를 퇴색시키고 게임을 단순히 자원을 소모하고 캐릭터를 레벨업시키는 반복적인 작업(Grind)으로 전락시킬 수 있다는 경제적, 구조적 특징을 지닙니다 [6, 7].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
- **Related Topics:** [[인앱 결제(IAP)|인앱 결제(IAP]], 인앱 광고(IAA), 고객 유지율(Retention), [[핵심 루프(Core Loop)|핵심 루프(Core Loop]]
- **Projects/Contexts:** [[원신(Genshin Impact)|원신(Genshin Impact]], [[하이브리드 캐주얼 퍼즐 게임(Hybrid Puzzle Games)|하이브리드 캐주얼 퍼즐 게임(Hybrid Puzzle Games]]
- **Contradictions/Notes:** 진행 제한 시스템은 장기적인 접속과 수익 창출을 위한 필수적인 경제 설계 장치로 작용하지만, 다른 한편으로는 게임의 주된 목표가 오픈 월드 '탐험'에서 캐릭터 '진행(Progression)'과 반복 작업으로 변질되게 만든다는 비판적 시각도 존재합니다 [6, 7].
---
*Last updated: 2026-04-28*
*Last updated: 2026-04-28*
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🧪 검증 상태 (Validation)
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 없음
- **정책 변화:** 없음
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/코드베이스_투어_Codebase_Tours.md
+70 -11
View File
@@ -1,18 +1,29 @@
---
category: Unified
id: wiki-2026-0508-코드베이스-투어-codebase-tours
title: 코드베이스 투어 Codebase Tours
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 코드베이스 투어 (Codebase Tours)
description: "코드베이스 투어(Codebase Tours)는 특정 기능이나 역할에 맞춰 코드베이스를 단계별로 안내하는 대화형 가이드(Interactive guided tour)입니다 [1, 2]."
last_updated: 2026-05-02
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
---
# 코드베이스 투어 (Codebase Tours)
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
코드베이스 투어(Codebase Tours)는 특정 기능이나 역할에 맞춰 코드베이스를 단계별로 안내하는 대화형 가이드(Interactive guided tour)입니다 [1, 2]. 신규 개발자의 온보딩을 돕거나 팀의 리팩토링 과정을 설명하기 위해 사용되며, 기존의 1대1 멘토링 시간을 크게 절약해 줍니다 [1, 3, 4]. 한 번 구축해 두면 개발자의 경력 수준이나 소속 팀에 맞춰 개인화된 학습 경험을 지속적으로 제공할 수 있습니다 [2, 4, 5].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **대화형 단계별 가이드 (Interactive Guided Tour):**
코드베이스 투어는 개발자가 특정 기능을 수행하기 위해 코드베이스를 단계별로 거쳐 가도록 안내합니다 [1]. 예를 들어, 리팩토링을 주도하는 팀 리더가 작업이 필요한 코드 요소를 보여주는 단계별 투어를 만들거나, 신규 입사자에게 코드 컴포넌트 간의 상호작용 방식을 안내하는 용도로 활용됩니다 [1].
* **사용자 맞춤형 투어 구성 (Customization):**
@@ -26,13 +37,12 @@ last_updated: 2026-05-02
* **주요 이점 (Benefits):**
코드 이해도 향상, 협업 증진, 코드 유지보수성 개선, 버그 수정 속도 단축, 개발 시간 단축, 그리고 효율적인 코드 리뷰에 기여합니다 [2]. 한 번 만들어두면 계속 사용할 수 있어("Build once; use forever") 경험이 많은 시니어 팀원의 귀중한 시간을 절약해 줍니다 [4].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* 코드베이스 투어를 설계하고 구축하는 데에는 팀 리더나 숙련된 개발자의 초기 시간과 노력이 투자되어야 합니다 [1, 4].
* 신규 개발자의 수준(주니어 vs 시니어)이나 팀의 특성에 맞춰 투어를 세심하게 커스터마이징하지 않으면, 적절한 정보를 제공하지 못해 도구의 효용성이 떨어질 수 있습니다 [4, 5].
* 복잡한 PR에 대해 투어 생성을 요구하는 자동화를 도입할 경우, 이는 온보딩에는 훌륭한 자료가 되지만 코드를 푸시하는 개발자에게는 추가적인 문서화 의무 및 작업 부담(Overhead)으로 작용할 수 있습니다 [8, 9].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [개념 이해/기반 지식]
@@ -74,4 +84,53 @@ last_updated: 2026-05-02
- 확장 방향: 시스템의 구조를 정적으로 표현하는 다이어그램이 어떻게 대화형인 코드베이스 투어와 맵의 초기 설계 기반이 되는지 이해 확장
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/하향식 및 상향식 접근법 (Top-Down and Bottom-Up Approaches).md
+54 -15
View File
@@ -1,25 +1,28 @@
---
id: P-REINFORCE-WIKI-8B676153
title: "하향식 및 상향식 접근법 (Top-Down and Bottom-Up Approaches)"
category: Unified
status: draft
canonical_id: ""
aliases: []
duplicate_of: ""
id: wiki-2026-0508-하향식-및-상향식-접근법-top-down-and-botto
title: 하향식 및 상향식 접근법 (Top Down and Bottom Up Approaches)
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: [P-REINFORCE-WIKI-8B676153]
duplicate_of: none
source_trust_level: A
confidence_score: 0.95
tags: ['Top-Down and Bottom-Up Approaches']
raw_sources: ["Datacollector_MAC/out_wiki/하향식 및 상향식 접근법 (Top-Down and Bottom-Up Approaches).md"]
tags: [Top-Down and Bottom-Up Approaches]
raw_sources: [Datacollector_MAC/out_wiki/하향식 및 상향식 접근법 (Top-Down and Bottom-Up Approaches).md]
last_reinforced: 2026-05-02
github_commit: ""
github_commit: pending
tech_stack:
language: unspecified
framework: unspecified
---
# [[하향식 및 상향식 접근법 (Top-Down and Bottom-Up Approaches)]]
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
하향식(Top-Down)과 상향식(Bottom-Up) 접근법은 대규모 소프트웨어 시스템의 코드베이스를 해독하고 탐색할 때 정보의 흐름을 추적하는 두 가지 근본적인 전략입니다 [1]. 하향식 접근법은 외부와 소통하는 최상위 인터페이스에서 시작하여 점진적으로 구현의 상세 로직으로 내려가는 방식이며, 상향식 접근법은 데이터가 도달하는 데이터베이스나 외부 시스템 등에서 시작하여 상위 호출 함수를 역추적하는 방식입니다 [1]. 복잡한 시스템의 전체상을 효율적으로 이해하기 위해서는 비즈니스 의도를 파악하는 하향식과 기술적 한계를 파악하는 상향식을 혼합한 하이브리드 전략이 필수적입니다 [2].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
* **하향식 접근법 (Top-Down Approach):**
* 시스템의 최상위 추상화 계층인 REST API, gRPC 서비스, 사용자 인터페이스(UI), CLI 진입점 등에서 시작하는 방식입니다 [1, 2].
* 호출 스택을 따라 내려가며 시스템의 요청 처리 흐름, 권한 검증, 비즈니스 로직의 오케스트레이션 과정을 관찰합니다 [1, 2].
@@ -34,14 +37,13 @@ github_commit: ""
* 대규모 코드베이스에서는 두 가지 접근법을 상황에 맞게 혼합하는 하이브리드 전략이 가장 효율적입니다 [2].
* 하향식으로 시스템의 비즈니스 목적을 파악하고, 상향식으로 기술적인 제약이나 동작 원리를 확인하며, 이 두 가지가 만나는 중간 지점에서 시스템에 대한 일관된 이해를 형성합니다 [2].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
* **관심 없는 코드 영역 포함 문제:** 하향식 접근법을 취할 경우, 특정 작업에 당장 필요하지 않거나 개발자가 전혀 관심 가질 필요가 없는 수많은 하위 로직과 불필요한 세부 사항까지 한꺼번에 마주칠 수 있는 부작용이 있습니다 [5].
* **탐색의 함정(Rabbit Holes):** 진입점(Entry point)에서 시작해 호출 스택을 따라 내려가다 보면 너무 깊은 세부 구현으로 빠져들어 길을 잃을 위험이 있습니다. 이를 방지하기 위해서는 모든 세부 경로로 즉시 내려가기보다는 시스템의 큰 조각들을 먼저 매핑하는 것이 권장됩니다 [6].
* **비즈니스 컨텍스트 누락의 위험:** 상향식으로 데이터베이스나 개별 컴포넌트부터 파악할 경우, 해당 로직의 세부 기술적 한계는 알 수 있으나 이것이 실제로 어떤 사용자 요구나 비즈니스 목표에 의해 설계되었는지 파악하기 어려울 수 있습니다 [2].
* **단일 접근법의 한계:** 오직 하나의 접근법에만 의존하게 되면 시스템 전체의 조망을 놓치기 쉬우므로, 항상 두 가지 전략을 교차 검증하며 사용해야 합니다 [2].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [코드 구조 및 탐색 전략 (Navigation Strategy & Structure)]
@@ -91,3 +93,40 @@ github_commit: ""
- **기존 유사 문서:** None
- **처리 방식:** CREATE
- **처리 이유:** 신규 지식 체계 도입
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
**언제 이 지식을 쓰는가:**
- *(TODO)*
**언제 쓰면 안 되는가:**
- *(TODO)*
## 🕓 변경 이력 (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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
10_Wiki/Topics/Backend/하향식Top-Down_접근법.md
+70 -10
View File
@@ -1,29 +1,40 @@
---
category: Unified
id: wiki-2026-0508-하향식top-down-접근법
title: 하향식Top Down 접근법
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-wikified, technical-documentation]
title: 하향식(Top-Down) 접근법
description: "하향식(Top-Down) 접근법은 복잡한 소프트웨어 시스템이나 대규모 코드베이스를 파악할 때 사용하는 전략적 탐색 방식입니다[1]."
last_updated: 2026-05-02
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
---
# 하향식(Top-Down) 접근법
## 📌 Brief Summary
## 📌 한 줄 통찰 (The Karpathy Summary)
하향식(Top-Down) 접근법은 복잡한 소프트웨어 시스템이나 대규모 코드베이스를 파악할 때 사용하는 전략적 탐색 방식입니다[1]. 시스템의 최상위 추상화 계층인 사용자 인터페이스(UI)나 공용 API 등 외부 세계와 소통하는 진입점(Entry point)에서 분석을 시작합니다[1, 2]. 이후 호출 스택을 따라 점진적으로 하위 구현 상세로 내려가며, 비즈니스 로직의 흐름과 시스템의 전체적인 가치 사슬을 이해하는 데 중점을 둡니다[1].
## 📖 Core Content
## 📖 구조화된 지식 (Synthesized Content)
- **최상위 진입점 기반 분석**: 하향식 접근법은 고객이나 최종 사용자가 상호작용하는 가장 높은 수준의 인터페이스인 REST API 가이드, gRPC 서비스 정의서, CLI 진입점, 사용자 인터페이스 등에서부터 시작합니다[1, 2].
- **비즈니스 의도 파악**: 세부적인 코드 구현에 매몰되기 전에 시스템의 거시적인 목적을 파악하는 데 유용합니다. 요청 처리의 흐름, 권한 검증, 서비스 오케스트레이션 과정을 관찰하여 시스템의 전체 기능과 사용자 가치 사슬을 파악합니다[1].
- **점진적 심층 탐색(Drill-Down)**: 최상위 수준의 기능에서 출발하여 이를 구성하는 하위 조각들을 하나씩 분해해 가며 가장 낮은 수준의 코드까지 이해를 넓혀나갑니다[2].
- **구조화된 온보딩 및 리뷰 프레임워크**: 새로운 시스템을 파악할 때 최상위 디렉토리 및 빌드 도구를 식별하고, 이후 시스템 시작 파일이나 라우터 등 진입점을 발견한 뒤, 데이터의 끝에서 끝까지(end-to-end) 흐름을 추적하는 하향식 워크플로우는 신규 개발자의 온보딩 과정을 크게 돕습니다[1, 3]. 또한, 풀 리퀘스트(PR)를 리뷰할 때도 큰 그림을 먼저 파악한 뒤 개별 파일의 수정 사항과 핵심 구현 로직으로 파고드는 것이 효과적입니다[4].
## ⚖️ Trade-offs & Caveats
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **불필요한 정보 과부하 위험**: 하향식으로만 코드를 읽어 내려갈 경우, 개발자가 당장 작업해야 하거나 관심을 가질 필요가 없는 방대한 영역의 코드와 종속성까지 모두 포함해서 살펴봐야 하는 비효율성이 발생할 수 있습니다[4].
- **기술적 제약 사항 파악의 한계**: 하향식 접근법은 비즈니스 의도를 파악하는 데는 탁월하지만, 데이터 변환의 구체적인 상태 전이나 데이터베이스 스토리지의 물리적 한계 같은 로우레벨(Low-level)의 제약 사항을 파악하기에는 한계가 있습니다[1].
- **하이브리드 전략의 필요성**: 따라서 하향식 접근법 단독으로만 의존하기보다는, 데이터 종착점에서 역추적하는 **상향식(Bottom-Up) 접근법**과 혼합하여 중간 지점에서 시스템에 대한 일관된 이해를 형성하는 하이브리드(Hybrid) 전략이 필수적입니다[1].
## 🔗 Knowledge Connections
## 🔗 지식 연결 (Graph)
### Related Concepts
#### [분석 및 탐색 전략 (Exploration & Analysis Strategies)]
@@ -61,4 +72,53 @@ last_updated: 2026-05-02
- 확장 방향: 하향식 분석 과정에서 흔히 마주하게 되는 구조로, 코드가 수평적인 층으로 구성되고 상위 계층이 하위 계층에만 의존하는 아키텍처 패턴의 특성과 통신 규칙을 탐구할 수 있습니다.
---
*Last updated: 2026-05-02*
*Last updated: 2026-05-02*
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*