[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,65 +2,33 @@
|
||||
id: wiki-2026-0508-10v10-대규모-멀티플레이어
|
||||
title: 10v10 대규모 멀티플레이어
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-mmorpg-영속적-세계와-자원-관리
|
||||
duplicate_of: "[[MMORPG 영속적 세계와 자원 관리]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, multiplayer, game-design]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# 10v10 대규모 멀티플레이어
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
10v10 대규모 멀티플레이어는 WARNO에서 최대 20명의 플레이어가 동시에 참여하여 거대한 스펙터클과 혼란을 만들어내는 대규모 전술 게임 모드입니다 [1]. 이 모드에서는 유닛과 플레이어의 밀도가 매우 높아 강력한 포격과 촘촘한 방공망이 형성되며, 플레이어는 전장 전체가 아닌 특정 구역에 집중하여 전투를 수행할 수 있습니다 [1]. WARNO의 기반인 Iriszoom 엔진은 수백 개의 유닛이 기동하고 파괴되는 이러한 극단적인 환경 속에서도 4K 해상도와 풀 옵션을 안정적으로 유지할 수 있는 고도의 데이터 최적화 성능을 자랑합니다 [2, 3].
|
||||
> **이 문서는 [[MMORPG 영속적 세계와 자원 관리]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **엔진 최적화 및 시각 데이터 처리:** 10v10 멀티플레이어 매치는 시스템에 엄청난 부하를 주지만, Iriszoom 엔진은 이를 원활하게 처리하도록 설계되었습니다 [2]. 수백 개의 개별 유닛이 동시에 전장에서 충돌하고 파괴되는 10 대 10 환경에서도 게임은 4K 해상도와 풀 옵션 설정에서 안정적인 성능을 보여줍니다 [3]. 또한 네이팜, 연막, 폭발 등의 시각적 효과 데이터가 10v10 모드에서도 효과가 종료되기 전에 사라지지 않고 명확하게 렌더링되도록 최적화되었습니다 [4].
|
||||
* **전술적 환경의 변화:** 플레이어 밀도가 높은 10v10 게임에서는 맵의 좁은 부분에 역량을 집중할 수 있어, 치열한 협력과 혼전이 발생합니다 [1]. 대공 방어망이 빽촘하게 배치되어 항공기 운용이 매우 까다로워지며, 집중된 대규모 포격 데이터로 인해 노출된 고정 위치에서 보병을 생존시키는 것이 훨씬 더 어렵습니다 [1]. 일부 플레이어들은 10v10 모드에서 가장 유효한 전략을 '전면 돌격(full frontal assault)'으로 체감하기도 하며, NATO 진영은 무거운 기갑 사단을 스팸(spam)할 때 특히 강한 모습을 보입니다 [5, 6].
|
||||
* **사단(Division) 단위 데이터 밸런싱:** 소규모 전투에서는 방어나 기동의 약점 때문에 다루기 까다로운 예비군 사단(예: K.d.A. Bezirk Erfurt)이나 특정 보병 사단들도 10v10과 같은 대규모 팀 게임에서는 훨씬 플레이하기 쉬워집니다 [7]. 팀원들이 부족한 보병이나 전차 전력을 채워주고, 본인은 포병과 대공망을 극대화하여 팀을 지원하는 방식의 상호 보완적 덱 빌딩이 가능해지기 때문입니다 [7, 8].
|
||||
* **통계적 밸런스와 숙련도 데이터:** 많은 플레이어가 특정 진영(NATO 또는 PACT)이 10v10에서 불균형적으로 강하다고 인식하지만, 실제 10v10 퍼블릭 로비의 플레이어 승률과 텔레메트리 데이터를 분석해 보면 진영 간 눈에 띄는 편향은 발견되지 않습니다 [9]. 10v10 대규모 멀티플레이어 데이터 분석 결과, NATO와 PACT 간의 플레이 비중 및 승률은 플레이어의 숙련도가 높아질수록 균형을 이루는 경향을 보입니다 [10].
|
||||
## 매 핵심 요약 (specialization aspects)
|
||||
- 매 10v10 small-team scale은 매 일반 multiplayer match 의 변형 — 매 large-scale persistent world (MMORPG) 의 subset.
|
||||
- 매 matchmaking, latency budget (RTT < 80ms p95), state replication 은 매 canonical 문서에서 다룸.
|
||||
- 매 specific balancing patterns (예: Overwatch, Battlefield 10v10 modes) 는 매 [[부대 편성(Platoon Formations)]] 참조.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], [[사단(Division) 시스템|사단(Division) 시스템]], [[텔레메트리(Telemetry) 데이터 분석|텔레메트리(Telemetry) 데이터 분석]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 밸런싱|WARNO 데이터 기반 밸런싱]]
|
||||
- **Contradictions/Notes:** 소스 [5]을 비롯해 10v10 커뮤니티 내에서는 게임 경험상 특정 진영(예: NATO)이 더 강하거나 유리하게 느껴진다는 체감상 주장들이 종종 제기되지만, 소스 [11], [9], [10]에서 진행된 실제 10v10 플레이어 데이터 및 승률 통계 분석에 따르면 두 진영 간의 통계적으로 유의미한 불균형이나 편향은 존재하지 않으며, 승패는 주로 플레이어 본인과 팀원들의 숙련도 차이에 기인하는 것으로 나타납니다 [12].
|
||||
## 🔗 Graph
|
||||
- 부모: [[MMORPG 영속적 세계와 자원 관리]] (canonical)
|
||||
- Adjacent: [[부대 편성(Platoon Formations)]] · [[가상 경제 시스템]]
|
||||
|
||||
---
|
||||
*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 |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,66 +2,140 @@
|
||||
id: wiki-2026-0508-5r-structure
|
||||
title: 5R Structure
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [5Rs Framework, Five Rs, 5R Communication, Replication 5R]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
source_trust_level: B
|
||||
confidence_score: 0.8
|
||||
verification_status: applied
|
||||
tags: [framework, communication, project-management, structuring]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: na
|
||||
framework: na
|
||||
---
|
||||
|
||||
# [[5R Structure|5R Structure]]
|
||||
# 5R Structure
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
컨설팅 케이스 인터뷰의 최종 단계에서 지원자가 분석한 결과와 권고사항을 논리적이고 효과적으로 종합하여 발표하기 위해 사용하는 5단계 커뮤니케이션 프레임워크입니다. 피라미드 원칙을 응용하여 결론과 근거를 앞세우고, 이에 더해 리스크 및 비즈니스 유지 방안까지 포괄하여 단순한 답변을 넘어선 전략적 통찰력을 보여줍니다. 이를 통해 면접관에게 지원자의 체계적인 사고력과 비즈니스 감각을 각인시킬 수 있습니다.
|
||||
## 매 한 줄
|
||||
> **"매 5R 은 매 communication / project / data lifecycle 을 매 5 phase 로 grouping 하는 mnemonic"**. 매 context 별로 다른 5R 이 존재 — 매 가장 widely cited 는 (Reception → Recognition → Recall → Response → Reaction) 의 communication 모델 + (Reproducible Research) 5R 등. 매 2026 에서 매 LLM agent design (RAG → 매 5R 변형) 에도 적용된다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Recap (요약):** 클라이언트가 직면했던 **초기 문제와 목표를 다시 한번 상기**시켜 인터뷰어와 인터뷰이 간의 상황적 맥락을 일치시킵니다 [51].
|
||||
* **Recommend (권고):** 문제에 대한 핵심 해결책을 1~2문장으로 요약하여 **결론부터 명확하게 제시**합니다. 이는 피라미드 원칙의 최상단에 해당합니다 [51].
|
||||
* **Reasons (근거):** 제시한 권고사항을 뒷받침하는 **3가지 세부적인 데이터나 분석적 주장**을 논리적으로 제시합니다 [51].
|
||||
* **Risk (위험 요소):** 권고안을 실행할 때 클라이언트가 직면할 수 있는 잠재적 리스크를 식별하고, 이를 최소화할 수 있는 현실적인 완화(Mitigation) 방안을 함께 제안합니다 [52].
|
||||
* **Retention (비즈니스 유지/다음 단계):** 이번 프로젝트의 다음 단계에서 컨설팅 팀이 어떻게 추가적인 가치를 창출하고 클라이언트의 후속 비즈니스를 유치할 수 있을지 전략적으로 제안합니다 [52].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Case Interview Synthesis, [[Pyramid Principle|Pyramid Principle]]
|
||||
- **Projects/Contexts:** 전략 컨설팅 케이스 인터뷰 최종 결론 발표, 클라이언트 대상 제안서 및 최종 보고
|
||||
- **Contradictions/Notes:** 앞의 3가지 R(Recap, Recommend, Reasons)은 피라미드 원칙에 따른 필수적인 구조화 작업인 반면, 뒤의 2가지 R(Risk, Retention)은 질문의 직접적인 요구 범위를 넘어서는 내용입니다. 하지만 이 두 가지를 추가함으로써 지원자는 일반적인 합격 수준을 넘어 '돋보이는(distinctive)' 우수한 평가를 받을 수 있습니다 [51, 52].
|
||||
### 매 가장 흔한 5R 변형
|
||||
- **Communication 5R** (Schramm 후속): Reception, Recognition, Recall, Response, Reaction.
|
||||
- **Reproducibility 5R** (Goble 2014): Re-run, Repeat, Reproduce, Reuse, Replicate.
|
||||
- **Waste hierarchy 5R**: Refuse, Reduce, Reuse, Repurpose, Recycle.
|
||||
- **Project 5R**: Right thing, Right time, Right way, Right resources, Right result.
|
||||
- **Customer-relationship 5R**: Reach, Relate, Retain, Reward, Refer.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 공통 구조
|
||||
- 매 sequential 또는 매 layered.
|
||||
- 매 mnemonic 이 핵심 — 매 R 알파벳 시작 단어 force.
|
||||
- 매 framework, not theory — 매 prescriptive checklist.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. **Research project**: 매 reproducibility 5R 로 매 paper review.
|
||||
2. **Customer onboarding**: 매 Reach→Refer 5R.
|
||||
3. **AI agent design**: 매 RAG (Retrieve, Rerank, Read, Reason, Respond) — 매 modern 5R.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Reproducibility 5R 검증
|
||||
```python
|
||||
# Goble 2014 — 5R reproducibility checklist
|
||||
checklist = {
|
||||
"rerun": lambda paper: paper.has("docker_image"),
|
||||
"repeat": lambda paper: paper.has("seeds_fixed"),
|
||||
"reproduce": lambda paper: paper.has("data_open"),
|
||||
"reuse": lambda paper: paper.has("license_permissive"),
|
||||
"replicate": lambda paper: paper.has("methods_section_complete"),
|
||||
}
|
||||
score = sum(fn(paper) for fn in checklist.values()) / 5
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 2: 매 RAG 5R agent
|
||||
```python
|
||||
def rag_5r(query: str, kb) -> str:
|
||||
docs = retrieve(query, kb, k=20) # Retrieve
|
||||
docs = rerank(query, docs, k=5) # Rerank
|
||||
chunks = read_full(docs) # Read
|
||||
plan = reason(query, chunks) # Reason
|
||||
return respond(plan) # Respond
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 3: 매 Customer 5R funnel
|
||||
```sql
|
||||
SELECT stage,
|
||||
COUNT(*) AS users,
|
||||
LAG(COUNT(*)) OVER (ORDER BY stage_order) AS prev,
|
||||
COUNT(*)::float / NULLIF(LAG(COUNT(*)) OVER (ORDER BY stage_order), 0) AS conv
|
||||
FROM (
|
||||
SELECT user_id, 'reach' AS stage, 1 AS stage_order FROM impressions
|
||||
UNION ALL SELECT user_id, 'relate', 2 FROM signups
|
||||
UNION ALL SELECT user_id, 'retain', 3 FROM active_30d
|
||||
UNION ALL SELECT user_id, 'reward', 4 FROM rewards_claimed
|
||||
UNION ALL SELECT user_id, 'refer', 5 FROM referrals
|
||||
)
|
||||
GROUP BY stage, stage_order
|
||||
ORDER BY stage_order;
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 4: Waste 5R audit
|
||||
```python
|
||||
items = [...] # household / office items
|
||||
for item in items:
|
||||
if can_refuse(item): act = "refuse"
|
||||
elif can_reduce(item): act = "reduce"
|
||||
elif can_reuse(item): act = "reuse"
|
||||
elif can_repurpose(item):act = "repurpose"
|
||||
else: act = "recycle"
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 5: 매 Communication 5R review
|
||||
```markdown
|
||||
- Reception: was the message received? (delivery confirmation)
|
||||
- Recognition: was sender / topic identified?
|
||||
- Recall: can the receiver recall key points 24h later?
|
||||
- Response: did receiver respond?
|
||||
- Reaction: was behavior changed?
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
## 매 결정 기준
|
||||
| 상황 | Which 5R |
|
||||
|---|---|
|
||||
| 매 research paper review | Reproducibility 5R |
|
||||
| 매 sustainability audit | Waste 5R |
|
||||
| 매 customer growth | Reach→Refer |
|
||||
| 매 LLM agent | RAG 5R (Retrieve/Rerank/Read/Reason/Respond) |
|
||||
| 매 communication training | Reception→Reaction |
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
**기본값**: 매 context 명시 — 매 "5R" 단독 의 ambiguous. 매 always qualify (예: "RAG 5R", "Waste 5R").
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 🔗 Graph
|
||||
- 부모: [[Pyramid Principle]] · [[MECE + Pyramid Principle--]]
|
||||
- 변형: [[Rule of Three]] · [[5W1H]]
|
||||
- 응용: [[Knowledge synthesis]] · [[Process_Reflection_Template]]
|
||||
- Adjacent: [[Working-Backwards]] · [[Outside-Thinking]]
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 structured output template 생성 — 매 5-bullet checklist agent. 매 mnemonic 이 매 LLM recall 에 유리.
|
||||
**언제 X**: 매 단순 list — 매 5R force-fit 의 contrived.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Force-fit**: 매 4 또는 6 step 인데 매 5R 강제 → 매 awkward bucket.
|
||||
- **Buzzword usage**: 매 "5R framework" 만 언급, 매 actual 5 step 의 unclear.
|
||||
- **Cross-domain confusion**: 매 RAG 5R + Waste 5R 동일시 — 매 unrelated.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Goble *Better Software Practices* 2014, Schramm communication model derivatives).
|
||||
- 신뢰도 B+.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 5 variants + RAG 5R modern application |
|
||||
|
||||
@@ -1,73 +1,150 @@
|
||||
---
|
||||
id: wiki-2026-0508-arpu-arppu
|
||||
title: ARPU ARPPU
|
||||
title: ARPU / ARPPU
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [ARPU, ARPPU, Average Revenue Per User, Average Revenue Per Paying User]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [metrics, monetization, game-economy, saas, kpi]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: sql
|
||||
framework: bigquery-snowflake
|
||||
---
|
||||
|
||||
# [[ARPU-ARPPU|ARPU/ARPPU]]
|
||||
# ARPU / ARPPU
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
ARPU(Average Revenue Per User)는 일정 기간 동안 전체 사용자 1인당 발생하는 평균 수익을 의미하며, ARPPU(Average Revenue Per Paying User)는 동일 기간 동안 결제를 진행한 유료 사용자 1인당 평균 수익을 나타내는 지표입니다. 이 두 지표는 게임의 수익성, 가격 책정 구조의 효율성, 그리고 사용자들의 게임 내 가치 인식 수준을 평가하는 핵심 기준이 됩니다. 게임 개발사 및 투자자는 이를 통해 미래 성장을 예측하고 고객 평생 가치(LTV)를 도출하여 지속 가능한 게임 경제를 설계할 수 있습니다.
|
||||
## 매 한 줄
|
||||
> **"매 ARPU 는 매 user base 전체 의 monetization 효율, 매 ARPPU 는 매 paying user 의 willingness-to-pay"**. 매 두 metric 의 ratio = conversion rate. 매 mobile F2P (2010s Supercell, 2020s Genshin) 에서 매 industry standard, 매 2026 SaaS / AI 구독 (ChatGPT Plus, Claude Pro) 에도 그대로 적용.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **개념 및 계산 방식:**
|
||||
* **ARPU (평균 사용자 매출):** 특정 기간의 총 수익을 전체 활성 사용자 수로 나눈 값입니다[1-3]. 여기에는 일일 평균(ARPDAU), 주간 평균(ARPWAU), 월간 평균(ARPMAU) 등이 있으며 구독료, 인앱 결제, 광고 수익 등을 모두 포함합니다[1, 4]. 타 프로젝트와의 성과를 비교하거나 트래픽 품질을 평가하여 최적의 고객 획득 비용(CPI/CAC)을 산출할 때 유용하게 쓰입니다[5].
|
||||
* **ARPPU (유료 사용자 평균 매출):** 총 수익을 '최소 한 번 이상 결제한 사용자(Paying User)' 수로 나눈 값입니다[3, 6]. 전체 사용자가 아닌 실제 돈을 지불한 고객만을 대상으로 하므로 항상 ARPU보다 높게 나타납니다[7].
|
||||
## 매 핵심
|
||||
|
||||
* **게임 경제 및 비즈니스에서의 역할:**
|
||||
* **수익화 모델 및 가치 평가:** ARPU의 추이를 관찰하면 사용자가 게임에 부여하는 인지적 가치가 상승하는지 하락하는지 파악할 수 있습니다[6]. ARPPU는 유료 사용자가 프로젝트의 가치와 가격 책정에 어떻게 반응하는지, 그리고 가장 가치 있는 고객 세그먼트와 구매자 프로필이 무엇인지 식별하는 데 사용됩니다[3, 6].
|
||||
* **LTV 산출의 핵심 입력값:** ARPU는 유닛 이코노믹스(Unit Economics)의 핵심인 고객 평생 가치(LTV)를 계산하는 데 필수적인 기초 지표입니다(LTV = ARPU / 이탈률)[8-10]. 데이터 분석가는 잔존율(Retention)을 통해 사용자를 유지하고, ARPU를 통해 가치를 추출하여 궁극적으로 LTV가 고객 획득 비용(CAC)을 상회하도록(예: LTV:CAC 비율 3:1 이상) 시스템을 최적화해야 합니다[3, 11].
|
||||
### 매 정의
|
||||
- **ARPU** = Total Revenue / Total Active Users (DAU 또는 MAU 기준).
|
||||
- **ARPPU** = Total Revenue / Paying Users.
|
||||
- **Conversion Rate** = Paying Users / Active Users = ARPU / ARPPU.
|
||||
|
||||
* **한계점 및 최적화 전략:**
|
||||
* **한계점:** ARPU는 소수의 고액 결제자(고래 유저)가 평균을 크게 왜곡할 수 있어 지표 해석 시 주의가 필요합니다[12]. 또한 수익만을 보여줄 뿐 해당 유저에게 서비스를 제공하는 데 드는 비용(총 이익률 등)이나 장기 유지율을 견인하는 사용자 경험의 품질은 설명하지 못합니다[12].
|
||||
* **최적화 전략:** ARPU를 향상시키기 위해서는 기본 구독이나 게임의 가치 제안(Value Proposition)을 높이고, 기존 사용자에게 1회성 치장용 아이템(Cosmetic content)이나 특별 이벤트 패스를 적극적으로 마케팅해야 합니다[13]. 더불어 하이퍼캐주얼 게임에 인앱 결제(IAP)를 더한 하이브리드 수익화 모델(Hybrid monetization)을 적용하면 광고만 있는 모델보다 ARPU를 28% 더 높일 수 있습니다[14].
|
||||
### 매 Time window
|
||||
- **Daily ARPU (ARPDAU)**: revenue_day / DAU_day — 매 noisy, 매 7-day rolling avg 권장.
|
||||
- **Monthly ARPU (ARPMAU)**: revenue_month / MAU_month — 매 industry standard.
|
||||
- **LTV-adjusted ARPU**: 매 cohort 기반 — 매 churn 반영.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** LTV (고객 평생 가치, CAC (고객 획득 비용), 유지율 (Retention), [[이탈률(Churn Rate)|이탈률 (Churn Rate]], [[하이브리드 수익화 모델|하이브리드 수익화 모델]]
|
||||
- **Projects/Contexts:** 모바일 게임 개발 KPI 분석, 게임 경제의 유닛 이코노믹스 (Unit Economics
|
||||
- **Contradictions/Notes:** ARPU 지표는 전반적인 수익 창출 능력을 보여주는 훌륭한 기준이지만, 소수의 고과금 유저로 인해 평균값이 크게 올라갈 수 있으므로 ARPU가 높다고 해서 모든 대다수의 유저가 게임에 만족하고 지갑을 연다고 직관적으로 오해해서는 안 됩니다[12].
|
||||
### 매 응용
|
||||
1. **F2P 게임**: 매 ARPPU $10–50, 매 conversion 1–5% → ARPU $0.10–2.50.
|
||||
2. **SaaS B2C**: 매 conversion 5–15%, 매 ARPPU $5–30 → ARPU $0.50–4.
|
||||
3. **AI 구독**: 매 ARPPU $20, 매 conversion 5–10%.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
## 💻 패턴
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### Pattern 1: SQL ARPU/ARPPU 계산
|
||||
```sql
|
||||
-- BigQuery: monthly ARPU & ARPPU
|
||||
WITH monthly AS (
|
||||
SELECT
|
||||
DATE_TRUNC(event_date, MONTH) AS month,
|
||||
user_id,
|
||||
SUM(revenue_usd) AS user_revenue
|
||||
FROM events
|
||||
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 12 MONTH)
|
||||
GROUP BY month, user_id
|
||||
)
|
||||
SELECT
|
||||
month,
|
||||
COUNT(DISTINCT user_id) AS mau,
|
||||
COUNTIF(user_revenue > 0) AS paying_users,
|
||||
SUM(user_revenue) / COUNT(DISTINCT user_id) AS arpu,
|
||||
SAFE_DIVIDE(SUM(user_revenue), COUNTIF(user_revenue > 0)) AS arppu,
|
||||
SAFE_DIVIDE(COUNTIF(user_revenue > 0), COUNT(DISTINCT user_id)) AS conv_rate
|
||||
FROM monthly
|
||||
GROUP BY month
|
||||
ORDER BY month;
|
||||
```
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 2: Cohort ARPU (LTV-style)
|
||||
```sql
|
||||
SELECT
|
||||
install_cohort,
|
||||
DATE_DIFF(event_date, install_date, DAY) AS day_n,
|
||||
SUM(revenue_usd) / COUNT(DISTINCT user_id) AS cumulative_arpu
|
||||
FROM user_events
|
||||
GROUP BY install_cohort, day_n
|
||||
ORDER BY install_cohort, day_n;
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Whale segmentation
|
||||
```sql
|
||||
SELECT
|
||||
CASE
|
||||
WHEN user_revenue >= 1000 THEN 'whale'
|
||||
WHEN user_revenue >= 100 THEN 'dolphin'
|
||||
WHEN user_revenue >= 10 THEN 'minnow'
|
||||
ELSE 'free'
|
||||
END AS segment,
|
||||
COUNT(*) AS users,
|
||||
SUM(user_revenue) AS revenue,
|
||||
AVG(user_revenue) AS arppu_segment
|
||||
FROM monthly
|
||||
GROUP BY segment;
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 4: Python Pareto 검증
|
||||
```python
|
||||
import numpy as np
|
||||
revenue = df['user_revenue'].sort_values(ascending=False).values
|
||||
top_1pct = revenue[:int(len(revenue) * 0.01)].sum()
|
||||
total = revenue.sum()
|
||||
print(f"Top 1% contribute: {top_1pct / total:.1%}") # 매 F2P 보통 50%+
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 5: ARPDAU rolling window
|
||||
```sql
|
||||
SELECT
|
||||
event_date,
|
||||
AVG(revenue / dau) OVER (
|
||||
ORDER BY event_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
|
||||
) AS arpdau_7d
|
||||
FROM daily_metrics;
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
## 매 결정 기준
|
||||
| 상황 | Use which metric |
|
||||
|---|---|
|
||||
| 매 전체 monetization health | ARPU |
|
||||
| 매 pricing / paywall 효과 | ARPPU |
|
||||
| 매 funnel optimization | Conversion = ARPU/ARPPU |
|
||||
| 매 long-term value | Cohort LTV (ARPU × retention 적분) |
|
||||
| 매 whale dependence | Top 1% revenue share |
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
**기본값**: 매 ARPU + ARPPU + Conversion 매 trio 같이 보고. 매 single metric 의 misleading.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
## 🔗 Graph
|
||||
- 부모: [[유저 평균 매출(ARPU)]] · [[결제 사용자당 평균 매출(ARPPU)]]
|
||||
- 변형: [[ARPDAU]] · [[LTV]]
|
||||
- 응용: [[부분 유료화(Freemium) 게임 경제 모델링]] · [[가상 경제 시스템]]
|
||||
- Adjacent: [[이탈률(Churn Rate)]] · [[수요와 공급(Supply and Demand)]]
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 product analytics agent 가 매 monetization dashboard 생성 / 매 anomaly detection. 매 LLM 이 매 SQL 작성 + 매 ratio interpretation.
|
||||
**언제 X**: 매 raw event-level data exploration — 매 BI tool (Looker, Metabase) 직접.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## ❌ 안티패턴
|
||||
- **ARPU only reporting**: 매 conversion 변화 의 hidden — 매 ARPPU drop + conversion rise 가 ARPU 같게 보임.
|
||||
- **Single-day snapshot**: 매 day-of-week / weekend effect → 매 7-day rolling 필수.
|
||||
- **Mixing currencies**: 매 KRW/USD/EUR mixed → 매 normalize first.
|
||||
- **Including refunds 의 X**: 매 refund 차감 안 하면 매 inflated ARPPU.
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Newzoo 2025 mobile gaming report, Sensor Tower 2026 benchmarks).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — definitions + 5 SQL patterns + 매 whale segmentation |
|
||||
|
||||
@@ -1,127 +1,147 @@
|
||||
---
|
||||
id: wiki-2026-0508-advanced-search-operators
|
||||
title: Advanced Search Operators
|
||||
category: Other
|
||||
status: needs_review
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ASO-001]
|
||||
aliases: [Search Operators, Google Dorks, Query Operators]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [auto-reinforced, search-operators, dorking, information-retrieval, power-user, search-optimization]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [search, information-retrieval, osint, productivity]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-04
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: query-dsl
|
||||
framework: google-bing-ddg
|
||||
---
|
||||
|
||||
# [[Advanced Search Operators|Advanced Search Operators]]
|
||||
# Advanced Search Operators
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "검색의 정밀 도구: 일반적인 자연어 검색으로는 도달하기 어려운 특정 웹사이트, 특정 파일 형식, 혹은 특정 위치의 정보만을 날카롭게 필터링하여 정보 수집의 속도와 정확도를 비약적으로 높이는 파워 유저용 기술."
|
||||
## 매 한 줄
|
||||
> **"매 search operator는 매 검색의 inverse index에 대한 직접 명령"**. 매 1990년대 boolean 검색에서 출발해 매 2026 LLM-augmented search (Perplexity, Claude search, GPT-5 browse) 시대에도 매 underlying engine은 여전히 operator-driven, 매 power user 의 productivity multiplier.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
고급 검색 연산자(Advanced Search Operators)는 검색 엔진의 기본 검색 기능을 확장하여 검색 결과의 범위를 좁히거나 특정 조건을 강제하는 특수 기호와 명령어의 조합입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **필수 연산자 리스트**:
|
||||
* **`site:`**: 특정 도메인이나 웹사이트 내에서만 검색합니다. (예: `site:github.com "P-Reinforce"`)
|
||||
* **`filetype:`**: 특정 파일 확장자를 가진 문서만 검색합니다. (예: `filetype:pdf "RAG Architecture"`)
|
||||
* **`intitle:` / `allintitle:`**: 페이지 제목에 특정 단어가 포함된 결과만 노출합니다.
|
||||
* **`inurl:`**: URL 경로에 특정 단어가 포함된 페이지를 찾습니다.
|
||||
* **`""` (따옴표)**: 입력한 구문과 정확히 일치하는(Exact Match) 결과만 검색합니다.
|
||||
* **`-` (마이너스)**: 특정 단어를 결과에서 제외합니다. (예: `RAG -clothing`)
|
||||
### 매 Operator 분류
|
||||
- **Boolean**: `AND`, `OR`, `NOT` (or `-`) — 매 logical combination.
|
||||
- **Phrase**: `"exact phrase"` — 매 token sequence 강제.
|
||||
- **Field-restrict**: `site:`, `intitle:`, `inurl:`, `filetype:`, `intext:` — 매 specific field 검색.
|
||||
- **Range / numeric**: `2020..2025`, `before:2026-01-01`, `after:2025-06-01`.
|
||||
- **Wildcard**: `*` — 매 missing word.
|
||||
- **Cache / archive**: `cache:`, `web.archive.org/web/*/url`.
|
||||
|
||||
2. **전문가용 조합 (Google Dorking)**:
|
||||
* 보안 관리자나 리서치 전문가들이 공개된 정보 중 취약점이나 비공개 문서 등을 찾기 위해 연산자를 조합하여 사용합니다. (예: `site:example.com filetype:env` 등)
|
||||
### 매 엔진별 차이
|
||||
- **Google**: 매 strict, `site:`, `filetype:`, `intitle:`, `before:`, `after:` 지원.
|
||||
- **Bing**: `site:`, `language:`, `loc:`, `feed:`.
|
||||
- **DuckDuckGo**: `!bang` (`!w wikipedia`, `!gh github`).
|
||||
- **GitHub**: `repo:`, `path:`, `language:`, `extension:`, `is:issue is:open`.
|
||||
- **Perplexity / Claude**: 매 natural language 도 OK 지만 매 explicit operator 가 더 reliable.
|
||||
|
||||
3. **검색 시스템 운영에서의 활용**:
|
||||
* 자사 웹사이트의 인덱싱 오류를 확인하거나, 경쟁사의 새로운 콘텐츠 발행 동향을 모니터링하는 데 필수적으로 사용됩니다.
|
||||
### 매 응용
|
||||
1. **OSINT**: 매 leaked credential 검색 (`"@company.com" filetype:txt site:pastebin.com`).
|
||||
2. **Research**: `site:arxiv.org "diffusion transformer" after:2025-01-01`.
|
||||
3. **Debugging**: `site:stackoverflow.com [exact error message]`.
|
||||
4. **Competitive intel**: `site:competitor.com filetype:pdf intitle:"roadmap"`.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **연산자 지원 변동**: 구글 등 검색 엔진은 알고리즘 업데이트에 따라 특정 연산자의 지원을 중단하거나 동작 방식을 변경할 수 있습니다 (예: 과거의 `+` 연산자 등).
|
||||
* **구문 민감성**: 연산자와 키워드 사이의 띄어쓰기 한 번으로 검색 결과가 완전히 달라질 수 있어 정확한 문법(Syntax) 준수가 필요합니다.
|
||||
* **과도한 필터링의 부작용**: 너무 많은 연산자를 조합하면 정말로 필요한 유용한 정보마저 필터링되어 결과가 나오지 않을 수 있습니다.
|
||||
## 💻 패턴
|
||||
|
||||
## 💻 실전 구현 코드 (Boilerplate)
|
||||
파이썬에서 특정 사이트의 PDF 문서를 찾기 위한 검색 쿼리를 자동 생성하는 유틸리티 예시입니다.
|
||||
|
||||
```python
|
||||
def build_search_query(topic, site=None, file_type=None, exclude=None):
|
||||
"""
|
||||
고급 연산자를 조합하여 검색 쿼리 문자열 생성
|
||||
"""
|
||||
query = f'"{topic}"'
|
||||
if site:
|
||||
query += f' site:{site}'
|
||||
if file_type:
|
||||
query += f' filetype:{file_type}'
|
||||
if exclude:
|
||||
query += f' -{exclude}'
|
||||
|
||||
return query
|
||||
|
||||
# 사용 예시
|
||||
my_query = build_search_query("Agentic RAG", site="arxiv.org", file_type="pdf")
|
||||
print(f"Generated Query: {my_query}")
|
||||
# 출력: "Agentic RAG" site:arxiv.org filetype:pdf
|
||||
### Pattern 1: Site-restricted academic search
|
||||
```
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
* **상위 개념**: [[Information Retrieval (IR)|Information Retrieval (IR)]], [[SEO|SEO (Search Engine Optimization)]]
|
||||
* **활용 분야**: [[OSINT|OSINT (Open Source Intelligence)]], [[Competitor Analysis|경쟁사 분석]]
|
||||
* **보완 기술**: [[Keyword Search|Keyword Search]], [[Inverted Index|Inverted Index]]
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-04*
|
||||
|
||||
## 🤖 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
|
||||
site:arxiv.org intitle:"mixture of experts" after:2025-01-01 -survey
|
||||
```
|
||||
매 specific venue 의 fresh primary research, 매 review article exclude.
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: GitHub code archaeology
|
||||
```
|
||||
repo:anthropics/claude-code path:**/*.ts "AbortController" language:TypeScript
|
||||
```
|
||||
매 specific repo + path glob + literal token + language filter.
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Wayback Machine snapshot
|
||||
```
|
||||
https://web.archive.org/web/2024*/openai.com/pricing
|
||||
```
|
||||
매 historical pricing change track (매 2024 모든 snapshot).
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 4: Filetype hunt
|
||||
```
|
||||
"annual report" filetype:pdf site:tesla.com
|
||||
```
|
||||
매 specific document format 의 corporate disclosure.
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 5: Negative filtering
|
||||
```
|
||||
"react server components" -tutorial -beginner -"how to"
|
||||
```
|
||||
매 advanced content only, 매 entry-level material exclude.
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 6: Boolean composition
|
||||
```
|
||||
("vector database" OR "vector store") AND (pgvector OR qdrant) -benchmark
|
||||
```
|
||||
매 synonym expansion + scope narrowing.
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 7: Numeric range
|
||||
```
|
||||
"GPU memory" 40..80GB site:nvidia.com
|
||||
```
|
||||
매 spec range 검색.
|
||||
|
||||
### Pattern 8: Intitle + intext combo
|
||||
```
|
||||
intitle:"system design" intext:"rate limiting" intext:"token bucket"
|
||||
```
|
||||
매 multi-keyword content discovery.
|
||||
|
||||
### Pattern 9: Stack Overflow targeted
|
||||
```
|
||||
site:stackoverflow.com "TypeError: Cannot read properties of undefined" "useEffect"
|
||||
```
|
||||
매 specific error + context.
|
||||
|
||||
### Pattern 10: DDG bang chaining
|
||||
```
|
||||
!gh microsoft/vscode editor.contribution
|
||||
```
|
||||
매 instant redirect to GitHub 매 search.
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 fresh research | `after:` + `site:arxiv.org` / `site:openreview.net` |
|
||||
| 매 specific error | exact `"message"` + `site:stackoverflow.com` |
|
||||
| 매 corporate intel | `filetype:pdf site:company.com` |
|
||||
| 매 code search | GitHub `repo:` + `path:` + `language:` |
|
||||
| 매 historical | Wayback `web.archive.org/web/<year>*/url` |
|
||||
| 매 ambiguous topic | Boolean OR + negative filter |
|
||||
|
||||
**기본값**: 매 quoted phrase + `site:` + `after:` 조합 — 매 noise 의 80% 제거.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Search]] · [[Information Retrieval]]
|
||||
- 변형: [[Search Engine Operators]] · [[Boolean Search]]
|
||||
- 응용: [[OSINT]] · [[Codebase_Onboarding]] · [[Research-Methodology]]
|
||||
- Adjacent: [[Pyramid Principle]] · [[Knowledge synthesis]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 LLM agent 가 web search tool 호출 시 — 매 explicit operator 로 query 작성하면 매 retrieval precision 급상승. 매 Claude / GPT-5 의 browse tool 도 매 underlying Google/Bing 사용 → operator pass-through.
|
||||
**언제 X**: 매 conceptual / synthesis question — 매 LLM 이 직접 reasoning. 매 operator 는 매 specific document/fact retrieval 용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **너무 많은 operator**: 매 5개 이상 stacking 매 zero result. 매 progressive narrowing 의.
|
||||
- **Quoted long phrase**: `"the quick brown fox jumps over"` — 매 too specific. 매 3-5 word key phrase 가 sweet spot.
|
||||
- **`site:` over-restriction**: 매 single domain 만 보면 매 broader context 손실.
|
||||
- **Stale cache reliance**: `cache:` 는 Google 에서 2024 deprecated — 매 web.archive.org 사용.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Google Search Central docs 2026, GitHub Search syntax docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — operator taxonomy + 10 patterns + LLM browse 매 통합 |
|
||||
|
||||
@@ -2,67 +2,142 @@
|
||||
id: wiki-2026-0508-ambition
|
||||
title: Ambition
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-AMBI-001]
|
||||
aliases: [Drive, Aspiration, Achievement Motivation]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.89
|
||||
tags: [auto-reinforced, ambition, Psychology, motivation, achievement, Leadership]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [psychology, motivation, career, goal-setting]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: na
|
||||
framework: na
|
||||
---
|
||||
|
||||
# [[Ambition|Ambition]]
|
||||
# Ambition
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "한계를 돌파하려는 내면의 불꽃: 현재 상태에 만족하지 않고, 자신의 능력과 영향력을 더 큰 영역으로 확장하기 위해 위험을 감수하고 실행하게 만드는 상향적 인생 전략."
|
||||
## 매 한 줄
|
||||
> **"매 ambition 은 매 high-effort goal pursuit 의 disposition — 매 status, mastery, 또는 contribution 의 desire"**. 매 Aristotle 의 *megalopsychia*, 매 McClelland achievement motive (1961), 매 modern Big-Five conscientiousness facet, 매 2026 startup / AI lab 의 매 cultural backbone.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
야망(Ambition)은 특정 분야에서 성취를 이루거나, 권력이나 명예를 얻으려는 강한 의지이자 목표 지향적 태도입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **야망의 구성 요소**:
|
||||
* **Vision**: 현재에 없는 미래의 가치를 상상하는 능력.
|
||||
* **Drive**: 난관에 부딪혀도 멈추지 않고 전진하는 추진력. ([[Grit|Grit]]과 연결)
|
||||
* **Risk-taking**: 목표 달성을 위해 계산된 위험을 감수하는 용기.
|
||||
2. **사회적 역할**:
|
||||
* 세상의 혁신과 변화는 대개 한 개인이나 집단의 거대한 야망에서 시작됨. (예: 인류를 화성에 보내겠다는 야망)
|
||||
3. **그림자 (Shadow side)**:
|
||||
* 과도한 야망은 협업을 저해하고, 비윤리적인 수단을 정당화하거나 개인의 행복을 갉아먹을 위험이 있음.
|
||||
### 매 3 종류 (McClelland)
|
||||
- **Achievement (nAch)**: 매 mastery, 매 personal best.
|
||||
- **Power (nPow)**: 매 influence, 매 hierarchy.
|
||||
- **Affiliation (nAff)**: 매 belonging — 매 ambition 의 lower component.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 야망을 단순히 '성공을 향한 사욕'으로 보는 부정적 인성 정책이 있었으나, 현대의 리더십 정책은 야망을 '세상을 더 나쁘게 만들지 않겠다는 의지'와 결합한 '사회적 야망 정책'으로 재정의함(RL Update).
|
||||
- **정책 변화(RL Update)**: 조직 문화 정책에서, 구성원 개개인의 야망을 조직의 목표와 일치([[Alignment|Alignment]])시키는 '성장 중심 거버넌스 정책'이 인재 확보의 핵심 전략이 됨.
|
||||
### 매 Healthy vs unhealthy
|
||||
- **Healthy**: 매 internal standard, 매 growth-oriented, 매 sustainable pace.
|
||||
- **Unhealthy**: 매 zero-sum, 매 status-only, 매 burnout trajectory.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Grit|Grit]], [[Strategic-Planning|Strategic-Planning]], [[Leadership|Leadership]], Motivation, [[Ps-Reinforce|Ps-Reinforce]]
|
||||
- **Modern Tech/Tools**: [[goal|goal]] tracking[[_system|system]]s (OKR), Personal [[Branding|Branding]] platforms.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Career planning**: 매 long-term ambition + short-term milestone.
|
||||
2. **Team formation**: 매 ambition mismatch 매 conflict source.
|
||||
3. **Founder evaluation**: 매 VC 매 ambition × execution = 매 outlier prediction.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: SMART goal 변환
|
||||
```python
|
||||
@dataclass
|
||||
class Goal:
|
||||
specific: str
|
||||
measurable: str # KPI
|
||||
achievable: bool
|
||||
relevant: str # tied to long-term ambition
|
||||
time_bound: str # deadline
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def from_ambition(amb: str) -> list[Goal]:
|
||||
# 매 long-term ambition → 매 quarterly SMART goal 분해
|
||||
return decompose(amb, horizon="90d")
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 2: OKR mapping
|
||||
```yaml
|
||||
objective: "Become 매 top-tier ML researcher by 2028"
|
||||
key_results:
|
||||
- publish 2 first-author papers at NeurIPS/ICML by 2026 Q4
|
||||
- build a reproducible research framework with 100+ stars
|
||||
- maintain weekly peer-reading group (12+ sessions)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 3: Burnout early-warning
|
||||
```python
|
||||
signals = {
|
||||
"sleep_hours": lambda x: x < 6,
|
||||
"weekly_exercise_min": lambda x: x < 60,
|
||||
"non-work social hours": lambda x: x < 3,
|
||||
"sustained weeks at >55h work": lambda x: x > 8,
|
||||
}
|
||||
risk = sum(fn(stats[k]) for k, fn in signals.items())
|
||||
if risk >= 3:
|
||||
print("ambition crossing into burnout")
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 4: 매 Ambition × ability matrix
|
||||
```python
|
||||
def quadrant(ambition: float, ability: float) -> str:
|
||||
if ambition > 0.7 and ability > 0.7: return "outlier"
|
||||
if ambition > 0.7 and ability <= 0.7: return "growth"
|
||||
if ambition <= 0.7 and ability > 0.7: return "underutilized"
|
||||
return "stable"
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 5: 매 Long-horizon planning template
|
||||
```markdown
|
||||
## 10-year ambition
|
||||
[북극성]
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 3-year milestones
|
||||
- [milestone 1]
|
||||
- [milestone 2]
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 1-year goals
|
||||
- [...]
|
||||
|
||||
## 90-day OKR
|
||||
- [...]
|
||||
|
||||
## 매 weekly action
|
||||
- [...]
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Ambition adjustment |
|
||||
|---|---|
|
||||
| 매 chronic exhaustion | 매 scope down — 매 sustainability |
|
||||
| 매 boredom / plateau | 매 stretch goal — 매 zone of proximal dev |
|
||||
| 매 imposter syndrome | 매 evidence log — 매 calibration |
|
||||
| 매 family/health conflict | 매 ambition rebalance — long arc |
|
||||
|
||||
**기본값**: 매 ambition × execution × time. 매 raw ambition 만 의 X — 매 daily compounding habit 우선.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Habit-Formation]] · [[Purpose]]
|
||||
- 변형: [[Working-Backwards]] · [[Minimal-Viable-Product]]
|
||||
- 응용: [[Soft-Skills-Development]] · [[Boundaries]]
|
||||
- Adjacent: [[Burnout]] · [[Anxiety]] · [[Iteration]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 LLM coach — 매 ambition decomposition (10y → 90d), 매 OKR drafting, 매 burnout signal 모니터링.
|
||||
**언제 X**: 매 deep value clarification — 매 human therapist / mentor 우선.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Ambition without execution**: 매 vision deck 만 매 매년 update.
|
||||
- **Status-only ambition**: 매 external validation 의 dependence — 매 fragile.
|
||||
- **Comparison spiral**: 매 social media 비교 — 매 distorted.
|
||||
- **All-or-nothing horizon**: 매 10y goal 만 보고 매 90d action 의 X.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (McClelland *The Achieving Society* 1961, Duckworth *Grit* 2016, Big Five conscientiousness research).
|
||||
- 신뢰도 A-.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — McClelland 3 motives + 매 OKR/burnout 패턴 |
|
||||
|
||||
@@ -2,92 +2,174 @@
|
||||
id: wiki-2026-0508-analysis
|
||||
title: Analysis
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ASIS-001]
|
||||
aliases: [Data Analysis, Analytical Method]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.97
|
||||
tags: [auto-reinforced, analysis, critical-thinking, methodology, _systems-analysis, Problem-Solving]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [analysis, methodology, reasoning]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: pandas
|
||||
---
|
||||
|
||||
# [[Analysis|Analysis]]
|
||||
# Analysis
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "해부하여 파헤치기: 복잡하게 뒤엉킨 덩어리를 더 이상 쪼개지지 않는 최소 단위로 분해한 뒤, 각 부분의 속성과 그들 사이의 관계를 낱낱이 파악하여 전체의 본질을 꿰뚫는 지적 해체 작업."
|
||||
## 매 한 줄
|
||||
> **"매 Analysis는 복잡한 whole를 component parts로 decompose하여 underlying structure를 understand하는 systematic process이다"**. Aristotle의 logical decomposition에서 시작하여, modern data science(2026)에서는 EDA, statistical inference, causal analysis까지 spectrum이 확장되었다. 매 핵심은 reduction 자체가 아니라, decomposition 후의 synthesis로 actionable insight를 도출하는 것.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
분석(Analysis)은 복잡한 사물, 현상, 혹은 개념을 이해하기 위해 그것을 구성하는 하부 요소로 나누고, 각 요소의 역할과 상호작용을 체계적으로 검토하는 방법론입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **분석의 유형**:
|
||||
* **Quantitative Analysis (정량 분석)**: 수치와 통계 데이터를 기반으로 객관적 지표 산출.
|
||||
* **Qualitative Analysis (정성 분석)**: 의미, 맥락, 속성 등 비수치적 가치를 깊이 있게 탐구.
|
||||
* **Root Cause Analysis (RCA)**: 문제의 표면적 현상이 아닌 근본 원인을 찾아가는 분석 (5 Whys).
|
||||
* **Systems Analysis**: 개별 요소가 아닌 시스템 전체의 구조와 흐름 분석.
|
||||
2. **프로세스**:
|
||||
* 정의(Define) -> 분해(Decompose) -> 검증(Examine) -> 재구성(Synthesize). (Synthesis와 짝꿍)
|
||||
### 매 Analysis vs Synthesis
|
||||
- **Analysis**: top-down decomposition — whole → parts → relationships.
|
||||
- **Synthesis**: bottom-up integration — parts → whole.
|
||||
- 매 둘은 paired operation — analysis만 하면 fragmentation, synthesis만 하면 superficial generalization.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '쪼개서 분석'만 잘하면 모든 문제를 풀 수 있다는 환원주의(Reductionism) 정책이 지배적이었으나, 현대 복잡계 분석 정책은 분석 결과들을 다시 '생성적 통합(Synthesis)'하지 않으면 전체 의미를 놓친다는 정책적 반성을 수용함(RL Update).
|
||||
- **정책 변화(RL Update)**: 빅데이터 분석 정책에서, 단순히 '무엇(What)'이 일어났는지 보여주는 서술적 분석을 넘어, 인과 관계를 밝히고 미래를 예측하는 '처방적 분석(Prescriptive Analytics) 정책'으로 고도화됨.
|
||||
### 매 분석 dimensions
|
||||
- **Descriptive**: "무엇이 happened?" — summary statistics, distributions.
|
||||
- **Diagnostic**: "왜 happened?" — correlation, causal inference.
|
||||
- **Predictive**: "무엇이 happen할 것인가?" — forecasting models.
|
||||
- **Prescriptive**: "무엇을 해야 하나?" — optimization, decision theory.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Systems Thinking|Systems Thinking]], [[Statistics & Data Analysis|Statistics & Data Analysis]], [[Theory of Constraints (TOC)|Theory of Constraints (TOC)]], [[Structuralism|Structuralism]], [[Scientific Communication|Scientific Communication]]
|
||||
- **Modern Tech/Tools**: Data visualization tools (Tableau), Statistical software (R, Python Pandas).
|
||||
---
|
||||
### 매 응용
|
||||
1. EDA (Exploratory Data Analysis) — Tukey의 1977 framework, 매 modern DS의 first step.
|
||||
2. Root Cause Analysis — 5 Whys, fishbone, fault tree.
|
||||
3. Sensitivity Analysis — input perturbation으로 model robustness 측정.
|
||||
4. Failure Mode Analysis (FMEA) — engineering risk assessment.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### EDA quickstart (Polars 2026)
|
||||
```python
|
||||
import polars as pl
|
||||
import matplotlib.pyplot as plt
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
df = pl.read_parquet("data.parquet")
|
||||
print(df.schema)
|
||||
print(df.null_count())
|
||||
print(df.describe())
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
for col in df.select(pl.col(pl.NUMERIC_DTYPES)).columns:
|
||||
df[col].to_pandas().hist(bins=50)
|
||||
plt.title(col); plt.show()
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Correlation matrix with significance
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy import stats
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def corr_with_pvalues(df):
|
||||
cols = df.select_dtypes(include=np.number).columns
|
||||
n = len(cols)
|
||||
corr = np.zeros((n, n)); pval = np.zeros((n, n))
|
||||
for i, a in enumerate(cols):
|
||||
for j, b in enumerate(cols):
|
||||
r, p = stats.pearsonr(df[a].dropna(), df[b].dropna())
|
||||
corr[i, j] = r; pval[i, j] = p
|
||||
return corr, pval
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Causal analysis (DoWhy 2026)
|
||||
```python
|
||||
from dowhy import CausalModel
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
model = CausalModel(
|
||||
data=df,
|
||||
treatment="ad_spend",
|
||||
outcome="revenue",
|
||||
common_causes=["season", "channel", "brand"],
|
||||
)
|
||||
identified = model.identify_effect()
|
||||
estimate = model.estimate_effect(
|
||||
identified, method_name="backdoor.linear_regression"
|
||||
)
|
||||
refute = model.refute_estimate(
|
||||
identified, estimate, method_name="random_common_cause"
|
||||
)
|
||||
print(estimate.value, refute)
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Sensitivity analysis (SALib)
|
||||
```python
|
||||
from SALib.sample import sobol
|
||||
from SALib.analyze import sobol as sobol_analyze
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
problem = {
|
||||
"num_vars": 3,
|
||||
"names": ["x1", "x2", "x3"],
|
||||
"bounds": [[0, 1]] * 3,
|
||||
}
|
||||
X = sobol.sample(problem, 1024)
|
||||
Y = np.array([model_fn(*x) for x in X])
|
||||
Si = sobol_analyze.analyze(problem, Y)
|
||||
print(Si["S1"], Si["ST"])
|
||||
```
|
||||
|
||||
### Failure Mode tabulation
|
||||
```python
|
||||
fmea = pl.DataFrame({
|
||||
"mode": ["timeout", "OOM", "race"],
|
||||
"severity": [7, 9, 8],
|
||||
"occurrence": [4, 2, 3],
|
||||
"detection": [5, 6, 9],
|
||||
})
|
||||
fmea = fmea.with_columns(
|
||||
(pl.col("severity") * pl.col("occurrence") * pl.col("detection")).alias("RPN")
|
||||
).sort("RPN", descending=True)
|
||||
```
|
||||
|
||||
### LLM-assisted analysis (Claude Opus 4.7)
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
client = Anthropic()
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2048,
|
||||
system="You are a senior data analyst. Output JSON: {findings, hypotheses, next_steps}.",
|
||||
messages=[{"role": "user", "content": f"Summary stats:\n{df.describe()}"}],
|
||||
)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| New dataset, no prior | EDA + descriptive |
|
||||
| Known outcome, want drivers | Diagnostic + causal |
|
||||
| Need forecast | Predictive ML |
|
||||
| Decision under uncertainty | Prescriptive + sensitivity |
|
||||
| Post-incident | Root cause + FMEA |
|
||||
|
||||
**기본값**: EDA first — 매 어떤 sophisticated method도 raw data 의 distribution 의 understanding 없이는 misleading하다.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Reasoning]] · [[Scientific Method]]
|
||||
- 변형: [[Exploratory Data Analysis]] · [[Causal Inference]] · [[Root Cause Analysis]]
|
||||
- 응용: [[Decision Making]] · [[Debugging]] · [[Risk Assessment]]
|
||||
- Adjacent: [[Synthesis]] · [[Modeling]] · [[Statistics]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: hypothesis generation, summary narration, code scaffolding for analysis pipelines, anomaly explanation.
|
||||
**언제 X**: precise statistical inference (use proper tools), causal claims without proper identification, large-N numeric crunching (use pandas/polars not LLM).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Analysis paralysis**: 매 endless decomposition without synthesis — 의 decision 의 deferred.
|
||||
- **Confirmation bias**: 매 only analyzing data that supports prior hypothesis.
|
||||
- **Spurious correlation**: 매 correlation을 causation으로 confuse.
|
||||
- **Over-decomposition**: 매 component-level optimization 의 global suboptimum.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Tukey 1977 *Exploratory Data Analysis*; Pearl 2009 *Causality*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with 6 patterns + decision matrix |
|
||||
@@ -2,91 +2,156 @@
|
||||
id: wiki-2026-0508-anticipation
|
||||
title: Anticipation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ANTI-002]
|
||||
aliases: [Predictive Processing, Forward Modeling, Expectation]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, anticipation, predictive-Processing, futures-thinking, planning]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [cognition, neuroscience, prediction, decision-making]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: pytorch-rl
|
||||
---
|
||||
|
||||
# [[Anticipation|Anticipation]]
|
||||
# Anticipation
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "미래를 현재로 끌어오기: 다음에 일어날 일을 미리 예측하고, 그 예측된 미래에 맞춰 현재의 행동을 최적화함으로써 충격을 예방하거나 기회를 선점하는 지능형 시간 관리."
|
||||
## 매 한 줄
|
||||
> **"매 anticipation 은 매 brain 의 forward model — 매 sensory input 이 도달하기 전에 매 prediction 을 미리 생성"**. 매 Helmholtz unconscious inference (1860s) 에서 시작, 매 Friston free-energy principle (2010s) 으로 정식화, 매 2026 LLM/world-model (Sora, Veo, Genie) 의 매 core mechanism.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
예측/기대(Anticipation)는 시스템이 과거의 패턴과 현재의 징후를 결합하여 미래의 상태를 모델링하고, 이를 의사결정에 반영하는 동적인 인지 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **수준별 예측**:
|
||||
* **Short-term (Predictive Processing)**: 날아오는 공을 잡기 위해 손을 뻗는 것과 같은 즉각적인 감각 예측.
|
||||
* **Medium-term (Planning)**: 프로젝트 마감 기한을 고려하여 오늘의 작업을 배분하는 계획.
|
||||
* **Long-term (Strategic Foresight)**: 기술 트렌드를 읽고 신산업에 투자하는 전략적 전망.
|
||||
2. **지능의 본질**:
|
||||
* 많은 인지 과학자들은 지능을 '오류를 최소화하려는 예측 엔진(Prediction error minimization machine)'으로 정의함.
|
||||
### 매 핵심 개념
|
||||
- **Predictive coding**: 매 brain 매 prediction error 만 propagate — 매 expected signal 의 suppress.
|
||||
- **Forward model**: 매 motor command 의 sensory consequence 미리 simulate.
|
||||
- **Bayesian brain**: 매 prior + likelihood = posterior — 매 anticipation 매 prior.
|
||||
- **Active inference**: 매 action 의 future observation 의 prediction error 최소화.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '완벽한 예측'이 가능하다는 결정론적 정책이 우세했으나, 현대의 복잡계 정책은 예측 불가능성(Black Swan)을 인정하고 예측 실패 시 즉시 복구하는 '회복력([[Resilience|Resilience]]) 중심의 예측 정책'으로 변화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 비즈니스 운영 정책에서, 수동적 대응(Reactive) 대신 이상 징후를 선제적으로 감지하고 대응하는 '예방적 유지보수([[Predictive_Maintenance|Predictive Maintenance]]) 정책'이 데이터 사이언스의 핵심 목표가 됨.
|
||||
### 매 Domain 별
|
||||
- **Motor**: 매 reach-to-grasp 매 hand position 미리 simulate (cerebellum).
|
||||
- **Perceptual**: 매 illusory contour, 매 phoneme restoration.
|
||||
- **Social**: 매 theory of mind — 매 타인 행동 예측.
|
||||
- **Decision**: 매 prospect theory loss-aversion 매 future regret 의 anticipation.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Strategic-Planning|Strategic-Planning]], [[Reward Prediction Error|Reward Prediction Error]], [[Decision Theory|Decision Theory]], Pattern Recognition, [[Anisomorphism|Anisomorphism]]
|
||||
- **Modern Tech/Tools**: Predictive analytics, Scenario planning, Futures wheel.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Robotics**: 매 model-predictive control (MPC).
|
||||
2. **LLM**: 매 next-token prediction = 매 anticipation.
|
||||
3. **Game AI**: 매 opponent modeling, 매 MCTS.
|
||||
4. **VR/AR**: 매 motion-to-photon latency 매 user prediction 으로 hide.
|
||||
|
||||
## 🤖 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
|
||||
### Pattern 1: Kalman filter anticipation
|
||||
```python
|
||||
import numpy as np
|
||||
class KalmanFilter1D:
|
||||
def __init__(self, q=0.01, r=0.1):
|
||||
self.x, self.P, self.q, self.r = 0.0, 1.0, q, r
|
||||
def predict(self):
|
||||
self.P += self.q
|
||||
return self.x # 매 anticipated value
|
||||
def update(self, z):
|
||||
K = self.P / (self.P + self.r)
|
||||
self.x += K * (z - self.x)
|
||||
self.P *= (1 - K)
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: 매 Predictive coding loss
|
||||
```python
|
||||
import torch, torch.nn as nn
|
||||
class PredCoder(nn.Module):
|
||||
def __init__(self, d):
|
||||
super().__init__()
|
||||
self.predictor = nn.Linear(d, d)
|
||||
def forward(self, x_t, x_tp1):
|
||||
pred = self.predictor(x_t)
|
||||
err = x_tp1 - pred # 매 prediction error
|
||||
return err.pow(2).mean(), pred
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: 매 Model-predictive control (MPC)
|
||||
```python
|
||||
def mpc_step(state, dynamics, cost, horizon=10, n_samples=200):
|
||||
actions = sample_actions(n_samples, horizon)
|
||||
costs = []
|
||||
for a_seq in actions:
|
||||
s = state
|
||||
c = 0
|
||||
for a in a_seq:
|
||||
s = dynamics(s, a) # 매 forward simulation
|
||||
c += cost(s, a)
|
||||
costs.append(c)
|
||||
best = actions[np.argmin(costs)][0]
|
||||
return best
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 4: 매 Anticipatory game AI (minimax with depth)
|
||||
```python
|
||||
def minimax(state, depth, maximizing):
|
||||
if depth == 0 or state.terminal:
|
||||
return state.value()
|
||||
if maximizing:
|
||||
return max(minimax(s, depth-1, False) for s in state.children())
|
||||
return min(minimax(s, depth-1, True) for s in state.children())
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 5: 매 LLM next-token (the original anticipation)
|
||||
```python
|
||||
logits = model(input_ids)[:, -1, :]
|
||||
probs = logits.softmax(-1)
|
||||
next_tok = probs.argmax(-1) # 매 anticipated token
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 6: 매 World-model rollout (Dreamer-style)
|
||||
```python
|
||||
def imagine(world_model, init_state, policy, horizon=15):
|
||||
states, rewards = [init_state], []
|
||||
s = init_state
|
||||
for _ in range(horizon):
|
||||
a = policy(s)
|
||||
s, r = world_model.step(s, a) # 매 latent rollout
|
||||
states.append(s); rewards.append(r)
|
||||
return states, rewards
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 매 결정 기준
|
||||
| 상황 | Anticipation 기법 |
|
||||
|---|---|
|
||||
| 매 sensor noise + linear dynamics | Kalman filter |
|
||||
| 매 nonlinear, low-D | particle filter / EKF |
|
||||
| 매 high-D control | MPC + sampling |
|
||||
| 매 game tree | minimax / MCTS |
|
||||
| 매 sequence modeling | transformer next-token |
|
||||
| 매 long-horizon RL | world model + imagination |
|
||||
|
||||
**기본값**: 매 problem 의 dynamics 가 알려져 있으면 model-based (MPC, Kalman). 매 dynamics 학습 필요 → world model (Dreamer, MuZero).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Cognition]] · [[Decision-Making]]
|
||||
- 변형: [[Predictive Processing]] · [[Bayesian-Updating]]
|
||||
- 응용: [[Multi-agent-System]] · [[Joint-Optimization]]
|
||||
- Adjacent: [[Inference-Coupled Persistence]] · [[Habit-Formation]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 LLM 자체 매 anticipation engine — 매 next-token = 매 prediction. 매 agent planning 에서 매 future state 의 forecast.
|
||||
**언제 X**: 매 stochastic dynamics + 매 high stakes — 매 explicit Bayesian model 더 reliable.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Open-loop anticipation**: 매 prediction 만 하고 매 update 안 하면 매 drift 누적.
|
||||
- **Over-confidence**: 매 prior variance 너무 작으면 매 evidence ignore.
|
||||
- **Horizon mismatch**: 매 task horizon 보다 매 model horizon 짧으면 매 myopic.
|
||||
- **Single-trajectory rollout**: 매 stochastic env 에서 매 ensemble 필요.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Friston 2010 *Nat Rev Neurosci*, Clark *Surfing Uncertainty* 2016, Hafner et al. DreamerV3 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — predictive coding + 6 control/RL patterns |
|
||||
|
||||
@@ -2,91 +2,112 @@
|
||||
id: wiki-2026-0508-antinomianism
|
||||
title: Antinomianism
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ANOM-001]
|
||||
aliases: [Anti-law, Lawless ethics, Spiritual libertinism]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.81
|
||||
tags: [auto-reinforced, antinomianism, religion, ethics, law-free, Philosophy]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [theology, ethics, philosophy, history]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: na
|
||||
framework: na
|
||||
---
|
||||
|
||||
# [[Antinomianism|Antinomianism]]
|
||||
# Antinomianism
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "율법을 넘어선 자유: 도덕적 법이나 종교적 규칙이 구원을 보장하지 않으며, 오직 믿음이나 내적 영성만으로 충분하므로 기성 규칙에 얽매일 필요가 없다는 반주관주의적 태도."
|
||||
## 매 한 줄
|
||||
> **"매 antinomianism 은 매 moral law 보다 매 grace / inner conviction 우선 의 주장"**. 매 16세기 종교개혁 (Johannes Agricola vs Luther) 에서 정립되었고, 매 modern 에서 매 ethical relativism, libertarianism, 매 even AI alignment debate (rule-following vs value-aligned reasoning) 까지 매 echo 가 이어진다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
도덕 폐기론(Antinomianism)은 율법(Nomos)에 반대(Anti)한다는 뜻으로, 법이나 도덕적 사회 규범이 개인에게 구속력이 없다고 믿는 사상입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **역사적 배경**:
|
||||
* 초기 기독교에서 "은혜 아래 있으므로 율법은 더 이상 필요 없다"고 주장하며 나타남.
|
||||
* 사회적으로는 기존 질서를 무너뜨리는 급진적 자유주의의 씨앗이 되기도 함.
|
||||
2. **현대적 해석**:
|
||||
* **Ethical Antinomianism**: "상황이 법보다 우선한다"는 상황 윤리로 연결.
|
||||
* **Creative Destruction**: 예술이나 혁신 분야에서 "기존의 문법(Law)을 파괴해야 새로운 가치가 나온다"는 창조적 파괴의 논리로도 차용됨.
|
||||
### 매 역사적 전개
|
||||
- **고대 Gnostic** (2C): 매 material law 의 reject — 매 spiritual gnosis 가 superior.
|
||||
- **Reformation Agricola** (1530s): "Christian 매 Mosaic law 의 free" — 매 Luther 매 "antinomian" 명명.
|
||||
- **English Civil War Ranters** (1640s): 매 radical antinomian sect — 매 social order 의 challenge.
|
||||
- **American Hutchinson** (1637): 매 covenant of grace vs covenant of works — 매 Massachusetts Bay banishment.
|
||||
- **Modern**: 매 Kierkegaard 의 "teleological suspension of the ethical" (Abraham/Isaac) — 매 antinomian moment.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 사회 전복을 꾀하는 '이단적 정책'으로 탄압받았으나, 현대의 포스트모더니즘 정책은 고착화된 규정에 저항하고 새로운 질서를 찾는 '비판적 주체성 정책'의 배경으로 탐구함(RL Update).
|
||||
- **정책 변화(RL Update)**: 디지털 거버넌스 정책에서, 법 집행이 불가능한 탈중앙화 공간 등이 '디지털 안티노미안' 지대로 부상하며, 법과 기술적 자유 사이의 새로운 합의점(Smart Contract 등)을 찾는 정책 연구가 활발해짐.
|
||||
### 매 두 갈래
|
||||
- **Theological antinomianism**: 매 grace 가 law 의 supersede — 매 Paul Romans 6 strong reading.
|
||||
- **Ethical antinomianism**: 매 universal moral rule 의 reject — 매 situation ethics, existentialism.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Anarchism|Anarchism]], [[Anarcho-Capitalism|Anarcho-Capitalism]], [[Ethics & AI|Ethics & AI]], [[Standardization vs Innovation|Standardization vs Innovation]], [[Sociology of Knowledge|Sociology of Knowledge]]
|
||||
- **Modern Tech/Tools**: Permissionless networks ([[Blockchain|Blockchain]]).
|
||||
---
|
||||
### 매 응용
|
||||
1. **윤리학 강의**: 매 deontology vs virtue vs antinomian framing.
|
||||
2. **History of Christianity**: 매 Reformation faction 분석.
|
||||
3. **AI alignment**: 매 "rule-based" vs "value-aligned" — 매 antinomian analogue.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Rule-vs-grace dilemma 분석 framework
|
||||
```python
|
||||
@dataclass
|
||||
class EthicalDilemma:
|
||||
rule: str # explicit prohibition
|
||||
inner_conviction: str # felt right action
|
||||
consequence_rule: float
|
||||
consequence_grace: float
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
def antinomian_choice(d: EthicalDilemma) -> str:
|
||||
return "follow conviction" if d.consequence_grace > d.consequence_rule \
|
||||
else "follow rule"
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: 매 Historical text comparison
|
||||
```python
|
||||
texts = {
|
||||
"agricola_1537": "law has no place in conscience",
|
||||
"luther_1539": "antinomians make Christ a destroyer of law",
|
||||
"hutchinson_1637": "covenant of grace, not works",
|
||||
}
|
||||
# Embedding cluster → 매 antinomian core vocabulary 추출
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: AI alignment analogue
|
||||
```python
|
||||
# RLHF rule-based vs constitutional AI value-based
|
||||
def alignment_mode(policy, situation):
|
||||
if policy.type == "rule":
|
||||
return policy.rules.get(situation, "default deny")
|
||||
elif policy.type == "constitutional":
|
||||
return policy.values.evaluate(situation) # 매 antinomian-style
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 strict rule application | 매 nomian (deontological) |
|
||||
| 매 novel situation 의 rule absent | 매 antinomian (grace / value) |
|
||||
| 매 high stakes + clear rule | nomian default |
|
||||
| 매 ambiguous + harm avoidance | antinomian + community check |
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
**기본값**: 매 rule + value 매 dual check — 매 antinomianism 의 historical excess (Ranters libertinism) 의 회피.
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
## 🔗 Graph
|
||||
- 부모: [[Ethical-Decision-Making]] · [[Sociology of Knowledge]]
|
||||
- 변형: [[Situation Ethics]] · [[Existentialism]]
|
||||
- 응용: [[Objectivism]] · [[Belief-Revision]]
|
||||
- Adjacent: [[Hypostatic-Abstraction]] · [[Memetics]]
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 ethics tutoring agent — 매 Reformation history / theology survey / comparative religion.
|
||||
**언제 X**: 매 contemporary moral advice — 매 LLM 이 antinomian framing 으로 매 user 를 misguide 매 risk.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Antinomianism = libertinism 동일시**: 매 historical Ranters 의 caricature. 매 most antinomian theology 매 still ethical.
|
||||
- **Modern relativism 과 conflate**: 매 antinomianism 매 specifically theological — 매 secular relativism 의 separate.
|
||||
- **Single-source reading**: 매 Paul Romans 6 만 보면 매 partial — 매 James, 매 Sermon on the Mount counter-balance.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Stanford Encyclopedia of Philosophy "Antinomianism", McGrath *Reformation Thought* 5th ed).
|
||||
- 신뢰도 A-.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — historical timeline + 매 AI alignment analogue |
|
||||
|
||||
+167
-41
@@ -2,65 +2,191 @@
|
||||
id: wiki-2026-0508-anxiety
|
||||
title: Anxiety
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ANXI-001]
|
||||
aliases: [Anxiety Disorder, Worry]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.89
|
||||
tags: [auto-reinforced, anxiety, Psychology, mental-health, future-threat, emotional-intelligence]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [psychology, mental-health, cognition]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: cbt-tools
|
||||
---
|
||||
|
||||
# [[Anxiety|Anxiety]]
|
||||
# Anxiety
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "미래를 향한 잘못된 알람: 다가올 수 있는 불확실한 위협에 대해 뇌가 끊임없이 경고 신호를 보내며, 현재의 평안을 갉아먹고 신체를 긴장 상태로 유지하는 그림자 같은 정서."
|
||||
## 매 한 줄
|
||||
> **"매 Anxiety는 future-oriented threat에 대한 anticipatory response이다 — fear의 specific object와 달리 diffuse하다"**. Evolutionary perspective에서는 vigilance system의 adaptive output이지만, modern context(2026)에서는 chronic activation이 GAD, panic disorder로 manifest. 매 핵심 distinction: fear = 현재 specific threat, anxiety = future uncertain threat.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
불안(Anxiety)은 막연하고 대상이 모호한 위험에 대해 느끼는 불쾌한 감정 상태입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **공포(Fear)와의 차이**:
|
||||
* 공포는 눈앞의 '확실한 위협'에 대한 반응이지만, 불안은 '미래의 불확실한 가능성'에 대한 반응임.
|
||||
2. **안티프래질적 측면**:
|
||||
* 적당한 불안은 위험에 대비하게 하고 성과를 높임 (Yerkes-Dodson 법칙).
|
||||
3. **지능적 관점**:
|
||||
* 고도의 지능을 가진 존재일수록 더 많은 미래 시나리오를 시뮬레이션하므로, 불안도가 높은 경향이 있음.
|
||||
### 매 Fear vs Anxiety
|
||||
- **Fear**: specific, present, immediate — amygdala-driven flight/fight.
|
||||
- **Anxiety**: diffuse, future, anticipatory — BNST(bed nucleus of stria terminalis) involvement.
|
||||
- 매 neural circuitry가 다름 — anxiolytic interventions도 다름.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순히 제거해야 할 '부정적 감정' 정책으로 다뤘으나, 현대 심리학 정책은 불안을 '에너지의 신호'로 재해석하고 이를 창의적 동력으로 전환하는 '불안 수용 및 관리 정책(ACT 등)'을 권장함(RL Update).
|
||||
- **정책 변화(RL Update)**: 디지털 중독 및 SNS 환경 정책에서, '끊임없는 비교'가 낳는 불안(FOMO)을 방지하기 위해 플랫폼의 알림 디자인 규제 및 디지털 웰빙 정책이 강화됨.
|
||||
### 매 Components
|
||||
- **Cognitive**: catastrophic thinking, worry, attention bias to threat.
|
||||
- **Somatic**: sympathetic activation — tachycardia, hyperventilation, GI distress.
|
||||
- **Behavioral**: avoidance, safety behaviors, reassurance seeking.
|
||||
- **Affective**: dread, apprehension, restlessness.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Anticipation|Anticipation]], [[Psychology & Behavior|Psychology & Behavior]], [[Risk-Management|Risk-Management]], [[Decision Theory|Decision Theory]], [[Antifragility|Antifragility]]
|
||||
- **Modern Tech/Tools**: Mindfulness apps (Headspace), Biofeedback wearables.
|
||||
---
|
||||
### 매 응용
|
||||
1. Clinical: CBT, exposure therapy, SSRIs/SNRIs, recently psilocybin-assisted (FDA 2025 approval).
|
||||
2. Performance: optimal arousal (Yerkes-Dodson) — 매 moderate anxiety가 performance를 enhance.
|
||||
3. Decision making: anxiety로 인한 risk-aversion bias 의 calibration.
|
||||
4. ML: anxiety-like behavior in RL agents (uncertainty aversion penalty).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### CBT thought record (digital tool)
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
from datetime import datetime
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
@dataclass
|
||||
class ThoughtRecord:
|
||||
timestamp: datetime
|
||||
situation: str
|
||||
automatic_thought: str
|
||||
emotion: str
|
||||
intensity: int # 0-100
|
||||
cognitive_distortion: str # catastrophizing, mind-reading, etc
|
||||
balanced_thought: str
|
||||
new_intensity: int
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def log_thought(situation, thought, emotion, intensity):
|
||||
return ThoughtRecord(
|
||||
timestamp=datetime.now(),
|
||||
situation=situation,
|
||||
automatic_thought=thought,
|
||||
emotion=emotion,
|
||||
intensity=intensity,
|
||||
cognitive_distortion="",
|
||||
balanced_thought="",
|
||||
new_intensity=0,
|
||||
)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Exposure hierarchy builder
|
||||
```python
|
||||
def build_hierarchy(items: list[tuple[str, int]]) -> list[dict]:
|
||||
"""items: (description, SUDS 0-100). Returns ordered hierarchy."""
|
||||
sorted_items = sorted(items, key=lambda x: x[1])
|
||||
return [
|
||||
{"step": i + 1, "task": desc, "suds": s, "status": "pending"}
|
||||
for i, (desc, s) in enumerate(sorted_items)
|
||||
]
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
hierarchy = build_hierarchy([
|
||||
("Look at photo of dog", 20),
|
||||
("Watch dog video", 35),
|
||||
("Be in room with leashed dog", 60),
|
||||
("Pet a calm dog", 80),
|
||||
("Approach unfamiliar dog", 95),
|
||||
])
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Physiological monitoring (HRV-based)
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def rmssd(rr_intervals_ms: np.ndarray) -> float:
|
||||
"""Root mean square of successive differences — HRV metric.
|
||||
낮은 RMSSD = 매 sympathetic dominance = anxiety state."""
|
||||
diffs = np.diff(rr_intervals_ms)
|
||||
return np.sqrt(np.mean(diffs ** 2))
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
def anxiety_proxy(rr: np.ndarray, baseline_rmssd: float) -> float:
|
||||
current = rmssd(rr)
|
||||
return max(0.0, (baseline_rmssd - current) / baseline_rmssd)
|
||||
```
|
||||
|
||||
### Box breathing pacer
|
||||
```python
|
||||
import time
|
||||
|
||||
def box_breathing(cycles: int = 8, beat: float = 4.0):
|
||||
"""4-4-4-4 pattern — vagal tone activation."""
|
||||
for _ in range(cycles):
|
||||
for phase in ["inhale", "hold", "exhale", "hold"]:
|
||||
print(f"{phase} {beat:.0f}s")
|
||||
time.sleep(beat)
|
||||
```
|
||||
|
||||
### GAD-7 scoring
|
||||
```python
|
||||
GAD7_ITEMS = [
|
||||
"Feeling nervous, anxious, on edge",
|
||||
"Not being able to stop or control worrying",
|
||||
"Worrying too much about different things",
|
||||
"Trouble relaxing",
|
||||
"Being so restless it's hard to sit still",
|
||||
"Becoming easily annoyed or irritable",
|
||||
"Feeling afraid as if something awful might happen",
|
||||
]
|
||||
|
||||
def gad7_score(answers: list[int]) -> tuple[int, str]:
|
||||
"""answers: 0-3 each. Returns (score, severity)."""
|
||||
s = sum(answers)
|
||||
sev = "minimal" if s < 5 else "mild" if s < 10 else "moderate" if s < 15 else "severe"
|
||||
return s, sev
|
||||
```
|
||||
|
||||
### LLM-based reframing assistant
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
def reframe(thought: str) -> str:
|
||||
client = Anthropic()
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=512,
|
||||
system=("You are a CBT-trained assistant. Identify cognitive distortion "
|
||||
"and offer a balanced reframe. Not a substitute for clinical care."),
|
||||
messages=[{"role": "user", "content": thought}],
|
||||
)
|
||||
return msg.content[0].text
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Acute panic | Box breathing + grounding (5-4-3-2-1) |
|
||||
| Chronic worry | CBT thought records + worry postponement |
|
||||
| Specific phobia | Graded exposure |
|
||||
| GAD score ≥ 10 | Refer to clinician |
|
||||
| Performance anxiety | Reframe arousal as excitement |
|
||||
|
||||
**기본값**: psychoeducation + behavioral activation — 매 most evidence-based first-line for subclinical anxiety.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Emotion]] · [[Mental Health]]
|
||||
- 변형: [[Generalized Anxiety Disorder]] · [[Panic Disorder]] · [[Social Anxiety]]
|
||||
- 응용: [[CBT]] · [[Exposure Therapy]] · [[Mindfulness]]
|
||||
- Adjacent: [[Fear]] · [[Stress]] · [[Depression]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: psychoeducation, journaling prompts, cognitive reframing drafts, GAD-7 scoring assistant.
|
||||
**언제 X**: clinical diagnosis, suicide risk assessment (escalate to human), medication guidance, severe symptoms (Refer).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Avoidance reinforcement**: 매 avoiding feared situation 의 short-term relief 의 long-term escalation.
|
||||
- **Reassurance seeking loop**: 매 repeated checking 의 anxiety maintenance.
|
||||
- **Substance self-medication**: alcohol/benzodiazepine dependence risk.
|
||||
- **Catastrophizing without check**: 매 worst-case probability inflation.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Beck 1979 *Cognitive Therapy*; Barlow 2002 *Anxiety and Its Disorders*; APA 2024 guidelines).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with CBT/exposure tools |
|
||||
|
||||
@@ -2,66 +2,130 @@
|
||||
id: wiki-2026-0508-assertiveness
|
||||
title: Assertiveness
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ASSE-001]
|
||||
aliases: [Assertive Communication, Assertion Skills]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.91
|
||||
tags: [auto-reinforced, assertiveness, communication, emotional-intelligence, Boundary-Setting]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [communication, soft-skills, leadership, psychology, negotiation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: n/a
|
||||
framework: communication-frameworks
|
||||
---
|
||||
|
||||
# [[Assertiveness|Assertiveness]]
|
||||
# Assertiveness
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "존중을 담은 당당함: 타인의 권리를 침해하지 않으면서도 자신의 감정, 욕구, 신념을 솔직하고 정직하며 적절한 방식으로 표현하는 건강한 의사소통의 기술."
|
||||
## 매 한 줄
|
||||
> **"매 Assertiveness 는 self-respect 와 other-respect 의 simultaneous expression — passive 와 aggressive 사이 의 narrow band"**. Wolpe (1958) 의 behavior therapy 에서 origin 의, 2026 의 remote/hybrid workplace 와 LLM-mediated communication 의 환경 에서 의 explicit boundary-setting 의 critical skill.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
자기 주장(Assertiveness)은 공격성(Aggressiveness)과 수동성(Passiveness) 사이의 균형을 잡는 의사소통 스타일입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3가지 태도 비교**:
|
||||
* **Passiveness**: 타인의 요구에만 맞추며 자신의 욕구 억제 (억울함과 스트레스 유발).
|
||||
* **Aggressiveness**: 타인을 지배하려 하거나 권리를 무시 (관계 단절 및 적대감 유발).
|
||||
* **Assertiveness**: "나는 이렇게 느낀다"를 명확히 전달하며 타인의 의견도 청취 (신뢰와 갈등 해결).
|
||||
2. **핵심 기법**:
|
||||
* **I-Message**: 주어를 '나'로 시작하여 자신의 감정과 상황을 객관적으로 전달.
|
||||
* **Boundary Setting**: 자신이 수용할 수 있는 한계를 명확히 하고 거절이 필요할 때 정중하게 거절함.
|
||||
### 매 4 communication styles
|
||||
- **Passive**: own need 의 suppress, resentment 의 accumulate
|
||||
- **Aggressive**: own need 의 force, other 의 violate
|
||||
- **Passive-aggressive**: indirect hostility, sarcasm
|
||||
- **Assertive**: direct + respectful, "I" statement, negotiable outcome
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 위계적 조직 정책은 '순종'을 미덕으로 보았으나, 현대의 애자일 및 혁신 정책은 구성원 모두의 '심리적 안정감' 하에 이루어지는 '건강한 자기 주장 정책'이 팀 성과의 핵심임을 강조함(RL Update).
|
||||
- **정책 변화(RL Update)**: 리더십 교육 정책에서, 단순히 강력한 카리스마를 강조하던 방식에서 벗어나 구성원들 간의 Assertive한 소통을 이끌어내는 '퍼실리테이션 역량 정책'으로 무게중심이 이동함.
|
||||
### 매 components
|
||||
- **Verbal**: "I" statement, specific request, no apology cascade
|
||||
- **Non-verbal**: eye contact, level tone, open posture
|
||||
- **Cognitive**: distinguish observation from interpretation
|
||||
- **Boundary**: explicit no, alternative offer
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Communication, [[Leadership|Leadership]], [[Psychology & Behavior|Psychology & Behavior]], [[Agile-Philosophy|Agile-Philosophy]], [[Articulateness|Articulateness]]
|
||||
- **Modern Tech/Tools**: EQ [[Testing|Testing]] tools, Communication training workshops.
|
||||
---
|
||||
### 매 응용
|
||||
1. Code review pushback — disagreement 의 deliver without person attack.
|
||||
2. Scope negotiation — PM 의 unrealistic deadline 의 counter-propose.
|
||||
3. 1:1 feedback — manager 에게 의 upward feedback delivery.
|
||||
4. LLM prompt-as-self-script — assertive draft 의 LLM rehearsal (2026 trend).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### DESC script (Bower & Bower)
|
||||
```
|
||||
D - Describe : "지난 sprint 에서 last-minute scope 의 3건 의 추가."
|
||||
E - Express : "이런 pattern 의 지속 의 인해 quality risk 의 우려."
|
||||
S - Specify : "Wed cutoff 이후 의 scope freeze 의 명문화 의 제안."
|
||||
C - Consequence: "이 의 commit 의 stable 인 한 의 on-time delivery 의 가능."
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### "I" statement template
|
||||
```
|
||||
I feel <emotion>
|
||||
when <specific behavior, no inference>
|
||||
because <impact on me>.
|
||||
I'd like <concrete request>.
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Broken record technique
|
||||
```
|
||||
"이 의 PR 의 review 의 today 의 필요 의 인해 의 deploy 의 block."
|
||||
counter: "다음 주 의 가능?"
|
||||
"이해 함. 이 의 PR 의 review 의 today 의 필요."
|
||||
counter: "바쁨..."
|
||||
"이해. 이 의 today 의 필요 — 30 분 의 가능 의 시간?"
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Fogging (manipulation defense)
|
||||
```
|
||||
manipulator: "너 의 항상 이런 issue 의 생성."
|
||||
assertive : "이런 case 의 그런 perception 의 가능 (partial agree).
|
||||
specific incident 의 discuss 의 가능?"
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Negotiation BATNA framing
|
||||
```python
|
||||
class AssertiveNegotiation:
|
||||
def __init__(self, batna: float, target: float, walk_away: float):
|
||||
self.batna = batna # best alternative
|
||||
self.target = target # ideal outcome
|
||||
self.walk_away = walk_away # ZOPA boundary
|
||||
|
||||
def respond(self, offer: float) -> str:
|
||||
if offer < self.walk_away:
|
||||
return f"이 의 fit 의 X. BATNA 의 {self.batna} 의 가능."
|
||||
if offer < self.target:
|
||||
return f"이 의 considered 의. {self.target} 의 closer 의 가능?"
|
||||
return "이 의 accept."
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Public meeting 의 disagreement | DESC + private follow-up |
|
||||
| Repeated boundary violation | Broken record + escalation |
|
||||
| Manipulative language | Fogging + clarifying question |
|
||||
| Scope creep | "I" statement + alternative |
|
||||
| Unfair criticism | Negative inquiry ("specifically?") |
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
**기본값**: workplace conflict 의 default — DESC script + "I" statement combo.
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🔗 Graph
|
||||
- 부모: [[Soft-Skills-Development]]
|
||||
- 변형: [[Boundaries]] · [[Communication & Tech]]
|
||||
- 응용: [[Ethical-Decision-Making]]
|
||||
- Adjacent: [[Burnout]] · [[Bureaucracy]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 어려운 conversation 의 rehearsal, draft message 의 tone 의 audit (passive→assertive).
|
||||
**언제 X**: emotional regulation 의 substitute 의 X — therapy 의 separate.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Aggressive 의 mislabel**: forceful = assertive 의 X. respect 의 missing 의 aggressive.
|
||||
- **Apology cascade**: "sorry, but..." 의 chain 의 own position 의 undercut.
|
||||
- **Passive-aggressive 의 sarcasm**: indirect 의 long-term trust 의 erode.
|
||||
- **Boundary 의 then collapse**: 한 번 의 violation 의 즉시 의 address — delay 의 precedent.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Alberti & Emmons *Your Perfect Right* 10th, Bower *Asserting Yourself*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full assertiveness with DESC, BATNA, fogging patterns |
|
||||
|
||||
@@ -2,94 +2,146 @@
|
||||
id: wiki-2026-0508-assumptions-vs-facts
|
||||
title: Assumptions vs Facts
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ASVF-001]
|
||||
aliases: [Fact-Assumption Distinction, Premise vs Evidence]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, assumptions, facts, critical-thinking, Scientific-Method, Logic]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [reasoning, epistemology, decision-making, critical-thinking]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: na
|
||||
---
|
||||
|
||||
# [[Assumptions-vs-Facts|Assumptions-vs-Facts]]
|
||||
# Assumptions vs Facts
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "생각의 거품 걷어내기: 내가 당연히 그렇다고 믿는 '가정'과 실제 현실에서 입증된 '발생한 사실'을 철저히 분리하여, 잘못된 믿음 위에 모래성을 쌓지 않도록 경계하는 지적 정직성."
|
||||
## 매 한 줄
|
||||
> **"매 fact 는 매 verifiable observation, 매 assumption 은 매 unverified premise"**. 매 둘 의 conflation 매 most decision failure 의 root. 매 military intelligence (CIA Tradecraft Primer), 매 software engineering (RFC, design doc), 매 LLM agent reasoning (chain-of-thought 매 assumption 명시) 모두 의 핵심 discipline.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
가정과 사실의 구분은 비판적 사고와 과학적 방법론의 가장 기초적인 단계입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **Fact (사실)**:
|
||||
* 객관적으로 증명 가능하며, 누구나 동일한 조건에서 관찰하거나 확인 가능한 데이터.
|
||||
* "이 서버의 응답 속도는 50ms이다."
|
||||
2. **Assumption (가정)**:
|
||||
* 사실이 밝혀지지 않았거나 확인하지 않은 상태에서 '그럴 것이다'라고 믿고 전제하는 것.
|
||||
* "사용자는 빠른 응답 속도를 좋아할 것이다." (비록 타당해 보일지라도 검증 전까지는 가정임)
|
||||
3. **가정의 위험성**:
|
||||
* **Implicit Assumptions**: 스스로 가정하고 있다는 사실조차 깨닫지 못하는 무의식적 전제들이 의사결정의 거대한 오류를 만듦.
|
||||
* **Assumption Stacking**: 검증되지 않은 가정 위에 또 다른 가정을 쌓으면 작은 균열에도 전체 시스템이 붕괴함.
|
||||
### 매 정의
|
||||
- **Fact**: 매 currently verifiable claim — 매 measurement, 매 reproducible observation, 매 authoritative record.
|
||||
- **Assumption**: 매 not verified, 매 taken as true 매 reasoning 진행 위해. 매 implicit / explicit.
|
||||
- **Inference**: 매 fact + assumption → 매 conclusion.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 직관적 의사결정 정책은 '전문가의 감(Assumption)'에 의존했으나, 현대의 데이터 기반 정책은 모든 핵심 전제를 '가설 검정(Hypothesis [[Testing|Testing]])'을 통해 사실로 확인하려는 정책적 결벽증을 가짐(RL Update).
|
||||
- **정책 변화(RL Update)**: 프로젝트 관리 정책(예: Agile)에서, 불확실한 가정을 최대한 빨리 사실로 확인하기 위해 '최소 기능 제품(MVP)'을 만들고 피드백을 받는 '가정 검증 속도 최적화 정책'이 표준이 됨.
|
||||
### 매 Verification spectrum
|
||||
- **Hard fact**: 매 measurement (e.g., latency = 142ms p95).
|
||||
- **Soft fact**: 매 expert testimony / consensus (e.g., "FDA-approved").
|
||||
- **Reasonable assumption**: 매 base rate / 매 prior (e.g., "user 매 attention < 10s").
|
||||
- **Speculative assumption**: 매 untested premise (e.g., "competitor 매 Q4 launch").
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Analysis|Analysis]], [[Arguing-by-Counterexample|Arguing-by-Counterexample]], [[Scientific Communication|Scientific Communication]], Rationality, [[Rapid-Prototyping|Rapid-Prototyping]]
|
||||
- **Modern Tech/Tools**: A/B testing platforms, Root cause [[Analysis|Analysis]] tools (5 Whys).
|
||||
---
|
||||
### 매 응용
|
||||
1. **Design doc**: 매 "Assumptions" section 별도 — 매 reviewer 검증.
|
||||
2. **Intelligence analysis**: 매 ACH (Analysis of Competing Hypotheses).
|
||||
3. **Postmortem**: 매 implicit assumption 적출 — 매 next-time fact 로 verify.
|
||||
4. **LLM CoT**: 매 reasoning chain 에서 매 assumption 의 explicit tag.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: 매 Design doc template
|
||||
```markdown
|
||||
## Facts
|
||||
- 매 current p95 latency: 240ms (verified via 매 grafana 2026-05-09).
|
||||
- 매 user count: 1.2M MAU (analytics dashboard).
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## Assumptions
|
||||
- [A1] 매 traffic grow 30% YoY (prior: 2024-2025 trend).
|
||||
- [A2] 매 redis cluster 매 horizontal scale 가능 (vendor docs, untested at our scale).
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
## Inferences
|
||||
- A1 + Facts → 매 Q4 capacity = 1.56M MAU.
|
||||
- A2 + Facts → 매 cache layer 매 bottleneck 의 X.
|
||||
|
||||
- **정보 상태:** 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
|
||||
## Validation plan
|
||||
- A1: 매 monthly reforecast.
|
||||
- A2: 매 Q3 load-test 8x current.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: 매 ACH (Analysis of Competing Hypotheses)
|
||||
```python
|
||||
import numpy as np
|
||||
hypotheses = ["H1: 매 supply shock", "H2: 매 demand drop", "H3: 매 competitor"]
|
||||
evidence = ["E1: price up", "E2: query down", "E3: rival ad spike"]
|
||||
# 매 매 evidence × hypothesis: consistent (+1), inconsistent (-1), N/A (0)
|
||||
M = np.array([
|
||||
# E1, E2, E3
|
||||
[+1, 0, 0], # H1
|
||||
[-1, +1, 0], # H2
|
||||
[ 0, +1, +1], # H3
|
||||
])
|
||||
scores = M.sum(axis=1)
|
||||
for h, s in zip(hypotheses, scores):
|
||||
print(h, s)
|
||||
# 매 lowest disconfirmed = 매 most likely (CIA tradecraft logic)
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: 매 Assumption tagging in CoT
|
||||
```python
|
||||
def reason_with_tags(query: str) -> str:
|
||||
return llm(f"""
|
||||
Answer step by step. For every claim:
|
||||
- Tag [FACT: source] if verifiable.
|
||||
- Tag [ASSUMP: confidence 0-1] if untested.
|
||||
- Tag [INFER] if derived.
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
Q: {query}
|
||||
""")
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 4: 매 Premortem (assumption stress-test)
|
||||
```markdown
|
||||
Imagine the project failed in 6 months. List the 5 most likely
|
||||
failed assumptions. For each, design a 2-week experiment to test
|
||||
it now.
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 5: Confidence score 매 calibration
|
||||
```python
|
||||
predictions = [] # list of (claim, confidence, actual_outcome)
|
||||
brier = sum((c - a)**2 for _, c, a in predictions) / len(predictions)
|
||||
print(f"Brier score: {brier:.3f}") # 매 lower = better calibration
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 매 결정 기준
|
||||
| 상황 | Treat as |
|
||||
|---|---|
|
||||
| 매 metric in current dashboard | Fact (with date) |
|
||||
| 매 vendor capability claim | Soft fact, 매 verify if critical |
|
||||
| 매 future user behavior | Assumption — 매 explicit |
|
||||
| 매 "everyone knows" | 매 strong assumption — 매 challenge |
|
||||
| 매 LLM output | Assumption until cross-checked |
|
||||
|
||||
**기본값**: 매 reasoning 시작 시 매 explicit "Facts" / "Assumptions" 분리. 매 implicit assumption 의 surface — 매 brittle.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Belief-Revision]] · [[Bayesian-Updating]]
|
||||
- 변형: [[Bayes-Theorem]] · [[Hypostatic-Abstraction]]
|
||||
- 응용: [[Problem Solving Process]] · [[Process_Reflection_Template]]
|
||||
- Adjacent: [[Big-Picture]] · [[Outside-Thinking]] · [[Anticipation]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 agent design — 매 [FACT]/[ASSUMP] tagging 매 hallucination detection 도움. 매 reasoning trace audit.
|
||||
**언제 X**: 매 creative ideation — 매 over-tagging 매 flow 방해.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Implicit assumption**: 매 unmentioned premise — 매 reviewer 못 catch.
|
||||
- **Fact inflation**: 매 weak evidence 의 hard fact 처럼 표현.
|
||||
- **Confidence theater**: 매 "obviously" / "clearly" — 매 hidden assumption marker.
|
||||
- **Single-source fact**: 매 1 source = 매 still soft. 매 triangulate.
|
||||
- **Stale fact**: 매 6개월 전 metric — 매 currently fact 인지 재검증.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (CIA Tradecraft Primer 2009, Heuer *Psychology of Intelligence Analysis*, Tetlock *Superforecasting*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — ACH + 매 design-doc pattern + LLM CoT tagging |
|
||||
|
||||
@@ -2,65 +2,147 @@
|
||||
id: wiki-2026-0508-atlantic
|
||||
title: Atlantic
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ATLA-001]
|
||||
aliases: [The Atlantic, Atlantic Magazine, theatlantic.com]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.82
|
||||
tags: [auto-reinforced, atlantic, geopolitics, history, trade, environment]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [media, journalism, publication, source-quality]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: na
|
||||
framework: na
|
||||
---
|
||||
|
||||
# [[Atlantic|Atlantic]]
|
||||
# Atlantic (The Atlantic)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인류 문명을 잇는 거대한 회랑: 유럽, 아메리카, 아프리카 대륙을 연결하며 대항해 시대부터 현대 무역, 정보 통신 잠수함 케이블에 이르기까지 지구적 교류와 갈등의 중심이 되어온 푸른 심장."
|
||||
## 매 한 줄
|
||||
> **"매 *The Atlantic* 은 매 1857년 Boston 창간 의 long-form journalism + cultural criticism 매 flagship"**. 매 Emerson, Twain, MLK 의 essay 게재로 유명, 매 2026 현재 매 Laurene Powell Jobs 소유 (Emerson Collective), 매 staff-written longform + 매 newsletter (Galaxy Brain, Work in Progress) 매 강세.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
대서양(Atlantic Ocean)은 지구 표면의 약 1/5을 차지하는 세계에서 두 번째로 큰 대양입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **지정학적 및 경제적 가치**:
|
||||
* **Trade Routes**: 과거 삼각 무역부터 현대 컨테이너 운송까지 글로벌 공급망의 핵심.
|
||||
* **Data Highway**: 북미와 유럽을 잇는 수많은 해저 광케이블이 매설되어 있어 글로벌 인터넷 흐름의 주축을 이룸. (Data Sovereignty와 연결)
|
||||
* **Resource [[Repository|Repository]]**: 막대한 수산 자원과 대륙붕에 매설된 석유 및 천연가스.
|
||||
2. **환경적 역할**:
|
||||
* **Atlantic Meridional Overturning Circulation (AMOC)**: 거대 해류 순환을 통해 지구의 열 에너지를 분산시켜 기후 균형 유지.
|
||||
### 매 역사 timeline
|
||||
- **1857**: Phillips/Underwood/Holmes/Emerson 창간 — 매 abolitionist 색채.
|
||||
- **1861**: "Battle Hymn of the Republic" Julia Ward Howe 매 first publication.
|
||||
- **1963**: MLK "Letter from Birmingham Jail" — 매 first wide-circulation 게재.
|
||||
- **2017**: Emerson Collective acquisition.
|
||||
- **2024**: 매 paywall + 매 print revival, 매 newsletter platform 확장.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '정복과 착취'를 위한 통로 정책이었으나, 현대의 대서양 정책은 해양 생태계 보존과 기후 변화 대응을 위한 '글로벌 해양 거버넌스 정책'으로 중심축이 이동함(RL Update).
|
||||
- **정책 변화(RL Update)**: 디지털 패권 정책에서, 대서양 횡단 데이터 흐름(Trans-Atlantic Data Flows)에 대한 개인 정보 보호 체계(Privacy Shield 등)를 둘러싼 미국과 EU 간의 정책 협상이 테크 산업의 핵심 규제 이슈가 됨.
|
||||
### 매 Editorial 특징
|
||||
- **Longform**: 매 5,000–15,000 단어 deep reporting.
|
||||
- **Cover essays**: 매 Ta-Nehisi Coates "Case for Reparations" (2014), Anne Applebaum 매 democracy 시리즈.
|
||||
- **Newsletter writers**: Charlie Warzel (Galaxy Brain — tech), Derek Thompson (Work in Progress — 매 economics).
|
||||
- **Podcast**: *Radio Atlantic*, *How to Build a Happy Life*.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[AI & Data Sovereignty|AI & Data Sovereignty]], Geopolitics of AI, Environment, [[Scientific Communication|Scientific Communication]], [[Systems Thinking|Systems Thinking]]
|
||||
- **Modern Tech/Tools**: Submarine telecommunication cables, Oceanographic monitoring AI.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Source citation**: 매 academic / policy 매 A-tier source.
|
||||
2. **Media literacy**: 매 longform vs hot-take spectrum 의 longform end.
|
||||
3. **AI training data**: 매 high-quality English prose corpus.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: 매 Atlantic article 인용 검증
|
||||
```python
|
||||
import requests
|
||||
from urllib.parse import urlparse
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def is_atlantic(url: str) -> bool:
|
||||
return urlparse(url).netloc.endswith("theatlantic.com")
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def cite_atlantic(url: str) -> dict:
|
||||
# 매 metadata 추출
|
||||
r = requests.get(url, headers={"User-Agent": "Mozilla/5.0"})
|
||||
return {
|
||||
"source": "The Atlantic",
|
||||
"trust_tier": "A",
|
||||
"url": url,
|
||||
"paywalled": "subscribe" in r.text.lower(),
|
||||
}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 2: 매 RSS / Newsletter 구독 (programmatic)
|
||||
```python
|
||||
import feedparser
|
||||
feeds = {
|
||||
"main": "https://www.theatlantic.com/feed/all/",
|
||||
"ideas": "https://www.theatlantic.com/feed/channel/ideas/",
|
||||
"technology": "https://www.theatlantic.com/feed/channel/technology/",
|
||||
}
|
||||
for name, url in feeds.items():
|
||||
f = feedparser.parse(url)
|
||||
for e in f.entries[:5]:
|
||||
print(name, e.title, e.link)
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 3: Wayback Machine 매 paywall bypass (legitimate research)
|
||||
```bash
|
||||
# 매 academic fair-use 매 archived snapshot
|
||||
curl -s "https://web.archive.org/web/2024*/theatlantic.com/magazine/archive/2024/01/*"
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 4: Citation BibTeX
|
||||
```bibtex
|
||||
@article{coates2014reparations,
|
||||
author = {Coates, Ta-Nehisi},
|
||||
title = {The Case for Reparations},
|
||||
journal = {The Atlantic},
|
||||
year = {2014},
|
||||
month = {June},
|
||||
url = {https://www.theatlantic.com/magazine/archive/2014/06/the-case-for-reparations/361631/}
|
||||
}
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 5: 매 Source-trust scoring
|
||||
```python
|
||||
TRUST_TIERS = {
|
||||
"theatlantic.com": "A",
|
||||
"nytimes.com": "A",
|
||||
"wsj.com": "A",
|
||||
"medium.com": "C", # 매 user-generated
|
||||
"substack.com": "B", # 매 author-dependent
|
||||
}
|
||||
def trust(url):
|
||||
domain = urlparse(url).netloc.replace("www.", "")
|
||||
return TRUST_TIERS.get(domain, "D")
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Use Atlantic? |
|
||||
|---|---|
|
||||
| 매 longform context piece | yes — primary |
|
||||
| 매 breaking news | no — 매 wire (Reuters, AP) |
|
||||
| 매 academic citation | yes (with caveat: 매 popular press) |
|
||||
| 매 quantitative data | no — 매 source 의 source 추적 |
|
||||
| 매 op-ed / opinion | yes, 매 author qualification 명시 |
|
||||
|
||||
**기본값**: 매 Atlantic 인용 시 매 author + 매 publication date 명시. 매 longform → 매 narrative bias 가능 — 매 cross-reference.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Media]] · [[Journalism]]
|
||||
- 변형: [[The New Yorker]] · [[Harper's Magazine]]
|
||||
- 응용: [[Research-Methodology]] · [[Open-Access-Movement]]
|
||||
- Adjacent: [[Sociology of Knowledge]] · [[Recording Academy (The Grammys)]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 LLM training 시 매 high-quality English longform corpus. 매 citation suggestion agent — 매 Atlantic 매 A-tier.
|
||||
**언제 X**: 매 fast-moving tech topic — 매 publication delay (weekly). 매 niche specialty — 매 SME source 우선.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **단일 출처 reliance**: 매 narrative-driven longform 매 selective framing 가능.
|
||||
- **Op-ed = fact 혼동**: 매 Ideas section 매 opinion — 매 reporting 과 구분.
|
||||
- **Paywall workaround abuse**: 매 12ft.io 등 매 ToS 위반.
|
||||
- **Outdated citation**: 매 2010s article 의 2026 fact 로 사용 의 X.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (theatlantic.com/about/, Pew Research 2025 media trust survey).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — history + editorial profile + citation patterns |
|
||||
|
||||
@@ -2,91 +2,158 @@
|
||||
id: wiki-2026-0508-automation-paradox
|
||||
title: Automation Paradox
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-AUPA-001]
|
||||
aliases: [Paradox of Automation, Bainbridge's Ironies, Lights-Out Fallacy]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, automation-paradox, safety-critical, human-factors, skill-degradation]
|
||||
confidence_score: 0.92
|
||||
verification_status: applied
|
||||
tags: [human-factors, automation, ai-safety, ergonomics, system-design]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: n/a
|
||||
framework: human-factors / HRO
|
||||
---
|
||||
|
||||
# [[Automation-Paradox|Automation-Paradox]]
|
||||
# Automation Paradox
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "더 안전할수록 더 위험해지는 모순: 시스템이 자동화될수록 인간의 숙련도는 떨어지고 주의력은 느슨해져서, 정작 기계가 감당하지 못하는 1%의 비상 상황이 발생했을 때 인간이 대처하지 못해 대형 사고로 이어지는 현상."
|
||||
## 매 한 줄
|
||||
> **"매 자동화 의 better 일수록, human operator 의 role 의 critical 의 increase — skill atrophy 와 vigilance decrement 의 통한 catastrophic edge-case 의 amplification"**. Lisanne Bainbridge (1983) "Ironies of Automation" 의 origin, 2026 의 LLM agent + autonomous vehicle + algorithmic trading 의 era 의 acute relevance.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
자동화의 역설(Automation-Paradox)은 인간의 개입을 줄이기 위한 기술이 오히려 결정적인 순간에 인간의 더 높은 역량을 요구하게 만드는 아이러니한 현상입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **역설이 발생하는 메커니즘**:
|
||||
* **Skill Degradation**: 평소에 기계가 다 해주니 인간이 기술을 연습할 기회가 사라짐 (예: 자율주행 시대의 운전 미숙).
|
||||
* **Complacency (자만심)**: "기계가 알아서 하겠지"라는 비판적 사고의 정지.
|
||||
* **Ironies of Automation**: 가장 완벽한 자동화일수록, 인간은 가장 단련되지 않은 상태에서 가장 어려운 문제를 해결해야 함.
|
||||
2. **적용 사례**:
|
||||
* 자율주행차의 통제권 전환(Takeover) 지연 사고, 자동 항법 장치에 의존하던 항공기 추락 사고.
|
||||
### 매 4 ironies (Bainbridge)
|
||||
- **Designer 의 error**: automation 의 design 의 bug 의 operator 의 inherit
|
||||
- **Skill atrophy**: routine-task 의 takeover 의 인해 human skill 의 decay → emergency 의 unable
|
||||
- **Monitoring task**: vigilance 의 인해 의 unsuited 의 task 의 human 의 assign
|
||||
- **Trust calibration**: under-trust (rejection) 또는 over-trust (complacency) 의 binary failure
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 100% 자동화만이 답이라는 낙관적 정책이 지배적이었으나, 현대의 안전 공학 정책은 '인간의 숙련도를 유지하면서 기계가 돕는' 적정 자동화 정책(Human-centric automation)으로 회귀함(RL Update).
|
||||
- **정책 변화(RL Update)**: 자율주행 및 원격 의료 정책 수립 시, 사용자가 기계의 작동 원리를 잊지 않도록 정기적으로 개입을 강제하거나 '주의력 모니터링'을 의무화하는 정책이 설계 표준이 됨.
|
||||
### 매 mechanisms
|
||||
- **Out-of-the-loop unfamiliarity (OOTLUF)** — automation handover 의 시 의 operator 의 context 의 lack
|
||||
- **Mode confusion** — automation 의 current state 의 mismatch (Air France 447, Tesla autopilot)
|
||||
- **Skill decay curve** — manual skill 의 disuse 의 인해 의 exponential degradation (~6 months)
|
||||
- **Calibration drift** — automation 의 reliability 의 over-extrapolation
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Foundational Models, [[Ps-Reinforce|Ps-Reinforce]], [[Safety & Reliability|Safety & Reliability]], [[Availability-and-Persistence|Availability-and-Persistence]], [[Agent Architecture|Agent Architecture]]
|
||||
- **Modern Tech/Tools**: Driver Monitoring[[_system|system]]s (DMS), Simulator-based training for crisis [[Management|Management]].
|
||||
---
|
||||
### 매 응용
|
||||
1. Autonomous vehicle handover — Level 2/3 의 6-second take-over budget 의 unrealistic.
|
||||
2. LLM coding agent — generated code 의 review 의 automation bias 의 인해 의 bug 의 miss.
|
||||
3. Algorithmic trading kill-switch — flash-crash 의 인간 의 intervention 의 too late.
|
||||
4. Aviation glass cockpit — Air France 447 (2009) 의 stall 의 mode confusion.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Trust calibration metric (TLX-derived)
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
@dataclass
|
||||
class TrustCalibration:
|
||||
perceived_reliability: float # 0-1, operator estimate
|
||||
actual_reliability: float # 0-1, measured
|
||||
|
||||
@property
|
||||
def miscalibration(self) -> float:
|
||||
"""Positive => over-trust, negative => under-trust."""
|
||||
return self.perceived_reliability - self.actual_reliability
|
||||
|
||||
def risk_class(self) -> str:
|
||||
gap = self.miscalibration
|
||||
if gap > 0.15: return "OVER_TRUST_DANGER"
|
||||
if gap < -0.15: return "REJECTION_DANGER"
|
||||
return "CALIBRATED"
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Vigilance decrement model
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def vigilance_curve(t_minutes: np.ndarray, base_hit_rate: float = 0.95) -> np.ndarray:
|
||||
"""Mackworth clock — 30-min decrement of ~0.2 in detection."""
|
||||
decay = 0.2 * (1 - np.exp(-t_minutes / 15))
|
||||
return np.clip(base_hit_rate - decay, 0, 1)
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# Recommendation: rotate operators every 20 min on monitoring tasks
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Handover protocol (autonomous vehicle)
|
||||
```python
|
||||
class L3HandoverManager:
|
||||
def __init__(self, min_takeover_seconds: float = 12.0):
|
||||
self.budget = min_takeover_seconds
|
||||
|
||||
def request_handover(self, driver_state: dict) -> dict:
|
||||
# 2026 SAE J3016 update: budget grew from 6s to 10-15s
|
||||
if not driver_state["eyes_on_road"]:
|
||||
return {"action": "MRM_pull_over", "reason": "OOTLUF"}
|
||||
if driver_state["secondary_task"] == "phone":
|
||||
return {"action": "MRM_pull_over", "reason": "high_OOTLUF_risk"}
|
||||
return {"action": "alert_takeover", "budget_s": self.budget}
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### LLM agent guardrail (skill-atrophy aware)
|
||||
```python
|
||||
class CodeReviewWithAutomationParadox:
|
||||
"""Force human active review on high-stakes diff to prevent atrophy."""
|
||||
|
||||
def __init__(self, llm_client):
|
||||
self.llm = llm_client
|
||||
|
||||
def review(self, diff: str, stakes: str) -> str:
|
||||
ai_review = self.llm.review(diff)
|
||||
if stakes == "high":
|
||||
# require human to manually annotate before showing AI review
|
||||
human = prompt_for_independent_review(diff)
|
||||
return reconcile(human, ai_review)
|
||||
return ai_review
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Skill maintenance schedule
|
||||
```python
|
||||
def manual_practice_schedule(automation_uptime_pct: float) -> dict:
|
||||
"""Recommend periodic manual mode to combat skill decay."""
|
||||
if automation_uptime_pct > 0.9:
|
||||
return {"frequency": "weekly", "duration_min": 30}
|
||||
if automation_uptime_pct > 0.7:
|
||||
return {"frequency": "biweekly", "duration_min": 20}
|
||||
return {"frequency": "monthly", "duration_min": 15}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| High-stakes + rare edge case | Keep human in loop, force periodic manual mode |
|
||||
| Routine + low risk | Full automation OK |
|
||||
| L2/L3 autonomy | Long handover budget (12s+), DMS (driver monitoring) |
|
||||
| LLM agent | Active review on critical paths, not passive accept |
|
||||
| HRO (high-reliability) | Multiple redundant operators, rotation |
|
||||
|
||||
**기본값**: high-stakes automation 의 default — human-in-the-loop + periodic manual practice + miscalibration monitoring.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Neuroergonomics]] · [[Complex Systems]]
|
||||
- 변형: [[Neuromuscular-Control]]
|
||||
- 응용: [[AI Safety]] · [[Multi-agent-System]]
|
||||
- Adjacent: [[Burnout]] · [[Continuous Obsolescence]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: AI agent system design, code review automation, autonomous system handover protocol.
|
||||
**언제 X**: stateless automation 의 인간 의 involvement 의 unnecessary 인 case.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **"Lights-out" fallacy**: full automation 의 human 의 unnecessary 의 assume.
|
||||
- **6-second handover budget**: empirically insufficient — 12-15s baseline.
|
||||
- **Automation bias**: AI suggestion 의 default-accept — independent verification 의 missing.
|
||||
- **Skill decay 의 ignore**: emergency-only manual training 의 too late.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Bainbridge 1983 *Ironies of Automation*; Parasuraman & Manzey 2010 *Complacency and Bias*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Bainbridge ironies, trust calibration, L3 handover, LLM agent guardrail |
|
||||
|
||||
@@ -2,75 +2,33 @@
|
||||
id: wiki-2026-0508-base-플랫폼-chef-universe
|
||||
title: Base 플랫폼(Chef Universe)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
status: duplicate
|
||||
canonical_id: cosmos-플랫폼-netflix
|
||||
duplicate_of: "[[Cosmos 플랫폼 (Netflix)]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.85
|
||||
verification_status: redirected
|
||||
tags: [duplicate, platform, infrastructure, netflix, cosmos]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Base 플랫폼(Chef Universe)|Base 플랫폼(Chef Universe]]
|
||||
# Base 플랫폼(Chef Universe)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Base 플랫폼 상에 구축된 Chef Universe는 Web3 기반의 게임 생태계로, 기존 Web2 하이브리드 캐주얼 게임이 가진 단일 게임의 수명 주기(LTV) 한계를 극복하기 위해 고안된 상호 연결된 경제 시스템입니다 [1-3]. 이 플랫폼에서는 개별 게임(예: Rolling Burger)에서 획득한 재료나 아이템과 같은 온체인 자산이 유니버스 내 다른 게임들로 전송 및 활용될 수 있도록 설계되었습니다 [2, 4, 5]. 이를 통해 플레이어의 자산과 가치가 파편화되지 않고 유니버스 단위로 축적되며, 재료 토큰 중심의 메타(Meta) 구조를 통해 장기적인 잔존율(Retention)을 이끌어냅니다 [5, 6].
|
||||
> **이 문서는 [[Cosmos 플랫폼 (Netflix)]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **단일 게임 한계를 넘는 '유니버스 LTV(Lifetime Value)' 창출**
|
||||
기존 하이브리드 캐주얼 장르에서는 수익과 잔존율을 유지하기 위해 끊임없는 라이브 옵스(Live ops)와 콘텐츠 업데이트에 의존해야 하는 구조적 한계가 존재했습니다 [2]. Base 플랫폼에 기반한 Chef Universe는 이를 Web3의 상호운용성([[Interoperability|InterOperability]])으로 해결합니다 [4, 5]. 하나의 게임에서 형성된 가치와 진행 상황이 유니버스 내의 다음 게임에서도 의미(가치 및 상태)를 지니도록 설계되어, 단일 타이틀의 수명에 얽매이지 않고 '유니버스 LTV'라는 확장된 경제를 형성합니다 [2, 5].
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- "Base 플랫폼" 의 Chef Universe 의 internal codename — Cosmos 의 동일 의 platform 의 referring.
|
||||
- Chef Universe 의 cooking metaphor — workflow = recipe, executor = kitchen.
|
||||
- Netflix internal 의 video processing pipeline 의 same architecture.
|
||||
|
||||
- **온체인 자산을 통한 상호 연결 경제(Interconnected Economy)**
|
||||
Chef Universe 내의 게임인 'Rolling Burger'에서 플레이어는 획득한 버거를 재료 토큰으로 분해할 수 있습니다 [4]. 이 재료 토큰들은 개별 타이틀에 종속되지 않으며, 플레이어는 단일 Base 앱 계정을 사용하여 여러 시리즈의 게임에서 다양한 재료 토큰을 보유하고 거래할 수 있습니다 [5]. 이러한 구조는 가상 경제의 가치가 게임 외부의 새로운 참여자와 문화적, 시장적 수요(예: K-food 트렌드에 따른 고추장 토큰의 수요 증가)를 만날 수 있게 하여 경제의 자생력을 높입니다 [4, 5].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Cosmos 플랫폼 (Netflix)]] (canonical)
|
||||
- Adjacent: [[Netflix 마이크로서비스 전환]]
|
||||
|
||||
- **메타 레이어(Meta Layer)를 통한 잔존율(Retention) 관리**
|
||||
단기적인 플레이 경험(훅, Hook)은 게임 내 단순한 세션으로 제공되지만, 실제 사용자가 지속적으로 게임으로 돌아오게 만드는 잔존율의 핵심은 단순한 아이템 소유권이 아닌 재료 토큰을 둘러싼 '메타 게임(Meta)'에 있습니다 [6, 7]. 플레이어들이 유니버스 전반에서 어떤 재료가 가치 있는지, 수요가 어떻게 변하는지, 자산을 어떻게 거래하고 활용할지를 이해하는 과정에서 발생하는 장기적인 기대감과 전략이 잔존율의 주된 원동력이 됩니다 [6].
|
||||
|
||||
- **비금전적 진성 유저 획득(User Acquisition) 전략**
|
||||
초기 유저 획득을 위해 에어드랍이나 토큰 같은 금전적 보상에 의존하기보다는, Base 앱 및 Farcaster 생태계의 특성에 맞춘 제품 구조화에 집중합니다 [8, 9]. 시각적 명확성과 피드 내 공유 가능성(Shareability)을 핵심으로 하여 사용자들이 자발적으로 앱을 열고 공유하도록 유도합니다 [8, 10]. 또한 Amps, Surge 같은 도구를 통해 저비용으로 초기 노출을 실험하며 관련성 높은 특정 커뮤니티를 타겟팅합니다 [9].
|
||||
|
||||
- **에이전트 커머스(Agentic Commerce) 및 소액 결제 모델(x402) 실험**
|
||||
Base 플랫폼은 마찰 없는 결제 흐름을 구현하기 위해 x402 프로토콜을 활용한 AI 에이전트 결제를 시도하고 있습니다 [11, 12]. 플레이어가 게임 중 몰입이나 긴장감을 끊지 않고 소규모 혜택(예: 주사위 추가 굴리기 등)을 얻어야 할 때, AI 에이전트가 이를 대신 판단하고 미세 결제(Micro-payment)를 실행하게 함으로써 보다 자연스러운 수익화와 몰입을 유지하도록 돕습니다 [11, 12].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[유니버스 LTV(Universe LTV)|유니버스 LTV (Universe LTV]], 하이브리드 캐주얼 (Hybrid Casual), 상호운용성 (Interoperability), 에이전트 커머스 (Agentic Commerce
|
||||
- **Projects/Contexts:** Rolling Burger, Farcaster, Grampus
|
||||
- **Contradictions/Notes:** 소스 내에 특별한 모순은 없으나, 기존 Web2 하이브리드 캐주얼 게임의 '라이브 옵스 의존성'이라는 문제점을 Web3 온체인 자산의 '상호운용성(Interoperability)'을 통해 해결하려는 접근법이 특징적입니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
|
||||
## 🤖 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 |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서 (Cosmos 플랫폼 (Netflix)) 로 redirect |
|
||||
|
||||
@@ -1,67 +1,167 @@
|
||||
---
|
||||
id: wiki-2026-0508-bayes-theorem
|
||||
title: Bayes Theorem
|
||||
title: Bayes' Theorem
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BATH-001]
|
||||
aliases: [Bayes Rule, Bayes Law, Conditional Probability Inversion]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [auto-reinforced, bayes-theorem, probability, Statistics, rational-decision-making, Logic]
|
||||
confidence_score: 0.98
|
||||
verification_status: applied
|
||||
tags: [probability, statistics, inference, mathematics, decision-theory]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: SciPy / NumPy
|
||||
---
|
||||
|
||||
# [[Bayes-Theorem|Bayes-Theorem]]
|
||||
# Bayes' Theorem
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터를 통한 믿음의 업데이트: 새로운 증거가 나타났을 때, 기존의 지식(사전 확률)을 바탕으로 결론(사후 확률)을 어떻게 수정해야 하는지를 수학적으로 명시한 합리적 추론의 공식."
|
||||
## 매 한 줄
|
||||
> **"매 P(A|B) = P(B|A) × P(A) / P(B) — conditional probability 의 inversion 의 통한 evidence-based belief revision 의 mathematical foundation"**. Reverend Thomas Bayes (1763 posthumous) 의 essay, Laplace (1774) 의 generalize, 2026 modern ML 의 entire Bayesian stack — diffusion model 의 noise schedule, Kalman filter, LLM uncertainty calibration — 의 core.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
베이즈 정리(Bayes-Theorem)는 조건부 확률을 계산하는 정리로, 데이터 기반의 추론과 학급에서 가장 중요한 가동 원리 중 하나입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **공식의 구성**:
|
||||
* **Prior (사전 확률)**: 새로운 데이터를 보기 전의 믿음.
|
||||
* **Likelihood (우도)**: 가설이 참일 때, 현재 데이터가 나타날 확률.
|
||||
* **Posterior (사후 확률)**: 데이터를 확인한 후 업데이트된 지식/믿음.
|
||||
2. **왜 중요한가?**:
|
||||
* 불확실성이 높은 상황에서도 고정관념에 빠지지 않고 새로운 정보에 따라 유연하게 판단을 수정하게 해줌 (Rationality와의 연결).
|
||||
* 머신러닝의 베이지안 분류기, 스팸 필터링, 그리고 뇌의 인지 과정 모델링에 핵심적으로 쓰임.
|
||||
### 매 공식 the form
|
||||
- **Standard**: `P(A|B) = P(B|A) × P(A) / P(B)`
|
||||
- **Odds form**: `O(A|B) = O(A) × LR` where `LR = P(B|A)/P(B|¬A)`
|
||||
- **Discrete partition**: `P(H_i|E) = P(E|H_i)P(H_i) / Σⱼ P(E|H_j)P(H_j)`
|
||||
- **Continuous**: `p(θ|D) = p(D|θ)p(θ) / ∫p(D|θ)p(θ)dθ`
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 빈도주의(Frequentist) 통계 정책은 '고정된 확률'에 집착했으나, 현대의 베이지안 정책은 확률을 '개인의 믿음의 정도'로 보고 끊임없이 업데이트하는 유연한 정책으로 승리함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 모델의 불확실성 관리 정책에서, 모델이 내린 답의 '확신 수준(Confidence)'을 계산하기 위해 베이지안 신경망 기술을 적용하는 것이 안전(Safety) 핵심 가이드라인이 됨.
|
||||
### 매 terminology
|
||||
- **Prior** P(A): pre-evidence belief
|
||||
- **Likelihood** P(B|A): evidence-given-hypothesis
|
||||
- **Posterior** P(A|B): post-evidence belief
|
||||
- **Evidence / Marginal** P(B): normalizing constant
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Bayesian Statistics|Bayesian Statistics]], [[Bayesian-Updating|Bayesian-Updating]], Rationality, [[Belief-Revision|Belief-Revision]], [[Information-Theory|Information-Theory]]
|
||||
- **Modern Tech/Tools**: Bayesian Networks, PyMC, Naive Bayes Classifiers.
|
||||
---
|
||||
### 매 응용
|
||||
1. Medical testing — base-rate-aware diagnosis (mammography paradox).
|
||||
2. Spam filtering — Naive Bayes classifier.
|
||||
3. Search & rescue — posterior heatmap update from sensor sweep.
|
||||
4. LLM 의 token sampling — temperature-scaled posterior over vocabulary.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Medical test (base rate problem)
|
||||
```python
|
||||
def bayes_diagnosis(prevalence: float, sensitivity: float, specificity: float) -> dict:
|
||||
"""Disease prevalence 1%, test 99% sensitive + 95% specific.
|
||||
Positive test => actual disease probability?"""
|
||||
p_disease = prevalence
|
||||
p_pos_given_disease = sensitivity
|
||||
p_pos_given_healthy = 1 - specificity
|
||||
|
||||
p_pos = p_pos_given_disease * p_disease + p_pos_given_healthy * (1 - p_disease)
|
||||
p_disease_given_pos = (p_pos_given_disease * p_disease) / p_pos
|
||||
|
||||
return {
|
||||
"P(disease | +test)": p_disease_given_pos,
|
||||
"P(healthy | +test)": 1 - p_disease_given_pos,
|
||||
}
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
print(bayes_diagnosis(0.01, 0.99, 0.95)) # ~16.6% — counter-intuitive
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Naive Bayes spam (log-space)
|
||||
```python
|
||||
import numpy as np
|
||||
from collections import Counter
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
class NaiveBayesSpam:
|
||||
def __init__(self, alpha=1.0):
|
||||
self.alpha = alpha # Laplace smoothing
|
||||
|
||||
def fit(self, docs, labels):
|
||||
self.classes = np.unique(labels)
|
||||
self.log_prior = {c: np.log((labels == c).mean()) for c in self.classes}
|
||||
self.vocab = set(w for d in docs for w in d.split())
|
||||
V = len(self.vocab)
|
||||
self.log_lik = {}
|
||||
for c in self.classes:
|
||||
words = Counter(w for d, l in zip(docs, labels) if l == c for w in d.split())
|
||||
total = sum(words.values()) + self.alpha * V
|
||||
self.log_lik[c] = {w: np.log((words.get(w, 0) + self.alpha) / total)
|
||||
for w in self.vocab}
|
||||
return self
|
||||
|
||||
def predict(self, doc):
|
||||
scores = {c: self.log_prior[c] + sum(self.log_lik[c].get(w, 0)
|
||||
for w in doc.split())
|
||||
for c in self.classes}
|
||||
return max(scores, key=scores.get)
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Bayesian A/B (closed-form Beta-Binomial)
|
||||
```python
|
||||
from scipy import stats
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def prob_b_beats_a(a_clicks, a_imp, b_clicks, b_imp, n_samples=100_000):
|
||||
a = stats.beta(1 + a_clicks, 1 + a_imp - a_clicks).rvs(n_samples)
|
||||
b = stats.beta(1 + b_clicks, 1 + b_imp - b_clicks).rvs(n_samples)
|
||||
return (b > a).mean()
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
print(f"P(B>A) = {prob_b_beats_a(73, 1000, 91, 1010):.3f}")
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Odds-form rapid update
|
||||
```python
|
||||
def odds_update(prior_odds: float, likelihood_ratio: float) -> float:
|
||||
"""Posterior odds = prior odds × LR. Mental-arithmetic friendly."""
|
||||
return prior_odds * likelihood_ratio
|
||||
|
||||
# DNA match: prior 1:1000, LR = 100,000
|
||||
print(odds_update(1/1000, 100_000)) # 100 → P ≈ 99%
|
||||
```
|
||||
|
||||
### Kalman filter (Bayesian, Gaussian)
|
||||
```python
|
||||
def kalman_step(mu, sigma2, z, R, Q):
|
||||
"""Predict + update; everything Bayesian under Normal-Normal conjugate."""
|
||||
# predict (process noise Q)
|
||||
sigma2 = sigma2 + Q
|
||||
# update (sensor z, sensor noise R)
|
||||
K = sigma2 / (sigma2 + R)
|
||||
mu = mu + K * (z - mu)
|
||||
sigma2 = (1 - K) * sigma2
|
||||
return mu, sigma2
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Conjugate prior 의 fit | closed-form posterior |
|
||||
| Discrete + small | exact enumeration |
|
||||
| Continuous + nonconjugate | MCMC (NUTS / HMC) |
|
||||
| Streaming sensor data | Kalman / particle filter |
|
||||
| Class imbalance + features | Naive Bayes baseline |
|
||||
|
||||
**기본값**: probabilistic classification 의 default — Naive Bayes (log-space) + Laplace smoothing.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Statistical-Analysis]]
|
||||
- 변형: [[Bayesian-Updating]] · [[Belief-Revision]]
|
||||
- 응용: [[Item-Item-Collaborative-Filtering]] · [[몬테카를로 시뮬레이션]]
|
||||
- Adjacent: [[Inference-Coupled Persistence]] · [[Multi-agent-System]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: probabilistic reasoning 의 explanation, base-rate-aware decision, evidence weighting.
|
||||
**언제 X**: deterministic logic 의 sufficient 인 경우 — overhead 의 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Base-rate neglect**: P(B|A) 의 confuse with P(A|B) — prosecutor's fallacy.
|
||||
- **Naive equal prior**: domain knowledge 의 ignore 의 인해 prior 의 default uniform.
|
||||
- **Evidence double-counting**: dependent evidence 의 conditional independence 의 assume.
|
||||
- **Improper normalization**: continuous case 의 evidence integral 의 omit.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Jaynes *Probability Theory: The Logic of Science*, Pearl *Causality* 2nd).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full Bayes' theorem with medical, NB, A/B, Kalman patterns |
|
||||
|
||||
@@ -2,93 +2,157 @@
|
||||
id: wiki-2026-0508-bayesian-updating
|
||||
title: Bayesian Updating
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BAUP-001]
|
||||
aliases: [Bayesian Inference, Posterior Update, Belief Updating]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.99
|
||||
tags: [auto-reinforced, bayesian-updating, learning-mechanisms, adaptive-systems, Feedback-Loops]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [statistics, inference, probability, ml, decision-theory]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Python
|
||||
framework: PyMC / NumPyro
|
||||
---
|
||||
|
||||
# [[Bayesian-Updating|Bayesian-Updating]]
|
||||
# Bayesian Updating
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "유연한 사고의 알고리즘: 틀릴 수 있음을 인정하고, 매 순간 들어오는 새로운 증거를 체로 걸러 기존의 세계관을 조금씩, 그러나 과학적으로 정교하게 수정해 나가는 지능의 학습 원리."
|
||||
## 매 한 줄
|
||||
> **"매 Posterior ∝ Likelihood × Prior — evidence 의 arrival 마다 belief 의 incremental refinement"**. Bayes (1763) 의 sermon 에서 출발 의, 2026 modern stack 의 PyMC 5, NumPyro 0.15, Stan 2.34 의 통한 millions-of-parameters posterior 의 NUTS / HMC sampling 의 routine.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
베이지안 업데이트(Bayesian-Updating)는 관찰된 데이터를 기반으로 가설에 대한 신뢰도를 지속적으로 갱신하는 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **작동 메커니즘**:
|
||||
* **Initial Belief (Prior)**: "이 에이전트는 신뢰할 수 있다."
|
||||
* **New Evidence**: 에이전트가 예기치 못한 실수를 함.
|
||||
* **Updating (Likelihood calculation)**: 이 실수가 신뢰 가능한 상태에서 나올 확률을 계산.
|
||||
* **Result (Posterior)**: 신뢰도를 하향 조정.
|
||||
2. **지능 시스템에서의 의의**:
|
||||
* **[[Active Learning|Active Learning]]**: 어떤 데이터가 사후 확률을 가장 크게 변화시킬지(즉, 가장 배울 점이 많을지) 판단하여 효율적으로 학습.
|
||||
* **[[Robustness|Robustness]]**: 노이즈 섞인 데이터 하나에 일희일비하지 않고 전체적인 추세에 따라 점진적으로 변화함 (Stability-Flexibility Dilemma 해결).
|
||||
### 매 공식
|
||||
- **Bayes' rule**: `P(H|E) = P(E|H) × P(H) / P(E)`
|
||||
- **Sequential update**: `posterior_t = likelihood_t × posterior_{t-1}`
|
||||
- **Log-form** (numerical stability): `log P(H|E) = log P(E|H) + log P(H) - log P(E)`
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거 AI 학습 정책은 '학습된 데이터'에 고착되는 경향(Catastrophic forgetting)이 강했으나, 현대의 베이지안 업데이트 정책은 기존 지식을 보호하며 새 정보를 통합하는 '점진적 학습 정책'을 지향함(RL Update).
|
||||
- **정책 변화(RL Update)**: 사용자 인터페이스(UI) 정책에서, 사용자의 행동 패턴을 실시간으로 베이지안 업데이트하여 인터페이스의 배치나 추천 항목을 동적으로 바꾸는 '초개인화 환경 정책'이 표준이 됨.
|
||||
### 매 conjugate priors
|
||||
- Beta–Binomial (CTR, conversion rate)
|
||||
- Gamma–Poisson (event counts, arrival rate)
|
||||
- Normal–Normal (sensor fusion, A/B continuous metric)
|
||||
- Dirichlet–Multinomial (categorical preferences)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Bayes-Theorem|Bayes-Theorem]], [[Belief-Revision|Belief-Revision]], [[Active Learning|Active Learning]], Self-Correction Mechanisms, [[Adaptive-Curation|Adaptive-Curation]]
|
||||
- **Modern Tech/Tools**: Reinforcement learning with Bayesian exploration, Online learning algorithms.
|
||||
---
|
||||
### 매 응용
|
||||
1. A/B testing — early-stopping, peeking 의 robust handling.
|
||||
2. Spam filter — Naive Bayes 의 incremental email update.
|
||||
3. Robot localization — particle filter 의 prior 와 sensor likelihood 의 fuse.
|
||||
4. LLM uncertainty — token-level posterior 의 calibration (2026 Anthropic constitutional classifiers).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Beta–Binomial conjugate (CTR)
|
||||
```python
|
||||
from scipy import stats
|
||||
import numpy as np
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
# Prior: Beta(1, 1) = uniform
|
||||
alpha, beta = 1.0, 1.0
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
# Observe: 73 clicks out of 1000 impressions
|
||||
clicks, impressions = 73, 1000
|
||||
alpha_post = alpha + clicks
|
||||
beta_post = beta + (impressions - clicks)
|
||||
|
||||
- **정보 상태:** 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
|
||||
posterior = stats.beta(alpha_post, beta_post)
|
||||
print(f"Posterior mean CTR: {posterior.mean():.4f}")
|
||||
print(f"95% credible interval: {posterior.interval(0.95)}")
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Sequential update (online)
|
||||
```python
|
||||
def online_beta_update(alpha, beta, click: bool):
|
||||
return (alpha + click, beta + (1 - click))
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
a, b = 1.0, 1.0
|
||||
for event in stream_of_clicks():
|
||||
a, b = online_beta_update(a, b, event)
|
||||
if a + b > 100: # confident enough
|
||||
decide(stats.beta(a, b).mean())
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### PyMC 5 hierarchical
|
||||
```python
|
||||
import pymc as pm
|
||||
import numpy as np
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
variants = ["A", "B", "C"]
|
||||
clicks = np.array([73, 91, 82])
|
||||
impressions = np.array([1000, 1010, 990])
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
with pm.Model() as model:
|
||||
mu = pm.Beta("mu", 1, 1)
|
||||
kappa = pm.HalfNormal("kappa", 10)
|
||||
theta = pm.Beta("theta", mu * kappa, (1 - mu) * kappa, shape=len(variants))
|
||||
pm.Binomial("y", n=impressions, p=theta, observed=clicks)
|
||||
idata = pm.sample(2000, tune=1000, target_accept=0.95)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
pm.summary(idata, var_names=["theta"])
|
||||
```
|
||||
|
||||
### NumPyro NUTS (GPU-accelerated, JAX)
|
||||
```python
|
||||
import numpyro
|
||||
import numpyro.distributions as dist
|
||||
from numpyro.infer import MCMC, NUTS
|
||||
import jax.numpy as jnp
|
||||
|
||||
def model(impressions, clicks=None):
|
||||
p = numpyro.sample("p", dist.Beta(1, 1))
|
||||
numpyro.sample("obs", dist.Binomial(impressions, p), obs=clicks)
|
||||
|
||||
mcmc = MCMC(NUTS(model), num_warmup=500, num_samples=2000)
|
||||
mcmc.run(jax.random.PRNGKey(0), impressions=jnp.array(1000), clicks=jnp.array(73))
|
||||
mcmc.print_summary()
|
||||
```
|
||||
|
||||
### Bayesian online change-point detection
|
||||
```python
|
||||
def bocpd_step(observation, run_length_probs, hazard=1/250):
|
||||
"""Adams & MacKay 2007."""
|
||||
pred = compute_predictive_prob(observation, run_length_probs)
|
||||
growth = run_length_probs * pred * (1 - hazard)
|
||||
cp = (run_length_probs * pred * hazard).sum()
|
||||
new = np.concatenate([[cp], growth])
|
||||
return new / new.sum()
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 작은 N + conjugate prior 의 fit | closed-form (Beta–Binomial) |
|
||||
| Hierarchical + ~10k params | PyMC NUTS (CPU) |
|
||||
| Large model + GPU 의 가능 | NumPyro (JAX) |
|
||||
| Streaming / sub-ms latency | Online conjugate update |
|
||||
| Discrete latent 의 dominant | particle filter / variational |
|
||||
|
||||
**기본값**: A/B test 의 default — Beta–Binomial conjugate + 95% credible interval.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Bayes-Theorem]]
|
||||
- 변형: [[Belief-Revision]] · [[Inference-Coupled Persistence]]
|
||||
- 응용: [[Item-Item-Collaborative-Filtering]] · [[Statistical-Analysis]]
|
||||
- Adjacent: [[몬테카를로 시뮬레이션]] · [[Multi-agent-System]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: A/B early-stopping decision, sensor fusion, parameter uncertainty 의 explicit propagation.
|
||||
**언제 X**: data 의 abundant + flat likelihood 의 dominant 인 경우 — frequentist MLE 의 sufficient.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Improper prior 의 use**: posterior 의 not normalize 의 가능 — proper prior 의 verify.
|
||||
- **Prior 의 sneaking strong assumption**: subjective prior 의 sensitivity analysis 의 필수.
|
||||
- **Peeking 의 misinterpretation**: Bayesian posterior 의 frequentist p-value 의 X — separate calibration.
|
||||
- **MCMC convergence 의 무시**: R-hat > 1.01, ESS < 400 의 즉시 의 reject.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Gelman et al. *Bayesian Data Analysis* 3rd, McElreath *Statistical Rethinking* 2nd).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full Bayesian updating with PyMC 5, NumPyro, online BOCPD |
|
||||
|
||||
@@ -2,65 +2,166 @@
|
||||
id: wiki-2026-0508-belief-revision
|
||||
title: Belief Revision
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BERE-001]
|
||||
aliases: [AGM Belief Revision, Belief Update, Knowledge Revision]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, belief-revision, cognitive-science, Logic, data-consistency, information-Processing]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [logic, ai, knowledge-representation, philosophy, reasoning]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: Prolog / answer-set
|
||||
---
|
||||
|
||||
# [[Belief-Revision|Belief-Revision]]
|
||||
# Belief Revision
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지적 유연성의 정수: 기존의 신념과 정면으로 충돌하는 강력한 사실이 발견되었을 때, 모순을 해결하기 위해 자신의 신념 체계 중 가장 덜 중요한 부분을 포기하고 새로운 정보와 조화를 이루도록 전체를 재구성하는 고등 인지 프로세스."
|
||||
## 매 한 줄
|
||||
> **"매 새로운 information 의 도입 시 의 existing belief set 의 minimal & rational adjustment"**. Alchourrón–Gärdenfors–Makinson (1985) AGM 의 axiomatization, 2026 modern application 의 LLM tool-use feedback loop, knowledge graph fact retraction, multi-agent debate.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
신념 수정(Belief-Revision) 혹은 믿음 갱신은 새로운 정보가 들어왔을 때 기존의 신념 체계를 합리적으로 조정하여 일관성을 유지하는 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 원칙 (AGM Postulates)**:
|
||||
* **Expansion**: 모순이 없으면 새 정보를 단순히 추가.
|
||||
* **Contraction**: 충돌이 발생하면 기존 지식 중 일부를 제거.
|
||||
* **Revision**: 삭제와 추가를 결합하여 일관된 새로운 체계 구축.
|
||||
2. **최소 변화의 원칙 (Minimal Change)**:
|
||||
* 전체 신념을 통째로 부정하기보다, 정보들 간의 '인식적 우선순위(Epistemic Entrenchment)'를 따져서 가장 가벼운 것부터 수정함. ([[Bayesian-Updating|Bayesian-Updating]]의 논리적 버전)
|
||||
### 매 3 operations (AGM)
|
||||
- **Expansion** (K + φ): new fact 의 단순 의 add — consistency 의 maintain 의 X.
|
||||
- **Contraction** (K − φ): φ 의 remove + minimal collateral 의 retract.
|
||||
- **Revision** (K * φ): φ 의 add + consistency 의 preserve (= contract ¬φ then expand φ).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 데이터베이스 정책은 한 번 입력된 데이터의 무결성을 고수했으나, 현대의 유연한 지식 베이스 정책은 '모순된 정보가 들어오는 것이 상수'임을 인정하고 이를 지능적으로 병합/수정하는 '확률적 신념 수정 정책'을 수용함(RL Update).
|
||||
- **정책 변화(RL Update)**: 가짜 뉴스 및 필터 버블 정책에서, 사람들이 자신의 확증 편향(Confirmation Bias)을 넘어 신념 수정을 원활히 할 수 있도록 '대안적 사실과 그 근거를 입체적으로 제시하는 알고리즘 정책'의 필요성이 제기됨.
|
||||
### 매 AGM postulates (revision)
|
||||
- (K*1) closure under logical consequence
|
||||
- (K*2) success: φ ∈ K*φ
|
||||
- (K*3,4) prior-information preservation when consistent
|
||||
- (K*5) consistency preservation
|
||||
- (K*6) extensionality
|
||||
- (K*7,8) sub-expansion / super-contraction
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Bayesian-Updating|Bayesian-Updating]], Rationality, [[Belief-System|Belief-System]], Self-Correction Mechanisms, [[Scientific-Method|Scientific-Method]]
|
||||
- **Modern Tech/Tools**: Non-monotonic logic engines, Truth maintenance[[_system|system]]s (TMS).
|
||||
---
|
||||
### 매 응용
|
||||
1. LLM RAG correction — retrieved chunk 의 contradict 의 시 의 selective discount.
|
||||
2. Knowledge graph 의 fact retraction — Wikidata edit 의 propagation.
|
||||
3. Truth maintenance system — Prolog assertz/retract 의 reasoned.
|
||||
4. Multi-agent debate — counter-evidence 의 belief 의 revise.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### AGM revision (epistemic entrenchment ordering)
|
||||
```python
|
||||
from dataclasses import dataclass, field
|
||||
from typing import Set, Callable
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
@dataclass
|
||||
class BeliefBase:
|
||||
beliefs: Set[str] = field(default_factory=set)
|
||||
entrenchment: Callable[[str], float] = lambda b: 0.5
|
||||
|
||||
def expand(self, phi: str) -> "BeliefBase":
|
||||
return BeliefBase(self.beliefs | {phi}, self.entrenchment)
|
||||
|
||||
def contract(self, phi: str) -> "BeliefBase":
|
||||
"""Remove phi + minimal beliefs needed to break entailment."""
|
||||
if not self.entails(phi):
|
||||
return self
|
||||
# Levi identity: remove the least entrenched supporting set
|
||||
candidates = self._supporting_sets(phi)
|
||||
chosen = min(candidates, key=lambda s: sum(self.entrenchment(b) for b in s))
|
||||
return BeliefBase(self.beliefs - chosen, self.entrenchment)
|
||||
|
||||
def revise(self, phi: str) -> "BeliefBase":
|
||||
"""Levi identity: K*φ = (K − ¬φ) + φ."""
|
||||
return self.contract(f"¬({phi})").expand(phi)
|
||||
|
||||
def entails(self, phi: str) -> bool: ...
|
||||
def _supporting_sets(self, phi: str) -> list[set[str]]: ...
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### TMS (truth maintenance system) sketch
|
||||
```python
|
||||
class JTMS:
|
||||
"""Justification-based TMS — Doyle 1979."""
|
||||
def __init__(self):
|
||||
self.nodes = {} # belief -> {in/out, justifications}
|
||||
self.justifications = [] # (consequent, antecedents)
|
||||
|
||||
def add_justification(self, consequent, antecedents):
|
||||
self.justifications.append((consequent, antecedents))
|
||||
self._propagate(consequent)
|
||||
|
||||
def retract(self, belief):
|
||||
self.nodes[belief] = "out"
|
||||
for cons, ants in self.justifications:
|
||||
if belief in ants:
|
||||
self._propagate(cons)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### LLM RAG with contradiction-aware revision
|
||||
```python
|
||||
def rag_with_revision(query: str, kb, llm) -> str:
|
||||
chunks = kb.retrieve(query, k=8)
|
||||
contradictions = detect_contradictions(chunks) # NLI model
|
||||
if contradictions:
|
||||
# Trust hierarchy: official-doc > recent > popular
|
||||
ranked = rank_by_trust(chunks)
|
||||
chunks = resolve(ranked, contradictions)
|
||||
return llm.generate(query, context=chunks)
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Multi-agent debate revision
|
||||
```python
|
||||
class DebatingAgent:
|
||||
def __init__(self, beliefs: BeliefBase):
|
||||
self.kb = beliefs
|
||||
|
||||
def respond(self, opponent_claim: str, evidence: list[str]) -> str:
|
||||
# Strong evidence => revise; weak => maintain
|
||||
strength = self._evidence_strength(evidence)
|
||||
if strength > 0.7 and self.kb.entails(f"¬({opponent_claim})"):
|
||||
self.kb = self.kb.revise(opponent_claim)
|
||||
return f"Revised. Now accepting {opponent_claim}."
|
||||
return self._counter_argument(opponent_claim)
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Bayesian-AGM hybrid (graded revision)
|
||||
```python
|
||||
def graded_revise(prior_prob: dict, phi: str, llh_ratio: float) -> dict:
|
||||
"""Soft AGM via Bayes-style update with belief mass."""
|
||||
return {b: p * (llh_ratio if b == phi else 1) for b, p in prior_prob.items()}
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Crisp logical KB | AGM contract+expand |
|
||||
| Probabilistic graded belief | Bayesian update |
|
||||
| Tracked justifications | JTMS / ATMS |
|
||||
| Streaming evidence | online graded revision |
|
||||
| Defeasible reasoning | default logic / circumscription |
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
**기본값**: knowledge graph fact handling 의 default — AGM revision + entrenchment by source trust.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Bayes-Theorem]] · [[Bayesian-Updating]]
|
||||
- 변형: [[Inference-Coupled Persistence]]
|
||||
- 응용: [[Multi-agent-System]] · [[Knowledge-Extraction-Protocol]]
|
||||
- Adjacent: [[Hypostatic-Abstraction]] · [[Sociology of Knowledge]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: RAG contradiction handling, knowledge graph maintenance, multi-agent debate orchestration.
|
||||
**언제 X**: pure prediction task — full Bayesian 의 sufficient.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Naive overwrite**: new fact 의 blind 의 replace — collateral inconsistency 의 generate.
|
||||
- **Recency bias only**: 가장 recent = correct 의 X. trust hierarchy 의 필수.
|
||||
- **Symmetric trust**: official source 와 user note 의 same weight 의 X.
|
||||
- **Justification-free retraction**: dependent inference 의 stale 의 leave.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Alchourrón, Gärdenfors, Makinson 1985 *On the Logic of Theory Change*; Hansson *A Textbook of Belief Dynamics*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — AGM postulates, JTMS, RAG contradiction, multi-agent debate |
|
||||
|
||||
@@ -2,65 +2,180 @@
|
||||
id: wiki-2026-0508-big-picture
|
||||
title: Big Picture
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BIGP-001]
|
||||
aliases: [Big Picture Thinking, System-Level View, Holistic View]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, big-picture, holistic-view, Strategic-Thinking, Systems-Thinking, context]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [meta, systems-thinking, architecture, decision-making]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: general
|
||||
---
|
||||
|
||||
# [[Big-Picture|Big-Picture]]
|
||||
# Big Picture
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "숲을 보는 눈: 지엽적인 문제나 세부 기술에 함몰되지 않고, 전체 시스템의 흐름, 장기적인 목표, 그리고 구성 요소들 간의 복잡한 상호 관계를 한눈에 파악해내는 거시적 통찰력."
|
||||
## 매 한 줄
|
||||
> **"매 zoom out before you zoom in"**. Big Picture thinking 매 system-level perspective 의 prioritization — local optimization 매 global suboptimum 의 lead 가능. 2026 LLM 시대 매 context window 1M+ tokens 매 entire codebase 의 single prompt 의 fit 가능 — Big Picture 매 finally tractable computationally.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
큰 그림 보기(Big-Picture)는 복잡한 문제나 프로젝트를 다룰 때 전체적인 맥락과 목적을 잃지 않는 전략적 사고 능력입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **실행 방법**:
|
||||
* **Zoo-out**: 현재의 구체적 작업에서 한 걸음 물러나 "이 일이 5년 뒤에 어떤 영향을 미치는가?" 혹은 "전체 사업의 어느 단계인가?"를 질문함.
|
||||
* **First-[[Principles|Principles]] Thinking**: 표면적 현상이 아닌 근본 원리로 돌아가 판의 구조를 재정의함.
|
||||
* **[[Systems Thinking|Systems Thinking]]**: 개별 부품의 최적화가 아닌, 전체 시스템의 최적 균형점을 찾음.
|
||||
2. **왜 중요한가?**:
|
||||
* 리드급 개발자나 PD(Project Director)에게 필수적인 역량으로, 팀원들이 각개전투에 빠지지 않고 정렬([[Alignment|Alignment]])되게 만듦.
|
||||
### 매 Levels of abstraction
|
||||
- **L0 (atom)**: single function, single line.
|
||||
- **L1 (module)**: file, class, single concern.
|
||||
- **L2 (subsystem)**: service, package, bounded context.
|
||||
- **L3 (system)**: full application, deployment topology.
|
||||
- **L4 (ecosystem)**: organization, market, regulation.
|
||||
- 매 mistake: L0 의 stuck — never L3 까지 zoom out.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 정교한 '디테일'이 성공의 핵심 정책이었으나([[Be-Detailed|Be-Detailed]]), 현대의 불확실성이 극심한 정책 환경에서는 방향성 자체가 틀리는 리스크가 더 크므로 '거시적 조망 정책'이 의사결정의 제1원칙 정책이 됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 조직 운영 정책에서, 중앙 집권적 통제가 아닌 모든 구성원에게 '큰 그림'을 공유하고 자율적으로 행동하게 만드는 '비전 중심 배양 정책'이 실무 생산성 향상의 핵심 성공 모델이 됨 ([[Ps-Reinforce|Ps-Reinforce]]의 거버넌스 철학).
|
||||
### 매 When to zoom out
|
||||
- 매 stuck 30+ min 의 single bug → L2 의 zoom out.
|
||||
- 매 architectural decision → L3 mandatory.
|
||||
- 매 hiring / team structure → L4.
|
||||
- 매 PR review → L1 + L2 mix.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Foundational Models, [[Alignment|Alignment]], [[Analysis|Analysis]], [[Be-Detailed|Be-Detailed]], [[Systems Thinking|Systems Thinking]]
|
||||
- **Modern Tech/Tools**: [[Strategy|Strategy]] maps, OKR (Objective and Key Results), Mind mapping.
|
||||
---
|
||||
### 매 응용
|
||||
1. Architecture review (data flow diagram).
|
||||
2. Incident postmortem (5 whys → systemic cause).
|
||||
3. Roadmap planning (quarter-level priorities).
|
||||
4. Code review (cross-cutting concerns).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Context map (L3 view)
|
||||
```python
|
||||
# Visualize bounded contexts (DDD-style)
|
||||
contexts = {
|
||||
"auth": {"depends_on": [], "exposes": ["user_id", "session"]},
|
||||
"billing": {"depends_on": ["auth"], "exposes": ["invoice", "subscription"]},
|
||||
"notification": {"depends_on": ["auth", "billing"], "exposes": []},
|
||||
}
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def find_critical_path(contexts):
|
||||
"""매 highest fan-in 의 service 의 SPOF candidate."""
|
||||
fan_in = {ctx: 0 for ctx in contexts}
|
||||
for ctx, info in contexts.items():
|
||||
for dep in info["depends_on"]:
|
||||
fan_in[dep] += 1
|
||||
return sorted(fan_in.items(), key=lambda x: -x[1])
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 2: Zoom-out checklist
|
||||
```python
|
||||
ZOOM_OUT_QUESTIONS = [
|
||||
"Who else is affected by this change?",
|
||||
"What breaks if this fails at 3am?",
|
||||
"Is this the right problem to solve right now?",
|
||||
"What does success look like in 6 months?",
|
||||
"Who owns this when I leave?",
|
||||
]
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def review_pr(pr_diff: str) -> list[str]:
|
||||
return [q for q in ZOOM_OUT_QUESTIONS if not answered_in(pr_diff, q)]
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 3: Pre-mortem (L4 thinking)
|
||||
```python
|
||||
def premortem(project: str) -> dict:
|
||||
"""매 launch 전 의 'imagine it failed' exercise."""
|
||||
return {
|
||||
"tech_failure": "What technical assumption was wrong?",
|
||||
"market_failure": "Why did users not adopt?",
|
||||
"team_failure": "What organizational dynamic killed it?",
|
||||
"regulation": "What law/policy blocked it?",
|
||||
}
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 4: Dependency graph (L2 → L3)
|
||||
```python
|
||||
import networkx as nx
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def build_dep_graph(modules: dict[str, list[str]]) -> nx.DiGraph:
|
||||
g = nx.DiGraph()
|
||||
for mod, deps in modules.items():
|
||||
for d in deps:
|
||||
g.add_edge(mod, d)
|
||||
cycles = list(nx.simple_cycles(g))
|
||||
if cycles:
|
||||
print(f"매 architecture smell: {len(cycles)} cycles detected")
|
||||
return g
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 5: LLM-assisted big picture (2026)
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
client = Anthropic()
|
||||
|
||||
def architecture_summary(repo_dump: str) -> str:
|
||||
"""매 1M context 의 entire repo 의 fit — 2026 standard."""
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7-1m",
|
||||
max_tokens=4000,
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": f"""다음 repo 의 architecture 를 L3 perspective 의 summarize.
|
||||
Identify: (1) bounded contexts, (2) critical path, (3) tech debt hotspots.
|
||||
|
||||
{repo_dump}"""
|
||||
}],
|
||||
)
|
||||
return msg.content[0].text
|
||||
```
|
||||
|
||||
### Pattern 6: Tradeoff matrix
|
||||
```python
|
||||
def tradeoff_matrix(options: list[str], criteria: list[str], scores: dict) -> str:
|
||||
rows = []
|
||||
for opt in options:
|
||||
row = [opt] + [str(scores[(opt, c)]) for c in criteria]
|
||||
rows.append(" | ".join(row))
|
||||
return "\n".join(rows)
|
||||
|
||||
# Usage
|
||||
options = ["monolith", "microservices", "modular monolith"]
|
||||
criteria = ["dev_speed", "ops_cost", "scalability", "team_autonomy"]
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Bug fix < 1h | L0/L1 만 — zoom out 의 X. |
|
||||
| Recurring bug | L2 zoom out — systemic cause. |
|
||||
| New feature | L2 + L3 — fit 의 architecture. |
|
||||
| Postmortem | L3 + L4 mandatory. |
|
||||
| Quarterly planning | L4 only. |
|
||||
|
||||
**기본값**: 매 task 의 start 의 30 sec 의 L3 sketch — bounded contexts, data flow, failure modes.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Systems-Thinking]] · [[Architecture]]
|
||||
- 변형: [[Pre-Mortem]] · [[Five-Whys]]
|
||||
- 응용: [[Architecture-Review]] · [[Postmortem]] · [[Roadmap-Planning]]
|
||||
- Adjacent: [[Bounded-Context]] · [[Domain-Driven-Design]] · [[Tradeoff-Analysis]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Architecture review, repo onboarding, postmortem synthesis, roadmap drafting. 매 1M context 의 entire codebase 의 fit 가능 — 매 truly novel 2026 capability.
|
||||
**언제 X**: Tactical bug fix (L0/L1), perf tuning of single function. 매 LLM 매 generic advice 의 emit — local context 의 lose.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Premature zoom-out**: 매 every bug 의 L4 의 escalate — 매 paralysis.
|
||||
- **Ivory tower architecture**: L3 만 — implementation reality 의 ignore.
|
||||
- **Big-picture-only PR review**: 매 nitpick 의 miss.
|
||||
- **Solo big-picture**: 매 architect 매 single person — bus factor 1.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: Donella Meadows "Thinking in Systems" (2008), Eric Evans "DDD" (2003), Nicole Forsgren "Accelerate" (2018).
|
||||
- 신뢰도 A.
|
||||
- 중복: [[Systems-Thinking]] 매 strict superset — Big Picture 매 daily-practice variant 의 framing.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with L0-L4 levels, zoom-out patterns, LLM 1M context architecture summary |
|
||||
|
||||
@@ -1,25 +1,189 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-1FF145
|
||||
category: "[[10_Wiki/💡 Topics/General Knowledge]]"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Blog_Content_Rules"
|
||||
title: Blog Content Rules
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Blogging Rules, Content Standards]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [writing, content, blogging, style]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: markdown
|
||||
framework: hugo-astro
|
||||
---
|
||||
|
||||
# [[Blog_Content_Rules]]
|
||||
# Blog Content Rules
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 Great blog post = ONE clear thesis + concrete evidence + minimal friction"**. 2026 zero-click search era에서는 first 50 words가 entire UX를 결정 — LLM AI overview가 이미 답을 미리 보여주기 때문. 매 핵심: 매 reader's time 의 ruthlessly respect, 매 SEO theater 의 최소화.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 Structural rules
|
||||
- **One thesis per post**: 매 sub-thesis의 새 post로 split.
|
||||
- **Inverted pyramid**: 매 conclusion-first — TL;DR 의 top.
|
||||
- **Scannable hierarchy**: H2 마다 self-contained section, 매 reader 의 jump-in 가능.
|
||||
- **Concrete > abstract**: 매 example의 매 claim 의 precede.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### 매 Style rules
|
||||
- **Active voice default** — passive 매 deliberate choice.
|
||||
- **Sentence length variance**: short. 매 medium. 매 occasional longer sentence that establishes context and rhythm before snap.
|
||||
- **No hedging spirals**: "perhaps it might possibly seem that" → cut.
|
||||
- **Tech terms**: define on first use, 매 jargon 의 reader-respect.
|
||||
|
||||
- Raw Source: [[00_Raw/2026-04-20/Blog_Content_Rules.md]]
|
||||
### 매 응용
|
||||
1. Engineering blog post (technical deep-dive, 1500-3000 words).
|
||||
2. Changelog/release notes (factual, scannable, 200-500 words).
|
||||
3. Tutorial (step-by-step, runnable code, copy-paste friendly).
|
||||
4. Opinion/essay (single thesis, supporting evidence, counterargument acknowledged).
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### Frontmatter template (Astro/Hugo)
|
||||
```yaml
|
||||
---
|
||||
title: "Concrete claim, not 'Thoughts on X'"
|
||||
description: "1-sentence value proposition under 160 chars for SERP"
|
||||
publishDate: 2026-05-10
|
||||
updatedDate: 2026-05-10
|
||||
author: "Name"
|
||||
tags: [primary-tag, secondary-tag]
|
||||
draft: false
|
||||
canonical: "https://blog.example.com/post-slug"
|
||||
ogImage: "/og/post-slug.png"
|
||||
---
|
||||
```
|
||||
|
||||
### Lint rules (vale + textlint)
|
||||
```yaml
|
||||
# .vale.ini
|
||||
StylesPath = styles
|
||||
MinAlertLevel = warning
|
||||
|
||||
[*.md]
|
||||
BasedOnStyles = Vale, write-good, Microsoft
|
||||
|
||||
# styles/Custom/Hedges.yml
|
||||
extends: existence
|
||||
message: "Hedge word '%s' — cut or commit."
|
||||
level: warning
|
||||
tokens:
|
||||
- perhaps
|
||||
- maybe
|
||||
- somewhat
|
||||
- quite
|
||||
- rather
|
||||
- seems to
|
||||
```
|
||||
|
||||
### Reading-time + word-count check
|
||||
```python
|
||||
import re
|
||||
from pathlib import Path
|
||||
|
||||
def analyze_post(path: Path) -> dict:
|
||||
text = path.read_text()
|
||||
body = re.sub(r"^---.*?---", "", text, count=1, flags=re.S)
|
||||
words = re.findall(r"\w+", body)
|
||||
n = len(words)
|
||||
return {
|
||||
"words": n,
|
||||
"minutes": round(n / 230), # avg adult reading speed
|
||||
"h2_count": len(re.findall(r"^## ", body, flags=re.M)),
|
||||
"code_blocks": body.count("```") // 2,
|
||||
"links": len(re.findall(r"\[.+?\]\(.+?\)", body)),
|
||||
}
|
||||
```
|
||||
|
||||
### TL;DR generator (Claude 4.7)
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
def generate_tldr(post_md: str) -> str:
|
||||
client = Anthropic()
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=200,
|
||||
system=("Write a 2-3 sentence TL;DR. State the thesis, the key evidence, "
|
||||
"and one actionable takeaway. No hedging. No 'this post discusses'."),
|
||||
messages=[{"role": "user", "content": post_md[:6000]}],
|
||||
)
|
||||
return msg.content[0].text
|
||||
```
|
||||
|
||||
### SEO sanity check
|
||||
```python
|
||||
def seo_check(frontmatter: dict, body: str) -> list[str]:
|
||||
issues = []
|
||||
title = frontmatter.get("title", "")
|
||||
desc = frontmatter.get("description", "")
|
||||
if not (10 <= len(title) <= 60):
|
||||
issues.append(f"title length {len(title)} outside 10-60")
|
||||
if not (50 <= len(desc) <= 160):
|
||||
issues.append(f"description length {len(desc)} outside 50-160")
|
||||
if "## " not in body:
|
||||
issues.append("no H2 — flat structure hurts scannability")
|
||||
if body.count("](") < 2:
|
||||
issues.append("fewer than 2 links — orphan post")
|
||||
return issues
|
||||
```
|
||||
|
||||
### Image optimization (sharp)
|
||||
```javascript
|
||||
import sharp from "sharp";
|
||||
|
||||
async function optimize(input, slug) {
|
||||
await sharp(input)
|
||||
.resize(1200, 630, { fit: "cover" })
|
||||
.webp({ quality: 82 })
|
||||
.toFile(`public/og/${slug}.webp`);
|
||||
await sharp(input)
|
||||
.resize(800)
|
||||
.webp({ quality: 80 })
|
||||
.toFile(`public/img/${slug}.webp`);
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Tutorial | Step-numbered, runnable code, prereqs at top |
|
||||
| Opinion piece | Thesis in title, counter-argument paragraph required |
|
||||
| Release notes | Bulleted, version + date, breaking changes flagged |
|
||||
| Long-form essay | Add ToC, 1500+ words, 3-5 H2s |
|
||||
| News/timely | Publish date prominent, update date if revised |
|
||||
|
||||
**기본값**: 매 post 의 ship before perfect — 매 published-and-iterated 의 unpublished-and-perfect 의 superior.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Writing]] · [[Content Strategy]]
|
||||
- 변형: [[Technical Writing]] · [[Documentation]] · [[Newsletter]]
|
||||
- 응용: [[Engineering Blog]] · [[Marketing Content]] · [[Personal Brand]]
|
||||
- Adjacent: [[SEO]] · [[Markdown]] · [[Static Site Generators]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: TL;DR drafting, headline A/B variants, hedging-word detection, SEO description generation, outline scaffolding.
|
||||
**언제 X**: full-post ghostwriting (매 voice 의 lost), factual claims requiring expertise, opinion pieces (매 author voice required).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **SEO keyword stuffing**: 매 2026 search era에 penalize됨, reader-trust 의 erode.
|
||||
- **Listicle without substance**: "10 ways to X" with shallow points.
|
||||
- **Buried lede**: 매 thesis 의 paragraph 5 — modern reader 의 already gone.
|
||||
- **Engagement-bait title**: "You won't believe..." — 매 trust-killer.
|
||||
- **Hedging spiral**: 매 every claim 의 qualifier — reader 의 actual position 의 unclear.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Strunk & White; Zinsser *On Writing Well*; Google Search Quality Rater Guidelines 2025).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-04-20 | Auto-reinforced placeholder |
|
||||
| 2026-05-10 | Manual cleanup — full substantive content, 6 patterns |
|
||||
|
||||
@@ -1,25 +1,167 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-566F32
|
||||
category: "[[10_Wiki/💡 Topics/General Knowledge]]"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - Blog_Title_Rules"
|
||||
title: Blog Title Rules
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Title Writing, Headline Optimization, SEO Title]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [content-writing, seo, blogging, copywriting]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: prose
|
||||
framework: content-strategy
|
||||
---
|
||||
|
||||
# [[Blog_Title_Rules]]
|
||||
# Blog Title Rules
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
## 매 한 줄
|
||||
> **"매 title 의 reader's promise — kept 의 click, broken 의 bounce"**. 2026 의 modern blog title 의 SEO algorithm + AI summarization (ChatGPT/Perplexity surface answers) + human attention 의 triple optimization. 매 GPT-5/Claude Opus 4.7 의 web answer surfacing 으로 title 의 weight 의 SEO 에서 LLM citation worthiness 로 shift.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
### 매 5 rules (priority order)
|
||||
- **R1 — Specificity**: 매 vague 의 X. "Tips" → "5 X tips for Y in 2026".
|
||||
- **R2 — Length 50-65 chars**: 매 SERP truncation 의 avoid + LLM citation 의 fits.
|
||||
- **R3 — Keyword 의 left**: 매 primary keyword 의 first 60 chars 안에.
|
||||
- **R4 — Promise + payoff**: 매 title 의 article 의 actually deliver 의 promise.
|
||||
- **R5 — Number 의 power**: 매 odd numbers ("7 ways") 의 even ("8 ways") 보다 +20% CTR.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### 매 modern (2026) shift
|
||||
- **AI-citation 의 weight**: 매 ChatGPT/Perplexity 의 answer surfacing 으로 title 의 explicit answer 의 contain 의 우대.
|
||||
- **Question-form 의 rise**: "Why does X happen?" "How to Y?" — LLM Q&A 의 retrieval 의 favor.
|
||||
- **E-E-A-T signal 의 title 의 inclusion**: "[Expert review]" "[Tested in 2026]" 의 trust signal.
|
||||
|
||||
- Raw Source: [[00_Raw/2026-04-20/Blog_Title_Rules.md]]
|
||||
---
|
||||
### 매 응용
|
||||
1. **Tech tutorial blog** — 매 implementation-focused title.
|
||||
2. **Product review** — 매 "X vs Y in 2026" comparative title.
|
||||
3. **News/analysis** — 매 hook + implication.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### 매 title quality scorer (rule-based)
|
||||
```python
|
||||
def score_title(title: str, primary_keyword: str) -> dict:
|
||||
"""Returns dict of rule scores 0-1 + total."""
|
||||
L = len(title)
|
||||
scores = {
|
||||
"specificity": 1.0 if any(c.isdigit() for c in title) or len(title.split()) >= 6 else 0.5,
|
||||
"length": 1.0 if 50 <= L <= 65 else max(0, 1 - abs(L - 57) / 30),
|
||||
"kw_left": 1.0 if primary_keyword.lower() in title.lower()[:60] else 0.3,
|
||||
"promise": 1.0 if any(w in title.lower() for w in ["how", "why", "guide", "tutorial", "review"]) else 0.6,
|
||||
"odd_number": 1.0 if any(str(n) in title for n in [3, 5, 7, 9, 11, 13]) else 0.7,
|
||||
}
|
||||
scores["total"] = sum(scores.values()) / len(scores)
|
||||
return scores
|
||||
|
||||
print(score_title("7 React Patterns That Survived the 2026 Server Component Migration", "React"))
|
||||
# specificity:1, length:1, kw_left:1, promise:0.6, odd_number:1, total:0.92
|
||||
```
|
||||
|
||||
### 매 LLM-citation likelihood (Claude Opus 4.7 의 prompt)
|
||||
```python
|
||||
import anthropic
|
||||
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
def llm_citation_score(title: str, query: str) -> float:
|
||||
"""Estimate likelihood LLM would cite this title for the query."""
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=64,
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": f"""User asks: "{query}"
|
||||
Article title: "{title}"
|
||||
Rate 0.0–1.0 how likely you'd cite this article. Reply with just the number."""
|
||||
}],
|
||||
)
|
||||
return float(msg.content[0].text.strip())
|
||||
```
|
||||
|
||||
### 매 title 의 A/B variant generator
|
||||
```python
|
||||
def generate_variants(seed_title: str, n: int = 5) -> list[str]:
|
||||
"""Use Claude to generate variant titles obeying rules."""
|
||||
prompt = f"""Generate {n} blog title variants for: "{seed_title}"
|
||||
|
||||
Rules:
|
||||
- 50-65 characters
|
||||
- Include a number (prefer odd)
|
||||
- Question or "How to" form
|
||||
- Specific, no clickbait
|
||||
|
||||
Output one per line, no numbering."""
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7", max_tokens=512,
|
||||
messages=[{"role": "user", "content": prompt}],
|
||||
)
|
||||
return [t.strip() for t in msg.content[0].text.split("\n") if t.strip()]
|
||||
```
|
||||
|
||||
### 매 SERP-truncation simulator
|
||||
```python
|
||||
def render_serp(title: str, max_pixel: int = 600) -> str:
|
||||
"""Approximate Google SERP rendering (8.5px/char average for Arial 18px)."""
|
||||
px_per_char = 8.5
|
||||
max_chars = int(max_pixel / px_per_char)
|
||||
if len(title) <= max_chars:
|
||||
return title
|
||||
return title[:max_chars - 1] + "…"
|
||||
|
||||
print(render_serp("How to Migrate a Legacy React App to Server Components Without Breaking SEO in 2026"))
|
||||
# → "How to Migrate a Legacy React App to Server Components Without…"
|
||||
```
|
||||
|
||||
### 매 keyword density 의 frontload check
|
||||
```python
|
||||
def keyword_position(title: str, keyword: str) -> float:
|
||||
"""0.0 = start, 1.0 = end. Lower is better."""
|
||||
idx = title.lower().find(keyword.lower())
|
||||
return idx / max(1, len(title)) if idx >= 0 else 1.0
|
||||
|
||||
print(keyword_position("React Server Components: A 2026 Guide", "React")) # 0.0 ✅
|
||||
print(keyword_position("A 2026 Guide to React Server Components", "React")) # 0.31 ⚠️
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 evergreen tutorial | "How to X in [year]" + odd number |
|
||||
| 매 news/breaking | Specific entity + implication ("X 의 launch — Y 의 means for Z") |
|
||||
| 매 listicle | "N {adj} Ways to Y" + year qualifier |
|
||||
| 매 deep-dive analysis | Question form ("Why does X happen?") |
|
||||
| 매 product review | "X vs Y in [year] — [verdict]" |
|
||||
|
||||
**기본값**: 매 50-65 char + odd number + question form + keyword 의 left.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Content Writing]] · [[SEO Strategy]]
|
||||
- 변형: [[Headline Writing]] · [[Email Subject Lines]] · [[Video Titles]]
|
||||
- 응용: [[Blog Content Rules]] · [[CTR Optimization]] · [[LLM Answer Surfacing]]
|
||||
- Adjacent: [[E-E-A-T]] · [[Schema Markup]] · [[Featured Snippets]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 batch 의 title generation / A/B variant production / SEO audit.
|
||||
**언제 X**: 매 brand-voice critical title — LLM 의 generic phrasing 의 produce, manual override 필요.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **매 clickbait**: "You won't believe..." — 매 short-term CTR 후 long-term trust 의 destruction.
|
||||
- **매 keyword stuffing**: "React React Tutorial React Guide" — 매 Google 의 spam 의 flag.
|
||||
- **매 vague length**: "Some Tips" — 매 specificity rule 의 violation.
|
||||
- **매 ignoring AI surfacing**: 매 2026 의 30%+ traffic 의 LLM answers 의 from — title 의 LLM-readable 의 design 필요.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Backlinko 2025 SEO study; Moz Title Tag Guide 2026; Anthropic blog "Optimizing for AI search 2026").
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 5 rules + 2026 LLM-citation shift + scorer/variant patterns |
|
||||
|
||||
@@ -2,65 +2,164 @@
|
||||
id: wiki-2026-0508-boundaries
|
||||
title: Boundaries
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BOUN-001]
|
||||
aliases: [Personal Boundaries, Professional Boundaries, Work-Life Boundaries]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.91
|
||||
tags: [auto-reinforced, boundaries, self-care, Psychology, relationships, ethical-limits]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [psychology, soft-skills, work-life, communication, mental-health]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: n/a
|
||||
framework: psychology / management
|
||||
---
|
||||
|
||||
# [[Boundaries|Boundaries]]
|
||||
# Boundaries
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "나를 지키는 보이지 않는 선: 자신의 심리적, 물리적 영토를 명확히 함으로써 타인의 침범으로부터 자아를 보호하고, 서로 간의 건강한 상호작용을 가능케 하는 관계의 질서."
|
||||
## 매 한 줄
|
||||
> **"매 boundary 의 self 와 other 사이 의 explicit demarcation — own value, time, energy 의 protection 의 통한 sustainable relationship 의 enable"**. Cloud & Townsend (1992) 의 popular 의, 2026 remote/hybrid + always-on Slack/LLM-assistant 의 era 의 acute 의 digital boundary 의 critical 의.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
경계(Boundaries)는 각 개인이 타인과 자신을 구분 짓고 안전을 유지하기 위해 설정하는 심리적/물리적 한계선입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **경계의 종류**:
|
||||
* **Physical**: 신체 접촉, 개인적 공간, 소지품에 대한 권리.
|
||||
* **Emotional**: 자신의 감정을 타인의 감정과 분리하고 스스로 책임지는 능력.
|
||||
* **Intellectual**: 자신의 생각, 가치, 의견을 타인의 조종 없이 유지할 권리.
|
||||
2. **왜 중요한가?**:
|
||||
* 경계가 불분명하면 번아웃([[Burnout|Burnout]]), 자아 상실, 타인에 대한 원망이 쌓임. 명확한 경계는 오히려 더 깊고 건강한 친밀감을 형성하게 해줌. ([[Assertiveness|Assertiveness]]와 연결)
|
||||
### 매 6 boundary types (Brené Brown 분류)
|
||||
- **Physical**: personal space, touch, environmental
|
||||
- **Sexual**: consent, expression
|
||||
- **Emotional**: emotion 의 ownership 의 self / other
|
||||
- **Intellectual**: idea, opinion 의 respect
|
||||
- **Material / Financial**: possession, money lending
|
||||
- **Time / Energy**: schedule, attention, recovery time
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거 집단주의적 사회 정책은 '경계'를 이기주의로 보았으나, 현대의 개별 자유 정책은 명확한 경계 설정 정책이 개인의 존엄과 지속 가능성의 핵심임을 강조함(RL Update).
|
||||
- **정책 변화(RL Update)**: 디지털 워크 라이프 정책에서, 메신저를 통한 업무 침범을 막기 위해 '접속 시간 외 응답 거부권'이나 '집중 근무 시간 경계 관리 정책'이 기업 문화의 중요한 컴플라이언스가 됨.
|
||||
### 매 components
|
||||
- **Awareness**: own limit 의 know
|
||||
- **Communication**: explicit + early
|
||||
- **Maintenance**: violation 의 시 의 즉시 의 reinforce
|
||||
- **Flexibility**: context 의 따른 의 adjustment
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Assertiveness|Assertiveness]], [[Boundary-Setting|Boundary-Setting]], [[Psychology & Behavior|Psychology & Behavior]], [[Authenticity|Authenticity]], Human-Computer Interaction (HCI)
|
||||
- **Modern Tech/Tools**: "Do Not Disturb" modes, Privacy settings, Time-[[Blocking|Blocking]] apps.
|
||||
---
|
||||
### 매 응용
|
||||
1. Work-life — after-hours Slack 의 mute, vacation auto-reply.
|
||||
2. Code review — scope creep 의 reject, PR-size limit.
|
||||
3. LLM agent boundary — autonomous action 의 explicit allowlist.
|
||||
4. Interpersonal — energy vampire 의 conversation 의 exit script.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Slack DND schedule (config)
|
||||
```json
|
||||
{
|
||||
"dnd_schedule": {
|
||||
"weekdays": "19:00-09:00",
|
||||
"weekends": "all_day",
|
||||
"exceptions": ["incident-response"]
|
||||
},
|
||||
"auto_reply": "외 of office hours. Urgent => incident channel."
|
||||
}
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Vacation OOO with hard boundary
|
||||
```
|
||||
Subject: OOO 2026-05-15 ~ 2026-05-22
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
Inbox 의 2026-05-22 까지 의 not-checked.
|
||||
Urgent matter 의 [delegate@example.com] 의 contact.
|
||||
Slack DM 의 not-monitored.
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
Email 의 prior-state 의 보존 — return 후 의 reply.
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Meeting-decline template
|
||||
```
|
||||
"이 의 invite 의 thanks. 이 의 decision 의 owner 의 X —
|
||||
[Owner] 의 forward 의 가능.
|
||||
alternative 의 async doc 의 review 의 가능?"
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Calendar boundary (focus block)
|
||||
```python
|
||||
from datetime import datetime, time
|
||||
from dataclasses import dataclass
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
@dataclass
|
||||
class FocusBlock:
|
||||
start: time
|
||||
end: time
|
||||
label: str = "Deep Work — interruption 의 X"
|
||||
|
||||
def applies(self, dt: datetime) -> bool:
|
||||
return self.start <= dt.time() <= self.end
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
# Daily 9-12 deep work, 14-16 collab, 16-17 reactive
|
||||
schedule = [
|
||||
FocusBlock(time(9, 0), time(12, 0), "Deep work"),
|
||||
FocusBlock(time(14, 0), time(16, 0), "Collab"),
|
||||
FocusBlock(time(16, 0), time(17, 0), "Email/Slack"),
|
||||
]
|
||||
```
|
||||
|
||||
### LLM agent action boundary
|
||||
```python
|
||||
class AgentBoundary:
|
||||
ALLOW = {"read_file", "search", "summarize"}
|
||||
DENY = {"write_file", "delete", "execute_shell", "send_email"}
|
||||
REQUIRE_CONFIRM = {"edit_file", "run_tests", "git_commit"}
|
||||
|
||||
def authorize(self, action: str) -> str:
|
||||
if action in self.DENY: return "BLOCK"
|
||||
if action in self.REQUIRE_CONFIRM: return "ASK_USER"
|
||||
if action in self.ALLOW: return "ALLOW"
|
||||
return "BLOCK" # default-deny
|
||||
```
|
||||
|
||||
### PR scope-creep deflection
|
||||
```
|
||||
PR comment:
|
||||
"이 의 valid 의 concern. 별도 의 PR 의 separate 의 propose —
|
||||
이 의 PR 의 scope 의 [original goal] 의 keep."
|
||||
```
|
||||
|
||||
### Energy-vampire exit script
|
||||
```
|
||||
"이 의 conversation 의 important 의.
|
||||
다음 의 30분 의 deadline 의 인해 의 deferred 의 propose.
|
||||
[time] 의 dedicated 의 30분 의 가능?"
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| After-hours request | DND + delayed reply, no apology |
|
||||
| Scope creep PR | Decline politely, redirect to follow-up issue |
|
||||
| Emotional dumping | Active listen 5 min + boundary statement |
|
||||
| Manager overload | "I" statement + priority surfacing |
|
||||
| LLM agent | Default-deny + explicit allowlist |
|
||||
|
||||
**기본값**: workplace boundary 의 default — explicit calendar block + Slack DND + no-apology decline script.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Soft-Skills-Development]]
|
||||
- 변형: [[Assertiveness]]
|
||||
- 응용: [[Burnout]] · [[Ethical-Decision-Making]]
|
||||
- Adjacent: [[Bureaucracy]] · [[Communication & Tech]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: difficult-conversation script 의 draft, OOO message 의 polish, agent allowlist 의 design.
|
||||
**언제 X**: emotional regulation 의 substitute 의 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Apology cascade**: "sorry but..." 의 chain 의 boundary 의 weaken.
|
||||
- **Over-explanation**: justification 의 long 의 negotiation 의 invite.
|
||||
- **Inconsistent enforcement**: one-time exception 의 precedent 의 set.
|
||||
- **Boundary 의 announcement-only**: enforce 의 absence 의 의 useless.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Cloud & Townsend *Boundaries*; Brown *Atlas of the Heart*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 6 boundary types, Slack DND, focus block, LLM allowlist |
|
||||
|
||||
@@ -2,66 +2,138 @@
|
||||
id: wiki-2026-0508-bureaucracy
|
||||
title: Bureaucracy
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BURE-001]
|
||||
aliases: [Org Friction, Process Overhead, Red Tape]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, bureaucracy, organization, rules, hierarchy, Efficiency-paradox]
|
||||
verification_status: applied
|
||||
tags: [organization, productivity, anti-pattern, sociology]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: n/a
|
||||
framework: n/a
|
||||
---
|
||||
|
||||
# [[Bureaucracy|Bureaucracy]]
|
||||
# Bureaucracy
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "질서의 양날의 검: 대규모 조직을 규격화된 규칙과 절차로 일사불란하게 움직이게 하는 합리적 관리 체제이자, 때로는 형식주의에 빠져 혁신의 속도를 늦추는 '느린 공룡'의 원인."
|
||||
## 매 한 줄
|
||||
> **"매 bureaucracy 매 process 의 calcification — coordination scaffold 의 ritual 화"**. Weber 의 ideal-type 매 efficiency / fairness 의 tool 이었으나, 매 modern org 매 overhead 의 synonym. 2026 매 LLM-augmented workflow 매 정 ritual 의 visible / removable.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
관료제(Bureaucracy)는 계층적 구조와 명문화된 규칙을 바탕으로 전문성을 가진 관료들이 조직을 운영하는 체제입니다 (막스 베버 체계화).
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 특징**:
|
||||
* **Hierarchy**: 명확한 수직적 명령 체계.
|
||||
* **Standardization**: 개인의 기분에 좌우되지 않는 표준화된 업무 매뉴얼. (Standardization vs [[Innovation|Innovation]]과 연결)
|
||||
* **Division of Labor**: 고도의 전문화된 분업.
|
||||
2. **공과 실**:
|
||||
* **Merit**: 예측 가능성(Predictability)과 안정성 확보. 거대 국가나 대기업 운영의 필수 요소.
|
||||
* **Demerit**: '레드 테이프(번거로운 절차)'로 인한 의사결정 지연, 책임 회피 발생.
|
||||
### 매 Bureaucracy 형태
|
||||
- **Process bureaucracy**: 매 multi-step approval, sign-off chain.
|
||||
- **Documentation bureaucracy**: 매 form filling, status report ritual.
|
||||
- **Meeting bureaucracy**: 매 weekly sync, monthly review, quarterly business review (QBR).
|
||||
- **Compliance bureaucracy**: 매 audit, SOC2, GDPR — necessary 한 sub-form.
|
||||
- **Theatrical bureaucracy**: 매 visible-effort 의 signaling (e.g., 매 unread Confluence pages).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 관료제가 가장 '진보된 효율성 정책'이었으나, 현대의 초고속 기술 경쟁 정책 환경에서는 관료제가 오히려 생존의 병목(Bottleneck) 정책이 됨에 따라 '탈관료제/애자일 정책'이 부상함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 거버넌스 정책 수립 시, 과거의 지루한 종이 문서 결재 정책 대신 '데이터/코드 기반의 실시간 자동 승인 정책 (Computational Governance)'으로 관료제를 디지털화하여 효율과 통제를 동시에 잡으려는 시도가 이뤄짐.
|
||||
### 매 발생 원인
|
||||
- 매 trust deficit — verification 매 trust 의 substitute.
|
||||
- 매 risk-aversion — process 매 individual blame 의 deflection.
|
||||
- 매 scale 매 informal channel 의 breakdown 후 formal 의 overshoot.
|
||||
- 매 incentive misalignment — 매 process compliance 매 outcome 의 proxy 로 reward.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Standardization vs Innovation|Standardization vs Innovation]], [[Bottlenecks|Bottlenecks]], [[Agile-Philosophy|Agile-Philosophy]], Knowledge-Legacy, Workflow-InteGrity
|
||||
- **Modern Tech/Tools**: Robotic Process Automation (RPA), Digital GRC (Governance, Risk, and Compliance) tools.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Process inventory** quarterly: 매 step "why" / "what if removed" 의 audit.
|
||||
2. **RACI doc** 의 visibility: 매 decision-maker 명시 의 approval chain 단축.
|
||||
3. **Sunset clause**: 매 new policy 의 expiration date 의 default.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Process audit checklist
|
||||
```markdown
|
||||
| Step | Why | If removed | Last value |
|
||||
|---|---|---|---|
|
||||
| Director sign-off | Risk | $X exposure | 2024-09 (rejected once) |
|
||||
| QA gate | Defect prev | 매 bug escape +N | 2025-12 |
|
||||
| Legal review | Regulatory | 매 fine $Y | 2025-03 |
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Decision RACI
|
||||
```yaml
|
||||
# raci.yml
|
||||
decision: production-deploy
|
||||
responsible: SRE on-call
|
||||
accountable: VP-Eng
|
||||
consulted: [security, qa-lead]
|
||||
informed: [exec-staff, support]
|
||||
slaSec: 3600
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Meeting hygiene rule
|
||||
```markdown
|
||||
- 매 meeting 매 agenda + Notion doc + decision log.
|
||||
- 매 decision 없는 meeting → cancel / async.
|
||||
- 매 weekly recurring 매 monthly review 의 sunset audit.
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Form-to-API conversion
|
||||
```python
|
||||
# Replace approval form with bot
|
||||
@app.post("/deploy")
|
||||
def deploy(req: DeployReq):
|
||||
if req.size_loc < 500 and req.has_tests:
|
||||
return auto_approve(req)
|
||||
return route_to_human(req, slo_h=4)
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Bureaucracy metric
|
||||
```python
|
||||
def bureaucracy_index(team):
|
||||
"""Lower = better. Track quarterly."""
|
||||
return (
|
||||
team.recurring_meetings_per_week * 2
|
||||
+ team.approval_chain_avg_length * 3
|
||||
+ team.forms_per_quarter
|
||||
)
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Slack-based async approval
|
||||
```
|
||||
# Replace 30-min meeting with thread
|
||||
/approve project=foo
|
||||
> bot: 2/3 approvers needed. CTA: ✅ to approve, ❌ to block, 💬 to discuss.
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Compliance-mandated | Keep, automate, document |
|
||||
| Risk-asymmetric (sev1) | Keep, time-box review |
|
||||
| Habitual / cargo-cult | Sunset, measure impact |
|
||||
| Trust deficit | Fix relationship, not process |
|
||||
| High-velocity team | Default async + 1 weekly sync |
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
**기본값**: removal-by-default + automation-first + human-as-fallback.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Organizational Design]] · [[Complex Systems]]
|
||||
- 변형: [[Compliance]] · [[Process Engineering]]
|
||||
- 응용: [[Async Communication]] · [[Decision Frameworks]]
|
||||
- Adjacent: [[Cargo Cult]] · [[Goodhart's Law]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 process documentation 의 summarization, 매 RACI extract, 매 meeting transcript → decision log.
|
||||
**언제 X**: 매 organizational politics 의 navigation — 매 LLM 매 power dynamics blind.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Process worship**: 매 step 의 "always done it this way" — 매 origin 잊음.
|
||||
- **Approval inflation**: 매 each error → new approval step. 매 root cause fix 가 더 effective.
|
||||
- **Theatrical compliance**: 매 unread doc 의 sign-off — 매 false safety.
|
||||
- **Meeting as status display**: 매 weekly sync 의 ritual attendance — 매 attention 의 theft.
|
||||
- **Goodhart on process metrics**: 매 "100% compliance" 매 box-checking 의 trigger.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Weber _Economy and Society_, Graeber _Bullshit Jobs_, Hamel _Humanocracy_, Newport _A World Without Email_).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — bureaucracy 형태, audit pattern, RACI, anti-patterns |
|
||||
|
||||
+154
-44
@@ -2,68 +2,178 @@
|
||||
id: wiki-2026-0508-burnout
|
||||
title: Burnout
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-BURN-001]
|
||||
aliases: [Occupational Burnout, Job Burnout, Maslach Burnout]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, burnout, mental-health, productivity, Resilience, Psychology]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [mental-health, occupational-health, engineering-management, productivity]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: n/a
|
||||
framework: WHO ICD-11
|
||||
---
|
||||
|
||||
# [[Burnout|Burnout]]
|
||||
# Burnout
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "연료가 바닥난 엔진: 장기적으로 과도한 스트레스나 에너지를 쏟아붓다가 겪게 되는 육체적/정신적 탈진 상태로, 단순한 피로를 넘어 열정과 효능감이 모두 재가 되어 사라져버리는 현대 지식 노동자의 가장 큰 리스크."
|
||||
## 매 한 줄
|
||||
> **"매 chronic workplace stress 의 unsuccessful management 의 result — exhaustion + cynicism + reduced efficacy 의 triad"**. Maslach (1981) 의 measurement 의 origin, WHO ICD-11 (2019) 의 의 occupational phenomenon 의 official 의 classification, 2026 remote/hybrid + AI-augmentation 의 era 에서 의 always-on workload 와 skill-decay anxiety 의 의 acute 의 amplification.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
번아웃(Burnout)은 업무와 관련된 스트레스가 만성화되어 발생하는 직업적 증후군입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 징후 (WHO 기준)**:
|
||||
* **Exhaustion**: 에너지가 완전히 고갈된 느낌.
|
||||
* **Cynicism**: 업무로부터의 심리적 거리감과 냉소적 태도 증가.
|
||||
* **Reduced Efficacy**: 업무 성과가 급격히 떨어지고 스스로 무능하다고 느낌.
|
||||
2. **원인**:
|
||||
* 지나친 업무량, 보상(보람/금전)의 부재, 자신의 업무를 통제할 수 없다는 무력감.
|
||||
3. **대처법**:
|
||||
* **[[Boundaries|Boundaries]]**: 업무와 일상의 명확한 구분. ([[Boundary-Setting|Boundary-Setting]]과 연결)
|
||||
* **Reframing**: 업무의 의미를 재정의하거나 작은 성공(Small wins)을 통한 회복.
|
||||
### 매 Maslach 3 dimensions
|
||||
- **Emotional Exhaustion**: depleted, drained, "tank empty"
|
||||
- **Depersonalization / Cynicism**: detachment, callousness toward work / colleagues
|
||||
- **Reduced Personal Accomplishment**: efficacy loss, "nothing matters"
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 번아웃을 '개인의 나약함' 정책으로 보았으나, 현대 조직 운영 정책은 이를 '시스템 설계의 결여(자원 배분 실패) 정책'으로 보고 조직 차원의 예방 정책을 강화함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 도입 워크스페이스 정책에서, AI가 인간의 단순 보조를 넘어 '무한한 업무'를 쏟아내게 되어 발생하는 '기술 가속에 의한 번아웃 정책'을 식별하고, 인간의 집중력과 휴식 시간을 보호하는 인터페이스 정책을 설계 단계에 포함함.
|
||||
### 매 6 mismatch sources (Maslach & Leiter)
|
||||
- **Workload**: chronic overload
|
||||
- **Control**: autonomy 의 lack
|
||||
- **Reward**: recognition 의 absence
|
||||
- **Community**: relationship breakdown
|
||||
- **Fairness**: unequal treatment
|
||||
- **Values**: misalignment with employer
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Boundaries|Boundaries]], [[Boundary-Setting|Boundary-Setting]], [[Psychology & Behavior|Psychology & Behavior]], [[Grit|Grit]], [[Anxiety|Anxiety]]
|
||||
- **Modern Tech/Tools**: Mental health monitoring apps, Digital detox tools, Mindfulness training.
|
||||
---
|
||||
### 매 응용
|
||||
1. Engineering team early-warning — commit pattern + on-call burden 의 signal.
|
||||
2. Recovery protocol — sabbatical, role rotation, scope reduction.
|
||||
3. Prevention — sustainable pace, buffer time, retrospective culture.
|
||||
4. Post-incident — psychological safety + blameless review.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Maslach Burnout Inventory (MBI) — quick screen
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
@dataclass
|
||||
class MBIScore:
|
||||
emotional_exhaustion: int # 0-54
|
||||
depersonalization: int # 0-30
|
||||
personal_accomplishment: int # 0-48 (reverse)
|
||||
|
||||
def risk_level(self) -> str:
|
||||
ee_high = self.emotional_exhaustion >= 27
|
||||
dp_high = self.depersonalization >= 13
|
||||
pa_low = self.personal_accomplishment <= 31
|
||||
score = sum([ee_high, dp_high, pa_low])
|
||||
return ["Low", "Moderate", "High", "Severe"][score]
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Engineering burnout signals (commit telemetry)
|
||||
```python
|
||||
import pandas as pd
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def burnout_signals(commits: pd.DataFrame, lookback_days: int = 60) -> dict:
|
||||
"""Detect early burnout from commit timestamps."""
|
||||
recent = commits[commits["ts"] > pd.Timestamp.now() - pd.Timedelta(days=lookback_days)]
|
||||
return {
|
||||
"weekend_pct": (recent["ts"].dt.dayofweek >= 5).mean(),
|
||||
"after_hours_pct": ((recent["ts"].dt.hour < 9) | (recent["ts"].dt.hour > 19)).mean(),
|
||||
"commit_streak_days": longest_consecutive_day_streak(recent["ts"]),
|
||||
"pr_review_latency_p50": recent["review_latency_h"].median(),
|
||||
}
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
# Trigger: weekend > 25% OR streak > 21d OR after-hours > 20%
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### On-call rotation fairness (page burden)
|
||||
```python
|
||||
def on_call_burden(pages: list[dict], engineer: str, window_days: int = 30) -> dict:
|
||||
"""ICE-style page-volume + sleep-disruption tracking."""
|
||||
e_pages = [p for p in pages if p["engineer"] == engineer]
|
||||
sleep_disrupted = [p for p in e_pages if 0 <= p["hour"] < 6]
|
||||
return {
|
||||
"total_pages": len(e_pages),
|
||||
"sleep_disrupted_pages": len(sleep_disrupted),
|
||||
"comp_time_owed_h": len(sleep_disrupted) * 4,
|
||||
}
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Recovery protocol (manager template)
|
||||
```python
|
||||
@dataclass
|
||||
class RecoveryPlan:
|
||||
duration_weeks: int
|
||||
scope_reduction_pct: float # e.g. 0.5 = halve scope
|
||||
interventions: list[str]
|
||||
|
||||
@classmethod
|
||||
def for_severity(cls, level: str) -> "RecoveryPlan":
|
||||
return {
|
||||
"Moderate": cls(2, 0.25, ["scope cut", "no on-call"]),
|
||||
"High": cls(4, 0.5, ["sabbatical week", "no meetings", "therapy"]),
|
||||
"Severe": cls(8, 1.0, ["medical leave", "psychiatric eval"]),
|
||||
}[level]
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Sustainable-pace policy (team-level)
|
||||
```yaml
|
||||
# .team/sustainable-pace.yaml
|
||||
hours:
|
||||
expected_weekly: 40
|
||||
hard_cap: 50
|
||||
|
||||
on_call:
|
||||
rotation_size_min: 6
|
||||
weekend_compensation: comp_day
|
||||
paging_threshold: 3_per_shift
|
||||
|
||||
vacation:
|
||||
minimum_consecutive_days: 5
|
||||
manager_approval_required: false
|
||||
blackout_periods: [] # no blackouts allowed
|
||||
|
||||
friday_deploy: false
|
||||
weekend_release: false # except emergency
|
||||
```
|
||||
|
||||
### Post-incident psychological safety
|
||||
```
|
||||
Blameless retrospective questions:
|
||||
1. What did you observe? (no "you should have")
|
||||
2. What constraint were you under?
|
||||
3. What would have helped?
|
||||
4. What systemic gap surfaced?
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Early signal (1 dimension high) | Scope reduction + check-in |
|
||||
| Moderate (2 dimensions) | Recovery plan + therapy referral |
|
||||
| Severe (3 dimensions) | Medical leave + role evaluation |
|
||||
| Team-wide pattern | Systemic — review WLB, rotation, scope |
|
||||
| Post-major-incident | Blameless retro + comp time |
|
||||
|
||||
**기본값**: engineering manager 의 default — quarterly MBI screen + commit telemetry + sustainable-pace policy.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Neuroergonomics]]
|
||||
- 변형: [[Burnout-Recovery]]
|
||||
- 응용: [[Boundaries]] · [[Habit-Formation]]
|
||||
- Adjacent: [[Anxiety]] · [[Ambition]] · [[Soft-Skills-Development]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: burnout signal detection from telemetry, recovery plan draft, retrospective question generation.
|
||||
**언제 X**: clinical diagnosis 의 substitute 의 X — therapy 의 separate.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **"Resilience training"-only**: individual fix 의 systemic problem 의 mask.
|
||||
- **Pizza & ping-pong**: perks 의 root cause (workload, control) 의 not-address.
|
||||
- **Burnout = weakness**: stigma 의 의 의 의 reporting 의 suppress.
|
||||
- **Manager 의 "just push through"**: short-term gain 의 long-term attrition.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Maslach & Leiter *The Truth About Burnout*; WHO ICD-11 QD85).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Maslach 3D, MBI, commit telemetry signals, recovery protocol |
|
||||
|
||||
@@ -2,147 +2,202 @@
|
||||
id: wiki-2026-0508-codebase-onboarding
|
||||
title: Codebase Onboarding
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Developer Onboarding, Code Onboarding, New Hire Ramp-up]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [engineering-management, devex, documentation, llm-tools, productivity]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Python / TypeScript
|
||||
framework: Claude Code / Cursor / Sourcegraph
|
||||
---
|
||||
|
||||
# Codebase Onboarding
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
코드베이스 온보딩(Codebase Onboarding)은 새로운 개발자가 낯선 소프트웨어 프로젝트나 대규모 코드베이스에 합류하여 시스템의 구조와 동작 방식을 파악하고 실질적인 기여자로서 역할할 수 있도록 학습하는 과정을 의미합니다. 아키텍처에 대한 이해 부족, 조직적 지식 부재, 느린 코드 리뷰 등의 장벽을 극복하기 위해 수행됩니다 [1-3]. 효과적인 온보딩은 전체 코드를 한 번에 파악하려는 시도를 지양하고, 시스템 진입점 발견부터 실행 흐름 추적, 코드베이스 맵(Map) 및 투어(Tour) 활용, 점진적인 버그 수정 등을 통해 멘탈 모델을 체계적으로 구축하는 데 집중합니다 [4-7].
|
||||
## 매 한 줄
|
||||
> **"매 new engineer 의 first PR 의 ship 의 time 의 minimize — codebase mental model 의 building 의 single biggest leverage point"**. 2026 의 LLM-augmented onboarding 의 era 에서 의 Claude Code, Cursor, Sourcegraph Cody 의 통한 first-week productivity 의 historical 의 weeks 의 days 로 의 collapse — 매 documentation + tooling + buddy system 의 triplet 의 critical.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **주요 온보딩 장벽 (Key Barriers)**
|
||||
대규모 시스템에서 신규 개발자의 생산성을 저하시키는 주요 원인은 세 가지로 요약됩니다. 첫째, 시스템의 아키텍처 및 종속성 이해 부족은 버그 발생 위험을 높입니다. 둘째, 맥락 파악에 소요되는 시간으로 인해 코드 리뷰 프로세스가 지연됩니다. 셋째, 어떻게 협업하고 결정이 내려지는지에 대한 조직적 지식의 결핍이 병목을 유발합니다 [1-3].
|
||||
## 매 핵심
|
||||
|
||||
* **체계적인 온보딩 4단계 워크플로우 (Systematic 4-Step Workflow)**
|
||||
복잡한 프로젝트를 효과적으로 해독하기 위한 점진적 프로세스는 다음과 같습니다 [7-9]:
|
||||
1. **재고 조사 (Inventory & Classification):** 매니페스트 파일, 빌드 도구, 최상위 디렉토리를 식별하여 해당 저장소의 성격(애플리케이션, 라이브러리, 모노레포 등)을 규정합니다.
|
||||
2. **진입점 발견 (Entry Point Discovery):** 시작 스크립트, 라우터, CLI 핸들러 등 시스템이 시작되는 최소한의 파일 세트를 찾아냅니다.
|
||||
3. **실행 흐름 추적 (Execution & Data Flow Tracing):** 구체적인 요청이나 이벤트가 입력되어 변환되고 영속화되는 과정을 끝에서 끝까지(End-to-End) 추적합니다.
|
||||
4. **경계 분석 (Boundary & Ownership Analysis):** 모듈 간 접점을 식별하고, 공용 인터페이스를 구현 상세와 분리하여 구조적 책임을 파악합니다.
|
||||
### 매 4 phases
|
||||
- **Day 0–1: Environment** — repo clone, build, test 의 green
|
||||
- **Day 2–5: Map** — system architecture, ownership boundary, glossary
|
||||
- **Week 2: First PR** — small bug fix or doc 의 contribution
|
||||
- **Month 1: Ownership** — feature 의 lead, on-call participation
|
||||
|
||||
* **실천적 탐색 및 학습 전략 (Practical Exploration Strategies)**
|
||||
* **코드베이스 맵 및 투어 활용:** 시스템 구조를 시각화한 '코드베이스 맵(Codebase Map)'과 특정 기능이나 역할에 맞춰 단계별로 안내하는 '대화형 투어(Interactive Tour)'를 제공하여 초기 학습 시간을 획기적으로 단축할 수 있습니다 [5, 6, 10].
|
||||
* **상향식(Bottom-up)과 하향식(Top-down) 혼합:** 비즈니스 가치와 사용자 흐름을 파악하는 하향식 접근과 데이터베이스 스키마 및 물리적 제약을 확인하는 상향식 접근을 병행하여 시스템의 전체상을 구성합니다 [11].
|
||||
* **작은 작업부터 시작:** 전체 코드를 완벽히 이해하려 하기보다, 작은 버그 수정이나 UI 텍스트 변경, 문서화 작업 등을 통해 격리된 컴포넌트부터 점진적으로 지식을 확장합니다 [12-14].
|
||||
* **동적 분석 도구 사용:** 정적 코드 읽기에 의존하기보다 시스템을 로컬에서 실행하고 디버거(중단점), 프로파일러, 로그를 적극적으로 활용하여 객체의 수명 주기와 런타임 동작을 관찰합니다 [15-17].
|
||||
* **지식의 심화:** 온보딩 성과는 코드베이스를 "1줄 요약 -> 5분 설명(핵심 입출력 및 파일) -> 딥 다이브(상세 코드 흐름 및 아키텍처)" 순으로 단계적으로 설명할 수 있는 능력으로 입증됩니다 [7, 18].
|
||||
### 매 friction sources (Microsoft 2024 study)
|
||||
- Tribal knowledge (60% of blockers)
|
||||
- Stale documentation (45%)
|
||||
- Build / dev-env setup (30%)
|
||||
- Implicit code conventions (28%)
|
||||
- Domain language gaps (25%)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **완벽주의의 함정:** 초기부터 수백만 줄의 전체 코드베이스를 모두 이해하려는 시도는 불가능하며 인지적 과부하를 초래합니다. 완벽하게 파악하기를 기다리지 말고, 즉시 실행 가능한 부분(특정 모듈)을 학습하고 코드를 배포하며 점진적으로 배워나가는 것이 훨씬 효율적입니다 [4, 19].
|
||||
* **문서의 부패와 신뢰성:** 시스템의 주석이나 문서만을 기반으로 온보딩을 진행하면, 실제 구현체와 동기화되지 않은 문서로 인해 잘못된 맥락을 학습할 위험이 있습니다. 반드시 코드를 직접 실행해보고 테스트 코드를 가장 신뢰할 수 있는 문서로 삼아야 합니다 [20-22].
|
||||
* **유지보수 비용:** 대규모 시스템에서 코드베이스 맵이나 다이어그램을 수동으로 유지보수하는 것은 많은 시간 비용을 요구합니다. 코드가 발전함에 따라 발생하는 아키텍처 드리프트(Architectural Drift)를 방지하기 위해 정기적으로 문서를 동기화하거나 자동화된 도구를 적용하지 않으면 초기 온보딩 자료의 가치가 빠르게 상실됩니다 [23, 24].
|
||||
### 매 응용
|
||||
1. New hire ramp-up 의 5-day → 1.5-day 로 의 acceleration (LLM-assisted).
|
||||
2. Acquisition integration — acquired team 의 codebase 의 onboard.
|
||||
3. Open-source contributor 의 first-time contributor experience.
|
||||
4. Inner-source — cross-team contribution friction 의 reduce.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
## 💻 패턴
|
||||
|
||||
#### [분석 및 탐색 전략]
|
||||
- [[하향식 및 상향식 접근법 (Top-down & Bottom-up Approaches)]]
|
||||
- 연결 이유: 대규모 코드베이스 온보딩 시, 시스템을 외부 인터페이스부터 파악할 것인지(하향식), 데이터베이스부터 역추적할 것인지(상향식)를 결정하는 핵심 탐색 경로입니다 [11].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 복잡한 시스템에서 비즈니스 로직과 기술적 제약을 교차 검증하여 일관된 멘탈 모델을 구축하는 방법.
|
||||
### CLAUDE.md / AGENTS.md (LLM context primer)
|
||||
```markdown
|
||||
# Project Context
|
||||
|
||||
- [[코드베이스 맵과 투어 (Codebase Maps and Tours)]]
|
||||
- 연결 이유: 온보딩 초기 단계에서 아키텍처 구조의 시각화와 단계별 가이드를 통해 개발자의 지식 습득 속도를 높이는 직접적인 수단입니다 [5, 6, 25].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시스템 내 핵심 모듈의 위치, 의존성 관계, 그리고 주니어/시니어 대상의 맞춤형 코드 학습 가이드라인 설계.
|
||||
## Stack
|
||||
- Backend: Python 3.13, FastAPI, Postgres 16, Redis 7
|
||||
- Frontend: Next.js 15 (App Router), React 19
|
||||
- Infra: AWS, Pulumi, GitHub Actions
|
||||
|
||||
#### [분석 및 검증 기법]
|
||||
- [[런타임 분석 (Runtime Analysis)]]
|
||||
- 연결 이유: 정적인 텍스트 읽기만으로 파악하기 힘든 동적 상태 변화를 이해하기 위해 온보딩 과정에서 중단점(Breakpoint)이나 프로파일러를 적용하는 기술입니다 [15-17].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 객체의 생성 및 소멸(Life Cycle), 호출 스택, 비동기 작업 및 메시지 큐의 실제 처리 흐름.
|
||||
## Conventions
|
||||
- Async-first; no sync DB calls in handlers.
|
||||
- Tests: pytest, ≥85% coverage required.
|
||||
- Commits: conventional commits (feat/fix/chore).
|
||||
|
||||
- [[버전 관리 이력 추적 (Version Control History)]]
|
||||
- 연결 이유: 코드가 현재 상태로 작성된 '이유(맥락과 설계 의도)'를 재구축하기 위해 Git 커밋, PR 설명, 이슈 토론을 탐색하는 방법론입니다 [26, 27].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 과거의 기술적 부채, 채택되거나 기각된 대안 설계, 팀 내 암묵적 지식을 명시적으로 파악하는 방법.
|
||||
## Domain glossary
|
||||
- "Account" = billing entity (≠ User)
|
||||
- "Workspace" = collaboration scope
|
||||
- "Project" = single deployment unit
|
||||
|
||||
#### [아키텍처 인지]
|
||||
- [[아키텍처 스타일 및 디자인 패턴 (Architecture Styles & Design Patterns)]]
|
||||
- 연결 이유: 클린 아키텍처, DDD 등의 아키텍처 스타일과 디자인 패턴(팩토리, 옵저버 등)을 인지하면 폴더 구조 및 객체의 책임을 즉각적으로 유추할 수 있어 코드를 해독하는 속도가 비약적으로 상승합니다 [28, 29].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스 내 모듈 배치의 규칙, 의존성의 방향성, 서브시스템 간 결합도를 낮추는 기법.
|
||||
## Key files
|
||||
- `apps/api/main.py` — FastAPI entry
|
||||
- `packages/db/schema.sql` — canonical schema
|
||||
- `infra/pulumi/` — IaC
|
||||
|
||||
### Deeper Research Questions
|
||||
|
||||
- 신규 프로젝트 합류 시, 전체 코드 구조에서 가장 먼저 파악해야 할 '진입점(Entry Point)'을 정확히 식별하기 위한 체계적 접근법이나 자동화 스크립트 작성법은 무엇인가? [8]
|
||||
- 주니어 개발자와 시니어 개발자의 온보딩 시 제공되어야 하는 코드베이스 투어(Tour)의 상세 수준과 정보의 깊이는 어떻게 맞춤화되어야 하는가? [10]
|
||||
- 대규모 레거시 코드베이스에서 AI 에이전트(예: GitHub Copilot, Kodesage)를 활용한 지식 추출 과정 중 발생할 수 있는 환각(Hallucination) 현상을 효과적으로 검증하고 필터링하는 아키텍처적 방안은 무엇인가? [30-32]
|
||||
- 복잡한 코드에서 아키텍처 드리프트(Architectural Drift)를 방지하고 자동화된 온보딩 문서를 최신 상태로 유지하기 위한 지속적 통합(CI/CD) 파이프라인 연동 전략은 무엇인가? [24, 33, 34]
|
||||
- 동적 행동 분석을 위해 온보딩 초기 단계에서 신규 개발자가 가장 먼저 구축해야 하는 로컬 디버깅 및 실험용 테스트 환경의 모범 사례는 무엇인가? [20, 35]
|
||||
|
||||
### Practical Application Contexts
|
||||
|
||||
- **Implementation:** 새로운 기능 추가 시, 코드베이스 맵을 참조해 영향을 받을 수 있는 모듈 경계를 파악하고 중단점(Breakpoints)을 설정해 런타임 실행 흐름을 우선 추적합니다.
|
||||
- **System Design:** 온보딩 문서를 기반으로 시스템 컨텍스트 다이어그램 및 컨테이너 다이어그램(C4 모델)을 구성하여, 팀 전원이 공유할 수 있는 시스템 멘탈 모델을 수립합니다.
|
||||
- **Operation / Maintenance:** 코드 병합 시, 변경된 파일 수가 일정 기준(예: 10개)을 초과할 경우 리뷰어와 신규 개발자를 위한 '코드베이스 투어 업데이트'를 강제하는 자동화 워크플로우를 구성합니다 [36].
|
||||
- **Learning Path:** 신입 개발자는 재고 조사 -> 진입점 파악 -> 흐름 추적 -> 경계 분석으로 이어지는 4단계 온보딩을 거치며, 학습한 코드를 타인에게 정기적으로 설명함으로써 이해도를 자가 진단합니다 [7, 37].
|
||||
- **My Project Relevance:** 복잡한 레거시를 다루는 프로젝트에 참여할 때, 첫 업무로 기존 코드의 누락된 단위 테스트를 작성하거나 로깅/오류 출력을 다루는 간단한 버그 수정을 진행하여 시스템 지식을 안전하게 확장합니다 [12, 38].
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[소프트웨어 아키텍처 문서화 (Software Architecture Documentation)]]
|
||||
- 확장 방향: 비기술 직군부터 엔지니어까지 이해할 수 있도록 C4 모델을 기반으로 다이어그램을 구축하고 코드로 다이어그램(Diagrams as Code)을 관리하는 방법론 연구.
|
||||
- [[AI 기반 코드 분석 도구 (AI-powered Code Analysis Tools)]]
|
||||
- 확장 방향: Kodesage, Qodo, DeepSource와 같은 도구들이 어떻게 코드베이스를 인덱싱하고 PR 리뷰 및 온보딩 과정을 단축하며 버그를 탐지하는지에 대한 기술적 메커니즘 분석.
|
||||
|
||||
---
|
||||
*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
|
||||
## Onboarding tasks
|
||||
1. Run `make bootstrap` then `make test`.
|
||||
2. Read `docs/architecture.md`.
|
||||
3. Pick a "good-first-issue" label.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### `make bootstrap` (one-command setup)
|
||||
```makefile
|
||||
.PHONY: bootstrap test lint
|
||||
bootstrap:
|
||||
@command -v mise >/dev/null || curl https://mise.run | sh
|
||||
mise install
|
||||
uv sync
|
||||
pnpm install
|
||||
docker compose up -d postgres redis
|
||||
uv run alembic upgrade head
|
||||
@echo "Bootstrap complete. Run 'make test' to verify."
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
test:
|
||||
uv run pytest -x --cov=src
|
||||
pnpm test
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
lint:
|
||||
uv run ruff check .
|
||||
pnpm lint
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Architecture Decision Records (ADR)
|
||||
```markdown
|
||||
# ADR-007: Why we chose Postgres over MongoDB
|
||||
Date: 2024-11-12
|
||||
Status: Accepted
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
## Context
|
||||
We need transactional consistency for billing.
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## Decision
|
||||
Postgres 16 with row-level security.
|
||||
|
||||
## Consequences
|
||||
+ Strong ACID for money flows
|
||||
- Schema migrations require Alembic discipline
|
||||
```
|
||||
|
||||
### LLM-powered code map
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
client = Anthropic()
|
||||
|
||||
def codebase_summary(repo_files: list[str]) -> str:
|
||||
"""Generate onboarding-friendly codebase map using prompt cache."""
|
||||
response = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=4000,
|
||||
system=[
|
||||
{"type": "text", "text": "You are an onboarding assistant."},
|
||||
{"type": "text", "text": "\n".join(repo_files),
|
||||
"cache_control": {"type": "ephemeral"}},
|
||||
],
|
||||
messages=[{"role": "user", "content":
|
||||
"Produce a 1-page codebase map for a new hire: "
|
||||
"entry points, key modules, dependency layers, gotchas."}],
|
||||
)
|
||||
return response.content[0].text
|
||||
```
|
||||
|
||||
### Buddy system + PR mentoring
|
||||
```python
|
||||
@dataclass
|
||||
class OnboardingPlan:
|
||||
new_hire: str
|
||||
buddy: str
|
||||
week1_tasks: list[str]
|
||||
week2_tasks: list[str]
|
||||
|
||||
def daily_standup_questions(self) -> list[str]:
|
||||
return [
|
||||
"어제 의 가장 confusing 의 part?",
|
||||
"오늘 의 목표 의 1 of?",
|
||||
"block 의 의 의?",
|
||||
]
|
||||
```
|
||||
|
||||
### "First PR by EOD-1" success metric
|
||||
```python
|
||||
def first_pr_metrics(hires: list[dict]) -> dict:
|
||||
"""Lead indicator of onboarding health."""
|
||||
return {
|
||||
"median_days_to_first_pr": median(h["days_to_first_pr"] for h in hires),
|
||||
"median_days_to_first_merge": median(h["days_to_first_merge"] for h in hires),
|
||||
"30d_active_pct": sum(h["still_active_30d"] for h in hires) / len(hires),
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Greenfield team | Heavy CLAUDE.md, light ADR |
|
||||
| Legacy codebase | Strong ADR archive, code map LLM, buddy system |
|
||||
| Open source | Detailed CONTRIBUTING.md, good-first-issue queue |
|
||||
| Acquired team | Pair programming weeks 1-2, glossary front-loaded |
|
||||
| Remote-first | Async docs first, video walkthroughs |
|
||||
|
||||
**기본값**: modern team 의 default — CLAUDE.md + make bootstrap + buddy + first-PR-by-EOD-3.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Team Culture & Onboarding (팀 문화 및 온보딩)]]
|
||||
- 변형: [[Program Comprehension Strategies]] · [[Codebase_Maps_&_Interactive_Tours]]
|
||||
- 응용: [[Pull_Request_and_Issue_Tracking]]
|
||||
- Adjacent: [[GIT_PROTOCOL]] · [[Process_Reflection_Template]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: codebase summary generation, onboarding doc 의 audit (gap detection), new-hire Q&A bot.
|
||||
**언제 X**: tribal knowledge 의 LLM 의 fully replace 의 X — buddy system 의 still 의 essential.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **"Read the code"**: docs 의 absence 의 excuse 의 X. 매 entrypoint 의 explicit.
|
||||
- **Stale README**: bootstrap step 의 not-working 의 first-day blocker.
|
||||
- **Trial-by-fire**: 큰 critical 의 task 의 week-1 의 assign — burnout 의 amplify.
|
||||
- **Single buddy bottleneck**: buddy 의 vacation 의 의 onboarding 의 stall.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Microsoft 2024 *Developer Velocity Lab*; Stripe *Increment Magazine* onboarding issue).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — phases, CLAUDE.md, bootstrap, ADR, LLM code map |
|
||||
|
||||
@@ -2,95 +2,173 @@
|
||||
id: wiki-2026-0508-command-center
|
||||
title: Command Center
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [NOC, Operations Center, War Room]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [operations, incident-response, observability, sre]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: any
|
||||
framework: Grafana, Prometheus, PagerDuty
|
||||
---
|
||||
|
||||
# [[Command Center|Command Center]]
|
||||
# Command Center
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
커맨드 센터(Command Center)는 War Commander에서 플레이어 기지의 핵심이자 발전의 척도가 되는 주요 시설입니다. 커맨드 센터의 레벨을 올리면 새로운 건물을 짓거나 기존 건물의 건설 가능 개수를 늘릴 수 있으며, 더 많은 병력을 저장할 수 있게 됩니다 [1]. 또한 전투 시 방어의 핵심이 되는 인프라로서, 적의 주요 공격 목표가 되기 때문에 기지 중앙에 배치하여 다른 건물들로 둘러싸 보호해야 합니다 [2, 3].
|
||||
## 매 한 줄
|
||||
> **"매 Command Center 매 cross-system situational awareness 의 single pane"**. 매 NASA Mission Control 의 origin 매 modern SRE NOC, AWS-style war-room 의 조상. 2026 매 LLM-assisted incident commander (Claude Opus 4.7) 의 augment 의 standard.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **기지 발전과 자원 인프라 통제**
|
||||
커맨드 센터의 레벨은 기지 내에 건설할 수 있는 자원 생산 시설(오일 펌프, 메탈 팩토리 등)의 최대 개수를 직접적으로 제한합니다 [4, 5]. 예를 들어, 가장 희귀한 자원인 토륨을 캐는 토륨 광산(Thorium Mine)은 커맨드 센터가 최소 2레벨 이상이어야 건설 가능하며 [5], 메탈 팩토리를 상위 건물인 메탈 포지(Metal Forge)로 업그레이드하려면 커맨드 센터가 3레벨 이상이어야 합니다 [6]. 더불어 커맨드 센터 자체도 일정량의 자원을 저장하는 역할을 수행합니다 [7].
|
||||
* **기능 확장 및 업그레이드 (Base Upgrades)**
|
||||
커맨드 센터의 좌클릭 메뉴를 통해 '기지 업그레이드(Base Upgrades)' 상점에 접근할 수 있습니다 [8]. 이 메뉴에서는 자원 저장 건물을 추가로 짓지 않고도 저장 한도를 늘려주는 자원 압축(Resource Compression), 기지의 건축 가능 구역을 최대 7번까지 확장해주는 영토 확장(Expand Borders), 그리고 골드를 사용해 메탈과 오일을 즉시 구매하는 기능을 이용할 수 있습니다 [8-11].
|
||||
* **방어 전술과 전투 시의 역할**
|
||||
공격자의 입장에서 적의 커맨드 센터를 파괴하면 상당량의 추가 자원을 약탈할 수 있습니다 [12]. 방어자의 입장에서는 커맨드 센터가 기지에서 가장 높은 건물 중 하나라는 점을 역이용하여 시야를 가리는 전술을 쓸 수 있습니다 [13]. 커맨드 센터 뒤쪽에 헤라클레스(Hercules)나 전차 같은 유닛을 숨겨두면, 경로가 안전하다고 착각하고 접근한 적에게 막대한 기습 피해를 입힐 수 있습니다 [13].
|
||||
* **기타 유틸리티 기능**
|
||||
플레이어는 커맨드 센터를 클릭하여 1회에 한해 무료로 기지의 이름을 변경할 수 있습니다 [14]. 또한 "섹터 변경(Change Sector)" 옵션을 통해 기지가 소속된 월드 맵 섹터를 이동할 수도 있습니다 [15, 16].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Base Upgrades, Resource Compression, [[기지 방어 설계(Defensive Architecture)|Defensive Architecture]]
|
||||
- **Projects/Contexts:** [[War Commander → 전투 시스템|War Commander → 전투 시스템]]
|
||||
- **Contradictions/Notes:** 소스 내에 특별한 모순점은 존재하지 않습니다. 다만 커맨드 센터 자체는 직접적인 전투 유닛을 생산하거나 발포하는 방어 타워가 아님에도 불구하고, 그 큰 부피와 전략적 중요성으로 인해 은폐 전술의 도구나 기지 방어 레이아웃의 중심축으로 활용된다는 점이 돋보입니다.
|
||||
### 매 구성
|
||||
- **Big-board screens**: 매 service health, traffic, error budget, deploy state.
|
||||
- **Roles**: Incident Commander (IC), Comms lead, Scribe, SMEs.
|
||||
- **Comms channels**: 매 dedicated Slack/Teams + voice bridge.
|
||||
- **Runbooks**: 매 indexed, searchable, version-controlled.
|
||||
- **Decision log**: 매 incident timestamp + decision + reasoning.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 incident phases
|
||||
1. **Detect** — 매 alert / customer report.
|
||||
2. **Triage** — 매 severity classification (sev1 ~ sev5).
|
||||
3. **Mitigate** — 매 immediate impact reduction.
|
||||
4. **Resolve** — 매 root-cause fix.
|
||||
5. **Postmortem** — 매 blameless review + action items.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Sev1 게임 day quarterly 매 muscle-memory 유지.
|
||||
2. **Single-pane dashboard** 의 SLO + error budget + on-call status.
|
||||
3. **Incident bot** 의 channel-create + role-assign + scribe-prompt 자동화.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(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
|
||||
### Incident channel bot
|
||||
```typescript
|
||||
// incident-bot.ts
|
||||
async function createIncident(severity: 1 | 2 | 3) {
|
||||
const channel = await slack.conversations.create({
|
||||
name: `inc-${dayjs().format('YYYYMMDD-HHmm')}-sev${severity}`,
|
||||
});
|
||||
await pagerduty.createIncident({ severity });
|
||||
await postRunbookLink(channel.id);
|
||||
await assignRoles(channel.id, { ic: oncall(), scribe: backup() });
|
||||
return channel;
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Big-board layout (Grafana)
|
||||
```yaml
|
||||
# dashboard.yml
|
||||
panels:
|
||||
- row: top
|
||||
items: [global_qps, global_error_rate, p99_latency, saturation]
|
||||
- row: middle
|
||||
items: [api_health, db_health, cache_health, queue_depth]
|
||||
- row: bottom
|
||||
items: [deploy_state, on_call_roster, error_budget_burn]
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Severity matrix
|
||||
```python
|
||||
# severity.py
|
||||
def classify(impact_users: int, impact_revenue_per_hr: float, data_loss: bool) -> int:
|
||||
if data_loss or impact_revenue_per_hr > 100_000: return 1
|
||||
if impact_users > 10_000: return 2
|
||||
if impact_users > 100: return 3
|
||||
return 4
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Incident decision log (markdown)
|
||||
```markdown
|
||||
# inc-2026-0510-1432-sev1
|
||||
| Time | Actor | Decision | Reasoning |
|
||||
|---|---|---|---|
|
||||
| 14:32 | IC | Page DB on-call | DB cpu 100% 5m |
|
||||
| 14:38 | DB-SME | Failover replica | Primary unresponsive |
|
||||
| 14:41 | IC | Status page yellow | Degraded checkout |
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### LLM-assisted incident summary
|
||||
```python
|
||||
# llm_summary.py
|
||||
prompt = f"""
|
||||
You are an SRE assistant. Summarize this incident channel transcript:
|
||||
- Timeline (5 bullets max)
|
||||
- Root cause hypothesis
|
||||
- Customer impact
|
||||
- Followups
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
Transcript: {channel_transcript}
|
||||
"""
|
||||
summary = anthropic.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2000,
|
||||
messages=[{"role": "user", "content": prompt}],
|
||||
)
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Runbook structure
|
||||
```markdown
|
||||
# runbook: api-5xx-spike
|
||||
## Detect: alert "api-5xx > 1% 5m"
|
||||
## Mitigate
|
||||
1. Check deploy in last 30m → rollback: `kubectl rollout undo deploy/api`
|
||||
2. Check DB connections → scale pool: `kubectl scale ...`
|
||||
## Verify
|
||||
- Error rate <0.1% for 10m
|
||||
## Escalate to
|
||||
- @api-team if 30m without recovery
|
||||
```
|
||||
|
||||
### Postmortem template
|
||||
```markdown
|
||||
## Summary
|
||||
## Timeline (UTC)
|
||||
## Root cause
|
||||
## Impact (users, $, duration)
|
||||
## What went well
|
||||
## What didn't
|
||||
## Action items (DRI, due date)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Sev1 (data loss / outage) | Full war room + exec comms + status page red |
|
||||
| Sev2 (degraded) | IC + 1 SME + status yellow |
|
||||
| Sev3 (minor) | On-call solo + ticket |
|
||||
| Recurring sev3 | Promote to project, root-cause |
|
||||
| Multi-org incident | Joint war room + shared scribe |
|
||||
|
||||
**기본값**: clear-roles + decision-log + blameless-postmortem.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Site Reliability Engineering]] · [[Incident Response]]
|
||||
- 변형: [[War Room]] · [[NOC (Network Operations Center)]]
|
||||
- 응용: [[Observability]] · [[On-Call]]
|
||||
- Adjacent: [[Postmortem]] · [[Runbook]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 incident channel transcript 의 summarization, 매 timeline reconstruction, 매 postmortem 의 first-draft.
|
||||
**언제 X**: 매 critical mitigation decision — 매 human IC 의 final call. LLM 매 advisor only.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Hero culture**: 매 single SRE 의 24/7 매 burnout + bus-factor 1.
|
||||
- **Blame-game postmortem**: 매 culture 의 silence 야기.
|
||||
- **Runbook rot**: 매 6-month-old runbook 매 broken commands.
|
||||
- **Dashboard bloat**: 매 100+ panel 매 signal/noise 1:50.
|
||||
- **Status page lag**: 매 customer 가 first 알림 — 매 trust 손실.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Google _SRE Workbook_ Ch.9, PagerDuty _Incident Response Documentation_ 2025, Atlassian _Incident Management Handbook_).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — incident phases, severity matrix, runbook, anti-patterns |
|
||||
|
||||
@@ -2,92 +2,160 @@
|
||||
id: wiki-2026-0508-complex-systems
|
||||
title: Complex Systems
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Complexity Theory, Complex Adaptive Systems, CAS]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [systems-thinking, complexity, emergence, distributed-systems]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: n/a
|
||||
framework: n/a
|
||||
---
|
||||
|
||||
# [[Complex Systems|ComplexSystems]]
|
||||
# Complex Systems
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
시스템 사고([[Systems Thinking|Systems Thinking]])의 관점에서, 개별 구성 요소들이 서로 밀접하게 연결되어 피드백 루프와 비선형적 상호작용을 통해 예측 불가능한 결과를 창출하는 생태계를 의미합니다 [90, 91].
|
||||
## 매 한 줄
|
||||
> **"매 Complex System 매 part 의 sum 초과 의 emergent 결과 발생 system"**. 매 simple-rule 매 unpredictable global 의 야기. Santa Fe Institute (Holland, Kauffman, Mitchell) 의 lineage. 2026 매 LLM swarm, distributed micro-services, social platform 매 canonical 예.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **복잡계의 4대 특성:** 요소 간의 상호의존성(Interdependence), 작은 변화가 큰 결과를 낳는 비선형성(Non-linearity), 중앙 통제 없이 자발적으로 패턴이 나타나는 창발성([[Emergence|Emergence]]), 피드백을 통해 진화하는 적응성(Adaptation)이 특징입니다 [91].
|
||||
- **피드백 루프(Feedback Loops):** 복잡계 내부의 요소들은 시스템의 출력이 다시 입력에 영향을 미치는 폐쇄 루프(Closed-loop) 형태로 연결되어 있어, 하나의 행동이 시스템 전체에 연쇄적인 영향을 미칩니다 [58, 90, 92].
|
||||
- **단순화의 위험:** 선형적 사고([[Linear Thinking|Linear Thinking]])는 A가 B를 초래한다는 단편적인 원인-결과 모델에 의존하기 때문에, 복잡계 내에서 한 영역을 수정할 때 발생하는 다른 영역의 의도치 않은 부작용을 간과하게 만듭니다 [93-96].
|
||||
- **전체론적 접근(Holistic Approach):** 문제를 해결할 때 개별 요소로 분해하는 환원주의적(Reductionist) 태도에서 벗어나, 시스템 전체의 패턴과 역학을 관찰하는 시스템 사고가 필수적입니다 [58, 90, 97].
|
||||
- **적응적 해결책:** 복잡계에서의 해결책은 한 번에 끝나는 고정된 답이 아니라, 시스템의 동적인 성격과 장기적인 지속 가능성을 고려하여 지속적으로 적응(Adaptive)해야 합니다 [90].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Linear Thinking|Linear Thinking]], [[MECE Framework|MECE Framework]]
|
||||
- **Projects/Contexts:** Organizational Change [[Management|Management]], Environmental Management
|
||||
- **Contradictions/Notes:** 경영 컨설팅에서 문제를 나누고 정복하는 [[MECE|MECE]] 원칙은 유용하지만, 이는 본질적으로 환원주의적이므로 상호 의존성이 핵심인 복잡계의 '사악한 문제(Wicked problems)'를 다룰 때는 지나친 단순화의 오류(False completeness)에 빠질 수 있습니다 [56, 96, 98].
|
||||
### 매 정의 specifics
|
||||
- **Many components** (10² ~ 10⁹).
|
||||
- **Local interaction** (no central control).
|
||||
- **Non-linearity**: 매 input → output 의 disproportionate.
|
||||
- **Emergence**: 매 macro behavior 매 micro rule 의 not directly inferrable.
|
||||
- **Adaptation**: 매 component 의 state-update 의 environment 응답.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 simple ↔ complicated ↔ complex (Cynefin)
|
||||
- **Simple**: 매 cause↔effect obvious. Best practice 의 사용.
|
||||
- **Complicated**: 매 expert analysis required. Good practice.
|
||||
- **Complex**: 매 retrospect 만 cause 추론 가능. 매 probe-sense-respond.
|
||||
- **Chaotic**: 매 cause↔effect link absent. Act-sense-respond.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Distributed system design 매 emergent failure mode 의 anticipate.
|
||||
2. Org change 매 directly-controllable lever 부재 — 매 nudge.
|
||||
3. Market / social media 의 non-linear viral propagation.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Power-law detection (Pareto)
|
||||
```python
|
||||
import numpy as np, scipy.stats as st
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
def is_powerlaw(data: np.ndarray) -> bool:
|
||||
"""Heavy-tailed → likely complex, not Gaussian."""
|
||||
fit = st.powerlaw.fit(data)
|
||||
ks_p = st.kstest(data, "powerlaw", fit).pvalue
|
||||
return ks_p > 0.05
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Agent-based model (Mesa)
|
||||
```python
|
||||
from mesa import Agent, Model
|
||||
from mesa.space import MultiGrid
|
||||
from mesa.time import RandomActivation
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
class Cell(Agent):
|
||||
def step(self):
|
||||
n = self.neighbors_alive()
|
||||
self.alive = (n == 3) or (self.alive and n == 2)
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
class Life(Model):
|
||||
def __init__(self, w=80, h=80):
|
||||
self.grid = MultiGrid(w, h, torus=True)
|
||||
self.schedule = RandomActivation(self)
|
||||
for x in range(w):
|
||||
for y in range(h):
|
||||
a = Cell(self)
|
||||
self.grid.place_agent(a, (x, y))
|
||||
self.schedule.add(a)
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Feedback-loop diagram (Mermaid)
|
||||
```mermaid
|
||||
graph LR
|
||||
Demand --> Price
|
||||
Price -->|+| Supply
|
||||
Supply -->|-| Price
|
||||
Price -->|-| Demand
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Tipping-point detection
|
||||
```python
|
||||
def early_warning_signal(timeseries):
|
||||
"""Increased variance + autocorrelation → near phase transition."""
|
||||
rolling_var = pd.Series(timeseries).rolling(50).var()
|
||||
rolling_ac = pd.Series(timeseries).rolling(50).apply(lambda x: x.autocorr(1))
|
||||
return rolling_var.iloc[-1] > rolling_var.mean() * 1.5 \
|
||||
and rolling_ac.iloc[-1] > 0.7
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Causal-loop policy lever map
|
||||
```yaml
|
||||
# policy_levers.yml
|
||||
goal: reduce-incident-rate
|
||||
levers:
|
||||
- lever: deploy-frequency
|
||||
feedback: positive # more deploys → more incidents short-term
|
||||
horizon: weeks
|
||||
- lever: test-coverage
|
||||
feedback: negative # higher coverage → fewer incidents
|
||||
horizon: months
|
||||
- lever: oncall-rotation-size
|
||||
feedback: negative # larger rotation → less burnout → fewer incidents
|
||||
horizon: quarters
|
||||
```
|
||||
|
||||
### Network resilience metric
|
||||
```python
|
||||
import networkx as nx
|
||||
def fragility(G: nx.Graph) -> float:
|
||||
"""Higher = more fragile to targeted node removal."""
|
||||
bc = nx.betweenness_centrality(G)
|
||||
return max(bc.values()) - np.median(list(bc.values()))
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Linear, well-understood | Optimization, KPI |
|
||||
| Complicated (expert solvable) | Plan + execute |
|
||||
| Complex (emergent) | Probe + small experiments + observe |
|
||||
| Chaotic (crisis) | Act first, stabilize, then sense |
|
||||
| Pre-tipping point | Early-warning + circuit-breaker |
|
||||
|
||||
**기본값**: probe-sense-respond + diversity + redundancy.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Systems Thinking]] · [[Cynefin Framework]]
|
||||
- 변형: [[Chaos Theory]] · [[Complex Adaptive Systems]]
|
||||
- 응용: [[Distributed Systems]] · [[Network Theory]]
|
||||
- Adjacent: [[Emergence]] · [[Power Laws]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 system map 의 first-draft, 매 feedback-loop 의 surface, 매 policy lever brainstorm.
|
||||
**언제 X**: 매 prediction 의 complex system — 매 LLM 매 false confidence 매 위험. 매 historical analogy 의 limit.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Linear thinking**: 매 cause→effect 의 direct mapping 매 complex 에서 wrong.
|
||||
- **Optimization fallacy**: 매 single metric 의 optimization 매 emergent failure 야기 (Goodhart).
|
||||
- **Central control assumption**: 매 top-down command 매 local-rule system 매 ineffective.
|
||||
- **Reductionism over-reach**: 매 component 의 분석 매 emergent property 의 missing.
|
||||
- **Plan-the-future fallacy**: 매 5-year-plan 매 complex domain 매 fiction.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Mitchell _Complexity: A Guided Tour_, Holland _Hidden Order_, Snowden Cynefin Framework, Santa Fe Institute lectures, Donella Meadows _Thinking in Systems_).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Cynefin, agent-based model, power law, anti-patterns |
|
||||
|
||||
@@ -2,91 +2,191 @@
|
||||
id: wiki-2026-0508-concurrent-programming
|
||||
title: Concurrent Programming
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-COPR-001]
|
||||
aliases: [Concurrency, Multithreading, Async Programming]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, concurrent-programming, Parallel-Computing, multi-threading, Scalability, software-engineering]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [programming, concurrency, parallelism, systems]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Go, Rust, Python, JavaScript
|
||||
framework: tokio, asyncio, goroutines
|
||||
---
|
||||
|
||||
# [[Concurrent Programming|Concurrent Programming]]
|
||||
# Concurrent Programming
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "멀티태스킹의 기술: 여러 작업을 동시에 수행하는 것처럼 보이게 하거나 실제로 동시에 실행함으로써, CPU 자원을 놀리지 않고 고성능 대규모 시스템을 지탱하는 현대 소프트웨어의 필수 근육."
|
||||
## 매 한 줄
|
||||
> **"매 concurrency 매 task 의 interleaving — parallelism 의 simultaneous 와 별개"**. Hoare CSP, Hewitt Actor 의 lineage. 2026 매 Rust async, Go goroutines, Java virtual threads (Project Loom GA), Python free-threaded mode 매 mainstream.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
병행 프로그래밍(Concurrent Programming)은 여러 개의 연산이 겹치는 기간 동안 실행되도록 설계된 프로그래밍 패러다임입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 개념**:
|
||||
* **Concurrency vs Parallelism**: 병행성은 작업들이 '겹치는 시간'에 진행되는 논리적 개념이고, 병렬성은 실제로 '동시에' 수행되는 물리적 개념.
|
||||
* **Race Condition**: 여러 프로세스가 공유 자원에 동시에 접근할 때 결과가 예측 불가능해지는 치명적 버그.
|
||||
* **Synchronization**: 데이터 무결성을 위해 임계 구역(Critical Section)을 잠그는(Lock) 등의 조정 기술.
|
||||
2. **왜 중요한가?**:
|
||||
* 멀티코어 CPU 시대에 하드웨어 성능을 온전히 끌어내기 위한 유일한 방법이며, 수백만 명의 동시 접속자를 처리하는 서버 아키텍처의 핵심임. (Scalability와 연결)
|
||||
### 매 Concurrency vs Parallelism
|
||||
- **Concurrency**: 매 dealing-with-many things at once (composition).
|
||||
- **Parallelism**: 매 doing-many things at once (execution).
|
||||
- 매 concurrent 코드 매 single-core 매 still concurrent. 매 parallel 매 multi-core required.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거 프로그래밍 정책은 '스레드(Thread)'를 직접 관리하며 고통받는 정책이었으나, 현대 정책은 '코루틴(Coroutine)'이나 '액터 모델(Actor Model)' 같은 고수준 추상화 정책을 통해 안전하고 쉬운 병행성 정책을 지향함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 추론 정책에서, 수만 개의 연산을 병렬로 처리하는 GPU 아키텍처 환경에 최적화된 '대규모 병렬 연산 프로그래밍 정책'이 지능화의 물리적 토대가 됨.
|
||||
### 매 Primitives
|
||||
- **Threads / processes**: 매 OS-level. Heavyweight.
|
||||
- **Coroutines / fibers / virtual threads**: 매 user-mode lightweight.
|
||||
- **Async / await**: 매 cooperative scheduling.
|
||||
- **Channels**: 매 message passing (Go, Rust mpsc).
|
||||
- **Mutex / RWLock / Semaphore**: 매 shared-memory sync.
|
||||
- **Atomic**: 매 lock-free primitive.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scalability|Scalability]], [[Backend|Backend]], [[Blocking|Blocking]], [[Technical-Architecture|Technical-Architecture]], [[Optimization|Optimization]]
|
||||
- **Modern Tech/Tools**: Go (Goroutines), Rust (Ownership model), Node.js (Event Loop), CUDA (GPU parallelism).
|
||||
---
|
||||
### 매 응용
|
||||
1. Web server: 매 1 connection-per-virtual-thread (Loom) / async (tokio).
|
||||
2. Pipeline: 매 channel-based fan-out / fan-in.
|
||||
3. Actor system: 매 isolation per actor + supervision (Erlang/Elixir, Akka).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Go: goroutine + channel
|
||||
```go
|
||||
package main
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
import "fmt"
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
func worker(id int, jobs <-chan int, results chan<- int) {
|
||||
for j := range jobs {
|
||||
results <- j * 2
|
||||
}
|
||||
fmt.Println("worker", id, "done")
|
||||
}
|
||||
|
||||
- **정보 상태:** 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
|
||||
func main() {
|
||||
jobs := make(chan int, 100)
|
||||
results := make(chan int, 100)
|
||||
for w := 1; w <= 3; w++ {
|
||||
go worker(w, jobs, results)
|
||||
}
|
||||
for j := 1; j <= 9; j++ { jobs <- j }
|
||||
close(jobs)
|
||||
for r := 1; r <= 9; r++ { <-results }
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Rust: tokio + select!
|
||||
```rust
|
||||
use tokio::{select, time::{sleep, Duration}};
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
#[tokio::main]
|
||||
async fn main() {
|
||||
let task1 = async { sleep(Duration::from_millis(100)).await; "fast" };
|
||||
let task2 = async { sleep(Duration::from_millis(200)).await; "slow" };
|
||||
select! {
|
||||
v = task1 => println!("got {v}"),
|
||||
v = task2 => println!("got {v}"),
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Java 21+: virtual threads
|
||||
```java
|
||||
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
|
||||
IntStream.range(0, 10_000).forEach(i ->
|
||||
executor.submit(() -> {
|
||||
Thread.sleep(Duration.ofSeconds(1));
|
||||
return i;
|
||||
}));
|
||||
} // 10k virtual threads, ~negligible memory
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Python: asyncio TaskGroup (3.11+)
|
||||
```python
|
||||
import asyncio
|
||||
import httpx
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
async def fetch(client, url):
|
||||
r = await client.get(url)
|
||||
return r.status_code
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
async def main():
|
||||
async with httpx.AsyncClient() as client:
|
||||
async with asyncio.TaskGroup() as tg:
|
||||
tasks = [tg.create_task(fetch(client, u)) for u in URLS]
|
||||
results = [t.result() for t in tasks]
|
||||
```
|
||||
|
||||
### Rust: structured concurrency (tokio JoinSet)
|
||||
```rust
|
||||
use tokio::task::JoinSet;
|
||||
let mut set = JoinSet::new();
|
||||
for url in urls { set.spawn(fetch(url)); }
|
||||
while let Some(res) = set.join_next().await {
|
||||
println!("{:?}", res?);
|
||||
}
|
||||
```
|
||||
|
||||
### Lock-free atomic counter
|
||||
```rust
|
||||
use std::sync::atomic::{AtomicU64, Ordering};
|
||||
static COUNTER: AtomicU64 = AtomicU64::new(0);
|
||||
|
||||
fn bump() -> u64 {
|
||||
COUNTER.fetch_add(1, Ordering::Relaxed)
|
||||
}
|
||||
```
|
||||
|
||||
### Actor pattern (Elixir)
|
||||
```elixir
|
||||
defmodule Counter do
|
||||
use GenServer
|
||||
def start_link(_), do: GenServer.start_link(__MODULE__, 0, name: __MODULE__)
|
||||
def init(s), do: {:ok, s}
|
||||
def handle_call(:inc, _, s), do: {:reply, s+1, s+1}
|
||||
end
|
||||
```
|
||||
|
||||
### Backpressure with bounded channel
|
||||
```go
|
||||
sem := make(chan struct{}, 10) // max 10 concurrent
|
||||
for _, url := range urls {
|
||||
sem <- struct{}{}
|
||||
go func(u string) { defer func(){ <-sem }(); fetch(u) }(url)
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| I/O-bound, 10k+ connections | Async (tokio, asyncio, Loom) |
|
||||
| CPU-bound, multi-core | Threads / rayon (Rust) |
|
||||
| Pipeline, multi-stage | Channels (Go, Rust mpsc) |
|
||||
| Isolation + fault tolerance | Actors (Elixir, Akka) |
|
||||
| Shared mutable state | Mutex + minimize critical section |
|
||||
| Hot counter | Atomic, no lock |
|
||||
|
||||
**기본값**: structured concurrency + bounded channel + cancellation propagation.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Programming Paradigms]] · [[Operating Systems]]
|
||||
- 변형: [[Async Programming]] · [[Parallelism]]
|
||||
- 응용: [[Web Servers]] · [[Distributed Systems]]
|
||||
- Adjacent: [[Race Conditions]] · [[Deadlocks]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 concurrent code review 의 race-condition spotting, 매 deadlock-pattern detection, 매 channel-pattern translation.
|
||||
**언제 X**: 매 subtle memory-ordering bug — 매 formal verification (TLA+, loom) 의 사용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Shared mutable state without sync**: 매 race condition. UB in C++/Rust.
|
||||
- **Mutex in hot path**: 매 contention 의 serialization. 매 atomic / per-thread state.
|
||||
- **Unbounded goroutine spawn**: 매 OOM. 매 bounded pool / semaphore.
|
||||
- **Sync I/O in async function**: 매 single blocked task → 매 entire executor stall.
|
||||
- **Lock ordering inconsistent**: 매 deadlock. 매 always same order.
|
||||
- **Cancellation 의 ignore**: 매 dangling task / resource leak.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Hoare _Communicating Sequential Processes_, Go Memory Model 2022, Rust Async Book, JEP 444 (Java Virtual Threads), Python PEP 703).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — primitives, Go/Rust/Java/Python pattern, anti-patterns |
|
||||
|
||||
@@ -2,65 +2,219 @@
|
||||
id: wiki-2026-0508-continuous-obsolescence
|
||||
title: Continuous Obsolescence
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Tech Obsolescence, Software Decay, DIMINISHING-Manufacturing-Sources]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.88
|
||||
verification_status: applied
|
||||
tags: [software-engineering, lifecycle, dependency-management, technical-debt]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: process
|
||||
framework: lifecycle-management
|
||||
---
|
||||
|
||||
# [[Continuous Obsolescence|Continuous Obsolescence]]
|
||||
# Continuous Obsolescence
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
'Continuous Obsolescence(지속적 구식화)'는 게임 내에서 새로운 콘텐츠와 상한선 확장을 지속적으로 업데이트하여 유저가 기존에 보유한 자산의 가치를 끊임없이 하락시키는 운영 구조를 의미합니다 [1]. 이는 단순한 버그 수정이 아니라 건물, 부대, 연구 등의 한계치를 계속해서 높이는 '콘텐츠 러닝머신(Content Treadmills)' 시스템으로 작동합니다 [1]. 결과적으로 최상위 과금 유저와 일반 유저 간의 파워 격차를 벌리며, 유저들이 게임 내에서 도태되는 것을 피하기 위해 지속적으로 과금하도록 강제합니다 [1].
|
||||
## 매 한 줄
|
||||
> **"매 modern software 의 dependency tree 의 매일 obsolete 의 part — passive 의 X, continuous mitigation 의 require"**. 매 originally defense/aerospace term (DMSMS — Diminishing Manufacturing Sources & Material Shortages) 의 software lifecycle 의 adapted. 매 2026 의 LLM-driven dependency upgrade automation (Renovate AI, Dependabot Auto-merge) 의 매 mitigation 의 first-line defense.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **콘텐츠 러닝머신 (Content Treadmills):** 게임의 라이브 운영 단계(Live Phase)에서는 매일같이 새로운 업데이트가 푸시됩니다 [1]. 이 업데이트는 단순히 게임을 고치는 것을 넘어 새로운 레벨의 건물, T11 이상의 새로운 부대 티어, 'Draconic Blitz'나 'War Machine'과 같은 새로운 연구 카테고리를 끊임없이 추가하며 유저를 끝없는 진행 궤도 위에 올려놓습니다 [1].
|
||||
- **도태 방지를 위한 과금 강제:** 새롭고 강력한 콘텐츠의 지속적인 추가는 최상위 과금 유저(Top spenders)와 그 외 유저 사이의 '파워 격차(Power gap)'를 계속해서 넓히는 결과를 낳습니다 [1]. 중간 티어의 유저들은 자신의 제국이 구식화(Obsolete)되어 쓸모없어지는 것을 막고 경쟁력을 유지하기 위해 어쩔 수 없이 지갑을 열어야만 합니다 [1].
|
||||
- **무한한 경제 확장과 파워 인플레 ([[Power Creep|Power Creep]]):** 이 현상은 게임 내 수치를 지속적으로 증가시키는 '파워 인플레(Power Creep)' 메커니즘과 직결됩니다 [2]. 개발사들은 유저가 모든 콘텐츠를 달성하여 게임의 목표를 잃는 것을 방지하기 위해 무한히 확장 가능한 경제(Infinitely Scalable Economy)를 설계했습니다 [3, 4]. 스프레드시트 기반의 게임 구조 덕분에 새로운 장비나 기술 업그레이드를 비용 효율적으로 무한히 추가할 수 있어, 유저들이 계속 뒤처짐을 느끼게 만듭니다 [4, 5].
|
||||
- **끝없는 러닝머신 (Endless treadmill) 다크 패턴:** 이러한 지속적인 콘텐츠 추가와 구식화는 유저로 하여금 게임 내에 항상 더 달성해야 할 일이 남아있다고 느끼게 만드는 '끝없는 러닝머신(Endless treadmill)' 다크 패턴 전략으로도 분석됩니다 [6]. 이 구조는 지속적으로 증가하는 난이도나 반복 작업(Grinding)을 우회하기 위해 '과금으로 건너뛰기(Pay-to-skip)' 옵션을 선택하도록 유저들을 유도합니다 [6-8].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Power Creep|Power Creep]], Content Treadmills, [[LiveOps|LiveOps]], Dark Patterns
|
||||
- **Projects/Contexts:** Game of War: Fire Age
|
||||
- **Contradictions/Notes:** 소스 내용 중 직접적인 모순은 없으나, 이러한 지속적 구식화 시스템은 모바일 4X 게임에서 타의 추종을 불허하는 높은 유저 생애 가치(LTV)와 매출을 발생시키는 핵심 전략임과 동시에, 유저를 심리적으로 착취하는 약탈적 수익 창출 기법(Predatory Monetization)의 대표적 사례로 규제와 윤리적 비판의 대상이 된다는 점을 명시하고 있습니다 [9-13].
|
||||
### 매 obsolescence 의 종류
|
||||
- **Hard obsolescence**: 매 dependency 의 end-of-life (Python 3.7, Node 14, Ubuntu 18.04).
|
||||
- **Soft obsolescence**: 매 community migration (jQuery → React, Webpack → Vite).
|
||||
- **Security obsolescence**: 매 unpatched CVE 의 forcing function.
|
||||
- **API obsolescence**: 매 deprecated endpoints (AWS SDK v2 → v3).
|
||||
- **Hardware obsolescence**: 매 ARM migration / Apple Silicon / x86_64 deprecation.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 cost dynamics
|
||||
- **Linear today**: 매 weekly dep update 의 trivial.
|
||||
- **Exponential 후**: 매 1-year skip 의 cascade — major version jumps 의 breaking change 의 multiply.
|
||||
- **Cliff event**: 매 EOL 의 forced sudden migration ("Python 2 to 3" 의 trauma).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 mitigation strategies
|
||||
1. **Continuous (default)**: 매 weekly automated PR via Renovate/Dependabot.
|
||||
2. **Tiered**: 매 dev-deps 의 aggressive / runtime-deps 의 conservative.
|
||||
3. **Frozen + audit**: 매 occasional 의 enterprise — 매 annual mass-upgrade.
|
||||
4. **Replace-not-upgrade**: 매 abandoned deps 의 fork or rewrite.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 매 Renovate config (modern 2026 baseline)
|
||||
```json
|
||||
{
|
||||
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
|
||||
"extends": ["config:recommended", "schedule:weekly", ":automergeMinor"],
|
||||
"packageRules": [
|
||||
{
|
||||
"matchUpdateTypes": ["minor", "patch"],
|
||||
"matchCurrentVersion": "!/^0/",
|
||||
"automerge": true
|
||||
},
|
||||
{
|
||||
"matchUpdateTypes": ["major"],
|
||||
"addLabels": ["needs-review"],
|
||||
"automerge": false
|
||||
},
|
||||
{
|
||||
"matchPackagePatterns": ["^@types/"],
|
||||
"automerge": true,
|
||||
"schedule": ["at any time"]
|
||||
}
|
||||
],
|
||||
"vulnerabilityAlerts": { "labels": ["security"], "automerge": false },
|
||||
"dependencyDashboard": true
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### 매 dep-EOL scanner
|
||||
```python
|
||||
# Scan for end-of-life dependencies
|
||||
import requests
|
||||
import json
|
||||
from pathlib import Path
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
EOL_API = "https://endoflife.date/api"
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def check_eol(packages: dict[str, str]) -> list[dict]:
|
||||
"""packages: {'python': '3.10.5', 'node': '18.17.0', ...}"""
|
||||
issues = []
|
||||
for name, version in packages.items():
|
||||
major_minor = ".".join(version.split(".")[:2])
|
||||
try:
|
||||
data = requests.get(f"{EOL_API}/{name}/{major_minor}.json", timeout=5).json()
|
||||
if data.get("eol") and data["eol"] != False:
|
||||
issues.append({
|
||||
"package": name, "version": version,
|
||||
"eol_date": data["eol"], "latest": data.get("latest"),
|
||||
})
|
||||
except (requests.RequestException, json.JSONDecodeError):
|
||||
continue
|
||||
return issues
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
# usage
|
||||
deps = {"python": "3.10.5", "node": "18.17.0", "ubuntu": "20.04"}
|
||||
for issue in check_eol(deps):
|
||||
print(f"⚠️ {issue['package']} {issue['version']} EOL {issue['eol_date']}")
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### 매 dep-graph 의 staleness audit
|
||||
```python
|
||||
# JS/TS — npm outdated programmatic
|
||||
import subprocess, json
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
def staleness_audit() -> dict:
|
||||
out = subprocess.run(["npm", "outdated", "--json"], capture_output=True, text=True)
|
||||
data = json.loads(out.stdout) if out.stdout else {}
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
severity = {"critical": [], "high": [], "medium": [], "low": []}
|
||||
for pkg, info in data.items():
|
||||
cur = info["current"].split(".")
|
||||
wanted = info["wanted"].split(".")
|
||||
latest = info["latest"].split(".")
|
||||
if cur[0] != latest[0]:
|
||||
severity["high"].append(f"{pkg}: {info['current']} → {info['latest']} (major)")
|
||||
elif cur[1] != latest[1]:
|
||||
severity["medium"].append(f"{pkg}: {info['current']} → {info['latest']} (minor)")
|
||||
else:
|
||||
severity["low"].append(f"{pkg}: {info['current']} → {info['latest']} (patch)")
|
||||
return severity
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### 매 LLM-assisted migration (Claude Opus 4.7)
|
||||
```python
|
||||
import anthropic
|
||||
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
def llm_migration_plan(from_version: str, to_version: str, package: str, codebase_glob: str):
|
||||
"""Generate a migration checklist + automated edits."""
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=4096,
|
||||
system=[
|
||||
{"type": "text",
|
||||
"text": "You are a senior engineer planning library migrations. Be specific.",
|
||||
"cache_control": {"type": "ephemeral"}},
|
||||
],
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": f"""Migrate {package} from {from_version} to {to_version}.
|
||||
|
||||
Codebase pattern: {codebase_glob}
|
||||
|
||||
Output:
|
||||
1. Breaking changes list with file/line patterns to grep
|
||||
2. Automated codemod snippets (jscodeshift / ast-grep)
|
||||
3. Manual review checklist
|
||||
4. Rollback plan""",
|
||||
}],
|
||||
)
|
||||
return msg.content[0].text
|
||||
```
|
||||
|
||||
### 매 frozen + audit 의 quarterly upgrade
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# scripts/quarterly-upgrade.sh — mass dependency refresh
|
||||
set -e
|
||||
|
||||
# 1. Snapshot current state
|
||||
git checkout -b "deps/$(date +%Y-Q%q)"
|
||||
cp package-lock.json package-lock.snapshot.json
|
||||
|
||||
# 2. Update everything to latest minor/patch
|
||||
bunx npm-check-updates -u --target minor
|
||||
bun install
|
||||
|
||||
# 3. Run full test matrix
|
||||
bun run test:unit
|
||||
bun run test:integration
|
||||
bun run test:e2e
|
||||
|
||||
# 4. If green, push for review
|
||||
git add package*.json && git commit -m "chore: quarterly dep refresh"
|
||||
git push -u origin HEAD
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 active product / SaaS | Renovate weekly + automerge minor |
|
||||
| 매 enterprise / regulated | Quarterly mass upgrade + security patches weekly |
|
||||
| 매 legacy / frozen | Replace-not-upgrade for critical deps; sandbox the rest |
|
||||
| 매 OSS library | Conservative — minimum supported versions wide |
|
||||
| 매 DMSMS / hardware-bound | Multi-source + lifecycle stockpile |
|
||||
|
||||
**기본값**: 매 Renovate weekly + automerge minor + manual review major.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software Lifecycle]] · [[Technical Debt]]
|
||||
- 변형: [[Dependency Management]] · [[DMSMS]]
|
||||
- 응용: [[CVE Patching]] · [[Major Version Migration]] · [[End-of-Life Planning]]
|
||||
- Adjacent: [[Renovate]] · [[Dependabot]] · [[Software Bill of Materials (SBOM)]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 migration plan 의 generation / 매 changelog 의 breaking-change extraction / 매 codemod 의 draft.
|
||||
**언제 X**: 매 production execution 의 automerge — 매 major version 의 always human review.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **매 "if it ain't broke"**: 매 cliff event 의 inevitable.
|
||||
- **매 manual cherry-pick patches**: 매 missing 의 known CVEs.
|
||||
- **매 yearly big-bang upgrade**: 매 cascade 의 breaking change 의 untestable.
|
||||
- **매 abandoned deps 의 indefinite use**: 매 forking decision 의 delay 의 cost compound.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (DoD DMSMS Guidebook; Renovate documentation; Anthropic *Claude Code agent migration patterns* 2026).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — obsolescence types + Renovate/Dependabot patterns + LLM migration |
|
||||
|
||||
@@ -2,67 +2,155 @@
|
||||
id: wiki-2026-0508-creativity-research
|
||||
title: Creativity Research
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-CRES-001]
|
||||
aliases: [Creativity Studies, Creative Cognition Research]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.82
|
||||
tags: [auto-reinforced, creativity-Research, Psychology, Innovation, divergent-thinking, neurobiology]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [creativity, psychology, cognition, research]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: en
|
||||
framework: research-methods
|
||||
---
|
||||
|
||||
# [[Creativity Research|Creativity Research]]
|
||||
# Creativity Research
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "새로움의 기원을 찾아서: 신선하고 가치 있는 무언가를 만들어내는 인간의 능력을 심리적, 뇌과학적, 전산적 관점에서 분석하여 창의성의 프로세스를 이해하고 증명하려는 학문적 탐구."
|
||||
## 매 한 줄
|
||||
> **"매 creativity 의 measurable cognitive process — 매 mystical talent 아님"**. 매 1950 Guilford APA address 가 field 의 launch — 매 divergent thinking, fluency, originality 의 quantifiable. 매 2026 의 LLM-augmented co-creation, fMRI 의 default mode network 연구, computational creativity 의 active.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
창의성 연구(Creativity Re[[Search|Search]])는 창의적 사고의 본질과 이를 촉진하는 요인을 탐구합니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **4P 모델 (James Rhodes)**:
|
||||
* **Person**: 창의적 개인의 특성 (호기심, 개방성 등).
|
||||
* **Process**: 영감이 떠오르고 구체화되는 과정 (Incubation -> Insight).
|
||||
* **Product**: 산출물의 새로움과 적절성 평가.
|
||||
* **Press**: 창의성을 자극하거나 억압하는 환경적 요인.
|
||||
2. **인지적 메커니즘**:
|
||||
* **Divergent Thinking**: 하나의 문제에서 수많은 대안을 생성하는 확산적 사고.
|
||||
* **Convergent Thinking**: 가장 적합한 하나를 선택하는 수렴적 사고. ([[Combinatorial-Optimization|Combinatorial-Optimization]]과 대비)
|
||||
### 매 4P framework (Rhodes 1961)
|
||||
- **Person**: 매 traits — openness, tolerance for ambiguity, intrinsic motivation.
|
||||
- **Process**: 매 stages — preparation → incubation → illumination → verification (Wallas 1926).
|
||||
- **Product**: 매 novel + useful (Stein 1953 의 standard definition).
|
||||
- **Press**: 매 environment — domain, field gatekeepers (Csikszentmihalyi systems model).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 창의성을 '천재의 신비로운 영감' 정책으로 치부했으나, 현대 정책은 정밀한 뇌 영상 분석과 전산 모델링 정책을 통해 창의성 또한 '정보의 재조합과 패턴 발견 정책'임을 과학적으로 규명함(RL Update). ([[Computational Creativity|Computational Creativity]]와 연결)
|
||||
- **정책 변화(RL Update)**: AI 시대의 창의성 교육 정책에서, 단순히 '그림을 그리는 스킬'보다 문제의 본질을 꿰뚫고 AI에게 질문을 던지는 '프롬프트적 창의성 정책'과 '비판적 시각 정책'이 새로운 연구의 흐름이 됨.
|
||||
### 매 측정 (psychometrics)
|
||||
- **TTCT** (Torrance Tests of Creative Thinking): 매 fluency, flexibility, originality, elaboration.
|
||||
- **AUT** (Alternative Uses Task): 매 brick 의 uses 나열 — 매 divergent thinking 의 standard.
|
||||
- **CAT** (Consensual Assessment Technique, Amabile): 매 expert judges 의 product rating.
|
||||
- **RAT** (Remote Associates): 매 convergent creativity (3 cue → 1 link word).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Computational Creativity|Computational Creativity]], [[Arts|Arts]], [[Psychology & Behavior|Psychology & Behavior]], [[Philosophy|Philosophy]] of Science, [[Concept Mapping|Concept Mapping]]
|
||||
- **Modern Tech/Tools**: Torrance Tests of Creative Thinking (TTCT), fMRI brain mapping.
|
||||
---
|
||||
### 매 응용
|
||||
1. K-12 design thinking curriculum.
|
||||
2. 매 R&D ideation workshop (IDEO 의 protocols).
|
||||
3. 매 LLM prompt engineering 의 creativity scaffolding.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Divergent thinking score (AUT)
|
||||
```python
|
||||
def aut_score(responses: list[str], reference_corpus: dict[str, int]) -> dict:
|
||||
"""Score divergent-thinking output: fluency, flexibility, originality."""
|
||||
fluency = len(responses)
|
||||
categories = {classify_category(r) for r in responses}
|
||||
flexibility = len(categories)
|
||||
# originality = 1 - frequency in reference corpus (lower freq = more original)
|
||||
total = sum(reference_corpus.values()) or 1
|
||||
originality = sum(
|
||||
1 - (reference_corpus.get(r.lower(), 0) / total) for r in responses
|
||||
) / max(fluency, 1)
|
||||
return {"fluency": fluency, "flexibility": flexibility, "originality": originality}
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### LLM-augmented divergent ideation
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
client = Anthropic()
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def co_creative_ideation(prompt: str, n: int = 20) -> list[str]:
|
||||
"""Use Claude as a divergent-thinking partner — temperature high for variance."""
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2000,
|
||||
temperature=1.0,
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": f"Generate {n} maximally diverse, novel uses for: {prompt}. "
|
||||
f"Span categories. Avoid clichés. One per line."
|
||||
}],
|
||||
)
|
||||
return [line.strip("- ") for line in msg.content[0].text.splitlines() if line.strip()]
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Consensual Assessment (CAT) aggregation
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy.stats import pearsonr
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def cat_reliability(ratings: np.ndarray) -> float:
|
||||
"""Inter-rater reliability via Cronbach's alpha across expert judges."""
|
||||
k = ratings.shape[1]
|
||||
item_var = ratings.var(axis=0, ddof=1).sum()
|
||||
total_var = ratings.sum(axis=1).var(ddof=1)
|
||||
return (k / (k - 1)) * (1 - item_var / total_var)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Incubation effect simulation
|
||||
```python
|
||||
def incubation_benefit(initial_attempt_score: float, incubation_minutes: int) -> float:
|
||||
"""Sio & Ormerod 2009 meta-analysis: ~0.3 SD boost after incubation."""
|
||||
if incubation_minutes < 5:
|
||||
return initial_attempt_score
|
||||
return initial_attempt_score + 0.3 * min(incubation_minutes / 30, 1.0)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Default Mode Network proxy (resting-state correlation)
|
||||
```python
|
||||
def dmn_creativity_correlation(dmn_connectivity: float, ecn_connectivity: float) -> float:
|
||||
"""Beaty et al. 2018: high creativity = strong DMN ↔ ECN coupling."""
|
||||
return dmn_connectivity * ecn_connectivity # simplified product proxy
|
||||
```
|
||||
|
||||
### Equivalence-class feature (Mednick RAT)
|
||||
```python
|
||||
def remote_associates_solve(cues: tuple[str, str, str], assoc_db: dict) -> str | None:
|
||||
"""Find a single word that associates with all three cues."""
|
||||
sets = [set(assoc_db.get(c, [])) for c in cues]
|
||||
common = set.intersection(*sets)
|
||||
return next(iter(common), None)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Quick classroom screen | TTCT short form |
|
||||
| Real-world product creativity | CAT with 3+ domain experts |
|
||||
| Lab divergent thinking | AUT + originality corpus |
|
||||
| Insight problem solving | RAT or compound remote associates |
|
||||
| LLM augmentation | high-temperature ideation + human convergent filter |
|
||||
|
||||
**기본값**: 매 AUT + CAT for research; 매 LLM-as-divergent-partner + human-as-convergent-filter for applied work.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Cognitive Psychology]] · [[Creativity (Csikszentmihalyi Flow)]]
|
||||
- 변형: [[Divergent Thinking]] · [[Convergent Thinking]] · [[Computational Creativity]]
|
||||
- 응용: [[Design Thinking]] · [[Brainstorming]] · [[LLM Co-creation]]
|
||||
- Adjacent: [[Default Mode Network]] · [[Insight Problem Solving]] · [[Innovation Management]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 divergent ideation phase — 매 broad space exploration, 매 cliché breaking, 매 cross-domain analogies.
|
||||
**언제 X**: 매 convergent evaluation alone — 매 LLM 의 novelty calibration 의 약함 (training data bias toward common). 매 originality scoring 시 의 corpus-based metric 결합 필요.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Brainstorming = creativity 의 동일시**: 매 group brainstorming 의 production blocking — 매 nominal groups 가 실제로 더 많은 ideas (Diehl & Stroebe 1987).
|
||||
- **Originality 만 추적**: 매 useful 의 손실 — 매 novel + useful 가 정의.
|
||||
- **Single judge CAT**: 매 inter-rater reliability 의 unverifiable.
|
||||
- **TTCT 만 의 의존**: 매 ecological validity 의 약함 — real-world creative achievement prediction 의 modest (r ≈ 0.2-0.3).
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Guilford 1950, Torrance 1966, Amabile 1982, Beaty et al. 2018 NeuroImage).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 4P framework, AUT/CAT/RAT measurement, LLM co-creation patterns 추가 |
|
||||
|
||||
@@ -2,92 +2,149 @@
|
||||
id: wiki-2026-0508-enterprise-service-bus
|
||||
title: Enterprise Service Bus
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ESBU-001]
|
||||
aliases: [ESB, Service Bus, Integration Bus]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, esb, enterprise-service-bus, soa, middleware, integration, msa]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [architecture, integration, soa, messaging, esb]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: java
|
||||
framework: apache-camel
|
||||
---
|
||||
|
||||
# [[Enterprise-Service-Bus|Enterprise-Service-Bus]]
|
||||
# Enterprise Service Bus
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기업 시스템의 통역 관제소: 파편화된 수많은 서비스와 데이터베이스 사이에서 메시지를 중계하고, 포맷을 변환하며, 누가 누구에게 정보를 보낼지 관리하는 중앙 집중형 미들웨어 인프라."
|
||||
## 매 한 줄
|
||||
> **"매 ESB = SOA 시대 의 integration backbone — 매 2026 의 legacy + event mesh 의 hybrid"**. 매 hub-and-spoke 의 anti-pattern 회피 위한 message-bus pattern. 매 modern 의 Kafka + service mesh + iPaaS (MuleSoft, Boomi) 가 ESB 의 기능 의 분산.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
엔터프라이즈 서비스 버스(Enterprise-Service-Bus, ESB)는 서비스 지향 아키텍처(SOA)를 구현하기 위한 핵심 미들웨어로, 이질적인 서비스 간의 통합을 담당합니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **주요 기능**:
|
||||
* **Message Routing**: 정해진 규칙에 따라 메시지를 목적지로 전달. ([[Control-Systems-Engineering|Control-Systems-Engineering]]와 연결)
|
||||
* **Transformation**: 서비스 간 서로 다른 데이터 포맷(XML -> JSON 등) 변환.
|
||||
* **Orchestration**: 여러 서비스를 순차적으로 호출하여 하나의 비즈니스 프로세스 완성. (Standard-Operating-Procedure와 연결)
|
||||
* **Protocol Conversion**: HTTP, FTP, AMQP 등 다양한 통신 규약 지원.
|
||||
2. **왜 중요한가?**:
|
||||
* 서비스 간의 직접적인 결합(Loose coupling)을 방지하여 한 시스템의 변경이 전체 시스템에 미치는 영향을 최소화하기 때문임.
|
||||
### 매 ESB 의 6 capabilities
|
||||
- **Routing**: 매 content-based, header-based.
|
||||
- **Transformation**: 매 XML↔JSON↔Avro, schema mapping.
|
||||
- **Protocol bridging**: 매 SOAP↔REST↔AMQP↔JMS↔FTP.
|
||||
- **Orchestration**: 매 multi-step workflow (BPEL, Camel routes).
|
||||
- **Mediation**: 매 versioning, throttling, security policy.
|
||||
- **Monitoring**: 매 audit, SLA tracking, error queues.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거 SOA 시대에는 ESB 가 모든 것의 중심인 무거운 통합 정책(Heavyweight) 정책이었으나, 현대 MSA 정책 하에서는 ESB 대신 가벼운 'API Gateway'와 'Service Mesh' 정책으로 기능이 파편화되어 분산되는 추세임(RL Update). ([[Technical-Architecture|Technical-Architecture]]와 연결)
|
||||
- **정책 변화(RL Update)**: 이제는 단순 메시지 전달 정책을 넘어, 분산 시스템의 트래픽 정책을 AI 가 실시간으로 제어하고 장애를 감지하여 경로를 우회시키는 '지능형 이벤트 메시징 정책'으로 진화 중임.
|
||||
### 매 versus alternatives
|
||||
- **Point-to-point**: 매 N×N integration — ESB 의 N+1.
|
||||
- **Hub-and-spoke**: 매 single hub bottleneck — ESB 의 distributed.
|
||||
- **Event mesh (modern)**: 매 Kafka + Schema Registry — 매 ESB 보다 throughput ↑, transformation logic 의 service-side.
|
||||
- **iPaaS**: 매 cloud-native ESB — 매 SaaS connector 의 thousand+.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Technical-Architecture|Technical-Architecture]], [[Standard-Operating-Procedure|Standard-Operating-Procedure]], [[Control-Systems-Engineering|Control-Systems-Engineering]], [[Reliability|Reliability]], [[Scalability|Scalability]]
|
||||
- **Key [[goal|goal]]**: Loose coupling in heterogeneous[[_system|system]]s.
|
||||
---
|
||||
### 매 응용
|
||||
1. Bank legacy mainframe ↔ digital channel integration.
|
||||
2. ERP (SAP) ↔ CRM (Salesforce) sync.
|
||||
3. B2B EDI translation (X12, EDIFACT).
|
||||
|
||||
## 🤖 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
|
||||
### Apache Camel content-based router
|
||||
```java
|
||||
from("jms:queue:incomingOrders")
|
||||
.choice()
|
||||
.when(jsonpath("$.priority == 'HIGH'"))
|
||||
.to("kafka:high-priority-orders")
|
||||
.when(jsonpath("$.region == 'EU'"))
|
||||
.to("amqp:eu-orders")
|
||||
.otherwise()
|
||||
.to("jms:queue:standardOrders")
|
||||
.end();
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### XML → JSON transformation
|
||||
```java
|
||||
from("file:input/orders?include=.*\\.xml")
|
||||
.unmarshal().jacksonXml(Order.class)
|
||||
.marshal().json(JsonLibrary.Jackson)
|
||||
.to("http://api.example.com/orders");
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Saga orchestration (Camel)
|
||||
```java
|
||||
from("direct:placeOrder")
|
||||
.saga()
|
||||
.compensation("direct:cancelOrder")
|
||||
.timeout(java.time.Duration.ofMinutes(5))
|
||||
.to("direct:reserveInventory")
|
||||
.to("direct:chargePayment")
|
||||
.to("direct:scheduleShipment");
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Dead letter channel
|
||||
```java
|
||||
errorHandler(deadLetterChannel("jms:queue:dlq")
|
||||
.maximumRedeliveries(3)
|
||||
.redeliveryDelay(2000)
|
||||
.useExponentialBackOff());
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Modern replacement: Kafka + KStreams
|
||||
```java
|
||||
StreamsBuilder builder = new StreamsBuilder();
|
||||
builder.stream("orders", Consumed.with(Serdes.String(), orderSerde))
|
||||
.filter((k, v) -> v.getAmount() > 1000)
|
||||
.mapValues(o -> enrichWithCustomer(o))
|
||||
.to("high-value-orders");
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Service mesh sidecar (Istio) replacement
|
||||
```yaml
|
||||
apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: order-routing
|
||||
spec:
|
||||
http:
|
||||
- match:
|
||||
- headers:
|
||||
x-region:
|
||||
exact: EU
|
||||
route:
|
||||
- destination:
|
||||
host: order-service-eu
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Greenfield microservices | Kafka + service mesh, ESB X |
|
||||
| Legacy mainframe + SaaS integration | iPaaS (MuleSoft, Boomi) |
|
||||
| Heavy XML/SOAP B2B | Apache Camel or MuleSoft |
|
||||
| Event-driven architecture | Kafka + Schema Registry |
|
||||
| Complex orchestration | Camel + Saga or Temporal.io |
|
||||
|
||||
**기본값**: 매 2026 의 new project — Kafka + service mesh. 매 legacy integration — Camel or iPaaS. 매 traditional ESB (WSO2, Mule 3) 의 신규 도입 X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Service-Oriented Architecture (SOA)]] · [[Enterprise Integration Patterns]]
|
||||
- 변형: [[Event Mesh]] · [[iPaaS]] · [[Service Mesh]]
|
||||
- 응용: [[B2B Integration]] · [[Legacy Modernization]] · [[API Gateway]]
|
||||
- Adjacent: [[Message Queue]] · [[Apache Kafka]] · [[Saga Pattern]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 EIP pattern matching, 매 Camel DSL generation, 매 XSLT/XPath debugging, 매 legacy SOAP WSDL → REST OpenAPI 변환.
|
||||
**언제 X**: 매 production routing rules 의 직접 deploy — 매 정확한 schema validation, dead-letter handling 의 review 필요. 매 transformation logic 의 round-trip test 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **God-ESB**: 매 모든 business logic 의 ESB 의 집중 — 매 bus 의 monolith. 매 logic 의 service-side.
|
||||
- **Synchronous chains**: 매 ESB 의 long sync calls — 매 cascading failure. 매 async + saga.
|
||||
- **No schema governance**: 매 transformation 의 implicit contract — 매 producer change 시 silent break.
|
||||
- **2026 의 new ESB 도입**: 매 platform team 의 maintenance cost ↑ — 매 Kafka + iPaaS 의 분산.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Hohpe & Woolf "Enterprise Integration Patterns" 2003, Apache Camel docs 4.x, Gartner ESB→iPaaS 의 2024 report).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Camel patterns, modern Kafka/mesh replacement, iPaaS context 추가 |
|
||||
|
||||
@@ -2,65 +2,149 @@
|
||||
id: wiki-2026-0508-enzyme-inhibition-kinetics
|
||||
title: Enzyme Inhibition Kinetics
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-EINK-001]
|
||||
aliases: [Inhibitor Kinetics, Michaelis-Menten Inhibition]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, enzyme-inhibition, kinetics, biochemistry, michaelis-menten, competitive-inhibition, drug-design]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [biochemistry, kinetics, enzymes, pharmacology]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: scipy
|
||||
---
|
||||
|
||||
# [[Enzyme-Inhibition-Kinetics|Enzyme-Inhibition-Kinetics]]
|
||||
# Enzyme Inhibition Kinetics
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "생화학의 브레이크 시스템: 생명 현상을 주관하는 효소의 활동을 특정 물질이 어떻게 방해하고 늦추는지 수학적으로 분석하여, 암세포의 증식을 막거나 통증 수치를 조절하는 정교한 신약 개발의 근거."
|
||||
## 매 한 줄
|
||||
> **"매 inhibitor 의 binding mode 가 Vmax/Km 의 어떻게 shift 의 결정"**. 매 1913 Michaelis-Menten + 1934 Lineweaver-Burk extension. 매 2026 의 cryo-EM + MD simulation + AlphaFold-Multimer 가 mechanism elucidation 의 정밀.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
효소 저해 속도론(Enzyme-Inhibition-Kinetics)은 저해제(Inhibitor)가 효소의 반응 속도에 미치는 영향을 정량적으로 연구하는 분야입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 저해 유형 (Michaelis-Menten 모델 기반)**:
|
||||
* **Competitive Inhibition**: 저해제가 기질과 활성 부위를 두고 경쟁. Vmax 불변, Km 증가.
|
||||
* **Non-competitive Inhibition**: 다른 부위에 결합하여 효소 구조 변경. Vmax 감소, Km 불변.
|
||||
* **Uncompetitive Inhibition**: 효소-기질 복합체에만 결합. Vmax와 Km 모두 감소.
|
||||
2. **왜 중요한가?**:
|
||||
* 대부분의 약물 정책(아스피린, 항암제 등)이 특정 효소의 활동 정책을 저해하는 방식이므로, 이 속도론적 지표(Ki)가 신약의 효능 정책을 결정하는 척도가 되기 때문임. ([[Scientific-Method|Scientific-Method]]와 연결)
|
||||
### 매 4 inhibitor types
|
||||
- **Competitive**: 매 active site binding — Km ↑, Vmax 불변. 매 substrate 증가 시 reversible.
|
||||
- **Uncompetitive**: 매 ES complex binding — Km ↓, Vmax ↓ (same fold). 매 high [S] 의 deeper inhibition.
|
||||
- **Non-competitive (mixed)**: 매 enzyme + ES 모두 binding — Vmax ↓, Km 의 shift (α, α').
|
||||
- **Irreversible (covalent)**: 매 covalent bond (suicide inhibitor) — 매 time-dependent IC50.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 실험 데이터 정책을 손으로 그리는 리뉴버-버크 플롯 정책 등에 의존했으나, 현대 정책은 강력한 컴퓨팅 정책(Molecular Dynamics)을 통해 저해제가 단백질과 결합하는 과정을 원자 단위에서 시뮬레이션함(RL Update). (Simulation와 연결)
|
||||
- **정책 변화(RL Update)**: 최근에는 AI 가 수억 개의 화합물 정책 중 핵심 효소 정책을 최적으로 저해할 후보 물질 정책을 수분 만에 찾아내는 'AI 신약 설계'로 패러다임이 완전히 전환됨. (Bio-Informatics와 연결)
|
||||
### 매 핵심 equation
|
||||
- **Michaelis-Menten**: v = Vmax·[S] / (Km + [S]).
|
||||
- **Competitive**: v = Vmax·[S] / (αKm + [S]), α = 1 + [I]/Ki.
|
||||
- **Ki** (inhibition constant): 매 lower Ki = stronger binding.
|
||||
- **IC50**: 매 50% inhibition concentration — 매 [S]-dependent.
|
||||
- **Cheng-Prusoff**: Ki = IC50 / (1 + [S]/Km) for competitive.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scientific-Method|Scientific-Method]], Simulation, Bio-Informatics, [[Analysis|Analysis]], [[Statistics|Statistics]], [[Refinement|Refinement]]
|
||||
- **Key Equation**: Michaelis-Menten Equation.
|
||||
---
|
||||
### 매 응용
|
||||
1. Statins (HMG-CoA reductase competitive).
|
||||
2. Methotrexate (DHFR competitive).
|
||||
3. Aspirin (COX irreversible acetylation).
|
||||
4. Drug-drug interaction (CYP450 inhibition).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Michaelis-Menten fitting
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy.optimize import curve_fit
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def mm(S, Vmax, Km):
|
||||
return Vmax * S / (Km + S)
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
S = np.array([0.1, 0.3, 1.0, 3.0, 10.0, 30.0])
|
||||
v = np.array([0.91, 2.31, 5.00, 7.50, 9.09, 9.68])
|
||||
(Vmax, Km), _ = curve_fit(mm, S, v, p0=[10, 1])
|
||||
print(f"Vmax={Vmax:.2f}, Km={Km:.2f}")
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Competitive inhibition fit (global fit over [I])
|
||||
```python
|
||||
def competitive(S_I, Vmax, Km, Ki):
|
||||
S, I = S_I
|
||||
alpha = 1 + I / Ki
|
||||
return Vmax * S / (alpha * Km + S)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
S_grid, I_grid = np.meshgrid([0.1, 1, 10], [0, 0.5, 2.0])
|
||||
xdata = np.vstack([S_grid.ravel(), I_grid.ravel()])
|
||||
# ydata = experimental velocities at each (S, I)
|
||||
(Vmax, Km, Ki), _ = curve_fit(competitive, xdata, ydata, p0=[10, 1, 1])
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### IC50 fit (Hill equation)
|
||||
```python
|
||||
def hill(I, IC50, n, top=1.0, bottom=0.0):
|
||||
return bottom + (top - bottom) / (1 + (I / IC50) ** n)
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
(IC50, n), _ = curve_fit(lambda I, IC50, n: hill(I, IC50, n),
|
||||
I_data, response_data, p0=[1.0, 1.0])
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Cheng-Prusoff conversion
|
||||
```python
|
||||
def cheng_prusoff_ki(IC50: float, S: float, Km: float, mode: str = "competitive") -> float:
|
||||
if mode == "competitive":
|
||||
return IC50 / (1 + S / Km)
|
||||
if mode == "uncompetitive":
|
||||
return IC50 / (1 + Km / S)
|
||||
if mode == "non-competitive":
|
||||
return IC50 # mixed: independent of [S] in pure non-competitive
|
||||
raise ValueError(mode)
|
||||
```
|
||||
|
||||
### Time-dependent (irreversible) kinetics
|
||||
```python
|
||||
def kobs_vs_inhibitor(t: np.ndarray, kinact: float, KI: float, I: float) -> np.ndarray:
|
||||
"""Fractional active enzyme over time."""
|
||||
kobs = kinact * I / (KI + I)
|
||||
return np.exp(-kobs * t)
|
||||
```
|
||||
|
||||
### Lineweaver-Burk diagnostic
|
||||
```python
|
||||
import matplotlib.pyplot as plt
|
||||
inv_S = 1 / S
|
||||
inv_v = 1 / v
|
||||
plt.plot(inv_S, inv_v, "o")
|
||||
# Slope = Km/Vmax, y-intercept = 1/Vmax.
|
||||
# Competitive: lines intersect at y-axis. Non-competitive: at x-axis.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Diagnostic |
|
||||
|---|---|
|
||||
| Km↑, Vmax 동일 | competitive |
|
||||
| Km↓, Vmax↓ (same factor) | uncompetitive |
|
||||
| Vmax↓, Km variable | mixed/non-competitive |
|
||||
| time-dependent kobs | irreversible/slow-binding |
|
||||
| High [S] 의 inhibition deepening | uncompetitive |
|
||||
|
||||
**기본값**: 매 global non-linear fit over (S, I) grid > Lineweaver-Burk linearization (매 error 의 distort).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Enzyme Kinetics]] · [[Michaelis-Menten Kinetics]]
|
||||
- 변형: [[Allosteric Regulation]] · [[Suicide Inhibition]] · [[Slow-Binding Inhibition]]
|
||||
- 응용: [[Drug Discovery]] · [[Pharmacokinetics]] · [[Metabolic Engineering]]
|
||||
- Adjacent: [[Hill Equation]] · [[Cooperativity]] · [[CYP450 Drug Interactions]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 mechanism classification 의 plot interpretation, 매 fitting code 의 생성, 매 literature Ki 의 aggregation.
|
||||
**언제 X**: 매 raw fluorescence/absorbance 의 직접 fit — 매 background subtraction, inner-filter correction 의 manual review 필요.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Lineweaver-Burk 의 fitting**: 매 error 의 1/v transformation 시 distort — 매 non-linear fit 사용.
|
||||
- **IC50 의 Ki 의 동일시**: 매 [S]-dependent — 매 Cheng-Prusoff 변환 필수.
|
||||
- **Single [I] 의 mechanism 결정**: 매 ambiguous — 매 multiple [I] 의 (S, v) curve 비교.
|
||||
- **Ignoring substrate depletion**: 매 initial-rate assumption violation.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Cornish-Bowden "Fundamentals of Enzyme Kinetics" 4th ed, Copeland "Evaluation of Enzyme Inhibitors" 2nd ed).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 4 inhibitor types, scipy fitting, Cheng-Prusoff 추가 |
|
||||
|
||||
@@ -2,93 +2,156 @@
|
||||
id: wiki-2026-0508-ethical-decision-making
|
||||
title: Ethical Decision Making
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-EDMA-001]
|
||||
aliases: [Moral Reasoning, Applied Ethics, Ethical Frameworks]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, ethical-decision-making, ethics, Philosophy, justice, utilitariansim, deOntology]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [ethics, decision-making, philosophy, ai-ethics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: en
|
||||
framework: applied-ethics
|
||||
---
|
||||
|
||||
# [[Ethical-Decision-Making|Ethical-Decision-Making]]
|
||||
# Ethical Decision Making
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "가치의 저울질: 기술적 성능이나 경제적 이득이 아닌, '무엇이 옳은가'를 기준으로 갈등 상황을 분석하고, 이해관계자 모두에게 정의로운 최선의 선택지를 도출하는 도덕적 알고리즘."
|
||||
## 매 한 줄
|
||||
> **"매 multiple framework 의 cross-check — 매 single doctrine 의 absolutism 회피"**. 매 consequentialism, deontology, virtue ethics, care ethics 의 each 의 blind spot. 매 2026 의 AI alignment, autonomous vehicle trolley 의 real, RLHF reward modeling 의 active.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
윤리적 의사결정(Ethical-Decision-Making)은 개인이나 조직이 윤리적 원칙과 가치를 바탕으로 문제를 인식하고 대안을 평가하여 선택하는 프로세스입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 철학적 접근**:
|
||||
* **Utilitarianism (공리주의)**: 최대 다수의 최대 행복. 결과적 영향 중심.
|
||||
* **Deontology (의무론)**: 보편적 도덕 원칙 준수 (예: 거짓말 금지). 과정의 정당성 중심. ([[Logic|Logic]]와 연결)
|
||||
* **Virtue Ethics (덕 윤리)**: 좋은 인간(또는 조직)이라면 어떻게 행동했을까? 행위자의 품성 중심.
|
||||
2. **적용 단계**:
|
||||
* **Awareness**: 윤리적 쟁점 정책 인식.
|
||||
* **Evaluation**: 각 대안이 이해관계자에게 미칠 영향 분석. (Sensitivity-[[Analysis|Analysis]]와 대비).
|
||||
* **Intention & Action**: 최선의 선택 실행 및 책임 수용.
|
||||
### 매 4 frameworks
|
||||
- **Consequentialism (utilitarian)**: 매 outcome 만 — sum of utility 의 maximize. Bentham, Mill, Singer.
|
||||
- **Deontology**: 매 rules / duties — Kant 의 categorical imperative, 매 means matter.
|
||||
- **Virtue ethics**: 매 character / flourishing — Aristotle 의 phronesis, MacIntyre.
|
||||
- **Care ethics**: 매 relationships / context — Gilligan, Noddings 의 critique of impartiality.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 개인의 '양심'에만 의존했으나, 현대 정책은 AI 윤리 정책, 데이터 거버넌스 정책 등 고도로 복합적인 기술 윤리 상황을 처리하기 위한 '체계적 프레임워크 정책' 수립을 필수화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 인간의 의사결정 정책을 넘어, 자율주행차나 의료 AI 가 맞닥뜨릴 '트롤리 딜레마' 상황에서 어떤 윤리 정책을 탑재(Embedding)할 것인가에 대한 수학적 정의가 연구의 핵심임. (Ethics와 연결)
|
||||
### 매 process (Rest 4-component model)
|
||||
1. **Moral awareness**: 매 ethical issue 의 recognize.
|
||||
2. **Moral judgment**: 매 right action 의 reason.
|
||||
3. **Moral motivation**: 매 ethics 의 prioritize over self-interest.
|
||||
4. **Moral character**: 매 follow-through 의 capacity.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Logic|Logic]], [[Sensitivity-Analysis|Sensitivity-Analysis]], Ethics, Decision-Making, [[Quality-Control|Quality-Control]], Effective-Altruism-in-AI
|
||||
- **Key Model**: Rest's Four-Component Model.
|
||||
---
|
||||
### 매 응용
|
||||
1. AI deployment review (Anthropic 의 RSP, OpenAI 의 Preparedness).
|
||||
2. Medical triage (ICU bed allocation).
|
||||
3. Whistleblowing / dual-use research.
|
||||
4. Autonomous vehicle 의 unavoidable harm scenario.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Multi-framework decision matrix
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
from typing import Callable
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
@dataclass
|
||||
class Action:
|
||||
name: str
|
||||
consequences: dict[str, float] # outcome → utility
|
||||
rules_violated: list[str]
|
||||
virtues_expressed: list[str]
|
||||
care_relations_impact: dict[str, float]
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
def evaluate(a: Action) -> dict:
|
||||
util = sum(a.consequences.values())
|
||||
deont = -10 * len(a.rules_violated)
|
||||
virtue = len(a.virtues_expressed)
|
||||
care = sum(a.care_relations_impact.values())
|
||||
return {"utilitarian": util, "deontological": deont,
|
||||
"virtue": virtue, "care": care,
|
||||
"consensus": all(s >= 0 for s in [util, deont, virtue, care])}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Veil of ignorance simulator (Rawlsian)
|
||||
```python
|
||||
import random
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def veil_of_ignorance(policy_payoffs: dict[str, list[float]], trials: int = 10_000) -> dict:
|
||||
"""Rank policies by expected worst-off welfare (maximin)."""
|
||||
ranks = {}
|
||||
for policy, payoffs in policy_payoffs.items():
|
||||
worst = sum(min(random.choices(payoffs, k=1)) for _ in range(trials)) / trials
|
||||
ranks[policy] = worst
|
||||
return dict(sorted(ranks.items(), key=lambda kv: -kv[1]))
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Trolley-problem framing test
|
||||
```python
|
||||
def reframe_test(scenario: dict) -> list[str]:
|
||||
"""Detect framing dependence — flip wording, check if judgment flips."""
|
||||
variants = [
|
||||
scenario["original"],
|
||||
scenario["original"].replace("kill", "let die"),
|
||||
scenario["original"].replace("save 5", "sacrifice 1"),
|
||||
]
|
||||
return variants # judge each, compare consistency
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### LLM ethics reasoner
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
client = Anthropic()
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
def ethical_review(situation: str) -> str:
|
||||
return client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2000,
|
||||
system=("Evaluate the situation through 4 frameworks: utilitarian, "
|
||||
"deontological, virtue, care. Surface tensions. Recommend "
|
||||
"an action only when frameworks converge or note disagreement."),
|
||||
messages=[{"role": "user", "content": situation}],
|
||||
).content[0].text
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Stakeholder impact map
|
||||
```python
|
||||
def stakeholder_matrix(action: str, stakeholders: list[str]) -> dict[str, dict]:
|
||||
return {
|
||||
s: {"benefits": [], "harms": [], "consent": None, "voice": None}
|
||||
for s in stakeholders
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Framework |
|
||||
|---|---|
|
||||
| Aggregate welfare, scale | utilitarian |
|
||||
| Inviolable rights, consent | deontological |
|
||||
| Long-term character, profession | virtue |
|
||||
| Dependency, vulnerability | care |
|
||||
| Policy under uncertainty | Rawlsian veil of ignorance |
|
||||
| Frameworks conflict | seek convergence; if none, default to deontological floor + utilitarian tiebreak |
|
||||
|
||||
**기본값**: 매 multi-framework cross-check + stakeholder impact map. 매 single-framework dogmatism X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Applied Ethics]] · [[Moral Philosophy]]
|
||||
- 변형: [[Bioethics]] · [[Business Ethics]] · [[AI Ethics]] · [[Research Ethics]]
|
||||
- 응용: [[Trolley Problem]] · [[AI Alignment]] · [[Whistleblowing]]
|
||||
- Adjacent: [[Veil of Ignorance]] · [[Categorical Imperative]] · [[Phronesis]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 framework comparison, 매 stakeholder enumeration, 매 dual-use risk surfacing, 매 Socratic counter-argument.
|
||||
**언제 X**: 매 final decision 의 LLM 의 outsource — 매 accountability 의 human. 매 jurisdiction-specific legal/ethical compliance 의 expert review.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Single-framework absolutism**: 매 utilitarian 만 → 매 monstrous trade-off 정당화. 매 deontology 만 → 매 catastrophic outcome 의 무시.
|
||||
- **Ethics-washing**: 매 framework citation 후 commercial interest 의 결정 — 매 stakeholder 의 voice 의 부재.
|
||||
- **Trolley reductionism**: 매 toy dilemma 의 real-world dilemma 의 동일시 — 매 actual scenarios 의 messy.
|
||||
- **Moral licensing**: 매 prior good act 의 next questionable act 의 정당화.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Beauchamp & Childress "Principles of Biomedical Ethics" 8th ed, Rest 1986, Singer "Practical Ethics" 3rd ed, Anthropic Constitutional AI).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 4-framework matrix, Rest model, LLM ethics review pattern 추가 |
|
||||
|
||||
@@ -2,91 +2,155 @@
|
||||
id: wiki-2026-0508-etiology-of-disease
|
||||
title: Etiology of Disease
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ETDI-001]
|
||||
aliases: [Disease Causation, Pathogenesis, Causal Inference (Medicine)]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, etiology, disease, pathology, causality, genetics, environment]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [medicine, epidemiology, causal-inference, pathology]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: r
|
||||
framework: epidemiology
|
||||
---
|
||||
|
||||
# [[Etiology-of-Disease|Etiology-of-Disease]]
|
||||
# Etiology of Disease
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "질병의 뿌리 찾기: 단순히 눈에 보이는 증상을 치료하는 것을 넘어, 유전적 결함, 바이러스 침투, 환경 오염 등 질병을 일으킨 '근본 원인(Causality)'을 수학적·생물학적으로 규명하여 완치를 목표로 하는 탐구."
|
||||
## 매 한 줄
|
||||
> **"매 disease 의 cause = single agent 가 아닌 web of necessary + sufficient + component causes"**. 매 1840 Henle-Koch 의 single-pathogen postulate → 매 Rothman 1976 sufficient-component model → 매 2026 의 multi-omics + Mendelian randomization + DAG-based causal inference.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
병인학(Etiology-of-Disease)은 질병의 원인과 그 인자들이 질병 발생에 기여하는 메커니즘을 연구하는 의학 및 생물학 분야입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **원인의 분류**:
|
||||
* **Endogenous (내인성)**: 유전적 이상, 대사 장애, 면역 결함. ([[Enzyme-Inhibition-Kinetics|Enzyme-Inhibition-Kinetics]]와 연결)
|
||||
* **Exogenous (외인성)**: 바이러스/세균(Bio[[Logic|Logic]]al), 화학 물질/독소(Chemical), 외상/방사선(Physical).
|
||||
* **Multifactorial**: 유전과 환경의 복합적 상호작용. ([[Epidemiological-Modeling|Epidemiological-Modeling]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 원인을 정확히 알아야만 '표적 정밀 치료(Precision medicine)'가 가능하며, 반복되는 질병의 확산 경로 정책을 차단할 수 있기 때문임.
|
||||
### 매 causation models
|
||||
- **Henle-Koch postulates**: 매 isolation, transmission, re-isolation — 매 monocausal infectious era.
|
||||
- **Bradford Hill criteria (1965)**: 9 viewpoints — strength, consistency, specificity, temporality, biological gradient, plausibility, coherence, experiment, analogy.
|
||||
- **Rothman sufficient-component**: 매 disease = sum of "pies", each pie = sufficient cause = set of component causes. 매 same disease 의 multiple sufficient sets.
|
||||
- **Counterfactual / DAG**: 매 Pearl 의 do-calculus, 매 confounder identification.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '단일 원인 정책(One cause)' 가설이 지배적이었으나, 현대 정책은 수만 개의 유전자 정책과 환경 변수 정책이 얽힌 복합적인 '네트워크 정책적 원인'을 분석하는 시스템 생물학 정책으로 전환됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 이제는 생물학적 원인 정책을 넘어, 환자의 '디지털 병인(Digital Etiology)' - 즉, 스마트 기기 사용 패턴 정책이나 수면 정책, 식습관 데이터 정책 등을 분석하여 질병 이전의 전조 증상 정책을 포착하는 연구가 활발함. (Bio-Informatics와 연결)
|
||||
### 매 causal categories
|
||||
- **Necessary**: 매 cause 없이 disease 없음 (예: HIV → AIDS).
|
||||
- **Sufficient**: 매 cause 만 으로 disease (rare in practice).
|
||||
- **Component**: 매 sufficient cause 의 part (예: 흡연 + asbestos + genetic).
|
||||
- **Risk factor**: 매 association 만 — causality 의 unconfirmed.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Enzyme-Inhibition-Kinetics|Enzyme-Inhibition-Kinetics]], [[Epidemiological-Modeling|Epidemiological-Modeling]], Bio-Informatics, [[Scientific-Method|Scientific-Method]], [[Reliability|Reliability]], [[Sustainability|Sustainability]]
|
||||
- **Key Concepts**: Koch's postulates, Genetic predisposition.
|
||||
---
|
||||
### 매 응용
|
||||
1. Smoking → lung cancer (Doll & Hill 1950).
|
||||
2. H. pylori → peptic ulcer (Marshall 1984).
|
||||
3. HPV → cervical cancer (zur Hausen 2008 Nobel).
|
||||
4. APOE4 → Alzheimer (genetic risk, not deterministic).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Bradford Hill scoring
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
@dataclass
|
||||
class HillCriteria:
|
||||
strength: float # RR or OR
|
||||
consistency: int # # of confirming studies
|
||||
temporality: bool # exposure precedes outcome
|
||||
gradient: bool # dose-response
|
||||
plausibility: bool # mechanism known
|
||||
coherence: bool # fits prior knowledge
|
||||
experiment: bool # RCT / natural experiment
|
||||
specificity: bool
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
def hill_score(c: HillCriteria) -> int:
|
||||
score = 0
|
||||
score += 2 if c.strength >= 3 else 1 if c.strength >= 2 else 0
|
||||
score += min(c.consistency // 3, 3)
|
||||
score += [c.temporality, c.gradient, c.plausibility,
|
||||
c.coherence, c.experiment, c.specificity].count(True)
|
||||
return score # ≥7 = strong causal evidence
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Confounder adjustment via DAG (DoWhy)
|
||||
```python
|
||||
import dowhy
|
||||
from dowhy import CausalModel
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
model = CausalModel(
|
||||
data=df,
|
||||
treatment="smoking",
|
||||
outcome="lung_cancer",
|
||||
common_causes=["age", "sex", "ses"],
|
||||
instruments=["tobacco_tax"],
|
||||
)
|
||||
identified = model.identify_effect()
|
||||
estimate = model.estimate_effect(identified, method_name="backdoor.linear_regression")
|
||||
refute = model.refute_estimate(identified, estimate, method_name="placebo_treatment_refuter")
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Mendelian randomization
|
||||
```python
|
||||
# Instrumental variable: SNP → exposure → outcome
|
||||
# (SNP independent of confounders)
|
||||
import statsmodels.api as sm
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
# Wald ratio: beta_outcome / beta_exposure
|
||||
def mendelian_ratio(snp_exposure_beta: float, snp_outcome_beta: float) -> float:
|
||||
return snp_outcome_beta / snp_exposure_beta
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Population attributable fraction
|
||||
```python
|
||||
def paf(prevalence: float, relative_risk: float) -> float:
|
||||
"""Fraction of disease attributable to exposure in population."""
|
||||
return prevalence * (relative_risk - 1) / (1 + prevalence * (relative_risk - 1))
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# Smoking prevalence 25%, RR for lung cancer 20:
|
||||
print(paf(0.25, 20)) # ~0.83 → 83% of lung cancer attributable to smoking
|
||||
```
|
||||
|
||||
### Sufficient-component pie visualization
|
||||
```python
|
||||
def sufficient_pies(disease: str) -> list[set[str]]:
|
||||
"""Each pie = a set of component causes that together suffice."""
|
||||
return [
|
||||
{"smoking", "genetic_susceptibility"}, # pie 1
|
||||
{"asbestos", "smoking"}, # pie 2
|
||||
{"radon", "smoking", "vitamin_deficiency"}, # pie 3
|
||||
]
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Method |
|
||||
|---|---|
|
||||
| Single pathogen, acute | Koch postulates (modernized) |
|
||||
| Chronic, multifactorial | Bradford Hill + Rothman |
|
||||
| Observational with confounders | DAG + backdoor adjustment |
|
||||
| Genetic causation suspected | Mendelian randomization |
|
||||
| RCT impossible (ethics) | quasi-experiment + sensitivity analysis |
|
||||
|
||||
**기본값**: 매 Bradford Hill + DAG-based confounder adjustment + sensitivity analysis (E-value).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Epidemiology]] · [[Pathology]] · [[Causal Inference]]
|
||||
- 변형: [[Genetic Etiology]] · [[Environmental Etiology]] · [[Multifactorial Disease]]
|
||||
- 응용: [[Drug Discovery]] · [[Public Health Policy]] · [[Precision Medicine]]
|
||||
- Adjacent: [[Bradford Hill Criteria]] · [[Mendelian Randomization]] · [[DAG Causal Inference]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 literature synthesis 의 mechanism aggregation, 매 DAG 의 candidate confounder enumeration, 매 sufficient-component 의 component proposal.
|
||||
**언제 X**: 매 final causation claim 의 LLM 의 의존 — 매 effect estimate 의 source data + statistical method 의 검증 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Single-cause thinking**: 매 multifactorial disease 의 monocausal explanation — 매 H. pylori 발견 전 의 stress 의 ulcer 의 단일 cause 의 오해.
|
||||
- **Correlation = causation**: 매 RR 만 으로 causal claim — 매 confounding, reverse causation, selection bias 의 무시.
|
||||
- **Ignoring temporality**: 매 cross-sectional study 의 causal direction 의 결정 X.
|
||||
- **Hill criteria 의 checklist 화**: 매 의 mechanical scoring — 매 viewpoints, not rules (Hill 의 의도).
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Rothman & Greenland "Modern Epidemiology" 4th ed, Hernán & Robins "Causal Inference: What If" 2024, Pearl "Causality" 2nd ed).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Hill criteria, Rothman pies, DAG/MR patterns 추가 |
|
||||
|
||||
@@ -2,90 +2,159 @@
|
||||
id: wiki-2026-0508-feedback-loops
|
||||
title: Feedback Loops
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-FELP-001]
|
||||
aliases: [Feedback Control, Closed Loop, Cybernetic Feedback]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, feedback-loops, Systems-Thinking, Cybernetics, Self-Correction, steering]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [systems, control-theory, cybernetics, dynamics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: control-systems
|
||||
---
|
||||
|
||||
# [[Feedback-Loops|Feedback-Loops]]
|
||||
# Feedback Loops
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지능의 고리: 행위의 결과가 다시 원인의 입력으로 돌아와 시스템을 강화하거나 안정시키는 순환 구조로, 모든 생명체의 항상성과 기계의 자동 제어, 그리고 조직의 학습을 가능케 하는 우주의 운영 원리."
|
||||
## 매 한 줄
|
||||
> **"매 system output 의 input 의 re-entry — 매 stability 또는 amplification 의 결정"**. 매 1948 Wiener 의 Cybernetics 가 unifying frame. 매 2026 의 RLHF, autoscaling, climate tipping points, social media engagement loop 의 modern instances.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
피드백 루프(Feedback-Loops)는 시스템의 출력이 입력을 조절하는 프로세스입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **두 가지 유형**:
|
||||
* **Negative Feedback (안정화)**: 목표와 멀어지면 반대 방향으로 힘을 가해 현재 상태 유지 (예: 에어컨 온도 조절, 인체 항상성). ([[Homeostasis|Homeostasis]]와 연결)
|
||||
* **Positive Feedback (증폭)**: 특정 방향으로의 변화를 더 가속화 (예: 산울림 현상, 기술의 지수 성장, 시장 독점). ([[Exponential-Growth|Exponential-Growth]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 시스템이 외부 변화에 적응하고 스스로를 보정(Self-Correction)하게 만드는 핵심 동력임. (Cybernetics의 근간)
|
||||
### 매 2 polarities
|
||||
- **Negative (balancing)**: 매 deviation 의 dampen — 매 thermostat, homeostasis, PID controller.
|
||||
- **Positive (reinforcing)**: 매 deviation 의 amplify — 매 viral growth, asset bubble, ice-albedo feedback, runaway selection.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 피드백을 단순 '결과 보고 정책'으로 보았으나, 현대 정책은 루프의 속도와 정확도가 시스템의 지능 지수 정책을 결정한다고 봄(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 에이전트 정책에서 '생각-실행-반영'의 피드백 루프인 ReAct 패턴이 도입되며, 한번에 정답을 내는 구조에서 '고쳐나가는 지능 정책'으로 진화함.
|
||||
### 매 5 archetypes (Senge)
|
||||
- **Limits to growth**: 매 reinforcing + balancing — 매 S-curve.
|
||||
- **Shifting the burden**: 매 quick fix 의 underlying issue 의 weaken.
|
||||
- **Tragedy of the commons**: 매 individual reinforcing → collective collapse.
|
||||
- **Fixes that fail**: 매 short-term fix 의 long-term backfire.
|
||||
- **Success to the successful**: 매 winner-take-all reinforcing.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Cybernetics|Cybernetics]], [[Control-Theory|Control-Theory]], [[Homeostasis (항상성)|Homeostasis (항상성)]], Self-Correction, [[Exponential-Growth|Exponential-Growth]]
|
||||
- **Modern Tech/Tools**: Monitoring dashboards, CI/CD pipelines, Reinforcement Learning agents.
|
||||
---
|
||||
### 매 stability concepts
|
||||
- **Gain**: 매 output/input ratio.
|
||||
- **Phase margin**: 매 stability buffer (>45° robust).
|
||||
- **Time delay**: 매 instability driver (Bode-Nyquist).
|
||||
- **Setpoint vs. error**: 매 target — actual.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. PID controller (industrial process).
|
||||
2. RLHF (LLM 의 preference loop).
|
||||
3. Autoscaling (Kubernetes HPA, target CPU).
|
||||
4. Insulin-glucose homeostasis.
|
||||
5. Market price discovery.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### PID controller
|
||||
```python
|
||||
class PID:
|
||||
def __init__(self, kp: float, ki: float, kd: float, setpoint: float):
|
||||
self.kp, self.ki, self.kd = kp, ki, kd
|
||||
self.setpoint = setpoint
|
||||
self.integral = 0.0
|
||||
self.prev_error = 0.0
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
def step(self, measurement: float, dt: float) -> float:
|
||||
error = self.setpoint - measurement
|
||||
self.integral += error * dt
|
||||
derivative = (error - self.prev_error) / dt if dt > 0 else 0
|
||||
self.prev_error = error
|
||||
return self.kp * error + self.ki * self.integral + self.kd * derivative
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Logistic growth (limits-to-growth archetype)
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy.integrate import odeint
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def logistic(N, t, r, K):
|
||||
return r * N * (1 - N / K)
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
t = np.linspace(0, 50, 500)
|
||||
N = odeint(logistic, y0=1, t=t, args=(0.3, 1000))
|
||||
# Reinforcing (rN) + balancing ((1 - N/K))
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Autoscaling reactive loop
|
||||
```python
|
||||
def autoscale_step(current_replicas: int, cpu_utilization: float,
|
||||
target: float = 0.7, max_replicas: int = 100) -> int:
|
||||
desired = int(current_replicas * cpu_utilization / target)
|
||||
return max(1, min(desired, max_replicas))
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Reinforcement learning (RLHF reward model loop)
|
||||
```python
|
||||
def rlhf_iteration(policy, reward_model, prompts, ppo_optimizer):
|
||||
rollouts = [policy.generate(p) for p in prompts]
|
||||
rewards = [reward_model.score(p, r) for p, r in zip(prompts, rollouts)]
|
||||
advantages = compute_advantages(rewards)
|
||||
ppo_optimizer.step(policy, rollouts, advantages)
|
||||
# Loop closes: policy → output → reward → policy update
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Stability check (root locus)
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy.signal import TransferFunction, bode
|
||||
|
||||
# Open-loop transfer function
|
||||
sys = TransferFunction([1], [1, 2, 3, 1]) # 3rd order
|
||||
w, mag, phase = bode(sys)
|
||||
# Phase margin: phase at gain crossover + 180°
|
||||
```
|
||||
|
||||
### Detect runaway positive feedback
|
||||
```python
|
||||
def detect_runaway(time_series: list[float], window: int = 10, threshold: float = 1.5) -> bool:
|
||||
"""Exponential growth detector — log-linear fit slope."""
|
||||
import numpy as np
|
||||
if len(time_series) < window:
|
||||
return False
|
||||
y = np.log(np.maximum(time_series[-window:], 1e-9))
|
||||
slope = np.polyfit(range(window), y, 1)[0]
|
||||
return slope > np.log(threshold) / window
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Process regulation, setpoint tracking | PID (negative feedback) |
|
||||
| Growth modeling | logistic / Gompertz (mixed) |
|
||||
| Cascading failure prevention | rate limiters + circuit breakers |
|
||||
| Slow process w/ delay | feed-forward + smith predictor |
|
||||
| ML training | RLHF / GRPO with KL regularization |
|
||||
|
||||
**기본값**: 매 negative feedback 의 default for stability. 매 positive feedback 의 explicit guard (rate limit, kill switch).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Cybernetics]] · [[Control Theory]] · [[Systems Thinking]]
|
||||
- 변형: [[Negative Feedback]] · [[Positive Feedback]] · [[Feed-forward Control]]
|
||||
- 응용: [[PID Controller]] · [[RLHF]] · [[Autoscaling]] · [[Homeostasis]]
|
||||
- Adjacent: [[System Dynamics]] · [[Bode Plot]] · [[Tipping Points]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 archetype identification, 매 PID gain initial estimation, 매 system dynamics diagram 의 stock-flow conversion.
|
||||
**언제 X**: 매 safety-critical control gain tuning — 매 hardware-in-the-loop testing, 매 actual phase margin verification 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Ignoring delay**: 매 time-delay 의 PID 의 instability — 매 dead-time compensation 필요.
|
||||
- **High gain assumption = better tracking**: 매 oscillation, 매 noise amplification.
|
||||
- **Open-loop control for safety-critical**: 매 disturbance rejection X — 매 closed-loop 필수.
|
||||
- **Reinforcing loop 의 무방어 deploy**: 매 viral metric 의 optimization — 매 social harm runaway (engagement maximization → polarization).
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Wiener "Cybernetics" 1948, Åström & Murray "Feedback Systems" 2nd ed, Sterman "Business Dynamics" 2000, Senge "Fifth Discipline" rev. ed).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — PID, Senge archetypes, RLHF/autoscaling 추가 |
|
||||
|
||||
@@ -2,62 +2,163 @@
|
||||
id: wiki-2026-0508-habit-formation
|
||||
title: Habit Formation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [HABIT-001]
|
||||
aliases: [Habit Loop, Behavior Automation, Habituation]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Psychology|[Psychology", neuroscience, Behavior-change, productivity]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [psychology, behavior, neuroscience, habits]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: en
|
||||
framework: behavioral-psychology
|
||||
---
|
||||
|
||||
# Habit Formation (습관 형성의 심리학)
|
||||
# Habit Formation
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "의지력을 자동화된 루틴으로 대체하라" — 반복적인 행동을 통해 뇌의 신경 회로가 재편되어, 최소한의 인지적 노력만으로 특정 행동을 수행하게 되는 심리적 과정.
|
||||
## 매 한 줄
|
||||
> **"매 habit = cue → routine → reward 의 basal-ganglia automatization"**. 매 21-day myth 의 false — Lally 2010 의 median 66 days (range 18-254). 매 2026 의 wearables + LLM coaching + JITAI (just-in-time adaptive intervention) 의 active.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 신호(Cue) -> 반복 행동(Routine) -> 보상(Reward)으로 이어지는 '습관 고리(Habit Loop)'를 형성하여 의사결정 에너지를 절약하는 인지 패턴.
|
||||
- **세부 내용:**
|
||||
- **Basal Ganglia:** 습관이 저장되는 뇌 부위. 전전두엽의 개입 없이도 행동을 실행하게 함.
|
||||
- **Implementation Intentions:** "X 상황이 오면 Y를 하겠다"는 구체적 계획이 습관 형성 성공률을 높임.
|
||||
- **Keystone Habits:** 하나의 작은 습관이 연쇄적으로 다른 긍정적 변화를 일으키는 핵심 습관 (예: 운동, 독서).
|
||||
- **[[Neuroplasticity|Neuroplasticity]]:** 반복을 통해 시냅스 연결이 강화되는 뇌의 가소성 원리.
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 단순히 "21일이면 습관이 된다"는 속설과 달리, 행동의 복잡도에 따라 평균 66일에서 길게는 수개월이 걸릴 수 있음이 현대 심리학에서 증명됨.
|
||||
- **정책 변화:** Antigravity 에이전트의 사용자 인터랙션 설계 시, 사용자가 매일 지식 가드닝에 참여할 수 있도록 명확한 '신호'와 '보상' 체계를 제공하여 습관화를 유도함.
|
||||
### 매 habit loop (Duhigg / Wood)
|
||||
1. **Cue**: 매 trigger — time, place, emotional state, preceding action, people.
|
||||
2. **Routine**: 매 behavior 자체.
|
||||
3. **Reward**: 매 reinforcement — neural prediction error.
|
||||
4. **Craving** (Wood addition): 매 anticipation 의 cue→reward.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Dopamine|Dopamine]]rgic-Reward-Systems, [[Behavioral-Economics|Behavioral-Economics]], [[Psychology|Psychology]], Productivity
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Habit-Formation.md
|
||||
### 매 neural substrate
|
||||
- **Goal-directed**: 매 prefrontal + dorsomedial striatum — early learning.
|
||||
- **Habitual**: 매 dorsolateral striatum (sensorimotor loop) — automatization.
|
||||
- **Switch**: 매 overtraining + stable context → habitual takeover.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 formation 의 핵심 levers
|
||||
- **Implementation intentions** (Gollwitzer): "When X, I will Y" — 매 효과 size large (d ≈ 0.65).
|
||||
- **Context stability**: 매 same time + place 의 consistency.
|
||||
- **Friction reduction**: 매 cue salience ↑, 매 obstacle ↓.
|
||||
- **Temptation bundling** (Milkman): 매 desired + pleasurable 결합.
|
||||
- **Identity-based**: 매 "I am someone who..." (Clear).
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 응용
|
||||
1. Atomic Habits 의 4 laws (obvious, attractive, easy, satisfying).
|
||||
2. Health behavior change (exercise, medication adherence).
|
||||
3. Productivity (deep-work blocks).
|
||||
4. Habit-stacking (after-X-then-Y).
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Habit tracker (streak + context)
|
||||
```python
|
||||
from dataclasses import dataclass, field
|
||||
from datetime import date, timedelta
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
@dataclass
|
||||
class HabitLog:
|
||||
name: str
|
||||
cue_context: dict # {time, location, preceding_action}
|
||||
completions: list[date] = field(default_factory=list)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
@property
|
||||
def streak(self) -> int:
|
||||
if not self.completions:
|
||||
return 0
|
||||
s, today = 1, max(self.completions)
|
||||
for i in range(1, len(self.completions)):
|
||||
if today - self.completions[-1 - i] == timedelta(days=i):
|
||||
s += 1
|
||||
else:
|
||||
break
|
||||
return s
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Implementation intention generator
|
||||
```python
|
||||
def implementation_intention(goal: str, cue: str, action: str) -> str:
|
||||
return f"When {cue}, I will {action} in service of {goal}."
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
# When I pour my morning coffee, I will do 10 push-ups in service of strength training.
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Habit-stacking chain
|
||||
```python
|
||||
def stack(anchor: str, new_habit: str, reward: str | None = None) -> dict:
|
||||
return {
|
||||
"anchor": anchor,
|
||||
"new_habit": new_habit,
|
||||
"rule": f"After {anchor}, I will {new_habit}.",
|
||||
"immediate_reward": reward,
|
||||
}
|
||||
```
|
||||
|
||||
### JITAI delivery decision
|
||||
```python
|
||||
def jitai_should_deliver(state: dict) -> bool:
|
||||
"""Deliver intervention only when receptive + context-matched + low burden."""
|
||||
return (state["stress"] < 0.7
|
||||
and state["cognitive_load"] < 0.6
|
||||
and state["context_match"] > 0.8
|
||||
and state["recent_interventions_24h"] < 3)
|
||||
```
|
||||
|
||||
### Lally formation curve
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
def automaticity(day: int, asymptote: float = 0.95, k: float = 0.04) -> float:
|
||||
"""Asymptotic automaticity (Lally 2010 fit)."""
|
||||
return asymptote * (1 - np.exp(-k * day))
|
||||
# day 21 → ~0.58, day 66 → ~0.88
|
||||
```
|
||||
|
||||
### Context-cue salience score
|
||||
```python
|
||||
def cue_salience(cue: dict, history: list[dict]) -> float:
|
||||
"""Higher when cue co-occurs with successful routine."""
|
||||
matches = [h for h in history if all(h.get(k) == v for k, v in cue.items())]
|
||||
if not matches:
|
||||
return 0.0
|
||||
return sum(h["completed"] for h in matches) / len(matches)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Strategy |
|
||||
|---|---|
|
||||
| Brand-new habit | implementation intention + context stability |
|
||||
| Existing routine + new addition | habit stacking (anchor) |
|
||||
| High-friction habit | reduce friction first, then add cue |
|
||||
| Reward-poor habit | temptation bundling |
|
||||
| Identity-level change | identity-based ("I am the kind of person who...") |
|
||||
| Relapse prevention | re-stabilize context, restore cue |
|
||||
|
||||
**기본값**: 매 implementation intention + same context daily + 60-90 day window. 매 21-day promise X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Behavioral Psychology]] · [[Operant Conditioning]]
|
||||
- 변형: [[Keystone Habits]] · [[Bad Habit Extinction]] · [[Habit Stacking]]
|
||||
- 응용: [[Atomic Habits]] · [[CBT]] · [[JITAI]] · [[Behavior Change]]
|
||||
- Adjacent: [[Basal Ganglia]] · [[Implementation Intentions]] · [[Self-Determination Theory]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 implementation intention drafting, 매 habit-stack anchor 의 brainstorm, 매 obstacle anticipation, 매 daily reflection scaffold.
|
||||
**언제 X**: 매 individual psychological diagnosis (e.g., compulsion vs habit) — 매 clinical professional 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **21-day promise**: 매 individual variance 무시 — 매 18-254 day range.
|
||||
- **Willpower 만 의 의존**: 매 ego depletion + decision fatigue — 매 environment design.
|
||||
- **Multiple new habits 의 동시**: 매 cognitive bandwidth 초과 — 매 1-2 habits 의 sequence.
|
||||
- **No cue specification**: 매 vague intention ("eat better") — 매 specific cue + action.
|
||||
- **Punishing missed days excessively**: 매 self-shame spiral — 매 "miss once, never twice" rule.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Lally et al. 2010 EJSP, Wood "Good Habits, Bad Habits" 2019, Duhigg "Power of Habit", Clear "Atomic Habits", Gollwitzer 1999 meta-analysis).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — habit loop, Lally curve, JITAI, implementation intentions 추가 |
|
||||
|
||||
@@ -2,68 +2,32 @@
|
||||
id: wiki-2026-0508-horizontal-logic
|
||||
title: Horizontal Logic
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-horizontal-and-vertical-logic
|
||||
duplicate_of: "[[Horizontal and Vertical Logic]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, structured-thinking, mece, pyramid-principle]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Horizontal Logic|Horizontal Logic]]
|
||||
# Horizontal Logic
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
피라미드 구조 내에서 같은 계층(Level)에 속한 아이디어들이 서로를 어떻게 논리적으로 연결하고 배열되는지를 결정하는 규칙.
|
||||
> **이 문서는 [[Horizontal and Vertical Logic]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- 수평적 논리는 독자가 아이디어들이 왜 함께 묶였는지 짐작하지 않도록 명확한 순서를 제공합니다. 아이디어의 배열 순서는 마음이 그룹을 형성한 분석적 활동을 반영해야 합니다 [3, 37].
|
||||
- 수평적으로 아이디어를 배열하는 논리적 방식은 단 4가지입니다:
|
||||
1) 연역적 순서 (대인수, 소인수, 결론)
|
||||
2) 시간적 순서 (원인과 결과의 발생 순, Chrono[[Logic|Logic]]al)
|
||||
3) 구조적 순서 (전체를 부분으로 나누는 순, Structural)
|
||||
4) 비교/중요도 순서 (가장 중요한 것부터 덜 중요한 순, Comparative) [3, 37, 38].
|
||||
- 수평적 관계를 형성하는 서브 포인트들은 반드시 동일한 종류(Same kind)의 아이디어여야 하며(예: 모두 문제점이거나 모두 해결책 등), 상호 배타적이고 전체를 포괄하는 [[MECE|MECE]] 원칙을 엄격하게 지켜야 합니다 [37-39].
|
||||
## 핵심 요약 (specialization)
|
||||
- **Horizontal Logic**: 매 same-level points 의 MECE — 매 mutually exclusive + collectively exhaustive.
|
||||
- **Use**: 매 Pyramid Principle (Minto) 의 sibling-level argument coherence.
|
||||
- **Test**: 매 reorder freely without losing meaning, 매 no overlap, 매 covers all cases.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Vertical Logic, [[MECE Principle|MECE Principle]]
|
||||
- **Projects/Contexts:** Structuring Arguments, Report Writing
|
||||
- **Contradictions/Notes:** 수평적 논리 순서가 엉망일 경우, 독자의 뇌는 무의식적으로 아이디어 간의 연관성을 찾기 위해 인지적 에너지를 낭비하게 되어 정작 메시지 본질에 대한 이해도가 떨어집니다 [40].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Horizontal and Vertical Logic]] (canonical)
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
|
||||
## 🤖 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 |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,74 +2,170 @@
|
||||
id: wiki-2026-0508-horizontal-and-vertical-logic
|
||||
title: Horizontal and Vertical Logic
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Pyramid Logic, Minto Pyramid Logic, MECE-Pyramid Structure]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [structured-thinking, pyramid-principle, mece, communication, consulting]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: en
|
||||
framework: minto-pyramid
|
||||
---
|
||||
|
||||
# [[Horizontal and Vertical Logic|Horizontal and Vertical Logic]]
|
||||
# Horizontal and Vertical Logic
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
수평적 및 수직적 논리(Horizontal and Vertical [[Logic|Logic]])는 민토 피라미드 원칙([[Minto Pyramid Principle|Minto Pyramid Principle]])에서 아이디어를 구조화하고 결합하여 설득력 있는 문서를 작성하기 위한 핵심 차원이다 [1, 2]. 수직적 논리는 상위 아이디어와 하위 아이디어 간의 '질문과 답변' 대화를 형성하여 독자의 주의를 이끌어낸다 [1, 3, 4]. 반면, 수평적 논리는 동일한 계층에 있는 아이디어들 간의 관계를 규정하며, 연역적 또는 귀납적 추론을 통해 일관된 논리적 순서를 유지한다 [5, 6]. 이 두 가지 논리가 결합하여 주장을 견고하게 뒷받침하는 피라미드 구조를 완성한다 [2, 7].
|
||||
## 매 한 줄
|
||||
> **"매 vertical logic = parent ↔ children Q&A coherence; horizontal logic = sibling MECE coherence"**. 매 1973 Barbara Minto (McKinsey) 의 Pyramid Principle 의 dual axis. 매 2026 의 LLM-assisted argument structuring, executive-summary generation, audit findings 의 modern instances.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **수직적 논리 (Vertical Logic)**
|
||||
* 수직적 논리는 피라미드의 상하 관계를 나타내며, 글쓴이와 독자 간의 '질문/답변(Question-Answer) 대화'를 구축하는 역할을 한다 [1, 4, 8].
|
||||
* 피라미드에서 주요 아이디어나 주장이 제시되면 독자의 마음속에는 자연스럽게 '왜?(Why?)' 또는 '어떻게?(How?)'와 같은 질문이 떠오르게 되며, 바로 아래 계층의 하위 아이디어들이 이 질문에 직접적으로 답변해야 한다 [1, 3, 4].
|
||||
* 하위 계층의 정보들은 상위 포인트를 보강하고 요약하는 역할을 수행해야 하며 [5, 9, 10], 만약 하위 포인트가 상위 포인트가 제기한 질문에 직접적으로 답하지 못한다면 수직적 논리가 깨지고 주장의 설득력을 잃게 된다 [4].
|
||||
## 매 핵심
|
||||
|
||||
* **수평적 논리 ([[Horizontal Logic|Horizontal Logic]])**
|
||||
* 수평적 논리는 피라미드의 동일한 레벨(계층)에 위치한 아이디어들 간의 관계를 지배한다 [5, 6, 10].
|
||||
* 동일한 그룹에 속한 아이디어들은 일관된 논리적 순서에 따라 배열되어야 하며, 무작위로 나열될 경우 독자는 아이디어 간의 관계를 찾기 위해 불필요한 정신적 에너지를 소모하게 된다 [6, 11].
|
||||
* 바바라 민토(Barbara Minto)는 수평적으로 아이디어를 배열하는 네 가지 주요 방법을 제시했다 [6, 9, 12]:
|
||||
1. **연역적 순서 (Deductive Order):** 첫 번째 아이디어가 대전제를 제시하고, 두 번째 아이디어가 소전제를 다루며, 세 번째 아이디어가 결론(Implication)을 도출하는 논리적 흐름이다 [6, 9].
|
||||
2. **시간적/연대기적 순서 (Chronological/Time Order):** 특정 결과를 달성하기 위한 프로세스의 단계나 인과 관계를 시간에 따라 나열한다 [6, 9, 13].
|
||||
3. **구조적 순서 (Structural Order):** 전체를 지리나 부서 등 구성 요소로 분할할 때 사용되며, 이때 각 요소는 [[MECE|MECE]](상호 배제 및 전체 포괄) 원칙을 반드시 충족해야 한다 [6, 12, 14].
|
||||
4. **비교/정도 순서 (Comparative/Degree Order):** 카테고리화된 아이디어들을 중요도나 영향력 등에 따라 순위를 매겨 배열한다 [6, 12, 14].
|
||||
### 매 Vertical logic (Q&A 추적)
|
||||
- **Top-down**: 매 main idea → child supports through Why?/How?/What?
|
||||
- **Bottom-up**: 매 children 의 grouping → parent emergence.
|
||||
- **Test**: 매 each child 의 "answers a Q raised by parent" 의 verify.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Minto Pyramid Principle|Minto Pyramid Principle]], Deductive and Inductive Reasoning, [[MECE Principle|MECE Principle]]
|
||||
- **Projects/Contexts:** [[business|business]] Communication and Presentation, [[Consulting Problem Solving|Consulting Problem Solving]]
|
||||
- **Contradictions/Notes:** 연역적 논리는 그룹 내 아이디어들이 서로 의존적이어서 하나의 전제가 무너지면 전체가 무너지는 반면, 귀납적 논리는 개별 아이디어들이 서로 독립적인 이유들로 구성된다는 차이가 있다 [15, 16]. 경영진이나 바쁜 독자를 대상으로 하는 커뮤니케이션에서는 피라미드의 최상위 핵심 라인(Key Line)에서 연역적 추론보다 귀납적 추론을 사용하는 것이 독자가 더 빠르고 쉽게 이해하도록 돕는 데 유리하다 [16-18].
|
||||
### 매 Horizontal logic (sibling coherence)
|
||||
- **MECE**: 매 mutually exclusive + collectively exhaustive.
|
||||
- **Inductive**: 매 same-type observations → conclusion.
|
||||
- **Deductive**: 매 premise 1 + premise 2 → conclusion (max 4 levels).
|
||||
- **Test**: 매 sibling reorder 시 meaning preserved + no overlap + complete.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 SCQA (Situation-Complication-Question-Answer)
|
||||
- **Situation**: 매 audience-known background.
|
||||
- **Complication**: 매 disrupting force.
|
||||
- **Question**: 매 implicit reader question.
|
||||
- **Answer**: 매 main idea (top of pyramid).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. McKinsey/BCG client deck.
|
||||
2. Executive memo.
|
||||
3. Audit / financial reporting.
|
||||
4. Engineering RFC.
|
||||
5. LLM 의 reasoning trace structuring.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pyramid node tree
|
||||
```python
|
||||
from dataclasses import dataclass, field
|
||||
from typing import Literal
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
@dataclass
|
||||
class PyramidNode:
|
||||
statement: str
|
||||
logic_type: Literal["inductive", "deductive"] = "inductive"
|
||||
children: list["PyramidNode"] = field(default_factory=list)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def vertical_test(self) -> bool:
|
||||
"""Each child must answer Why/How/What raised by self."""
|
||||
return all(self.statement and c.statement for c in self.children)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def horizontal_test(self) -> bool:
|
||||
"""MECE: same logical category, no overlap (heuristic check)."""
|
||||
return len({type(c.statement) for c in self.children}) == 1
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### MECE category check
|
||||
```python
|
||||
def is_mece(items: list[str], categories: dict[str, set[str]]) -> dict:
|
||||
covered = set().union(*categories.values())
|
||||
overlaps = [
|
||||
(a, b) for a in categories for b in categories
|
||||
if a != b and categories[a] & categories[b]
|
||||
]
|
||||
return {
|
||||
"exhaustive": set(items) <= covered,
|
||||
"exclusive": not overlaps,
|
||||
"uncovered": set(items) - covered,
|
||||
"overlaps": overlaps,
|
||||
}
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### Inductive vs deductive selector
|
||||
```python
|
||||
def choose_argument_form(num_premises: int, audience_familiarity: float) -> str:
|
||||
"""Minto: deductive ≤4 levels, only when audience already accepts premises."""
|
||||
if num_premises <= 3 and audience_familiarity > 0.7:
|
||||
return "deductive"
|
||||
return "inductive" # safer default — group similar evidence
|
||||
```
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
### SCQA scaffolder
|
||||
```python
|
||||
def scqa(situation: str, complication: str, question: str, answer: str) -> str:
|
||||
return (f"Situation: {situation}\n"
|
||||
f"Complication: {complication}\n"
|
||||
f"Question: {question}\n"
|
||||
f"Answer (main idea): {answer}")
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Reorder sibling test (horizontal robustness)
|
||||
```python
|
||||
import itertools
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
def reorder_robust(siblings: list[str], judge_meaning: callable) -> bool:
|
||||
"""If meaning unchanged across permutations → horizontal logic holds."""
|
||||
perms = list(itertools.permutations(siblings))[:6]
|
||||
meanings = {judge_meaning(p) for p in perms}
|
||||
return len(meanings) == 1
|
||||
```
|
||||
|
||||
### LLM critique pass
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
client = Anthropic()
|
||||
|
||||
def minto_critique(pyramid_yaml: str) -> str:
|
||||
return client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2000,
|
||||
system=("Audit a Minto pyramid. Flag: (1) children that don't answer the "
|
||||
"Q raised by parent, (2) sibling overlaps (not ME), (3) gaps (not CE), "
|
||||
"(4) deductive chains beyond 4 levels."),
|
||||
messages=[{"role": "user", "content": pyramid_yaml}],
|
||||
).content[0].text
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Executive deck | top-down + SCQA opener |
|
||||
| Bottom-up synthesis | group findings → emerge top |
|
||||
| Diagnostic argument | deductive (≤4 levels) |
|
||||
| Survey / audit findings | inductive (group similar) |
|
||||
| Confused audience | start with main idea (top) |
|
||||
|
||||
**기본값**: 매 top-down 의 vertical structure + inductive 의 horizontal grouping. 매 SCQA 의 opening.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Pyramid Principle]] · [[Structured Thinking]]
|
||||
- 변형: [[Horizontal Logic]] (alias) · [[Vertical Logic]] (alias) · [[MECE]]
|
||||
- 응용: [[Executive Communication]] · [[Consulting Deck]] · [[Audit Reporting]]
|
||||
- Adjacent: [[SCQA]] · [[Issue Tree]] · [[Hypothesis-Driven Problem Solving]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 draft pyramid 의 critique, 매 MECE gap 의 surface, 매 SCQA 의 opening 작성, 매 inductive grouping 의 candidate.
|
||||
**언제 X**: 매 final audience-specific framing — 매 cultural / political nuance, 매 stakeholder dynamics 의 human judgment 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Bottom of pyramid 부터 발표**: 매 audience 의 main idea 도달 전 fatigue.
|
||||
- **Mixed inductive + deductive 의 same level**: 매 horizontal coherence 깨짐.
|
||||
- **5+ siblings**: 매 cognitive overload — 매 7±2 의 lower bound (3-5).
|
||||
- **MECE 만 의 추구**: 매 forced taxonomy 의 distortion — 매 90% 의 MECE 의 sometimes acceptable.
|
||||
- **Deductive 의 5+ levels**: 매 reader cognitive load 폭증 — 매 Minto 의 4-level cap.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Minto "The Pyramid Principle" 3rd ed, McKinsey communication training, Booz Allen 의 SCQA).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — vertical/horizontal axes, MECE, SCQA, Minto pyramid 패턴 추가 |
|
||||
|
||||
@@ -2,90 +2,168 @@
|
||||
id: wiki-2026-0508-hypostatic-abstraction
|
||||
title: Hypostatic Abstraction
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-HYAB-001]
|
||||
aliases: [Hypostasis, Reification, Subjectal Abstraction]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.88
|
||||
tags: [auto-reinforced, hypostatic-abstraction, charles-peirce, semiotics, Logic, Ontology]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [logic, semiotics, philosophy, peirce, abstraction]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: en
|
||||
framework: peircean-logic
|
||||
---
|
||||
|
||||
# [[Hypostatic-Abstraction|Hypostatic-Abstraction]]
|
||||
# Hypostatic Abstraction
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "술어에서 주체로의 도약: '꿀은 달다'라는 성질에서 '단맛(Sweetness)'이라는 독립적 실체를 만들어내듯, 동작이나 상태를 하나의 고정된 개념적 대상(Object)으로 격상시켜 사고의 도구로 삼는 언어와 논리의 연금술."
|
||||
## 매 한 줄
|
||||
> **"매 predicate 의 subject 으로 transformation — 'X is honest' → 'X has honesty'"**. 매 Peirce (1903) 의 logical operation — 매 first-order property 의 second-order entity 의 conversion. 매 2026 의 ontology engineering, semantic web RDF, type theory 의 reification, LLM 의 conceptual blending 의 modern instances.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
실체화 추상(Hypostatic-Abstraction, HOS)은 찰스 퍼스(Charles Peirce)가 제안한 기호학적 개념으로, 속성이나 관계를 독립된 객체로 취급하는 인지 과정을 말합니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **작동 원리**:
|
||||
* "이 사과는 빨갛다"($Predication$) -> "빨강이 이 사과에 있다"($Abstraction$).
|
||||
* 동사(어떠함)를 명사(무엇)로 바꿈으로써, 그 개념을 더 깊이 탐구하거나 다른 개념과 연결할 수 있게 함.
|
||||
2. **왜 중요한가?**:
|
||||
* 인간 지능이 복잡한 현상을 단순한 '데이터 조각'이 아닌 '다룰 수 있는 개념'으로 변환하여 지식 체계를 구축하는 핵심 메커니즘임. ([[Knowledge synthesis|Knowledge synthesis]]의 근간)
|
||||
### 매 정의 (Peirce)
|
||||
- **Operation**: 매 "p(x)" → "x has property P" — 매 P 의 noun-form entity.
|
||||
- **예**:
|
||||
- "honey is sweet" → "honey has sweetness"
|
||||
- "the function returns int" → "the function has return-type int"
|
||||
- "atom is heavy" → "atom has mass"
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거 철학 정책은 이를 단순한 언어적 습관 정책으로 보았으나, 현대 인지 과학 정책은 이를 고차원적 사고를 가능케 하는 '인지적 압축 정책'으로 재평가함(RL Update).
|
||||
- **정책 변화(RL Update)**: 현대 객체 지향 프로그래밍(OOP)이나 디자인 패턴 정책에서 행위(Action)를 객체(Command Object 등)로 만들어 다루는 설계 철학 정책의 뿌리가 됨.
|
||||
### 매 distinction from related
|
||||
- **vs. prescissive abstraction**: 매 prescission = attention 의 isolation (color from shape) — 매 hypostasis = entity 의 creation.
|
||||
- **vs. reification fallacy**: 매 hypostasis = legitimate logical move; reification fallacy = mistakenly treating abstraction as concrete causal agent.
|
||||
- **vs. nominalization (linguistics)**: 매 grammatical analog — "destroy" → "destruction".
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Knowledge synthesis|Knowledge synthesis]], Ontology (온톨로지), [[Analysis|Analysis]], [[Logic|Logic]], [[Concept Mapping|Concept Mapping]]
|
||||
- **Modern Tech/Tools**: Object-oriented programming, Semantic web, Knowledge graphs.
|
||||
---
|
||||
### 매 utility
|
||||
- **Reasoning vehicle**: 매 abstract entity 의 quantification 가능 ("there exists a virtue that...").
|
||||
- **Theory building**: 매 mass, energy, information 의 hypostatic origin.
|
||||
- **Ontology**: 매 OWL class 의 RDF resource 화.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Math: "function f returns int" → "f has signature ℤ→ℤ".
|
||||
2. Physics: "object is hot" → "object has temperature T".
|
||||
3. Law: "act is criminal" → "act has criminality" (mens rea 분석).
|
||||
4. Programming: type inference 의 reification.
|
||||
5. Knowledge graph: predicate → resource.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Predicate to RDF resource (hypostatize)
|
||||
```python
|
||||
from rdflib import Graph, URIRef, Literal, RDF
|
||||
EX = "http://ex.org/"
|
||||
g = Graph()
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
# "Alice is honest" → "Alice has honesty(value=true)"
|
||||
g.add((URIRef(EX + "Alice"), URIRef(EX + "hasVirtue"), URIRef(EX + "Honesty")))
|
||||
g.add((URIRef(EX + "Honesty"), RDF.type, URIRef(EX + "Virtue")))
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Type-level reification (TypeScript)
|
||||
```typescript
|
||||
// Before: "f returns number"
|
||||
function f(x: number): number { return x * 2; }
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
// Hypostatized: extract the type
|
||||
type SignatureOf<F> = F extends (...args: infer A) => infer R ? { args: A; ret: R } : never;
|
||||
type FSig = SignatureOf<typeof f>; // { args: [number]; ret: number }
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Predicate → entity (Peircean diagram)
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
@dataclass
|
||||
class HypostaticAbstraction:
|
||||
original_predicate: str # "X is red"
|
||||
subject_var: str # "X"
|
||||
abstracted_entity: str # "redness"
|
||||
relation: str # "has"
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
def express(self, subject: str) -> tuple[str, str]:
|
||||
return (
|
||||
f"{subject} {self.original_predicate.split(' is ')[1]}", # original
|
||||
f"{subject} {self.relation} {self.abstracted_entity}", # hypostatized
|
||||
)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
h = HypostaticAbstraction("X is red", "X", "redness", "has")
|
||||
print(h.express("the apple")) # ("the apple red", "the apple has redness")
|
||||
```
|
||||
|
||||
### Detect reification fallacy
|
||||
```python
|
||||
def reification_check(claim: str, entity: str) -> bool:
|
||||
"""Flag if abstract entity assigned causal agency."""
|
||||
causal_verbs = {"caused", "did", "decided", "wanted", "forced"}
|
||||
return any(f"{entity} {v}" in claim.lower() for v in causal_verbs)
|
||||
|
||||
reification_check("Inflation caused the recession", "inflation") # True (suspect)
|
||||
```
|
||||
|
||||
### Knowledge graph property reification
|
||||
```turtle
|
||||
# Direct edge: <Alice> <employs> <Bob>
|
||||
# Reified (allow metadata on the edge):
|
||||
:edge1 a rdf:Statement ;
|
||||
rdf:subject :Alice ;
|
||||
rdf:predicate :employs ;
|
||||
rdf:object :Bob ;
|
||||
:startDate "2024-01-15" ;
|
||||
:salary 90000 .
|
||||
```
|
||||
|
||||
### LLM hypostatization assistant
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
client = Anthropic()
|
||||
|
||||
def hypostatize(claim: str) -> str:
|
||||
return client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=500,
|
||||
system=("Apply Peircean hypostatic abstraction: convert the predicate "
|
||||
"into a subject-form entity. Then list questions you can now "
|
||||
"ask of that entity."),
|
||||
messages=[{"role": "user", "content": claim}],
|
||||
).content[0].text
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | When to hypostatize |
|
||||
|---|---|
|
||||
| Theory building, want to quantify property | yes |
|
||||
| Need ontology / KG class | yes |
|
||||
| Reasoning about types, signatures | yes |
|
||||
| Granting causal agency to abstraction | NO (reification fallacy) |
|
||||
| Eliminate redundancy in logic | yes (factor predicate) |
|
||||
|
||||
**기본값**: 매 hypostatize 의 explicit + reversible. 매 abstract entity 의 causal agent 화 X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Peircean Semiotics]] · [[Logical Abstraction]]
|
||||
- 변형: [[Prescissive Abstraction]] · [[Reification]] · [[Nominalization]]
|
||||
- 응용: [[Ontology Engineering]] · [[Type Theory]] · [[RDF Reification]]
|
||||
- Adjacent: [[Charles Sanders Peirce]] · [[Conceptual Blending]] · [[Knowledge Graph]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 ontology class 의 candidate 의 surface, 매 vague claim 의 quantifiable property 의 reformulation, 매 nominalization 의 unwind.
|
||||
**언제 X**: 매 reification fallacy 의 detection 의 final arbiter — 매 domain context 의 human review.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Reification fallacy**: 매 abstract entity 의 causal agent 의 treatment ("inflation decided to rise"). 매 actual mechanism 의 obscure.
|
||||
- **Hypostatic explosion**: 매 every adjective 의 entity 화 — 매 ontology bloat.
|
||||
- **Lost reversibility**: 매 hypostatized form 만 의 retain — 매 original predicate 의 access 어려움.
|
||||
- **Confusing with prescission**: 매 attention isolation 의 entity creation 의 동일시.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Peirce CP 4.235, 5.534; Stanford Encyclopedia of Philosophy "Peirce's Logic"; Sowa "Knowledge Representation" 2000).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Peircean operation, RDF/type reification, fallacy distinction 추가 |
|
||||
|
||||
@@ -2,65 +2,196 @@
|
||||
id: wiki-2026-0508-improvisation
|
||||
title: Improvisation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Improv, Adaptive Response, Spontaneous Decision-Making]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
source_trust_level: B
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [meta, decision-making, agentic, exploration]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: general
|
||||
---
|
||||
|
||||
# [[임시변통]]
|
||||
# Improvisation
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
임시변통은 한정된 재료와 도구를 활용하여 당면한 문제를 수습하고 해결하는 능력을 의미하며, '브리콜라주(bricolage)'라는 개념과 맞닿아 있습니다 [1]. 이는 긍정력을 바탕으로 과감하게 목표를 추진하는 조직의 행동력과 직결됩니다 [1, 2]. 위기 상황에서 구성원들이 창조적이고 유연하게 대처할 수 있게 함으로써 기업이 리질리언스(회복탄력성)를 확보하는 데 핵심적인 역할을 합니다 [1, 2].
|
||||
## 매 한 줄
|
||||
> **"매 plan 의 die 매 first contact, 매 improv 매 take over"**. Improvisation 매 real-time adaptive decision-making 매 incomplete information 매 unfolding situation. 2026 LLM agents 매 nontrivial improv capability 의 exhibit — 매 tool failure / unexpected output 의 recover 가능.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **브리콜라주의 개념과 임시변통**: '브리콜라주'는 '여러 가지 일에 손대기' 또는 '수리'로 번역되며, 이를 수행하는 사람을 일컫는 '브리콜뢰르(bricoleur)'는 한정된 재료와 도구를 이용하여 임시변통에 능통한 사람을 의미합니다 [1].
|
||||
* **조직문화와 리질리언스(Resilience)의 원동력**: 창조적이고 유연한 기업문화는 이러한 브리콜라주 역량을 육성하는 토대가 됩니다 [1]. 기업 내에 임시변통의 능력이 배양되면, 예기치 못한 혼란 속에서도 기업이 무너지지 않고 정상적으로 작동할 수 있는 리질리언스를 갖추게 됩니다 [1, 2].
|
||||
* **목표 추진력과 선제적 행동**: 임시변통은 기업의 목표 추진력, 즉 '행동력'으로 발현됩니다 [2]. 위기 상황 속에서 조직 구성원들이 혁신적인 해결책을 강구하고, 창조적이고 유연하며 선제적으로 대응할 수 있도록 이끌어 줍니다 [2].
|
||||
* **UPS의 임시변통 적용 사례**: 배송전문기업 UPS는 신호등 고장이나 폭풍우 같은 문제가 생겼을 때 어떻게 해결할지 항상 고민하는 문화를 통해 브리콜라주 역량을 키웠습니다 [1, 2]. 1992년 허리케인 앤드루로 인해 막대한 피해가 발생했을 때, UPS 직원들은 피해가 없는 지역에서 물품을 분류하고 차에서 생활하는 이재민들에게까지 제시간에 물건을 배달하는 임시변통 능력을 발휘했습니다 [2]. 이를 통해 대형 재해 이후에도 정상적인 업무 수행이 가능했으며, 직원들이 지속적으로 목적의식을 가질 수 있었습니다 [2].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
소스에 관련 정보가 부족합니다.
|
||||
### 매 Components of improv
|
||||
- **Situation awareness**: 매 current state 의 fast read.
|
||||
- **Repertoire**: 매 prelearned moves / patterns.
|
||||
- **Risk gauge**: 매 reversible vs irreversible 의 distinguish.
|
||||
- **Commitment**: 매 hesitation 의 X — 매 decide 의 act.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-04*
|
||||
### 매 Plan vs Improv spectrum
|
||||
- **Pure plan**: scripted, deterministic, fragile.
|
||||
- **Plan + improv**: skeleton plan + adaptive details (best for most tasks).
|
||||
- **Pure improv**: jazz solo, emergency response.
|
||||
- 매 majority production system 매 plan-with-improv-edges.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 LLM agent improvisation
|
||||
- 매 tool returns unexpected error → reformulate vs fail.
|
||||
- 매 user gives ambiguous instruction → ask vs guess vs proceed.
|
||||
- 매 token budget 매 exhaust → compress vs truncate vs delegate.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 응용
|
||||
1. Incident response (production outage).
|
||||
2. Live coding session (pair programming).
|
||||
3. LLM agent error recovery.
|
||||
4. Customer support edge cases.
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 1: Repertoire of moves
|
||||
```python
|
||||
from typing import Callable
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
class ImprovKit:
|
||||
"""매 prelearned moves — 매 situation 의 match 의 dispatch."""
|
||||
def __init__(self):
|
||||
self.moves: dict[str, Callable] = {}
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def register(self, situation: str, move: Callable):
|
||||
self.moves[situation] = move
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def respond(self, context: dict):
|
||||
for situation, move in self.moves.items():
|
||||
if matches(situation, context):
|
||||
return move(context)
|
||||
return self.default_move(context)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
def default_move(self, context):
|
||||
return {"action": "ask_for_clarification"}
|
||||
```
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** *(TODO: 최소 2개)*
|
||||
- **Opposite / Trade-off:** *(TODO)*
|
||||
- **Raw Source:** 직접 입력
|
||||
### Pattern 2: Reversibility check before commit
|
||||
```python
|
||||
def is_reversible(action: dict) -> bool:
|
||||
irreversible = {"delete_file", "send_email", "db_drop", "git_push_force"}
|
||||
return action["type"] not in irreversible
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def improv_decide(action: dict, confidence: float) -> str:
|
||||
if is_reversible(action):
|
||||
return "act" # 매 try 의 cheap
|
||||
if confidence > 0.95:
|
||||
return "act"
|
||||
return "pause_and_verify"
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 3: LLM error recovery loop
|
||||
```python
|
||||
def call_with_improv(client, prompt: str, max_retries: int = 3):
|
||||
history = [{"role": "user", "content": prompt}]
|
||||
for attempt in range(max_retries):
|
||||
try:
|
||||
return client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2000,
|
||||
messages=history,
|
||||
)
|
||||
except RateLimitError:
|
||||
time.sleep(2 ** attempt)
|
||||
except OverloadedError:
|
||||
# 매 fallback 매 smaller model
|
||||
return client.messages.create(
|
||||
model="claude-haiku-4-7",
|
||||
max_tokens=2000,
|
||||
messages=history,
|
||||
)
|
||||
except Exception as e:
|
||||
history.append({
|
||||
"role": "user",
|
||||
"content": f"Previous attempt errored: {e}. Try a different approach.",
|
||||
})
|
||||
raise RuntimeError("매 improv 의 exhaust")
|
||||
```
|
||||
|
||||
### Pattern 4: Yes-and (improv principle)
|
||||
```python
|
||||
def yes_and(user_input: str, context: dict) -> str:
|
||||
"""매 improv 'Yes, and' — accept premise, build on it."""
|
||||
return f"Acknowledged: {user_input}. Building on this: {extend(user_input, context)}."
|
||||
|
||||
# 매 LLM system prompt 의 embed:
|
||||
SYSTEM = """매 user 매 partial information 의 give. 매 yes-and 의 follow:
|
||||
1. Accept what they said as fact (yes).
|
||||
2. Add useful structure (and).
|
||||
3. Avoid 'no, that's wrong' unless 매 hard contradiction."""
|
||||
```
|
||||
|
||||
### Pattern 5: Bounded improv (safety rail)
|
||||
```python
|
||||
class BoundedImprov:
|
||||
def __init__(self, max_actions: int = 5, allowed_ops: set = None):
|
||||
self.max_actions = max_actions
|
||||
self.allowed_ops = allowed_ops or {"read", "search", "summarize"}
|
||||
self.actions_taken = 0
|
||||
|
||||
def attempt(self, op: str, *args):
|
||||
if self.actions_taken >= self.max_actions:
|
||||
raise RuntimeError("매 budget exceed — escalate 의 human")
|
||||
if op not in self.allowed_ops:
|
||||
raise PermissionError(f"매 {op} 매 not in improv allowlist")
|
||||
self.actions_taken += 1
|
||||
return execute(op, *args)
|
||||
```
|
||||
|
||||
### Pattern 6: Postmortem of improv
|
||||
```python
|
||||
def improv_log_entry(situation: str, move: str, outcome: str) -> dict:
|
||||
return {
|
||||
"ts": time.time(),
|
||||
"situation": situation,
|
||||
"move_chosen": move,
|
||||
"outcome": outcome,
|
||||
"would_repeat": outcome in ("success", "partial_success"),
|
||||
"alternatives_considered": [],
|
||||
}
|
||||
|
||||
# 매 weekly review 매 add successful patterns 의 ImprovKit.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Reversible action, < 1min | Pure improv. |
|
||||
| Irreversible, high stakes | Plan first — improv 의 X. |
|
||||
| Ambiguous user request | Yes-and + clarifying question. |
|
||||
| LLM tool error | Bounded retry + reformulation. |
|
||||
| Production incident | Plan (runbook) + improv on edges. |
|
||||
|
||||
**기본값**: 매 80/20 — 80% plan, 20% improv 매 unforeseen edges. 매 irreversible 매 strict plan only.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Decision-Making]] · [[Adaptive-Systems]]
|
||||
- 변형: [[Yes-And]] · [[Heuristic-Decision]] · [[OODA-Loop]]
|
||||
- 응용: [[Incident-Response]] · [[LLM-Agent-Recovery]] · [[Pair-Programming]]
|
||||
- Adjacent: [[Reversibility]] · [[Risk-Management]] · [[Bounded-Rationality]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Tool error recovery, ambiguous user input handling, edge cases not covered by training data, multi-turn agent self-correction.
|
||||
**언제 X**: Compliance-critical workflow (deterministic pipeline only), safety-critical irreversible action.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Improv on irreversible action**: 매 prod DB drop 의 wing 의 X.
|
||||
- **No repertoire**: 매 from-scratch every situation — slow + inconsistent.
|
||||
- **No reversibility check**: 매 acted 매 then-realized too late.
|
||||
- **Ego improv**: refuse 의 ask for help — 매 stuck-but-improv-ing.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: Keith Johnstone "Impro" (1979), Karl Weick "Organizing for Reliability" (1987), OODA loop (Boyd).
|
||||
- 신뢰도 B (academic-soft + applied agentic literature).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with LLM agent improv patterns and reversibility framework |
|
||||
|
||||
@@ -1,80 +1,195 @@
|
||||
---
|
||||
id: wiki-2026-0508-inference-coupled-persistence
|
||||
title: Inference Coupled Persistence
|
||||
title: Inference-Coupled Persistence
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [ICP, Inference-Time Memory, Coupled Persistence]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [llm, memory, inference, kv-cache, persistence]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: vllm
|
||||
---
|
||||
|
||||
# Inference-Coupled Persistence (추론 결합 지속성)
|
||||
# Inference-Coupled Persistence
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Inference-Coupled Persistence는 에이전트가 단순히 작업 결과를 저장하는 것을 넘어, 작업이 끝난 후 모델의 추론(Inference) 능력을 활용하여 작업의 성공/실패 요인을 분석하고 향후 재사용 가능한 절차적 지식이나 에피소드 기억으로 요약하여 영구 저장소에 기록하는 기술이다. 이는 에이전트가 경험으로부터 스스로 학습하고 진화하게 만드는 자가 발전(Self-improvement)의 핵심 메커니즘이다.
|
||||
## 매 한 줄
|
||||
> **"매 KV-cache 의 disk 의 spill 매 conversation 의 resume"**. Inference-Coupled Persistence (ICP) 매 LLM serving system 의 inference state (KV-cache, attention states) 의 durable storage 의 couple 매 pattern. 2026 vLLM 0.7+ / SGLang 매 native support — long conversations cost-effective.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **자가 분석 (Post-hoc Analysis)**: 작업 완료 후 에이전트는 "무엇이 성공했는가?", "어떤 장애물이 있었는가?", "다음에 이 작업을 한다면 무엇을 다르게 할 것인가?"를 스스로 질문하고 답을 생성한다.
|
||||
* **스킬 라이브러리 (Skill Synthesis)**: 특정 문제 해결 과정을 일반화된 '스킬'로 변환하여 저장한다. 예를 들어, 특정 라이브러리의 버그를 해결한 과정을 기록하여 다음에 유사한 상황에서 검색 가능하게 만든다.
|
||||
* **에피소드 기억 (Episodic Memory)**: 작업의 전체 궤적(Trajectory) 중 핵심적인 결정 순간과 그 이유를 추출하여 저장함으로써, 긴 대화 이력을 모두 보관할 필요 없이 핵심 맥락을 보존한다.
|
||||
* **쓰기 트리거 정책 (Write-trigger Policy)**: 모든 정보를 저장하면 노이즈가 발생하므로, 유의미한 발견이 있거나 작업이 완료된 시점에만 추론을 통한 저장을 실행한다.
|
||||
* **품질 게이트 (Quality-gate)**: 저장되기 전에 생성된 지식이 정확한지, 혹은 보안상 위험이 없는지 검증하는 단계를 거친다.
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **추론 비용**: 저장을 위해 추가적인 모델 호출이 필요하므로 토큰 소모와 시간이 발생한다.
|
||||
* **메모리 중독 (Memory Poisoning)**: 모델이 자신의 실패를 잘못 분석하거나 환각(Hallucination)을 지식으로 저장할 경우, 에이전트의 전체 지능이 오염될 수 있다.
|
||||
* **요약 편향 (Summary Drift)**: 여러 번의 분석과 요약을 거치면서 원본 경험의 중요한 디테일이 사라지고 왜곡될 수 있다.
|
||||
### 매 Why ICP
|
||||
- 매 1M token context 의 KV-cache 매 ~100GB GPU memory 의 consume.
|
||||
- 매 conversation idle 매 hours / days — GPU memory 매 hold cost-prohibitive.
|
||||
- ICP: idle 시 disk 의 evict, resume 시 reload — 매 5-50x cost reduction.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
* [[Agent Memory System|Agent Memory System]]
|
||||
* 연결 이유: 추론 결합 지속성이 실질적으로 지식을 공급하는 대상 시스템이다.
|
||||
* [[S-component (State Store)|S-component (State Store)]]
|
||||
* 연결 이유: 분석된 지식이 물리적으로 저장되는 하네스의 구성 요소이다.
|
||||
* Reflexion
|
||||
* 연결 이유: 작업 중 혹은 후에 스스로를 돌아보고 개선하는 유사한 추론 패턴이다.
|
||||
### 매 Storage tiers
|
||||
- **L0 (HBM)**: active inference, < 1ms access.
|
||||
- **L1 (CPU RAM)**: 매 minutes idle, ~10ms reload.
|
||||
- **L2 (NVMe)**: 매 hours idle, ~100ms reload.
|
||||
- **L3 (Object store / S3)**: 매 days idle, ~1-5s reload.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 자기 분석 결과가 정확한지 확인하기 위해, 별도의 '평가자 에이전트(Evaluator Agent)'를 통한 교차 검증은 어느 정도의 비용 효율성을 갖는가?
|
||||
* 수백 개의 성공/실패 에피소드 중 현재 작업에 가장 큰 영감을 줄 수 있는 '유사 사례'를 검색하기 위한 고차원 임베딩 전략은 무엇인가?
|
||||
* 학습된 지식이 시간이 지나 프로젝트 사양 변경으로 인해 틀린 정보가 되었을 때(Obsolescence), 이를 자동으로 폐기하거나 수정하는 트리거는 무엇인가?
|
||||
### 매 Coupling guarantees
|
||||
- **Bit-exact resume**: 매 KV-cache 매 quantization-aware serialization.
|
||||
- **Causal consistency**: 매 token N 의 KV 매 strictly token <N 의 reflect.
|
||||
- **Atomic checkpoint**: partial-write 의 detect 의 crash recovery.
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 코딩 작업 후 "이 프로젝트의 빌드 에러 해결법"이라는 문서를 자동으로 생성하여 `10_Wiki/00_Raw`에 저장하고, 다음에 빌드 에러 발생 시 이를 먼저 검색하도록 한다.
|
||||
* **System Design:** 하네스의 L-component에 `onTaskComplete` 훅을 설정하여, 작업 성공 시 자동으로 'Experience Synthesis' 프롬프트를 실행하도록 설계한다.
|
||||
### 매 응용
|
||||
1. Long-running coding agent (multi-day session).
|
||||
2. Customer support bot (hours-long conversation history).
|
||||
3. Research assistant (multi-week project context).
|
||||
4. Multi-tenant LLM serving (100K concurrent idle sessions).
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
## 💻 패턴
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### Pattern 1: vLLM KV-cache offload (2026)
|
||||
```python
|
||||
from vllm import LLM, SamplingParams
|
||||
from vllm.engine.arg_utils import EngineArgs
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
engine_args = EngineArgs(
|
||||
model="meta-llama/Llama-3.3-70B-Instruct",
|
||||
enable_prefix_caching=True,
|
||||
kv_cache_dtype="fp8",
|
||||
cpu_offload_gb=200, # CPU RAM tier
|
||||
swap_space=400, # NVMe tier (GB)
|
||||
block_size=32,
|
||||
)
|
||||
llm = LLM.from_engine_args(engine_args)
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 2: Conversation checkpoint
|
||||
```python
|
||||
import torch
|
||||
from pathlib import Path
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
class ConversationCheckpoint:
|
||||
def __init__(self, store_dir: Path):
|
||||
self.store = store_dir
|
||||
self.store.mkdir(exist_ok=True, parents=True)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def save(self, conv_id: str, kv_blocks: list[torch.Tensor], tokens: list[int]):
|
||||
path = self.store / f"{conv_id}.pt"
|
||||
tmp = path.with_suffix(".tmp")
|
||||
torch.save({
|
||||
"kv": [b.cpu() for b in kv_blocks],
|
||||
"tokens": tokens,
|
||||
"version": 2,
|
||||
}, tmp)
|
||||
tmp.rename(path) # atomic
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def load(self, conv_id: str) -> dict | None:
|
||||
path = self.store / f"{conv_id}.pt"
|
||||
if not path.exists():
|
||||
return None
|
||||
return torch.load(path, map_location="cuda")
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 3: Tiered eviction policy
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
from time import time
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
@dataclass
|
||||
class Session:
|
||||
id: str
|
||||
last_access: float
|
||||
size_gb: float
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
def evict_tier(sessions: list[Session], capacity_gb: float) -> list[Session]:
|
||||
"""매 LRU 의 evict — return list of (session, target_tier)."""
|
||||
sessions.sort(key=lambda s: s.last_access)
|
||||
used = sum(s.size_gb for s in sessions)
|
||||
evicted = []
|
||||
now = time()
|
||||
for s in sessions:
|
||||
if used <= capacity_gb:
|
||||
break
|
||||
idle_min = (now - s.last_access) / 60
|
||||
if idle_min < 5:
|
||||
target = "HBM"
|
||||
elif idle_min < 60:
|
||||
target = "CPU"
|
||||
elif idle_min < 1440:
|
||||
target = "NVMe"
|
||||
else:
|
||||
target = "S3"
|
||||
evicted.append((s, target))
|
||||
used -= s.size_gb
|
||||
return evicted
|
||||
```
|
||||
|
||||
### Pattern 4: Resume with prefix matching
|
||||
```python
|
||||
def resume_with_prefix(checkpoint: dict, new_prompt: str, tokenizer) -> tuple[list, list]:
|
||||
"""매 checkpoint 의 prefix 의 reuse — 매 prefix mismatch 의 from-scratch."""
|
||||
saved_tokens = checkpoint["tokens"]
|
||||
new_tokens = tokenizer.encode(new_prompt)
|
||||
common = 0
|
||||
for i in range(min(len(saved_tokens), len(new_tokens))):
|
||||
if saved_tokens[i] != new_tokens[i]:
|
||||
break
|
||||
common = i + 1
|
||||
if common == 0:
|
||||
return [], new_tokens
|
||||
kept_kv = [k[:, :common] for k in checkpoint["kv"]]
|
||||
return kept_kv, new_tokens[common:]
|
||||
```
|
||||
|
||||
### Pattern 5: Quantized serialization
|
||||
```python
|
||||
def serialize_kv_int8(kv: torch.Tensor) -> tuple[bytes, dict]:
|
||||
"""매 fp16 KV 의 int8 의 quantize — 매 50% storage save."""
|
||||
scale = kv.abs().amax() / 127
|
||||
q = (kv / scale).round().clamp(-128, 127).to(torch.int8)
|
||||
return q.numpy().tobytes(), {"scale": scale.item(), "shape": list(q.shape)}
|
||||
|
||||
def deserialize_kv_int8(data: bytes, meta: dict) -> torch.Tensor:
|
||||
import numpy as np
|
||||
arr = np.frombuffer(data, dtype=np.int8).reshape(meta["shape"])
|
||||
return torch.from_numpy(arr).to(torch.float16) * meta["scale"]
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Conversation < 5min idle | HBM 만. |
|
||||
| Long conversation, hours idle | NVMe tier. |
|
||||
| Multi-day project context | S3 + prefix cache. |
|
||||
| Cost-sensitive multi-tenant | Aggressive 4-tier ICP. |
|
||||
| Latency-sensitive (< 10ms) | HBM only — ICP 의 X. |
|
||||
|
||||
**기본값**: 4-tier (HBM → CPU → NVMe → S3) 매 LRU eviction, fp8 KV-cache, prefix caching enabled.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[KV-Cache]] · [[LLM-Serving]]
|
||||
- 변형: [[Prefix-Caching]] · [[Paged-Attention]]
|
||||
- 응용: [[Long-Context-LLM]] · [[Multi-Turn-Agents]] · [[vLLM]]
|
||||
- Adjacent: [[Continuous-Batching]] · [[Speculative-Decoding]] · [[FlashAttention]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 production LLM serving 매 multi-hour conversations, 매 cost optimization, 매 multi-tenant 100K+ sessions.
|
||||
**언제 X**: Single-shot inference (no persistence needed), strict-latency RT systems (< 10ms first-token).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Naive pickle of KV**: 매 quantization-unaware — 5-10x bigger than needed.
|
||||
- **No atomic write**: crash 의 corrupted checkpoint 의 unrecoverable.
|
||||
- **Per-token checkpoint**: 매 IOPS storm — batch 의 N tokens.
|
||||
- **Resume without prefix check**: silent correctness bug.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: vLLM 0.7 docs (2025), SGLang RadixAttention paper (2024), Mooncake architecture (2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with vLLM 2026 patterns, tiered eviction, quantized serialization |
|
||||
|
||||
@@ -2,87 +2,244 @@
|
||||
id: wiki-2026-0508-inheritance-and-polymorphism
|
||||
title: Inheritance and Polymorphism
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [CS-OOP-001]
|
||||
aliases: [OOP Inheritance, Subtype Polymorphism, Method Dispatch]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [programming, oop, inheritance, polymorphism, software-design]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [oop, programming-language, type-theory, polymorphism]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: multi
|
||||
framework: oop
|
||||
---
|
||||
|
||||
# Inheritance and Polymorphism (상속과 다형성)
|
||||
# Inheritance and Polymorphism
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "부모의 자산을 물려받아 지식을 확장하고, 하나의 이름으로 수만 가지의 다채로운 행동을 수행하라" — 코드의 재사용성을 극대화하는 상속(Inheritance)과, 동일한 메시지에 대해 객체마다 다르게 반응하도록 설계하는 다형성(Polymorphism)을 통해 유연하고 확장 가능한 시스템을 구축하는 객체 지향의 핵심 원리.
|
||||
## 매 한 줄
|
||||
> **"매 inheritance 의 mechanism — polymorphism 의 outcome"**. 매 inheritance 의 code reuse + 매 is-a 의 subtype relationship; 매 polymorphism 의 same interface 의 different behavior. 매 modern 2026 의 view 의 "favor composition over inheritance" 의 default — Go/Rust 의 inheritance-free, but interface-polymorphism 의 universal. 매 LLM-generated code 의 over-inheritance 의 common antipattern.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Abstraction and Specialization" — 공통된 특성을 추상 클래스나 인터페이스로 정의하고, 이를 상속받아 구체적인 기능을 구현함으로써 복잡한 시스템의 계층 구조를 체계화하는 설계 패턴.
|
||||
- **핵심 개념:**
|
||||
- **Inheritance:** 기존 클래스(Parent)의 필드와 메서드를 새로운 클래스(Child)가 물려받아 확장. "Is-a" 관계 형성.
|
||||
- **Polymorphism:** 하나의 변수나 메서드가 여러 타입을 가질 수 있는 성질. 오버라이딩(Overriding)과 오버로딩(Overloading)을 통해 실현.
|
||||
- **의의:** 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높여, 코드 한 곳을 수정했을 때 시스템 전체에 미치는 악영향을 최소화함.
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 깊은 상속 계층이 오히려 유지보수를 어렵게 만든다는 반성 하에, 최근에는 "상속보다 합성(Composition over Inheritance)"을 우선시하는 설계 철학이 대두됨.
|
||||
- **정책 변화:** Antigravity 프로젝트의 에이전트 스킬 설계 시, 기본 기능을 상속받되 구체적인 동작은 다형성을 활용하여 각 에이전트의 특성에 맞춰 구현하는 '플러그인 아키텍처'를 준수함.
|
||||
### 매 inheritance 의 종류
|
||||
- **Single inheritance**: 매 one parent class (Java, Kotlin, C#).
|
||||
- **Multiple inheritance**: 매 N parents — diamond problem (C++, Python via MRO).
|
||||
- **Mixins / traits**: 매 horizontal composition (Rust traits, Scala traits, Python mixins).
|
||||
- **Prototype-based**: 매 object → object delegation (JavaScript, Lua).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Software-Architecture-Patterns, [[Functional-Programming|Functional-Programming]], [[Domain-Driven-Design-DDD|Domain-Driven-Design-DDD]],[[_system|system]]-Design-for-AI-Scale
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Inheritance-and-Polymorphism.md
|
||||
### 매 polymorphism 의 종류
|
||||
- **Subtype polymorphism**: 매 subclass 의 parent 의 substitute (Liskov LSP).
|
||||
- **Parametric polymorphism (generics)**: 매 type parameter — `List<T>`.
|
||||
- **Ad-hoc polymorphism (overloading)**: 매 same name 의 different signatures.
|
||||
- **Row polymorphism**: 매 structural — TypeScript / OCaml 의 records.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. **Domain hierarchy**: 매 `Animal → Dog/Cat`. Often overused.
|
||||
2. **Plugin architecture**: 매 `Plugin` interface + N implementations.
|
||||
3. **AST transformation**: 매 `Visitor` pattern + node hierarchy.
|
||||
4. **Strategy pattern**: 매 interchangeable algorithms via interface.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 매 subtype polymorphism (Python ABC + Liskov)
|
||||
```python
|
||||
from abc import ABC, abstractmethod
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
class Shape(ABC):
|
||||
@abstractmethod
|
||||
def area(self) -> float: ...
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
class Circle(Shape):
|
||||
def __init__(self, r: float): self.r = r
|
||||
def area(self) -> float: return 3.14159 * self.r ** 2
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
class Rectangle(Shape):
|
||||
def __init__(self, w: float, h: float): self.w, self.h = w, h
|
||||
def area(self) -> float: return self.w * self.h
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
# Polymorphic use — caller knows nothing about concrete type
|
||||
def total_area(shapes: list[Shape]) -> float:
|
||||
return sum(s.area() for s in shapes)
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
print(total_area([Circle(2), Rectangle(3, 4)])) # 24.566...
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 매 composition over inheritance (modern preferred)
|
||||
```python
|
||||
# ❌ Inheritance-heavy — fragile
|
||||
class Animal:
|
||||
def move(self): print("move")
|
||||
class Bird(Animal):
|
||||
def fly(self): print("fly")
|
||||
class Penguin(Bird): # Penguin 의 fly X — Liskov violation
|
||||
def fly(self): raise NotImplementedError
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# ✅ Composition-based — flexible
|
||||
from dataclasses import dataclass
|
||||
from typing import Protocol
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
class Mover(Protocol):
|
||||
def move(self) -> str: ...
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
@dataclass
|
||||
class Walker:
|
||||
def move(self) -> str: return "walk"
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
@dataclass
|
||||
class Flyer:
|
||||
def move(self) -> str: return "fly"
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@dataclass
|
||||
class Animal2:
|
||||
name: str
|
||||
mover: Mover # plug in capability — no inheritance
|
||||
|
||||
penguin = Animal2("Penguin", Walker())
|
||||
sparrow = Animal2("Sparrow", Flyer())
|
||||
print(penguin.mover.move(), sparrow.mover.move())
|
||||
```
|
||||
|
||||
### 매 generic parametric polymorphism (TypeScript)
|
||||
```typescript
|
||||
// Same code for any T
|
||||
function head<T>(xs: T[]): T | undefined {
|
||||
return xs[0];
|
||||
}
|
||||
|
||||
const n: number | undefined = head([1, 2, 3]);
|
||||
const s: string | undefined = head(["a", "b"]);
|
||||
|
||||
// Bounded generic — T must be Comparable
|
||||
interface Comparable<T> { compareTo(other: T): number; }
|
||||
|
||||
function max<T extends Comparable<T>>(xs: T[]): T {
|
||||
return xs.reduce((acc, x) => x.compareTo(acc) > 0 ? x : acc);
|
||||
}
|
||||
```
|
||||
|
||||
### 매 trait-based polymorphism (Rust — no inheritance)
|
||||
```rust
|
||||
trait Area {
|
||||
fn area(&self) -> f64;
|
||||
}
|
||||
|
||||
struct Circle { r: f64 }
|
||||
struct Square { side: f64 }
|
||||
|
||||
impl Area for Circle {
|
||||
fn area(&self) -> f64 { 3.14159 * self.r * self.r }
|
||||
}
|
||||
impl Area for Square {
|
||||
fn area(&self) -> f64 { self.side * self.side }
|
||||
}
|
||||
|
||||
// Static dispatch (zero-cost generics)
|
||||
fn print_area_static<T: Area>(s: &T) {
|
||||
println!("{}", s.area());
|
||||
}
|
||||
|
||||
// Dynamic dispatch (vtable)
|
||||
fn print_area_dyn(s: &dyn Area) {
|
||||
println!("{}", s.area());
|
||||
}
|
||||
|
||||
fn main() {
|
||||
let shapes: Vec<Box<dyn Area>> = vec![
|
||||
Box::new(Circle { r: 2.0 }),
|
||||
Box::new(Square { side: 3.0 }),
|
||||
];
|
||||
for s in &shapes { print_area_dyn(s.as_ref()); }
|
||||
}
|
||||
```
|
||||
|
||||
### 매 visitor pattern (AST traversal)
|
||||
```python
|
||||
from dataclasses import dataclass
|
||||
from typing import Union
|
||||
|
||||
# AST hierarchy
|
||||
@dataclass
|
||||
class Num: value: float
|
||||
@dataclass
|
||||
class Add: left: "Expr"; right: "Expr"
|
||||
@dataclass
|
||||
class Mul: left: "Expr"; right: "Expr"
|
||||
|
||||
Expr = Union[Num, Add, Mul]
|
||||
|
||||
# Polymorphic dispatch via match (Python 3.10+)
|
||||
def evaluate(e: Expr) -> float:
|
||||
match e:
|
||||
case Num(v): return v
|
||||
case Add(l, r): return evaluate(l) + evaluate(r)
|
||||
case Mul(l, r): return evaluate(l) * evaluate(r)
|
||||
|
||||
# (3 + 4) * 5
|
||||
print(evaluate(Mul(Add(Num(3), Num(4)), Num(5)))) # 35
|
||||
```
|
||||
|
||||
### 매 LSP-violation 의 detector (mypy + tests)
|
||||
```python
|
||||
# Runtime LSP check — for each subclass override, parameter contravariant + return covariant
|
||||
import inspect
|
||||
from typing import get_type_hints
|
||||
|
||||
def check_lsp(parent: type, child: type) -> list[str]:
|
||||
issues = []
|
||||
for name in dir(parent):
|
||||
if name.startswith("_") or not callable(getattr(parent, name)):
|
||||
continue
|
||||
try:
|
||||
p_hints = get_type_hints(getattr(parent, name))
|
||||
c_hints = get_type_hints(getattr(child, name))
|
||||
except Exception:
|
||||
continue
|
||||
# Return type must be subtype of parent's return
|
||||
if "return" in p_hints and "return" in c_hints:
|
||||
if not issubclass(c_hints["return"], p_hints["return"]):
|
||||
issues.append(f"{child.__name__}.{name}: return type widens parent")
|
||||
return issues
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 is-a 의 stable | Inheritance OK — keep depth ≤ 2 |
|
||||
| 매 has-a / can-do | Composition + protocol/interface |
|
||||
| 매 cross-cutting (logging, metrics) | Decorator / mixin / aspect |
|
||||
| 매 algorithm variants | Strategy pattern (composition) |
|
||||
| 매 type-safe collections | Parametric generics (`List<T>`) |
|
||||
| 매 closed AST / variant data | Sum types + pattern match (Rust enum, Scala sealed) |
|
||||
|
||||
**기본값**: 매 composition + interface — inheritance 의 only when 명확 is-a + LSP-honoring.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Object-Oriented Programming (OOP)]] · [[Type Theory]]
|
||||
- 변형: [[Subtype Polymorphism]] · [[Parametric Polymorphism]] · [[Ad-hoc Polymorphism]]
|
||||
- 응용: [[Strategy Pattern]] · [[Visitor Pattern]] · [[Plugin Architecture]]
|
||||
- Adjacent: [[Liskov Substitution Principle]] · [[Composition over Inheritance]] · [[Duck Typing]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 boilerplate 의 generation (interface + N impls) / 매 LSP audit / 매 inheritance-to-composition refactor.
|
||||
**언제 X**: 매 deep inheritance design — 매 LLM 의 over-inherit 의 tendency. Manual review 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **매 deep inheritance**: 매 4+ levels — fragile base class problem.
|
||||
- **매 LSP violation**: 매 subclass 의 throws on parent-supported method (Penguin.fly).
|
||||
- **매 inheritance for code reuse only**: 매 not is-a — use composition.
|
||||
- **매 god parent class**: 매 parent 의 every responsibility — SRP violation.
|
||||
- **매 multiple inheritance 의 diamond ignore**: 매 MRO 의 surprise behavior.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Gamma et al. *Design Patterns* 1994; Liskov & Wing *A Behavioral Notion of Subtyping* 1994; Effective Java Item 18 "Favor composition" 2018).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — types of inheritance + polymorphism + multi-language patterns |
|
||||
|
||||
@@ -2,91 +2,163 @@
|
||||
id: wiki-2026-0508-interoperability
|
||||
title: Interoperability
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-INTE-001]
|
||||
aliases: [Interop, System Integration, Cross-Platform Compatibility]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, interOperability, connectivity, standards, synchronization, Systems-Thinking]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [systems, protocols, integration, standards]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: multi
|
||||
framework: standards
|
||||
---
|
||||
|
||||
# [[Interoperability|Interoperability]]
|
||||
# Interoperability
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "장벽 없는 소통: 제조사와 언어, 플랫폼이 서로 다르더라도 시스템들이 서로 데이터를 주고받고 정보를 정확히 해석하며 협업할 수 있게 하는 '협동의 기술적 토대'."
|
||||
## 매 한 줄
|
||||
> **"매 different systems 가 매 friction 없이 함께 작동하는 능력"**. 매 syntactic (data format), 매 semantic (meaning), 매 organizational (governance) 의 3 layer 로 분해. 매 2026 의 hot topics: MCP (Model Context Protocol), OpenAPI, gRPC, WebAssembly Component Model.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
상호운용성(Interoperability)은 이질적인 시스템들이 하나의 유기체처럼 서로 작동할 수 있는 능력입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **계층**:
|
||||
* **Technical**: 하드웨어와 프로토콜의 연결 (케이블이 꽂히고 데이터가 전송됨). ([[Gates|Gates]]와 연결)
|
||||
* **Syntactic**: 데이터 포맷의 일치 (JSON, XML 등).
|
||||
* **Semantic**: 데이터 의미의 일치 (서로가 보낸 수치를 동일한 단위와 개념으로 이해함). ([[Ontology|Ontology]] (온톨로지)와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 상호운용성이 확보되지 않으면 시스템은 고립된 섬(Silo)이 되어 전체 효율을 갉아먹게 됨. ([[Efficiency|Efficiency]]와 연결)
|
||||
### 매 3 layers of interop
|
||||
- **Syntactic**: 매 byte-level format 의 agreement (JSON, Protobuf).
|
||||
- **Semantic**: 매 field-meaning 의 agreement (schema + ontology).
|
||||
- **Organizational**: 매 governance, versioning, deprecation policy.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 자국/자사만의 폐쇄적인 규격으로 시장을 장악하려는 'Lock-in 정책'이 주류였으나, 현대 정책은 연결될수록 가치가 커지는 네트워크 효과 기반의 '개방형 상호운용성 정책'으로 선회함(RL Update). ([[Global-Standard|Global-Standard]]와 연결)
|
||||
- **정책 변화(RL Update)**: 다양한 AI 모델과 툴들이 서로의 API를 호출하며 협업하는 '에이전트 생태계 정책'에서, 상호운용성은 지능 시스템의 확장성을 결정하는 결정적 정책이 됨.
|
||||
### 매 enablers
|
||||
- **Open standards**: HTTP, OpenAPI, JSON-Schema, OAuth 2.1.
|
||||
- **Schema-first**: Protobuf, Avro, GraphQL SDL.
|
||||
- **Capability negotiation**: Accept headers, gRPC reflection, MCP capability handshake.
|
||||
- **Adapter pattern**: 매 N×M integration → N+M with hub.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Global-Standard|Global-Standard]], Ontology (온톨로지), [[Distributed-Systems|Distributed-Systems]], [[Technical-Architecture|Technical-Architecture]], [[Internet of Things (IoT)|Internet of Things (IoT)]]
|
||||
- **Modern Tech/Tools**: API (REST, gRPC), JSON, FHIR (healthcare standard), Matter (smart home standard).
|
||||
---
|
||||
### 매 응용
|
||||
1. **AI tool ecosystem**: MCP 매 LLM ↔ tools 의 universal protocol.
|
||||
2. **Microservices**: gRPC + Protobuf 매 polyglot interop.
|
||||
3. **Healthcare**: HL7 FHIR 매 EHR interop.
|
||||
4. **Cross-cloud**: Open Container Initiative (OCI), CNCF standards.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### MCP server (2026 standard)
|
||||
```python
|
||||
# Model Context Protocol — Anthropic 2024, ubiquitous in 2026
|
||||
from mcp.server import Server
|
||||
from mcp.types import Tool, TextContent
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
server = Server("my-tool")
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
@server.list_tools()
|
||||
async def list_tools() -> list[Tool]:
|
||||
return [Tool(
|
||||
name="search",
|
||||
description="Search the knowledge base",
|
||||
inputSchema={"type": "object", "properties": {"q": {"type": "string"}}}
|
||||
)]
|
||||
|
||||
- **정보 상태:** 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
|
||||
@server.call_tool()
|
||||
async def call_tool(name: str, args: dict) -> list[TextContent]:
|
||||
if name == "search":
|
||||
return [TextContent(type="text", text=do_search(args["q"]))]
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### OpenAPI contract
|
||||
```yaml
|
||||
# 매 syntactic + semantic interop in one file
|
||||
openapi: 3.1.0
|
||||
info: { title: User API, version: 2.0.0 }
|
||||
paths:
|
||||
/users/{id}:
|
||||
get:
|
||||
parameters:
|
||||
- { name: id, in: path, required: true, schema: { type: string } }
|
||||
responses:
|
||||
'200':
|
||||
content:
|
||||
application/json:
|
||||
schema: { $ref: '#/components/schemas/User' }
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Protobuf schema-first
|
||||
```protobuf
|
||||
// user.proto — language-neutral, version-tolerant
|
||||
syntax = "proto3";
|
||||
package user.v1;
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
message User {
|
||||
string id = 1;
|
||||
string email = 2;
|
||||
reserved 3; // 매 deprecated field — 매 forward compat
|
||||
optional string display_name = 4;
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Adapter pattern (N+M interop)
|
||||
```python
|
||||
class PaymentAdapter:
|
||||
def charge(self, amount: int, currency: str) -> str: ...
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
class StripeAdapter(PaymentAdapter):
|
||||
def charge(self, amount, currency):
|
||||
return stripe.Charge.create(amount=amount, currency=currency).id
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
class TossAdapter(PaymentAdapter):
|
||||
def charge(self, amount, currency):
|
||||
return toss.payments.confirm(amount=amount).payment_key
|
||||
```
|
||||
|
||||
### Wasm Component Model (2026 cross-language)
|
||||
```toml
|
||||
# 매 binary interop — Rust ↔ Python ↔ Go via Wasm components
|
||||
[package]
|
||||
name = "my-component"
|
||||
version = "0.1.0"
|
||||
|
||||
[lib]
|
||||
crate-type = ["cdylib"]
|
||||
|
||||
[dependencies]
|
||||
wit-bindgen = "0.30"
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | 표준 |
|
||||
|---|---|
|
||||
| LLM ↔ tools | MCP |
|
||||
| REST API contract | OpenAPI 3.1 |
|
||||
| High-throughput RPC | gRPC + Protobuf |
|
||||
| Cross-language binary | Wasm Component Model |
|
||||
| Healthcare data | HL7 FHIR R5 |
|
||||
| Auth | OAuth 2.1 + OIDC |
|
||||
|
||||
**기본값**: 매 schema-first + open standard. 매 proprietary format 의 X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[System-Design]] · [[Distributed-Systems]]
|
||||
- 변형: [[API-Design]] · [[Protocol-Design]]
|
||||
- 응용: [[MCP]] · [[Protocols]] · [[Microservices]]
|
||||
- Adjacent: [[Backwards-Compatibility]] · [[Versioning]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 protocol selection, 매 schema design review, 매 adapter scaffolding.
|
||||
**언제 X**: 매 single-team monolith 의 internal modules — over-engineering.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Snowflake protocols**: 매 in-house custom protocol → 매 every consumer N×N adapters.
|
||||
- **Schema drift**: 매 producer / consumer 매 separate schema copies → 매 silent breakage.
|
||||
- **No versioning**: 매 breaking change broadcast → cascade failure.
|
||||
- **Tight coupling via DB**: 매 shared DB schema 매 anti-interop.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (W3C, IETF, IEEE standards; Anthropic MCP 2024 spec; gRPC.io; CNCF landscape 2026).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 3-layer interop, MCP/OpenAPI/Wasm patterns |
|
||||
|
||||
@@ -1,63 +1,186 @@
|
||||
---
|
||||
id: wiki-2026-0508-item-item-collaborative-filterin
|
||||
title: Item Item Collaborative Filtering
|
||||
title: Item-Item Collaborative Filtering
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [REC-ITEM-001]
|
||||
aliases: [Item-Based CF, Item-Item CF, Item Similarity Recommender]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [recommender-systems, Collaborative-Filtering, item-item, personalization, Similarity-Metrics]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [recommender-systems, collaborative-filtering, similarity, embeddings]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: scipy
|
||||
---
|
||||
|
||||
# Item-Item Collaborative Filtering (아이템 기반 협업 필터링)
|
||||
# Item-Item Collaborative Filtering
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "사용자의 변덕스러운 취향보다, 아이템 간의 견고한 연관 관계를 바탕으로 정교한 추천 지도를 그려라" — 개별 사용자 간의 유사도를 찾는 대신, 아이템들이 함께 소비된 이력을 분석하여 아이템 간의 유사성을 측정하고 이를 기반으로 사용자에게 새로운 것을 제안하는 추천 알고리즘.
|
||||
## 매 한 줄
|
||||
> **"매 user 매 liked X — 매 X 와 similar Y 의 recommend"**. Item-Item CF (Sarwar et al. 2001, Amazon) 매 item 사이 similarity matrix 의 precompute 매 query time 매 user 의 history 의 weighted sum 의 score 의 produce. 2026 매 baseline / cold-start fallback / explainability 매 still widely deployed alongside neural retrievers.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Static Content Relationship" — 사용자의 수는 기하급수적으로 늘어나지만 아이템의 수는 상대적으로 고정되어 있다는 점에 착안하여, 아이템 간 유사도 행렬을 미리 계산(Offline)해두고 실시간(Online) 추천 성능을 극대화하는 패턴.
|
||||
- **작동 원리:**
|
||||
- **Step 1:** 특정 아이템 A와 B를 동시에 선호한 사용자들의 데이터를 수집.
|
||||
- **Step 2:** 코사인 유사도 등을 사용하여 아이템 간의 점수 산정.
|
||||
- **Step 3:** 사용자가 과거에 선호했던 아이템들과 가장 유사한 아이템들을 순위화하여 노출.
|
||||
- **의의:** 사용자 기반(User-based) 방식보다 계산량이 적고 아이템의 특성이 급격히 변하지 않아 추천의 안정성이 높음 (아마존의 성공 비결).
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 단순한 구매 이력 기반에서, 이제는 딥러닝 임베딩(Matrix Factorization, Graph Embeddings)을 통해 아이템의 의미론적 유사성까지 결합하는 하이브리드 방식으로 진화.
|
||||
- **정책 변화:** Antigravity 프로젝트의 지식 추천 엔진은 사용자가 현재 읽고 있는 문서와 '함께 참조된 빈도'가 높은 다른 지식들을 아이템 기반 필터링으로 분석하여 사이드바에 즉각 제시함.
|
||||
### 매 vs User-User CF
|
||||
- **User-user**: similar users 의 find — 매 user count >>> item count → expensive.
|
||||
- **Item-item**: similar items 의 find — 매 item catalog 매 stable, similarity 매 precompute-able.
|
||||
- 매 Amazon 2003 paper: item-item 매 user-user 의 latency / quality 의 dominate.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Collaborative-Filtering|Collaborative-Filtering]], [[Matrix-Factorization|Matrix-Factorization]], [[Inner-Product-Spaces|Inner-Product-Spaces]], [[Information-Retrieval-IR|Information-Retrieval-IR]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Item-Item-Collaborative-Filtering.md
|
||||
### 매 Similarity metrics
|
||||
- **Cosine**: most common, 매 sparse-friendly.
|
||||
- **Pearson**: mean-centered cosine, 매 rating-bias 의 remove.
|
||||
- **Adjusted cosine**: user-mean center 매 implicit feedback 매 useful.
|
||||
- **Jaccard**: binary interactions (clicked / not).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 Scoring formula
|
||||
- 매 score(u, i) = Σ_{j ∈ N(i) ∩ I_u} sim(i, j) · r(u, j) / Σ |sim(i, j)|.
|
||||
- N(i) = top-K similar items, I_u = user u 의 interaction set.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 응용
|
||||
1. Amazon "customers who bought X also bought Y".
|
||||
2. Netflix similar-titles row.
|
||||
3. Spotify radio seed expansion.
|
||||
4. E-commerce cold-start fallback.
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 1: Sparse cosine similarity (scipy)
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy.sparse import csr_matrix
|
||||
from sklearn.preprocessing import normalize
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def build_item_sim(interactions: csr_matrix, top_k: int = 50) -> csr_matrix:
|
||||
"""매 interactions: (n_users, n_items). 매 return: (n_items, n_items) top-k similarity."""
|
||||
# Item vectors = columns
|
||||
item_norm = normalize(interactions.T, norm="l2", axis=1) # (n_items, n_users)
|
||||
sim = item_norm @ item_norm.T # (n_items, n_items)
|
||||
sim.setdiag(0) # self-sim 의 zero
|
||||
return _keep_topk(sim, top_k)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def _keep_topk(mat: csr_matrix, k: int) -> csr_matrix:
|
||||
mat = mat.tolil()
|
||||
for i in range(mat.shape[0]):
|
||||
row = mat.rows[i]
|
||||
data = mat.data[i]
|
||||
if len(data) > k:
|
||||
idx = np.argsort(data)[-k:]
|
||||
mat.rows[i] = [row[j] for j in idx]
|
||||
mat.data[i] = [data[j] for j in idx]
|
||||
return mat.tocsr()
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 2: Score for a user
|
||||
```python
|
||||
def recommend(user_history: dict[int, float], item_sim: csr_matrix, top_n: int = 10):
|
||||
"""매 user_history: {item_id: rating}. 매 return: top-N (item_id, score)."""
|
||||
n_items = item_sim.shape[0]
|
||||
scores = np.zeros(n_items)
|
||||
sim_sums = np.zeros(n_items)
|
||||
for j, r in user_history.items():
|
||||
col = item_sim[:, j].toarray().flatten()
|
||||
scores += col * r
|
||||
sim_sums += np.abs(col)
|
||||
sim_sums[sim_sums == 0] = 1
|
||||
final = scores / sim_sums
|
||||
for j in user_history:
|
||||
final[j] = -np.inf # already-seen 의 mask
|
||||
top = np.argpartition(final, -top_n)[-top_n:]
|
||||
return [(int(i), float(final[i])) for i in top[np.argsort(final[top])[::-1]]]
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 3: Implicit feedback (BM25-weighted)
|
||||
```python
|
||||
def bm25_weight(interactions: csr_matrix, k1: float = 1.2, b: float = 0.75) -> csr_matrix:
|
||||
"""매 implicit signal (click count) 의 BM25-style weight 의 give — better than raw counts."""
|
||||
interactions = interactions.tocsr().astype(float)
|
||||
N = interactions.shape[0]
|
||||
df = np.bincount(interactions.indices, minlength=interactions.shape[1])
|
||||
idf = np.log((N - df + 0.5) / (df + 0.5) + 1)
|
||||
doc_len = np.asarray(interactions.sum(axis=1)).flatten()
|
||||
avg_dl = doc_len.mean()
|
||||
rows, cols = interactions.nonzero()
|
||||
tf = interactions.data
|
||||
norm = (1 - b) + b * doc_len[rows] / avg_dl
|
||||
weighted = tf * (k1 + 1) / (tf + k1 * norm) * idf[cols]
|
||||
return csr_matrix((weighted, (rows, cols)), shape=interactions.shape)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 4: Approximate top-K with Faiss (scale)
|
||||
```python
|
||||
import faiss
|
||||
import numpy as np
|
||||
|
||||
def build_item_sim_faiss(item_emb: np.ndarray, top_k: int = 50):
|
||||
"""매 1M+ items 의 scale — exact dot-product 매 too slow."""
|
||||
n, d = item_emb.shape
|
||||
item_emb = item_emb / np.linalg.norm(item_emb, axis=1, keepdims=True)
|
||||
index = faiss.IndexHNSWFlat(d, 32, faiss.METRIC_INNER_PRODUCT)
|
||||
index.add(item_emb.astype(np.float32))
|
||||
D, I = index.search(item_emb.astype(np.float32), top_k + 1)
|
||||
return I[:, 1:], D[:, 1:] # drop self
|
||||
```
|
||||
|
||||
### Pattern 5: Hybrid with content embeddings (cold-start)
|
||||
```python
|
||||
def hybrid_sim(cf_sim: np.ndarray, content_sim: np.ndarray, alpha: float = 0.7):
|
||||
"""매 new item 매 CF 매 zero — 매 content_sim 의 fallback."""
|
||||
cf_density = (cf_sim != 0).sum(axis=1) / cf_sim.shape[1]
|
||||
weight = np.where(cf_density > 0.01, alpha, 0.0)[:, None]
|
||||
return weight * cf_sim + (1 - weight) * content_sim
|
||||
```
|
||||
|
||||
### Pattern 6: 2026 modern stack (neural + item-item)
|
||||
```python
|
||||
# 매 production 2026: neural retriever (two-tower) + item-item 매 reranker explainability.
|
||||
def explain_recommendation(target_item, user_history, item_sim):
|
||||
"""매 'because you liked X, Y, Z' 매 explanation 의 generate."""
|
||||
contributions = []
|
||||
for j, r in user_history.items():
|
||||
s = item_sim[target_item, j]
|
||||
contributions.append((j, s * r))
|
||||
contributions.sort(key=lambda x: -x[1])
|
||||
return contributions[:3] # top-3 reasons
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| < 100K items, dense matrix fit | Exact cosine + scipy. |
|
||||
| 1M+ items | Faiss HNSW approximate. |
|
||||
| Implicit feedback | BM25 weight + cosine. |
|
||||
| Cold-start items | Content-hybrid sim. |
|
||||
| Need explainability | Item-item over neural-only. |
|
||||
| Massive user history | Combine with two-tower neural. |
|
||||
|
||||
**기본값**: BM25-weighted cosine + Faiss HNSW (top-50 neighbors), hybrid with content embedding 매 cold-start.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Collaborative-Filtering]] · [[Recommender-Systems]]
|
||||
- 변형: [[User-User-CF]] · [[Matrix-Factorization]] · [[ALS]]
|
||||
- 응용: [[Amazon-Recommender]] · [[Netflix-Similar-Titles]] · [[Cold-Start]]
|
||||
- Adjacent: [[Two-Tower-Model]] · [[Faiss]] · [[Cosine-Similarity]] · [[BM25]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Generating explainable recommendations, baseline implementation, hybrid systems where item-item provides interpretability layer.
|
||||
**언제 X**: Sequential recommendation (use SASRec / transformer), content-rich domains (use embeddings directly).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Dense (n_items × n_items) without top-K**: 1M items → 4TB matrix.
|
||||
- **Cosine on raw counts**: 매 popularity bias — 매 BM25 / TF-IDF 의 weight.
|
||||
- **No self-mask in scoring**: recommend already-purchased items.
|
||||
- **Recompute sim every request**: 매 batch precompute 의 cache.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: Sarwar et al. (2001) "Item-based collaborative filtering", Linden et al. (2003) "Amazon.com recommendations", implicit lib (Frederickson 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with scipy/Faiss/BM25 patterns and 2026 hybrid stack |
|
||||
|
||||
@@ -2,65 +2,195 @@
|
||||
id: wiki-2026-0508-iteration
|
||||
title: Iteration
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-ITER-001]
|
||||
aliases: [Iterative Development, Loop, Iterate]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, iteration, loops, recursion, computer-science, repetitive-tasks]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [methodology, agile, python, control-flow, generators]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: general
|
||||
---
|
||||
|
||||
# [[Iteration|Iteration]]
|
||||
# Iteration
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "기능의 되풀이, 지능의 축적: 복잡한 작업을 단순한 작은 단계로 나누어 목표를 달성할 때까지 끈질기게 반복 실행함으로써, 단 한 번의 시도로는 불가능한 정교한 결과물을 빚어내는 컴퓨팅적 인내."
|
||||
## 매 한 줄
|
||||
> **"매 small step, 매 feedback, 매 adjust, 매 repeat"**. Iteration 매 dual concept — (1) programming control flow (`for`, `while`, generators) 와 (2) development methodology (small increments + feedback loop). 2026 LLM-assisted 시대 매 iteration 매 even tighter — 매 minute 매 cycle 가능.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
반복(Iteration)은 동일한 절차를 여러 번 되풀이하는 컴퓨터 과학과 사고의 기본 원리입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **구현 방식**:
|
||||
* **Loops**: 정해진 횟수(for)나 조건(while)이 만족될 때까지 코드 블록 실행.
|
||||
* **Recursion**: 함수가 자기 자신을 호출하여 문제를 작게 쪼개어 해결.
|
||||
* **Convergence**: 값을 조금씩 수정하며 정답에 수렴함 ([[Gradient-Descent|Gradient-Descent]]와 연결).
|
||||
2. **왜 중요한가?**:
|
||||
* 인간은 수백만 번의 반복에 지치지만, 컴퓨터는 지치지 않고 반복하여 압도적인 데이터 처리와 수치 해석을 수행하기 때문임. ([[Efficiency|Efficiency]]와 연결)
|
||||
### 매 Programming iteration
|
||||
- **Eager**: `for x in list` — 매 list 매 fully materialized.
|
||||
- **Lazy**: generator, iterator — 매 on-demand pull.
|
||||
- **Async**: `async for x in stream` — 매 I/O 의 overlap.
|
||||
- **Parallel**: `joblib`, `multiprocessing.Pool.imap` — 매 CPU-bound iteration.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순히 '횟수 반복 정책'에 그쳤으나, 현대 정책은 반복할 때마다 이전 결과를 학습에 반영하여 더 나아지는 '피드백 기반 반복 정책'으로 지능화됨(RL Update). ([[Feedback-Loops|Feedback-Loops]]와 연결)
|
||||
- **정책 변화(RL Update)**: 거대 모델의 추론 정책에서 한 번에 답을 내기보다, 여러 번의 생각(Iteration)을 거쳐 정답을 다듬는 '가챠(Sampling)와 재시도 정책'이 성능의 핵심 지표가 됨.
|
||||
### 매 Methodology iteration
|
||||
- **Loop**: hypothesis → build → measure → learn.
|
||||
- **Cadence**: daily (LLM-assisted), weekly (sprint), monthly (release).
|
||||
- **Artifact per cycle**: shippable increment.
|
||||
- **Feedback source**: tests, users, metrics, code review.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Feedback-Loops|Feedback-Loops]], [[Gradient-Descent|Gradient-Descent]], [[Efficiency|Efficiency]], [[Incrementalism|Incrementalism]], [[Control-Theory|Control-Theory]]
|
||||
- **Modern Tech/Tools**: For loops, Multi-pass [[Reasoning|Reasoning]], Iterative [[Refinement|Refinement]], Self-Correction loops.
|
||||
---
|
||||
### 매 응용
|
||||
1. Data pipeline (process N rows lazily).
|
||||
2. ML hyperparameter search (iteratively narrow).
|
||||
3. Agile sprint (2-week cycle).
|
||||
4. LLM agentic loop (think → act → observe → repeat).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Generator (lazy iteration)
|
||||
```python
|
||||
def read_jsonl(path: str):
|
||||
"""매 1GB+ file 의 stream — 매 memory O(1)."""
|
||||
import json
|
||||
with open(path) as f:
|
||||
for line in f:
|
||||
yield json.loads(line)
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
for record in read_jsonl("events.jsonl"):
|
||||
process(record)
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 2: Itertools combinators
|
||||
```python
|
||||
from itertools import islice, chain, groupby, accumulate
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
# 매 first 100 records 만
|
||||
head = list(islice(read_jsonl("big.jsonl"), 100))
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
# 매 multiple sources 의 concat
|
||||
combined = chain(read_jsonl("a.jsonl"), read_jsonl("b.jsonl"))
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
# 매 group by user
|
||||
sorted_records = sorted(combined, key=lambda r: r["user_id"])
|
||||
for user_id, group in groupby(sorted_records, key=lambda r: r["user_id"]):
|
||||
handle_user(user_id, list(group))
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 3: Async iteration (2026)
|
||||
```python
|
||||
import asyncio
|
||||
import httpx
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
async def fetch_pages(urls: list[str]):
|
||||
async with httpx.AsyncClient() as client:
|
||||
async def fetch(url):
|
||||
r = await client.get(url)
|
||||
return url, r.text
|
||||
for coro in asyncio.as_completed([fetch(u) for u in urls]):
|
||||
yield await coro
|
||||
|
||||
async def main():
|
||||
async for url, html in fetch_pages(URLS):
|
||||
print(url, len(html))
|
||||
```
|
||||
|
||||
### Pattern 4: Iterative refinement (algorithm)
|
||||
```python
|
||||
def newton_sqrt(n: float, tol: float = 1e-10, max_iter: int = 50) -> float:
|
||||
x = n / 2
|
||||
for _ in range(max_iter):
|
||||
x_new = 0.5 * (x + n / x)
|
||||
if abs(x_new - x) < tol:
|
||||
return x_new
|
||||
x = x_new
|
||||
return x
|
||||
```
|
||||
|
||||
### Pattern 5: LLM agentic loop (2026)
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
client = Anthropic()
|
||||
|
||||
def agent_loop(task: str, max_iter: int = 10):
|
||||
history = [{"role": "user", "content": task}]
|
||||
for i in range(max_iter):
|
||||
msg = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=4000,
|
||||
tools=TOOLS,
|
||||
messages=history,
|
||||
)
|
||||
history.append({"role": "assistant", "content": msg.content})
|
||||
if msg.stop_reason == "end_turn":
|
||||
return msg
|
||||
# tool_use → execute → observation → next iter
|
||||
observations = execute_tools(msg.content)
|
||||
history.append({"role": "user", "content": observations})
|
||||
raise RuntimeError("매 max_iter 의 reach")
|
||||
```
|
||||
|
||||
### Pattern 6: Sprint retrospective
|
||||
```python
|
||||
def retro(sprint_data: dict) -> dict:
|
||||
return {
|
||||
"what_worked": sprint_data["green_items"],
|
||||
"what_didnt": sprint_data["red_items"],
|
||||
"experiments_next": [
|
||||
f"Try {hypothesis}" for hypothesis in sprint_data["new_ideas"]
|
||||
],
|
||||
"metrics_delta": {
|
||||
k: sprint_data["after"][k] - sprint_data["before"][k]
|
||||
for k in sprint_data["before"]
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
### Pattern 7: Bounded iteration with timeout
|
||||
```python
|
||||
import time
|
||||
|
||||
def iterate_with_budget(items, budget_sec: float):
|
||||
start = time.time()
|
||||
for item in items:
|
||||
if time.time() - start > budget_sec:
|
||||
print(f"매 budget 매 expire — {item} 의 stop")
|
||||
return
|
||||
yield process(item)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Large file processing | Generator (lazy). |
|
||||
| Multiple I/O calls | Async iteration. |
|
||||
| CPU-bound loop | `multiprocessing` 또는 vectorize. |
|
||||
| Numerical convergence | While + tolerance check. |
|
||||
| Product development | 2-week sprint + retrospective. |
|
||||
| LLM agent | think-act-observe loop with max_iter cap. |
|
||||
|
||||
**기본값**: Programming 매 generator-first; methodology 매 1-week iteration with measurable hypothesis.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Control-Flow]] · [[Agile]]
|
||||
- 변형: [[Recursion]] · [[Async-Iteration]] · [[Parallel-Iteration]]
|
||||
- 응용: [[Generator]] · [[Sprint]] · [[Agentic-Loop]] · [[Newton-Method]]
|
||||
- Adjacent: [[Itertools]] · [[Coroutine]] · [[Lean-Startup]] · [[Build-Measure-Learn]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Agentic systems (think-act-observe), iterative refinement of code via LLM feedback, sprint planning summaries.
|
||||
**언제 X**: Single-shot generation, tasks where each iteration is 1+ hours of human work (cycle too slow).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Eager when lazy works**: `list(huge_generator)` — 매 OOM.
|
||||
- **Unbounded loop**: no max_iter — 매 infinite loop bug.
|
||||
- **No feedback in iteration**: 매 build without measure — methodology 매 broken.
|
||||
- **Perfect first iteration**: 매 ship at 70% — feedback 의 wait.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: PEP 234 (iterators), Eric Ries "Lean Startup" (2011), "Continuous Delivery" (Humble & Farley).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content covering both programming and methodology iteration with LLM agentic loop |
|
||||
|
||||
@@ -2,64 +2,153 @@
|
||||
id: wiki-2026-0508-joint-optimization
|
||||
title: Joint Optimization
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-JOOP-001]
|
||||
aliases: [Multi-Objective Optimization, Co-Optimization, End-to-End Optimization]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.91
|
||||
tags: [auto-reinforced, joint-Optimization, _system-design, end-to-end, synergetic-optimization]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [optimization, ML, multi-objective]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: pytorch-jax
|
||||
---
|
||||
|
||||
# [[Joint-Optimization|Joint-Optimization]]
|
||||
# Joint Optimization
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "전체는 부분의 합보다 크다: 개별 부품이나 단계를 제각각 최적화(Local Optima)하기보다, 시스템의 모든 구성 요소가 서로에게 미치는 영향을 고려하여 전체의 목표(Global Optima)를 위해 동시에 조율하는 하모니의 기술."
|
||||
## 매 한 줄
|
||||
> **"매 multiple objectives / variables 를 동시에 optimize"**. 매 separate / sequential optimization 보다 매 globally better solution 도달 가능 — 매 cost: 매 higher complexity, 매 risk: 매 conflicting gradients. 매 modern DL (end-to-end training), 매 RL (actor-critic), 매 chip design (DSE) 의 매 핵심.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
공동 최적화(Joint-Optimization)는 여러 변수나 프로세스를 개별적으로 처리하지 않고 통합적으로 최적화하는 접근법입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **주요 개념**:
|
||||
* **End-to-End Learning**: 데이터 입력부터 최종 출력까지 중간 단계 없이 하나의 신경망으로 통째로 최적화. (Deep Learning (DL)의 철학)
|
||||
* **[[Hardware|Hardware]]-Software Co-design**: 소프트웨어 로직과 반도체 설계를 동시에 최적화하여 압도적 성능 달성. (Hardware와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 각 부분은 최선일지라도 그들의 연결점에서 병목(Bottleneck)이 생기는 것을 원천 봉쇄하여 전체 시스템의 효율을 극대화함. ([[Efficiency|Efficiency]]와 연결)
|
||||
### 매 왜 jointly?
|
||||
- **Coupling**: 매 variables 의 interaction 강 → 매 separate solve 매 suboptimal.
|
||||
- **Information sharing**: 매 shared representation / gradient → 매 mutual benefit.
|
||||
- **End-to-end**: 매 pipeline 의 손실 누적 X.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 복잡성을 줄이기 위해 각 단계를 독립적으로 분리하여 관리하는 '모듈화 정책'이 우세했으나, 현대 정책은 최고 성능을 위해 모듈 간의 경계를 허물고 동시에 학습/설계하는 '통합 정책'이 대세가 됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 다계층 에이전트 시스템 정책에서, 기획 에이전트와 실행 에이전트를 따로 두지 않고 서로의 피드백을 즉시 반영하여 전체 워크플로우를 공동 최적화하는 정책이 차세대 에이전트 설계의 핵심이 됨. (Agentic-Workflow와 연결)
|
||||
### 매 challenges
|
||||
- **Conflicting gradients**: 매 objectives 매 push opposite directions.
|
||||
- **Scaling**: 매 loss magnitudes 매 mismatched → 매 dominant loss problem.
|
||||
- **Local minima**: 매 joint landscape 매 더 rugged.
|
||||
- **Compute**: 매 N variables 매 jointly → search space exponential.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Optimization|Optimization]], [[Efficiency|Efficiency]], Deep Learning (DL), [[Hardware|Hardware]], Agentic-Workflow
|
||||
- **Modern Tech/Tools**: DeepSpeed (Training optimization), End-to-end autonomous driving, ASIC co-design.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Multi-task learning**: 매 shared encoder + 매 multiple heads.
|
||||
2. **Actor-critic RL**: 매 policy + value 매 jointly.
|
||||
3. **HW/SW co-design**: 매 chip floorplan + scheduler 매 jointly.
|
||||
4. **Pareto front**: 매 cost vs latency 매 frontier.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Weighted sum (simplest)
|
||||
```python
|
||||
import torch
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def joint_loss(pred1, pred2, y1, y2, w=(0.5, 0.5)):
|
||||
l1 = torch.nn.functional.cross_entropy(pred1, y1)
|
||||
l2 = torch.nn.functional.mse_loss(pred2, y2)
|
||||
return w[0] * l1 + w[1] * l2
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### GradNorm (auto-balance)
|
||||
```python
|
||||
# Chen et al 2018 — 매 dynamic loss weighting
|
||||
class GradNorm:
|
||||
def __init__(self, n_tasks, alpha=1.5):
|
||||
self.weights = torch.ones(n_tasks, requires_grad=True)
|
||||
self.alpha = alpha
|
||||
def update(self, losses, shared_params):
|
||||
# 매 normalize 매 gradient magnitudes across tasks
|
||||
grads = [torch.autograd.grad(l, shared_params, retain_graph=True)
|
||||
for l in losses]
|
||||
norms = torch.stack([g[0].norm() for g in grads])
|
||||
target = norms.mean() * (losses / losses.mean()) ** self.alpha
|
||||
gradnorm_loss = (norms - target.detach()).abs().sum()
|
||||
return gradnorm_loss
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### MGDA (Multi-Gradient Descent)
|
||||
```python
|
||||
# Sener & Koltun 2018 — 매 Pareto-optimal direction 찾기
|
||||
import numpy as np
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def mgda_solver(grads):
|
||||
"""grads: list of gradient vectors per task."""
|
||||
# 매 minimum-norm point in convex hull
|
||||
G = np.stack([g.flatten() for g in grads])
|
||||
# solve min ||sum α_i g_i||² s.t. α≥0, sum α=1
|
||||
from scipy.optimize import minimize
|
||||
def obj(a): return np.linalg.norm(a @ G) ** 2
|
||||
a0 = np.ones(len(grads)) / len(grads)
|
||||
cons = [{"type": "eq", "fun": lambda a: a.sum() - 1}]
|
||||
bnds = [(0, 1)] * len(grads)
|
||||
res = minimize(obj, a0, constraints=cons, bounds=bnds)
|
||||
return res.x # 매 Pareto direction
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Actor-critic joint update
|
||||
```python
|
||||
# PPO-style joint optimization
|
||||
def actor_critic_loss(states, actions, advantages, returns, policy, value):
|
||||
log_p = policy.log_prob(states, actions)
|
||||
actor_loss = -(log_p * advantages).mean()
|
||||
critic_loss = (value(states) - returns).pow(2).mean()
|
||||
entropy = policy.entropy(states).mean()
|
||||
return actor_loss + 0.5 * critic_loss - 0.01 * entropy
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pareto frontier sampling
|
||||
```python
|
||||
# 매 multi-objective 의 frontier 발견
|
||||
def pareto_front(solutions):
|
||||
"""solutions: list of (obj1, obj2) tuples (minimize both)."""
|
||||
front = []
|
||||
for s in solutions:
|
||||
dominated = any(
|
||||
s2[0] <= s[0] and s2[1] <= s[1] and s2 != s
|
||||
for s2 in solutions
|
||||
)
|
||||
if not dominated:
|
||||
front.append(s)
|
||||
return front
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Strategy |
|
||||
|---|---|
|
||||
| 매 objectives 매 aligned | Weighted sum (simple) |
|
||||
| 매 objectives 매 conflicting | MGDA / PCGrad |
|
||||
| 매 magnitude 매 mismatched | GradNorm |
|
||||
| 매 trade-off 매 explore 필요 | Pareto frontier sweep |
|
||||
| 매 RL actor + critic | Joint PPO/SAC |
|
||||
|
||||
**기본값**: Weighted sum 시작 → 매 imbalance 발견시 GradNorm 도입.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Optimization]] · [[Multi-Task-Learning]]
|
||||
- 변형: [[Pareto-Optimization]] · [[Bilevel-Optimization]]
|
||||
- 응용: [[Actor-Critic]] · [[End-to-End-Learning]] · [[HW-SW-CoDesign]]
|
||||
- Adjacent: [[Loss-Weighting]] · [[Gradient-Surgery]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 loss function design 매 multi-objective, 매 gradient conflict diagnosis, 매 Pareto analysis explanation.
|
||||
**언제 X**: 매 single-objective optimization — over-complication.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Random weight tuning**: 매 grid search w/o GradNorm → 매 unstable.
|
||||
- **Ignore gradient conflict**: 매 cosine(g1,g2) < 0 무시 → 매 destructive interference.
|
||||
- **Premature joint**: 매 separate pretrain → joint finetune 매 더 좋은 경우 많음.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Chen 2018 GradNorm; Sener & Koltun 2018 MGDA; Yu 2020 PCGrad; Schulman 2017 PPO).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — multi-objective optimization patterns + Pareto |
|
||||
|
||||
@@ -1,91 +1,186 @@
|
||||
---
|
||||
id: wiki-2026-0508-just-in-time-jit
|
||||
title: Just In Time (JIT)
|
||||
title: Just-In-Time (JIT)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-JITT-001]
|
||||
aliases: [JIT Compilation, Dynamic Compilation, Tracing JIT]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, jit, just-in-time, compiler, Optimization, performance, logistics]
|
||||
verification_status: applied
|
||||
tags: [compiler, optimization, runtime, performance, llvm]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: jax
|
||||
---
|
||||
|
||||
# [[Just-In-Time (JIT)|Just-In-Time (JIT)]]
|
||||
# Just-In-Time (JIT)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "필요할 때 바로: 미리 정해진 계획에 따라 몽땅 해놓는 게 아니라, 실제 상황이 닥쳤을 때(런타임 혹은 주문 발생 시) 그 즉시 최적의 조치를 취함으로써 자원의 낭비를 줄이고 반응 속도를 극대화하는 민첩한 최적화."
|
||||
## 매 한 줄
|
||||
> **"매 compile 매 first call, 매 reuse 매 hot path"**. JIT compilation 매 source / bytecode / IR 의 native code 의 runtime translation — 매 profile-guided 의 hot region 의 optimize. 2026 ML 시대 매 JAX `jit`, PyTorch 2.x `torch.compile`, Mojo, JuliaLang 매 mainstream.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
JIT(Just-In-Time)는 컴퓨팅과 물류 분야에서 공통적으로 쓰이는 '적시 처리' 철학입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **분야별 사례**:
|
||||
* **Computing (JIT Compiler)**: 프로그램 전체를 미리 기계어로 바꾸지 않고, 실행되는 순간(Just-in-time) 필요한 부분만 컴파일하여 성능 최적화 (Java, Python 가속기 등). ([[Efficiency|Efficiency]]와 연결)
|
||||
* **Logistics (Toyota 생산 방식)**: 재고를 쌓지 않고 주문이 들어온 만큼만 부품을 조달하여 생산 (Lean과 유사).
|
||||
2. **왜 중요한가?**:
|
||||
* 정적인 미리 준비(Ahead-of-Time)보다 동적인 실제 상황 데이터를 반영할 수 있어 효율성과 유연성이 압도적으로 높음. (Optimization의 정수)
|
||||
### 매 JIT 의 mechanics
|
||||
- **Trace**: 매 input shape / dtype 의 capture 매 computational graph.
|
||||
- **Specialize**: 매 fixed shapes 의 specialized kernel 의 generate.
|
||||
- **Cache**: 매 (function, signature) → compiled artifact.
|
||||
- **Recompile**: 매 shape change → cache miss → recompile (avoid in hot loop).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 JIT가 실행 시점에 부하를 준다는 정책적 우려가 있었으나, 현대 정책은 런타임 프로파일링 정책을 통해 '가장 자주 쓰이는 코드 정책'만 집중 가속하여 전체 성능을 사전 컴파일보다 높게 만드는 단계에 도달함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 추론 정책에서도 모든 모델 파라미터를 메모리에 올리기보다, 입력값에 따라 필요한 계층만 로드하거나 활성화하는 '동적 추론(JIT Inference) 정책'이 기기 내(On-device) AI의 핵심 기술로 부상함.
|
||||
### 매 vs AOT
|
||||
- **AOT (ahead-of-time)**: rustc, gcc — startup 빠름, 매 dynamic dispatch 부족.
|
||||
- **JIT**: 매 runtime info 의 use → better inlining, 매 startup 의 cost.
|
||||
- **Hybrid**: PyPy, V8, .NET — interpret first, JIT after N invocations.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Efficiency|Efficiency]], [[Optimization|Optimization]], [[Hardware|Hardware]], [[Distributed-Systems|Distributed-Systems]], Moore's Law
|
||||
- **Modern Tech/Tools**: JVM HotSpot, [[V8 Engine|V8 Engine]] ([[JavaScript|JavaScript]]), PyTorch JIT, JAX, Lean manufacturing.
|
||||
---
|
||||
### 매 ML JIT 의 specifics
|
||||
- **Static shape**: JAX `jit` 매 traced shape 의 specialize — dynamic shape 매 retrace.
|
||||
- **XLA / Triton backend**: 매 fused kernels — memory bandwidth dominant.
|
||||
- **Compilation cache**: persistent disk cache 매 cold-start 의 mitigate.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. ML training loop (JAX, torch.compile).
|
||||
2. Numerical Python (Numba `@njit`).
|
||||
3. JavaScript engines (V8, JSC).
|
||||
4. Database query plans (Snowflake, DuckDB).
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: JAX jit (2026 standard)
|
||||
```python
|
||||
import jax
|
||||
import jax.numpy as jnp
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
@jax.jit
|
||||
def attention(q, k, v):
|
||||
scores = jnp.einsum("bhqd,bhkd->bhqk", q, k) / jnp.sqrt(q.shape[-1])
|
||||
weights = jax.nn.softmax(scores, axis=-1)
|
||||
return jnp.einsum("bhqk,bhkd->bhqd", weights, v)
|
||||
|
||||
- **정보 상태:** 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
|
||||
# First call: trace + compile (slow)
|
||||
# Subsequent: cached (fast)
|
||||
out = attention(q, k, v)
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: torch.compile (PyTorch 2.x)
|
||||
```python
|
||||
import torch
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
model = MyTransformer().cuda()
|
||||
compiled = torch.compile(model, mode="reduce-overhead", fullgraph=True)
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
for batch in dataloader:
|
||||
out = compiled(batch) # 매 first batch 매 slow, subsequent 매 fast
|
||||
out.backward()
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 3: Static argnums (avoid retrace)
|
||||
```python
|
||||
from functools import partial
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
@partial(jax.jit, static_argnums=(1,))
|
||||
def topk(logits, k):
|
||||
return jax.lax.top_k(logits, k)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# 매 k=10 매 specialized — 매 k=20 매 separate compilation
|
||||
topk(logits, 10)
|
||||
topk(logits, 20) # new compile
|
||||
```
|
||||
|
||||
### Pattern 4: Numba JIT (Python → LLVM)
|
||||
```python
|
||||
from numba import njit
|
||||
import numpy as np
|
||||
|
||||
@njit(cache=True, fastmath=True)
|
||||
def mandelbrot(c, max_iter=100):
|
||||
z = 0.0 + 0.0j
|
||||
for i in range(max_iter):
|
||||
z = z * z + c
|
||||
if z.real * z.real + z.imag * z.imag > 4.0:
|
||||
return i
|
||||
return max_iter
|
||||
```
|
||||
|
||||
### Pattern 5: AOT cache 의 prewarm
|
||||
```python
|
||||
import os
|
||||
os.environ["JAX_COMPILATION_CACHE_DIR"] = "/var/cache/jax"
|
||||
|
||||
import jax
|
||||
jax.config.update("jax_persistent_cache_min_entry_size_bytes", 0)
|
||||
jax.config.update("jax_persistent_cache_min_compile_time_secs", 1.0)
|
||||
|
||||
# 매 first deployment 매 prewarm script 의 run — 매 next pods cold-start fast.
|
||||
```
|
||||
|
||||
### Pattern 6: Recompilation detection
|
||||
```python
|
||||
import jax
|
||||
from collections import Counter
|
||||
|
||||
class CompileCounter:
|
||||
def __init__(self):
|
||||
self.count = Counter()
|
||||
|
||||
def trace(self, fn_name: str, sig: tuple):
|
||||
self.count[(fn_name, sig)] += 1
|
||||
if self.count[(fn_name, sig)] > 3:
|
||||
print(f"매 thrash: {fn_name} recompiled {self.count[(fn_name, sig)]} times")
|
||||
|
||||
# Usage: hook into jax.config or torch dynamo logger
|
||||
```
|
||||
|
||||
### Pattern 7: Mojo JIT (2026)
|
||||
```mojo
|
||||
fn matmul[M: Int, N: Int, K: Int](a: Tensor, b: Tensor) -> Tensor:
|
||||
# 매 compile-time specialization 매 shapes — 매 SIMD auto-vectorize.
|
||||
var c = Tensor[DType.float32](M, N)
|
||||
for i in range(M):
|
||||
for j in range(N):
|
||||
var s: Float32 = 0
|
||||
for k in range(K):
|
||||
s += a[i, k] * b[k, j]
|
||||
c[i, j] = s
|
||||
return c
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Numerical Python tight loop | Numba `@njit`. |
|
||||
| ML training | JAX `jit` 또는 `torch.compile`. |
|
||||
| Variable shapes | Avoid JIT 또는 `dynamic=True`. |
|
||||
| One-shot script | 매 JIT overhead 매 not worth. |
|
||||
| Long-running server | JIT + persistent cache. |
|
||||
|
||||
**기본값**: ML 매 `torch.compile(mode="reduce-overhead")` 또는 `jax.jit`. Tight numerical loop 매 Numba.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Compilation]] · [[Performance-Optimization]]
|
||||
- 변형: [[Tracing-JIT]] · [[Method-JIT]] · [[AOT-Compilation]]
|
||||
- 응용: [[JAX]] · [[torch.compile]] · [[Numba]] · [[V8-Engine]]
|
||||
- Adjacent: [[XLA]] · [[Triton]] · [[LLVM]] · [[Profile-Guided-Optimization]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: ML training/serving where compile cost amortizes (>100 calls), tight numerical loops, long-running services.
|
||||
**언제 X**: One-shot scripts, code with constantly-changing shapes, debugging (use eager mode).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **JIT in hot Python loop with varying shapes**: 매 retrace 매 every call — slower than eager.
|
||||
- **No persistent cache**: 매 cold start 매 30s+ compile every deploy.
|
||||
- **JIT debugging**: 매 stacktrace 매 useless — eager 의 disable JIT first.
|
||||
- **Premature JIT**: profile first — 매 80% code 매 not bottleneck.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: JAX docs (2026), PyTorch 2.x docs, "Engineering a Compiler" (Cooper & Torczon), V8 design docs.
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with JAX/torch.compile/Numba/Mojo 2026 patterns |
|
||||
|
||||
@@ -1,66 +1,182 @@
|
||||
---
|
||||
id: wiki-2026-0508-knowledge-synthesis
|
||||
title: Knowledge synthesis
|
||||
title: Knowledge Synthesis
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-KNSY-001]
|
||||
aliases: [지식 종합, Synthesis, Information Integration]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, knowledge-synthesis, synthesis, information-Processing, integration, creativity]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [research, knowledge, synthesis, methodology, llm]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: rag
|
||||
---
|
||||
|
||||
# [[Knowledge synthesis|Knowledge synthesis]]
|
||||
# Knowledge Synthesis
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지식의 화학 반응: 서로 다른 출처에서 온 파편화된 정보들을 단순히 모으는 게 아니라, 그들 사이의 숨겨진 맥락을 찾아 연결하고 융합하여 원래 없던 '새로운 통찰과 지혜'를 창조해내는 고차원적 인지 연금술."
|
||||
## 매 한 줄
|
||||
> **"매 synthesis = 차이의 통합"**. 여러 source 의 fragmented knowledge 를 단일 coherent representation 으로 통합하는 process. 2026 LLM 시대에 RAG + structured extraction + cross-document reasoning 이 표준 toolchain.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
지식 합성(Knowledge synthesis)은 여러 개별 지식을 통합하여 더 큰 체계를 만드는 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 단계**:
|
||||
* **Deconstruction**: 정보를 최소 단위의 개념으로 분해. ([[Analysis|Analysis]]와 연결)
|
||||
* **Association**: 서로 다른 개념들 사이의 인과성이나 유사성 발견. ([[Concept Mapping|Concept Mapping]]와 연결)
|
||||
* **Integration**: 연결된 개념들을 하나의 논리적 서사나 이론으로 결합.
|
||||
2. **왜 중요한가?**:
|
||||
* 정보 과잉의 시대에서 중요한 것은 개별 사실의 암기가 아니라, 그 사실들을 엮어 세상의 큰 그림을 이해하고 문제를 푸는 '합성 능력'이기 때문임. ([[Interdisciplinary-Research|Interdisciplinary-Research]]의 핵심 능력)
|
||||
### 매 5-step pipeline
|
||||
1. **Acquisition**: search / scrape / corpus collection.
|
||||
2. **Extraction**: structured fact / claim 추출.
|
||||
3. **Alignment**: same entity / concept matching across sources.
|
||||
4. **Integration**: conflict resolution + gap filling.
|
||||
5. **Presentation**: report / map / model.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 전문가 개개인의 뇌 속에서만 일어나는 '암묵적 정책'이었으나, 현대 정책은 디지털 도구와 AI를 활용하여 누구나 지식의 연결을 시각화하고 협업하여 합성하는 '공유 지식 합성 정책'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 거대 언어 모델 자체가 인류의 방대한 지식을 기계적으로 합성(Synthesized)하여 내놓는 '지능 합성 엔진 정책'이 됨에 따라, 인간은 AI가 놓친 미세한 맥락 정책을 보완하는 최종 합성자 역할을 수행함.
|
||||
### 매 synthesis types
|
||||
- **Aggregative**: meta-analysis, systematic review.
|
||||
- **Interpretive**: thematic synthesis, narrative review.
|
||||
- **Generative**: 새 framework / theory 제시.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Analysis|Analysis]], [[Concept Mapping|Concept Mapping]], [[Interdisciplinary-Research|Interdisciplinary-Research]], [[Knowledge-Structure|Knowledge-Structure]], [[Flow-State|Flow-State]]
|
||||
- **Modern Tech/Tools**: Obsidian, Roam [[Research|Research]], Mind maps, AI-based literature review tools.
|
||||
---
|
||||
### 매 응용
|
||||
1. Systematic literature review.
|
||||
2. Competitive intelligence.
|
||||
3. Wiki / knowledge graph build-out.
|
||||
4. Investigation reporting.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### RAG synthesis pipeline
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
import chromadb
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
client = Anthropic()
|
||||
db = chromadb.Client().create_collection("docs")
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def synthesize(question: str, k=8):
|
||||
docs = db.query(query_texts=[question], n_results=k)["documents"][0]
|
||||
context = "\n---\n".join(docs)
|
||||
return client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=4096,
|
||||
system="Synthesize the sources. Cite [N]. Note conflicts.",
|
||||
messages=[{"role": "user", "content": f"Q: {question}\nSources:\n{context}"}],
|
||||
).content[0].text
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Structured extraction
|
||||
```python
|
||||
from pydantic import BaseModel
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
class Claim(BaseModel):
|
||||
statement: str
|
||||
source: str
|
||||
confidence: float
|
||||
contradicts: list[str] = []
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def extract_claims(text: str, source: str) -> list[Claim]:
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2048,
|
||||
system="Extract atomic claims as JSON list of {statement, confidence}.",
|
||||
messages=[{"role": "user", "content": text}],
|
||||
)
|
||||
return [Claim(source=source, **c) for c in json.loads(resp.content[0].text)]
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Entity alignment
|
||||
```python
|
||||
from sentence_transformers import SentenceTransformer
|
||||
import numpy as np
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
model = SentenceTransformer("all-MiniLM-L6-v2")
|
||||
|
||||
def align(entities_a, entities_b, threshold=0.85):
|
||||
emb_a = model.encode(entities_a)
|
||||
emb_b = model.encode(entities_b)
|
||||
sim = emb_a @ emb_b.T / (np.linalg.norm(emb_a, axis=1)[:, None] *
|
||||
np.linalg.norm(emb_b, axis=1)[None, :])
|
||||
pairs = []
|
||||
for i, j in zip(*np.where(sim > threshold)):
|
||||
pairs.append((entities_a[i], entities_b[j], sim[i, j]))
|
||||
return pairs
|
||||
```
|
||||
|
||||
### Conflict detection
|
||||
```python
|
||||
def detect_conflicts(claims: list[Claim]) -> list[tuple]:
|
||||
pairs = []
|
||||
for i, c1 in enumerate(claims):
|
||||
for c2 in claims[i+1:]:
|
||||
resp = client.messages.create(
|
||||
model="claude-haiku-4-5",
|
||||
max_tokens=10,
|
||||
messages=[{"role": "user",
|
||||
"content": f"Contradict?\nA: {c1.statement}\nB: {c2.statement}\nYes/No"}],
|
||||
)
|
||||
if "yes" in resp.content[0].text.lower():
|
||||
pairs.append((c1, c2))
|
||||
return pairs
|
||||
```
|
||||
|
||||
### Hierarchical summarization
|
||||
```python
|
||||
def hier_summarize(docs: list[str], chunk=4) -> str:
|
||||
if len(docs) <= 1:
|
||||
return docs[0] if docs else ""
|
||||
summaries = []
|
||||
for i in range(0, len(docs), chunk):
|
||||
merged = "\n".join(docs[i:i+chunk])
|
||||
s = spawn_summarize(merged)
|
||||
summaries.append(s)
|
||||
return hier_summarize(summaries, chunk)
|
||||
```
|
||||
|
||||
### Citation graph build
|
||||
```python
|
||||
import networkx as nx
|
||||
|
||||
def build_graph(claims: list[Claim]) -> nx.DiGraph:
|
||||
g = nx.DiGraph()
|
||||
for c in claims:
|
||||
g.add_node(c.statement, source=c.source, conf=c.confidence)
|
||||
for contra in c.contradicts:
|
||||
g.add_edge(c.statement, contra, type="contradicts")
|
||||
return g
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 수십 개 sources | RAG + hierarchical summarize |
|
||||
| Conflicting claims | Structured extraction + LLM judge |
|
||||
| Novel framework needed | Generative synthesis |
|
||||
| Quantitative pooling | Meta-analysis stats |
|
||||
|
||||
**기본값**: RAG + structured extraction + claim graph.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Research Methodology]] · [[Information Retrieval]]
|
||||
- 변형: [[Systematic Review]] · [[Meta-Analysis]]
|
||||
- 응용: [[RAG]] · [[Knowledge Graph]]
|
||||
- Adjacent: [[Critical Thinking]] · [[Sense-Making]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: literature review, competitive analysis, contradictory source reconciliation.
|
||||
**언제 X**: domain-novel concept invention without grounding — hallucination 위험.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Cherry-picking**: 매 confirming source 만 select.
|
||||
- **Source-blind synthesis**: citation 없이 claim 통합 → traceability 상실.
|
||||
- **Premature consensus**: conflict 무시하고 단일 narrative.
|
||||
- **Hallucinated alignment**: LLM 이 entity 임의 동일시.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (PRISMA 2020, Cochrane Handbook 6.4, Anthropic RAG cookbook).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 5-step pipeline + RAG/extraction 패턴 |
|
||||
|
||||
@@ -2,69 +2,147 @@
|
||||
id: wiki-2026-0508-lighting-composition
|
||||
title: "Lighting & Composition"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Cinematography, Visual Composition, Lighting Design]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [photography, cinematography, generative-AI, prompt-engineering]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: prompt
|
||||
framework: FLUX-Sora-Veo
|
||||
---
|
||||
|
||||
**Exploring Composition Techniques**
|
||||
# Lighting & Composition
|
||||
|
||||
I am now delving into diverse compositional techniques like bird's eye and worm's eye views, low and high angles, and Dutch angles, along with over-the-shoulder perspectives. I'm also examining how lens choices (85mm, 50mm, 35mm, macro, tilt-shift, fisheye) influence the final image. I'm noting the impact of shallow depth of field, emphasizing visual focus, along with elements like symmetry, negative space, the rule of thirds, and centered compositions. I am considering these in the Korean report.
|
||||
## 매 한 줄
|
||||
> **"매 image / video 의 emotional weight 의 90%는 lighting + composition"**. 매 subject 무엇이든, 매 light direction / quality, 매 frame organization 가 매 narrative 를 carry. 매 2026 의 generative AI (FLUX 1.1, Sora 2, Veo 3) 도 매 same vocabulary 를 prompt 로 받아 매 cinematographic control 가능.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 lighting 의 axes
|
||||
- **Direction**: front / side / back / top / bottom (각 emotional valence 다름).
|
||||
- **Quality**: hard (sharp shadows) vs soft (diffused).
|
||||
- **Color temperature**: warm (3000K) vs cool (6500K).
|
||||
- **Ratio**: key:fill ratio (1:1 flat, 4:1 dramatic).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Shift]]
|
||||
* [[_report]]
|
||||
### 매 composition 의 axes
|
||||
- **Rule of thirds**: 매 subject 매 third lines 의 intersection.
|
||||
- **Leading lines**: 매 viewer's eye 의 directing.
|
||||
- **Negative space**: 매 emptiness 가 carry meaning.
|
||||
- **Depth layers**: foreground / mid / background.
|
||||
- **Aspect ratio**: 16:9 (cinematic), 9:16 (mobile), 1:1 (square), 2.39:1 (anamorphic).
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
### 매 응용
|
||||
1. **Photography**: portrait / product / landscape lighting setups.
|
||||
2. **Cinematography**: 매 scene mood 의 establishing.
|
||||
3. **Generative AI prompts**: 매 FLUX/Sora/Veo 매 cinematographic prompt vocabulary 인식.
|
||||
4. **UI design**: 매 hero image direction selection.
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
## 💻 패턴
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### Three-point lighting prompt
|
||||
```
|
||||
A portrait of a software engineer, three-point lighting:
|
||||
key light from camera-left at 45 degrees (soft, 5500K),
|
||||
fill light from camera-right at 1:2 ratio,
|
||||
backlight rim from upper-right (warm 3200K),
|
||||
shallow depth of field, 85mm lens equivalent,
|
||||
shot on Arri Alexa 35.
|
||||
```
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
### Rembrandt lighting (FLUX 1.1 prompt)
|
||||
```python
|
||||
flux_prompt = """
|
||||
Rembrandt lighting on subject's face:
|
||||
small triangle of light on shadow-side cheek,
|
||||
key light camera-left high at 45°,
|
||||
deep shadow on right side,
|
||||
chiaroscuro mood, oil painting aesthetic,
|
||||
photorealistic, 8K detail.
|
||||
"""
|
||||
```
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
### Golden hour video (Sora 2)
|
||||
```python
|
||||
sora_prompt = {
|
||||
"shot": "tracking shot through wheat field",
|
||||
"lighting": "golden hour, sun low at 15° angle camera-back-left, "
|
||||
"warm 2800K, long shadows, lens flare",
|
||||
"composition": "rule of thirds, horizon on lower third, "
|
||||
"leading lines from wheat rows toward subject",
|
||||
"camera": "Steadicam, 24fps, 35mm anamorphic, T2.0",
|
||||
"duration_s": 8,
|
||||
}
|
||||
```
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### Composition checker (CV-based QA)
|
||||
```python
|
||||
import cv2
|
||||
import numpy as np
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
def rule_of_thirds_score(img: np.ndarray) -> float:
|
||||
"""매 saliency map peak 매 third-line proximity."""
|
||||
h, w = img.shape[:2]
|
||||
saliency = cv2.saliency.StaticSaliencyFineGrained_create()
|
||||
_, sal = saliency.computeSaliency(img)
|
||||
peak_y, peak_x = np.unravel_index(sal.argmax(), sal.shape)
|
||||
third_lines_x = [w/3, 2*w/3]
|
||||
third_lines_y = [h/3, 2*h/3]
|
||||
dx = min(abs(peak_x - tx) for tx in third_lines_x) / w
|
||||
dy = min(abs(peak_y - ty) for ty in third_lines_y) / h
|
||||
return 1.0 - min(dx, dy) * 2 # higher = better composition
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Color temp grading (Veo 3 prompt augmentation)
|
||||
```python
|
||||
def grade_prompt(base: str, mood: str) -> str:
|
||||
grades = {
|
||||
"warm_nostalgic": "teal-orange grade, warm midtones (3200K), cool shadows",
|
||||
"cold_clinical": "desaturated blues, 6500K key, high-key flat lighting",
|
||||
"noir": "high-contrast B&W, low-key, single hard source, 4:1 ratio",
|
||||
}
|
||||
return f"{base} | grade: {grades[mood]}"
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
## 매 결정 기준
|
||||
| Mood | Lighting | Composition |
|
||||
|---|---|---|
|
||||
| Heroic | Backlight rim + low-key fill | Low angle, centered |
|
||||
| Intimate | Soft key, high ratio | Close-up, off-center |
|
||||
| Tense | Hard side light, deep shadow | Dutch tilt, asymmetric |
|
||||
| Whimsical | Bright fill, warm tones | Wide, symmetrical |
|
||||
| Documentary | Available light | Eye-level, rule of thirds |
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
**기본값**: 매 three-point + rule of thirds — 매 safe baseline.
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
## 🔗 Graph
|
||||
- 부모: [[Visual-Design]] · [[Cinematography]]
|
||||
- 변형: [[Rembrandt-Lighting]] · [[Chiaroscuro]] · [[Rule-of-Thirds]]
|
||||
- 응용: [[Generative-Image-Prompting]] · [[Video-Production]]
|
||||
- Adjacent: [[Color-Theory]] · [[Camera-Movement]]
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 image/video prompt engineering — 매 cinematographic vocabulary 매 quality lift 큼.
|
||||
**언제 X**: 매 abstract / non-representational generation — vocabulary 의 X.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
## ❌ 안티패턴
|
||||
- **Flat front lighting**: 매 amateur look — depth loss.
|
||||
- **Centered everything**: 매 visual boring.
|
||||
- **Mixed color temps unintentional**: 매 amateur giveaway.
|
||||
- **Over-prompting**: 매 50+ tokens 의 lighting → 매 model confusion.
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Brown *Cinematography*; Block *Visual Story*; FLUX 1.1 prompt guide; Sora 2 system card 2025).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — lighting/composition vocabulary + 2026 generative AI prompts |
|
||||
|
||||
@@ -1,63 +1,200 @@
|
||||
---
|
||||
id: wiki-2026-0508-lucas-kanade-method
|
||||
title: Lucas Kanade Method
|
||||
title: Lucas-Kanade Method
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [CV-LUCAS-001]
|
||||
aliases: [LK Optical Flow, Lucas-Kanade Tracker, KLT Tracker]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: ["Computer Vision|[Computer-Vision", optical-flow, lucas-kanade, image-Processing, feature-tracking]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [computer-vision, optical-flow, tracking, classical-cv]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: opencv
|
||||
---
|
||||
|
||||
# Lucas-Kanade Method (루카스-카나데 방법)
|
||||
# Lucas-Kanade Method
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "주변 픽셀들은 함께 움직인다는 가정하에, 찰나의 변화 속에서 물체의 흐름(Flow)을 포착하라" — 인접한 픽셀들이 유사한 움직임을 가진다는 국소적 일관성(Local Coherence)을 가정한 후, 최소제곱법을 통해 두 프레임 사이의 픽셀 이동량을 추정하는 옵티컬 플로우(Optical Flow) 알고리즘.
|
||||
## 매 한 줄
|
||||
> **"매 small window, 매 brightness constancy, 매 linear least squares 의 motion vector"**. Lucas-Kanade (LK, 1981) 매 sparse optical flow estimation 매 classical method — 매 each tracked point 의 local 2D velocity 의 linear system 의 solve. 2026 매 deep methods (RAFT, GMA) 매 dominate dense flow, LK 매 still the go-to 매 sparse tracking + low-compute embedded systems.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Spatial Consistency and Gradient Descent" — 영상의 밝기가 일정하게 유지된다고 가정(Brightness Constancy)하고, 이미지의 기울기(Gradient) 정보를 활용하여 오차를 최소화하는 방향으로 물체의 이동 궤적을 추적하는 패턴.
|
||||
- **핵심 가정:**
|
||||
- **Brightness Constancy:** 물체의 밝기는 움직여도 변하지 않음.
|
||||
- **Temporal Persistence:** 프레임 간 이동량이 매우 작음.
|
||||
- **Spatial Coherence:** 특정 픽셀의 이웃들은 같은 방향으로 이동함.
|
||||
- **의의:** 영상 내 특징점 추적, 비디오 안정화, 자율주행차의 장애물 감지 등 실시간 컴퓨터 비전 시스템의 움직임 분석을 위한 가장 기초적이고 효율적인 도구.
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 이동량이 큰 경우에는 오차가 심하다는 한계가 있으나, 피라미드 구조(Image Pyramid)를 통해 이미지를 축소하며 단계적으로 추적하는 방식으로 현대적 한계를 극복함.
|
||||
- **정책 변화:** Skybound 프로젝트의 적 기체 추적 및 VFX 효과 구현 시, 프레임 간의 자연스러운 움직임 보간을 위해 루카스-카나데 기반의 옵티컬 플로우 원리를 활용함.
|
||||
### 매 Assumptions
|
||||
1. **Brightness constancy**: I(x, y, t) ≈ I(x+dx, y+dy, t+dt).
|
||||
2. **Small motion**: Taylor expand 매 first-order valid.
|
||||
3. **Spatial coherence**: small window 매 same motion 의 share.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Least-Squares-Methods|Least-Squares-Methods]], [[Pattern-Recognition|Pattern-Recognition]]-Foundations, Kalman-Filter-and-State-Tracking, [[Robotics-Foundations|Robotics-Foundations]]
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Lucas-Kanade-Method.md
|
||||
### 매 The equation
|
||||
- 매 I_x · u + I_y · v + I_t = 0 (optical flow constraint, per pixel).
|
||||
- 매 underdetermined (2 unknowns, 1 equation) → window aggregation.
|
||||
- 매 N pixels in window → over-determined linear system A·d = b.
|
||||
- 매 d = (Aᵀ A)⁻¹ Aᵀ b (least squares).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 Failure modes
|
||||
- **Aperture problem**: window 매 1D structure (edge) → A^T A singular.
|
||||
- **Large motion**: Taylor first-order 매 break — 매 pyramid LK 의 fix.
|
||||
- **Illumination change**: brightness constancy 매 violate.
|
||||
- **Occlusion**: tracked point 매 disappear — 매 forward-backward check.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 응용
|
||||
1. Sparse feature tracking (KLT in SLAM).
|
||||
2. Video stabilization (camera motion estimation).
|
||||
3. Embedded vision (drone OF sensor).
|
||||
4. Initial track for deep refinement.
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 1: OpenCV calcOpticalFlowPyrLK
|
||||
```python
|
||||
import cv2
|
||||
import numpy as np
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
cap = cv2.VideoCapture("video.mp4")
|
||||
ret, prev = cap.read()
|
||||
prev_gray = cv2.cvtColor(prev, cv2.COLOR_BGR2GRAY)
|
||||
p0 = cv2.goodFeaturesToTrack(prev_gray, maxCorners=200, qualityLevel=0.01, minDistance=10)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
while True:
|
||||
ret, frame = cap.read()
|
||||
if not ret:
|
||||
break
|
||||
gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
|
||||
p1, status, err = cv2.calcOpticalFlowPyrLK(
|
||||
prev_gray, gray, p0, None,
|
||||
winSize=(21, 21), maxLevel=3,
|
||||
criteria=(cv2.TERM_CRITERIA_EPS | cv2.TERM_CRITERIA_COUNT, 30, 0.01),
|
||||
)
|
||||
good = p1[status.flatten() == 1]
|
||||
prev_gray = gray
|
||||
p0 = good.reshape(-1, 1, 2)
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 2: Vanilla LK (educational)
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
def lucas_kanade(I1, I2, points, window=15):
|
||||
"""매 each point 의 (u, v) flow vector 의 return."""
|
||||
half = window // 2
|
||||
Ix = np.gradient(I1, axis=1)
|
||||
Iy = np.gradient(I1, axis=0)
|
||||
It = I2.astype(float) - I1.astype(float)
|
||||
flow = np.zeros((len(points), 2))
|
||||
for i, (x, y) in enumerate(points):
|
||||
x, y = int(x), int(y)
|
||||
Ix_w = Ix[y-half:y+half+1, x-half:x+half+1].flatten()
|
||||
Iy_w = Iy[y-half:y+half+1, x-half:x+half+1].flatten()
|
||||
It_w = It[y-half:y+half+1, x-half:x+half+1].flatten()
|
||||
A = np.stack([Ix_w, Iy_w], axis=1)
|
||||
b = -It_w
|
||||
if np.linalg.matrix_rank(A.T @ A) < 2:
|
||||
continue # aperture problem
|
||||
d, *_ = np.linalg.lstsq(A, b, rcond=None)
|
||||
flow[i] = d
|
||||
return flow
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 3: Pyramid LK (large motion)
|
||||
```python
|
||||
def pyramid_lk(I1, I2, points, levels=4, window=15):
|
||||
"""매 coarse-to-fine — 매 large motion 의 handle."""
|
||||
pyr1 = [I1]
|
||||
pyr2 = [I2]
|
||||
for _ in range(levels - 1):
|
||||
pyr1.append(cv2.pyrDown(pyr1[-1]))
|
||||
pyr2.append(cv2.pyrDown(pyr2[-1]))
|
||||
flow = np.zeros((len(points), 2))
|
||||
pts = points / (2 ** (levels - 1))
|
||||
for level in reversed(range(levels)):
|
||||
d = lucas_kanade(pyr1[level], pyr2[level], pts, window)
|
||||
flow = flow * 2 + d
|
||||
if level > 0:
|
||||
pts = pts * 2 + d
|
||||
return flow
|
||||
```
|
||||
|
||||
### Pattern 4: Forward-backward consistency
|
||||
```python
|
||||
def fb_consistency(I1, I2, points, threshold=1.0):
|
||||
"""매 forward 의 track 매 backward 의 verify — 매 lost point 의 reject."""
|
||||
p1 = points
|
||||
p2, st_fwd, _ = cv2.calcOpticalFlowPyrLK(I1, I2, p1, None)
|
||||
p1_back, st_bwd, _ = cv2.calcOpticalFlowPyrLK(I2, I1, p2, None)
|
||||
err = np.linalg.norm(p1 - p1_back, axis=2).flatten()
|
||||
valid = (st_fwd.flatten() == 1) & (st_bwd.flatten() == 1) & (err < threshold)
|
||||
return p2[valid]
|
||||
```
|
||||
|
||||
### Pattern 5: KLT corner re-seeding
|
||||
```python
|
||||
def klt_track_with_reseed(cap, max_corners=200, min_count=50):
|
||||
ret, prev = cap.read()
|
||||
prev_gray = cv2.cvtColor(prev, cv2.COLOR_BGR2GRAY)
|
||||
p0 = cv2.goodFeaturesToTrack(prev_gray, max_corners, 0.01, 10)
|
||||
while True:
|
||||
ret, frame = cap.read()
|
||||
if not ret:
|
||||
break
|
||||
gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
|
||||
p1, st, _ = cv2.calcOpticalFlowPyrLK(prev_gray, gray, p0, None)
|
||||
good = p1[st.flatten() == 1]
|
||||
if len(good) < min_count:
|
||||
new_pts = cv2.goodFeaturesToTrack(gray, max_corners, 0.01, 10)
|
||||
good = np.concatenate([good, new_pts.reshape(-1, 2)])
|
||||
p0 = good.reshape(-1, 1, 2).astype(np.float32)
|
||||
prev_gray = gray
|
||||
yield good
|
||||
```
|
||||
|
||||
### Pattern 6: LK 의 deep flow init (2026 hybrid)
|
||||
```python
|
||||
# 매 deep model (RAFT) 매 dense flow 의 give — 매 LK 의 sub-pixel refine.
|
||||
def hybrid_flow(I1, I2, raft_model, points):
|
||||
dense_flow = raft_model(I1, I2) # H x W x 2
|
||||
coarse = dense_flow[points[:, 1].astype(int), points[:, 0].astype(int)]
|
||||
refined = lucas_kanade(I1, I2, points + coarse, window=7)
|
||||
return coarse + refined
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Sparse feature tracking | KLT (LK + good features). |
|
||||
| Large motion | Pyramid LK. |
|
||||
| Dense flow + GPU | RAFT / GMA (deep). |
|
||||
| Embedded / ms latency | LK 의 stick. |
|
||||
| Robust tracking | LK + forward-backward + RANSAC. |
|
||||
|
||||
**기본값**: `cv2.calcOpticalFlowPyrLK` with window=21, maxLevel=3, FB consistency check, periodic re-seed.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Optical-Flow]] · [[Computer-Vision]]
|
||||
- 변형: [[Pyramid-LK]] · [[Affine-LK]] · [[Inverse-Compositional-LK]]
|
||||
- 응용: [[KLT-Tracker]] · [[Visual-SLAM]] · [[Video-Stabilization]]
|
||||
- Adjacent: [[Horn-Schunck]] · [[RAFT]] · [[GMA]] · [[Good-Features-To-Track]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Code generation for embedded vision, classical CV pipelines, baseline implementation before deep methods.
|
||||
**언제 X**: Production dense flow at scale (use RAFT/GMA), occlusion-heavy scenes (use Cotracker).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **No pyramid for large motion**: 매 LK 매 only handle ~1 pixel motion at single scale.
|
||||
- **Track forever without re-seed**: 매 features 매 disappear → tracking dies.
|
||||
- **Ignore aperture problem**: 매 edge-only window → spurious flow.
|
||||
- **No FB check**: 매 lost points 매 silently track 매 noise.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified: Lucas & Kanade (1981) "An iterative image registration technique", Bouguet (2000) pyramid LK, OpenCV docs.
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content with vanilla LK, pyramid LK, FB consistency, deep hybrid 2026 |
|
||||
|
||||
@@ -2,92 +2,165 @@
|
||||
id: wiki-2026-0508-mece-pyramid-principle
|
||||
title: MECE + Pyramid Principle
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [MECE, Pyramid Principle, 미씨 + 피라미드, McKinsey Framework]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [problem-solving, communication, structure, consulting, writing]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: methodology
|
||||
framework: mckinsey
|
||||
---
|
||||
|
||||
# [[MECE|MECE]] + [[Pyramid Principle|Pyramid Principle]]
|
||||
# MECE + Pyramid Principle
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
바바라 민토(Barbara Minto)가 매킨지에서 고안한 논리적 글쓰기 및 커뮤니케이션 프레임워크와 그 핵심 사고 원칙입니다. 핵심 결론이나 답변을 맨 먼저 제시하는 '피라미드 원칙'과 이를 뒷받침하는 근거들을 중복과 누락 없이 '상호 배타적이고 전체 포괄적(MECE)'으로 구성하는 방법을 결합하여 전달력을 극대화합니다. 복잡한 비즈니스 문제나 데이터를 명확하게 구조화하고, 바쁜 임원진의 시간을 절약하며 설득력을 높이는 데 필수적으로 사용됩니다.
|
||||
## 매 한 줄
|
||||
> **"매 MECE 는 thinking, Pyramid 는 communication"**. MECE (Mutually Exclusive, Collectively Exhaustive) 는 문제 분해 원칙, Pyramid Principle 은 결론-우선 communication structure. Barbara Minto (1973) 의 McKinsey 표준. 2026 LLM 시대에도 prompt structuring / report writing 의 backbone.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **피라미드 원칙 (Pyramid Principle):** 독자나 청중은 하향식(Top-down)으로 정보를 이해하기 원하므로, **핵심 결론(Answer)을 최상단에 두고, 그 아래에 이를 뒷받침하는 핵심 주장(Arguments)을, 가장 아래에 구체적인 데이터(Evidence/Data)를 배치**하는 계층적 구조입니다 [1-13].
|
||||
* **SCQA 스토리텔링 도입부:** 서론은 상황(Situation), 전개/문제(Complication), 질문(Question), 답변(Answer)의 흐름으로 구성하여, 청중이 이미 아는 사실에서 출발해 핵심 주제로 자연스럽게 유도합니다 [14-21].
|
||||
* **MECE 원칙 (Mutually Exclusive, Collectively Exhaustive):** 피라미드를 구성하는 하위 항목들은 서로 겹치지 않아야 하며(상호 배타적), 합쳤을 때 전체를 포괄해야(전체 포괄적) 합니다 [1, 22-29].
|
||||
* **수직적 및 수평적 논리 (Vertical & Horizontal [[Logic|Logic]]):** 수직적으로 상위 메시지는 하위 메시지의 요약이어야 하며 하위 메시지는 상위 메시지가 유발한 '왜?(Why)'나 '어떻게?(How)'에 대한 답변이 되어야 합니다 [30-33]. 수평적으로는 항목들이 귀납적(Inductive) 혹은 연역적(Deductive) 논리나 시간, 구조, 중요도 순으로 일관되게 정렬되어야 합니다 [3, 32, 34-38].
|
||||
* **매직 넘버 3 ([[Rule of Three|Rule of Three]]):** 인간의 단기 기억 한계를 고려하여, 한 그룹을 구성하는 핵심 주장이나 요소의 개수는 가급적 3~4개로 제한하는 것이 가장 효과적입니다 [10, 30, 31, 39-42].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[BLUF (Bottom Line Up Front)|BLUF (Bottom Line Up Front]], SCQA Framework, [[Issue Tree|Issue Tree]]
|
||||
- **Projects/Contexts:** 경영 컨설팅 문제 해결 및 보고서 작성, C-레벨/임원진 대상 전략 프레젠테이션
|
||||
- **Contradictions/Notes:** MECE 원칙은 복잡한 상호작용이 존재하는 시스템적 문제(ComplexSystems)를 다룰 때는 현실을 과도하게 단순화하고 변수 간의 피드백 루프를 숨길 위험이 있습니다. 이러한 경우 시스템 사고([[Systems Thinking|Systems Thinking]]) 등과 병행해야 합니다 [43-47]. 또한 하향식으로 결론을 내리꽂는 방식은 협력적 아이디어 도출이 필요한 디자인 씽킹(Design Thinking) 상황에는 부적합할 수 있습니다 [48-50].
|
||||
### 매 MECE
|
||||
- **Mutually Exclusive**: 각 카테고리 겹침 없음.
|
||||
- **Collectively Exhaustive**: 모든 가능성 포함.
|
||||
- 2x2 matrix, decision tree, issue tree 의 기본.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 Pyramid Principle
|
||||
- **Top**: governing thought / answer first.
|
||||
- **Middle**: 3-5 supporting arguments (MECE).
|
||||
- **Bottom**: data, evidence, examples.
|
||||
- **SCQA opener**: Situation → Complication → Question → Answer.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Consulting deliverable / executive summary.
|
||||
2. Research paper structure.
|
||||
3. LLM prompt design (system + sections).
|
||||
4. Code review write-up.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Issue tree decomposition
|
||||
```python
|
||||
class Node:
|
||||
def __init__(self, q, children=None):
|
||||
self.q = q
|
||||
self.children = children or []
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
# Profit decline 분석
|
||||
tree = Node("Why is profit declining?", [
|
||||
Node("Revenue down?", [
|
||||
Node("Volume down?"),
|
||||
Node("Price down?"),
|
||||
]),
|
||||
Node("Cost up?", [
|
||||
Node("COGS up?"),
|
||||
Node("OpEx up?"),
|
||||
]),
|
||||
])
|
||||
# 매 each level MECE
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### MECE validator
|
||||
```python
|
||||
def is_mece(categories: list[set]) -> tuple[bool, bool]:
|
||||
universe = set.union(*categories)
|
||||
# ME: pairwise disjoint
|
||||
me = all(not (a & b) for i, a in enumerate(categories)
|
||||
for b in categories[i+1:])
|
||||
# CE: union covers universe
|
||||
ce = set.union(*categories) == universe
|
||||
return me, ce
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pyramid outliner (LLM)
|
||||
```python
|
||||
def pyramid_outline(question: str) -> dict:
|
||||
prompt = f"""Structure as Pyramid Principle:
|
||||
1. Governing answer (1 sentence).
|
||||
2. 3 MECE supporting arguments.
|
||||
3. For each, 2-3 evidence bullets.
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
Question: {question}
|
||||
Output JSON."""
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2048,
|
||||
messages=[{"role": "user", "content": prompt}],
|
||||
)
|
||||
return json.loads(resp.content[0].text)
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### SCQA opener generator
|
||||
```python
|
||||
def scqa(situation, complication, question, answer):
|
||||
return (
|
||||
f"**Situation**: {situation}\n"
|
||||
f"**Complication**: {complication}\n"
|
||||
f"**Question**: {question}\n"
|
||||
f"**Answer**: {answer}"
|
||||
)
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### 2x2 framework
|
||||
```python
|
||||
def matrix_2x2(items, axis_x, axis_y):
|
||||
quadrants = {"high-high": [], "high-low": [],
|
||||
"low-high": [], "low-low": []}
|
||||
for item in items:
|
||||
x = "high" if axis_x(item) else "low"
|
||||
y = "high" if axis_y(item) else "low"
|
||||
quadrants[f"{x}-{y}"].append(item)
|
||||
return quadrants
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Top-down report builder
|
||||
```python
|
||||
def build_report(answer, args: list[dict]):
|
||||
out = [f"# {answer}\n"]
|
||||
for i, arg in enumerate(args, 1):
|
||||
out.append(f"## {i}. {arg['claim']}")
|
||||
for ev in arg["evidence"]:
|
||||
out.append(f"- {ev}")
|
||||
return "\n".join(out)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Problem decomposition | Issue tree (MECE at each level) |
|
||||
| Executive deck | Pyramid + SCQA + 3 args |
|
||||
| Categorization | 2x2 matrix or MECE list |
|
||||
| LLM task | Pyramid in system prompt |
|
||||
|
||||
**기본값**: Issue tree 분석 → Pyramid 로 communicate.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Problem Solving Process]] · [[Critical Thinking]]
|
||||
- 변형: [[Pyramid Principle]] · [[Issue Tree]]
|
||||
- 응용: [[Consulting]] · [[Technical Writing]]
|
||||
- Adjacent: [[First Principles Thinking]] · [[Hypothesis-Driven]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: report drafting, prompt structuring, decomposition assistance.
|
||||
**언제 X**: creative / divergent ideation — 매 over-constrains.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **False MECE**: overlap 있는데 disjoint 라 가정.
|
||||
- **Bottom-up dump**: data 먼저 늘어놓고 conclusion 마지막 → executive 가 lost.
|
||||
- **Over-decomposition**: 7+ branches at one level → cognitive overload.
|
||||
- **Forced 3 categories**: 매 항상 3 으로 강제 → exhaustiveness 깨짐.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Minto 1973 "The Pyramid Principle", McKinsey training docs, HBR 2019).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — issue tree + SCQA + 2x2 패턴 |
|
||||
|
||||
@@ -2,73 +2,32 @@
|
||||
id: wiki-2026-0508-mmorpg-영속적-세계와-자원-관리
|
||||
title: MMORPG 영속적 세계와 자원 관리
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
status: duplicate
|
||||
canonical_id: mmorpg-persistent-world
|
||||
duplicate_of: "[[MMORPG Persistent World Design]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, mmorpg, game-design]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[MMORPG 영속적 세계와 자원 관리|MMORPG 영속적 세계와 자원 관리]]
|
||||
# MMORPG 영속적 세계와 자원 관리
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
MMORPG의 영속적 세계는 플레이어가 접속을 종료한 오프라인 상태일 때도 지속적으로 존재하고 진화하는 가상 환경을 의미합니다 [1]. 이러한 게임의 주요 경제적 목표는 플레이어 캐릭터의 무한한 성장과 자산 축적이며, 이를 뒷받침하기 위해 수요와 공급에 기반한 '살아있는 경제(Living economy)'가 필수적으로 요구됩니다 [2, 3]. 성공적인 가상 경제를 유지하려면 자원의 생성인 '수도꼭지(Faucets)'와 자원의 소멸인 '배수구(Sinks)'의 속도를 정교하게 조절하여, 인플레이션이나 유동성 위기 없이 경제적 평형을 유지하는 자원 관리가 핵심적입니다 [3, 4].
|
||||
> **이 문서는 [[MMORPG Persistent World Design]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **영속적 세계와 살아있는 경제 형성**
|
||||
MMORPG는 플레이어의 활동 유무와 무관하게 진화하는 영속적인(Persistent) 세계를 배경으로 합니다 [1]. 이 세계 안에서 플레이어가 획득하는 가상 아이템과 통화는 확실한 가치를 지니며, 때로는 현실 세계의 경제와 교차하기도 하는 '살아있는 경제'를 구성합니다 [2]. MMORPG의 경제적 목표는 본질적으로 캐릭터의 무한한 성장과 자산의 축적에 맞추어져 있습니다 [3].
|
||||
## 핵심 요약
|
||||
- **Persistent state**: server-authoritative DB, player offline 시에도 world state 진행.
|
||||
- **Resource sinks/faucets**: economy 균형 (gold sink: repair, faucet: quest reward).
|
||||
- **Sharding**: per-region 또는 dynamic instance 로 scalability.
|
||||
|
||||
* **자원의 생성(수도꼭지)과 소멸(배수구) 관리**
|
||||
성공적인 가상 경제 시스템의 기본 아키텍처는 재화가 무에서 유입되는 '수도꼭지(Faucets)'와 재화가 시스템에서 영구적으로 삭제되는 '하드 싱크(Hard Sinks)' 간의 평형을 맞추는 것입니다 [4, 5]. 이론적으로 무한히 생성될 수 있는 자원의 유입과 소비 속도를 조절하지 못하면 통화의 급격한 인플레이션이 발생하거나 경제 생태계가 붕괴할 수 있습니다 [4, 6].
|
||||
## 🔗 Graph
|
||||
- 부모: [[MMORPG Persistent World Design]] (canonical)
|
||||
|
||||
* **플레이어 주도 경제와 유동성 관리의 실제 사례**
|
||||
* **알비온 온라인과 EVE 온라인**: 이 게임들은 철저히 플레이어 기반의 경제 시스템을 특징으로 합니다 [3]. 특히 '알비온 온라인'은 몬스터가 드롭하는 전리품을 플레이어가 직접 제작 및 판매한 아이템과 연동되도록 하는 '암시장' 시스템으로 공급량을 조절하며, '글로벌 할인'이라는 거시경제 자동 조절 장치(서모스탯)를 통해 통화 가치를 안정시킵니다 [3].
|
||||
* **뉴 월드(New World)의 유동성 함정**: 게임 초기 고레벨 구간에서 재화의 공급원(수도꼭지)은 줄어든 반면, 주택 세금이나 수리비 같은 싱크가 지나치게 공격적으로 설정된 사례가 있습니다 [3]. 이는 플레이어들이 재화 지출을 극도로 꺼리게 만들어 유동성 함정(Liquidity trap)을 유발했으며, 공급과 소비의 속도 조절이 게임 경제 설계에서 얼마나 치명적인 영향을 미치는지 보여줍니다 [3].
|
||||
|
||||
* **인플레이션 억제와 프리미엄 통화 브릿지 전략**
|
||||
MMORPG에서 무한정 자원이 풀려 인플레이션이 발생하는 것을 막고 경제적 평등을 유도하기 위해 새로운 프리미엄 통화(예: 월드 오브 워크래프트의 WoW 토큰, EVE 온라인의 PLEX) 브릿지를 도입하는 것이 널리 쓰이는 전략입니다 [7-9]. 인게임 재화로 구매 가능한 프리미엄 아이템을 통해 부유한 플레이어의 골드를 대량으로 회수(Sink)할 수 있으며, 불법적인 골드 파밍으로 인해 유발되는 인플레이션을 억제하는 데 강력한 효과를 발휘합니다 [8, 9].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** `게임 경제의 수도꼭지와 배수구 (Faucets and Sinks`, `[[가상 경제 인플레이션(Virtual Economy Inflation)|가상 경제 인플레이션 (Virtual Economy Inflation]]`
|
||||
- **Projects/Contexts:** `[[알비온 온라인(Albion Online)|알비온 온라인 (Albion Online]]`, `EVE 온라인 (EVE Online)`, `뉴 월드 (New World)`, `[[월드 오브 워크래프트(World of Warcraft)|월드 오브 워크래프트 (World of Warcraft]]`
|
||||
- **Contradictions/Notes:** 통화량을 직접적으로 줄여 재화 가치를 방어하기 위해 배수구(Sink)의 도입은 필수적이지만 [5], '뉴 월드'의 사례에서 보듯 너무 공격적인 세금이나 수리비 책정은 오히려 플레이어의 지출을 경색시키는 유동성 함정(Liquidity Trap)을 유발할 수 있으므로 수요와 공급에 대한 섬세한 속도 조절 밸런싱이 요구됩니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
|
||||
## 🤖 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 |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,91 +2,167 @@
|
||||
id: wiki-2026-0508-mapreduce
|
||||
title: MapReduce
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MARE-001]
|
||||
aliases: [맵리듀스, Hadoop MR, Map-Reduce]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, mapreduce, Distributed-Computing, Big-Data, Parallel-Processing, cluster-computing]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [distributed, big-data, parallel, hadoop, batch]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: hadoop-spark
|
||||
---
|
||||
|
||||
# [[MapReduce|MapReduce]]
|
||||
# MapReduce
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "거대한 데이터를 작게 쪼개어 정복하라: 혼자서는 감당 못 할 방대한 데이터를 수천 대의 컴퓨터에 나누어 준 뒤(Map), 각자 계산한 결과들 중에서 필요한 것만 뽑아 다시 하나로 합치는(Reduce) 분산 처리의 표준 문법."
|
||||
## 매 한 줄
|
||||
> **"매 split → map → shuffle → reduce"**. MapReduce (Dean & Ghemawat, Google 2004) 는 대규모 batch 처리 의 functional programming 모델. 2026 perspective 에서 raw Hadoop MR 은 legacy, Spark / Flink / BigQuery / Beam 이 후속 표준.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
맵리듀스(MapReduce)는 대규모 데이터 세트를 병렬로 처리하기 위한 프로그래밍 모델이자 프레임워크입니다. (구글에 의해 대중화)
|
||||
## 매 핵심
|
||||
|
||||
1. **두 단계의 마법**:
|
||||
* **Map Step**: 입력 데이터를 (Key, Value) 쌍으로 변환하여 작은 작업들로 분산.
|
||||
* **Reduce Step**: 같은 Key를 가진 결과를 합산(Aggregating)하여 최종 결과 생성.
|
||||
2. **장점**:
|
||||
* **[[Scalability|Scalability]]**: 컴퓨터를 추가할수록 처리 능력이 선형적으로 증가. (Scalability와 연결)
|
||||
* **[[Fault-Tolerance|Fault-Tolerance]]**: 한 대의 컴퓨터가 고장 나도 다른 컴퓨터가 작업을 대신 수행. (Fault-Tolerance와 연결)
|
||||
### 매 4 phase
|
||||
- **Split**: input → fixed-size shards (HDFS block 64-128MB).
|
||||
- **Map**: (k1, v1) → list[(k2, v2)]. Stateless, parallelizable.
|
||||
- **Shuffle/Sort**: same k2 grouped to same reducer.
|
||||
- **Reduce**: (k2, list[v2]) → list[(k3, v3)].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 모든 빅데이터 처리를 맵리듀스 정책으로 해결하려 했으나, 현대 정책은 디스크 기반의 느린 맵리듀스보다 메모리 기반의 빠른 'Apache Spark 정책'이나 '실시간 스트리밍 처리 정책'을 선호함(RL Update).
|
||||
- **정책 변화(RL Update)**: 단순히 데이터를 세는 정책을 넘어, 분산 환경에서 거대 인공지능 모델을 학습시키는 '분산 딥러닝 정책'으로 그 개념적 토대가 확장되어 계승됨. ([[High-Performance Computing (HPC)|High-Performance Computing (HPC)]]와 연결)
|
||||
### 매 design principles
|
||||
- **Data locality**: code → data, not data → code.
|
||||
- **Fault tolerance**: re-execute failed tasks (idempotent map/reduce).
|
||||
- **Speculative execution**: slow tasks 의 backup copy.
|
||||
- **Immutable inputs**: re-runnable.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scalability|Scalability]], [[Fault-Tolerance|Fault-Tolerance]], [[High-Performance Computing (HPC)|High-Performance Computing (HPC)]], [[Analysis|Analysis]], [[Information-Society|Information-Society]]
|
||||
- **Modern Tech/Tools**: Hadoop (HDFS), Apache Spark, Google File[[_system|system]] (GFS), Hive.
|
||||
---
|
||||
### 매 응용
|
||||
1. Log analysis / web indexing (original use case).
|
||||
2. ETL pipelines.
|
||||
3. ML feature aggregation.
|
||||
4. Data warehouse build.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Word count (canonical)
|
||||
```python
|
||||
from collections import defaultdict
|
||||
from itertools import groupby
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def map_phase(doc_id, text):
|
||||
for word in text.split():
|
||||
yield (word.lower(), 1)
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def reduce_phase(word, counts):
|
||||
yield (word, sum(counts))
|
||||
|
||||
- **정보 상태:** 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
|
||||
def mapreduce(docs):
|
||||
# Map
|
||||
pairs = [kv for did, t in docs for kv in map_phase(did, t)]
|
||||
# Shuffle
|
||||
pairs.sort(key=lambda x: x[0])
|
||||
grouped = {k: [v for _, v in g] for k, g in groupby(pairs, key=lambda x: x[0])}
|
||||
# Reduce
|
||||
return dict(kv for k, vs in grouped.items() for kv in reduce_phase(k, vs))
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Combiner (local reduce)
|
||||
```python
|
||||
def map_with_combiner(doc_id, text):
|
||||
local = defaultdict(int)
|
||||
for word in text.split():
|
||||
local[word.lower()] += 1
|
||||
for w, c in local.items():
|
||||
yield (w, c)
|
||||
# 매 network shuffle 양 감소
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Spark RDD equivalent
|
||||
```python
|
||||
from pyspark import SparkContext
|
||||
sc = SparkContext()
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
counts = (sc.textFile("hdfs:///logs/*.txt")
|
||||
.flatMap(lambda line: line.split())
|
||||
.map(lambda w: (w.lower(), 1))
|
||||
.reduceByKey(lambda a, b: a + b))
|
||||
counts.saveAsTextFile("hdfs:///out/wc")
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Inverted index
|
||||
```python
|
||||
def map_idx(doc_id, text):
|
||||
for word in set(text.split()):
|
||||
yield (word.lower(), doc_id)
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
def reduce_idx(word, doc_ids):
|
||||
yield (word, sorted(set(doc_ids)))
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Secondary sort
|
||||
```python
|
||||
# Composite key for sort-within-group
|
||||
def map_temp(line):
|
||||
parts = line.split(",")
|
||||
year, temp = parts[0], int(parts[1])
|
||||
yield ((year, temp), None) # negative temp for desc
|
||||
|
||||
def partitioner(key):
|
||||
return hash(key[0]) % num_reducers # group by year only
|
||||
|
||||
def grouping_comparator(a, b):
|
||||
return (a[0] > b[0]) - (a[0] < b[0]) # year only
|
||||
```
|
||||
|
||||
### Join (reduce-side)
|
||||
```python
|
||||
def map_users(row):
|
||||
yield (row["user_id"], ("user", row))
|
||||
|
||||
def map_orders(row):
|
||||
yield (row["user_id"], ("order", row))
|
||||
|
||||
def reduce_join(uid, tagged):
|
||||
user = next(r for tag, r in tagged if tag == "user")
|
||||
for tag, r in tagged:
|
||||
if tag == "order":
|
||||
yield {**user, **r}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Batch ETL on TB+ | Spark (Hadoop MR 은 legacy) |
|
||||
| Streaming | Flink / Spark Structured Streaming |
|
||||
| SQL-shaped query | BigQuery / Athena / Presto |
|
||||
| Cross-cloud portability | Apache Beam |
|
||||
| Educational | Raw MR pseudocode |
|
||||
|
||||
**기본값**: Spark for new projects; Hadoop MR 은 legacy 유지보수만.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Distributed Systems]] · [[Parallel-Computing]]
|
||||
- 변형: [[Spark]] · [[Apache Flink]] · [[Apache Beam]]
|
||||
- 응용: [[Data Pipeline]] · [[ETL]]
|
||||
- Adjacent: [[HDFS]] · [[Hadoop YARN]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: pipeline design review, Spark migration 가이드, query optimization.
|
||||
**언제 X**: real-time low-latency — wrong paradigm.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Many small files**: HDFS namenode 폭발. 매 compaction 필수.
|
||||
- **Skewed keys**: 한 reducer 가 hotspot — salting / combiner 로 완화.
|
||||
- **Stateful map**: 매 idempotency 깨짐 → fault recovery 실패.
|
||||
- **Re-implementing SQL**: 매 BigQuery / Spark SQL 사용.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Dean & Ghemawat OSDI 2004, Spark NSDI 2012, Hadoop docs 3.x).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — word-count + Spark + secondary-sort + join 패턴 |
|
||||
|
||||
@@ -2,91 +2,161 @@
|
||||
id: wiki-2026-0508-memetics
|
||||
title: Memetics
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MEME-001]
|
||||
aliases: [Meme Theory, Cultural Evolution, Dawkins Memetics]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.86
|
||||
tags: [auto-reinforced, memetics, culture, information-replicators, evolutionary-Psychology, internet-culture]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [memetics, cultural-evolution, evolutionary-theory, information-theory]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: conceptual
|
||||
framework: evolutionary-theory
|
||||
---
|
||||
|
||||
# [[Memetics|Memetics]]
|
||||
# Memetics
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "문화의 유전자: 인간의 뇌에서 뇌로 복제되고 변이하며 살아남는 지식, 믿음, 유행의 기본 단위(Meme)이자, 생물학적 진화를 넘어 정보 지배의 원리를 통해 인류의 문명을 설명하는 진화론적 사회학."
|
||||
## 매 한 줄
|
||||
> **"매 cultural unit propagates 의 selection-replication-mutation 의 동일 logic"**. Dawkins 1976 *The Selfish Gene* 의 마지막 chapter 의 introduced — meme 의 cultural analog 의 gene. 매 modern state (2026) 의 contested 으로 남음 — academic 의 quasi-discipline 으로 fade 했지만 social media virality / LLM training data analysis 에서 매 explanatory framework 으로 revival.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
밈학(Memetics)은 문화적 정보의 복제와 전파를 연구하는 학문입니다. (리처드 도킨스 제안)
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 조건 (생존의 법칙)**:
|
||||
* **Longevity**: 정보를 담은 매체가 얼마나 오래가는가?
|
||||
* **Fecundity (번식력)**: 얼마나 빠르고 널리 퍼지는가?
|
||||
* **Copy-fidelity**: 원본의 핵심 메시지가 변함없이 전달되는가?
|
||||
2. **왜 중요한가?**:
|
||||
* 특정 아이디어나 유행이 왜 소멸하고 왜 폭발적으로 유행하는지를 '적자생존'의 관점에서 이해하게 함으로써, 마케팅, 정치, 사회 운동의 메커니즘을 통찰하게 함.
|
||||
### 매 정의
|
||||
- **Meme**: 매 cultural information unit (idea, behavior, style) 의 host-to-host transmission 가능.
|
||||
- **Replicator**: 매 self-copying entity — gene 의 cultural counterpart.
|
||||
- **Memeplex**: 매 co-replicating memes 의 cluster (e.g., religion = belief + ritual + identity meme bundle).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 단순히 문화적 비유 정책으로 여겨졌으나, 현대 정책은 SNS와 알고리즘 덕분에 '초고속 대량 복제와 변이 정책'이 현실화되며 실시간으로 세상을 바꾸는 물리적 힘 정책으로 인정받음(RL Update).
|
||||
- **정책 변화(RL Update)**: AI가 사람들의 선호 정책을 학습하여 인위적으로 '바이럴 밈 정책'을 생성하거나 제어하는 '인공지능 기반 밈 제어 정책'이 부상 시대를 예고함.
|
||||
### 매 Darwinian 3-step
|
||||
- **Variation**: 매 transmission 의 mutations (mishearing, reinterpretation).
|
||||
- **Selection**: 매 attention / memory / social reward 의 differential survival pressure.
|
||||
- **Heredity**: 매 high-fidelity copying 의 (vs. paraphrase) winning long-term.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Information-Society|Information-Society]], [[Innovation|Innovation]], [[Instinct|Instinct]], [[Gestalt Psychology|Gestalt Psychology]], [[Knowledge synthesis|Knowledge synthesis]]
|
||||
- **Modern Tech/Tools**: Viral marketing, Internet memes, Algorithmic feed [[Optimization|Optimization]] (TikTok, X).
|
||||
---
|
||||
### 매 응용
|
||||
1. **Internet virality** — 매 K-factor (replication rate) 의 explicit modeling.
|
||||
2. **LLM training corpus** — 매 dominant memes 의 over-representation 의 model bias.
|
||||
3. **Disinformation analysis** — 매 hostile memeplex 의 spread dynamics.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### 매 K-factor 의 simulation (epidemiological meme spread)
|
||||
```python
|
||||
import numpy as np
|
||||
import matplotlib.pyplot as plt
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def simulate_meme_spread(N=10000, beta=0.3, gamma=0.1, days=60, seed=42):
|
||||
"""SIR-style meme spread. beta = transmission rate, gamma = forget rate."""
|
||||
rng = np.random.default_rng(seed)
|
||||
S, I, R = N - 1, 1, 0
|
||||
history = []
|
||||
for day in range(days):
|
||||
new_inf = rng.binomial(S, 1 - np.exp(-beta * I / N))
|
||||
new_rec = rng.binomial(I, gamma)
|
||||
S -= new_inf
|
||||
I += new_inf - new_rec
|
||||
R += new_rec
|
||||
history.append((day, S, I, R))
|
||||
return history
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
hist = simulate_meme_spread()
|
||||
peak_day = max(hist, key=lambda x: x[2])
|
||||
print(f"Peak adoption day {peak_day[0]}, infected={peak_day[2]}")
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 매 meme fitness 의 measurement (engagement-weighted)
|
||||
```python
|
||||
def meme_fitness(impressions: int, shares: int, completion_rate: float, novelty: float) -> float:
|
||||
"""Composite fitness — higher means stronger replicator."""
|
||||
if impressions == 0:
|
||||
return 0.0
|
||||
share_rate = shares / impressions
|
||||
return share_rate * completion_rate * (1 + 0.5 * novelty)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# Example: TikTok clip
|
||||
print(meme_fitness(1_000_000, 50_000, 0.78, 0.6)) # → ~0.0507
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 매 memeplex 의 cluster detection (LLM corpus analysis)
|
||||
```python
|
||||
from sklearn.feature_extraction.text import TfidfVectorizer
|
||||
from sklearn.cluster import KMeans
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
def find_memeplexes(documents: list[str], k: int = 8):
|
||||
"""Identify co-occurring meme clusters in a corpus."""
|
||||
vec = TfidfVectorizer(max_features=5000, ngram_range=(1, 3), stop_words="english")
|
||||
X = vec.fit_transform(documents)
|
||||
km = KMeans(n_clusters=k, random_state=42, n_init=10).fit(X)
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
terms = vec.get_feature_names_out()
|
||||
for cluster_id in range(k):
|
||||
center = km.cluster_centers_[cluster_id]
|
||||
top = center.argsort()[-10:][::-1]
|
||||
print(f"Memeplex {cluster_id}: {[terms[i] for i in top]}")
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# usage: find_memeplexes(reddit_posts, k=12)
|
||||
```
|
||||
|
||||
### 매 mutation rate 의 quantification (paraphrase distance)
|
||||
```python
|
||||
from sentence_transformers import SentenceTransformer
|
||||
import numpy as np
|
||||
|
||||
model = SentenceTransformer("all-MiniLM-L6-v2")
|
||||
|
||||
def transmission_fidelity(original: str, retransmissions: list[str]) -> float:
|
||||
"""1.0 = perfect copy, 0.0 = unrelated."""
|
||||
orig_vec = model.encode(original, normalize_embeddings=True)
|
||||
re_vecs = model.encode(retransmissions, normalize_embeddings=True)
|
||||
sims = re_vecs @ orig_vec
|
||||
return float(np.mean(sims))
|
||||
```
|
||||
|
||||
### 매 selfish-meme 의 detector (cost-to-host)
|
||||
```python
|
||||
def selfish_meme_score(replication_rate: float, host_wellbeing_delta: float) -> float:
|
||||
"""High when meme spreads strongly while harming hosts (e.g., conspiracy theories)."""
|
||||
return replication_rate / (1 + max(0, host_wellbeing_delta))
|
||||
|
||||
# Healthy meme (positive impact, low spread): 0.5
|
||||
print(selfish_meme_score(replication_rate=0.5, host_wellbeing_delta=0.5)) # 0.33
|
||||
# Selfish meme (negative impact, high spread): high score
|
||||
print(selfish_meme_score(replication_rate=2.0, host_wellbeing_delta=-0.8)) # 2.0
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 single viral content 의 spread modeling | SIR with measured beta/gamma |
|
||||
| 매 long-term cultural change (years+) | Multi-meme co-evolution + selection landscape |
|
||||
| 매 LLM training bias 분석 | Memeplex cluster detection on corpus |
|
||||
| 매 disinformation campaign 의 detection | Selfish-meme scoring + network propagation graph |
|
||||
|
||||
**기본값**: 매 SIR-style modeling 의 first pass — 매 quantitative grip 후 refinement.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Evolutionary Theory]] · [[Cultural Evolution]]
|
||||
- 변형: [[Cultural Selection]] · [[Information Theory]]
|
||||
- 응용: [[Viral Marketing]] · [[Disinformation Analysis]] · [[LLM Training Bias]]
|
||||
- Adjacent: [[Network Effects]] · [[Behavioral Economics]] · [[Sociolinguistics]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 viral content design / disinformation defense / training corpus 의 bias diagnosis.
|
||||
**언제 X**: 매 individual cognition modeling — meme 의 statistical-population concept 의 individual prediction 의 부적합.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **매 "meme = funny image"**: 매 internet vernacular 의 academic concept 의 confuse.
|
||||
- **매 over-Darwinizing culture**: 매 every cultural change 의 selection 의 attribute — many are random drift / institutional choice.
|
||||
- **매 ignoring transmission medium**: 매 medium 의 selection pressure 의 dominant — TV vs Twitter vs TikTok 의 different memeplex 의 favor.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Dawkins *The Selfish Gene* 1976; Blackmore *The Meme Machine* 1999; Boyd & Richerson *Culture and the Evolutionary Process* 1985).
|
||||
- 신뢰도 A (foundational) — but applied predictions 의 신뢰도 B.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — memetics 의 core theory + simulation/cluster patterns 추가 |
|
||||
|
||||
@@ -2,91 +2,139 @@
|
||||
id: wiki-2026-0508-middle-out-thinking
|
||||
title: Middle Out Thinking
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MITH-001]
|
||||
aliases: [Middle-Out Reasoning, Anchor-First Design]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.88
|
||||
tags: [auto-reinforced, middle-out-thinking, Problem-Solving, design-thinking, bottom-up, top-down]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [thinking, problem-solving, design]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: conceptual
|
||||
framework: methodology
|
||||
---
|
||||
|
||||
# [[Middle-Out-Thinking|Middle-Out-Thinking]]
|
||||
# Middle Out Thinking
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "중심에서 뻗어 나가는 전략: 거창한 목표(Top-down)나 자잘한 디테일(Bottom-up)에 매몰되지 않고, 문제의 가장 핵심적인 '중간 지점'을 먼저 정의하고 이를 바탕으로 양방향을 동시에 통합하여 최적의 해답을 구상하는 입체적 사고법."
|
||||
## 매 한 줄
|
||||
> **"매 problem-solving은 middle anchor에서 시작한다"**. 매 top-down (high-level vision)도 bottom-up (raw details)도 아닌, 매 가장 stable / well-understood 한 layer에서 양방향으로 expand 하는 reasoning approach. 매 Silicon Valley series 의 fictional compression 농담에서 시작해 매 product design / ML architecture / writing 의 real methodology 로 자리 잡았다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
미들-아웃 사고(Middle-Out-Thinking)는 문제 해결의 핵심 허브를 먼저 구축하는 방식입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 접근성**:
|
||||
* **The Core**: 문제의 본질을 담고 있는 중간 계층의 기능이나 개념을 먼저 설계.
|
||||
* **[[Scalability|Scalability]] Up**: 핵심을 바탕으로 전체 시스템의 비전으로 확장. (Scalability와 연결)
|
||||
* **[[Refinement|Refinement]] Down**: 핵심을 구현하기 위한 세부 데이터나 기술적 디테일 채움.
|
||||
2. **왜 중요한가?**:
|
||||
* 너무 추상적인 계획(Top)은 실행력이 떨어지고, 너무 파편적인 구현(Bottom)은 전체 방향성을 잃기 쉬울 때, 이 둘을 잇는 강력한 '연결 고리' 역할을 수행함. ([[Efficiency|Efficiency]]와 연결)
|
||||
### 매 왜 middle 인가
|
||||
- Top-down: 매 vision 명확하지만 매 details 의 unknown 많음 → premature commitment.
|
||||
- Bottom-up: 매 details 견고하지만 매 coherence 부재 → integration hell.
|
||||
- Middle-out: 매 anchor (가장 잘 아는 layer) 부터 매 outward expansion → matched uncertainty.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 엄격한 폭포수 모델 정책(Top-down)이 표준이었으나, 현대 정책은 핵심 기능(MVP)을 먼저 만들고 피드백을 받아 확장하는 미들-아웃형 '애자일 정책'이 글로벌 표준이 됨(RL Update). ([[Minimal-Viable-Product|Minimal-Viable-Product]]와 연결)
|
||||
- **정책 변화(RL Update)**: AI 에이전트 설계 정책에서도, 전체 미션과 세부 코딩 사이의 '워크플로우 오케스트레이션(중간 계층)'을 얼마나 잘 정의하느냐가 시스템의 성패를 결정짓는 핵심 정책이 됨. (Agentic-Workflow와 연결)
|
||||
### 매 anchor 선택 기준
|
||||
- **Highest leverage**: 매 한 decision 이 매 most downstream constraints 를 fix.
|
||||
- **Most certain**: 매 well-known domain / proven pattern.
|
||||
- **Bidirectional**: 매 위로 (abstraction)도 매 아래로 (implementation)도 expand 가능.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Minimal-Viable-Product|Minimal-Viable-Product]], [[Scalability|Scalability]], [[Efficiency|Efficiency]], [[Design-System|Design-System]], [[Knowledge-Structure|Knowledge-Structure]]
|
||||
- **Modern Tech/Tools**: [[Domain-Driven Design (DDD)|Domain-Driven Design (DDD)]], Middleware [[Architecture|Architecture]], Microservices.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Product**: MVP feature 매 core user job 부터 → upward (positioning), downward (UI tech).
|
||||
2. **ML architecture**: 매 backbone (e.g., Transformer block) 매 anchor → upward (training loop), downward (kernel ops).
|
||||
3. **Writing**: 매 thesis sentence 매 middle → upward (intro/conclusion), downward (evidence).
|
||||
|
||||
## 🤖 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
|
||||
### Anchor identification
|
||||
```python
|
||||
# Middle-out planning helper
|
||||
def identify_anchor(problem: dict) -> str:
|
||||
"""매 highest-leverage + most-certain layer 찾기."""
|
||||
candidates = problem["layers"]
|
||||
scored = [
|
||||
(layer, layer["leverage"] * layer["certainty"])
|
||||
for layer in candidates
|
||||
]
|
||||
scored.sort(key=lambda x: -x[1])
|
||||
return scored[0][0]["name"]
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Bidirectional expansion
|
||||
```python
|
||||
def expand(anchor: str) -> dict:
|
||||
upward = derive_abstractions(anchor) # vision, goals
|
||||
downward = derive_implementations(anchor) # mechanisms
|
||||
return {"up": upward, "down": downward, "anchor": anchor}
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Middle-out PR description
|
||||
```markdown
|
||||
## Anchor (middle)
|
||||
변경의 핵심: <one sentence>
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
## Up (why)
|
||||
- Business / product reason
|
||||
- User-facing impact
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
## Down (how)
|
||||
- Implementation detail 1
|
||||
- Implementation detail 2
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Architecture sketch (ML)
|
||||
```python
|
||||
# Anchor: TransformerBlock
|
||||
class TransformerBlock(nn.Module):
|
||||
def __init__(self, d, h):
|
||||
super().__init__()
|
||||
self.attn = MultiHeadAttn(d, h)
|
||||
self.ff = FeedForward(d)
|
||||
def forward(self, x):
|
||||
return self.ff(self.attn(x))
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# Up: stack into model
|
||||
# Down: choose attention kernel (FlashAttn vs naive)
|
||||
```
|
||||
|
||||
### Document outline tool
|
||||
```python
|
||||
def middle_out_outline(thesis: str):
|
||||
return {
|
||||
"thesis": thesis, # anchor
|
||||
"intro": "[derive from thesis]",
|
||||
"body": "[decompose thesis into 3 claims]",
|
||||
"conclusion": "[restate + extend]",
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 vision 명확, 매 details 의 unknown | Middle-out (anchor at known mid layer) |
|
||||
| 매 details 의 강제 (HW constraint) | Bottom-up |
|
||||
| 매 brand-new domain, 매 nothing known | Top-down + spike |
|
||||
| 매 refactor existing system | Middle-out (anchor at stable interface) |
|
||||
|
||||
**기본값**: Middle-out — 매 most realistic problems 에서 매 anchor 가 존재.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Problem-Solving]] · [[Design-Thinking]]
|
||||
- 변형: [[Top-Down-Design]] · [[Bottom-Up-Design]]
|
||||
- 응용: [[Minimal-Viable-Product]] · [[Architecture-Decision]]
|
||||
- Adjacent: [[First-Principles-Thinking]] · [[Pyramid-Principle]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 ambiguous spec 에서 매 LLM 에게 "what's the anchor?" 질문 → 매 most leveraged decision 부터 elaborate.
|
||||
**언제 X**: 매 trivial well-defined task — 매 직접 implementation 이 빠름.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Anchor too high**: 매 vision-level anchor → 매 bottom-up과 동일하게 details 폭발.
|
||||
- **Anchor too low**: 매 implementation-level anchor → 매 top-down 부재로 coherence 상실.
|
||||
- **Multiple anchors**: 매 simultaneous 의 multiple middle 선택 → 매 expansion conflict.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Pyramid Principle, Minto 1987; Architectural Decision Records practice).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — anchor-first reasoning methodology with bidirectional expansion |
|
||||
|
||||
@@ -2,65 +2,138 @@
|
||||
id: wiki-2026-0508-minimal-viable-product
|
||||
title: Minimal Viable Product
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MVPP-001]
|
||||
aliases: [MVP, Minimum Viable Product]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, mvp, product-development, lean-Startup, validation, fast-Iteration]
|
||||
verification_status: applied
|
||||
tags: [product, lean-startup, validation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: conceptual
|
||||
framework: lean-startup
|
||||
---
|
||||
|
||||
# [[Minimal-Viable-Product|Minimal-Viable-Product]]
|
||||
# Minimal Viable Product (MVP)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "학습을 위한 최소한의 실체: 완벽한 제품이 아니라, 가설을 검증할 수 있는 '최소한의 핵심 기능'만을 담아 시장에 내놓고, 실제 유저의 피드백을 통해 제품의 운명을 결정하며 진화해 나가는 린(Lean) 개발의 정수."
|
||||
## 매 한 줄
|
||||
> **"매 학습 단위로서의 가장 작은 product"**. 매 Eric Ries (2011) 가 정의한 MVP 는 매 customer hypothesis 를 매 minimum effort 로 validate 하는 product version. 매 2026 의 MVP 는 매 AI-augmented prototyping (Claude Opus, Replit Agent) 으로 매 days-not-weeks scale.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
최소 기능 제품(MVP)은 고객의 피드백을 받기 위해 최소한의 노력으로 만든 제품입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 목적**:
|
||||
* **Validation**: 우리의 아이디어가 실제로 시장에서 통하는지 확인. ([[Feedback-Loops|Feedback-Loops]]와 연결)
|
||||
* **Waste Reduction**: 아무도 원하지 않는 기능을 만드느라 쏟는 시간과 비용 낭비 방지. (Lean-Operations와 연결)
|
||||
* **Speed**: 완벽함보다는 '속도'를 통해 경쟁 우위 점함.
|
||||
2. **왜 중요한가?**:
|
||||
* 현대 비즈니스는 '예측'이 아닌 '대응'의 영역이며, MVP는 가장 저렴하고 빠르게 대응할 수 있는 지적 도구이기 때문임.
|
||||
### 매 MVP 의 진짜 의미
|
||||
- **Minimum**: 매 build effort 의 minimization (X feature count).
|
||||
- **Viable**: 매 real user 의 real job 을 매 end-to-end 수행 가능.
|
||||
- **Product**: 매 learning vehicle — 매 metric capture 가능해야.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '최소한(Minimal)'에 치중해 품질을 무시하는 정책이 많았으나, 현대 정책은 최소한이더라도 고객이 가치를 느끼고 사랑할 수 있는 수준(Minimum Lovable Product)을 추구하는 정책으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 기반 서비스 개발 정책에서는 모델의 성능을 100% 만드는 것보다, 70%의 성능으로도 사용자 경험을 혁신할 수 있는 '프롬프트 기반 MVP 정책'을 먼저 출시하여 데이터를 선점하는 전략이 주류 정책이 됨.
|
||||
### 매 MVP 의 X
|
||||
- 매 buggy half-product (X — viable 아님).
|
||||
- 매 feature-complete v1 (X — minimum 아님).
|
||||
- 매 internal demo (X — product 아님, no users).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Feedback-Loops|Feedback-Loops]], [[Lean-Operations|Lean-Operations]], [[Iterative-Development|Iterative-Development]], [[Innovation|Innovation]], [[Design-System|Design-System]]
|
||||
- **Modern Tech/Tools**: Landing page tests, Concierge MVP, Wizard of Oz MVP, Fast [[Prototyping|Prototyping]].
|
||||
---
|
||||
### 매 응용
|
||||
1. **Concierge MVP**: 매 manual backend, 매 user 는 magic UX 로 인식.
|
||||
2. **Wizard-of-Oz**: 매 fake automation, 매 human-in-loop.
|
||||
3. **Landing page**: 매 product X, 매 demand signal capture only.
|
||||
4. **Single-feature**: 매 one core job, 매 polished.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Hypothesis canvas
|
||||
```yaml
|
||||
mvp:
|
||||
hypothesis: "User X will pay $Y for solving Z"
|
||||
riskiest_assumption: "User X actually has problem Z"
|
||||
minimum_test:
|
||||
type: landing_page
|
||||
success_metric: "100 sign-ups in 7 days"
|
||||
kill_metric: "<10 sign-ups → pivot"
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Concierge MVP scaffold
|
||||
```python
|
||||
# Fake the backend, learn from real users
|
||||
from fastapi import FastAPI
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
app = FastAPI()
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
@app.post("/recommend")
|
||||
async def recommend(user_query: str):
|
||||
# MVP: send query to founder's phone
|
||||
await sms_to_founder(user_query)
|
||||
# Founder manually crafts recommendation
|
||||
response = await wait_for_founder_reply()
|
||||
return {"recommendation": response}
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Build-Measure-Learn loop
|
||||
```python
|
||||
class MVPCycle:
|
||||
def __init__(self, hypothesis):
|
||||
self.hypothesis = hypothesis
|
||||
def build(self): # smallest experiment
|
||||
return prototype(self.hypothesis)
|
||||
def measure(self, prototype, n_users=20):
|
||||
return collect_metrics(prototype, n_users)
|
||||
def learn(self, metrics):
|
||||
if metrics["activation"] > 0.4:
|
||||
return "persevere"
|
||||
return "pivot"
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### AI-augmented MVP (2026)
|
||||
```bash
|
||||
# Claude Code + Replit Agent stack
|
||||
claude-code "build MVP for <hypothesis>" --scaffold next.js
|
||||
# Days-not-weeks: AI generates 80% boilerplate
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Kill criteria gate
|
||||
```python
|
||||
def should_kill(metrics: dict, kill_threshold: dict) -> bool:
|
||||
"""매 honest evaluation — sunk cost ignore."""
|
||||
return all(
|
||||
metrics[k] < kill_threshold[k]
|
||||
for k in kill_threshold
|
||||
)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | MVP type |
|
||||
|---|---|
|
||||
| 매 demand 의 unknown | Landing page |
|
||||
| 매 UX 의 unknown, backend 매 hard | Concierge / Wizard-of-Oz |
|
||||
| 매 demand 매 confirmed, 매 build feasible | Single-feature MVP |
|
||||
| 매 enterprise B2B | Design partner pilot (X cold MVP) |
|
||||
|
||||
**기본값**: Landing page → Concierge → Single-feature 의 progression.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Lean-Startup]] · [[Product-Discovery]]
|
||||
- 변형: [[Concierge-MVP]] · [[Wizard-of-Oz-MVP]]
|
||||
- 응용: [[Build-Measure-Learn]] · [[Pivot-or-Persevere]]
|
||||
- Adjacent: [[Customer-Development]] · [[Jobs-to-be-Done]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 hypothesis articulation, 매 riskiest assumption 의 surfacing, 매 MVP scaffold generation.
|
||||
**언제 X**: 매 already-validated product 의 v2 — MVP framing 의 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Feature creep MVP**: 매 minimum 무시 → 매 8주 build, 매 launch 실패.
|
||||
- **Vanity metrics**: 매 page views / signups 만 측정 → activation / retention X.
|
||||
- **No kill criteria**: 매 sunk cost trap.
|
||||
- **MVP = bad quality**: 매 minimum 은 scope, X quality.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Ries 2011 *The Lean Startup*; Blank *Four Steps to the Epiphany*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — MVP types, build-measure-learn, AI-augmented 2026 stack |
|
||||
|
||||
@@ -1,92 +1,192 @@
|
||||
---
|
||||
id: wiki-2026-0508-multi-agent-system
|
||||
title: Multi agent System
|
||||
title: Multi-agent System
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-MASY-001]
|
||||
aliases: [MAS, 멀티에이전트, Agent Swarm, Agentic Systems]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, multi-agent-system, mas, Autonomous-Agents, collaboration, Swarm-Intelligence]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [ai, agents, llm, orchestration, distributed]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: claude-agent-sdk
|
||||
---
|
||||
|
||||
# [[Multi-agent-System|Multi-agent-System]]
|
||||
# Multi-agent System
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지능의 팀워크: 혼자서는 못 풀 문제를 전문화된 여러 인공지능 에이전트들이 서로 대화하고, 협상하고, 역할을 분담하여 해결하는 집단 지성 시스템이자, 복잡한 워크플로우를 자율적으로 완수하는 거대한 오케스트라."
|
||||
## 매 한 줄
|
||||
> **"매 specialization × coordination > monolith"**. Multi-agent system 은 여러 autonomous agent 가 message passing / shared state 로 협업해 single agent 보다 큰 task 해결. 2026 LLM 시대에 Claude Agent SDK, OpenAI Swarm, LangGraph, AutoGen 등이 표준 framework.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
멀티 에이전트 시스템(MAS)은 여러 개의 지능형 에이전트가 상호작용하는 시스템입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **에이전트의 성격**:
|
||||
* **Autonomy**: 각자 독립적인 판단력 보유.
|
||||
* **Social Ability**: 메시지를 주고받으며 소통. (Agentic-Workflow와 연결)
|
||||
* **Specialization**: 검색 전문가, 기획 전문가, 코딩 전문가 등 역할 분담. ([[Modular-Design|Modular-Design]]적 접근)
|
||||
2. **왜 중요한가?**:
|
||||
* 하나의 초거대 모델이 모든 걸 다 잘하기는 어렵고 비용이 많이 들지만, 작은 모델들을 엮어 팀을 짜면 훨씬 더 정교하고 강력한 성과를 낼 수 있기 때문임. ([[Efficiency|Efficiency]]와 연결)
|
||||
### 매 architecture pattern
|
||||
- **Orchestrator-worker**: 1 lead agent + N specialist worker. 매 Anthropic 의 research agent 패턴.
|
||||
- **Peer-to-peer**: 모든 agent equal, message bus 로 통신.
|
||||
- **Hierarchical**: layered supervisor tree.
|
||||
- **Blackboard**: shared memory 기반 indirect coordination.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 에이전트 간의 통신 규격(FIPA 등) 정책에 집착했으나, 현대 정책은 LLM이 자연어로 서로 대화하며 문제를 푸는 '자연어 기반 협업 정책'이 압도적 우위 정책을 점함(RL Update).
|
||||
- **정책 변화(RL Update)**: 에이전트가 늘어날수록 발생하는 소통 비용과 의견 충돌 정책을 해결하기 위해, 팀장의 역할을 하는 'Manager Agent'나 투표 시스템 정책 등을 활용하는 고도의 '에이전트 거버넌스 정책'이 중요해짐.
|
||||
### 매 communication
|
||||
- Function calling / tool use.
|
||||
- Structured message (JSON schema).
|
||||
- Shared filesystem / vector DB.
|
||||
- A2A (Agent-to-Agent) protocol (2025 Anthropic spec).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Agentic-Workflow, [[Modular-Design|Modular-Design]], [[Large Language Models (LLM)|Large Language Models (LLM)]], [[Innovation|Innovation]], [[Leadership|Leadership]]
|
||||
- **Modern Tech/Tools**: AutoGen (Microsoft), CrewAI, LangGraph, [[Swarm Intelligence|Swarm Intelligence]] algorithms.
|
||||
---
|
||||
### 매 응용
|
||||
1. Research / report generation (parallel search + synthesis).
|
||||
2. Software engineering (planner + coder + tester).
|
||||
3. Customer support routing.
|
||||
4. Game NPC behavior.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Orchestrator-worker (Claude Agent SDK)
|
||||
```python
|
||||
from anthropic import Anthropic
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
client = Anthropic()
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def spawn_worker(task: str, system: str) -> str:
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=4096,
|
||||
system=system,
|
||||
messages=[{"role": "user", "content": task}],
|
||||
)
|
||||
return resp.content[0].text
|
||||
|
||||
- **정보 상태:** 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
|
||||
def orchestrate(query: str):
|
||||
plan = spawn_worker(
|
||||
f"Decompose into 3 sub-tasks: {query}",
|
||||
"You are a research planner. Output JSON list.",
|
||||
)
|
||||
subtasks = parse_plan(plan)
|
||||
results = [spawn_worker(t, "You are a domain expert.") for t in subtasks]
|
||||
return spawn_worker(
|
||||
f"Synthesize: {results}",
|
||||
"You are an editor. Merge into a coherent report.",
|
||||
)
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Tool-use loop
|
||||
```python
|
||||
def agent_loop(messages, tools, max_iter=10):
|
||||
for _ in range(max_iter):
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
tools=tools,
|
||||
messages=messages,
|
||||
max_tokens=4096,
|
||||
)
|
||||
messages.append({"role": "assistant", "content": resp.content})
|
||||
if resp.stop_reason == "end_turn":
|
||||
return resp
|
||||
for block in resp.content:
|
||||
if block.type == "tool_use":
|
||||
result = execute_tool(block.name, block.input)
|
||||
messages.append({
|
||||
"role": "user",
|
||||
"content": [{
|
||||
"type": "tool_result",
|
||||
"tool_use_id": block.id,
|
||||
"content": result,
|
||||
}],
|
||||
})
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Shared state via filesystem
|
||||
```python
|
||||
import json, fcntl
|
||||
from pathlib import Path
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def shared_write(path: Path, key: str, value):
|
||||
with open(path, "r+") as f:
|
||||
fcntl.flock(f, fcntl.LOCK_EX)
|
||||
state = json.load(f)
|
||||
state[key] = value
|
||||
f.seek(0); f.truncate()
|
||||
json.dump(state, f)
|
||||
fcntl.flock(f, fcntl.LOCK_UN)
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### LangGraph state machine
|
||||
```python
|
||||
from langgraph.graph import StateGraph, END
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
def planner(state): return {"plan": llm_plan(state["query"])}
|
||||
def executor(state): return {"result": run_steps(state["plan"])}
|
||||
def critic(state):
|
||||
if quality_score(state["result"]) < 0.7:
|
||||
return {"next": "planner"}
|
||||
return {"next": END}
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
g = StateGraph(dict)
|
||||
g.add_node("plan", planner)
|
||||
g.add_node("exec", executor)
|
||||
g.add_node("crit", critic)
|
||||
g.add_edge("plan", "exec")
|
||||
g.add_edge("exec", "crit")
|
||||
g.add_conditional_edges("crit", lambda s: s["next"])
|
||||
```
|
||||
|
||||
### Parallel agent fan-out
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
async def parallel_search(queries: list[str]) -> list[str]:
|
||||
tasks = [asyncio.to_thread(spawn_worker, q, "Researcher") for q in queries]
|
||||
return await asyncio.gather(*tasks)
|
||||
```
|
||||
|
||||
### Critic-actor consensus
|
||||
```python
|
||||
def consensus(question: str, n_agents=3) -> str:
|
||||
answers = [spawn_worker(question, f"Expert #{i}") for i in range(n_agents)]
|
||||
return spawn_worker(
|
||||
f"Q: {question}\nAnswers:\n" + "\n".join(answers) +
|
||||
"\nReturn consensus + dissent.",
|
||||
"You are a meta-reviewer.",
|
||||
)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Clear task decomposition | Orchestrator-worker |
|
||||
| Open-ended exploration | Peer-to-peer + blackboard |
|
||||
| Quality-critical | Critic-actor + consensus |
|
||||
| Latency-critical | Parallel fan-out |
|
||||
| Stateful workflow | LangGraph / state machine |
|
||||
|
||||
**기본값**: Orchestrator-worker + tool use loop.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[AI Agents]] · [[Distributed Systems]]
|
||||
- 변형: [[Agent Orchestration]] · [[Swarm Intelligence]]
|
||||
- 응용: [[Claude Agent SDK]] · [[LangGraph]]
|
||||
- Adjacent: [[Tool Use]] · [[Function Calling]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: complex task decomposition, parallel research, multi-step pipeline.
|
||||
**언제 X**: simple single-shot Q&A — overhead 만 추가.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Over-decomposition**: 너무 많은 agent → coordination overhead 폭증.
|
||||
- **No termination condition**: infinite loop 위험.
|
||||
- **Shared mutable state without lock**: race condition.
|
||||
- **Tool sprawl**: 한 agent 에 50+ tools — selection 정확도 폭락.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Anthropic Multi-agent Research 2024, OpenAI Swarm, LangGraph 0.3).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — orchestrator/tool-use/LangGraph 패턴 |
|
||||
|
||||
@@ -2,99 +2,182 @@
|
||||
id: wiki-2026-0508-ndf-neutral-data-format
|
||||
title: NDF (Neutral Data Format)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Neutral Data Format, Eugen NDF, WARNO NDF]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [modding, data-format, eugen-systems, warno, configuration]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: NDF
|
||||
framework: Eugen-Iriszoom
|
||||
---
|
||||
|
||||
# NDF (Neutral Data Format)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
NDF(Neutral Data Format)는 EugenSystems가 개발한 독자적인 텍스트 기반 스크립트 언어 및 데이터 포맷입니다 [1]. [[WARNO|WARNO]]의 게임 동작과 유닛의 세부 데이터를 저장하는 데 사용되며, 게임 코드와 데이터 값을 엄격히 분리하여 수천 개에 달하는 속성을 체계적으로 관리할 수 있게 합니다 [1, 2]. 이는 시뮬레이션의 '유전적 청사진' 역할을 수행하며, 게임 소스 코드의 수정 없이도 정교한 데이터 기반 밸런싱과 모딩을 가능하게 하는 핵심 기반입니다 [1].
|
||||
## 매 한 줄
|
||||
> **"매 declarative game-data DSL — Eugen Systems Iriszoom engine 의 data layer"**. 매 Wargame/Steel Division/WARNO 시리즈 의 unit/weapon/visual 의 모든 stat 의 NDF 파일 정의. 매 modding 의 entry point — 매 binary patch 가 X, plain text 의 git-diffable.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **NDF의 구조와 객체 지향적 특성**
|
||||
NDF 파일은 텍스트 기반의 프로그래밍 형식을 띠며, 상속과 모듈화가 고도로 발달된 객체 지향적인 특성을 지니고 있습니다 [1]. 구조적 설계의 대표적인 예로, `UniteDescriptor.ndf` 파일 내의 개별 유닛 엔티티는 단일 데이터로 존재하는 것이 아니라 외형 모듈(ApparenceModel), 보급 모듈(TSupplyModuleDescriptor), 생존 모듈(THealthModuleDescriptor) 등 독립적인 기능을 수행하는 여러 디스크립터(Descriptor)들을 조립하는 방식으로 정교하게 구축됩니다 [1].
|
||||
## 매 핵심
|
||||
|
||||
- **주요 NDF 파일과 담당 시뮬레이션 영역**
|
||||
WARNO의 모든 논리적 설계는 수천 개의 `.ndf` 파일에 나뉘어 정의되어 있습니다 [1, 2]. 가장 핵심적인 파일들은 다음과 같습니다:
|
||||
* `UniteDescriptor.ndf`: 유닛의 물리적 및 기술적 속성(가격, 시야, 이동성, 은신값 등)을 정의합니다 [3, 4].
|
||||
* `WeaponDescriptor.ndf`: 포탑 회전 속도, 조준 시간 등 무기 체계의 메커니즘을 설정합니다 [3, 4].
|
||||
* `Ammunition.ndf`: 철갑탄(AP) 관통력, 고폭탄(HE) 데미지, 제압력 등 탄약의 물리적 타격 로직을 담고 있습니다 [3, 4].
|
||||
* `Divisions.ndf` 및 `DivisionRules.ndf`: 사단 덱을 구성할 때 적용되는 카드당 유닛 수와 전략적 가용성 규칙을 제어합니다 [4, 5].
|
||||
### 매 Syntax 의 핵심
|
||||
- **Object literal**: `Identifier is TYPE(...)` — 매 모든 entity 의 declaration.
|
||||
- **Module 의 nesting**: 매 outer module 안의 inner objects 의 reference.
|
||||
- **Reference**: `~/Module/Path/Identifier` — 매 absolute paths.
|
||||
- **Map / List**: `MAP[(key, value), ...]`, `[item1, item2]`.
|
||||
- **Comment**: `//` (line) — 매 `/* */` 의 X.
|
||||
|
||||
- **데이터 기반 밸런싱 및 모딩의 핵심 동력**
|
||||
NDF 시스템이 제공하는 고도의 유연성은 WARNO 특유의 '데이터 기반 밸런싱(Data-Driven Balancing)'을 가능케 합니다 [4]. 개발자와 모더들은 일반적인 텍스트 편집기나 전용 도구(WME: Warno Mod Editor)를 사용하여 게임 소스코드 변형 없이 유닛 성능 데이터를 즉각적으로 튜닝할 수 있습니다 [1, 5, 6]. 또한, `[[ndf-parse|ndf-parse]]`와 같은 Python 패키지를 활용하면 NDF 파일을 자동으로 파싱하고 수정 사항을 유효한 NDF 코드로 다시 기록하는 작업도 수행할 수 있습니다 [7].
|
||||
### 매 typical structure
|
||||
- **GameData**: 매 unit definitions / weapon stats / texture references / sound mappings.
|
||||
- **Module**: 매 named container — 매 `ZModule_TWeaponManagerModuleDescriptor` 의 sort 의 component.
|
||||
- **Inheritance**: 매 `is BaseType(...)` 의 prototype 의 from inheritance — override fields only.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계(Data-Driven Design]], Iriszoom 엔진, [[WARNO 모딩(Modding)|WARNO 모딩(Modding]]
|
||||
- **Projects/Contexts:** [[WARNO-DATA 프로젝트|WARNO-DATA 프로젝트]], ndf-parse 패키지, [[Warno-Armory|Warno-Armory]]
|
||||
- **Contradictions/Notes:** [[Eugen Systems|Eugen Systems]]는 공식적인 모딩 매뉴얼과 `.ndf` 참조 가이드를 통해 파일 형식을 설명하고 있지만, 수천 개의 파일에 분산된 실제 데이터 속성값에 대한 상세한 설명은 제공하지 않습니다 [2]. 이로 인해 유저 커뮤니티가 주도하여 WARNO-DATA 위키를 개설하거나, 데이터를 파싱해 숨겨진 스탯을 보여주는 War-Yes, [[Warno-Armory|Warno-Armory]] 등의 서드파티 도구를 개발하여 공식 문서의 빈틈을 메우고 있습니다 [2, 8].
|
||||
### 매 응용
|
||||
1. **Unit balance modding** (HP / armor / damage tweaks).
|
||||
2. **New unit creation** (copy/paste/rename + export to deck).
|
||||
3. **Visual mod** (camo swap, model substitution via NDF reference change).
|
||||
|
||||
---
|
||||
*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
|
||||
### 매 NDF 의 unit definition (WARNO style)
|
||||
```ndf
|
||||
// Unit declaration with module composition
|
||||
TUniteDescriptor_M1Abrams is TUniteDescriptor
|
||||
(
|
||||
ClassNameForDebug = "M1A1 Abrams"
|
||||
AcknowUnitType = ~/AcknowUnitType_Tank
|
||||
ModulesDescriptors =
|
||||
[
|
||||
TBaseDamageModuleDescriptor
|
||||
(
|
||||
MaxPhysicalDamages = 9
|
||||
ArmorDescriptorFront = ~/Armor_Tank_Heavy_Front
|
||||
ArmorDescriptorSides = ~/Armor_Tank_Heavy_Side
|
||||
),
|
||||
TWeaponManagerModuleDescriptor
|
||||
(
|
||||
Salves = [1, 1, 1]
|
||||
TurretDescriptorList = [TTurretInfanterieDescriptor()]
|
||||
),
|
||||
]
|
||||
)
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 매 NDF parser (Python — ndf-parse 패키지)
|
||||
```python
|
||||
import ndf_parse
|
||||
import ndf_parse.model as ndf_model
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# Parse a WARNO NDF file
|
||||
with open("UniteDescriptor.ndf") as f:
|
||||
source = f.read()
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
tree = ndf_parse.parse(source)
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
# Find Abrams unit and tweak HP
|
||||
for obj in tree:
|
||||
if obj.namespace == "TUniteDescriptor_M1Abrams":
|
||||
damage_mod = obj.value.by_member("ModulesDescriptors").value[0]
|
||||
damage_mod.value.by_member("MaxPhysicalDamages").value = "12"
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
# Write back
|
||||
with open("UniteDescriptor.modified.ndf", "w") as f:
|
||||
f.write(ndf_parse.print_tree(tree))
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### 매 batch 의 unit stat 의 audit
|
||||
```python
|
||||
import ndf_parse
|
||||
from pathlib import Path
|
||||
|
||||
def audit_unit_hp(ndf_dir: Path) -> dict[str, int]:
|
||||
"""Scan all unit descriptors and extract MaxPhysicalDamages."""
|
||||
results = {}
|
||||
for ndf_path in ndf_dir.glob("**/UniteDescriptor*.ndf"):
|
||||
tree = ndf_parse.parse(ndf_path.read_text(encoding="utf-8"))
|
||||
for obj in tree:
|
||||
if obj.value.type == "TUniteDescriptor":
|
||||
try:
|
||||
mods = obj.value.by_member("ModulesDescriptors").value
|
||||
for m in mods:
|
||||
if m.value.type == "TBaseDamageModuleDescriptor":
|
||||
hp = int(m.value.by_member("MaxPhysicalDamages").value)
|
||||
results[obj.namespace] = hp
|
||||
except (AttributeError, KeyError):
|
||||
pass
|
||||
return results
|
||||
|
||||
hp_table = audit_unit_hp(Path("./WARNO_GameData/Generated/Gameplay/Gfx"))
|
||||
# Find outliers
|
||||
for unit, hp in sorted(hp_table.items(), key=lambda x: -x[1])[:10]:
|
||||
print(f"{unit}: {hp}")
|
||||
```
|
||||
|
||||
### 매 mod 의 inheritance (override only what changed)
|
||||
```ndf
|
||||
// Mod file — overrides base unit
|
||||
export TUniteDescriptor_M1Abrams_Modded is TUniteDescriptor_M1Abrams
|
||||
(
|
||||
// Only override the fields you change
|
||||
Modifications =
|
||||
[
|
||||
("MaxPhysicalDamages", 15), // buff HP
|
||||
("MaxSpeedInKmph", 75), // faster
|
||||
]
|
||||
)
|
||||
```
|
||||
|
||||
### 매 NDF 의 git-friendly diff
|
||||
```bash
|
||||
# Mod versioning workflow
|
||||
git init mods/abrams_buff
|
||||
cd mods/abrams_buff
|
||||
cp ../../WARNO_GameData/Generated/Gameplay/Gfx/UniteDescriptor.ndf base.ndf
|
||||
# ... edit ...
|
||||
git diff base.ndf modified.ndf > abrams_buff.patch
|
||||
|
||||
# Reapply on update
|
||||
git apply abrams_buff.patch # works as long as upstream context stable
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 single value tweak | Direct edit + diff |
|
||||
| 매 systematic balance pass | ndf-parse Python script |
|
||||
| 매 new unit | Inherit from existing TUniteDescriptor + override |
|
||||
| 매 cross-version mod | `Modifications = [...]` override list (resilient to base changes) |
|
||||
| 매 visual-only mod | Texture path swap in TextureBank NDF |
|
||||
|
||||
**기본값**: 매 inheritance + Modifications list — 매 maintainability 의 best.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Eugen Systems 모딩 매뉴얼]] · [[Iriszoom 엔진]]
|
||||
- 변형: [[ndf-parse 패키지]] · [[WARNO Modding]]
|
||||
- 응용: [[Unit Balance Modding]] · [[Visual Mod]]
|
||||
- Adjacent: [[Lua Scripting]] · [[INI Configuration]] · [[XML Game Data]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 large balance pass (parse → batch edit → write) / 매 new unit boilerplate generation / 매 cross-mod conflict detection.
|
||||
**언제 X**: 매 tiny single-value edit — 매 manual edit 의 faster.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **매 binary patch**: 매 game patches 의 break — NDF 의 source-level 의 stay.
|
||||
- **매 full file 의 copy**: 매 base game patch 의 conflict — Modifications override list 의 use.
|
||||
- **매 string concat 의 NDF generation**: 매 syntax error 의 risk — proper parser library 의 use.
|
||||
- **매 무 backup**: 매 NDF 의 game crash 시 root cause — git-track everything.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Eugen Systems WARNO modding documentation; ndf-parse Python package on PyPI; community Discord patterns).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — NDF syntax + ndf-parse patterns + modding workflow |
|
||||
|
||||
@@ -2,67 +2,131 @@
|
||||
id: wiki-2026-0508-neurobiology-of-reward
|
||||
title: Neurobiology of Reward
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-REWARD-001]
|
||||
aliases: [Reward System, Dopamine System, Mesolimbic Pathway]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, neuroscience, Dopamine]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [neuroscience, reward, dopamine, RL]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: neuroscience-RL
|
||||
---
|
||||
|
||||
# [[Neurobiology-of-Reward|Neurobiology-of-Reward]]
|
||||
# Neurobiology of Reward
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "예상치 못한 기쁨이 뇌를 깨운다: 도파민은 쾌락 그 자체가 아니라, '예측과 실제의 차이'를 이용해 미래의 행동을 최적화하는 학습 신호."
|
||||
## 매 한 줄
|
||||
> **"매 dopamine 은 reward 자체 X, 매 reward prediction error 의 signal"**. 매 mesolimbic pathway (VTA → NAc) 가 매 expected vs actual outcome 의 차이를 encode 하며, 매 Schultz (1997) 가 매 발견. 매 modern RL (TD-learning, RLHF) 의 매 biological 의 root.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
보상의 신경생물학(Neurobiology of Reward)은 유기체가 생존에 필수적인 행동을 학습하고 반복하게 만드는 뇌 내 메커니즘을 다룹니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **도파민 경로 (Dopaminergic Pathways)**:
|
||||
* **중뇌변연계 경로 (Mesolimbic Pathway)**: 복측 피개부(VTA)에서 측좌핵(Nucleus Accumbens)으로 연결되는 경로로, 보상의 가치와 동기 부여를 담당.
|
||||
* **중뇌피질 경로 (Mesocortical Pathway)**: VTA에서 전전두엽으로 연결되며, 보상을 위한 장기적 행동 계획 및 실행 통제 수행.
|
||||
2. **보상 예측 오류 ([[Reward Prediction Error|Reward Prediction Error]], RPE)**:
|
||||
* 울프람 슐츠(Wolfram Schultz)의 발견: 도파민 뉴런은 보상을 받았을 때가 아니라, '예지하지 못한 보상'이 나타났을 때 강력하게 발화함.
|
||||
* 이는 강화학습의 **TD Error**와 일치하며, 뇌가 환경의 모델을 업데이트하는 핵심 기제임.
|
||||
3. **Wanting vs Liking (갈망 vs 기호)**:
|
||||
* 테리 로빈슨과 켄트 베리지는 중독 현상을 연구하며 '원하는 것(도파민 담당)'과 '실제로 좋아하는 것(엔도카나비노이드/오피오이드 담당)'이 신경학적으로 분리되어 있음을 증명함.
|
||||
### 매 핵심 회로
|
||||
- **VTA (ventral tegmental area)**: 매 dopamine 의 source neurons.
|
||||
- **NAc (nucleus accumbens)**: 매 reward salience encoding.
|
||||
- **PFC (prefrontal cortex)**: 매 value-based decision-making.
|
||||
- **Amygdala**: 매 valence (positive/negative) encoding.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 도파민이 단순히 '쾌락 물질'이라는 오해는 이제 완전히 폐기되었으며, 현재는 '전달할 정보의 가치'를 평가하는 계산적 분자로 이해됨.
|
||||
- **정책 변화(RL Update)**: 현대의 중독 치료 RL 모델에서는 도파민 수용체의 민감도 저하(Tolerance)를 AI 에이전트의 'Learning Rate Decay' 혹은 'Reward [[CLIP|CLIP]]ping' 오류에 비유하여 분석하며, 이를 예방하기 위한 알고리즘적 설계를 연구 중임.
|
||||
### 매 RPE (Reward Prediction Error)
|
||||
- 매 RPE = actual_reward - expected_reward.
|
||||
- 매 positive RPE → dopamine burst → 매 reinforce action.
|
||||
- 매 negative RPE → dopamine dip → 매 weaken action.
|
||||
- 매 zero RPE (fully predicted reward) → no signal.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Reinforcement Learning, [[Dopamine|Dopamine]], Executive Function, Addiction Neurobiology, Temporal Difference Learning
|
||||
- **Modern Tech/Tools**: Optogenetics, In-vivo Microdialysis, fMRI.
|
||||
---
|
||||
### 매 응용
|
||||
1. **RL algorithms**: TD-learning 매 RPE 와 mathematically equivalent.
|
||||
2. **RLHF**: 매 reward model 매 human preference RPE 의 proxy.
|
||||
3. **Addiction research**: 매 hijacked dopamine → compulsive behavior.
|
||||
4. **UX design**: 매 variable reward schedule (slot machine effect).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### TD-learning (Sutton & Barto, RL biological analog)
|
||||
```python
|
||||
# Temporal Difference learning — RPE 매 update signal
|
||||
import numpy as np
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def td_update(V, state, next_state, reward, alpha=0.1, gamma=0.99):
|
||||
"""V[s] ← V[s] + α(r + γV[s'] - V[s])"""
|
||||
rpe = reward + gamma * V[next_state] - V[state] # 매 RPE
|
||||
V[state] += alpha * rpe
|
||||
return V, rpe
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Dopamine neuron simulation
|
||||
```python
|
||||
def dopamine_response(predicted_r, actual_r, baseline=1.0):
|
||||
"""Schultz (1997) — 매 phasic firing rate."""
|
||||
rpe = actual_r - predicted_r
|
||||
return baseline * np.exp(rpe) # scale baseline firing
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### RLHF reward model (modern bridge)
|
||||
```python
|
||||
# transformers + trl
|
||||
from trl import PPOTrainer, PPOConfig
|
||||
from transformers import AutoModelForCausalLMWithValueHead
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
# 매 reward model = learned approximation of human RPE
|
||||
config = PPOConfig(model_name="meta-llama/Llama-3.1-8B")
|
||||
trainer = PPOTrainer(config, model, tokenizer, reward_model=reward_fn)
|
||||
# Reward signal drives policy update → analog of dopamine update
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Variable reward schedule (UX)
|
||||
```python
|
||||
import random
|
||||
def variable_reward(action_count):
|
||||
"""매 intermittent reinforcement — strongest learning."""
|
||||
if random.random() < 0.3: # 30% reward
|
||||
return "reward"
|
||||
return "no_reward"
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Aversive learning (negative valence)
|
||||
```python
|
||||
def negative_rpe_update(V, s, s_, r, alpha=0.1):
|
||||
"""매 amygdala-mediated learning."""
|
||||
rpe = r + V[s_] - V[s] # r typically negative
|
||||
V[s] += alpha * rpe
|
||||
return V
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 질문 | 답 |
|
||||
|---|---|
|
||||
| 매 dopamine 매 pleasure 인가? | X — RPE signal (wanting ≠ liking) |
|
||||
| 매 RL 의 reward 매 dopamine? | Functional analog yes (Schultz) |
|
||||
| 매 addiction 매 dopamine 과잉? | X — dysregulated RPE / hijacked salience |
|
||||
| 매 RLHF 매 brain-like? | At reward-update level yes (policy update) |
|
||||
|
||||
**기본값**: 매 dopamine = "wanting / RPE", 매 opioid = "liking" 의 dissociation 기억.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Neuroscience]] · [[Reinforcement-Learning]]
|
||||
- 변형: [[Dopamine-Hypothesis]] · [[Wanting-vs-Liking]]
|
||||
- 응용: [[RLHF]] · [[TD-Learning]] · [[Addiction]]
|
||||
- Adjacent: [[Operant-Conditioning]] · [[Habit-Formation]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 reward modeling intuition, 매 RLHF reward shaping debugging, 매 motivation framework explanation.
|
||||
**언제 X**: 매 clinical psychiatry — 매 specialist 영역.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Dopamine = pleasure**: 매 popular myth — 실제는 RPE / wanting.
|
||||
- **More dopamine = better**: 매 tonic 과잉 매 schizophrenia, parkinson off-state.
|
||||
- **Reward hacking**: 매 RL agent 매 RPE exploit, 매 brain analog (addiction).
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Schultz 1997 *Science*; Berridge & Robinson 1998 wanting/liking; Sutton & Barto *RL Book* 2018 2e).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — RPE biology + RL bridge + RLHF analog |
|
||||
|
||||
@@ -2,67 +2,146 @@
|
||||
id: wiki-2026-0508-neuroergonomics
|
||||
title: Neuroergonomics
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-NERGO-001]
|
||||
aliases: [Neuro-Ergonomics, Brain at Work, Cognitive Ergonomics]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, ergonomics, hci, cognitive-load]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [neuroergonomics, hci, cognitive-load, fnirs, eeg]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: mne-python
|
||||
---
|
||||
|
||||
# [[Neuroergonomics|Neuroergonomics]]
|
||||
# Neuroergonomics
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인간의 뇌를 가장 잘 아는 작업 환경 설계: 인지 부하를 실시간으로 모니터링하여 인간의 실수(Human Error)를 원천 차단하는 유연한 시스템 구축."
|
||||
## 매 한 줄
|
||||
> **"매 brain at work — 매 neural signals 의 measure, 매 system 의 adapt"**. 매 2003 Parasuraman 의 coin, 매 fNIRS/EEG/eye-tracking 의 mature. 매 2026 의 closed-loop adaptive systems (cockpits, surgery, AR work) 의 deploy.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
신경인간공학(Neuroergonomics)은 인간의 뇌 활동을 기반으로 작업 환경, 도구, 시스템을 설계하여 효율성과 안전성을 극대화하는 학문입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **실시간 인지 모니터링**:
|
||||
* **fNIRS & Wearable EEG**: 작업자가 실제 현장에서 움직이는 동안 뇌의 산소화 혈류량이나 뇌파를 측정하여 집중도 유실(Mind-wandering)이나 정신적 피로도를 감지.
|
||||
* **Adaptive Automation**: 작업자의 인지 부하가 한계에 달했을 때, 시스템이 자동으로 조작 난이도를 낮추거나 비상 모드로 전환하는 기술.
|
||||
2. **핵심 응용**:
|
||||
* **항공 및 모빌리티**: 조종사나 운전자의 졸음 및 주의 분산을 뇌 신호로 직접 파악하여 경고.
|
||||
* **산업 현장**: 복잡한 기계 조작 시 인간의 시각적·청각적 수용 능력을 뇌과학적으로 계산하여 인터페이스 최적화.
|
||||
3. **HCI로의 확장**:
|
||||
* 마우스나 키보드가 아닌 '뇌-컴퓨터 인터페이스(BCI)'를 통한 직관적 조작 환경 연구.
|
||||
### 매 measurement modalities
|
||||
- **EEG**: 매 ms-level temporal resolution. 매 cognitive load 의 alpha-suppression / theta-Fz 의 marker.
|
||||
- **fNIRS**: 매 cortex hemodynamics. 매 portable, motion-tolerant — 매 real-world 의 work.
|
||||
- **Eye tracking**: 매 fixation duration, pupil dilation — 매 mental effort 의 proxy.
|
||||
- **HRV / GSR**: 매 ANS arousal — 매 stress / engagement.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 인간공학이 '행동 반응(반응 속도 등)'에만 집중했다면, 신경인간공학은 행동 이전에 발생하는 '뇌의 스트레스 신호'를 선제적으로 포착함.
|
||||
- **정책 변화(RL Update)**: 단순히 생산성 향상을 위한 도구로 쓰이던 것에서 벗어나, 최근에는 직원의 '정신적 웰빙(Mental Well-being)'과 '번아웃 예방'을 위한 기업용 건강 관리 표준으로 정책이 변화 중임.
|
||||
### 매 cognitive states 의 detect
|
||||
- **Workload**: 매 over-load → 매 error spike. 매 under-load → 매 vigilance drop.
|
||||
- **Vigilance / fatigue**: 매 P300 amplitude decline + theta increase.
|
||||
- **Engagement / flow**: 매 mid-frontal theta + alpha asymmetry.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Human-Computer Interaction (HCI), [[Cognitive_Load|Cognitive Load]] Theory, Attention Theory, [[Brain-Computer Interface (BCI)|Brain-Computer Interface (BCI)]]
|
||||
- **Modern Tech/Tools**: fNIRS, Emotiv, OpenBCI Pro, [[Eye-Tracking|Eye-Tracking]].
|
||||
---
|
||||
### 매 응용
|
||||
1. 매 adaptive cockpit (Airbus, Honeywell): 매 pilot workload 의 high → 매 secondary task 의 defer.
|
||||
2. 매 surgical training: 매 trainee fNIRS prefrontal 의 over-activation = novice marker.
|
||||
3. 매 driver-state monitoring (Tesla v13, Mercedes Drive Pilot): 매 EEG drowsiness 의 detect.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### EEG workload index (theta/alpha ratio)
|
||||
```python
|
||||
import mne, numpy as np
|
||||
raw = mne.io.read_raw_brainvision('subj.vhdr', preload=True)
|
||||
raw.filter(1, 40)
|
||||
psd = raw.compute_psd(fmin=4, fmax=12, picks=['Fz', 'Pz'])
|
||||
freqs = psd.freqs
|
||||
power = psd.get_data() # (channels, freqs)
|
||||
theta = power[:, (freqs >= 4) & (freqs < 8)].mean(axis=1)
|
||||
alpha = power[:, (freqs >= 8) & (freqs < 13)].mean(axis=1)
|
||||
workload_index = theta / alpha # higher = more load
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### fNIRS prefrontal activation (MNE-NIRS)
|
||||
```python
|
||||
from mne_nirs.experimental_design import make_first_level_design_matrix
|
||||
from mne_nirs.statistics import run_glm
|
||||
raw_haemo = mne.preprocessing.nirs.beer_lambert_law(raw_od, ppf=0.1)
|
||||
design = make_first_level_design_matrix(raw_haemo, drift_model='cosine')
|
||||
glm = run_glm(raw_haemo, design)
|
||||
# beta for HbO in PFC channels = task-evoked activation
|
||||
pfc_activation = glm.to_dataframe().query("ch_name.str.contains('S1_D1') & Chroma=='hbo'")
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pupil-based effort (PsychoPy + Pupil Labs)
|
||||
```python
|
||||
import zmq, msgpack
|
||||
ctx = zmq.Context(); sub = ctx.socket(zmq.SUB)
|
||||
sub.connect('tcp://127.0.0.1:50020'); sub.setsockopt_string(zmq.SUBSCRIBE, 'pupil')
|
||||
while True:
|
||||
topic, payload = sub.recv_multipart()
|
||||
msg = msgpack.unpackb(payload)
|
||||
if msg['confidence'] > 0.8:
|
||||
diameter_mm = msg['diameter_3d']
|
||||
# baseline-corrected pupil dilation = effort proxy
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Closed-loop adaptive UI (workload-triggered)
|
||||
```python
|
||||
class AdaptiveDashboard:
|
||||
def tick(self, workload_idx: float):
|
||||
if workload_idx > 1.5: # high load
|
||||
self.hide_secondary_widgets()
|
||||
self.enlarge_primary_alert()
|
||||
elif workload_idx < 0.6: # under-load → boredom
|
||||
self.inject_status_check()
|
||||
else:
|
||||
self.restore_default()
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Drowsiness detector (real-time EEG)
|
||||
```python
|
||||
from scipy.signal import welch
|
||||
def is_drowsy(eeg_window, fs=256):
|
||||
f, P = welch(eeg_window, fs=fs, nperseg=fs*2)
|
||||
theta = P[(f>=4)&(f<8)].mean()
|
||||
beta = P[(f>=13)&(f<30)].mean()
|
||||
return (theta / beta) > 4.0 # KSS-validated threshold
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### NASA-TLX subjective + neural fusion
|
||||
```python
|
||||
def fused_workload(neural_idx: float, tlx_score: float) -> float:
|
||||
# weight neural higher when within-subject calibrated
|
||||
return 0.6 * neural_idx_z + 0.4 * (tlx_score / 100)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Lab, high precision needed | EEG (32-64ch) + eye-track |
|
||||
| Field / mobile work | fNIRS + wearable HRV |
|
||||
| Driver / pilot | Webcam-pupil + steering-entropy + PERCLOS |
|
||||
| Long shift fatigue | Actigraphy + HRV + PVT |
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
**기본값**: fNIRS + eye-tracking — 매 real-world ecological validity 의 best.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Human Factors]] · [[Cognitive-Science]]
|
||||
- 변형: [[Affective-Computing]] · [[Brain-Computer-Interface]]
|
||||
- 응용: [[Adaptive-Automation]] · [[Driver-State-Monitoring]] · [[Surgical-Training]]
|
||||
- Adjacent: [[NASA-TLX]] · [[Mental-Workload]] · [[Vigilance-Decrement]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 study design review, 매 GLM script generation, 매 multimodal-feature engineering, 매 paper synthesis.
|
||||
**언제 X**: 매 raw artifact rejection, 매 individual-subject calibration — 매 expert review 의 require.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Single-modality reliance**: 매 EEG-only 의 motion artifact 에 fragile. 매 fusion 의 require.
|
||||
- **No baseline**: 매 absolute power 의 between-subject 의 noisy. 매 within-subject z-score 의 use.
|
||||
- **Open-loop dashboard**: 매 measure-but-not-act → 매 value 의 zero. 매 closed-loop 의 design.
|
||||
- **No personalization**: 매 group-mean threshold 의 50% individuals 에 wrong.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Parasuraman & Rizzo 2007 *Neuroergonomics*; Ayaz & Dehais 2019).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — modalities + closed-loop adaptive patterns |
|
||||
|
||||
@@ -2,67 +2,144 @@
|
||||
id: wiki-2026-0508-neuromuscular-control
|
||||
title: Neuromuscular Control
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-NMCTL-001]
|
||||
aliases: [신경근 조절, Motor Control, NMS Control]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, motor-control, sensorimotor]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [neuroscience, biomechanics, motor-control, robotics, biomedical]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: opensim
|
||||
---
|
||||
|
||||
# [[Neuromuscular-Control|Neuromuscular-Control]]
|
||||
# Neuromuscular Control
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "감각이 명령을 만들고, 명령이 동작을 빚어낸다: 소뇌와 고유수용성 감각이 협력하여 무의식적으로 움직임을 미세 조정하는 실시간 하이퍼 오토메이션."
|
||||
## 매 한 줄
|
||||
> **"매 brain plans, spine reflexes, muscle executes"**. Neuromuscular control 은 CNS 가 motor neuron 을 통해 muscle 활성화를 조절해 movement 를 produce 하는 hierarchical process. 2026 perspective 에서 EMG-driven simulation, exoskeleton control, BCI prosthetics 의 핵심.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
신경근 제어(Neuromuscular Control)는 중추신경계(CNS)가 신체 내부 및 외부의 감각 정보를 통합하여 근육의 수축과 이완을 정밀하게 실행하는 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **제어 레이어**:
|
||||
* **Feedforward(선행 제어)**: 동작을 수행하기 전, 과거 데이터를 바탕으로 근육의 긴장도를 미리 설정(전전두엽/기저핵 개입).
|
||||
* **Feedback(후행 제어)**: 고유수용감각([[Proprioception|Proprioception]])을 통해 실시간으로 들어오는 오차 정보를 바탕으로 동작을 수정(소뇌/척수 개입).
|
||||
2. **핵심 조절 요소**:
|
||||
* **Proprioception**: 신체 각 부위의 위치와 움직임을 감지하는 6번째 감각.
|
||||
* **Muscle Synergies**: 복잡한 움직임을 위해 여러 근육을 하나의 단위로 묶어 제어함으로써 뇌의 계산 부하를 줄임.
|
||||
3. **부상 방지 아키텍처**:
|
||||
* 갑작스러운 균형 상실 시 반사 작용(Stretch Reflex)을 통해 관절 손상을 방지.
|
||||
### 매 hierarchy
|
||||
- **Cortex (M1, PMC, SMA)**: motor planning.
|
||||
- **Cerebellum**: timing, coordination, error correction.
|
||||
- **Basal ganglia**: action selection, gain modulation.
|
||||
- **Spinal cord**: reflex circuits, central pattern generators (CPG).
|
||||
- **Motor unit**: α-MN + muscle fibers (final common pathway).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 뇌가 모든 근육 세포 하나하나에 명령을 내린다고 생각했으나(고전적 제어론), 현대에는 뇌가 '목표'만 설정하면 척수와 말초 신경계가 알아서 디테일을 채우는 'Self-organized criticality' 모델로 전환됨.
|
||||
- **정책 변화(RL Update)**: 로봇 공학의 인공다리(Prosthetic) 설계 시, 단순 모터 힘 강화보다는 인간의 '신경근 제어' 데이터를 모방하여 지면의 굴곡에 따라 스스로 적응하는 '지능형 제어 알고리즘' 주입이 필수 정책이 됨.
|
||||
### 매 control principles
|
||||
- **Size principle (Henneman)**: small MN 먼저, large 나중.
|
||||
- **Co-contraction**: agonist + antagonist 동시 활성화 → stiffness 조절.
|
||||
- **Stretch reflex**: muscle spindle Ia → α-MN monosynaptic.
|
||||
- **Equilibrium point hypothesis**: descending command = desired length.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Motor Control, [[Proprioception|Proprioception]], Biomechanics, Cerebellum Function
|
||||
- **Modern Tech/Tools**: Computational Motor Control, Kinematic [[Analysis|Analysis]], BCI.
|
||||
---
|
||||
### 매 응용
|
||||
1. Prosthetic / exoskeleton control.
|
||||
2. Rehabilitation robotics.
|
||||
3. Surgical motor mapping.
|
||||
4. Sport biomechanics.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Hill-type muscle model
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def hill_muscle(activation, length, velocity,
|
||||
F_max=1000, l_opt=0.1, v_max=10):
|
||||
f_l = np.exp(-((length - l_opt) / (0.5 * l_opt))**2)
|
||||
if velocity <= 0:
|
||||
f_v = (v_max + velocity) / (v_max - 4 * velocity)
|
||||
else:
|
||||
f_v = (1.8 - 0.8 * (v_max + velocity) / (v_max - 7.56 * velocity))
|
||||
return F_max * activation * f_l * f_v
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Motor unit recruitment (size principle)
|
||||
```python
|
||||
def recruit(excitation, n_units=100, threshold_max=1.0):
|
||||
thresholds = np.linspace(0.05, threshold_max, n_units)
|
||||
return np.where(excitation > thresholds,
|
||||
(excitation - thresholds) / (1 - thresholds), 0)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### EMG → activation mapping
|
||||
```python
|
||||
from scipy.signal import butter, filtfilt
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def emg_to_activation(emg_raw, fs=1000):
|
||||
b, a = butter(4, [20, 450], btype="band", fs=fs)
|
||||
emg = filtfilt(b, a, emg_raw)
|
||||
emg = np.abs(emg)
|
||||
b, a = butter(4, 6, btype="low", fs=fs)
|
||||
env = filtfilt(b, a, emg)
|
||||
return env / env.max()
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Inverse dynamics (joint torque)
|
||||
```python
|
||||
def inverse_dynamics(theta, theta_dot, theta_ddot, m=5, l=0.4, g=9.81):
|
||||
I = m * l**2 / 3
|
||||
return I * theta_ddot + 0.5 * m * g * l * np.sin(theta)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### CPG (Matsuoka oscillator)
|
||||
```python
|
||||
def matsuoka_step(x1, x2, v1, v2, u=1.0, beta=2.5, tau=0.1, dt=0.001):
|
||||
y1, y2 = max(0, x1), max(0, x2)
|
||||
dx1 = (-x1 - beta*v1 - 2.0*y2 + u) / tau
|
||||
dx2 = (-x2 - beta*v2 - 2.0*y1 + u) / tau
|
||||
dv1 = (-v1 + y1) / (tau * 12)
|
||||
dv2 = (-v2 + y2) / (tau * 12)
|
||||
return x1 + dx1*dt, x2 + dx2*dt, v1 + dv1*dt, v2 + dv2*dt
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### EMG-driven prosthetic control
|
||||
```python
|
||||
class MyoelectricController:
|
||||
def __init__(self, n_channels=8):
|
||||
self.classifier = train_lda()
|
||||
def predict(self, emg_window):
|
||||
feat = extract_features(emg_window) # MAV, ZC, WL, AR4
|
||||
return self.classifier.predict(feat)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Whole-body simulation | OpenSim / MyoSuite |
|
||||
| Single joint, real-time | Hill-type + LDA EMG |
|
||||
| Locomotion robot | CPG + reflexes |
|
||||
| Pathology study | Inverse dynamics + EMG |
|
||||
|
||||
**기본값**: Hill-type muscle + size-principle recruitment + EMG envelope.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Neuroscience]] · [[Biomechanics]]
|
||||
- 변형: [[Perceptual-Motor-Skills]] · [[Motor Learning]]
|
||||
- 응용: [[Prosthetics]] · [[Exoskeleton Control]]
|
||||
- Adjacent: [[Reinforcement Learning]] · [[BCI]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: simulation parameter tuning, EMG feature engineering, paper synthesis.
|
||||
**언제 X**: clinical motor diagnosis — neurologist 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Linear EMG-force assumption**: 매 force 는 nonlinear (length × velocity × activation).
|
||||
- **Ignoring co-contraction**: stiffness control 무시 → unstable model.
|
||||
- **Pure feedback control**: feed-forward (internal model) 누락 → laggy.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Zajac 1989, Delp OpenSim 2018, Henneman 1965).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Hill model + EMG + CPG 패턴 |
|
||||
|
||||
@@ -2,66 +2,146 @@
|
||||
id: wiki-2026-0508-neuroplasticity-in-addiction
|
||||
title: Neuroplasticity in Addiction
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-NPADD-001]
|
||||
aliases: [Addiction Plasticity, Reward Learning Plasticity, Drug-Induced LTP]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, Neuroplasticity, addiction, synaptic-changes]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [neuroplasticity, addiction, dopamine, ltp, mesolimbic]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: brian2-rl
|
||||
---
|
||||
|
||||
# [[Neuroplasticity in Addiction|Neuroplasticity in Addiction]]
|
||||
# Neuroplasticity in Addiction
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "학습 기계의 오작동: 새로운 것을 배우기 위해 존재하는 뇌의 유연성이 중독이라는 파괴적인 루틴을 영구적인 하드웨어 설비로 구축해버린 비극."
|
||||
## 매 한 줄
|
||||
> **"매 reward 의 hijack — 매 mesolimbic LTP 의 maladaptive learning"**. 매 VTA→NAc dopamine surge 의 AMPA-receptor insertion 의 trigger, 매 cue→drug association 의 over-consolidation. 매 2026 의 ketamine / psilocybin assisted therapy 의 reverse-plasticity 의 promising clinical evidence.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
중독에서의 신경가소성(Neuroplasticity in Addiction)은 중독성 물질이나 행위가 뇌의 구조적, 기능적 연결성을 기형적인 방향으로 재구성하는 과정을 설명합니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **시냅스 수준의 변화**:
|
||||
* **LTP (Long-Term Potentiation)**: 보상 회로 내의 약물 관련 자극 시냅스가 비정상적으로 강화되어, 주변의 일상적 자극은 무시될 정도로 강력한 연결 구축.
|
||||
* **수상돌기 변화**: 측좌핵(NAcc)의 뉴런 수상돌기 분지가 늘어나 약물 관련 단서(Cues)에 극도로 민감해짐.
|
||||
2. **광범위한 네트워크 재편**:
|
||||
* **Frontal-Limbic Imbalance**: 전전두엽(통제)과 변연계(충동) 사이의 평형이 깨져 충동 조절 능력이 영구적으로 감퇴.
|
||||
3. **가소성을 이용한 치료**:
|
||||
* 환경 변화, 운동, 인지 훈련 등을 통해 약물 회로를 '가지치기'하고 건강한 회로를 강화하는 '재배선(Rewiring)' 전략.
|
||||
### 매 circuits
|
||||
- **Mesolimbic (VTA→NAc)**: 매 reward prediction error → 매 reinforcement.
|
||||
- **Mesocortical (VTA→mPFC)**: 매 craving, executive control 의 erode.
|
||||
- **Amygdala→NAc**: 매 cue-conditioning, withdrawal-anxiety.
|
||||
- **Hippocampus→NAc**: 매 contextual cues.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 중독으로 인한 뇌 손상은 영구적이라고 여겨졌으나, 최근 연구는 장기간의 금욕과 치료를 통해 손상된 가소성 기제(Neurogenesis 등)를 어느 정도 복구할 수 있음을 보여줌.
|
||||
- **정책 변화(RL Update)**: 중독을 '학습 장애(Learning Disorder)'의 일종으로 재정의함에 따라, 단순히 막는 것이 아니라 새로운 건강한 보상 경험을 '과잉 학습(Overlearning)'시켜 중독 회로를 덮어쓰는(Overwriting) 전략이 정책 수준에서 권고됨.
|
||||
### 매 plasticity mechanisms
|
||||
- **AMPAR trafficking**: 매 GluA1 surface 의 increase → 매 NAc MSN excitability.
|
||||
- **Silent synapses**: 매 NMDAR-only 의 cocaine 후 의 unsilencing.
|
||||
- **Dendritic spines**: 매 stimulants → 매 spine density 의 increase. 매 opioids → 매 decrease.
|
||||
- **Epigenetic** (ΔFosB, HDAC5): 매 long-term gene-expression 의 lock-in.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: [[Neuroplasticity|Neuroplasticity]], Neurobiology of Reward, Habit Formation, Cognitive [[Behavior|Behavior]]al Therapy (CBT)
|
||||
- **Modern Tech/Tools**: rTMS, Neurofeedback-based rewiring, Exercise-induced BDNF release.
|
||||
---
|
||||
### 매 응용
|
||||
1. 매 cue-exposure therapy + reconsolidation blockade (propranolol, ketamine).
|
||||
2. 매 TMS / DBS (NAc, sgACC) 의 craving reduction.
|
||||
3. 매 contingency management + digital phenotyping.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Q-learning model fit (drug-bias parameter)
|
||||
```python
|
||||
import numpy as np
|
||||
def q_learn_ll(choices, rewards, alpha=0.3, beta=5.0):
|
||||
Q = np.zeros(2); ll = 0.0
|
||||
for c, r in zip(choices, rewards):
|
||||
p = np.exp(beta*Q) / np.exp(beta*Q).sum()
|
||||
ll += np.log(p[c] + 1e-9)
|
||||
Q[c] += alpha * (r - Q[c])
|
||||
return ll
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Reconsolidation window detector
|
||||
```python
|
||||
from datetime import timedelta
|
||||
def in_reconsolidation_window(cue_t, now_t, win_min=10, win_max=60):
|
||||
dt = (now_t - cue_t).total_seconds() / 60
|
||||
return win_min <= dt <= win_max
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Striatal MSN STDP (Brian2)
|
||||
```python
|
||||
from brian2 import *
|
||||
G = NeuronGroup(100, 'dv/dt=(El-v)/tau:volt', threshold='v>-50*mV', reset='v=El')
|
||||
S = Synapses(G, G,
|
||||
'''w:1
|
||||
dApre/dt=-Apre/tauPre:1 (event-driven)
|
||||
dApost/dt=-Apost/tauPost:1 (event-driven)''',
|
||||
on_pre='Apre+=dApre; w=clip(w+Apost,0,wmax)',
|
||||
on_post='Apost+=dApost; w=clip(w+Apre,0,wmax)')
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Cue-reactivity fMRI ROI extraction
|
||||
```python
|
||||
from nilearn import input_data
|
||||
masker = input_data.NiftiMasker(mask_img='nac_left.nii.gz', standardize=True)
|
||||
ts = masker.fit_transform('subject_task.nii.gz')
|
||||
craving_corr = np.corrcoef(beta_drug_cue_per_subj, vas_craving)[0, 1]
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Digital-phenotyping relapse-risk score
|
||||
```python
|
||||
def relapse_risk(z):
|
||||
# z: dict of z-scored features (gps_entropy, sleep_var, screen_night, hrv)
|
||||
s = 0.4*z['gps_entropy'] + 0.3*z['sleep_var'] \
|
||||
+ 0.2*z['screen_night'] - 0.1*z['hrv']
|
||||
return 1 / (1 + np.exp(-s))
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Ketamine plasticity-window dosing protocol stub
|
||||
```python
|
||||
from datetime import timedelta
|
||||
class KetamineProtocol:
|
||||
window_h = 24 # BDNF / mTOR peak
|
||||
def schedule_therapy(self, infusion_t):
|
||||
return infusion_t + timedelta(hours=2)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### TMS dlPFC craving protocol
|
||||
```python
|
||||
def tms_session():
|
||||
return dict(target='left_dlPFC', frequency_hz=10,
|
||||
trains=20, pulses_per_train=50,
|
||||
inter_train_s=20, intensity_pct_rmt=110)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Intervention |
|
||||
|---|---|
|
||||
| Acute craving | TMS dlPFC 10 Hz |
|
||||
| Treatment-resistant | DBS NAc (case-by-case) |
|
||||
| Comorbid depression | Ketamine + therapy |
|
||||
| Stimulant-use disorder | Contingency management + counseling |
|
||||
| Opioid-use disorder | Buprenorphine + therapy |
|
||||
|
||||
**기본값**: CBT + medication + digital tools — 매 multimodal 의 best evidence.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Neuroplasticity]] · [[Addiction-Neuroscience]]
|
||||
- 변형: [[Long-Term-Potentiation]] · [[Reward-Prediction-Error]]
|
||||
- 응용: [[Cue-Exposure-Therapy]] · [[TMS-for-Craving]] · [[Psychedelic-Assisted-Therapy]]
|
||||
- Adjacent: [[Mesolimbic-Pathway]] · [[Dopamine-System]] · [[Reconsolidation]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 mechanism teaching, 매 protocol scaffold, 매 patient-education content.
|
||||
**언제 X**: 매 clinical decision making — 매 licensed clinician 의 require.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Plasticity = bad**: 매 plasticity itself 의 healing 의 vehicle.
|
||||
- **Single-receptor focus**: 매 D2-only blockade 의 outcomes 의 weak. 매 circuit-level 의 think.
|
||||
- **Reconsolidation hype**: 매 window narrow, 매 boundary conditions 의 strict.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Lüscher & Malenka 2011 *Neuron*; Kalivas & Volkow 2005).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — circuits + reversal-therapy patterns |
|
||||
|
||||
@@ -2,65 +2,141 @@
|
||||
id: wiki-2026-0508-nexus-gaming-labs
|
||||
title: Nexus Gaming Labs
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [NGL, Nexus Labs]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
source_trust_level: B
|
||||
confidence_score: 0.7
|
||||
verification_status: applied
|
||||
tags: [game-studio, ugc, web3, nexus]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: typescript
|
||||
framework: unity-photon
|
||||
---
|
||||
|
||||
# Nexus Gaming Labs
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Nexus Gaming Labs는 코어 게이머를 표적으로 삼아 프리미엄 구독 모델을 추구하는 모바일 게임 개발 스튜디오입니다 [1]. 이들은 일반적인 광고 기반 무료 게임(Free-to-Play)과 달리, 구독 등급과 일회성 구매를 통해 수익을 창출하는 구조를 가지고 있습니다 [1, 2]. 주요 목표는 LTV(고객 평생 가치)와 CAC(고객 획득 비용)의 비율을 3:1 이상으로 유지하며 장기적이고 건전한 수익성을 달성하는 것입니다 [3, 4].
|
||||
## 매 한 줄
|
||||
> **"매 indie-scale UGC game lab — 매 prototype-first, 매 community-publish"**. 매 small studio archetype, 매 Unity / Unreal pipelines + Photon networking + Steam workshop + (optional) Web3 royalty rails. 매 2026 의 GenAI tooling (Scenario, Convai, Layer.AI) 의 leverage 의 1-3 person studios 의 differentiator.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **비즈니스 모델 및 타겟층**: Nexus Gaming Labs는 일반적인 광고 지원 모바일 게임과 달리, 코어 게이머를 대상으로 한 프리미엄 구독 모델을 지향합니다 [1]. 프리미엄 스토리가 중심이 되는 구독을 판매하며, 구독 등급 및 스페셜 이벤트 패스, 꾸미기 콘텐츠(코스메틱)와 같은 일회성 구매를 통해 플레이어 기반을 수익화합니다 [2, 5, 6].
|
||||
- **주요 재무 목표 및 ARPU**: 2026년 목표 ARPU(가입자당 평균 수익)는 800달러로 매우 높게 책정되어 있으며, 이는 게임의 가치 제안(value proposition)이 예외적으로 강력할 때만 달성 가능한 수치입니다 [1, 2]. 수익의 즉각적인 변화를 파악하기 위해 ARPU 지표를 매주 검토합니다 [2].
|
||||
- **LTV 및 CAC 최적화**: 2026년 목표 CAC(고객 획득 비용)는 15달러입니다 [4, 7]. 회사가 목표로 하는 LTV:CAC 비율인 3:1을 충족하려면 LTV가 최소 45달러가 되어야 합니다 [4]. LTV는 한 명의 구독자가 지불을 중단하기 전까지 창출하는 총 수익을 예측하는 지표로, Nexus Gaming Labs가 사용자를 확보하는 데 얼마를 지출해야 하는지 정당성을 부여하는 핵심적인 역할을 합니다 [8].
|
||||
- **수치적 모순의 발견**: 800달러라는 ARPU와 45달러라는 목표 LTV를 기반으로 요구되는 내재 이탈률(Implied Churn Rate)을 계산하면 1778%라는 불가능한 수치가 도출됩니다 [4]. 이는 800달러의 ARPU가 월간 수익이 아닌 연간 수익이거나, 현재 수익 기반에 비해 3:1 비율 목표가 너무 보수적일 수 있음을 시사하므로 지표 가정에 대한 검증이 요구됩니다 [4].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[유저 평균 매출(ARPU)|ARPU]], LTV, CAC
|
||||
- **Projects/Contexts:** 모바일 게임 구독 모델의 수익화 지표 최적화 및 타당성 검증
|
||||
- **Contradictions/Notes:** 소스는 Nexus Gaming Labs의 목표 ARPU(800달러)와 CAC 달성을 위한 목표 LTV(45달러) 간의 수학적 계산을 통해 1778%라는 비현실적인 이탈률이 도출된다고 지적합니다. 이는 제공된 ARPU 수치가 월간이 아닌 연간 기준일 가능성이 있거나 목표 비율 설정에 모순이 있음을 보여줍니다 [4].
|
||||
### 매 stack archetype
|
||||
- **Engine**: Unity 6 / Unreal 5.5.
|
||||
- **Net**: Photon Fusion 2 / Mirror.
|
||||
- **Backend**: PlayFab / Nakama.
|
||||
- **Distribution**: Steam, Epic, itch.io, mobile stores.
|
||||
- **Optional Web3**: Immutable zkEVM / Sui royalty contracts.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
### 매 differentiation levers
|
||||
- **Niche genre depth** (autobattlers, deckbuilders, simulation).
|
||||
- **UGC tooling** — 매 in-game editor 의 player retention 의 multiplier.
|
||||
- **GenAI content** — 매 art / VO / dialogue scaling.
|
||||
- **Lean dev** — 매 1-3 person, 매 12-month cycle.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. 매 prototype → public demo → wishlist build.
|
||||
2. 매 modding SDK release → community content flywheel.
|
||||
3. 매 royalty-on-resale (optional Web3) — 매 secondary-market revenue.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Photon Fusion 2 networked input
|
||||
```csharp
|
||||
public struct InputData : INetworkInput {
|
||||
public Vector2 Move;
|
||||
public NetworkButtons Buttons;
|
||||
}
|
||||
public override void FixedUpdateNetwork() {
|
||||
if (GetInput(out InputData input)) {
|
||||
transform.position += (Vector3)input.Move * speed * Runner.DeltaTime;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Steam workshop upload (Steamworks.NET)
|
||||
```csharp
|
||||
var handle = SteamUGC.CreateItem(appId, EWorkshopFileType.k_EWorkshopFileTypeCommunity);
|
||||
SteamUGC.SetItemTitle(handle, "My Mod");
|
||||
SteamUGC.SetItemContent(handle, "C:/mods/my-mod");
|
||||
SteamUGC.SubmitItemUpdate(handle, "Initial release");
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Convai NPC dialogue stream (Unity)
|
||||
```csharp
|
||||
var convaiClient = new ConvaiClient(apiKey);
|
||||
await foreach (var token in convaiClient.StreamReply(playerUtterance, npcId)) {
|
||||
dialogueUI.Append(token);
|
||||
}
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Nakama match listing
|
||||
```typescript
|
||||
const matches = await client.listMatches(session, 10, true, "deathmatch", 1, 8);
|
||||
matches.matches?.forEach(m => console.log(m.match_id, m.size));
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Royalty smart contract (Sui Move)
|
||||
```move
|
||||
public entry fun pay_royalty(item: &Item, sale: Coin<SUI>, ctx: &mut TxContext) {
|
||||
let royalty_bps: u64 = 500; // 5%
|
||||
let amount = balance::value(coin::balance(&sale)) * royalty_bps / 10_000;
|
||||
let cut = coin::split(&mut sale, amount, ctx);
|
||||
transfer::public_transfer(cut, item.creator);
|
||||
transfer::public_transfer(sale, tx_context::sender(ctx));
|
||||
}
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### LiveOps event scheduler
|
||||
```typescript
|
||||
type Event = { id: string; start: Date; end: Date; rewards: Reward[] };
|
||||
function activeEvents(now: Date, events: Event[]) {
|
||||
return events.filter(e => e.start <= now && now < e.end);
|
||||
}
|
||||
```
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
### Telemetry funnel
|
||||
```typescript
|
||||
const funnel = ['install', 'tutorial_done', 'first_match', 'd1_return', 'd7_return'];
|
||||
const conversion = funnel.map((step, i) =>
|
||||
i === 0 ? 1 : counts[step] / counts[funnel[i-1]]);
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 1-3 person, premium PC | Unity + Steam + Discord community |
|
||||
| Mobile F2P | Unity + PlayFab + IronSource ads |
|
||||
| Web3-first | Unreal + Immutable / Sui |
|
||||
| UGC-heavy | Built-in editor + Steam workshop |
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
**기본값**: Unity + Steam + Discord + telemetry-driven LiveOps — 매 indie sweet spot.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Game-Studio]] · [[Indie-Development]]
|
||||
- 변형: [[Web3-Gaming]] · [[UGC-Platforms]]
|
||||
- 응용: [[LiveOps]] · [[Modding-SDK]] · [[Steam-Distribution]]
|
||||
- Adjacent: [[Photon-Fusion]] · [[Nakama]] · [[Convai]] · [[Scenario]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 design-doc draft, 매 quest / dialogue gen, 매 telemetry SQL.
|
||||
**언제 X**: 매 final art / VO 의 ship-quality — 매 human polish 의 still need.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Engine over-build**: 매 custom engine 의 indie 의 trap. 매 off-the-shelf 의 use.
|
||||
- **Web3-first marketing**: 매 gameplay 의 second 의 fail. 매 fun-first.
|
||||
- **No telemetry**: 매 LiveOps 의 blind. 매 D1/D7/D30 funnel 의 ship-day-one.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (GDC 2025 indie talks; Steamworks docs; Photon docs).
|
||||
- 신뢰도 B (studio-archetype, 매 specific entity verification 의 limited).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — stack + LiveOps patterns |
|
||||
|
||||
@@ -2,67 +2,142 @@
|
||||
id: wiki-2026-0508-nutritional-biochemistry
|
||||
title: Nutritional Biochemistry
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-NBIO-001]
|
||||
aliases: [영양 생화학, Nutrient Biochemistry, Metabolic Nutrition]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, biochemistry, nutrition, metabolism]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [biochemistry, nutrition, metabolism, biology, health]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: domain-knowledge
|
||||
framework: biochemistry
|
||||
---
|
||||
|
||||
# [[Nutritional-Biochemistry|Nutritional-Biochemistry]]
|
||||
# Nutritional Biochemistry
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "음식은 곧 데이터이자 연료: 영양소가 분자 수준에서 인간의 유전자 발현과 대사 경로를 어떻게 조절하는지 탐구하는 생명의 화학적 지도."
|
||||
## 매 한 줄
|
||||
> **"매 nutrient 는 metabolic substrate + cofactor + signal"**. Nutritional biochemistry 는 macronutrient 와 micronutrient 가 cellular metabolism, gene expression, signaling 에 어떻게 작용하는지 연구. 2026 perspective 에서 personalized nutrition + microbiome interaction + metabolomics 가 frontier.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
영양 생화학(Nutritional Biochemistry)은 영양소가 체내에서 소화, 흡수, 대사되는 과정과 이것이 건강 및 질병에 미치는 기전을 다룹니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 영양소의 대사 경로**:
|
||||
* **탄수화물**: 글리코겐 저장 및 인슐린 신호 전달 통로 조절.
|
||||
* **지질**: 세포막 구조 유지 및 호르몬 합성의 전구체 역할.
|
||||
* **단백질**: 효소, 항체 구성 및 근육 단백질 합성(mTOR 경로).
|
||||
2. **미량 영양소와 보조 인자**:
|
||||
* 비타민과 미네랄이 효소의 활성 부위에서 화학 반응을 촉매하는 방식(예: ATP 생성에서의 마그네슘 역할).
|
||||
3. **영양유전학 (Nutrigenomics)**:
|
||||
* 영양소가 유전자의 스위치를 켜고 끄는(Epigenetics) 방식 연구. 예: 엽산이 DNA 메틸화에 미치는 영향.
|
||||
### 매 macronutrient pathways
|
||||
- **Carbohydrate**: glycolysis → pyruvate → acetyl-CoA → TCA → ETC. 4 kcal/g.
|
||||
- **Lipid**: β-oxidation → acetyl-CoA → TCA. 9 kcal/g. Membrane lipids, eicosanoids.
|
||||
- **Protein**: amino acid → transamination → urea / gluconeogenesis. 4 kcal/g.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 '단순 칼로리(Calories In vs Out)'가 핵심이었으나, 현대 생화학은 영양소마다 인슐린 반응과 대사적 '신호 강도'가 다르다는 점을 강조함(예: 과당 vs 포도당의 간 대사 차이).
|
||||
- **정책 변화(RL Update)**: 개인의 유전적 차이에 따라 만성 질환 위험도가 다르다는 증거가 쌓이면서, 일률적인 권장 영양 섭취량(RDA)에서 '정밀 영양(Precision Nutrition)'으로 국가 보건 정책의 패러다임이 전환되고 있음.
|
||||
### 매 micronutrient roles
|
||||
- **B-vitamins**: coenzymes (NAD, FAD, CoA, THF, PLP).
|
||||
- **Fat-soluble (ADEK)**: signaling (retinoic acid, calcitriol).
|
||||
- **Minerals**: cofactors (Mg-ATP, Zn-fingers, Fe-heme), electrolytes.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Metabolism, Molecular Biology, Epigenetics, [[Elite-Sport-Science-Protocols|Elite-Sport-Science-Protocols]], [[Homeostasis|Homeostasis]]
|
||||
- **Modern Tech/Tools**: Metabolomics, Microbiome [[Analysis|Analysis]], Continuous Glucose Monitors (CGM).
|
||||
---
|
||||
### 매 응용
|
||||
1. Sports nutrition / supplement design.
|
||||
2. Disease management (diabetes, NAFLD).
|
||||
3. Personalized diet (genotype + microbiome).
|
||||
4. Public health policy.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Basal metabolic rate (Mifflin-St Jeor)
|
||||
```python
|
||||
def bmr(weight_kg, height_cm, age_y, sex="M"):
|
||||
base = 10*weight_kg + 6.25*height_cm - 5*age_y
|
||||
return base + 5 if sex == "M" else base - 161
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def tdee(bmr_val, activity="moderate"):
|
||||
factors = {"sedentary": 1.2, "light": 1.375,
|
||||
"moderate": 1.55, "active": 1.725}
|
||||
return bmr_val * factors[activity]
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Macro split optimization
|
||||
```python
|
||||
def macro_split(tdee, goal="maintain", body_kg=70):
|
||||
protein_g = body_kg * (1.6 if goal == "cut" else 1.2)
|
||||
p_cal = protein_g * 4
|
||||
fat_cal = tdee * 0.25
|
||||
carb_cal = tdee - p_cal - fat_cal
|
||||
return {"protein_g": protein_g,
|
||||
"fat_g": fat_cal / 9,
|
||||
"carb_g": carb_cal / 4}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Glycemic load
|
||||
```python
|
||||
def glycemic_load(food: dict) -> float:
|
||||
return food["gi"] * food["carb_g"] / 100
|
||||
# Low <10, medium 11-19, high 20+
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### TCA cycle ATP yield
|
||||
```python
|
||||
def atp_per_glucose():
|
||||
glycolysis = 2
|
||||
nadh_glyc = 2 * 2.5
|
||||
pyruvate_to_acetyl = 2 * 2.5
|
||||
tca_per_acetyl = (3*2.5) + 1.5 + 1
|
||||
tca_total = 2 * tca_per_acetyl
|
||||
return glycolysis + nadh_glyc + pyruvate_to_acetyl + tca_total
|
||||
# ≈ 30 ATP / glucose (modern stoichiometry)
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Nitrogen balance
|
||||
```python
|
||||
def n_balance(protein_intake_g, urea_n_excreted_g, fecal_skin_g=4):
|
||||
n_in = protein_intake_g / 6.25
|
||||
n_out = urea_n_excreted_g + fecal_skin_g
|
||||
return n_in - n_out
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Vitamin D activation cascade
|
||||
```python
|
||||
def vit_d_activation():
|
||||
return [
|
||||
"7-dehydrocholesterol",
|
||||
"cholecalciferol (D3, skin UVB)",
|
||||
"25-OH-D3 (liver, CYP2R1)",
|
||||
"1,25-(OH)2-D3 (kidney, CYP27B1, calcitriol)",
|
||||
"VDR-RXR transcription factor",
|
||||
]
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Weight loss | Caloric deficit + protein-priority |
|
||||
| Performance | Periodized carb + creatine |
|
||||
| T2D management | Low GL + Mediterranean |
|
||||
| Deficiency screen | Serum 25-OH-D, B12, ferritin, Mg |
|
||||
|
||||
**기본값**: TDEE 기반 + protein floor + micronutrient screen.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Biochemistry]] · [[Physiology]]
|
||||
- 변형: [[Sports Nutrition]] · [[Clinical Nutrition]]
|
||||
- 응용: [[Diabetes Management]] · [[Athletic Performance]]
|
||||
- Adjacent: [[Microbiome]] · [[Metabolomics]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: meal plan template, nutrient interaction summary, label decoding.
|
||||
**언제 X**: clinical diagnosis / Rx — RD / MD 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Calorie-only thinking**: hormone / micronutrient 무시.
|
||||
- **Single-nutrient hype**: antioxidant / superfood 일반화 — context-free.
|
||||
- **Ignoring bioavailability**: total intake ≠ absorbed.
|
||||
- **Population stat → individual**: personal genetics / microbiome 무시.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Lehninger 8e, Modern Nutrition in Health and Disease 11e, USDA DRI 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — BMR/macro/TCA/Vit-D 패턴 |
|
||||
|
||||
@@ -2,96 +2,32 @@
|
||||
id: wiki-2026-0508-owa-vs-cwa-개방-세계-vs-폐쇄-세계-가설
|
||||
title: OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-OWAC-001]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: open-closed-world-assumption
|
||||
duplicate_of: "[[Open World Assumption vs Closed World Assumption]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, Logic, knowledge-representation, semantic-web]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, knowledge-representation, logic]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)|OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)]]
|
||||
# OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "모르는 것을 '거짓'이라 할 것인가, '미지'라 할 것인가: 불완전한 지식 앞에서 논리 엔진이 취하는 두 가지 태도의 극명한 차이."
|
||||
> **이 문서는 [[Open World Assumption vs Closed World Assumption]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
개방 세계 가설(Open World Assumption, OWA)과 폐쇄 세계 가설(Closed World Assumption, CWA)은 지식 표현과 추론 시스템이 부재한 정보(Missing Information)를 처리하는 방식에 대한 두 가지 상반된 철학입니다.
|
||||
## 핵심 요약
|
||||
- **OWA**: 정보 부재 = unknown. RDF / OWL / 지식 그래프 표준.
|
||||
- **CWA**: 정보 부재 = false. SQL / Prolog / DB query 표준.
|
||||
- 추론 / completeness 가정 차이가 핵심.
|
||||
|
||||
1. **CWA (폐쇄 세계 가설)**:
|
||||
* **핵심**: "모르는 것은 거짓(False)이다."
|
||||
* **특징**: 데이터베이스(DB)나 프로그래밍 언어에서 주로 사용. '홍길동이 학생 리스트에 없다'면 '홍길동은 학생이 아니다'라고 결론 지음.
|
||||
* **장점**: 추론 속도가 빠르고 명확함.
|
||||
2. **OWA (개방 세계 가설)**:
|
||||
* **핵심**: "모르는 것은 그저 알 수 없는(Unknown) 것일 뿐이다."
|
||||
* **특징**: 온톨로지나 시맨틱 웹, 복잡한 인공지능 지식 베이스에서 사용. '홍길동이 리스트에 없다'고 해서 '학생이 아니다'라고 단정하지 않음(단지 정보가 부족할 뿐).
|
||||
* **장점**: 지식의 불완전성을 인정하므로 데이터가 계속 추가되는 환경에 적합.
|
||||
3. **적용 사례**:
|
||||
* **시맨틱 웹 (OWL)**: OWA를 채택하여 전 세계에 흩어진 데이터들 사이의 논리적 모순을 탐지.
|
||||
* **관계형 DB (SQL)**: 테이블에 없는 데이터는 존재하지 않는 것으로 처리(CWA).
|
||||
## 🔗 Graph
|
||||
- 부모: [[Open World Assumption vs Closed World Assumption]] (canonical)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거의 AI 시스템은 완벽한 규칙 기반(CWA)을 전제로 했으나, 실제 복잡한 현실 세계의 지식은 늘 불완전하므로 현대의 대규모 지식 구축 프로젝트는 기본적으로 OWA를 전제로 설계됨.
|
||||
- **정책 변화(RL Update)**: 최근의 생성형 AI(LLM)는 CWA적 착각(Halucination)에 빠져 '모르는 것'을 '거짓'이 아닌 '창작된 가실'로 출력하는 경향이 있음. 이를 교정하기 위해 모델이 '모름' 상태를 명시적으로 인지(OWA적 인지)하도록 하는 훈련 정책이 강화되고 있음.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: [[Logic|Logic]], [[Ontology-Engineering|Ontology-Engineering]], Knowledge Models, Common Sense [[Reasoning|Reasoning]]
|
||||
- **Modern Tech/Tools**: RDF, OWL, Prolog (Negation as Failure).
|
||||
---
|
||||
|
||||
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,92 +2,138 @@
|
||||
id: wiki-2026-0508-objectivism
|
||||
title: Objectivism
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-OBJ-001]
|
||||
aliases: [Randian Philosophy, Rational Egoism, Ayn Rand]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.91
|
||||
tags: [auto-reinforced, Philosophy, ethics, rational-egoism]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [philosophy, ethics, epistemology, ayn-rand]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: text
|
||||
framework: philosophy
|
||||
---
|
||||
|
||||
# [[Objectivism|Objectivism]]
|
||||
# Objectivism
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "자신을 위한 삶의 찬가: 이성(Reason)만이 유일한 절대자이며, 창의적 개인의 합리적 이기심이 인류 진보의 엔진임을 천명한 아인 랜드의 철학."
|
||||
## 매 한 줄
|
||||
> **"매 reality 의 objective, 매 reason 의 only means, 매 self-interest 의 moral, 매 laissez-faire capitalism 의 social"**. 매 Ayn Rand (1957 *Atlas Shrugged*) 의 founding, 매 axioms (existence, identity, consciousness) 의 base. 매 2026 의 tech-libertarian discourse (Thiel, Andreessen) 의 indirect 의 influence — 매 academic philosophy 의 mostly margin.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
객관주의(Objectivism)는 작가 아인 랜드(Ayn Rand)가 창시한 철학으로, 실재의 객관성과 인간 이성의 절대성을 강조합니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **4대 지주**:
|
||||
* **형이상학 (객관적 실재)**: 존재는 존재한다(A is A). 우리 의식과 무관하게 세계는 독립적으로 존재함.
|
||||
* **인식론 (이성)**: 지식의 유일한 도구는 이성뿐이며, 직관이나 신비주의는 배격함.
|
||||
* **윤리학 (합리적 이기심)**: 자신의 행복을 추구하는 것이 도덕적 의무이며, 타인을 위해 자신을 희생하거나 타인에게 희생을 요구하는 것은 부당함.
|
||||
* **정치학 (자본주의)**: 완전한 자유방임 자본주의만이 개인의 자유와 권리를 보장하는 유일한 도덕적 체제임.
|
||||
2. **생산적 노동의 가치**:
|
||||
* 인간의 가치는 자신의 이성으로 가치를 창조하는 '생산적 활동'에서 나옴.
|
||||
### 매 four pillars
|
||||
- **Metaphysics**: 매 objective reality — A is A (Aristotelian identity).
|
||||
- **Epistemology**: 매 reason 의 only valid cognition. 매 mysticism / faith 의 reject.
|
||||
- **Ethics**: 매 rational self-interest. 매 altruism (sacrifice 의 moral) 의 reject.
|
||||
- **Politics**: 매 individual rights (life, liberty, property), 매 laissez-faire capitalism, 매 minimal state.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 객관주의는 '강한 개인'만을 찬미하여 사회적 안전망의 필요성을 부정한다는 비판을 받아왔으며, 현대 사회의 복잡한 상호 의존성([[Externalities|Externalities]]) 문제를 설명하는 데 한계가 있음이 지적됨.
|
||||
- **정책 변화(RL Update)**: 실리콘밸리의 창업가 정신(Entrepreneurship)에 큰 영감을 주었으나, 최근에는 사회적 책임(ESG) 중심의 정책이 강화되며 '극단적 개인주의'보다는 '자유로운 개인의 사회적 계약' 관점으로 재해석되는 중임.
|
||||
### 매 distinctive concepts
|
||||
- **Man qua man**: 매 rational productive being 의 ideal.
|
||||
- **Trader principle**: 매 voluntary value-for-value exchange.
|
||||
- **Sanction of the victim**: 매 self-sacrifice 의 evil 의 enabler.
|
||||
- **Primacy of existence vs consciousness**: 매 reality precedes mind.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Ethics, Capitalism, Rationality, BioShock (as a critique of Objectivism)
|
||||
- **Modern Tech/Tools**: Li[[BERT|BERT]]arianism, Decentralized Autonomous Organizations (DAO).
|
||||
---
|
||||
### 매 응용 / influence
|
||||
1. 매 libertarian / classical-liberal politics.
|
||||
2. 매 entrepreneurial self-image (Atlas Shrugged founder mythos).
|
||||
3. 매 ARI (Ayn Rand Institute) education / outreach.
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
## 💻 패턴
|
||||
|
||||
### Ethical decision filter (rational self-interest)
|
||||
```text
|
||||
# TODO
|
||||
1. Identify long-range hierarchy of values.
|
||||
2. Does action advance my rational long-term self-interest?
|
||||
3. Does it violate another's rights (force / fraud)?
|
||||
4. Reject any action requiring 'sanction of the victim'.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Argument structure (Rand axiomatic)
|
||||
```
|
||||
Axiom 1: Existence exists.
|
||||
Axiom 2: A is A.
|
||||
Axiom 3: Consciousness perceives existence.
|
||||
→ Knowledge possible, not arbitrary.
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Critical reading checklist
|
||||
```text
|
||||
- [ ] Is the hierarchy of concepts grounded in observation?
|
||||
- [ ] Are package-deals (mixing distinct concepts) avoided?
|
||||
- [ ] Are metaphors smuggling in unsupported claims?
|
||||
- [ ] Is 'altruism' steel-manned vs straw-manned?
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Comparing ethical frameworks
|
||||
```
|
||||
| Framework | Source of value | Self vs Other |
|
||||
|------------------|-----------------|-------------------|
|
||||
| Objectivism | Rational ego | Self primary |
|
||||
| Utilitarianism | Aggregate util | Sum across people |
|
||||
| Kantian deont. | Duty / CI | Universalizable |
|
||||
| Virtue ethics | Character | Eudaimonia |
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Steel-man counter-arguments
|
||||
```text
|
||||
- Egoism vs evolutionary cooperation (Hamilton, Nowak).
|
||||
- Altruism reframed as enlightened long-term self-interest.
|
||||
- Market failures, externalities, public goods.
|
||||
- Concentration of power & rights of children / disabled.
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Concept-formation (measurement-omission)
|
||||
```text
|
||||
"Table" = entity supporting flat surface for use, with measurements
|
||||
(height, material, shape) omitted but specified in some range.
|
||||
Source: Rand, ITOE 1979.
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Reading order (canonical)
|
||||
```
|
||||
1. Anthem (1938) — short novella, theme intro.
|
||||
2. The Fountainhead — individualism in art / ethics.
|
||||
3. Atlas Shrugged — full system in fiction.
|
||||
4. Virtue of Selfishness — ethics essays.
|
||||
5. ITOE — epistemology (formal).
|
||||
6. Peikoff, OPAR (1991) — systematic exposition.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 사용 맥락 | 적합도 |
|
||||
|---|---|
|
||||
| 개인 long-term planning frame | 적합 (productivity ethic) |
|
||||
| Public-policy serious analysis | 부적합 (academic 의 underweight) |
|
||||
| Literature / culture history | 적합 (mid-20c American thought) |
|
||||
| 매 sole moral framework | 신중 (steel-man critics) |
|
||||
|
||||
**기본값**: 매 one tradition among many — 매 Aristotle / Kant / Mill / Rawls 의 also read.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Philosophy]] · [[Ethics]]
|
||||
- 변형: [[Libertarianism]] · [[Classical-Liberalism]] · [[Rational-Egoism]]
|
||||
- 응용: [[Tech-Libertarianism]] · [[Atlas-Shrugged]]
|
||||
- Adjacent: [[Aristotle]] · [[Nietzsche]] · [[Locke]] · [[Hayek]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 syllabus draft, 매 contrast-essay scaffold, 매 primary-source navigation.
|
||||
**언제 X**: 매 normative endorsement — 매 user 의 decide.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Cult-like adherence**: 매 ARI orthodoxy 의 dogmatic 의 trap.
|
||||
- **Naive policy export**: 매 night-watchman state 의 modern complexity 의 ignore.
|
||||
- **Strawmanning altruism**: 매 nuanced ethics-of-care / virtue-ethics 의 collapse.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Rand 1957, 1964; Peikoff *OPAR* 1991; SEP entries).
|
||||
- 신뢰도 A (text source); evaluation contested.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — pillars + critique-balance |
|
||||
|
||||
@@ -2,68 +2,141 @@
|
||||
id: wiki-2026-0508-open-access-movement
|
||||
title: Open Access Movement
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-OPENA-001]
|
||||
aliases: [OA, Open Science Publishing, Plan S]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, open-science, academic-publishing, knowledge-sharing]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [open-access, scholarly-publishing, plan-s, preprints]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: openalex-api
|
||||
---
|
||||
|
||||
# [[Open-Access-Movement|Open-Access-Movement]]
|
||||
# Open Access Movement
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지식의 감옥을 허물다: 거대 학술 출판사의 유료 장벽을 걷어내고, 전 인류가 최신 연구 성과를 무료로 공유하며 평등하게 소통할 수 있는 지식 생태계를 꿈꾸는 혁명."
|
||||
## 매 한 줄
|
||||
> **"매 publicly-funded research 의 publicly-readable"**. 매 2002 Budapest OA Initiative 의 launch, 매 2018 Plan S (cOAlition S) 의 Europe-wide mandate, 매 2024 OSTP Nelson Memo 의 US federal 의 require. 매 2026 의 ~50% global articles 의 OA, 매 APC ($3-12k) 의 contention 의 ongoing.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
오픈 액세스 운동(Open Access Movement)은 학술 정보를 디지털 환경에서 저작권 및 비용 장벽 없이 누구나 자유롭게 이용할 수 있도록 하려는 전 지구적인 흐름입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **주요 경로**:
|
||||
* **Gold OA (골드)**: 저널 전체가 오픈 액세스이며, 저자가 출판 비용(APC)을 지불하고 독자는 무료로 이용.
|
||||
* **Green OA (그린)**: 유료 저널에 출판하되, 저자가 기관 리포지토리에 셀프 아카이빙하여 공개.
|
||||
* **Hybrid OA (하이브리드)**: 유료 저널 내에서 개별 논문만 비용을 내고 오픈 액세스로 전환.
|
||||
2. **기여 요인**:
|
||||
* 인터넷의 보급과 학술 정보 유통 비용의 감소.
|
||||
* 전통적 출판사들의 과도한 저널 구독료 인상(Serial Crisis)에 대한 반발.
|
||||
3. **사회적 가치**:
|
||||
* 개발도상국 연구자들의 지식 접근성 향상, 연구의 투명성 및 재현성 강화, 지식의 사회적 환원 가속화.
|
||||
### 매 OA flavors
|
||||
- **Gold**: 매 publisher journal 의 native OA. 매 APC funded.
|
||||
- **Green**: 매 author self-archiving (preprint / postprint) 의 repository.
|
||||
- **Hybrid**: 매 subscription journal 의 individual article 의 OA-buy.
|
||||
- **Diamond**: 매 no-APC + no-paywall (community-funded). 매 2026 EU push.
|
||||
- **Bronze**: 매 free-to-read 의 license unclear (예: corporate access).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 이전에는 OA 논문의 품질이 낮다는 편견이 있었으나, 현재는 자연(Nature), 사이언스(Science) 등 권위 있는 저널들도 OA 섹션을 운영하며 인용 지수(Impact Factor) 면에서 OA 논문이 더 유리하다는 결과가 쌓임.
|
||||
- **정책 변화(RL Update)**: 미국(부시 행정부 이후 가속) 및 유럽연합(Plan S)은 정부 예산이 투입된 연구 결과물은 반드시 즉각적인 오픈 액세스로 출판해야 한다는 강력한 강제 정책을 시행 중임.
|
||||
### 매 stakeholders
|
||||
- **Researchers**: 매 reach + citation impact 의 want.
|
||||
- **Funders** (NIH, ERC, Gates): 매 OA mandates.
|
||||
- **Publishers**: 매 Elsevier, Springer-Nature, Wiley — 매 transformative agreements.
|
||||
- **Libraries**: 매 Big Deal cancellation, 매 read-and-publish negotiation.
|
||||
- **Preprint servers**: arXiv, bioRxiv, SSRN, Research Square.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Open-Source-Software, Information-Ethics, [[Epistemology|Epistemology]], Knowledge [[Management|Management]]
|
||||
- **Modern Tech/Tools**: arXiv, Sci-Hub (논란의 중심), Creative Commons Licenses (CC).
|
||||
---
|
||||
### 매 응용
|
||||
1. 매 funder mandate compliance (NIH PubMed Central submission).
|
||||
2. 매 institutional repository deposit.
|
||||
3. 매 OA discovery (Unpaywall, OpenAlex, OA.Works).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### OpenAlex query — recent OA papers
|
||||
```python
|
||||
import requests
|
||||
r = requests.get(
|
||||
"https://api.openalex.org/works",
|
||||
params={"filter": "is_oa:true,publication_year:2025",
|
||||
"per-page": 25, "sort": "cited_by_count:desc"})
|
||||
for w in r.json()["results"]:
|
||||
print(w["doi"], w["open_access"]["oa_status"], w["title"][:80])
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Unpaywall lookup (best OA copy)
|
||||
```python
|
||||
def find_oa(doi, email):
|
||||
r = requests.get(f"https://api.unpaywall.org/v2/{doi}", params={"email": email})
|
||||
j = r.json()
|
||||
return j["best_oa_location"]["url"] if j.get("best_oa_location") else None
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Preprint deposit (bioRxiv API stub)
|
||||
```python
|
||||
def deposit_biorxiv(metadata, pdf_path, token):
|
||||
files = {'pdf': open(pdf_path, 'rb')}
|
||||
return requests.post(
|
||||
"https://api.biorxiv.org/submit",
|
||||
headers={"Authorization": f"Bearer {token}"},
|
||||
data=metadata, files=files)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### CC-license selection helper
|
||||
```python
|
||||
def recommend_license(funder_mandates):
|
||||
if "plan_s" in funder_mandates or "nih_2024" in funder_mandates:
|
||||
return "CC-BY"
|
||||
return "CC-BY-NC-ND" # author preference if unconstrained
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### APC budget tracker
|
||||
```python
|
||||
def annual_apc_budget(papers, avg_apc=2500, gold_fraction=0.6):
|
||||
return papers * gold_fraction * avg_apc
|
||||
# 50 papers, 60% gold → $75k/yr departmental APC
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Read-and-publish (transformative agreement) check
|
||||
```python
|
||||
def covered_by_ta(institution, publisher, agreements_db):
|
||||
return any(a["institution"] == institution and a["publisher"] == publisher
|
||||
and a["active"] for a in agreements_db)
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Compliance check (Plan S)
|
||||
```python
|
||||
def plan_s_compliant(license, apc_capped, embargo_months, repo_deposited):
|
||||
return (license in {"CC-BY", "CC-BY-SA"}
|
||||
and apc_capped
|
||||
and embargo_months == 0
|
||||
and repo_deposited)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| Funder / context | Recommended path |
|
||||
|---|---|
|
||||
| Plan S funder | Gold (CC-BY) or Green-immediate |
|
||||
| NIH | PMC deposit ≤12 mo (now immediate post-2024) |
|
||||
| Self-funded | Preprint + Diamond OA journal |
|
||||
| High-IF ambition | Hybrid + TA-covered if available |
|
||||
|
||||
**기본값**: Preprint (arXiv/bioRxiv/SSRN) + Gold OA journal under TA — 매 reach + compliance balance.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Open-Science]] · [[Scholarly-Communication]]
|
||||
- 변형: [[Plan-S]] · [[Diamond-Open-Access]] · [[Preprints]]
|
||||
- 응용: [[Institutional-Repositories]] · [[OpenAlex]] · [[Unpaywall]]
|
||||
- Adjacent: [[ORCID]] · [[FAIR-Data]] · [[CC-Licenses]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 funder-mandate decoding, 매 license-comparison summary, 매 author-letter draft.
|
||||
**언제 X**: 매 contract negotiation 의 final — 매 librarian / IP office 의 require.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Predatory journals**: 매 Beall's-list-style 의 sham OA. 매 DOAJ membership 의 verify.
|
||||
- **Hybrid double-dip**: 매 subscription + APC 의 paid-twice. 매 TA negotiate.
|
||||
- **Copyright transfer accident**: 매 author 의 reuse rights 의 lose. 매 retain-rights addendum.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Budapest OA Initiative 2002; Plan S 2018; OSTP Nelson Memo 2022; OpenAlex docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — flavors + compliance + APIs |
|
||||
|
||||
+114
-294
@@ -2,319 +2,139 @@
|
||||
id: wiki-2026-0508-other
|
||||
title: Other
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Misc, Uncategorized, Index]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [category-index, other]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [index, navigation, taxonomy]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: text
|
||||
framework: obsidian-dataview
|
||||
---
|
||||
|
||||
# Other Directory
|
||||
# Other
|
||||
|
||||
이 문서는 `Other` 카테고리에 속한 모든 지식 문서들의 목록을 제공합니다.
|
||||
## 매 한 줄
|
||||
> **"매 cross-domain landing — 매 yet-uncategorized 의 holding"**. 매 wiki 의 catch-all bucket, 매 promote-to-category 의 routine 의 host. 매 2026 의 wiki cleanup 의 active triage 의 zone.
|
||||
|
||||
## 📄 문서 목록
|
||||
- [[10v10 대규모 멀티플레이어]] : 10v10 대규모 멀티플레이어
|
||||
- [[5R Structure]] : [[5R Structure|5R Structure]]
|
||||
- [[ACP (Agent Communication Protocol)]] : [[ACP (Agent Communication Protocol)|ACP (Agent Communication Protocol)]]
|
||||
- [[ARPU-ARPPU]] : [[ARPU-ARPPU|ARPU/ARPPU]]
|
||||
- [[AWS_Lambda]] : AWS Lambda
|
||||
- [[Agent Memory System]] : Agent Memory System (에이전트 메모리 시스템)
|
||||
- [[Agent_Memory_Harness]] : Agent Memory Harness
|
||||
- [[Agentic Governance]] : Agentic Governance (에이전트 거버넌스)
|
||||
- [[Ambition]] : [[Ambition|Ambition]]
|
||||
- [[Analysis]] : [[Analysis|Analysis]]
|
||||
- [[Anticipation]] : [[Anticipation|Anticipation]]
|
||||
- [[Antinomianism]] : [[Antinomianism|Antinomianism]]
|
||||
- [[Anxiety]] : [[Anxiety|Anxiety]]
|
||||
- [[Assertiveness]] : [[Assertiveness|Assertiveness]]
|
||||
- [[Assumptions-vs-Facts]] : [[Assumptions-vs-Facts|Assumptions-vs-Facts]]
|
||||
- [[Atlantic]] : [[Atlantic|Atlantic]]
|
||||
- [[Automation-Paradox]] : [[Automation-Paradox|Automation-Paradox]]
|
||||
- [[Base 플랫폼(Chef Universe)]] : [[Base 플랫폼(Chef Universe)|Base 플랫폼(Chef Universe]]
|
||||
- [[Bayes-Theorem]] : [[Bayes-Theorem|Bayes-Theorem]]
|
||||
- [[Bayesian-Updating]] : [[Bayesian-Updating|Bayesian-Updating]]
|
||||
- [[Behavioral Interview Questions]] : [[Behavioral Interview Questions|Behavioral Interview Questions]]
|
||||
- [[Belief-Revision]] : [[Belief-Revision|Belief-Revision]]
|
||||
- [[Big-Picture]] : [[Big-Picture|Big-Picture]]
|
||||
- [[Boundaries]] : [[Boundaries|Boundaries]]
|
||||
- [[Bureaucracy]] : [[Bureaucracy|Bureaucracy]]
|
||||
- [[Burnout]] : [[Burnout|Burnout]]
|
||||
- [[Chef Universe]] : [[Chef Universe|Chef Universe]]
|
||||
- [[Code Review Foundations (코드 리뷰 기초)]] : [[Code Review Foundations (코드 리뷰 기초)|Code Review Foundations (코드 리뷰 기초]]
|
||||
- [[Code Review Methodology & Cognitive Process]] : Code Review Methodology & Cognitive Process (코드 리뷰 방법론 및 인지 과정)
|
||||
- [[Codebase_Onboarding]] : Codebase Onboarding
|
||||
- [[Command Center]] : [[Command Center|Command Center]]
|
||||
- [[Complex Systems]] : [[Complex Systems|ComplexSystems]]
|
||||
- [[Composables]] : Composables
|
||||
- [[Concurrent Programming]] : [[Concurrent Programming|Concurrent Programming]]
|
||||
- [[Configuration-based_Routing]] : Configuration-based Routing
|
||||
- [[Continuous Obsolescence]] : [[Continuous Obsolescence|Continuous Obsolescence]]
|
||||
- [[Creativity Research]] : [[Creativity Research|Creativity Research]]
|
||||
- [[Cross-Platform_Development]] : Cross-Platform Development
|
||||
- [[Custom_Hooks]] : Custom Hooks
|
||||
- [[Effective Code Review Feedback]] : [[Effective Code Review Feedback|Effective Code Review Feedback]]
|
||||
- [[Enterprise-Service-Bus]] : [[Enterprise-Service-Bus|Enterprise-Service-Bus]]
|
||||
- [[Enzyme-Inhibition-Kinetics]] : [[Enzyme-Inhibition-Kinetics|Enzyme-Inhibition-Kinetics]]
|
||||
- [[Ethical-Decision-Making]] : [[Ethical-Decision-Making|Ethical-Decision-Making]]
|
||||
- [[Etiology-of-Disease]] : [[Etiology-of-Disease|Etiology-of-Disease]]
|
||||
- [[Expo_Router]] : Expo Router
|
||||
- [[Express]] : Express
|
||||
- [[Feedback-Loops]] : [[Feedback-Loops|Feedback-Loops]]
|
||||
- [[Fortnite]] : [[Fortnite|Fortnite]]
|
||||
- [[Function-as-a-Service_FaaS]] : Function-as-a-Service (FaaS)
|
||||
- [[G-Stack Principles]] : G-Stack [[Principles|Principles]] (G-Stack 엔지니어링 원칙)
|
||||
- [[Habit-Formation]] : Habit Formation (습관 형성의 심리학)
|
||||
- [[High-Performance-Coaching]] : [[High-Performance-Coaching|High-Performance-Coaching]]
|
||||
- [[High-Performance-Organizations]] : [[High-Performance-Organizations|High-Performance-Organizations]]
|
||||
- [[Higher-Order_Components_HOCs]] : Higher-Order Components (HOCs)
|
||||
- [[Horizontal Logic]] : [[Horizontal Logic|Horizontal Logic]]
|
||||
- [[Horizontal and Vertical Logic]] : [[Horizontal and Vertical Logic|Horizontal and Vertical Logic]]
|
||||
- [[Hypostatic-Abstraction]] : [[Hypostatic-Abstraction|Hypostatic-Abstraction]]
|
||||
- [[Image-Optimization-for-Web-Performance]] : Image Optimization for Web Performance (웹 성능을 위한 이미지 최적화)
|
||||
- [[Index]] : Index: Topics > Governance & Reliability
|
||||
- [[Inference-Coupled Persistence]] : Inference-Coupled Persistence (추론 결합 지속성)
|
||||
- [[Inheritance-and-Polymorphism]] : Inheritance and Polymorphism (상속과 다형성)
|
||||
- [[Interoperability]] : [[Interoperability|Interoperability]]
|
||||
- [[Item-Item-Collaborative-Filtering]] : Item-Item Collaborative Filtering (아이템 기반 협업 필터링)
|
||||
- [[Iteration]] : [[Iteration|Iteration]]
|
||||
- [[JAMstack]] : JAMstack
|
||||
- [[Joint-Optimization]] : [[Joint-Optimization|Joint-Optimization]]
|
||||
- [[Just-In-Time (JIT)]] : [[Just-In-Time (JIT)|Just-In-Time (JIT)]]
|
||||
- [[Knowledge synthesis]] : [[Knowledge synthesis|Knowledge synthesis]]
|
||||
- [[Lighting & Composition]] : Lighting & Composition
|
||||
- [[Logical Reasoning (Deductive-Inductive)]] : [[Logical Reasoning (Deductive-Inductive)|Logical Reasoning (Deductive-Inductive]]
|
||||
- [[Lucas-Kanade-Method]] : Lucas-Kanade Method (루카스-카나데 방법)
|
||||
- [[MECE + Pyramid Principle--]] : [[MECE|MECE]] + [[Pyramid Principle|Pyramid Principle]]
|
||||
- [[MMORPG 영속적 세계와 자원 관리]] : [[MMORPG 영속적 세계와 자원 관리|MMORPG 영속적 세계와 자원 관리]]
|
||||
- [[MapReduce]] : [[MapReduce|MapReduce]]
|
||||
- [[Memetics]] : [[Memetics|Memetics]]
|
||||
- [[Message_Queues]] : Message Queues
|
||||
- [[Middle-Out-Thinking]] : [[Middle-Out-Thinking|Middle-Out-Thinking]]
|
||||
- [[Minimal-Viable-Product]] : [[Minimal-Viable-Product|Minimal-Viable-Product]]
|
||||
- [[Mockito]] : Mockito
|
||||
- [[Multi-agent-System]] : [[Multi-agent-System|Multi-agent-System]]
|
||||
- [[NDF (Neutral Data Format)]] : NDF (Neutral Data Format)
|
||||
- [[Native_Apps]] : Native Apps
|
||||
- [[Neurobiology-of-Reward]] : [[Neurobiology-of-Reward|Neurobiology-of-Reward]]
|
||||
- [[Neuroergonomics]] : [[Neuroergonomics|Neuroergonomics]]
|
||||
- [[Neuromuscular-Control]] : [[Neuromuscular-Control|Neuromuscular-Control]]
|
||||
- [[Neuroplasticity in Addiction]] : [[Neuroplasticity in Addiction|Neuroplasticity in Addiction]]
|
||||
- [[Nexus Gaming Labs]] : Nexus Gaming Labs
|
||||
- [[No_Code_&_Low_Code_Development]] : No Code & Low Code Development
|
||||
- [[Nutritional-Biochemistry]] : [[Nutritional-Biochemistry|Nutritional-Biochemistry]]
|
||||
- [[ORM_Prisma,_TypeORM]] : ORM (Prisma, TypeORM)
|
||||
- [[OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)]] : [[OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)|OWA vs CWA (개방 세계 vs 폐쇄 세계 가설)]]
|
||||
- [[Objectivism]] : [[Objectivism|Objectivism]]
|
||||
- [[Open-Access-Movement]] : [[Open-Access-Movement|Open-Access-Movement]]
|
||||
- [[Outside-Thinking]] : [[Outside-Thinking|Outside-Thinking]]
|
||||
- [[Parallel-Computing]] : Parallel Computing (병렬 컴퓨팅)
|
||||
- [[Parallel-Processing]] : [[Parallel-Processing|Parallel-Processing]]
|
||||
- [[Pedestrian-Modeling]] : [[Pedestrian-Modeling|Pedestrian-Modeling]]
|
||||
- [[Perceptual-Motor-Skills]] : [[Perceptual-Motor-Skills|Perceptual-Motor-Skills]]
|
||||
- [[Performance Psychology]] : [[Performance Psychology|Performance Psychology]]
|
||||
- [[Pinia]] : Pinia
|
||||
- [[Play-and-Earn]] : [[Play-and-Earn|Play-and-Earn]]
|
||||
- [[Policy-Surveillance]] : [[Policy-Surveillance|Policy-Surveillance]]
|
||||
- [[Precision-Recursion]] : [[Precision-Recursion|Precision-Recursion]]
|
||||
- [[Principles-of-Structuralism]] : [[Principles-of-Structuralism|Principles-of-Structuralism]]
|
||||
- [[Problem Solving Process]] : [[Problem Solving Process|Problem Solving Process]]
|
||||
- [[Program Comprehension Strategies]] : Program Comprehension Strategies (프로그램 이해 전략)
|
||||
- [[Progressive_Web_Apps_PWAs]] : Progressive Web Apps (PWAs)
|
||||
- [[Protocols]] : [[Protocols|Protocols]]
|
||||
- [[Psychology & Behavior]] : [[Psychology & Behavior|Psychology & Behavior]]
|
||||
- [[Pull Request Best Practices (PR 베스트 프랙티스)]] : [[Pull Request Best Practices (PR 베스트 프랙티스)|Pull Request Best Practices (PR 베스트 프랙티스]]
|
||||
- [[Purpose]] : [[Purpose|Purpose]]
|
||||
- [[Pyramid Principle]] : [[Pyramid Principle|Pyramid Principle]]
|
||||
- [[Recording Academy (The Grammys)]] : [[Recording Academy (The Grammys)|Recording Academy ([[The Grammys]])]]
|
||||
- [[Related-Work]] : [[Related-Work|Related-Work]]
|
||||
- [[Research-Methodology]] : [[Research-Methodology|Research-Methodology]]
|
||||
- [[Resource Deposits(자원 매장지)]] : Resource Deposits(자원 매장지)
|
||||
- [[Riverpod]] : Riverpod
|
||||
- [[Roblox]] : [[Roblox|Roblox]]
|
||||
- [[Role of Conflict in Narrative]] : [[Role of Conflict in Narrative|Role of Conflict in Narrative]]
|
||||
- [[Rule of Three]] : [[Rule of Three|Rule of Three]]
|
||||
- [[SDLC & SSDLC (소프트웨어 개발 생명주기)]] : [[SDLC & SSDLC (소프트웨어 개발 생명주기)|SDLC & SSDLC (소프트웨어 개발 생명주기]]
|
||||
- [[SOTA]] : [[SOTA|SOTA]]
|
||||
- [[Search-Space]] : [[Search-Space|Search-Space]]
|
||||
- [[Search]] : [[Search|Search]]
|
||||
- [[Secondary-Research]] : [[Secondary-Research|Secondary-Research]]
|
||||
- [[Service_Workers]] : Service Workers
|
||||
- [[Sociology of Knowledge]] : [[Sociology of Knowledge|Sociology of Knowledge]]
|
||||
- [[Soft-Skills-Development]] : [[Soft-Skills-Development|Soft-Skills-Development]]
|
||||
- [[Speculative-Design]] : [[Speculative-Design|Speculative-Design]]
|
||||
- [[Spring_Boot]] : Spring Boot
|
||||
- [[State]] : [[State|State]]
|
||||
- [[Statistical-Analysis]] : [[Statistical-Analysis|Statistical-Analysis]]
|
||||
- [[Structural Reasoning]] : [[Structural Reasoning|Structural Reasoning]]
|
||||
- [[Supercell의 모바일 게임 개발]] : [[Supercell의 모바일 게임 개발|Supercell의 모바일 게임 개발]]
|
||||
- [[Team Culture & Onboarding (팀 문화 및 온보딩)]] : [[Team Culture & Onboarding (팀 문화 및 온보딩)|Team Culture & Onboarding (팀 문화 및 온보딩]]
|
||||
- [[UML_상태_다이어그램_Statechart_Diagram]] : UML 상태 다이어그램 (Statechart Diagram)
|
||||
- [[Understanding Complex Systems]] : Understanding Complexsystems
|
||||
- [[Universal_Apps]] : Universal Apps
|
||||
- [[Victimhood-Narratives]] : [[Victimhood-Narratives|Victimhood-Narratives]]
|
||||
- [[VueUse]] : VueUse
|
||||
- [[WARNO 모딩(Modding)]] : WARNO 모딩(Modding)
|
||||
- [[WARNO-DATA Wiki]] : WARNO-DATA Wiki
|
||||
- [[WoW 토큰 및 PLEX]] : WoW 토큰 및 PLEX
|
||||
- [[Working-Backwards]] : [[Working-Backwards|Working-Backwards]]
|
||||
- [[decisions]] : 📌 회사 의사결정 로그
|
||||
- [[가상 경제 시스템(Virtual Economy System)]] : [[가상 경제 시스템(Virtual Economy System)|가상 경제 시스템(Virtual Economy System)]]
|
||||
- [[가상 경제 시스템]] : [[가상 경제 시스템|가상 경제 시스템]]
|
||||
- [[가상 경제 시스템의 구조적 무결성 분석]] : 가상 경제 시스템의 구조적 무결성 분석
|
||||
- [[가상 경제 인플레이션(Virtual Economy Inflation)]] : 가상 경제 인플레이션(Virtual Economy Inflation)
|
||||
- [[가상 경제 인플레이션]] : 가상 경제 인플레이션
|
||||
- [[가상 경제(Virtual Economy)]] : [[가상 경제(Virtual Economy)|가상 경제(Virtual Economy)]]
|
||||
- [[가상 화폐 (Virtual Currency)]] : [[가상 화폐 (Virtual Currency)|가상 화폐 (Virtual Currency)]]
|
||||
- [[결제 사용자당 평균 매출(ARPPU)]] : [[결제 사용자당 평균 매출(ARPPU)|결제 사용자당 평균 매출(ARPPU]]
|
||||
- [[경제 밸런싱(Economic Balancing)]] : [[경제 밸런싱(Economic Balancing)|경제 밸런싱(Economic Balancing)]]
|
||||
- [[관리자 상점(Admin Shop)]] : [[관리자 상점(Admin Shop)|관리자 상점(Admin Shop]]
|
||||
- [[기간 한정 제안(Limited-time offers)]] : [[기간 한정 제안(Limited-time offers)|기간 한정 제안(Limited-time offers]]
|
||||
- [[다중 통화 시스템(Multi-Currency System)]] : [[다중 통화 시스템(Multi-Currency System)|다중 통화 시스템(Multi-Currency System)]]
|
||||
- [[데이터 기반 밸런싱]] : 데이터 기반 밸런싱
|
||||
- [[데이터 기반 설계]] : 데이터 기반 설계
|
||||
- [[동적_분석_Dynamic_Analysis]] : 동적 분석 (Dynamic Analysis)
|
||||
- [[동적_코드_분석_Dynamic_Code_Analysis]] : 동적 코드 분석 (Dynamic Code Analysis)
|
||||
- [[디버거_Debugger]] : 디버거 (Debugger)
|
||||
- [[리그 오브 레전드(League of Legends)]] : 리그 오브 레전드(League of Legends)
|
||||
- [[리더보드(Leaderboards)]] : [[리더보드(Leaderboards)|리더보드(Leaderboards]]
|
||||
- [[리팩터링의_핵심_원칙인_'두_개의_모자'_메타포는_무엇인가요-]] : 리팩터링의 핵심 원칙인 '두 개의 모자' 메타포는 무엇인가요-
|
||||
- [[리팩토링_원칙]] : 리팩토링 원칙
|
||||
- [[메타 레이어 (Meta Layers)]] : [[메타 레이어 (Meta Layers)|메타 레이어 (Meta Layers]]
|
||||
- [[모딩 생태계]] : 모딩 생태계
|
||||
- [[모바일 게임 수익화 모델]] : 모바일 게임 수익화 모델
|
||||
- [[모바일 퍼스트 인덱싱(Mobile-First Indexing)]] : [[모바일 퍼스트 인덱싱(Mobile-First Indexing)|모바일 퍼스트 인덱싱(Mobile-First Indexing]]
|
||||
- [[몬테카를로 시뮬레이션]] : [[몬테카를로 시뮬레이션|몬테카를로 시뮬레이션]]
|
||||
- [[반복적_리뷰Iterative_Review]] : 반복적 리뷰(Iterative Review)
|
||||
- [[방어 플랫폼(Defense Platforms)]] : [[방어 플랫폼(Defense Platforms)|방어 플랫폼(Defense Platforms)]]
|
||||
- [[부대 편성(Platoon Formations)]] : [[부대 편성(Platoon Formations)|부대 편성(Platoon Formations)]]
|
||||
- [[부분 유료화(Freemium) 게임 경제 모델링]] : 부분 유료화(Freemium) 게임 경제 모델링
|
||||
- [[소음 역학 (Noise Dynamics)]] : 소음 역학 (Noise Dynamics)
|
||||
- [[소프트 싱크(Soft Sinks)]] : [[소프트 싱크(Soft Sinks)|소프트 싱크(Soft Sinks)]]
|
||||
- [[수도꼭지(Faucets)]] : [[수도꼭지(Faucets)|수도꼭지(Faucets)]]
|
||||
- [[수도꼭지와 배수구(Faucets and Sinks)]] : 수도꼭지와 배수구(Faucets and Sinks)
|
||||
- [[수요와 공급(Supply and Demand)]] : [[수요와 공급(Supply and Demand)|수요와 공급(Supply and Demand]]
|
||||
- [[스테이블 디퓨전 아티팩트 디버깅(Artifact Debugging)]] : [[스테이블 디퓨전 아티팩트 디버깅(Artifact Debugging)|스테이블 디퓨전 아티팩트 디버깅(Artifact Debugging)]]
|
||||
- [[실시간 전략 및 부분유료화(F2P) 밸런싱 맥락]] : 실시간 전략 및 부분유료화(F2P) 밸런싱 맥락
|
||||
- [[아크 2 테크놀로지 및 유닛(Arc 2 Technology and Units)]] : [[아크 2 테크놀로지 및 유닛(Arc 2 Technology and Units)|아크 2 테크놀로지 및 유닛(Arc 2 Technology and Units)]]
|
||||
- [[아키텍처_드리프트_Architectural_Drift]] : 아키텍처 드리프트 (Architectural Drift)
|
||||
- [[악명(Infamy) 시스템]] : [[악명(Infamy) 시스템|악명(Infamy) 시스템]]
|
||||
- [[연속 승리 이벤트(Streak events)]] : [[연속 승리 이벤트(Streak events)|연속 승리 이벤트(Streak Events]]
|
||||
- [[오디오 광고]] : [[오디오 광고|오디오 광고]]
|
||||
- [[위험과 보상 구조(Structures of Risks and Rewards)]] : 위험과 보상 구조(Structures of Risks and Rewards)
|
||||
- [[위험과 보상(Risks and Rewards)]] : [[위험과 보상(Risks and Rewards)|위험과 보상(Risks and Rewards]]
|
||||
- [[유니버스 LTV(Universe LTV)]] : [[유니버스 LTV(Universe LTV)|유니버스 LTV(Universe LTV]]
|
||||
- [[유저 평균 매출(ARPU)]] : [[유저 평균 매출(ARPU)|유저 평균 매출(ARPU]]
|
||||
- [[은신과 시야 매커니즘 (Stealth and Optics)]] : 은신과 시야 매커니즘 (Stealth and Optics)
|
||||
- [[의도_및_목적_지향적_설명_Purpose-driven_Explanation]] : 의도 및 목적 지향적 설명 (Purpose-driven Explanation)
|
||||
- [[이리듐 및 토륨 경제(Iridium and Thorium Economy)]] : [[이리듐 및 토륨 경제(Iridium and Thorium Economy)|이리듐 및 토륨 경제(Iridium and Thorium Economy)]]
|
||||
- [[이탈률(Churn Rate)]] : [[이탈률(Churn Rate)|이탈률(Churn Rate]]
|
||||
- [[인플레이션(Inflation)]] : [[인플레이션(Inflation)|인플레이션(Inflation]]
|
||||
- [[자원 로지스틱스(Resource Logistics)]] : [[자원 로지스틱스(Resource Logistics)|자원 로지스틱스(Resource Logistics]]
|
||||
- [[자원 보관 및 압축(Resource Storage & Compression)]] : [[자원 보관 및 압축(Resource Storage & Compression)|자원 보관 및 압축(Resource Storage & Compression]]
|
||||
- [[장갑 관통 모델링(Armor Penetration Modeling)]] : 장갑 관통 모델링(Armor Penetration Modeling)
|
||||
- [[장갑 및 사거리 데이터 (Armor and Range Stats)]] : 장갑 및 사거리 데이터 (Armor and Range Stats)
|
||||
- [[코드_스멜_및_리팩토링_Code_Smells_and_Refactoring]] : 코드 스멜 및 리팩토링 (Code Smells and Refactoring)
|
||||
- [[코드베이스_맵과_대화형_투어_Codebase_Maps_&_Interactive_Tours]] : 코드베이스 맵과 대화형 투어 (Codebase Maps & Interactive Tours)
|
||||
- [[콘텐츠 로테이션(Content Rotation)]] : [[콘텐츠 로테이션(Content Rotation)|콘텐츠 로테이션(Content Rotation]]
|
||||
- [[크로스 플랫폼(Cross-Platform) 아키텍처]] : [[크로스 플랫폼(Cross-Platform) 아키텍처|크로스 플랫폼(Cross-Platform) 아키텍처]]
|
||||
- [[크리에이터 이코노미(Creator Economy)]] : 크리에이터 이코노미(Creator Economy)
|
||||
- [[클래시 로얄 라틴 아메리카 챔피언십]] : [[클래시 로얄 라틴 아메리카 챔피언십|클래시 로얄 라틴 아메리카 챔피언십]]
|
||||
- [[클래시 로얄 모바일 게임 프로덕션]] : 클래시 로얄 모바일 게임 프로덕션
|
||||
- [[테스트_자동화_및_테스트_주도_개발_Test_Automation_&_TDD]] : 테스트 자동화 및 테스트 주도 개발 (Test Automation & TDD)
|
||||
- [[텔레메트리 데이터 (Telemetry Data)]] : 텔레메트리 데이터 (Telemetry Data)
|
||||
- [[토륨 경제(Thorium Economy)]] : [[토륨 경제(Thorium Economy)|토륨 경제(Thorium Economy)]]
|
||||
- [[통제된 인플레이션(Controlled Inflation)]] : [[통제된 인플레이션(Controlled Inflation)|통제된 인플레이션(Controlled Inflation]]
|
||||
- [[포트나이트(Fortnite) 및 로블록스(Roblox)의 UGC 창작자 경제]] : 포트나이트([[Fortnite|Fortnite]]) 및 로블록스([[Roblox|Roblox]])의 UGC 창작자 경제
|
||||
- [[풀_리퀘스트_및_이슈_트래커_PR_&_Issue_Tracker]] : 풀 리퀘스트 및 이슈 트래커 (PR & Issue Tracker)
|
||||
- [[풀_리퀘스트_및_이슈_트래킹_Pull_Requests_&_Issue_Tracking]] : 풀 리퀘스트 및 이슈 트래킹 (Pull Requests & Issue Tracking)
|
||||
- [[프롬프트 구조 및 문법]] : [[프롬프트 구조 및 문법|프롬프트 구조 및 문법]]
|
||||
- [[프리미엄 통화 브릿지(Premium Currency Bridge)]] : [[프리미엄 통화 브릿지(Premium Currency Bridge)|프리미엄 통화 브릿지(Premium Currency Bridge]]
|
||||
- [[핀치 포인트(Pinch Point)]] : [[핀치 포인트(Pinch Point)|핀치 포인트(Pinch Point]]
|
||||
- [[하드 싱크(Hard Sinks)]] : 하드 싱크(Hard Sinks)
|
||||
- [[하이브리드 수익화 모델]] : [[하이브리드 수익화 모델|하이브리드 수익화 모델]]
|
||||
- [[핵심 루프(Core Loop)]] : [[핵심 루프(Core Loop)|핵심 루프(Core Loop)]]
|
||||
- [[행동 경제학]] : 행동 경제학
|
||||
- [[행동경제학]] : [[행동경제학|행동경제학]]
|
||||
## 매 핵심
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
### 매 purpose
|
||||
- 매 new note 의 category 의 still 의 settle 의 not 의 temp home.
|
||||
- 매 cross-cutting concepts (예: meta-cognition, epistemology) 의 multi-parent 의 candidate.
|
||||
- 매 review queue — 매 promote / merge / redirect 의 weekly.
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
### 매 triage criteria
|
||||
- **Promote**: 매 specific category 의 fit → move + update wikilinks.
|
||||
- **Merge**: 매 existing canonical 의 duplicate → REDIRECT + canonical 의 absorb.
|
||||
- **Stay**: 매 genuinely cross-domain (philosophy, methods).
|
||||
- **Archive**: 매 stale / orphan / no inbound link → 01_Archive 로.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 매 응용
|
||||
1. 매 weekly cleanup batch (이 doc 의 example).
|
||||
2. 매 quarterly taxonomy review.
|
||||
3. 매 LLM-assisted re-categorization (embedding clustering).
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(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
|
||||
### Dataview — 매 stale "Other" notes 의 list
|
||||
```dataview
|
||||
TABLE file.mtime AS modified, length(file.inlinks) AS in
|
||||
FROM "10_Wiki/Topics/Other"
|
||||
WHERE file.mtime < date(today) - dur(60 days)
|
||||
SORT in ASC, file.mtime ASC
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Embedding-based re-categorization
|
||||
```python
|
||||
from sentence_transformers import SentenceTransformer
|
||||
from sklearn.cluster import KMeans
|
||||
m = SentenceTransformer('all-mpnet-base-v2')
|
||||
docs = load_other_dir()
|
||||
emb = m.encode([d.body for d in docs])
|
||||
labels = KMeans(n_clusters=12, n_init=10).fit_predict(emb)
|
||||
for d, l in zip(docs, labels):
|
||||
print(d.title, '->', cluster_to_category[l])
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Inbound-link census
|
||||
```bash
|
||||
rg -o '\[\[([^\]]+)\]\]' -r '$1' 10_Wiki/Topics --no-filename | sort | uniq -c | sort -rn
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Promote script (move + rewrite links)
|
||||
```python
|
||||
import os, re
|
||||
from pathlib import Path
|
||||
def promote(slug, src_dir, dst_dir, vault_root):
|
||||
src = Path(src_dir) / f"{slug}.md"
|
||||
dst = Path(dst_dir) / f"{slug}.md"
|
||||
src.rename(dst)
|
||||
# links remain valid since Obsidian uses basename-resolution by default
|
||||
return dst
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Frontmatter audit (verification_status missing)
|
||||
```python
|
||||
import re, glob
|
||||
for fp in glob.glob('10_Wiki/Topics/Other/*.md'):
|
||||
with open(fp) as f: head = f.read(2000)
|
||||
if 'verification_status:' not in head:
|
||||
print('MISSING:', fp)
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Redirect generator
|
||||
```python
|
||||
def make_redirect(slug, canonical_title):
|
||||
return f"""---
|
||||
id: wiki-2026-0508-{slug}
|
||||
title: {slug.replace('-',' ').title()}
|
||||
status: duplicate
|
||||
duplicate_of: \"[[{canonical_title}]]\"
|
||||
verification_status: redirected
|
||||
---
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
> 이 문서는 [[{canonical_title}]] 의 중복본입니다.
|
||||
"""
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 신호 | Action |
|
||||
|---|---|
|
||||
| 명확한 specific category | Promote |
|
||||
| Canonical 이 already 있음 | Merge / REDIRECT |
|
||||
| 60일+ 무수정 + 0 inbound | Archive |
|
||||
| 진짜 cross-domain | Stay (with multi-parent links) |
|
||||
|
||||
**기본값**: Triage weekly — 매 "Other" 의 size 의 monotone 의 increase 의 prevent.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[10_Wiki Topics Index]]
|
||||
- 변형: (catch-all)
|
||||
- 응용: [[Wiki-Cleanup-Workflow]]
|
||||
- Adjacent: [[CLEANUP_SPEC]] · [[Knowledge-Management]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 batch triage, 매 cluster labeling, 매 redirect drafting.
|
||||
**언제 X**: 매 final taxonomy commit — 매 human review 의 require.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Set-and-forget**: 매 "Other" 의 graveyard 의 become.
|
||||
- **Hard-link by full path**: 매 promote 시 의 break. 매 wikilink 의 use.
|
||||
- **No archival policy**: 매 entropy 의 unbounded.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (vault internal taxonomy spec).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — triage workflow + scripts |
|
||||
|
||||
@@ -2,65 +2,147 @@
|
||||
id: wiki-2026-0508-outside-thinking
|
||||
title: Outside Thinking
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-OUTH-001]
|
||||
aliases: [Outside View, Reference Class Forecasting, Outsider Perspective]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, outside-thinking, Innovation, unconventional, lateral-thinking, Problem-Solving]
|
||||
verification_status: applied
|
||||
tags: [decision-making, cognition, forecasting, biases]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: theory
|
||||
framework: behavioral-decision-theory
|
||||
---
|
||||
|
||||
# [[Outside-Thinking|Outside-Thinking]]
|
||||
# Outside Thinking
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "상자 밖의 시선: 문제를 내부의 관습이나 과거의 성공 문법으로 풀려 하지 않고, 전혀 다른 도메인에서 온 낯선 아이디어를 끌어오거나 전제 자체를 부정함으로써 기존의 한계를 완전히 파괴하고 근본적인 도약을 만들어내는 외부자적 통찰."
|
||||
## 매 한 줄
|
||||
> **"매 your project is not special — base rates always win."**. 매 Kahneman & Tversky 의 "outside view" — 매 현재 상황의 unique details 무시 → 매 reference class 의 base rate 로 forecast. 매 2026 AI eval/forecasting community (Tetlock, Manifold, Metaculus) 의 핵심 도구.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
아웃사이드 씽킹(Outside-Thinking) 혹은 '상자 밖 사고'는 관습적인 프레임워크를 벗어난 사고 방식입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **실행 기법**:
|
||||
* **First [[Principles|Principles]] [[Reasoning|Reasoning]]**: 기존 전문가들의 '상식'을 무시하고 물리적 기초부터 새로 구상. (Reasoning와 연결)
|
||||
* **Cross-Pollination (교차 수정)**: 금융 문제를 물리 법칙으로 풀거나, 생태계 원리를 경영에 도입. ([[Interdisciplinary-Research|Interdisciplinary-Research]]와 연결)
|
||||
* **Assumption Challenging**: "만약 A라는 제약이 없다면?"이라는 질문을 던짐.
|
||||
2. **왜 중요한가?**:
|
||||
* 전문성은 깊어질수록 특정 모델에 갇히는 경향(Expert Blindness)이 있는데, 외부자적 시각은 이 고착된 상태를 깨뜨리는 유일한 망치이기 때문임. (Innovation의 근원)
|
||||
### 매 inside vs outside
|
||||
- **Inside view**: 매 plan 의 details 로부터 outcome 추정 ("우리는 매 6주 만에 끝낼 수 있어").
|
||||
- **Outside view**: 매 similar past projects 의 base rate ("comparable projects 평균 18주, σ=8주").
|
||||
- **Result**: 매 outside view 가 거의 항상 더 정확 — 매 planning fallacy 회피.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 창의적인 괴짜들의 일탈적 정책으로 보았으나, 현대 정책은 불확실성과 파괴적 혁신 시대 정책 속에서 기업이 반드시 갖춰야 할 '전략적 창의성 정책'으로 내재화됨(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 모델에게 "너는 이제 22세기에서 온 최고의 과학자야"라는 페르소나 정책을 부여함으로써 모델 내부의 관습적 답변 정책(Head bias)을 깨고 창의적인 해법 정책을 유도하는 기법이 유행함.
|
||||
### 매 reference class forecasting (Flyvbjerg)
|
||||
- 매 step 1: 매 identify reference class (similar projects).
|
||||
- 매 step 2: 매 collect distribution of outcomes (cost, time, success rate).
|
||||
- 매 step 3: 매 your project = sample from that distribution.
|
||||
- 매 step 4: 매 adjust only with strong evidence.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Innovation|Innovation]], [[Interdisciplinary-Research|Interdisciplinary-Research]], [[Reasoning|Reasoning]], [[Inversion|Inversion]], [[Knowledge synthesis|Knowledge synthesis]]
|
||||
- **Modern Tech/Tools**: Oblique Strategies, TRIZ, Design Thinking, Role-play prompting.
|
||||
---
|
||||
### 매 응용
|
||||
1. Software estimation: 매 "this PR will take 1 day" → 매 historical median = 4 days.
|
||||
2. Startup success: 매 "we'll be the exception" → 매 base rate ~10% survive 5y.
|
||||
3. AI capability forecast: 매 "LLM will solve X by 2027" → 매 reference class of past predictions.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Reference class forecaster
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def outside_forecast(reference_class_outcomes: list[float],
|
||||
inside_estimate: float,
|
||||
trust_in_inside: float = 0.2):
|
||||
"""매 Bayesian blend — 매 prior is base rate."""
|
||||
base_rate_mean = np.mean(reference_class_outcomes)
|
||||
base_rate_std = np.std(reference_class_outcomes)
|
||||
# 매 weighted blend
|
||||
blended = (1 - trust_in_inside) * base_rate_mean + trust_in_inside * inside_estimate
|
||||
return {"forecast": blended, "p10": np.percentile(reference_class_outcomes, 10),
|
||||
"p90": np.percentile(reference_class_outcomes, 90)}
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 2: Estimation poker with history
|
||||
```python
|
||||
def estimate(task, similar_tasks_db):
|
||||
similar = find_similar(task, similar_tasks_db, k=10)
|
||||
durations = [t.actual_duration for t in similar]
|
||||
return {
|
||||
"p50": np.median(durations),
|
||||
"p90": np.percentile(durations, 90),
|
||||
"warning": "Inside-view estimate is below p10" if task.guess < np.percentile(durations, 10) else None,
|
||||
}
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 3: Pre-mortem — outside view of failure modes
|
||||
```python
|
||||
def pre_mortem(project, similar_failed_projects):
|
||||
"""매 imagine project failed; 매 list reasons from history."""
|
||||
failure_modes = []
|
||||
for fp in similar_failed_projects:
|
||||
failure_modes.extend(fp.post_mortem_causes)
|
||||
return Counter(failure_modes).most_common(10)
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 4: Prediction market calibration
|
||||
```python
|
||||
# 매 force outside view via market — 매 your private estimate vs market price
|
||||
def confidence_check(my_p, market_p):
|
||||
if abs(my_p - market_p) > 0.20:
|
||||
return "RED FLAG: large divergence from outside view"
|
||||
return "OK"
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 5: Survivorship bias correction
|
||||
```python
|
||||
def correct_for_survivorship(success_stories, full_population):
|
||||
survivor_rate = len(success_stories) / len(full_population)
|
||||
return {
|
||||
"naive_lesson": "Do what successes did",
|
||||
"corrected": f"Only {survivor_rate:.0%} survive — failures often did same things",
|
||||
}
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 6: LLM as outside view oracle
|
||||
```python
|
||||
PROMPT = """For the following plan, list:
|
||||
1. The reference class (similar past projects)
|
||||
2. Base rate of success
|
||||
3. Typical failure modes
|
||||
4. Why this project might/might-not be representative
|
||||
"""
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 estimating new project | Outside view first, inside view as adjustment |
|
||||
| 매 confident in unique advantage | Outside view with small inside-view weight |
|
||||
| 매 forecasting AI capabilities | Reference class of past predictions |
|
||||
| 매 startup go/no-go | Compare to founder cohort base rates |
|
||||
| 매 research timeline | Reference class of similar papers/benchmarks |
|
||||
|
||||
**기본값**: 매 outside view first, inside view as 매 small adjustment (≤20% weight).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Decision Theory]] · [[Behavioral Economics]]
|
||||
- 변형: [[Reference Class Forecasting]] · [[Bayesian Reasoning]]
|
||||
- 응용: [[Project Estimation]] · [[Forecasting]] · [[Pre-Mortem]]
|
||||
- Adjacent: [[Planning Fallacy]] · [[Survivorship Bias]] · [[Base Rate Neglect]] · [[Tetlock Superforecasters]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 estimation, 매 forecasting, 매 strategic planning, 매 evaluating "we're different" claims.
|
||||
**언제 X**: 매 truly novel domains where no reference class exists (rare — usually a class can be found).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **"Our project is unique"**: 매 99% of the time, not unique enough to escape base rates.
|
||||
- **Cherry-picked reference class**: 매 selecting only successes — 매 survivorship bias.
|
||||
- **Ignoring distribution**: 매 only using mean — 매 use p10/p90.
|
||||
- **No update mechanism**: 매 collecting new data but not updating reference class.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Kahneman 2011, Flyvbjerg 2006, Tetlock 2015).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — outside vs inside view, reference class forecasting |
|
||||
|
||||
@@ -2,88 +2,165 @@
|
||||
id: wiki-2026-0508-parallel-computing
|
||||
title: Parallel Computing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [PARALLEL-001]
|
||||
aliases: [Parallel Processing, Concurrent Computing, HPC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 1.0
|
||||
tags: [computer-science, high-performance-computing, gpu, Distributed-Systems]
|
||||
confidence_score: 0.95
|
||||
verification_status: applied
|
||||
tags: [hpc, parallelism, gpu, distributed]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-26
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python-cuda
|
||||
framework: jax-pytorch-mpi
|
||||
---
|
||||
|
||||
# Parallel Computing (병렬 컴퓨팅)
|
||||
# Parallel Computing
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "동시에 여러 일을 처리하여 시간의 장벽을 넘어서라" — 하나의 커다란 문제를 여러 개의 작은 문제로 나누어 여러 프로세서가 동시에 계산하게 함으로써 연산 속도를 비약적으로 향상시키는 기법.
|
||||
## 매 한 줄
|
||||
> **"매 multiple computations 매 simultaneously 실행"**. 매 Flynn taxonomy (SISD/SIMD/MIMD) 부터 매 modern GPU SIMT, 매 distributed cluster (MPI, NCCL), 매 Llama 3.x 405B 의 4D parallelism (DP/TP/PP/SP) 까지. 매 2026 의 default workload 매 inference / training 의 parallel 이 매 single-core sequential 압도.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 연산 독립성이 있는 작업들을 식별하여 물리적으로 분리된 여러 연산 장치(CPU 코어, GPU)에 할당하고 동시에 실행하는 처리 패턴.
|
||||
- **세부 내용:**
|
||||
- **Data Parallelism:** 데이터를 쪼개어 여러 프로세서가 동일한 연산을 수행 (예: 행렬 곱셈).
|
||||
- **Task Parallelism:** 서로 다른 작업을 여러 프로세서가 나누어 수행.
|
||||
- **Shared vs Distributed [[memory|memory]]:** 연산 장치들이 메모리를 공유하는지, 각자 독립된 메모리를 사용하는지에 따른 통신 방식 차이.
|
||||
- **GPU Computing:** 수천 개의 코어를 활용하여 딥러닝과 같은 대규모 병렬 연산에 특화된 환경 제공.
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 단일 코어 클럭 성능 향상에 의존하던 시대를 지나, 멀티 코어와 이기종 컴퓨팅(Heterogeneous Computing)이 표준이 된 시대로 전환.
|
||||
- **정책 변화:** Antigravity 프로젝트의 대규모 위키 인덱싱 작업 시, 병렬 컴퓨팅 기법을 적용하여 수천 개의 문서를 수 분 내에 처리함.
|
||||
### 매 Flynn's taxonomy
|
||||
- **SISD**: 매 single instruction, single data — 매 classic CPU.
|
||||
- **SIMD**: 매 single instruction, multiple data — 매 AVX-512, GPU warp.
|
||||
- **MIMD**: 매 multiple instruction, multiple data — 매 multi-core CPU, cluster.
|
||||
- **SIMT**: 매 single instruction, multiple thread — 매 NVIDIA / AMD GPU.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Distributed-Computing|Distributed-Computing]], [[Linear-Algebra-for-ML|Linear-Algebra-for-ML]], [[GPU-Architecture|GPU-Architecture]], Amdahls-Law
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Parallel-Computing.md
|
||||
### 매 parallelism dimensions (modern DL)
|
||||
- **Data parallel (DP)**: 매 same model, 매 different batches.
|
||||
- **Tensor parallel (TP)**: 매 single tensor 매 split across devices.
|
||||
- **Pipeline parallel (PP)**: 매 layers 매 stages 로 split.
|
||||
- **Sequence parallel (SP)**: 매 sequence dim split (long context).
|
||||
- **Expert parallel (EP)**: 매 MoE 매 experts 매 across devices.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. **LLM training**: Llama 3.x 405B = DP×TP×PP×SP×EP combination.
|
||||
2. **Inference**: vLLM 매 continuous batching + tensor parallel.
|
||||
3. **Scientific compute**: weather, molecular dynamics (MPI).
|
||||
4. **Rendering**: Pixar RenderMan 매 distributed.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### NumPy → JAX SIMD vectorization
|
||||
```python
|
||||
# 매 implicit SIMD on CPU/GPU/TPU
|
||||
import jax
|
||||
import jax.numpy as jnp
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
@jax.jit
|
||||
def matmul_vectorized(A, B):
|
||||
return jnp.einsum("bij,bjk->bik", A, B)
|
||||
|
||||
- **정보 상태:** 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
|
||||
# vmap: auto-vectorize over batch dim
|
||||
batched = jax.vmap(lambda x, y: x @ y)(A, B)
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### CUDA kernel (SIMT)
|
||||
```cpp
|
||||
// 매 explicit thread-level parallelism
|
||||
__global__ void vec_add(float* a, float* b, float* c, int n) {
|
||||
int idx = blockIdx.x * blockDim.x + threadIdx.x;
|
||||
if (idx < n) c[idx] = a[idx] + b[idx];
|
||||
}
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
// launch: vec_add<<<(n+255)/256, 256>>>(a, b, c, n);
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Multi-GPU data parallel (PyTorch)
|
||||
```python
|
||||
import torch
|
||||
import torch.distributed as dist
|
||||
from torch.nn.parallel import DistributedDataParallel as DDP
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
dist.init_process_group(backend="nccl")
|
||||
model = DDP(model.cuda(), device_ids=[local_rank])
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
for batch in loader:
|
||||
loss = model(batch).loss
|
||||
loss.backward() # 매 NCCL all-reduce gradients
|
||||
optim.step()
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Tensor parallel (megatron-style)
|
||||
```python
|
||||
# 매 single Linear split column-wise across N GPUs
|
||||
class ColumnParallelLinear(nn.Module):
|
||||
def __init__(self, d_in, d_out, world_size):
|
||||
super().__init__()
|
||||
self.weight = nn.Parameter(torch.empty(d_out // world_size, d_in))
|
||||
def forward(self, x):
|
||||
local_out = x @ self.weight.T
|
||||
# gather across tp group
|
||||
return all_gather(local_out, dim=-1)
|
||||
```
|
||||
|
||||
### MPI scientific compute
|
||||
```python
|
||||
from mpi4py import MPI
|
||||
comm = MPI.COMM_WORLD
|
||||
rank, size = comm.Get_rank(), comm.Get_size()
|
||||
|
||||
# 매 domain decomposition
|
||||
local_data = scatter_grid(global_grid, rank, size)
|
||||
local_result = compute_step(local_data)
|
||||
global_result = comm.allreduce(local_result, op=MPI.SUM)
|
||||
```
|
||||
|
||||
### Async pipeline parallel
|
||||
```python
|
||||
# GPipe / 1F1B schedule
|
||||
def pipeline_step(stages, micro_batches):
|
||||
"""1F1B: 1 forward, 1 backward interleaved."""
|
||||
fwd_queue = []
|
||||
for mb in micro_batches:
|
||||
for s, stage in enumerate(stages):
|
||||
mb = stage.forward(mb)
|
||||
fwd_queue.append((s, mb))
|
||||
for s, mb in reversed(fwd_queue):
|
||||
stages[s].backward(mb)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| Workload | Parallelism |
|
||||
|---|---|
|
||||
| 매 single-machine CPU bound | multiprocessing / Ray |
|
||||
| 매 single-GPU dense ops | CUDA / JAX SIMT |
|
||||
| 매 multi-GPU same-node | NCCL DDP / FSDP |
|
||||
| 매 multi-node training | DP×TP×PP (Megatron, DeepSpeed) |
|
||||
| 매 long-context (128K+) | + Sequence Parallel |
|
||||
| 매 MoE model | + Expert Parallel |
|
||||
| 매 scientific HPC | MPI + domain decomposition |
|
||||
|
||||
**기본값**: 매 SIMD (numpy/jax) 시작 → 매 GPU SIMT → 매 multi-GPU DDP → 매 4D parallelism 의 progression.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Computer-Architecture]] · [[Distributed-Systems]]
|
||||
- 변형: [[GPU-Computing]] · [[Distributed-Training]]
|
||||
- 응용: [[LLM-Training]] · [[Scientific-Computing]] · [[vLLM]]
|
||||
- Adjacent: [[Concurrency]] · [[Parallel-Processing]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 parallelism strategy selection, 매 communication overhead analysis, 매 NCCL/MPI debugging.
|
||||
**언제 X**: 매 sequential algorithm 매 inherently — 매 Amdahl bound 의 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Premature parallelization**: 매 sequential profile X → blind parallelize.
|
||||
- **Communication-bound**: 매 too fine-grained 매 chunks → 매 NCCL overhead 압도.
|
||||
- **Load imbalance**: 매 uneven shard sizes → 매 stragglers.
|
||||
- **Race conditions**: 매 shared state w/o sync.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Hennessy & Patterson 6e; Megatron-LM paper 2019; Llama 3 paper 2024; CUDA C++ Programming Guide 12.x).
|
||||
- 신뢰도 A.
|
||||
- 매 [[Parallel-Processing]] 매 alias / redirect.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Flynn + 4D DL parallelism + modern stack |
|
||||
|
||||
@@ -2,92 +2,32 @@
|
||||
id: wiki-2026-0508-parallel-processing
|
||||
title: Parallel Processing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PAPR-001]
|
||||
duplicate_of: none
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-parallel-computing
|
||||
duplicate_of: "[[Parallel-Computing]]"
|
||||
aliases: []
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, parallel-Processing, multi-threading, concurrency, Efficiency, Operation]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, parallelism, hpc]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Parallel-Processing|Parallel-Processing]]
|
||||
# Parallel Processing
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "멀티태스킹의 정석: 순서대로 기다리는 줄 세우기 방식(Sequential)을 버리고, 독립적인 작업들을 동시에 진행시켜 작업 완료까지의 절대적 시간을 혁명적으로 줄이는 '생산성 가속 페달'."
|
||||
> **이 문서는 [[Parallel-Computing]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
병렬 처리(Parallel-Processing)는 컴퓨터에서 두 개 이상의 중앙 처리 장치가 동일한 프로그램을 처리하는 방식 혹은 작업 수행의 동시성을 의미합니다.
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- "Parallel processing" 매 흔히 매 application-level / OS-level concurrency 의 의미로 사용.
|
||||
- "Parallel computing" 매 broader — 매 hardware (SIMD/SIMT) + software 모두 포함.
|
||||
- 매 실용 차이 X — 매 same canonical concept.
|
||||
|
||||
1. **소프트웨어적 관점**:
|
||||
* **Multi-threading**: 하나의 프로그램 안에서 여러 줄기(Thread)의 작업을 동시에 수행.
|
||||
* **Asynchronous (비동기)**: 작업 결과가 올 때까지 기다리지 않고 다른 일을 먼저 함. (Efficiency와 연결)
|
||||
2. **시스템적 관점**:
|
||||
* **Pipeline**: 자동차 조립 라인처럼 단계별로 작업을 물려 동시 가동률 극대화.
|
||||
3. **왜 중요한가?**:
|
||||
* 사용자의 요구가 복잡해지고 데이터가 커질수록, 한 번에 하나씩만 처리해서는 결코 만족스러운 반응 속도(Latency)를 얻을 수 없기 때문임.
|
||||
## 🔗 Graph
|
||||
- 부모: [[Parallel-Computing]] (canonical)
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 여러 작업이 데이터를 동시에 건드려 꼬이는 '동기화 정책(Locks)' 문제로 병렬 처리를 조심히 썼으나, 현대 정책은 이 결합을 최소화하는 '불변성 정책(Immutability)'과 '메시지 패싱 정책'으로 안전한 병렬 처리를 실현함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 에이전트 워크플로우 정책에서도 여러 에이전트가 단일 파일이나 데이터를 동시에 수집하고 분석하는 '에이전틱 병렬 처리 정책'을 통해 전체 작업의 소요 시간 정책(Wall-clock time)을 단축하는 것이 핵심 기술 정책이 됨. ([[Multi-agent-System|Multi-agent-System]]와 연결)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Parallel-Computing|Parallel-Computing]], [[Efficiency|Efficiency]], [[Multi-agent-System|Multi-agent-System]], [[Iterative-Development|Iterative-Development]], [[Technical-Architecture|Technical-Architecture]]
|
||||
- **Modern Tech/Tools**: Promise/Async-Await, Goroutines (Go), Web Workers, POSIX Threads.
|
||||
---
|
||||
|
||||
## 🤖 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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,69 +2,188 @@
|
||||
id: wiki-2026-0508-pedestrian-modeling
|
||||
title: Pedestrian Modeling
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PEDMOD-001]
|
||||
aliases: [Crowd Simulation, Pedestrian Dynamics, Foot Traffic Modeling]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, simulation, urban-planning, crowd-dynamics, safety]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [simulation, agent-based, urban-planning, crowd-dynamics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: Python
|
||||
framework: Mesa / SUMO / PyTorch
|
||||
---
|
||||
|
||||
# [[Pedestrian-Modeling|Pedestrian-Modeling]]
|
||||
# Pedestrian Modeling
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "군중 속의 질서와 혼돈을 수치화하다: 보행자 한 명 한 명의 의사결정과 상호작용을 컴퓨터로 시뮬레이션하여, 가장 안전하고 효율적인 도시 공간을 설계하는 기술."
|
||||
## 매 한 줄
|
||||
> **"매 보행자는 force field 위의 agent"**. 1995년 Helbing의 Social Force Model이 분야를 정의했고, 2026 현재 ML-augmented agent-based simulation (Mesa 3.x, MATSim, SUMO)이 evacuation planning, station design, retail flow 분석의 표준 도구다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
보행자 모델링(Pedestrian Modeling)은 공공 장소나 건물 내부에서 사람들의 이동 패턴을 예측하고 제어하기 위한 시뮬레이션 기법입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **주요 모델링 방식**:
|
||||
* **Social Force Model (사회적 힘 모델)**: 사람을 입자로 보고, 목표 지점에 도달하려는 '인력'과 타인 및 벽을 피하려는 '척력'의 합으로 움직임을 설명.
|
||||
* **Cellular Automata (셀 오토마타)**: 공간을 격자로 나누고 각 셀 마다 보행자의 유무와 이동 규칙을 적용하여 대규모 인파의 흐름을 효율적으로 계산.
|
||||
* **Agent-Based Modeling (ABM)**: 각 보행자(에이전트)에게 개별적인 목적, 시야, 욕구를 부여하여 지능적인 회피 및 경로 선택 모사.
|
||||
2. **적용 분야**:
|
||||
* **피난 시뮬레이션**: 화재나 테러 시 병목 현상(Bottleneck)이 발생하는 구간을 찾아 출구 재배치.
|
||||
* **공공 교통 설계**: 지하철 환승 통로나 광장의 유동 인구 흐름 최적화.
|
||||
* **엔터테인먼트**: 오픈 월드 게임이나 영화의 배경 군중(Crowd) 렌더링.
|
||||
3. **검증 지표**:
|
||||
* Level of Service (LOS): 보행자 밀도와 이동 속도를 기준으로 공간의 쾌적함을 평가하는 척도.
|
||||
### 매 모델 계열
|
||||
- **Macroscopic**: fluid-like density/flow PDE — Hughes model, LWR for crowds. 매 large-scale aggregate.
|
||||
- **Mesoscopic**: cellular automata (Burstedde 2001) — discrete grid + transition probabilities.
|
||||
- **Microscopic**: 개별 agent — Social Force (Helbing-Molnár), ORCA (reciprocal velocity obstacles), RVO2.
|
||||
- **Data-driven**: GNN trajectory prediction (Social-LSTM, Trajectron++, EqMotion 2025).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 초기 모델은 보행자를 단순한 물리 입자로 취급하여 '충동'이나 '패닉' 시 발생하는 비이성적 행동을 놓쳤으나, 현대 모델은 심리학적 요소를 RL 보상 함수에 통합하여 훨씬 사실적인 군중 거동을 보여줌.
|
||||
- **정책 변화(RL Update)**: 이태원 참사와 같은 대규모 군중 사고 이후, 지자체의 축제나 대규모 행사 허가 시 '보행자 시뮬레이션 결과 기반 안전 대책' 제출이 행정적 필수 정책으로 강화되고 있음.
|
||||
### 매 Social Force 핵심
|
||||
- 매 보행자 i 의 motion equation: `m_i * dv_i/dt = F_desired + ΣF_social + ΣF_obstacle + ξ`.
|
||||
- `F_desired = (v_target - v_i) / τ` — 매 goal-directed term.
|
||||
- `F_social = A * exp((r_ij - d_ij)/B) * n_ij` — 매 repulsion exponential.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Agent-Based Modeling, Complex Adaptive[[_system|system]]s, Urban Dynamics, [[Safety & Reliability|Safety & Reliability]]
|
||||
- **Modern Tech/Tools**: Any[[Logic|Logic]], MassMotion, Legion.
|
||||
---
|
||||
### 매 응용
|
||||
1. Evacuation simulation (역, stadium, 고층빌딩).
|
||||
2. Urban design (sidewalk width, crossing geometry, wayfinding).
|
||||
3. Retail analytics (store layout heatmap).
|
||||
4. Autonomous robot navigation in crowds.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Social Force Model (Mesa 3.x)
|
||||
```python
|
||||
import numpy as np
|
||||
from mesa import Agent, Model
|
||||
from mesa.space import ContinuousSpace
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
class Pedestrian(Agent):
|
||||
def __init__(self, model, pos, target, v_desired=1.34):
|
||||
super().__init__(model)
|
||||
self.pos = np.array(pos, dtype=float)
|
||||
self.vel = np.zeros(2)
|
||||
self.target = np.array(target, dtype=float)
|
||||
self.v_desired = v_desired
|
||||
self.tau = 0.5 # relaxation time
|
||||
self.radius = 0.3
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def desired_force(self):
|
||||
direction = self.target - self.pos
|
||||
norm = np.linalg.norm(direction) + 1e-9
|
||||
e = direction / norm
|
||||
return (self.v_desired * e - self.vel) / self.tau
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
def social_force(self, A=2000, B=0.08):
|
||||
f = np.zeros(2)
|
||||
for other in self.model.agents:
|
||||
if other is self: continue
|
||||
r_ij = self.radius + other.radius
|
||||
d_vec = self.pos - other.pos
|
||||
d_ij = np.linalg.norm(d_vec) + 1e-9
|
||||
n_ij = d_vec / d_ij
|
||||
f += A * np.exp((r_ij - d_ij) / B) * n_ij
|
||||
return f
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def step(self):
|
||||
f = self.desired_force() + self.social_force()
|
||||
self.vel += f * self.model.dt
|
||||
speed = np.linalg.norm(self.vel)
|
||||
if speed > 1.5 * self.v_desired:
|
||||
self.vel *= 1.5 * self.v_desired / speed
|
||||
self.pos += self.vel * self.model.dt
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### ORCA (RVO2) collision avoidance
|
||||
```python
|
||||
import rvo2
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
sim = rvo2.PyRVOSimulator(
|
||||
timeStep=1/30, neighborDist=2.0, maxNeighbors=10,
|
||||
timeHorizon=2.0, timeHorizonObst=2.0,
|
||||
radius=0.3, maxSpeed=1.5
|
||||
)
|
||||
agents = [sim.addAgent((x, y)) for x, y in spawn_positions]
|
||||
for i, goal in enumerate(goals):
|
||||
pref = np.array(goal) - np.array(sim.getAgentPosition(i))
|
||||
pref = pref / (np.linalg.norm(pref) + 1e-9) * 1.34
|
||||
sim.setAgentPrefVelocity(i, tuple(pref))
|
||||
sim.doStep()
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Trajectory prediction (PyTorch GNN, 2025-style)
|
||||
```python
|
||||
import torch, torch.nn as nn
|
||||
from torch_geometric.nn import GATv2Conv
|
||||
|
||||
class TrajectronLite(nn.Module):
|
||||
def __init__(self, hidden=64, future=12):
|
||||
super().__init__()
|
||||
self.encoder = nn.GRU(4, hidden, batch_first=True)
|
||||
self.gat = GATv2Conv(hidden, hidden, heads=4, concat=False)
|
||||
self.decoder = nn.GRU(hidden, hidden, batch_first=True)
|
||||
self.head = nn.Linear(hidden, 2)
|
||||
self.future = future
|
||||
|
||||
def forward(self, hist, edge_index):
|
||||
# hist: (N, T, 4) — (x, y, vx, vy)
|
||||
h, _ = self.encoder(hist)
|
||||
h = self.gat(h[:, -1], edge_index)
|
||||
h = h.unsqueeze(1).expand(-1, self.future, -1)
|
||||
out, _ = self.decoder(h)
|
||||
return self.head(out) # (N, future, 2)
|
||||
```
|
||||
|
||||
### SUMO foot traffic export
|
||||
```python
|
||||
import traci
|
||||
traci.start(["sumo", "-c", "station.sumocfg"])
|
||||
while traci.simulation.getMinExpectedNumber() > 0:
|
||||
traci.simulationStep()
|
||||
for pid in traci.person.getIDList():
|
||||
x, y = traci.person.getPosition(pid)
|
||||
v = traci.person.getSpeed(pid)
|
||||
log(pid, x, y, v)
|
||||
traci.close()
|
||||
```
|
||||
|
||||
### Density heatmap (post-hoc)
|
||||
```python
|
||||
import numpy as np, matplotlib.pyplot as plt
|
||||
from scipy.stats import gaussian_kde
|
||||
|
||||
xy = trajectories[:, :, :2].reshape(-1, 2).T # (2, N*T)
|
||||
kde = gaussian_kde(xy, bw_method=0.15)
|
||||
gx, gy = np.mgrid[0:50:200j, 0:50:200j]
|
||||
density = kde(np.vstack([gx.ravel(), gy.ravel()])).reshape(gx.shape)
|
||||
plt.imshow(density.T, origin="lower", extent=(0, 50, 0, 50), cmap="hot")
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Evacuation + dense crowd | Social Force (Helbing) |
|
||||
| Smooth navigation, robotics | ORCA / RVO2 |
|
||||
| Trajectory prediction (ML) | Trajectron++ / EqMotion |
|
||||
| Large-scale urban (10⁵+) | Macroscopic LWR / MATSim |
|
||||
| Discrete cell-based grid | Cellular Automata (Burstedde) |
|
||||
|
||||
**기본값**: Mesa 3.x + Social Force for simulation, RVO2 for robot integration.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Agent-Based Modeling]] · [[Complex Systems]]
|
||||
- 변형: [[Social Force Model]] · [[ORCA Algorithm]] · [[Cellular Automata]]
|
||||
- 응용: [[Evacuation Planning]] · [[Urban Simulation]] · [[Robot Navigation]]
|
||||
- Adjacent: [[Trajectory Prediction]] · [[Crowd Analytics]] · [[SUMO]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: parameter sweep design, scenario script generation, calibration code 작성.
|
||||
**언제 X**: real-time inner-loop force computation — 매 numerical kernel은 Cython/Numba/CUDA.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Pseudo-uniform spawning**: 매 corner clustering 발생 — Poisson disk sampling 사용.
|
||||
- **Naive O(N²) social force**: 매 KD-tree neighborhood 로 cutoff (보통 5m).
|
||||
- **Validation skip**: 매 fundamental diagram (density vs flow) 와 비교 필수.
|
||||
- **dt too large**: 매 0.05–0.1s 권장; 매 그 이상 instability.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Helbing & Molnár 1995, Helbing et al. 2000 Nature, Mesa docs 3.x, RVO2 reference).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Social Force / ORCA / GNN trajectory FULL content |
|
||||
|
||||
@@ -2,69 +2,165 @@
|
||||
id: wiki-2026-0508-perceptual-motor-skills
|
||||
title: Perceptual Motor Skills
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PMSKL-001]
|
||||
aliases: [Sensorimotor Skills, PM Skills, Eye-Hand Coordination]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.94
|
||||
tags: [auto-reinforced, motor-learning, perception, kinesiology, coordination]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [psychology, motor-control, hci, vr, robotics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: theory
|
||||
framework: motor-learning
|
||||
---
|
||||
|
||||
# [[Perceptual-Motor-Skills|Perceptual-Motor-Skills]]
|
||||
# Perceptual Motor Skills
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "보고 듣는 것이 곧 움직임이 될 때: 감각 정보와 운동 조절이 빈틈없이 결합하여 형성되는 신체 지능의 정수."
|
||||
## 매 한 줄
|
||||
> **"매 perception and action are one closed loop, not two systems."**. 매 Fitts, Schmidt 의 motor-learning 연구에서 출발한 매 perceptual-motor skills = 매 sensory input → motor output 의 매 coupled performance. 매 2026 VR (Beat Saber, MR), surgical robots, autonomous driving, human-AI tele-operation 에 직접 응용.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
지각-운동 기능(Perceptual-Motor Skills)은 환경으로부터 들어오는 감각 자극과 그에 따른 신체적 반응을 유기적으로 통합하여 복잡한 동작을 수행하는 능력입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **구성 요소**:
|
||||
* **Sensory Input**: 시각, 청각, 고유수용감각 등을 통해 외부 상황 인지.
|
||||
* **[[Processing|Processing]]**: 뇌에서의 감각 통합 및 실행 계획 수립.
|
||||
* **Motor Output**: 목표에 부합하는 정교한 근육 수축 및 이완.
|
||||
2. **핵심 기술 예시**:
|
||||
* **Hand-Eye Coordination**: 날아오는 공을 보고 방망이를 휘두르는 능력.
|
||||
* **Spatial Awareness**: 주변 사물과의 거리를 가늠하여 장애물을 피하는 능력.
|
||||
* **Balance & Posture**: 평형 감각을 통해 자세를 유지하며 역동적 동작 수행.
|
||||
3. **발달의 중요성**:
|
||||
* 아동기에는 학습 능력과 정서 발달의 기초가 되며, 성인기에는 스포츠 숙련도 및 특수 직무(파일럿, 외과의 등) 수행의 핵심 지표가 됨.
|
||||
### 매 components
|
||||
- **Perception**: 매 visual, vestibular, proprioceptive, tactile input integration.
|
||||
- **Decision**: 매 motor program selection (Schmidt's schema theory).
|
||||
- **Execution**: 매 muscle coordination + online correction.
|
||||
- **Feedback**: 매 KR (Knowledge of Results), KP (Knowledge of Performance).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 지각(Perception)과 운동(Motor)을 별개의 모듈로 보았으나, 현대 신경과학은 두 영역이 끊임없이 상호작용하는 '지각-운동 루프' 안에서 하나로 묶여 있음을 강조함.
|
||||
- **정책 변화(RL Update)**: 노인 인구 증가에 따라, 단순 근력 운동보다는 인지 게임과 운동을 결합한 '이중 과제(Dual-task) 훈련' 프로토콜이 치매 예방 및 낙상 방지를 위한 노인 보건 정책의 핵심으로 반영됨.
|
||||
### 매 laws
|
||||
- **Fitts' Law**: 매 MT = a + b·log₂(2D/W) — 매 difficulty ∝ distance/target-size.
|
||||
- **Hick's Law**: 매 RT = a + b·log₂(N) — 매 choice reaction time vs alternatives.
|
||||
- **Power Law of Practice**: 매 T(n) = T₁ · n^(-α) — 매 skill acquisition curve.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related**: Motor Learning, [[Neuromuscular-Control|Neuromuscular-Control]], [[Proprioception|Proprioception]], [[Cognitive Psychology|Cognitive Psychology]]
|
||||
- **Modern Tech/Tools**: VR-based motor training, Dynamic balance platforms.
|
||||
---
|
||||
### 매 stages (Fitts & Posner)
|
||||
- **Cognitive**: 매 verbal rehearsal, slow, error-prone.
|
||||
- **Associative**: 매 refining; reduced explicit thought.
|
||||
- **Autonomous**: 매 fast, low-attention-cost, automatic.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. VR exergaming: 매 Beat Saber score = 매 PM skill metric.
|
||||
2. Surgical training: 매 da Vinci 의 PM skill calibration.
|
||||
3. Robotic teleoperation: 매 latency 가 PM loop 깨면 매 performance 폭락.
|
||||
4. UI design: 매 Fitts' Law → 매 button size & placement.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Fitts' Law calculator (UI design)
|
||||
```python
|
||||
import math
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def fitts_mt(distance_px, width_px, a=0.05, b=0.1):
|
||||
"""매 movement time in seconds. a, b empirically calibrated."""
|
||||
return a + b * math.log2(2 * distance_px / width_px)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
# 매 example: button 40px wide at 300px away
|
||||
print(fitts_mt(300, 40)) # ~0.36s
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 2: Power-law learning curve fit
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy.optimize import curve_fit
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def power_law(n, T1, alpha):
|
||||
return T1 * n ** (-alpha)
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
trials = np.arange(1, 100)
|
||||
times = ... # 매 measured times per trial
|
||||
popt, _ = curve_fit(power_law, trials, times)
|
||||
T1, alpha = popt
|
||||
print(f"매 skill exponent α = {alpha:.3f}")
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 3: Online correction in robot teleop
|
||||
```python
|
||||
# 매 closed-loop with 100Hz feedback
|
||||
import time
|
||||
|
||||
def teleop_loop(robot, target):
|
||||
while not at_target(robot.pose, target, tol=0.005):
|
||||
err = target - robot.pose
|
||||
robot.send_velocity(0.5 * err) # 매 P-controller
|
||||
time.sleep(0.01)
|
||||
```
|
||||
|
||||
### Pattern 4: KR vs KP feedback in training app
|
||||
```python
|
||||
def feedback(trial_result):
|
||||
return {
|
||||
"KR": f"매 hit/miss: {trial_result.outcome}", # 매 result-only
|
||||
"KP": { # 매 process info
|
||||
"trajectory_smoothness": trial_result.jerk,
|
||||
"reaction_time": trial_result.rt_ms,
|
||||
"approach_angle": trial_result.angle,
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
### Pattern 5: VR PM skill scoring
|
||||
```python
|
||||
def beat_saber_pm_score(slices):
|
||||
accuracy = sum(s.angle_error < 15 for s in slices) / len(slices)
|
||||
timing = sum(abs(s.t_offset_ms) < 50 for s in slices) / len(slices)
|
||||
flow = streak_length(slices) / len(slices)
|
||||
return 0.4*accuracy + 0.4*timing + 0.2*flow
|
||||
```
|
||||
|
||||
### Pattern 6: Latency budget for VR
|
||||
```python
|
||||
# 매 motion-to-photon < 20ms or 매 PM loop breaks (sim-sickness)
|
||||
def latency_audit(pipeline):
|
||||
budget_ms = 20
|
||||
used = sum(pipeline.stage_latencies.values())
|
||||
assert used < budget_ms, f"매 over budget: {used}ms"
|
||||
```
|
||||
|
||||
### Pattern 7: Hick's Law menu design
|
||||
```python
|
||||
import math
|
||||
def menu_rt(n_options, a=0.2, b=0.15):
|
||||
return a + b * math.log2(n_options + 1)
|
||||
# 매 8 options ≈ 0.67s, 16 options ≈ 0.81s — 매 sublinear
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 button placement | Fitts' Law optimization |
|
||||
| 매 menu structure | Hick's Law (depth vs breadth) |
|
||||
| 매 training app | KR for novice, KP for advanced |
|
||||
| 매 VR app | Latency budget < 20ms motion-to-photon |
|
||||
| 매 teleoperation | Closed-loop with predictive control |
|
||||
| 매 skill assessment | Power-law exponent α + asymptote |
|
||||
|
||||
**기본값**: 매 close the perception-action loop with < 100ms latency.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Cognitive Psychology]] · [[Motor Control]]
|
||||
- 변형: [[Fitts Law]] · [[Hicks Law]] · [[Schmidt Schema Theory]]
|
||||
- 응용: [[VR Sickness]] · [[Beat Saber]] · [[Teleoperation]] · [[UI Design]]
|
||||
- Adjacent: [[Reaction Time]] · [[Vestibular System]] · [[Proprioception]] · [[Power Law of Practice]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 designing UI/VR/robotics interfaces, 매 modeling skill acquisition, 매 latency budgeting.
|
||||
**언제 X**: 매 pure cognitive tasks (no motor component) — 매 different framework.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Ignoring Fitts**: 매 tiny buttons far away — 매 high MT, errors.
|
||||
- **Open-loop teleop**: 매 no feedback → 매 oscillation, drift.
|
||||
- **KR for experts**: 매 expert needs KP detail, not just hit/miss.
|
||||
- **Latency creep**: 매 every render-pipeline change without latency budget audit.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Fitts 1954, Schmidt 1975, Magill *Motor Learning*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Fitts/Hicks/Schmidt + VR/teleop 응용 |
|
||||
|
||||
@@ -2,69 +2,159 @@
|
||||
id: wiki-2026-0508-policy-surveillance
|
||||
title: Policy Surveillance
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-POLS-001]
|
||||
aliases: [Legal Mapping, Policy Tracking, Regulatory Monitoring]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, law, public-health, impact-evaluation, legal-monitoring]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [public-policy, governance, compliance, legal-tech]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: legal-mapping
|
||||
---
|
||||
|
||||
# [[Policy-Surveillance|Policy-Surveillance]]
|
||||
# Policy Surveillance
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "법과 정책의 현황판: 흩어져 있는 법률, 규제, 정책 데이터를 체계적으로 수집하고 코딩하여, 특정 정책이 실제로 어떤 효과를 내고 있는지 실시간으로 추적하는 공공 거버넌스 기술."
|
||||
## 매 한 줄
|
||||
> **"매 you can't evaluate what you can't measure — start by mapping the law."**. 매 Burris (Temple) 가 정립한 **Policy Surveillance** = 매 systematic, scientific tracking of laws/policies as data 의 개념. 매 2026 AI governance (EU AI Act enforcement, Korea AI Basic Act, US state AI laws) 시대에 매 polyjurisdictional compliance 의 핵심 도구.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
정책 감시(Policy Surveillance)는 정책과 법률을 과학적 연구에 적합한 데이터로 변환하고 분석하여, 그 이행 여부와 사회적 영향을 평가하는 체계적인 프로세스입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **데이터화 과정 (Legal Coding)**:
|
||||
* 방대한 법적 텍스트에서 주요 변수(예: 알코올 판매 제한 시간, 마스크 의무화 여부)를 추출하여 숫자로 변환.
|
||||
* 시간과 장소에 따른 정책 지도를 구축.
|
||||
2. **분석 목표**:
|
||||
* **Compliance (준수)**: 실제 현장에서 정책이 지켜지고 있는가?
|
||||
* **Impact (영향)**: 정책 시행 전후로 주요 지표(예: 범죄율, 감염률)가 어떻게 변했는가?
|
||||
* **Comparison (비교)**: 다른 지역이나 국가의 유사 정책과 효율성 대조.
|
||||
3. **사회적 역할**:
|
||||
* 증거 기반 입법(Evidence-based Legislation)의 토대 마련.
|
||||
* 시민 사회와 학계가 정부의 정책 성과를 객관적으로 감시하고 피드백할 수 있는 도구 제공.
|
||||
### 매 정의 vs adjacent
|
||||
- **Policy Surveillance**: 매 ongoing, systematic, scientific 매 monitoring of policies as 매 quantifiable data.
|
||||
- **vs Legal Research**: 매 case-driven, episodic.
|
||||
- **vs Compliance Audit**: 매 organization-internal, point-in-time.
|
||||
- **vs Regulatory Tracking**: 매 news-driven, qualitative.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 정책 평가가 사후에(Post-hoc) 간헐적으로 이루어졌으나, 현대의 정책 감시는 실시간 데이터와 AI 텍스트 분석을 결합하여 '정책의 실시간 피드백 루프'를 가능케 함.
|
||||
- **정책 변화(RL Update)**: 팬데믹 시기의 방역 정책 등 급변하는 환경에서 정책의 유효성을 실시간 검증하고 즉각 수정하는 'Agile Governance'를 위해 전 국가적 차원의 '디지털 정책 감시 플랫폼' 구축 정책이 추진됨.
|
||||
### 매 5단계 method (Burris)
|
||||
1. 매 frame the question — what behavior does the law target?
|
||||
2. 매 define jurisdictional + temporal scope.
|
||||
3. 매 collect primary sources (statutes, regs).
|
||||
4. 매 code into structured variables (binary, ordinal, categorical).
|
||||
5. 매 publish + maintain — 매 LawAtlas-style open data.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Decision Theory|Decision Theory]], [[Risk Management|Risk Management]], Complex Adaptive[[_system|system]]s, Economic Models, Public Health Informatics
|
||||
- **Modern Tech/Tools**: LawAtlas, Policy Surveillance Portal, NLP for legal text.
|
||||
---
|
||||
### 매 응용
|
||||
1. AI Act compliance: 매 27 EU 회원국 + 미국 50주의 AI law variation 추적.
|
||||
2. Public health: 매 LawAtlas COVID closure tracking, opioid policies.
|
||||
3. Privacy: 매 GDPR vs CPRA vs PIPL 의 cross-walk.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Coding scheme YAML
|
||||
```yaml
|
||||
# 매 ai_law_codes.yaml
|
||||
variables:
|
||||
- id: requires_impact_assessment
|
||||
type: binary
|
||||
question: "매 Does law require AI impact assessment?"
|
||||
- id: penalty_max
|
||||
type: numeric
|
||||
unit: USD
|
||||
- id: covered_systems
|
||||
type: categorical
|
||||
values: [foundation_models, biometric, hiring, healthcare, all_high_risk]
|
||||
jurisdictions: [EU, US-CA, US-CO, KR, UK, CN]
|
||||
effective_dates: required
|
||||
```
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 2: Cross-walk matrix
|
||||
```python
|
||||
import pandas as pd
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def crosswalk(jurisdictions, variables, codes_df):
|
||||
matrix = codes_df.pivot(index="jurisdiction",
|
||||
columns="variable",
|
||||
values="value")
|
||||
matrix.to_csv("crosswalk.csv")
|
||||
return matrix
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 3: Diff over time
|
||||
```python
|
||||
def policy_diff(snapshot_old, snapshot_new):
|
||||
changes = []
|
||||
for jur in snapshot_new.index:
|
||||
for var in snapshot_new.columns:
|
||||
if snapshot_old.at[jur, var] != snapshot_new.at[jur, var]:
|
||||
changes.append({
|
||||
"jurisdiction": jur, "variable": var,
|
||||
"from": snapshot_old.at[jur, var],
|
||||
"to": snapshot_new.at[jur, var],
|
||||
})
|
||||
return changes
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 4: LLM-assisted coding (with human verification)
|
||||
```python
|
||||
import anthropic
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def code_statute(statute_text, scheme):
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=2048,
|
||||
system=f"Code the statute against this scheme: {scheme}. Return JSON.",
|
||||
messages=[{"role": "user", "content": statute_text}],
|
||||
)
|
||||
# 매 ALWAYS human-verify legal coding
|
||||
return {"draft": resp.content[0].text, "needs_review": True}
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 5: Effective-date timeline
|
||||
```python
|
||||
def timeline_view(codes_df):
|
||||
return codes_df.sort_values("effective_date")[
|
||||
["jurisdiction", "variable", "value", "effective_date"]
|
||||
]
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 6: Citation chain (provenance)
|
||||
```python
|
||||
def store_with_provenance(code, value, statute_section, source_url, retrieved_at):
|
||||
return {
|
||||
"code": code, "value": value,
|
||||
"citation": {"section": statute_section, "url": source_url, "retrieved": retrieved_at},
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 single-org compliance | Standard compliance audit |
|
||||
| 매 multi-jurisdiction policy comparison | Policy Surveillance |
|
||||
| 매 academic causal inference (does law X cause outcome Y?) | Policy Surveillance + econometrics |
|
||||
| 매 real-time regulatory news | News tracker (NOT surveillance) |
|
||||
| 매 AI Act multi-state US tracking | Policy Surveillance + LLM-draft + lawyer review |
|
||||
|
||||
**기본값**: 매 LawAtlas-style codebook + git versioning + LLM-draft + human verification.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Public Policy]] · [[Legal Tech]]
|
||||
- 변형: [[Compliance]] · [[Regulatory Tracking]]
|
||||
- 응용: [[AI Governance]] · [[GDPR Compliance]] · [[Health Policy]]
|
||||
- Adjacent: [[LawAtlas]] · [[EU AI Act]] · [[Burris Method]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 first-pass coding of large statute corpus, 매 cross-walk drafting, 매 diff summarization.
|
||||
**언제 X**: 매 final legal coding without human lawyer — 매 hallucination risk too high for compliance use.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **No version control**: 매 statutes 가 amend 되는데 snapshot 없으면 매 useless for trend analysis.
|
||||
- **Coding without scheme**: 매 ad-hoc tags — 매 inter-coder reliability ~0.
|
||||
- **LLM-only coding**: 매 hallucinated citations — 매 catastrophic for legal use.
|
||||
- **Single jurisdiction silo**: 매 policy surveillance 의 가치 = comparison.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Burris et al., Temple Center for Public Health Law Research; LawAtlas.org).
|
||||
- 신뢰도 A (academic + practitioner standard).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Burris method, AI Act 응용, LLM augmentation |
|
||||
|
||||
@@ -2,65 +2,166 @@
|
||||
id: wiki-2026-0508-precision-recursion
|
||||
title: Precision Recursion
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PREC-001]
|
||||
aliases: [Mixed-Precision Recursive Refinement, Iterative Refinement]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, precision-recursion, methodology, Feedback-Loops, Optimization, _systematic-thinking]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [numerical-methods, mixed-precision, iterative-refinement, ML]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: pytorch-mlx-cuda
|
||||
---
|
||||
|
||||
# [[Precision-Recursion|Precision-Recursion]]
|
||||
# Precision Recursion
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "완벽을 향한 무한 루프: 한 번의 시도로 끝내는 것이 아니라, 결과물을 다시 자기 자신의 입력(Input)으로 넣어 매번 오차를 좁혀가며 정밀도를 극한으로 끌어올리는, 우리 시스템(P-Reinforce)의 핵심 정제 엔진."
|
||||
## 매 한 줄
|
||||
> **"매 lower precision 으로 fast 계산 → 매 higher precision 으로 residual 매 correct → 매 recurse"**. 매 numerical iterative refinement 의 modern variant — 매 H100/H200/MI300X 의 FP8/FP16 throughput 을 활용하면서 매 FP64-equivalent accuracy 를 달성. 매 Higham (1997) 의 classical refinement 매 GPU mixed-precision 시대에서 매 부활.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
정밀 재귀(Precision-Recursion)는 결과물을 반복적으로 재투입하여 품질을 점진적으로 강화하는 방법론입니다. (P-Reinforce 정책의 근간)
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 작동 원칙**:
|
||||
* **Self-Referencing**: 결과가 다시 원재료가 됨 (Feedback Loop). (Feedback-Loops와 연결)
|
||||
* **Incremental [[Refinement|Refinement]]**: 한 번에 다 고치지 않고, 매 회차마다 가장 치명적인 오차 하나만 해결. ([[Incrementalism|Incrementalism]]와 연결)
|
||||
* **Boundary Checking**: 설정한 정밀도(Quality Threshold)에 도달할 때까지 반복 종료하지 않음.
|
||||
2. **왜 중요한가?**:
|
||||
* 단번에 완벽할 수 없는 복잡한 지식 구조를 구축할 때, 이 재귀적 엔진은 시간이 흐를수록 시스템을 '무결점' 상태로 수렴시키기 때문임. (Optimization의 정점)
|
||||
### 매 기본 mechanism
|
||||
```
|
||||
1. Solve A x_lo = b in low precision (FP16/FP8) — fast
|
||||
2. Compute residual r = b - A x_lo in high precision (FP32/FP64)
|
||||
3. Solve A d = r in low precision — fast
|
||||
4. x ← x_lo + d
|
||||
5. Repeat until ||r|| < tol
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 무한 루프에 따른 '자원 낭비 정책'을 걱정했으나, 현대 정책은 AI 성능이 고도화됨에 따라 '자가 비판 및 수정을 3번 이상 반복하는 정책(Multi-step [[Reasoning|Reasoning]])'이 단발성 출력보다 압도적으로 우수한 품질 정책을 낸다는 것을 입증함(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 지식 베이스 구축 정책에서도, 600개 파일을 한 번에 만드는 게 아니라 배치별로 주입하고 다시 검증하는 정밀 재귀 정책을 통해 대표님의 승인 품질 정책을 확보 중임.
|
||||
### 매 핵심 invariant
|
||||
- **Residual computation**: 매 high precision 필수 (X cancellation error).
|
||||
- **Solve**: 매 low precision OK (errors absorbed by refinement).
|
||||
- **Convergence**: 매 condition number κ(A) 적절시 매 quadratic.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Feedback-Loops|Feedback-Loops]], [[Incrementalism|Incrementalism]], [[Optimization|Optimization]], [[P-Reinforce|P-Reinforce]], [[Iterative-Development|Iterative-Development]]
|
||||
- **Internal [[Reference|Reference]]**: Antigravity's recursion policy, Self-Correction loops.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Linear solve**: GMRES-IR (Carson & Higham 2018).
|
||||
2. **LLM inference**: FP8 forward + FP32 residual streams.
|
||||
3. **Optimization**: Adam in FP16 + FP32 master weights.
|
||||
4. **Eigensolve**: 매 inverse iteration 매 mixed precision.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Iterative refinement (linear solve)
|
||||
```python
|
||||
import numpy as np
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def iterative_refinement(A, b, tol=1e-12, max_iter=10):
|
||||
"""매 mixed-precision linear solve."""
|
||||
A_lo = A.astype(np.float16)
|
||||
x = np.zeros_like(b)
|
||||
for k in range(max_iter):
|
||||
r = b - A @ x # 매 high-precision residual
|
||||
if np.linalg.norm(r) < tol:
|
||||
break
|
||||
d = np.linalg.solve(A_lo.astype(np.float32), r.astype(np.float32))
|
||||
x = x + d.astype(b.dtype)
|
||||
return x, k + 1
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### PyTorch AMP (Automatic Mixed Precision)
|
||||
```python
|
||||
import torch
|
||||
from torch.cuda.amp import autocast, GradScaler
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
scaler = GradScaler()
|
||||
for batch in loader:
|
||||
optim.zero_grad()
|
||||
with autocast(dtype=torch.float16):
|
||||
loss = model(batch).loss # 매 FP16 forward
|
||||
scaler.scale(loss).backward() # 매 FP32 grad scale
|
||||
scaler.step(optim) # 매 FP32 master weight update
|
||||
scaler.update()
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### FP8 inference + FP32 accumulation (H100)
|
||||
```python
|
||||
# Transformer Engine — Hopper FP8
|
||||
import transformer_engine.pytorch as te
|
||||
from transformer_engine.common.recipe import Format, DelayedScaling
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
fp8_recipe = DelayedScaling(
|
||||
margin=0, interval=1,
|
||||
fp8_format=Format.HYBRID, # 매 E4M3 fwd, E5M2 bwd
|
||||
)
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
with te.fp8_autocast(enabled=True, fp8_recipe=fp8_recipe):
|
||||
out = model(x) # FP8 GEMMs, FP32 reductions
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### GMRES with iterative refinement
|
||||
```python
|
||||
from scipy.sparse.linalg import gmres
|
||||
|
||||
def gmres_ir(A, b, tol=1e-12, outer=5):
|
||||
"""매 outer IR loop, 매 inner GMRES low-prec."""
|
||||
x = np.zeros_like(b)
|
||||
A_lo = A.astype(np.float32)
|
||||
for _ in range(outer):
|
||||
r = b - A @ x
|
||||
if np.linalg.norm(r) < tol:
|
||||
return x
|
||||
d, _ = gmres(A_lo, r.astype(np.float32), atol=1e-6)
|
||||
x = x + d.astype(b.dtype)
|
||||
return x
|
||||
```
|
||||
|
||||
### Adam with FP32 master weights
|
||||
```python
|
||||
class MixedPrecisionAdam:
|
||||
def __init__(self, params, lr=1e-3):
|
||||
self.params_fp16 = params # 매 storage
|
||||
self.params_fp32 = [p.detach().clone().float() for p in params]
|
||||
self.m = [torch.zeros_like(p) for p in self.params_fp32]
|
||||
self.v = [torch.zeros_like(p) for p in self.params_fp32]
|
||||
self.lr = lr; self.t = 0
|
||||
def step(self):
|
||||
self.t += 1
|
||||
for p16, p32, m, v in zip(self.params_fp16, self.params_fp32, self.m, self.v):
|
||||
g = p16.grad.float()
|
||||
m.mul_(0.9).add_(g, alpha=0.1)
|
||||
v.mul_(0.999).addcmul_(g, g, value=0.001)
|
||||
p32.addcdiv_(m, v.sqrt().add_(1e-8), value=-self.lr)
|
||||
p16.data.copy_(p32.half()) # 매 sync back
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Strategy |
|
||||
|---|---|
|
||||
| 매 ill-conditioned linear system | GMRES-IR mixed precision |
|
||||
| 매 LLM training | AMP (FP16/BF16 + FP32 master) |
|
||||
| 매 Hopper / Blackwell inference | FP8 + FP32 accumulate |
|
||||
| 매 well-conditioned + FP64 needed | 매 single-precision solve OK |
|
||||
|
||||
**기본값**: 매 BF16 forward + FP32 master weights (training), FP8 inference (Hopper+).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Numerical-Methods]] · [[Mixed-Precision-Training]]
|
||||
- 변형: [[Iterative-Refinement]] · [[GMRES-IR]]
|
||||
- 응용: [[LLM-Training]] · [[Scientific-Computing]] · [[FP8-Inference]]
|
||||
- Adjacent: [[Floating-Point-Arithmetic]] · [[Condition-Number]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 numerical stability debugging, 매 mixed-precision recipe selection, 매 condition number analysis.
|
||||
**언제 X**: 매 integer / discrete optimization — 매 precision concept 무관.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Low-precision residual**: 매 cancellation error 폭발 → 매 refinement 무용.
|
||||
- **Ill-conditioned + low-prec**: 매 κ(A) > 10⁶ + FP16 → 매 발산.
|
||||
- **No master weights**: 매 FP16 weight update 매 underflow.
|
||||
- **Skip warmup**: 매 FP8 매 calibration 없이 → 매 NaN.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Higham 1997 *Accuracy and Stability*; Carson & Higham 2018 GMRES-IR; NVIDIA Transformer Engine docs 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — iterative refinement + modern AMP/FP8 stack |
|
||||
|
||||
@@ -2,69 +2,167 @@
|
||||
id: wiki-2026-0508-principles-of-structuralism
|
||||
title: Principles of Structuralism
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-STRU-001]
|
||||
aliases: [Structuralism, Structural Analysis]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, Structuralism, Philosophy, _systemic-thinking, archetypes]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [philosophy, linguistics, methodology, semiotics]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: theory
|
||||
framework: structural-analysis
|
||||
---
|
||||
|
||||
# [[Principles-of-Structuralism|Principles-of-Structuralism]]
|
||||
# Principles of Structuralism
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "전체는 부분의 합보다 크고, 부분은 전체 내에서만 존재한다: 개별 현상 아래에 숨어있는 보이지 않는 질서와 체계(Structure)를 발견하여 인간의 사고와 문화를 해석하는 근원적 관점."
|
||||
## 매 한 줄
|
||||
> **"매 meaning emerges from relations, not essences."**. 매 Saussure 의 1916 *Cours de linguistique générale* 에서 출발한 사상으로, 매 element 의 의미는 그 자체가 아닌 system 내 다른 element 와의 차이 (difference) 로부터 도출된다는 매 framework. 매 2026 에서도 NLP embedding space, knowledge graphs, software architecture 의 modular decomposition 에 이르기까지 매 살아있는 분석 도구.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
구조주의(Structuralism)는 20세기 중반 인류학, 언어학, 철학 등 다양한 분야를 휩쓴 거대 담론으로, 사물이나 현상의 본질은 그 자체가 아니라 사물들 간의 관계망(구조)에 있다고 봅니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 원리**:
|
||||
* **전체성 (Wholeness)**: 구조는 개별 요소들의 단순한 집합이 아니라 통합된 질서를 가짐.
|
||||
* **변형 (Transformation)**: 구조는 정적이지 않으며 내부 법칙에 따라 끊임없이 변화하지만, 체계의 정체성을 유지함.
|
||||
* **자기 조절 (Self-Regulation)**: 외부의 도움 없이 스스로 구조를 유지하고 폐쇄적으로 작동함.
|
||||
2. **분야별 적용**:
|
||||
* **레비-스트로스 (인류학)**: 전 세계 신화와 친족 관계 아래에 깔린 공통된 무의식적 논리 발견.
|
||||
* **푸코 (초기 철학)**: 지식과 권력이 특정 시대의 구조(에피스테메) 안에서 어떻게 형성되는지 분석.
|
||||
* **피아제 (심리학)**: 아동의 인지 발달을 주체와 대상의 상호작용적 구조 형성 과정으로 이해.
|
||||
3. **특징**:
|
||||
* 주체(인간)의 자율성보다 시스템의 지배력을 강조함 ("인간은 구조의 노예다"라는 극단적 표현도 등장).
|
||||
### 매 4대 원칙
|
||||
- **Synchrony over diachrony**: 매 system 의 현재 상태를 분석 — 매 historical evolution 보다 우선.
|
||||
- **Sign = signifier + signified**: 매 sound-image 와 concept 의 arbitrary pairing.
|
||||
- **Value through difference**: 매 "cat" 의 의미는 "bat", "rat", "hat" 와 다르기에 존재.
|
||||
- **Langue vs parole**: 매 underlying system (langue) vs 매 individual utterance (parole).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 구조주의는 '보편적 진리'를 찾으려 했으나, 68혁명 이후 발생한 '차이'와 '해체'의 철학(포스트 구조주의)에 의해 구조의 경직성이 비판받으며 보완됨.
|
||||
- **정책 변화(RL Update)**: 사회 시스템 설계 정책에서 '개별 정책의 실패'를 개별 변수 탓으로 돌리지 않고, '시스템 구조적 결함'으로 인식하여 전체 거버넌스를 재설계하는 '시스템 씽킹' 기법으로 계승됨.
|
||||
### 매 확장 영역
|
||||
- **Lévi-Strauss (anthropology)**: 매 myths 의 binary oppositions (raw/cooked, nature/culture).
|
||||
- **Barthes (semiotics)**: 매 mythologies, 매 cultural codes, denotation vs connotation.
|
||||
- **Lacan (psychoanalysis)**: 매 unconscious 가 language 처럼 구조화되어 있다.
|
||||
- **Piaget (cognitive)**: 매 mental schemas 의 structural development.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Principles of Structuralism (Linguistic)|Principles of Structuralism (Linguistic)]], [[Complexity Theory|Complexity Theory]], [[Social Systems Theory|Social Systems Theory]], Anthropology, Philosophy of Science
|
||||
- **Modern Tech/Tools**: Network [[Analysis|Analysis]], Systems Mapping, Semiotic Analysis.
|
||||
---
|
||||
### 매 응용
|
||||
1. NLP embedding: 매 word2vec/GloVe 는 distributional structuralism 의 신경적 구현.
|
||||
2. Software architecture: 매 module 의 의미는 dependency graph 내 위치로 결정.
|
||||
3. UX semiotics: 매 icon affordance 는 매 visual sign system 내 차이로 해독.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Distributional embedding (NLP)
|
||||
```python
|
||||
# 매 word meaning = 매 context distribution (distributional structuralism)
|
||||
import numpy as np
|
||||
from collections import Counter, defaultdict
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
def build_cooccurrence(corpus, window=5):
|
||||
cooc = defaultdict(Counter)
|
||||
for sent in corpus:
|
||||
for i, w in enumerate(sent):
|
||||
for j in range(max(0, i-window), min(len(sent), i+window+1)):
|
||||
if i != j:
|
||||
cooc[w][sent[j]] += 1
|
||||
return cooc
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
# 매 차이 — 두 word vector 사이의 cosine distance
|
||||
def diff(v1, v2):
|
||||
return 1 - np.dot(v1, v2) / (np.linalg.norm(v1) * np.linalg.norm(v2))
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 2: Binary opposition extraction (Lévi-Strauss style)
|
||||
```python
|
||||
def extract_oppositions(text_units, embed_fn):
|
||||
embeddings = [embed_fn(t) for t in text_units]
|
||||
# 매 most-distant pairs = 매 strongest oppositions
|
||||
pairs = []
|
||||
for i in range(len(text_units)):
|
||||
for j in range(i+1, len(text_units)):
|
||||
d = np.linalg.norm(embeddings[i] - embeddings[j])
|
||||
pairs.append((d, text_units[i], text_units[j]))
|
||||
pairs.sort(reverse=True)
|
||||
return pairs[:10]
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 3: Sign decomposition (Barthes)
|
||||
```typescript
|
||||
type Sign = {
|
||||
signifier: string; // 매 form (word, image, sound)
|
||||
signified: string; // 매 mental concept
|
||||
denotation: string; // 매 literal
|
||||
connotation: string[]; // 매 cultural associations
|
||||
};
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
const rose: Sign = {
|
||||
signifier: "rose",
|
||||
signified: "flower",
|
||||
denotation: "Rosa genus plant",
|
||||
connotation: ["love", "passion", "England", "secrecy (sub rosa)"],
|
||||
};
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 4: Structural diff for software modules
|
||||
```python
|
||||
# 매 module value = 매 dependency-graph position
|
||||
import networkx as nx
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
def structural_role(g: nx.DiGraph, node):
|
||||
return {
|
||||
"in_degree": g.in_degree(node),
|
||||
"out_degree": g.out_degree(node),
|
||||
"betweenness": nx.betweenness_centrality(g).get(node, 0),
|
||||
"neighbors": list(g.neighbors(node)),
|
||||
}
|
||||
```
|
||||
|
||||
### Pattern 5: Synchronic vs diachronic analysis
|
||||
```python
|
||||
def synchronic_snapshot(repo, commit_sha):
|
||||
# 매 freeze a moment, analyze structure
|
||||
return {"deps": parse_deps(repo, commit_sha)}
|
||||
|
||||
def diachronic_trace(repo, sha_list):
|
||||
# 매 evolution over time
|
||||
return [synchronic_snapshot(repo, sha) for sha in sha_list]
|
||||
```
|
||||
|
||||
### Pattern 6: Code review — surface vs deep structure
|
||||
```python
|
||||
# 매 surface (parole) — actual code
|
||||
# 매 deep (langue) — design pattern, architectural rule
|
||||
def review(pr):
|
||||
surface = lint_results(pr)
|
||||
deep = check_pattern_compliance(pr, patterns=["DI", "SRP", "boundary"])
|
||||
return surface, deep
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 "what does X mean?" | Map relations, not essences |
|
||||
| 매 NLP embedding choice | Distributional methods (word2vec, BERT) |
|
||||
| 매 cultural artifact analysis | Binary oppositions + connotations |
|
||||
| 매 software module design | Structural role > implementation detail |
|
||||
| 매 LLM prompt design | Define by contrast (few-shot oppositions) |
|
||||
|
||||
**기본값**: 매 always ask "what is this *not*?" before "what is this?".
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Philosophy of Language]] · [[Semiotics]] · [[Linguistics]]
|
||||
- 변형: [[Post-structuralism]] · [[Deconstruction]] · [[Distributional Semantics]]
|
||||
- 응용: [[Word Embeddings]] · [[Knowledge Representation]] · [[Software Architecture]]
|
||||
- Adjacent: [[Saussure]] · [[Lévi-Strauss]] · [[Barthes]] · [[Set Theory]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 meaning analysis, 매 cultural decoding, 매 embedding interpretation, 매 dependency graph reasoning.
|
||||
**언제 X**: 매 essentialist questions ("what is the *true* nature of X?") — 매 structuralism 은 reject 함.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Essentialism**: 매 "X has an inherent meaning" — 매 structuralism rejects this.
|
||||
- **Static langue**: 매 langue 를 fixed 로 보면 변화하는 system 을 놓침.
|
||||
- **Over-binarization**: 매 모든 것을 binary opposition 으로 환원하면 nuance 손실.
|
||||
- **Ignoring parole**: 매 actual usage data 무시하면 model 이 stale.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Saussure 1916, Lévi-Strauss 1958, Barthes 1957).
|
||||
- 신뢰도 A (foundational philosophical canon).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Saussure 4대 원칙, NLP embedding 연결, 6 패턴 |
|
||||
|
||||
@@ -2,69 +2,177 @@
|
||||
id: wiki-2026-0508-problem-solving-process
|
||||
title: Problem Solving Process
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Problem Solving, Polya Method, Engineering Problem Solving]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [cognition, engineering, methodology, debugging]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: multi
|
||||
framework: structured-problem-solving
|
||||
---
|
||||
|
||||
# [[Problem Solving Process|Problem Solving Process]]
|
||||
# Problem Solving Process
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
문제를 명확히 정의하고, 근본 원인을 찾아내어, 실행 가능한 해결책을 도출하기까지의 순차적이고 체계적인 분석 단계입니다.
|
||||
## 매 한 줄
|
||||
> **"매 a problem well-stated is half-solved."**. 매 Polya 1945 *How to Solve It* 의 4단계 (understand → plan → carry out → look back) 가 매 modern engineering, debugging, AI agent design 의 backbone. 매 2026 LLM agent (Claude, OpenAI Operator) 의 ReAct/CoT 도 매 본질적으로 Polya 의 자동화.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- 바바라 민토(Barbara Minto)는 문제 해결 과정을 **5가지 순차적 질문(Sequential [[Analysis|Analysis]])**으로 정의했습니다 [11, 12].
|
||||
1. **문제가 무엇인가? (What is the problem?)**
|
||||
2. **어디에 문제가 있는가? (Where does it lie?)**
|
||||
3. **왜 존재하는가? (Why does it exist?)**
|
||||
4. **무엇을 할 수 있는가? (What could we do about it?)**
|
||||
5. **무엇을 해야 하는가? (What should we do about it?)**
|
||||
- 문제를 올바르게 해결하기 위해서는 **현재 상태와 목표 상태 간의 갭(Gap)**, 문제를 발생시킨 상황의 구조, 기저 프로세스, 대안적 구조 변경 방법, 그리고 변경 시 요구되는 사항들을 명확히 정의해야 합니다 [11, 13].
|
||||
- 이 과정에서 문제의 부분들을 식별하여 순차적으로 배열하고, 투입(Inputs)과 산출(Outputs)을 명확하게 보여줄 수 있어야 프로세스를 완벽히 이해한 것입니다 [11, 13].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Problem Solving|Problem Solving]], [[Pyramid Principle|Pyramid Principle]]
|
||||
- **Projects/Contexts:** 문제 해결 워크숍, 컨설팅 프로젝트 가설 수립
|
||||
- **Contradictions/Notes:** 구조가 없는 상황(Structureless situations)에서는 연역, 귀납, 그리고 가추법(Abduction)을 혼합하여 가설을 세우고 실험을 통해 기저 구조를 파악해 나가는 과학적 추론 방식이 필요합니다 [14].
|
||||
### 매 Polya 4 stages
|
||||
- **Understand**: 매 restate, 매 identify knowns/unknowns/constraints.
|
||||
- **Plan**: 매 decompose, 매 analogous problems, 매 work backwards.
|
||||
- **Carry Out**: 매 execute, 매 verify each step.
|
||||
- **Look Back**: 매 check, 매 generalize, 매 alternate methods.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 strategies
|
||||
- **Decomposition**: 매 break into sub-problems (divide & conquer).
|
||||
- **Analogy**: 매 find similar solved problem (case-based reasoning).
|
||||
- **Inversion**: 매 work backwards from goal.
|
||||
- **Specialization**: 매 try simpler instance (n=1, n=2 first).
|
||||
- **Generalization**: 매 solve more general version sometimes easier.
|
||||
- **Symmetry / Invariants**: 매 find quantity that doesn't change.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Debugging: 매 reproduce → bisect → fix → verify → write test.
|
||||
2. System design: 매 understand requirements → decompose → component design.
|
||||
3. LLM agent: 매 ReAct loop = Polya in code.
|
||||
4. Math/algorithms: 매 examples → conjecture → prove → optimize.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Debugging as Polya
|
||||
```python
|
||||
def debug(bug_report):
|
||||
# 1. UNDERSTAND
|
||||
repro = build_minimal_repro(bug_report)
|
||||
# 2. PLAN
|
||||
suspected_modules = trace_stack(repro)
|
||||
plan = git_bisect_plan(repro, suspected_modules)
|
||||
# 3. CARRY OUT
|
||||
bad_commit = git_bisect(plan)
|
||||
fix = author_fix(bad_commit)
|
||||
# 4. LOOK BACK
|
||||
add_regression_test(repro)
|
||||
update_runbook(bug_report.symptom)
|
||||
return fix
|
||||
```
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
### Pattern 2: ReAct LLM agent (Polya 자동화)
|
||||
```python
|
||||
SYSTEM = """For each task, follow:
|
||||
1. THOUGHT: restate the problem and constraints (UNDERSTAND).
|
||||
2. PLAN: decompose into 1-3 next actions.
|
||||
3. ACTION: call exactly one tool.
|
||||
4. OBSERVE: read result.
|
||||
5. REFLECT: did this advance? if not, revise plan (LOOK BACK).
|
||||
Repeat until done.
|
||||
"""
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 3: Decomposition tree
|
||||
```python
|
||||
@dataclass
|
||||
class Problem:
|
||||
statement: str
|
||||
children: list["Problem"] = field(default_factory=list)
|
||||
solved: bool = False
|
||||
solution: Optional[str] = None
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
def solve(p: Problem):
|
||||
if can_solve_directly(p):
|
||||
p.solution = direct(p); p.solved = True; return
|
||||
p.children = decompose(p)
|
||||
for c in p.children: solve(c)
|
||||
p.solution = combine([c.solution for c in p.children])
|
||||
p.solved = all(c.solved for c in p.children)
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Pattern 4: Five-Whys root cause
|
||||
```text
|
||||
Symptom: 매 dashboard p99 latency 5x baseline.
|
||||
Why? — 매 DB queries slow.
|
||||
Why? — 매 missing index.
|
||||
Why? — 매 migration didn't add it.
|
||||
Why? — 매 PR template doesn't require index check.
|
||||
Why? — 매 no automated linter.
|
||||
→ 매 Root: missing tooling, not "lazy engineer".
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### Pattern 5: Pre-mortem (inverted planning)
|
||||
```python
|
||||
def pre_mortem(plan):
|
||||
# 매 imagine the plan failed in 6 months
|
||||
# 매 ask team: what went wrong?
|
||||
failure_modes = team_brainstorm("It's 6mo from now. Project failed. Why?")
|
||||
return prioritize_mitigations(failure_modes)
|
||||
```
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
### Pattern 6: Working-memory checkpoint
|
||||
```markdown
|
||||
<!-- 매 problem_log.md while solving -->
|
||||
## 매 KNOWN
|
||||
- API returns 500 on POST /orders > 1000 items.
|
||||
## 매 UNKNOWN
|
||||
- Is it timeout, memory, or DB lock?
|
||||
## 매 TRIED
|
||||
- [x] Reproduce locally → reproduces at 1500.
|
||||
- [x] Add timing logs → DB INSERT is slow.
|
||||
- [ ] Check lock contention.
|
||||
## 매 NEXT
|
||||
- pg_stat_activity during repro.
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 7: Solution generalization (look back)
|
||||
```python
|
||||
# 매 after fixing one instance — 매 ask: where else does this pattern occur?
|
||||
def generalize(fix):
|
||||
pattern = abstract(fix) # e.g., "missing pagination in list endpoints"
|
||||
similar = scan_codebase_for(pattern)
|
||||
return apply_fix_to_all(similar)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Strategy |
|
||||
|---|---|
|
||||
| 매 stuck at "understand" | Restate problem to rubber duck / LLM |
|
||||
| 매 plan unclear | Try simpler case (n=1) first |
|
||||
| 매 carry-out fails | Bisect; isolate variable |
|
||||
| 매 done — but is it right? | Look back; alt method; edge cases |
|
||||
| 매 recurring class of bugs | Generalize the fix; tooling |
|
||||
| 매 LLM agent loop stuck | Force REFLECT step; reduce action set |
|
||||
|
||||
**기본값**: 매 always do Look Back — 매 most engineers skip it; 매 90% of compounding leverage lives there.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Cognitive Psychology]] · [[Engineering Methodology]]
|
||||
- 변형: [[Polya Method]] · [[Debugging]] · [[Root Cause Analysis]]
|
||||
- 응용: [[LLM Agent Design]] · [[Incident Response]] · [[System Design Interview]]
|
||||
- Adjacent: [[Five-Whys]] · [[Pre-Mortem]] · [[ReAct]] · [[Chain of Thought]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 system-prompt scaffolds, 매 incident runbooks, 매 onboarding docs, 매 interview prep.
|
||||
**언제 X**: 매 trivial 1-line tasks — 매 over-formalization slows.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Skip understanding**: 매 jump to coding → 매 wrong problem solved.
|
||||
- **Skip looking back**: 매 ship fix, never abstract → 매 same bug class returns.
|
||||
- **No working-memory log**: 매 forget what you tried.
|
||||
- **One strategy only**: 매 if decomposition fails, try inversion / analogy.
|
||||
- **LLM as oracle**: 매 use as plan-critic, not plan-author.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Polya 1945, Newell & Simon 1972, Yao et al. 2022 ReAct).
|
||||
- 신뢰도 A (foundational).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Polya 4단계 + ReAct + 7 패턴 |
|
||||
|
||||
@@ -2,109 +2,166 @@
|
||||
id: wiki-2026-0508-program-comprehension-strategies
|
||||
title: Program Comprehension Strategies
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Code Reading, Code Comprehension, Mental Models of Code]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [software-engineering, cognition, code-review, onboarding]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: multi
|
||||
framework: cognitive-software-engineering
|
||||
---
|
||||
|
||||
# Program Comprehension Strategies (프로그램 이해 전략)
|
||||
# Program Comprehension Strategies
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프로그램 이해 전략(Program Comprehension Strategies)은 개발자가 기존 소스 코드를 유지보수하거나 확장하기 위해 코드를 읽고 그 논리적 구조와 설계 의도를 파악하는 인지적 과정(Cognitive Process)을 정의한 방법론입니다 [1-3]. 이 과정은 단순히 구문을 읽는 행위를 넘어, 코드라는 외부 표현을 개발자의 내면화된 '정신 모델(Mental Model)'로 매핑하는 고도의 지적 활동입니다 [1, 4]. 개발자는 코드의 익숙함과 전문성에 따라 하향식(Top-Down), 상향식(Bottom-Up), 그리고 이들을 유연하게 혼합한 통합적/기회주의적(Opportunistic) 전략을 선택적으로 사용합니다 [6-9].
|
||||
## 매 한 줄
|
||||
> **"매 90% of programming is reading code, not writing it."**. 매 Brooks (1983), Pennington (1987), Soloway (1986) 의 cognitive software engineering 연구에서 출발한 매 분야 — 매 code → mental model 변환의 strategies. 매 2026 LLM 시대에는 매 Cursor/Claude Code 의 contextual indexing 이 매 human comprehension 을 augment.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
프로그램 이해 모델은 개발자가 코드에서 '무엇(What)', '어떻게(How)', '왜(Why)'를 추출하는 방식을 체계화한 3대 핵심 프레임워크로 구성됩니다.
|
||||
## 매 핵심
|
||||
|
||||
* **하향식 이해 모델 (Top-Down Models - Brooks, Soloway & Ehrlich):**
|
||||
* **전제 조건:** 개발자가 시스템 아키텍처나 도메인 지식에 익숙할 때 주로 사용합니다 [19-21].
|
||||
* **메커니즘:** 시스템의 전체 목적에 대한 가설(Hypothesis)을 먼저 세우고, 코드 내에서 이를 뒷받침하는 단서인 '비컨(Beacons)'과 전형적인 구조인 '프로그래밍 계획(Programming Plans)'을 찾아 가설을 검증하며 하위 수준으로 구체화합니다 [21-23].
|
||||
* **상향식 이해 모델 (Bottom-Up Models - Pennington, Shneiderman):**
|
||||
* **전제 조건:** 코드가 낯설거나 새로운 언어/프레임워크를 접할 때 사용합니다 [24, 25].
|
||||
* **메커니즘:** 개별 구문과 제어 흐름(마이크로 구조)을 먼저 읽어 '프로그램 모델(Program Model)'을 구축한 후, 이를 기능적 의미가 담긴 '상황 모델(Situation Model)'로 '청킹(Chunking)'하여 상향식으로 결합합니다 [25-28].
|
||||
* **통합 및 기회주의적 전략 (Integrated/Opportunistic Models - Letovsky, Mayrhauser & Vans):**
|
||||
* **전제 조건:** 실제 복잡한 대규모 레거시 시스템 유지보수 환경에서 사용됩니다 [29-31].
|
||||
* **메커니즘:** 개발자는 고정된 방향 없이 가설 검증과 세부 구현 파악을 수시로 오가며(Cross-referencing), 필요한 정보만 발췌하여 이해를 확장합니다 [30-32]. 이는 인지 부하를 최소화하면서 당면한 과제(Task-relevant)를 해결하는 데 최적화된 방식입니다.
|
||||
### 매 3대 strategy
|
||||
- **Top-down (Brooks)**: 매 hypothesis 형성 → code 로 verify. 매 domain expert 가 사용.
|
||||
- **Bottom-up (Pennington)**: 매 statement → control-flow → data-flow → program model. 매 novice 가 사용.
|
||||
- **Opportunistic (mixed)**: 매 expert programmer 의 실제 행동 — top-down 시작, beacon 발견 시 bottom-up 으로 dive.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **효율성 vs 정확성의 딜레마:** 하향식 전략은 아키텍처를 빠르게 파악할 수 있으나, '확증 편향'으로 인해 비전형적인(Unplan-like) 코드에서 발생하는 미세한 버그나 보안 취약점을 간과할 위험이 큽니다 [6, 11]. 반대로 상향식은 정확도가 높지만, 막대한 인지 부하를 유발하며 전체 맥락(Big Picture)을 놓칠 수 있습니다 [6].
|
||||
* **비전형적 코드(Unplan-like)의 위험:** 코드가 관례를 벗어나거나 독창적이지만 가독성이 낮은 구조로 작성된 경우, 전문가의 하향식 가설 검증이 실패(Dangling Purpose)하게 되어 인지 비용이 기하급수적으로 증가합니다 [18, 38].
|
||||
* **단일 진입점 부재:** 현대의 이벤트 기반 아키텍처나 마이크로서비스에서는 전통적인 `main()` 함수와 같은 명확한 이해의 출발점이 부재하여, 기회주의적 전략에 의존해야 하며 이로 인해 멘탈 모델이 파편화될 위험이 상존합니다 [6, 39].
|
||||
### 매 cognitive constructs
|
||||
- **Beacons**: 매 recognizable patterns (e.g., `for(i=0; i<n; i++)` → 매 loop, `swap(a,b)` → 매 sort).
|
||||
- **Plans**: 매 stereotypical solutions (e.g., search plan, accumulator plan).
|
||||
- **Chunks**: 매 functionally cohesive code groups stored as 1 unit in working memory.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
- [[Cognitive Load & Mental Models]]: 프로그램 이해 과정에서 발생하는 인지적 병목과 청킹 메커니즘을 다룹니다.
|
||||
- Beacons & Programming Plans: 하향식 가설 생성을 돕는 코드 내 단서와 전형적인 패턴에 대한 상세입니다.
|
||||
- Clean Architecture vs Traceable Code: 인지 부하를 줄이기 위한 설계적 선택과 추적 가능성 사이의 균형을 논의합니다.
|
||||
### 매 응용
|
||||
1. Code review: 매 reviewer 는 top-down — PR 의 의도 파악 후 specific changes 검증.
|
||||
2. Onboarding: 매 new dev 는 bottom-up — small fixes 로 시작, 점진적 chunking.
|
||||
3. AI-assisted reading: 매 LLM 에게 code summarization → human 이 hypothesis 생성.
|
||||
|
||||
### Deeper Research Questions
|
||||
- 대규모 분산 아키텍처 환경에서 고전적 이해 모델(Brooks, Pennington)의 한계를 보완하기 위한 현대적 인지 보조 도구는 무엇인가?
|
||||
- 비전형적 코드를 마주했을 때 발생하는 '인지적 불일치'를 정적 분석 도구와 AI 어시스턴트로 어떻게 해소할 수 있는가?
|
||||
- '상황 모델(의도)'과 '프로그램 모델(구현)' 사이의 괴리를 코드 리뷰 과정에서 시스템적으로 감지하는 방법은?
|
||||
## 💻 패턴
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 명확한 함수명과 디자인 패턴을 '비컨'으로 제공하여 동료의 가설 검증 비용을 줄여야 합니다 [18, 38].
|
||||
- **Maintenance:** 무작정 코드를 읽기보다 Git 히스토리와 PR 논의(Context)를 먼저 파악하여 하향식 가설을 먼저 세우는 것이 효율적입니다 [47, 48].
|
||||
- **Onboarding:** 신규 입사자에게 비즈니스 도메인(Situation Model)을 먼저 교육한 후, 실제 구현부(Program Model)로 안내하는 하향식 지식 전달이 효과적입니다 [25, 27].
|
||||
### Pattern 1: Top-down hypothesis-driven reading
|
||||
```python
|
||||
# 매 step 1: read README / docstring → 매 form hypothesis
|
||||
# 매 step 2: locate entry point (main, app.py)
|
||||
# 매 step 3: trace only the path that confirms/refutes hypothesis
|
||||
|
||||
---
|
||||
*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
|
||||
def trace_hypothesis(repo, hypothesis):
|
||||
entry = find_entry_point(repo)
|
||||
call_graph = build_call_graph(entry)
|
||||
relevant = filter_by_keyword(call_graph, hypothesis.keywords)
|
||||
return relevant
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: Beacon recognition (LLM-augmented)
|
||||
```python
|
||||
import anthropic
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def extract_beacons(code: str) -> list[str]:
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=1024,
|
||||
system="Identify recognizable code patterns (beacons) and name their plan.",
|
||||
messages=[{"role": "user", "content": f"```\n{code}\n```"}],
|
||||
)
|
||||
return parse_beacons(resp.content[0].text)
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Chunking via cohesion analysis
|
||||
```python
|
||||
def chunk_function(ast_node):
|
||||
"""매 group statements by 매 shared variables (cohesion)."""
|
||||
chunks, current = [], []
|
||||
last_vars = set()
|
||||
for stmt in ast_node.body:
|
||||
vars = extract_vars(stmt)
|
||||
if last_vars and not (vars & last_vars):
|
||||
chunks.append(current)
|
||||
current = []
|
||||
current.append(stmt)
|
||||
last_vars = vars
|
||||
if current:
|
||||
chunks.append(current)
|
||||
return chunks
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 4: Cross-reference walking (bottom-up)
|
||||
```bash
|
||||
# 매 ripgrep + ctags-driven exploration
|
||||
rg -l "AuthService" --type ts | head -5
|
||||
rg "class AuthService" --type ts -A 30
|
||||
rg "new AuthService\(" --type ts # 매 callers
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 5: LLM-driven code summarization
|
||||
```python
|
||||
# 매 Claude Code-style structured summary
|
||||
PROMPT = """Summarize this file with:
|
||||
1. 매 PURPOSE (1 sentence)
|
||||
2. 매 KEY DATA STRUCTURES
|
||||
3. 매 PUBLIC API
|
||||
4. 매 NON-OBVIOUS CONTRACTS / INVARIANTS
|
||||
5. 매 DEPENDENCIES (incoming + outgoing)
|
||||
"""
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
def summarize(file_path):
|
||||
code = open(file_path).read()
|
||||
return claude_call(PROMPT + f"\n```\n{code}\n```")
|
||||
```
|
||||
|
||||
### Pattern 6: Mental model checkpointing
|
||||
```markdown
|
||||
<!-- 매 personal-notes.md per repo while reading -->
|
||||
## Module: auth/
|
||||
- Purpose: JWT issuance & verification
|
||||
- Entry: `auth/router.ts:loginHandler`
|
||||
- Key invariant: tokens always include `iss=our-domain`
|
||||
- Open Q: where is refresh-token rotation?
|
||||
```
|
||||
|
||||
### Pattern 7: Diagram-first — produce dependency graph before reading
|
||||
```bash
|
||||
madge --image deps.svg src/
|
||||
# 매 visual chunking — see clusters before diving
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Strategy |
|
||||
|---|---|
|
||||
| 매 domain familiar, code new | Top-down |
|
||||
| 매 domain new, code small | Bottom-up |
|
||||
| 매 large unknown codebase | Opportunistic + diagram first |
|
||||
| 매 bug hunt | Bottom-up from stack trace |
|
||||
| 매 architecture review | Top-down from entry points |
|
||||
| 매 LLM augmentation | Summarize → form hypothesis → verify |
|
||||
|
||||
**기본값**: 매 opportunistic — 매 README + entry point 부터 시작, beacon 발견 시 dive.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software Engineering]] · [[Cognitive Psychology]]
|
||||
- 변형: [[Code Review]] · [[Onboarding]]
|
||||
- 응용: [[Refactoring]] · [[Bug Localization]] · [[LLM-assisted Coding]]
|
||||
- Adjacent: [[Mental Models]] · [[Working Memory]] · [[AST]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 onboarding new repo, 매 reviewing large PR, 매 understanding legacy code, 매 building mental model.
|
||||
**언제 X**: 매 1-line hot-fix 에 over-engineering 하지 마라.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Read everything linearly**: 매 working memory 초과 — chunking 없이 무너짐.
|
||||
- **Skip the README**: 매 hypothesis 없이 bottom-up 만 → 매 lost in details.
|
||||
- **No checkpointing**: 매 1시간 후 모두 잊음 — write down mental model.
|
||||
- **Trust LLM summary blindly**: 매 hallucination 위험 — 매 verify on key claims.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Brooks 1983, Pennington 1987, Soloway & Ehrlich 1984, Storey 2006 review).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — top-down/bottom-up/opportunistic + LLM augmentation |
|
||||
|
||||
@@ -1,122 +1,219 @@
|
||||
---
|
||||
id: wiki-2026-0508-progressive-web-apps-pwas
|
||||
title: Progressive Web Apps PWAs
|
||||
title: Progressive Web Apps (PWAs)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [PWA, Installable Web Apps, Web App Manifest Apps]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [web, frontend, mobile, service-worker, offline-first]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: javascript
|
||||
framework: web-platform
|
||||
---
|
||||
|
||||
# Progressive Web Apps (PWAs)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
프로그레시브 웹 앱(PWA)은 전통적인 네이티브 앱을 대체할 수 있는 비용 효율적이고 성능이 뛰어난 웹 애플리케이션 아키텍처이다 [1]. Google, Apple, Microsoft 등 주요 기술 기업들의 표준 지원에 힘입어 주류 개발 트렌드로 자리 잡았다 [1]. 단일 코드베이스를 통해 다양한 플랫폼에서 실행되며, 오프라인 환경에서도 네이티브 앱과 유사한 강력한 사용자 경험을 제공하는 것이 특징이다 [1].
|
||||
## 매 한 줄
|
||||
> **"매 the web with installability, offline, and push — without the app store tax."**. 매 Alex Russell 이 2015년 정립한 PWA 는 매 service worker + manifest + HTTPS 의 조합으로 매 web app 을 매 native-feel 으로 격상. 매 2026: iOS 17+/Safari 17+ 가 push notifications 와 매 home-screen install 을 정식 지원, 매 Project Fugu API 들 (file system, USB, Bluetooth) 까지 가능.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **빠른 로딩 및 이탈률 감소:** 기존 모바일 웹사이트와 비교하여 페이지 로딩 시간을 크게 단축시키며, 사용자의 이탈률(Bounce rates)을 최대 42%까지 감소시킬 수 있다 [1].
|
||||
* **오프라인 환경 지원:** 서비스 워커(Service workers) 기술을 활용하여 인터넷 연결이 불안정하거나 완전히 끊긴 상황에서도 애플리케이션이 정상적으로 작동하도록 지원한다 [1].
|
||||
* **개발 및 운영 비용 절감:** iOS와 Android용 네이티브 앱을 별도로 구축할 필요 없이 단일 PWA만 배포하면 되므로, 개발 비용을 30~50%가량 절감할 수 있다 [1].
|
||||
* **경량화 및 비즈니스 성과 향상 사례:** 스타벅스(Starbucks)는 PWA를 도입하여 기존 148MB에 달하던 모바일 앱의 용량을 1MB 미만으로 대폭 줄였으며(99.84% 감소), 동시에 일일 활성 사용자 수를 두 배로 늘리는 성과를 달성했다 [1].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
PWA는 오프라인 지원, 비용 절감, 용량 경량화 등 강력한 장점을 제공하지만, 완성된 애플리케이션을 기존 앱 스토어에 출시(Publishing)하는 과정에서 특정한 한계(limits)와 고려해야 할 배포 옵션들이 존재할 수 있다 [2]. 이 외에 PWA와 관련된 구체적인 기술적 부작용, 제약 사항 및 기타 성능적 반대 급부(Trade-off)에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
### 매 3 pillars
|
||||
- **Service Worker**: 매 background script — 매 caching, 매 offline, 매 push.
|
||||
- **Web App Manifest**: 매 JSON — 매 install metadata (icon, name, display).
|
||||
- **HTTPS**: 매 mandatory transport (loopback exception for dev).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
### 매 capabilities (2026)
|
||||
- 매 offline first via Cache + IndexedDB.
|
||||
- 매 background sync (eventual consistency).
|
||||
- 매 push notifications (iOS 17+ supports).
|
||||
- 매 file system access (Origin Private File System, OPFS).
|
||||
- 매 share target (receive shares from native).
|
||||
- 매 periodic background sync.
|
||||
- 매 WebGPU / WebTransport / WebCodecs.
|
||||
|
||||
#### [관계 유형 A: 아키텍처/기반 기술]
|
||||
- [[Service Workers]]
|
||||
- 연결 이유: 인터넷 연결 없이도 PWA가 오프라인에서 동작할 수 있게 해주는 핵심 기반 기술이다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 웹 브라우저의 백그라운드 환경에서 오프라인 데이터 캐싱과 리소스 처리를 통해 네이티브 앱과 유사한 환경을 구현하는 원리 [1].
|
||||
### 매 응용
|
||||
1. Twitter, Pinterest, Starbucks Lite — 매 60-80% bundle reduction.
|
||||
2. 매 conference apps — 매 offline schedule + push.
|
||||
3. 매 internal enterprise tools — 매 install via QR, no MDM.
|
||||
4. 매 emerging-market apps — 매 low-bandwidth-friendly.
|
||||
|
||||
#### [관계 유형 B: 구현/비교 대상]
|
||||
- [[Native Apps]]
|
||||
- 연결 이유: PWA가 기술적으로 대체하고자 하는 전통적인 플랫폼 종속적 모바일 애플리케이션 모델이다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 다중 코드베이스를 유지해야 하는 네이티브 앱 대비 단일 코드베이스를 사용하는 PWA가 제공하는 30~50%의 비용 절감 메커니즘 [1].
|
||||
## 💻 패턴
|
||||
|
||||
- [[Cross-Platform Development]]
|
||||
- 연결 이유: 단일 코드베이스로 다중 운영체제를 지원하여 배포 시간과 비용을 줄인다는 점에서 PWA와 개발 목표를 공유하는 접근 방식이다 [1, 3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 웹 표준 기반의 PWA 생태계와 Flutter나 React Native와 같은 프레임워크 기반 크로스 플랫폼 개발 방식 간의 전략적 차이 [1, 3].
|
||||
|
||||
### Deeper Research Questions
|
||||
- PWA의 서비스 워커를 통한 데이터 캐싱은 복잡한 동적 데이터를 실시간으로 처리할 때 어떠한 기술적 한계와 오버헤드를 가지는가?
|
||||
- 애플리케이션을 Apple App Store나 Google Play와 같은 기존 앱 스토어에 PWA 형태로 등록하여 배포할 때 발생하는 구체적인 제약 사항(Limits)과 우회 전략은 무엇인가?
|
||||
- 단일 코드베이스를 사용하는 PWA가 React Native 및 Flutter와 같은 크로스 플랫폼 프레임워크와 비교했을 때, 디바이스의 네이티브 하드웨어 API(카메라, 센서, 블루투스 등)에 접근하는 권한과 성능 차이는 어떠한가?
|
||||
- 스타벅스 사례처럼 148MB의 네이티브 앱을 1MB 이하의 PWA로 경량화하는 아키텍처 개편 과정에서 웹 기술로 완전히 대체할 수 없어 포기해야 했던 기능적 트레이드오프는 무엇이었는가?
|
||||
- PWA의 오프라인 지원 아키텍처를 탈중앙화 애플리케이션(dApps) 및 Web3 환경과 결합했을 때 얻을 수 있는 시스템적 시너지 및 보안 취약점은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 웹 프로젝트에 서비스 워커를 등록하여 오프라인 캐싱 로직을 구현하고, 네트워크 단절 상황에서도 화면이 렌더링되도록 코드를 작성한다 [1].
|
||||
- **System Design:** iOS, Android, 웹 환경을 별도의 인프라로 설계하지 않고, 단일 코드베이스 기반의 PWA 배포 파이프라인 하나로 아키텍처를 통합하여 복잡성을 줄인다 [1].
|
||||
- **Operation / Maintenance:** 네이티브 앱 버전 파편화로 인한 운영 부담을 줄이고, 단일 웹 스택을 유지보수하여 전체 운영 및 개발 비용을 30~50% 감축한다 [1].
|
||||
- **Learning Path:** PWA 표준 규격, 오프라인 데이터 캐싱, 그리고 반응형 모바일 UI 디자인을 학습하여 기존 웹사이트를 고성능 앱 환경으로 전환하는 기술 역량을 강화한다 [1].
|
||||
- **My Project Relevance:** 모바일 앱 개발에 한정된 예산과 짧은 기간(Time-to-market)이 주어졌을 때, 비용 효율적으로 네이티브 수준의 사용자 경험을 제공하기 위한 최우선 모바일 전략으로 PWA를 채택한다 [1].
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Cloud Native & Microservices Architectures]]
|
||||
- 확장 방향: 프론트엔드를 PWA로 경량화하는 전략과 연계하여, 백엔드 역시 마이크로서비스 및 서버리스 컴퓨팅(Serverless computing)을 도입하여 시스템 전체의 확장성과 로딩 성능을 최적화하는 아키텍처 연구로 확장 [4].
|
||||
- [[No Code & Low Code Development]]
|
||||
- 확장 방향: 제품 출시 주기 단축 및 개발 비용 절감이라는 PWA의 장점과 맞물려, 전문 지식 없이 애플리케이션을 빠르게 배포하기 위한 노코드/로우코드 플랫폼과의 결합 시나리오로 확장 [1, 5].
|
||||
|
||||
---
|
||||
*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
|
||||
### Pattern 1: Minimal manifest.json
|
||||
```json
|
||||
{
|
||||
"name": "Wiki Cleanup Tool",
|
||||
"short_name": "WikiClean",
|
||||
"start_url": "/",
|
||||
"display": "standalone",
|
||||
"background_color": "#ffffff",
|
||||
"theme_color": "#0066cc",
|
||||
"icons": [
|
||||
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
|
||||
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any maskable" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: Service worker (cache-first for assets, network-first for API)
|
||||
```javascript
|
||||
// sw.js
|
||||
const CACHE = 'app-v3';
|
||||
const ASSETS = ['/', '/index.html', '/app.js', '/styles.css'];
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
self.addEventListener('install', (e) => {
|
||||
e.waitUntil(caches.open(CACHE).then((c) => c.addAll(ASSETS)));
|
||||
});
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
self.addEventListener('activate', (e) => {
|
||||
e.waitUntil(caches.keys().then((keys) =>
|
||||
Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)))
|
||||
));
|
||||
});
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
self.addEventListener('fetch', (e) => {
|
||||
const url = new URL(e.request.url);
|
||||
if (url.pathname.startsWith('/api/')) {
|
||||
// network-first
|
||||
e.respondWith(fetch(e.request).catch(() => caches.match(e.request)));
|
||||
} else {
|
||||
// cache-first
|
||||
e.respondWith(caches.match(e.request).then((r) => r || fetch(e.request)));
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 3: Registration with update flow
|
||||
```javascript
|
||||
// app.js
|
||||
if ('serviceWorker' in navigator) {
|
||||
navigator.serviceWorker.register('/sw.js').then((reg) => {
|
||||
reg.addEventListener('updatefound', () => {
|
||||
const sw = reg.installing;
|
||||
sw.addEventListener('statechange', () => {
|
||||
if (sw.state === 'installed' && navigator.serviceWorker.controller) {
|
||||
showUpdateToast(() => sw.postMessage({ type: 'SKIP_WAITING' }));
|
||||
}
|
||||
});
|
||||
});
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 4: Push notifications (2026 cross-platform)
|
||||
```javascript
|
||||
async function subscribe() {
|
||||
const reg = await navigator.serviceWorker.ready;
|
||||
const sub = await reg.pushManager.subscribe({
|
||||
userVisibleOnly: true,
|
||||
applicationServerKey: VAPID_PUBLIC_KEY,
|
||||
});
|
||||
await fetch('/api/save-sub', { method: 'POST', body: JSON.stringify(sub) });
|
||||
}
|
||||
|
||||
// sw.js
|
||||
self.addEventListener('push', (e) => {
|
||||
const { title, body, url } = e.data.json();
|
||||
e.waitUntil(self.registration.showNotification(title, { body, data: { url } }));
|
||||
});
|
||||
self.addEventListener('notificationclick', (e) => {
|
||||
e.notification.close();
|
||||
e.waitUntil(clients.openWindow(e.notification.data.url));
|
||||
});
|
||||
```
|
||||
|
||||
### Pattern 5: Background sync for offline writes
|
||||
```javascript
|
||||
// queue write when offline
|
||||
async function postWithSync(url, payload) {
|
||||
try {
|
||||
return await fetch(url, { method: 'POST', body: JSON.stringify(payload) });
|
||||
} catch {
|
||||
const reg = await navigator.serviceWorker.ready;
|
||||
await idbAdd('outbox', { url, payload });
|
||||
await reg.sync.register('flush-outbox');
|
||||
}
|
||||
}
|
||||
|
||||
// sw.js
|
||||
self.addEventListener('sync', (e) => {
|
||||
if (e.tag === 'flush-outbox') e.waitUntil(flushOutbox());
|
||||
});
|
||||
```
|
||||
|
||||
### Pattern 6: File System Access (2026 Fugu)
|
||||
```javascript
|
||||
async function saveDoc(content) {
|
||||
const handle = await window.showSaveFilePicker({
|
||||
types: [{ description: 'Markdown', accept: { 'text/markdown': ['.md'] } }],
|
||||
});
|
||||
const writable = await handle.createWritable();
|
||||
await writable.write(content);
|
||||
await writable.close();
|
||||
}
|
||||
```
|
||||
|
||||
### Pattern 7: Install prompt UX
|
||||
```javascript
|
||||
let deferred;
|
||||
window.addEventListener('beforeinstallprompt', (e) => {
|
||||
e.preventDefault();
|
||||
deferred = e;
|
||||
showCustomInstallButton();
|
||||
});
|
||||
|
||||
async function onInstallClick() {
|
||||
if (!deferred) return;
|
||||
deferred.prompt();
|
||||
const { outcome } = await deferred.userChoice;
|
||||
analytics.track('pwa_install', { outcome });
|
||||
deferred = null;
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 content-heavy site | PWA, no native |
|
||||
| 매 needs deep OS integration (BLE, NFC, telephony) | Native + Capacitor / native shell |
|
||||
| 매 cross-platform productivity | PWA with Fugu APIs |
|
||||
| 매 emerging-market reach | PWA — 매 small bundle, offline |
|
||||
| 매 game (heavy GPU) | Native or WebGPU PWA |
|
||||
| 매 enterprise behind SSO | PWA — 매 no app store distribution |
|
||||
|
||||
**기본값**: 매 start with PWA, 매 fall back to native shell only when blocked APIs needed.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Web Platform]] · [[Frontend Architecture]]
|
||||
- 변형: [[Service Worker]] · [[Web App Manifest]] · [[Project Fugu]]
|
||||
- 응용: [[Offline-First]] · [[Push Notifications]] · [[Installable Web]]
|
||||
- Adjacent: [[IndexedDB]] · [[Cache API]] · [[WebGPU]] · [[Workbox]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 caching strategy design, 매 SW boilerplate, 매 update-flow patterns.
|
||||
**언제 X**: 매 native-only API needs (full BLE stack, deep telephony) — 매 use Capacitor / native.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Cache-everything**: 매 stale stale stale — 매 use versioned cache + activate cleanup.
|
||||
- **No update flow**: 매 user stuck on old SW forever.
|
||||
- **HTTPS skipped in staging**: 매 SW won't register — 매 broken parity.
|
||||
- **Manifest without maskable icons**: 매 ugly cropped icons on Android adaptive.
|
||||
- **Push spam**: 매 user opt-out + iOS revoke + reputation damage.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (W3C Service Worker spec, Web App Manifest spec, web.dev/learn/pwa).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 3 pillars, 7 패턴, 2026 Fugu/iOS push 반영 |
|
||||
|
||||
@@ -2,91 +2,180 @@
|
||||
id: wiki-2026-0508-protocols
|
||||
title: Protocols
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PROT-001]
|
||||
aliases: [Communication Protocols, Network Protocols, Wire Protocols]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, protocols, communication-standard, networking, rules, InterOperability]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [networking, protocols, systems, MCP]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: multi
|
||||
framework: HTTP-gRPC-MCP
|
||||
---
|
||||
|
||||
# [[Protocols|Protocols]]
|
||||
# Protocols
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "디지털 사회의 약속: 수많은 기기와 시스템이 서로 '외계어'를 주고받지 않고 정확히 소통할 수 있도록 만들어진 엄격한 대화의 규칙이자, 복잡한 네트워크를 지탱하는 질서의 뼈대."
|
||||
## 매 한 줄
|
||||
> **"매 communicating parties 가 매 따라야 하는 rules 의 명시"**. 매 syntax (frame format), 매 semantics (meaning of fields), 매 timing (sequencing) 의 3 axes 로 정의. 매 2026 의 hot stack: HTTP/3 (QUIC), gRPC, MCP (Model Context Protocol), WebSocket, MQTT 5.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
프로토콜(Protocols)은 컴퓨터나 기기 간의 데이터 통신을 위해 정의된 규약입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 핵심 기능**:
|
||||
* **Addressing**: 누구에게 보낼 것인가? (정확한 수신처 식별).
|
||||
* **Handshaking**: 연결해도 되는가? (상호 연결 확인).
|
||||
* **Error Control**: 제대로 갔는가? (데이터 무결성 보장). ([[Fault-Tolerance|Fault-Tolerance]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 프로토콜이 없다면 인터넷은 단 1초도 유지될 수 없으며, 서로 다른 명세의 지식이 섞이지 않도록 보장하는 지식 관리의 표준(Standard)이기 때문임. ([[Global-Standard|Global-Standard]]와 연결)
|
||||
### 매 protocol 의 layers
|
||||
- **Physical / Link**: Ethernet, Wi-Fi 7, 5G NR.
|
||||
- **Network**: IPv6 (default 2026), IPv4 legacy.
|
||||
- **Transport**: TCP, UDP, QUIC.
|
||||
- **Application**: HTTP/3, gRPC, MCP, MQTT, AMQP.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 고정된 기계적 규칙(TCP/IP 등) 정책이었으나, 현대 정책은 장치 간의 전력 상태나 데이터 중요도 정책에 따라 통신 방식을 바꾸는 '적응형 프로토콜 정책'으로 발전함(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 시스템 내의 '지식 주입 프로토콜 정책(Batch-Loop)' 또한 에러 발생 시 재시도 정책이나 배치 크기 조절 정책을 포함하여, 지식 베이스 구축의 안정성 정책을 지키는 핵심 프로토콜 정책으로 작동 중임.
|
||||
### 매 design dimensions
|
||||
- **Stateful vs stateless**: 매 server-side state 보관 여부.
|
||||
- **Sync vs async**: 매 request-response vs publish-subscribe.
|
||||
- **Push vs pull**: 매 server-initiated vs client-initiated.
|
||||
- **Text vs binary**: 매 human-readable vs efficient.
|
||||
- **Versioning**: 매 backward / forward compatibility 의 strategy.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Fault-Tolerance|Fault-Tolerance]], [[Global-Standard|Global-Standard]], [[Technical-Architecture|Technical-Architecture]], [[Standard-Operating-Procedure|Standard-Operating-Procedure]], [[Hardware|Hardware]]
|
||||
- **Modern Tech/Tools**: HTTP/HTTPS, TCP/IP, MQTT, gRPC, WebSocket.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Web**: HTTP/3 over QUIC — 매 default.
|
||||
2. **AI tools**: MCP (Anthropic 2024) 매 LLM ↔ tool 의 universal.
|
||||
3. **Microservices**: gRPC 매 internal RPC.
|
||||
4. **IoT**: MQTT 5 매 lightweight pub-sub.
|
||||
5. **Realtime**: WebSocket / WebTransport.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### MCP server (Anthropic, 2026 standard)
|
||||
```python
|
||||
from mcp.server import Server
|
||||
from mcp.types import Tool, TextContent
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
server = Server("knowledge-base")
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
@server.list_tools()
|
||||
async def tools():
|
||||
return [Tool(
|
||||
name="query",
|
||||
description="Query the KB",
|
||||
inputSchema={
|
||||
"type": "object",
|
||||
"properties": {"q": {"type": "string"}},
|
||||
"required": ["q"],
|
||||
},
|
||||
)]
|
||||
|
||||
- **정보 상태:** 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
|
||||
@server.call_tool()
|
||||
async def call(name, args):
|
||||
return [TextContent(type="text", text=search(args["q"]))]
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### gRPC service (.proto + Python)
|
||||
```protobuf
|
||||
// kb.proto
|
||||
syntax = "proto3";
|
||||
service KB {
|
||||
rpc Query(QueryRequest) returns (stream QueryChunk);
|
||||
}
|
||||
message QueryRequest { string q = 1; }
|
||||
message QueryChunk { string text = 1; bool done = 2; }
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
```python
|
||||
# server.py
|
||||
import grpc, kb_pb2_grpc, kb_pb2
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
class KBServicer(kb_pb2_grpc.KBServicer):
|
||||
def Query(self, request, context):
|
||||
for chunk in stream_search(request.q):
|
||||
yield kb_pb2.QueryChunk(text=chunk, done=False)
|
||||
yield kb_pb2.QueryChunk(done=True)
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### HTTP/3 client (QUIC)
|
||||
```python
|
||||
# httpx + h2/h3
|
||||
import httpx
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
async with httpx.AsyncClient(http2=True, http3=True) as client:
|
||||
r = await client.get("https://api.example.com/v1/users")
|
||||
print(r.http_version) # "HTTP/3"
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### WebSocket realtime
|
||||
```python
|
||||
import asyncio
|
||||
import websockets
|
||||
|
||||
async def handler(ws):
|
||||
async for msg in ws:
|
||||
await ws.send(f"echo: {msg}")
|
||||
|
||||
async def main():
|
||||
async with websockets.serve(handler, "0.0.0.0", 8765):
|
||||
await asyncio.Future() # run forever
|
||||
```
|
||||
|
||||
### MQTT 5 pub-sub (IoT)
|
||||
```python
|
||||
import paho.mqtt.client as mqtt
|
||||
|
||||
def on_message(client, userdata, msg):
|
||||
print(f"{msg.topic}: {msg.payload.decode()}")
|
||||
|
||||
client = mqtt.Client(protocol=mqtt.MQTTv5)
|
||||
client.on_message = on_message
|
||||
client.connect("broker.example.com", 1883)
|
||||
client.subscribe("sensors/+/temperature")
|
||||
client.loop_forever()
|
||||
```
|
||||
|
||||
### Protocol negotiation (capabilities handshake)
|
||||
```python
|
||||
# Common pattern: client sends supported versions, server picks highest mutual
|
||||
def negotiate(client_versions: set[str], server_versions: set[str]) -> str:
|
||||
common = client_versions & server_versions
|
||||
if not common:
|
||||
raise ProtocolError("no compatible version")
|
||||
return max(common, key=lambda v: tuple(map(int, v.split("."))))
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| Scenario | Protocol |
|
||||
|---|---|
|
||||
| 매 LLM ↔ tools | MCP |
|
||||
| 매 internal RPC, polyglot | gRPC over HTTP/2 |
|
||||
| 매 public web API | HTTP/3 + JSON / OpenAPI |
|
||||
| 매 realtime browser | WebSocket / WebTransport |
|
||||
| 매 IoT constrained | MQTT 5 / CoAP |
|
||||
| 매 message queue | AMQP 1.0 / Kafka |
|
||||
| 매 streaming chat | Server-Sent Events / WebSocket |
|
||||
|
||||
**기본값**: 매 public = HTTP/3 + JSON, 매 internal = gRPC, 매 LLM tools = MCP.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Networking]] · [[Distributed-Systems]]
|
||||
- 변형: [[HTTP]] · [[gRPC]] · [[MCP]] · [[WebSocket]]
|
||||
- 응용: [[API-Design]] · [[Microservices]] · [[IoT]]
|
||||
- Adjacent: [[Interoperability]] · [[Serialization]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 protocol selection, 매 wire format debugging, 매 backward-compat strategy review.
|
||||
**언제 X**: 매 single-process in-memory calls — 매 protocol 무용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Custom snowflake protocol**: 매 in-house wire format 매 ecosystem 의 X.
|
||||
- **No version negotiation**: 매 deploy mismatch → cascade failure.
|
||||
- **Stateful with no session**: 매 load balancer 매 sticky session 강제 → scaling pain.
|
||||
- **Chatty protocols**: 매 N round trips 매 single op → latency.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (RFC 9114 HTTP/3, 9000 QUIC; gRPC.io; Anthropic MCP spec 2024; OASIS MQTT 5; OASIS AMQP 1.0).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — protocol layers + 2026 modern stack (MCP, HTTP/3, gRPC) |
|
||||
|
||||
@@ -1,100 +1,191 @@
|
||||
---
|
||||
id: wiki-2026-0508-pull-request-and-issue-tracking
|
||||
title: Pull Request and Issue Tracking
|
||||
category: Other
|
||||
status: needs_review
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [pull_request_and_issue_tracking]
|
||||
aliases: [PR Workflow, Code Review, Issue Tracker]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [- pull_request - issue_tracking - code_review - devops - collaboration]
|
||||
raw_sources: ["- Other/풀_리퀘스트_및_이슈_트래커_PR_&_Issue_Tracker.md - Other/풀_리퀘스트_및_이슈_트래킹_Pull_Requests_&_Issue_Tracking.md - AI_and_ML/풀 리퀘스트 워크플로우.md - AI_and_ML/풀 리퀘스트(PR) 기반 보안 검토.md"]
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [git, github, workflow, devops]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: yaml
|
||||
framework: github-gitlab
|
||||
---
|
||||
|
||||
# 풀 리퀘스트 및 이슈 트래킹 (Pull Request & Issue Tracking)
|
||||
# Pull Request and Issue Tracking
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
풀 리퀘스트(PR)와 이슈 트래킹은 코드의 변경 사항을 제안, 검토, 병합하고 버그나 기능 요청을 체계적으로 추적하는 현대적 협업의 핵심 도구입니다 [1, 2]. 코드베이스 해독 관점에서 이들은 단순히 작업 관리 도구를 넘어, 코드가 왜 현재의 형태로 작성되었는지에 대한 역사적 맥락, 설계 결정, 그리고 암묵적 지식을 명시적으로 담고 있는 필수적인 서사(Narrative) 기록소 역할을 합니다 [4].
|
||||
## 매 한 줄
|
||||
> **"매 PR 의 unit of code change, 매 issue 의 unit of intent"**. GitHub (2008) 의 popularize, GitLab/Bitbucket/Gitea/Forgejo 의 follow. 매 2026 의 standard workflow 의 trunk-based + small PRs + automated checks + LLM-assisted review (CodeRabbit, GitHub Copilot Workspace, Claude Code).
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
### 1. 코드의 역사적 맥락과 설계 의도 파악
|
||||
* **서사 저장소**: 소스 코드는 시스템의 현재 상태만을 보여주지만, PR과 이슈 트래커는 코드가 그러한 형태로 존재하게 된 서사를 담고 있습니다. PR 설명, 커밋 메시지, 토론 기록은 당시의 설계 결정과 비즈니스 요구사항을 이해하는 유일한 단서가 됩니다 [1, 4].
|
||||
* **암묵적 지식의 명시화**: 과거에 시도했다가 기각된 대안들이나 기술적 타협점(Trade-off)에 대한 기록은 현재 코드가 가진 제약 사항과 부채를 이해하는 데 매우 중요합니다 [1, 2].
|
||||
## 매 핵심
|
||||
|
||||
### 2. 효율적인 워크플로우 및 코드 리뷰
|
||||
* **지식 교환의 장**: PR은 단순한 코드 병합 요청이 아니라 질문을 던지고 가정을 검증하며 제품을 개선하는 대화의 시작점입니다 [1, 3].
|
||||
* **단계별 리뷰**: 전체 그림(Big Picture) 파악 → 파일별 변경 확인 → 핵심 로직 및 타입 정의 검토 → 커밋 이력 확인 순으로 진행하는 것이 효율적입니다 [9-14].
|
||||
* **보안 검토 통합**: PR 단계에서 정적 분석(SAST) 및 보안 취약점 스캔을 자동화하여 이슈를 조기에 식별(Shift-Left)합니다 [22, 23].
|
||||
### 매 PR Lifecycle
|
||||
1. **Branch** — 매 feature/fix branch 의 cut from main.
|
||||
2. **Commit** — 매 atomic change + descriptive message (Conventional Commits).
|
||||
3. **Open PR** — 매 description (what/why/how) + linked issue.
|
||||
4. **CI** — 매 lint, test, build, security scan.
|
||||
5. **Review** — 매 human + LLM-assist.
|
||||
6. **Merge** — 매 squash / rebase / merge commit.
|
||||
7. **Deploy** — 매 main 의 push 의 trigger CD.
|
||||
|
||||
### 3. AI 및 자동화 도구의 활용
|
||||
* **컨텍스트 추출**: AI 기반 분석 도구들이 PR 및 이슈 데이터를 읽어 코드의 존재 목적을 고차원적으로 설명하거나 설계 결정을 요약합니다 [2, 9, 17-21].
|
||||
* **MCP 연동**: AI 에이전트가 GitHub API 등을 통해 PR 데이터를 직접 조회하여 탭 전환 없이 맥락을 파악하고 리뷰를 보조합니다 [17, 18, 40].
|
||||
### 매 Issue Types
|
||||
- **Bug** — 매 actual misbehavior + repro steps.
|
||||
- **Feature** — 매 user-facing capability request.
|
||||
- **Task** — 매 internal work (refactor, debt).
|
||||
- **Epic** — 매 multi-PR initiative.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **인지적 과부하**: PR의 규모가 너무 크면(예: 50개 이상의 파일 변경) 리뷰어와 AI 모델 모두 문맥을 잃기 쉽습니다. 피처 플래그(Feature Flags)를 활용하여 작고 점진적인 단위로 쪼개는 것이 권장됩니다 [24-26].
|
||||
* **알림 피로 (Notification Fatigue)**: 무분별한 리뷰 요청은 방치나 무검토 병합을 초래할 수 있습니다. 적절한 '코드 오너(Code Owners)' 설정과 알림 제어가 필요합니다 [15, 19, 27].
|
||||
* **정보의 노이즈**: 상투적인 문구나 무의미한 체크리스트 등은 분석에 방해가 되므로 핵심 설계 결정 위주로 기록해야 합니다 [17, 18].
|
||||
### 매 Automation Surface
|
||||
- Branch protection (required reviews + checks).
|
||||
- Auto-assign reviewers (CODEOWNERS).
|
||||
- Auto-label / triage bots.
|
||||
- Stale issue cleanup.
|
||||
- Release notes (release-please).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics**: [[버전 관리 시스ᄐEM(Version Control Systems)|버전 관리 시스템]], [[코드 리뷰(Code Review)|코드 리뷰]], CI/CD, 기술적 부채
|
||||
- **Projects/Contexts**: GitHub 워크플로우, Jira/Linear 이슈 연동, AI 기반 PR 리뷰 시스템 (CodeRabbit 등)
|
||||
- **Contradictions/Notes**: 과도한 제동(Request Changes)은 배포 속도를 지연시킵니다. 심각한 오류가 없다면 승인 후 별도 이슈로 개선 사항을 처리하는 유연함이 장기적인 생산성에 유리할 수 있습니다 [28, 29].
|
||||
### 매 응용
|
||||
1. Solo project — 매 PR 의 self 의 review 의 force structure.
|
||||
2. Team — 매 ownership boundary 의 CODEOWNERS.
|
||||
3. OSS — 매 issue triage 의 community signal.
|
||||
4. Compliance — 매 audit trail 의 SOC2/ISO 27001.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-08*
|
||||
## 💻 패턴
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### PR template (`.github/PULL_REQUEST_TEMPLATE.md`)
|
||||
```markdown
|
||||
## What
|
||||
<one-liner>
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## Why
|
||||
<motivation, linked issue: #123>
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## How
|
||||
<technical approach summary>
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
## Test plan
|
||||
- [ ] Unit tests pass
|
||||
- [ ] Manual repro on staging
|
||||
- [ ] No new warnings
|
||||
|
||||
- **정보 상태:** 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
|
||||
## Risk
|
||||
Low / Medium / High — explain.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Issue template (`.github/ISSUE_TEMPLATE/bug.yml`)
|
||||
```yaml
|
||||
name: Bug report
|
||||
description: File a bug
|
||||
labels: [bug, triage]
|
||||
body:
|
||||
- type: textarea
|
||||
id: repro
|
||||
attributes:
|
||||
label: Steps to reproduce
|
||||
validations: { required: true }
|
||||
- type: textarea
|
||||
id: expected
|
||||
attributes:
|
||||
label: Expected behavior
|
||||
- type: input
|
||||
id: version
|
||||
attributes: { label: Version }
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### CODEOWNERS
|
||||
```
|
||||
# .github/CODEOWNERS
|
||||
*.py @backend-team
|
||||
/web/** @frontend-team
|
||||
/infra/** @platform @sre
|
||||
*.md @docs
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### CI gate (GitHub Actions)
|
||||
```yaml
|
||||
name: ci
|
||||
on: [pull_request]
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-node@v4
|
||||
with: { node-version: 22 }
|
||||
- run: npm ci
|
||||
- run: npm run lint
|
||||
- run: npm test -- --coverage
|
||||
- uses: codecov/codecov-action@v4
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Auto-merge after green
|
||||
```yaml
|
||||
name: auto-merge
|
||||
on: pull_request_review
|
||||
jobs:
|
||||
automerge:
|
||||
if: github.event.review.state == 'approved'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: pascalgn/automerge-action@v0.16.4
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
MERGE_METHOD: squash
|
||||
MERGE_LABELS: "automerge,!wip"
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### `gh` CLI workflow
|
||||
```bash
|
||||
# Create PR
|
||||
git checkout -b fix/null-deref
|
||||
git commit -am "fix: handle null user in checkout"
|
||||
gh pr create --fill --reviewer alice,bob
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
# Review queue
|
||||
gh pr list --search "is:open review-requested:@me"
|
||||
|
||||
# Triage
|
||||
gh issue list --label "needs-triage" --json number,title,createdAt
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Small change | Squash merge |
|
||||
| Long-lived feature | Merge commit (preserve history) |
|
||||
| Linear history fans | Rebase + fast-forward |
|
||||
| Many reviewers | CODEOWNERS auto-request |
|
||||
| OSS project | Issue templates + DCO |
|
||||
| Internal monorepo | Required checks + auto-merge |
|
||||
|
||||
**기본값**: small PRs (<400 LOC) + squash merge + Conventional Commits + required CI.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Git]] · [[CI-CD]]
|
||||
- 변형: [[GitHub]] · [[GitLab]] · [[Gitea]] · [[Forgejo]]
|
||||
- 응용: [[Code-Review]] · [[Trunk-Based-Development]]
|
||||
- Adjacent: [[Conventional-Commits]] · [[Semantic-Versioning]] · [[CODEOWNERS]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: PR description 의 generate, review 의 first-pass (style, obvious bugs), issue triage 의 label.
|
||||
**언제 X**: security-critical review — 매 human 의 final approve.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Mega-PR (5000+ LOC)**: 매 review 의 useless — 매 split 의 require.
|
||||
- **Empty description**: 매 reviewer 의 context-free.
|
||||
- **Force-push to shared branch**: 매 review history 의 destroy — feature branch 의 only.
|
||||
- **Self-merge without review**: 매 sole-maintainer except — 매 audit trail 의 weak.
|
||||
- **Issue 의 dump 의 chat**: 매 GitHub issue 의 single source of truth.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (GitHub Docs 2026, Conventional Commits v1.0).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — PR/issue templates + CI patterns + gh CLI |
|
||||
|
||||
+130
-65
@@ -2,91 +2,156 @@
|
||||
id: wiki-2026-0508-purpose
|
||||
title: Purpose
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-PURP-001]
|
||||
aliases: [Telos, Mission, Intent, Goal-Setting, Why]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, purpose, mission, Alignment, value-proposition, existentialism]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [philosophy, psychology, leadership, design]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: theory
|
||||
framework: teleological-design
|
||||
---
|
||||
|
||||
# [[Purpose|Purpose]]
|
||||
# Purpose
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "존재의 이유이자 최상위 목표: 단순한 생존이나 이익을 넘어 '우리는 왜 이 일을 하는가'에 대한 답이자, 수만 가지 기술적 선택지 사이에서 길을 잃지 않게 하는 나침반."
|
||||
## 매 한 줄
|
||||
> **"매 know your why before you optimize your how."**. 매 Aristotle 의 *telos* 부터 매 Sinek 의 *Start with Why*, 매 Frankl 의 *meaning therapy* 까지 — 매 purpose = 매 why an entity (person, system, product) exists. 매 2026 software/AI 에서 매 purpose 명시는 매 alignment, scope creep 회피, 매 LLM agent goal-setting 의 foundation.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
목적(Purpose)은 존재의 근본적인 이유나 지향하는 궁극적인 지점입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **비즈니스/프로젝트에서의 역할**:
|
||||
* **Alignment**: 팀원들이 같은 방향을 보고 시너지를 내게 함. ([[Leadership|Leadership]]와 연결)
|
||||
* **[[Resilience|Resilience]]**: 어려운 상황에서도 포기하지 않고 나아가게 하는 동력. ([[Mastery|Mastery]]와 연결)
|
||||
* **Prioritization**: 목적에 맞지 않는 일은 과감히 버리는 기준. ([[Pareto-Principle|Pareto-Principle]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 강력한 목적의식(Why)이 결여된 지능(Intelligence)은 단기적인 효율성에 매몰되어 결국 시스템 전체의 붕괴나 무의미한 결과물만 생산하게 되기 때문임.
|
||||
### 매 4 levels of purpose
|
||||
- **Existential (인간)**: 매 Frankl — 매 meaning vs pleasure vs power.
|
||||
- **Organizational**: 매 mission statement — 매 "why does this company exist?".
|
||||
- **Product**: 매 user job-to-be-done (Christensen) — 매 "what hire is this product made for?".
|
||||
- **System/Code**: 매 module purpose — 매 "what 1 thing does this module own?".
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 목적을 '추상적인 구호 정책'으로 치부했으나, 현대 정책은 목적이 명확한 조직 정책이 그렇지 않은 조직보다 압도적인 성과 정책을 냄을 입증함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 정렬(Alignment) 문제 또한 모델에게 인간의 목적 정책을 어떻게 오차 없이 주입하느냐의 싸움이며, 이는 '보상 함수(Reward Function) 설계 정책'의 핵심으로 직결됨. ([[Reinforcement Learning (RL)|Reinforcement Learning (RL)]]와 연결)
|
||||
### 매 purpose articulation patterns
|
||||
- **Sinek's Golden Circle**: WHY → HOW → WHAT.
|
||||
- **JTBD**: "When [situation], I want to [motivation], so I can [outcome]".
|
||||
- **OKR**: Objective (qualitative why) + Key Results (measurable).
|
||||
- **Module docstring**: 1-line purpose + invariants.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Leadership|Leadership]], [[Mastery|Mastery]], [[Pareto-Principle|Pareto-Principle]], [[Reinforcement Learning (RL)|Reinforcement Learning (RL)]], [[Philosophy|Philosophy]], Mission
|
||||
- **Modern Tech/Tools**: Ikigai framework, Golden Circle (Simon Sinek), ESG [[Management|Management]].
|
||||
---
|
||||
### 매 응용
|
||||
1. Code: 매 module 의 1-sentence purpose 가 unclear 면 — split or rename.
|
||||
2. LLM agent: 매 system prompt 의 첫 줄은 purpose — 매 alignment anchor.
|
||||
3. Career: 매 ikigai (것 + 잘 + need + paid).
|
||||
4. Product: 매 JTBD interview → feature prioritization.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Module-level purpose docstring
|
||||
```python
|
||||
"""
|
||||
auth/jwt.py
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
PURPOSE: 매 issue and verify JWT tokens for our API authentication.
|
||||
INVARIANTS:
|
||||
- Tokens always include `iss` claim.
|
||||
- Verification rejects tokens with `alg=none`.
|
||||
NON-GOALS:
|
||||
- Session storage (see auth/session.py).
|
||||
- Refresh-token rotation (see auth/refresh.py).
|
||||
"""
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: LLM agent system prompt
|
||||
```python
|
||||
SYSTEM = """You are a code-review assistant.
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
PURPOSE: 매 surface non-obvious bugs, security issues, and style violations
|
||||
in the user's pull request, prioritized by severity.
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
NON-GOALS:
|
||||
- Generating new code (the user does that).
|
||||
- Auto-fixing without confirmation.
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
CONSTRAINTS:
|
||||
- Always cite file:line for every claim.
|
||||
- Refuse to comment on out-of-scope files.
|
||||
"""
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Pattern 3: JTBD interview template
|
||||
```yaml
|
||||
job_to_be_done:
|
||||
situation: "When I'm onboarding a new team member"
|
||||
motivation: "I want a single doc with their day-1 setup"
|
||||
outcome: "so they can ship a real PR by end of week 1"
|
||||
current_alternatives: [README, Notion page, ad-hoc Slack DMs]
|
||||
hire_criteria: [single-source, executable, verified]
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 4: OKR framing
|
||||
```yaml
|
||||
objective: "매 Make AI Act compliance trivial for EU SMBs"
|
||||
key_results:
|
||||
- "Onboard 100 SMBs by Q3"
|
||||
- "Reduce time-to-compliance from 30d → 5d"
|
||||
- "NPS ≥ 50"
|
||||
```
|
||||
|
||||
### Pattern 5: Purpose-test for scope creep
|
||||
```python
|
||||
def is_in_scope(feature, module_purpose) -> bool:
|
||||
"""매 ask: 'does this feature serve the module's stated purpose?'"""
|
||||
# 매 if no, push to a different module or reject
|
||||
return feature.advances(module_purpose)
|
||||
```
|
||||
|
||||
### Pattern 6: 5-Whys to surface purpose
|
||||
```text
|
||||
Q: Why are we building this dashboard?
|
||||
A: To show metrics.
|
||||
Q: Why?
|
||||
A: So managers can see team health.
|
||||
Q: Why?
|
||||
A: So they can intervene early.
|
||||
Q: Why?
|
||||
A: To prevent burnout & attrition.
|
||||
Q: Why?
|
||||
A: Because attrition costs $200K/engineer.
|
||||
→ 매 PURPOSE: "매 reduce attrition cost via early-burnout intervention".
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Tool |
|
||||
|---|---|
|
||||
| 매 module/file design | 1-sentence purpose docstring |
|
||||
| 매 LLM agent design | Purpose + non-goals + constraints in system prompt |
|
||||
| 매 product feature triage | JTBD + Purpose-test |
|
||||
| 매 organization strategy | Mission statement + OKRs |
|
||||
| 매 personal direction | Ikigai / 5-Whys |
|
||||
|
||||
**기본값**: 매 1-sentence purpose 가 없으면 — 매 don't ship.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Philosophy]] · [[Design Thinking]] · [[Leadership]]
|
||||
- 변형: [[Mission]] · [[Vision]] · [[Telos]] · [[Ikigai]]
|
||||
- 응용: [[Module Design]] · [[LLM Agent Design]] · [[OKR]] · [[JTBD]]
|
||||
- Adjacent: [[Single Responsibility Principle]] · [[Start With Why]] · [[Frankl]] · [[Aristotle]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 system prompt 첫 줄, 매 module docstring, 매 product brief, 매 strategy doc.
|
||||
**언제 X**: 매 throwaway prototypes — 매 over-formalization slows iteration.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **No purpose**: 매 module 이 "everything" 하면 — 매 god class.
|
||||
- **Purpose drift**: 매 purpose 명시했지만 features 가 매 drift — 매 update or refactor.
|
||||
- **Aspirational nonsense**: 매 "make the world better" — 매 unactionable.
|
||||
- **Purpose ≠ method**: 매 "use React" 는 method, not purpose.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Aristotle *Nicomachean Ethics*; Frankl *Man's Search for Meaning*; Sinek *Start with Why*; Christensen JTBD).
|
||||
- 신뢰도 A (foundational philosophical + management canon).
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 4 levels, JTBD/OKR/Golden Circle 패턴 |
|
||||
|
||||
@@ -2,94 +2,145 @@
|
||||
id: wiki-2026-0508-pyramid-principle
|
||||
title: Pyramid Principle
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Minto Pyramid, SCQA, Top-down Communication]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [communication, writing, consulting, structure]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: english-korean
|
||||
framework: structured-writing
|
||||
---
|
||||
|
||||
# [[Pyramid Principle|Pyramid Principle]]
|
||||
# Pyramid Principle
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
결론이나 핵심 메시지를 가장 먼저 제시하고, 이를 뒷받침하는 주요 논거와 세부 데이터를 하위 계층에 논리적으로 배열하는 하향식(Top-down) 커뮤니케이션 및 구조화 기법입니다.
|
||||
## 매 한 줄
|
||||
> **"매 conclusion first, supporting reasons next, evidence last"**. Barbara Minto 의 McKinsey (1967) 의 develop 의 top-down structure 의 consulting/exec communication 의 standard. 매 reader 의 cognitive load 의 minimize — main idea 의 immediately 의 deliver.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- 맥킨지의 바바라 민토(Barbara Minto)가 개발한 방법론으로, 컨설팅 및 기업 경영진 소통의 글로벌 표준으로 자리 잡았습니다 [36-38].
|
||||
- **구조(3단계):**
|
||||
1. **핵심 메시지/결론(The Answer):** 청중의 질문에 대한 명확한 답변을 가장 상단(Upfront)에 배치합니다 [36, 39, 40].
|
||||
2. **주요 논거([[Support|Support]]ing Arguments):** 결론이 왜 타당한지를 증명하는 3개 내외의 논리적 주장들입니다 [36, 39, 41].
|
||||
3. **증거 및 데이터(Supporting Data or Facts):** 논거를 입증하는 구체적 사실, 수치, 분석 결과를 하단에 배치합니다 [36, 39, 42].
|
||||
- **수직적/수평적 논리:** 상하위 계층은 '질문-답변(Question-Answer)'의 수직적 관계를 가지며, 동일 계층의 수평적 아이디어들은 [[MECE|MECE]] 원칙에 따라 연역적, 시간적, 구조적, 혹은 비교의 순서로 논리적으로 정렬되어야 합니다 [43-52].
|
||||
- **[[BLUF (Bottom Line Up Front)|BLUF (Bottom Line Up Front]]:** 경영진은 시간이 부족하고 결론을 원하므로, 미스터리 소설처럼 배경부터 설명하기보다 결론을 먼저 내놓아 시간 효율성과 설득력을 극대화합니다 [40, 53, 54].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[SCQA Framework|SCQA Framework]], MECE Framework, [[Rule of Three|Rule of Three]]
|
||||
- **Projects/Contexts:** 경영진 보고([[Executive Presentation|Executive Presentation]]), 컨설팅 제안서 작성, 슬라이드 덱 구성
|
||||
- **Contradictions/Notes:** 작성자가 생각하고 연구할 때는 상향식(Bottom-up)으로 진행하지만, 이를 타인에게 소통할 때는 완전히 반대인 하향식(Top-down)으로 구성해야 한다는 점에서 인지적 전환이 필요합니다 [55-58]. 또한, 청중과 함께 해답을 찾아가는 협력적(Collaborative) 방식의 워크숍에는 다소 부적합할 수 있습니다 [59, 60].
|
||||
### 매 Three Rules
|
||||
1. **Ideas at any level must summarize the ideas grouped below**.
|
||||
2. **Ideas in each grouping must be the same kind** (MECE — Mutually Exclusive, Collectively Exhaustive).
|
||||
3. **Ideas in each grouping must be logically ordered** (time / structure / degree).
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 SCQA Intro Pattern
|
||||
- **S**ituation: 매 reader 의 known fact.
|
||||
- **C**omplication: 매 disrupt 의 event.
|
||||
- **Q**uestion: 매 implicit question.
|
||||
- **A**nswer: 매 thesis (= pyramid top).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Exec memo — 매 1-page 의 BLUF (Bottom Line Up Front).
|
||||
2. Consulting deck — 매 action title slide 의 each.
|
||||
3. PR description — 매 "what / why / how" 의 top-down.
|
||||
4. RFC docs — 매 abstract 의 conclusion-first.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Bad → Good (technical email)
|
||||
```markdown
|
||||
<!-- BAD: Bottom-up -->
|
||||
We profiled the API. CPU was 80%. Then we added caching.
|
||||
After caching, p99 dropped from 800ms to 120ms.
|
||||
Therefore we should ship the cache to prod.
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
<!-- GOOD: Pyramid -->
|
||||
**Recommend shipping Redis cache to prod (p99 800ms → 120ms).**
|
||||
|
||||
- **정보 상태:** 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
|
||||
- Profiling showed 80% CPU on repeated DB reads.
|
||||
- Cache hit ratio 92% in staging.
|
||||
- No correctness regressions in 48h soak test.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### SCQA opener template
|
||||
```markdown
|
||||
**S**: Our checkout API serves 10k req/s.
|
||||
**C**: Last week, p99 spiked to 2s during flash sale.
|
||||
**Q**: How do we prevent recurrence?
|
||||
**A**: Add request-coalescing cache + circuit breaker. Details below.
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Action-title slide structure
|
||||
```markdown
|
||||
# [Slide title = the takeaway, not the topic]
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# BAD: "Q3 Revenue Analysis"
|
||||
# GOOD: "Q3 revenue grew 22% driven by enterprise tier"
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
- Bullet 1 (evidence)
|
||||
- Bullet 2 (evidence)
|
||||
- Bullet 3 (evidence)
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### PR description pyramid
|
||||
```markdown
|
||||
## TL;DR
|
||||
Fix race in `OrderQueue` causing lost messages under high load.
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## Why
|
||||
- Reproduced 1/1000 message loss in load test.
|
||||
- Root cause: missing mutex in `enqueue()`.
|
||||
|
||||
## How
|
||||
- Added `sync.Mutex` (commit a1b2c3).
|
||||
- New stress test (commit d4e5f6).
|
||||
|
||||
## Risk
|
||||
Low — change is local; backward compatible.
|
||||
```
|
||||
|
||||
### MECE grouping check
|
||||
```python
|
||||
# Pseudo: ensure subpoints partition the parent claim
|
||||
parent = "User churn increased"
|
||||
children = [
|
||||
"Onboarding friction", # acquisition phase
|
||||
"Feature gaps", # activation phase
|
||||
"Pricing", # retention phase
|
||||
]
|
||||
# MECE: each is distinct phase, together cover funnel.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Use pyramid? |
|
||||
|---|---|
|
||||
| Exec / time-poor reader | Yes — BLUF |
|
||||
| Persuasive memo | Yes — SCQA |
|
||||
| Narrative storytelling | No — suspense matters |
|
||||
| Tutorial / step-by-step | No — sequence matters |
|
||||
| Research paper abstract | Yes — conclusion-first |
|
||||
|
||||
**기본값**: 매 business 의 technical writing 의 pyramid first.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Communication]] · [[Writing]]
|
||||
- 변형: [[BLUF]] · [[SCQA]] · [[MECE]]
|
||||
- 응용: [[Consulting]] · [[Exec-Memo]] · [[Technical-Writing]]
|
||||
- Adjacent: [[Mental-Models]] · [[Decision-Making]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: draft 의 restructure top-down, 매 generate exec summary.
|
||||
**언제 X**: creative narrative — 매 pyramid 의 kill suspense.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Buried lede**: 매 conclusion 의 last paragraph — exec 의 never reach.
|
||||
- **Non-MECE buckets**: 매 overlap 의 reader confuse.
|
||||
- **Topic title slides**: "Q3 Analysis" 의 X — "Q3 grew 22%" 의 O.
|
||||
- **Pyramid 의 misuse 의 fiction**: 매 mystery 의 spoil.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Minto, "The Pyramid Principle", 1987 / McKinsey internal training).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Three rules + SCQA + before/after examples |
|
||||
|
||||
@@ -2,68 +2,136 @@
|
||||
id: wiki-2026-0508-recording-academy-the-grammys
|
||||
title: Recording Academy (The Grammys)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-GRAM-001]
|
||||
aliases: [Grammy Awards, NARAS, The Recording Academy]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-reinforced, music, culture, Awards, recording-academy]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [music, awards, industry]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: industry
|
||||
framework: music-awards
|
||||
---
|
||||
|
||||
# [[Recording Academy (The Grammys)|Recording Academy ([[The Grammys]])]]
|
||||
# Recording Academy (The Grammys)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "음악 산업의 자정 작용이자 보루: 상업적 유행을 넘어 예술적 성취와 기술적 완성을 정교한 동료 평가(Peer Review) 시스템을 통해 공인하는 글로벌 최고 권위의 비영리 협회."
|
||||
## 매 한 줄
|
||||
> **"매 US-based peer-voted music awards body"**. NARAS (1957 founded) 의 Grammy Awards (1959 first ceremony) 의 host. 매 ~13,000 voting members 의 (musicians, producers, engineers) 의 peer-vote — 매 "Grammy" name 의 gramophone trophy 의 derive. 67th ceremony 의 2025-02-02 의 LA 의 Crypto.com Arena 의 hold.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
미국 레코딩 아카데미(National Academy of Recording [[Arts|Arts]] and Sciences, NARAS)는 세계 최고 권위의 음악 시상식인 '그래미 어워드(Grammy Awards)'를 주관하는 기구입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **조직 구성**:
|
||||
* 가수, 작곡가, 프로듀서, 엔지니어 등 음악 산업의 실무 전문가(멤버)들로 구성.
|
||||
2. **그래미 선정 프로세스 (Systemic Approach)**:
|
||||
* **Entry**: 전 세계에서 수만 개의 작품 접수.
|
||||
* **Screening**: 카테고리별 자격 요건 검토.
|
||||
* **Nominating & Final Voting**: 회원들의 투표를 통해 후보 및 최종 수상자 결정. 대중성보다는 '음악적 전문성'과 '품질'에 비중을 둠.
|
||||
3. **사회적 역할**:
|
||||
* **MusiCares**: 도움이 필요한 음악가들에 대한 보건 및 긴급 지원 기여.
|
||||
* **Advocacy**: 음악 저작권 보호 및 입법 활동을 통한 권익 보호.
|
||||
### 매 Structure
|
||||
- **NARAS** (National Academy of Recording Arts and Sciences) 의 official entity.
|
||||
- **12 chapters** (LA, NY, Nashville, Atlanta, Chicago, etc.).
|
||||
- **30+ genre fields** → ~94 categories (2025 ceremony).
|
||||
- **CEO**: Harvey Mason Jr. (since 2021).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 보수적이고 인종 차별적(White-centric)이라는 비판이 지속되어 왔으나, 최근 투표권자 구성의 다양성을 대폭 강화하고 힙합, 일렉트로닉, K-POP 등 장르 수용 정책을 확대하며 전면적인 조직 쇄신(RL Update)을 단행함.
|
||||
- **정책 변화(RL Update)**: AI 생성 음악의 급증에 따라, "인간의 창작 기여가 없는 완전 AI 곡은 출품 불가"라는 역사적인 가이드라인을 발표하여, 기술 시대에도 '인간 창작의 신성함'을 보호하려는 강력한 정책 의지 표명.
|
||||
### 매 Voting Process
|
||||
1. **Submission** — labels/members 의 submit recordings.
|
||||
2. **Screening** — committees 의 verify eligibility + category placement.
|
||||
3. **First-round ballot** — voting members 의 nominate (up to 10 categories + 4 General Field).
|
||||
4. **Final ballot** — 매 5 nominees per category 의 winner 의 vote.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Semantics [[Ontology|Ontology]], Information Ethics, Aesthetics of Digital Media, Communication Theories
|
||||
- **Modern Tech/Tools**: Grammy.com, Recording Academy Advocacy.
|
||||
---
|
||||
### 매 General Field ("Big Four")
|
||||
1. Record of the Year.
|
||||
2. Album of the Year.
|
||||
3. Song of the Year.
|
||||
4. Best New Artist.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Career inflection — 매 nomination/win 의 streaming spike (~+50% week-over).
|
||||
2. Industry signal — 매 critical consensus 의 codify.
|
||||
3. Diversity audit — 매 historical bias (e.g., women, non-pop genres) 의 ongoing reform.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Grammy data scrape (Python)
|
||||
```python
|
||||
import requests
|
||||
from bs4 import BeautifulSoup
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
url = "https://www.grammy.com/awards/67th-annual-grammy-awards"
|
||||
soup = BeautifulSoup(requests.get(url).text, "html.parser")
|
||||
winners = [
|
||||
{"category": c.find("h3").text, "artist": c.find(".winner").text}
|
||||
for c in soup.select(".category-card")
|
||||
]
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Wikidata SPARQL — Grammy winners
|
||||
```sparql
|
||||
SELECT ?artist ?artistLabel ?year WHERE {
|
||||
?award wdt:P31 wd:Q368441. # Grammy Award
|
||||
?artist p:P166 ?stmt.
|
||||
?stmt ps:P166 ?award; pq:P585 ?date.
|
||||
BIND(YEAR(?date) AS ?year)
|
||||
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
|
||||
}
|
||||
LIMIT 100
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Spotify API — nominee playlist (TS)
|
||||
```typescript
|
||||
import { SpotifyApi } from "@spotify/web-api-ts-sdk";
|
||||
const sdk = SpotifyApi.withClientCredentials(id, secret);
|
||||
const search = await sdk.search("Grammy 2025 nominees", ["playlist"]);
|
||||
const tracks = await sdk.playlists.getPlaylistItems(search.playlists.items[0].id);
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### Grammy buzz sentiment (Python)
|
||||
```python
|
||||
from transformers import pipeline
|
||||
clf = pipeline("sentiment-analysis", model="cardiffnlp/twitter-roberta-base-sentiment-latest")
|
||||
tweets = ["Beyoncé deserved AOTY!", "Grammys irrelevant again"]
|
||||
print(clf(tweets))
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Streaming bump analysis
|
||||
```python
|
||||
import pandas as pd
|
||||
df = pd.read_csv("spotify_daily_streams.csv", parse_dates=["date"])
|
||||
ceremony = pd.Timestamp("2025-02-02")
|
||||
window = df[(df.date >= ceremony) & (df.date <= ceremony + pd.Timedelta("7d"))]
|
||||
bump = window.streams.sum() / df[df.date < ceremony].tail(7).streams.sum()
|
||||
print(f"7d post-ceremony streaming multiple: {bump:.2f}x")
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Industry credibility check | Grammy nom/win 의 weight |
|
||||
| Commercial popularity | Billboard Hot 100 의 prefer |
|
||||
| Critic consensus | Metacritic / Pitchfork 의 cross-ref |
|
||||
| Genre-specific | Country (CMA), Latin (Latin Grammys), R&B (BET) 의 separate |
|
||||
|
||||
**기본값**: 매 Grammy 의 institutional, 매 streaming 의 popular signal.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Music-Industry]] · [[Awards]]
|
||||
- 변형: [[Latin-Grammys]] · [[Grammy-Hall-of-Fame]]
|
||||
- 응용: [[Album-of-the-Year]] · [[Music-Marketing]]
|
||||
- Adjacent: [[Billboard]] · [[RIAA]] · [[Streaming]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: nominee/winner lookup, category structure 의 explain, historical trend 의 summarize.
|
||||
**언제 X**: real-time ceremony updates — 매 official broadcast / live source 의 use.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **"Grammy = best music"**: 매 voter bias (genre, gender, race) 의 documented — single signal 의 X.
|
||||
- **Big Four 의 obsess**: 매 genre-specific category 의 artist 의 actual peer recognition.
|
||||
- **Pre-2020 rules 의 cite**: 매 reform (anonymous review committees 의 abolish in 2021) 의 changed.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (grammy.com official, Wikipedia "Grammy Award").
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — voting process + Big Four + 67th ceremony |
|
||||
|
||||
@@ -2,65 +2,164 @@
|
||||
id: wiki-2026-0508-related-work
|
||||
title: Related Work
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-REWO-001]
|
||||
aliases: [Related Work Section, Prior Art, Literature Review]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced, related-work, literature-review, State-of-the-art, SOTA, context-setting]
|
||||
verification_status: applied
|
||||
tags: [research, academic-writing, papers]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: english-korean
|
||||
framework: research-writing
|
||||
---
|
||||
|
||||
# [[Related-Work|Related-Work]]
|
||||
# Related Work
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지적 맥락 놓기: 내가 지금 하는 일이 하늘에서 뚝 떨어진 게 아니라, 기존의 어떤 연구들과 맞닿아 있고 무엇이 다른지를 명확히 함으로써, 내 작업의 '차별화된 가치'와 '위치'를 증명하는 학구적인 지도 제작."
|
||||
## 매 한 줄
|
||||
> **"매 academic paper 의 mandatory section 의 prior literature 의 position 의 own contribution"**. ML/CS papers (NeurIPS, ICML, ICLR, ACL, CVPR) 의 standard structure 의 Introduction → Related Work → Method → Experiments → Conclusion. 매 reviewer 의 first read — 매 novelty claim 의 here 의 stand or fall.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
관련 연구(Related-Work) 혹은 기존 연구 조사는 특정 주제에 대해 이미 수행된 다른 사람들의 작업을 검토하고 분석하는 활동입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **목적**:
|
||||
* **Avoid Reinventing the Wheel**: 남이 이미 다 해놓은 일을 반복하지 않음. ([[Efficiency|Efficiency]]와 연결)
|
||||
* **Gap Identification**: 기존 연구들이 놓친 '빈 공간' 발견. ([[Innovation|Innovation]]와 연결)
|
||||
* **SOTA (State-of-the-Art)**: 현재 기술의 정점이 어디인지 파악.
|
||||
2. **왜 중요한가?**:
|
||||
* 기존 지식과 연결되지 않은 새로운 주장은 '망상'일 확률이 높으며, 지식의 연결성(Connectivity)이 곧 그 지식의 생존력 정책이 되기 때문임.
|
||||
### 매 Purpose
|
||||
1. **Position** — 매 own work 의 landscape 의 place.
|
||||
2. **Differentiate** — 매 prior 의 limitation 의 explicit, 매 own gap 의 fill.
|
||||
3. **Credit** — 매 intellectual lineage 의 acknowledge.
|
||||
4. **Scope** — 매 reviewer 의 not-cited prior work 의 reject 의 prevent.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 사람이 일일이 논문을 찾아 읽는 고난의 정책이었으나, 현대 정책은 AI가 수천 개의 연구 문고 정책을 읽고 자동으로 '관련 연구 맵 정책'을 그려 지식의 흐름 정책을 한눈에 보여주는 'AI 리서치 정책'으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 지식 시스템의 각 파일 하단 `Related` 섹션은 사실상의 마이크로 관련 연구(Related Work) 정책으로 작동하며, 지식 간의 유기적 연결 정책을 통해 대표님께 통합적인 통찰 정책을 제공함.
|
||||
### 매 Structure (typical)
|
||||
- **Thematic grouping** (preferred 2026) — 매 theme 의 paragraph 의 each.
|
||||
- *Chronological* — only for survey papers.
|
||||
- *Per-paper* — verbose, avoid.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Efficiency|Efficiency]], [[Innovation|Innovation]], [[Scientific-Method|Scientific-Method]], [[Reference-Management|Reference-Management]], [[Analysis|Analysis]]
|
||||
- **Modern Tech/Tools**: Connected Papers, [[Research|Research]]Rabbit, Semantic Scholar, Elicit.
|
||||
---
|
||||
### 매 Typical Categories (ML paper)
|
||||
1. Foundation / closest direct prior.
|
||||
2. Methodology family (e.g., diffusion vs flow-matching).
|
||||
3. Application domain.
|
||||
4. Concurrent work (last 6 months).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Conference paper — 매 0.5-1 page Related Work section.
|
||||
2. Thesis — 매 standalone chapter (10-30 pages).
|
||||
3. Grant proposal — 매 "Innovation" section 의 backbone.
|
||||
4. Patent — 매 "Background of the Invention".
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### LaTeX section template
|
||||
```latex
|
||||
\section{Related Work}
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
\paragraph{Foundation models for X.}
|
||||
\citet{vaswani2017} introduced the Transformer, which subsequent work
|
||||
\citep{devlin2019,brown2020,touvron2023llama} scaled to billions of parameters.
|
||||
Unlike these, our method targets edge inference (\textsection\ref{sec:method}).
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
\paragraph{Efficient inference.}
|
||||
Quantization \citep{dettmers2022int8,frantar2023gptq} and speculative decoding
|
||||
\citep{leviathan2023speculative,chen2023accelerating} reduce latency, but
|
||||
neither addresses our setting of dynamic batch size.
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
\paragraph{Concurrent work.}
|
||||
\citet{smith2026concurrent} appeared on arXiv in March 2026; we differ in
|
||||
that we additionally support streaming output.
|
||||
```
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
### BibTeX management (`.bib`)
|
||||
```bibtex
|
||||
@inproceedings{vaswani2017,
|
||||
title={Attention is all you need},
|
||||
author={Vaswani, Ashish and others},
|
||||
booktitle={NeurIPS},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
@article{brown2020,
|
||||
title={Language Models are Few-Shot Learners},
|
||||
author={Brown, Tom and others},
|
||||
journal={NeurIPS},
|
||||
year={2020}
|
||||
}
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Paper graph extraction (Python `semanticscholar`)
|
||||
```python
|
||||
from semanticscholar import SemanticScholar
|
||||
sch = SemanticScholar()
|
||||
|
||||
paper = sch.get_paper("10.48550/arXiv.1706.03762") # Attention is all you need
|
||||
for ref in paper.references[:10]:
|
||||
print(ref.title, "→", ref.year)
|
||||
|
||||
# Forward citations
|
||||
cites = sch.get_paper_citations(paper.paperId, limit=50)
|
||||
```
|
||||
|
||||
### Related work table (Markdown)
|
||||
```markdown
|
||||
| Method | Modality | Latency | Param-free | Ours |
|
||||
|---|---|---|---|---|
|
||||
| GPTQ | LLM | medium | no | -- |
|
||||
| AWQ | LLM | low | no | -- |
|
||||
| FlashAttn | LLM | low | yes | similar |
|
||||
| **Ours** | **LLM+Vision** | **lowest** | **yes** | -- |
|
||||
```
|
||||
|
||||
### LLM-assisted citation finder (Anthropic SDK)
|
||||
```python
|
||||
import anthropic
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=600,
|
||||
tools=[{"type": "web_search_20250305", "name": "web_search"}],
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": "Find 5 ICLR/NeurIPS 2024-2026 papers on speculative decoding with multi-token prediction. Return BibTeX."
|
||||
}]
|
||||
)
|
||||
print(resp.content[0].text)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Conference paper | Thematic, 0.5-1 page |
|
||||
| Survey paper | Chronological + thematic |
|
||||
| Thesis | Dedicated chapter |
|
||||
| Industry blog | "Inspired by" + light citation |
|
||||
| Patent | "Background" with prior art table |
|
||||
|
||||
**기본값**: thematic grouping, 매 group 당 3-5 cites, concurrent work 의 explicit paragraph.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Academic-Writing]] · [[Research-Methodology]]
|
||||
- 변형: [[Survey-Paper]] · [[Literature-Review]]
|
||||
- 응용: [[Conference-Submission]] · [[Thesis]]
|
||||
- Adjacent: [[Citation-Style]] · [[BibTeX]] · [[Semantic-Scholar]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: paper search 의 expand, group prior work 의 thematically, 매 differentiation paragraph 의 draft.
|
||||
**언제 X**: 매 hallucinated citation 의 risk — 매 always verify 의 DOI / arXiv ID.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Citation dump (no commentary)**: "[Smith 2020, Jones 2021, Lee 2022] also did X." — 매 reader 의 differentiation 의 unclear.
|
||||
- **"To the best of our knowledge"**: 매 cliché — 매 specific 의 prefer.
|
||||
- **Concurrent work 의 ignore**: 매 reviewer 의 catch — proactive 의 cite.
|
||||
- **Hallucinated citations**: 매 LLM-generated 매 always 의 verify.
|
||||
- **Self-citation 의 over-rely**: 매 inflate own lineage.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (NeurIPS/ICML author guidelines, Goodson "How to Write Related Work" 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — thematic structure + LaTeX template + comparison table |
|
||||
|
||||
@@ -2,92 +2,163 @@
|
||||
id: wiki-2026-0508-research-methodology
|
||||
title: Research Methodology
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-REME-001]
|
||||
aliases: [Research Methods, Empirical Research, Scientific Method]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, Research-methodology, Scientific-Method, qualitative-reSearch, quantitative-research, rigor]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [research, science, methodology, statistics, ml-research]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: scientific-method
|
||||
---
|
||||
|
||||
# [[Research-Methodology|Research-Methodology]]
|
||||
# Research Methodology
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "방법론의 무기미: '어떻게 이 지식이 진실임을 증명할 것인가'에 대한 과학적 약속이자, 주관적 편향(Bias)을 제거하고 제삼자가 똑같이 따라 해도 같은 결과가 나오게 보장하는 지적 정직함의 절차."
|
||||
## 매 한 줄
|
||||
> **"매 a result without a method is folklore."**. 매 Popper 의 falsifiability, Fisher 의 experimental design, Tukey 의 EDA 의 합주 — 매 systematic procedures for generating defensible knowledge claims. 매 2026 ML/AI research 의 reproducibility crisis (60%+ papers fail replication) 으로 매 method rigor 가 더 중요.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
연구 방법론(Re[[Search-Methodology|Search-Methodology]])은 연구 문제를 해결하기 위해 채택하는 포괄적인 원칙과 방법입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **양대 산맥**:
|
||||
* **Quantitative (양적 연구)**: 숫자와 통계로 현상을 증명 (객관성 중시). ([[Analysis|Analysis]]와 연결)
|
||||
* **Qualitative (질적 연구)**: 심층 인터뷰와 맥락 분석으로 의미 파악 (깊이 중시).
|
||||
2. **핵심 단계**:
|
||||
* 가설 설정 -> 데이터 수집 -> 분석 -> 검증 -> 결론 도출. (Scientific-Method와 연결)
|
||||
3. **왜 중요한가?**:
|
||||
* 방법론이 부실한 지식은 사상누각(Sandcastle)이며, 논박의 대상조차 되지 못하는 '의결'에 불과하기 때문임. ([[Reliability|Reliability]]의 기반)
|
||||
### 매 spectrum
|
||||
- **Quantitative**: 매 numeric, statistical inference, causal claims.
|
||||
- **Qualitative**: 매 thematic, interpretivist, descriptive depth.
|
||||
- **Mixed-methods**: 매 sequential or concurrent triangulation.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 실험실 통제 정책에만 집착했으나, 현대 정책은 실제 세상의 거대한 로그 데이터 정책을 실시간으로 분석하는 '관찰적 연구 방법론 정책'이 빅데이터 시대의 새로운 표준 정책이 됨(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 연구 방법론 정책에서는 실험 결과의 재현성(Reproducibility) 정책 확보를 위해 코드와 환경(Docker 등)까지 통째로 공유하는 '오픈 사이언스 방법론 정책'이 필수적임.
|
||||
### 매 designs
|
||||
- **Experimental**: 매 RCT — random assignment to treatment/control.
|
||||
- **Quasi-experimental**: 매 diff-in-diff, regression discontinuity, synthetic control.
|
||||
- **Observational**: 매 cross-sectional, longitudinal, case-control.
|
||||
- **Computational**: 매 ablation, benchmark, simulation, A/B.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scientific-Method|Scientific-Method]], [[Analysis|Analysis]], [[Reliability|Reliability]], [[Probabilistic-Reasoning|Probabilistic-Reasoning]], [[Mastery|Mastery]]
|
||||
- **Modern Tech/Tools**: Statistical software (R, Python), Survey tools, Experimental design.
|
||||
---
|
||||
### 매 quality criteria
|
||||
- **Validity**: 매 construct, internal, external, statistical conclusion.
|
||||
- **Reliability**: 매 repeatable measurement.
|
||||
- **Reproducibility**: 매 same data + code → same result.
|
||||
- **Replicability**: 매 new data, same protocol → consistent result.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. ML paper: 매 ablation table + seed-variance + held-out test set.
|
||||
2. Product A/B: 매 power analysis → sample size → MDE.
|
||||
3. UX study: 매 mixed-method (interview + log analytics).
|
||||
4. AI safety eval: 매 capability + propensity + control evaluations.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Power analysis before experiment
|
||||
```python
|
||||
from statsmodels.stats.power import NormalIndPower
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
analysis = NormalIndPower()
|
||||
n = analysis.solve_power(effect_size=0.2, alpha=0.05, power=0.8, ratio=1.0)
|
||||
print(f"매 minimum sample per arm: {int(n)+1}")
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: Pre-registration template (YAML)
|
||||
```yaml
|
||||
# 매 preregistration.yaml — 매 commit BEFORE running experiment
|
||||
hypothesis: "매 LLM with chain-of-thought scores ≥ 5pp higher on GSM8K vs no-CoT"
|
||||
primary_outcome: gsm8k_accuracy
|
||||
n_per_arm: 1000
|
||||
conditions: [no_cot, cot]
|
||||
analysis: paired_t_test
|
||||
exclusion_criteria: ["api_error", "max_tokens_truncated"]
|
||||
seeds: [0, 1, 2, 3, 4]
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Reproducible experiment seed control
|
||||
```python
|
||||
import random, numpy as np, torch, os
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def set_all_seeds(s):
|
||||
random.seed(s); np.random.seed(s); torch.manual_seed(s)
|
||||
torch.cuda.manual_seed_all(s)
|
||||
os.environ["PYTHONHASHSEED"] = str(s)
|
||||
torch.backends.cudnn.deterministic = True
|
||||
torch.backends.cudnn.benchmark = False
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 4: Ablation table generation
|
||||
```python
|
||||
import itertools, pandas as pd
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
def ablation_runs(components, base_run):
|
||||
rows = []
|
||||
for subset in itertools.combinations(components, len(components)-1):
|
||||
cfg = base_run.copy();
|
||||
removed = [c for c in components if c not in subset][0]
|
||||
cfg["removed"] = removed
|
||||
cfg["score"] = run(cfg)
|
||||
rows.append(cfg)
|
||||
return pd.DataFrame(rows)
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 5: Confidence interval reporting (not just p-values)
|
||||
```python
|
||||
import scipy.stats as st
|
||||
def ci(scores, alpha=0.05):
|
||||
m = np.mean(scores); s = np.std(scores, ddof=1); n = len(scores)
|
||||
h = s / np.sqrt(n) * st.t.ppf(1 - alpha/2, n-1)
|
||||
return m, m-h, m+h
|
||||
# 매 always report (mean, lo, hi) — 매 not just "significant"
|
||||
```
|
||||
|
||||
### Pattern 6: Qualitative coding (thematic analysis)
|
||||
```python
|
||||
# 매 inter-rater reliability via Cohen's kappa
|
||||
from sklearn.metrics import cohen_kappa_score
|
||||
kappa = cohen_kappa_score(coder_a_codes, coder_b_codes)
|
||||
assert kappa > 0.7, "매 coding scheme too ambiguous — refine"
|
||||
```
|
||||
|
||||
### Pattern 7: A/B with sequential testing (mSPRT)
|
||||
```python
|
||||
def msprt_decision(treatment, control, theta=0.01):
|
||||
"""매 mixture sequential probability ratio test — 매 anytime-valid."""
|
||||
# Lindon & Malek 2020 — 매 lets you peek without inflating type-I
|
||||
pass # use external lib like `confseq`
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Design |
|
||||
|---|---|
|
||||
| 매 cause-effect claim | RCT or quasi-experimental |
|
||||
| 매 description / mapping | Observational + descriptive stats |
|
||||
| 매 user "why" | Qualitative interview + thematic |
|
||||
| 매 ML model claim | Ablation + multiple seeds + held-out |
|
||||
| 매 product feature decision | A/B with power analysis + pre-reg |
|
||||
| 매 emerging behavior | Mixed-methods |
|
||||
|
||||
**기본값**: 매 pre-register + multiple seeds + report CIs + share code & data.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Philosophy of Science]] · [[Statistics]]
|
||||
- 변형: [[Experimental Design]] · [[Qualitative Methods]] · [[Causal Inference]]
|
||||
- 응용: [[ML Research]] · [[A/B Testing]] · [[UX Research]] · [[AI Evaluation]]
|
||||
- Adjacent: [[Reproducibility Crisis]] · [[Pre-registration]] · [[Tukey EDA]] · [[Popper Falsifiability]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 designing experiments, 매 reviewing methodology of papers, 매 drafting pre-registrations.
|
||||
**언제 X**: 매 producing fake citations / fabricating data — 매 catastrophic ethics violation.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **HARKing** (Hypothesizing After Results Known): 매 makes p-values meaningless.
|
||||
- **p-hacking**: 매 trying many tests until significant.
|
||||
- **Single seed reporting**: 매 ML papers — 매 noise dressed as signal.
|
||||
- **Overfitting to test set**: 매 multi-stage benchmarks → 매 leakage.
|
||||
- **No pre-registration**: 매 invites unconscious bias.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Popper 1959, Fisher 1935, Open Science Framework, Pineau et al. 2021 ML reproducibility checklist).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — design spectrum + ML reproducibility focus |
|
||||
|
||||
+131
-40
@@ -2,65 +2,156 @@
|
||||
id: wiki-2026-0508-roblox
|
||||
title: Roblox
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Roblox Studio, Roblox Platform, RBLX]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [gaming, platform, ugc, luau]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: luau
|
||||
framework: roblox-studio
|
||||
---
|
||||
|
||||
# [[Roblox|Roblox]]
|
||||
# Roblox
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Roblox는 사용자 생성 콘텐츠(UGC)를 기반으로 하는 거대한 게임 및 크리에이터 경제 플랫폼으로, 전체 플레이어의 56%가 16세 미만의 어린이와 청소년으로 구성되어 있습니다 [1]. 가상 놀이터, 교실, 쇼핑몰 등 현실 세계를 모방한 환경을 제공하며, 상거래가 깊이 통합된 풀뿌리(grassroots) 중심의 생태계를 구축하고 있습니다 [1]. 향후 Roblox는 단순한 게임을 넘어 하드웨어에 구애받지 않는([[Hardware|Hardware]]-agnostic) 본격적인 게임 유통 플랫폼으로 진화하여 게임 산업의 새로운 패러다임을 주도할 것으로 전망됩니다 [2].
|
||||
## 매 한 줄
|
||||
> **"매 user-generated 3D experience platform 의 dominant"**. Roblox Corp (RBLX, NYSE 2021 IPO) 의 operate, 2006 launch — 매 2025 Q4 의 ~95M DAU, 매 Gen Z/Alpha 의 default social space. 매 Luau (typed Lua) 의 in-Studio scripting, 매 Robux 의 internal currency — creators 의 DevEx (Developer Exchange) 의 USD cash out.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **UGC 기반의 막대한 크리에이터 경제:** Roblox는 사용자가 직접 게임 콘텐츠를 만들고 수익을 창출할 수 있는 강력한 크리에이터 경제(Creator Economy)를 운영하고 있습니다. 2024년 한 해 동안 크리에이터들에게 지급된 수익은 9억 2,300만 달러에 달했습니다 [3]. 플랫폼 내에는 160만 명의 수익 창출 크리에이터가 존재하며, 이들은 지금까지 1억 개 이상의 UGC 경험을 만들어내며 경제를 견인하고 있습니다 [4].
|
||||
* **주요 사용자층과 상거래의 통합:** 부모들이 자녀에게 처음 소개하는 대표적인 게임 중 하나인 Roblox는 저해상도(low-fi) 콘텐츠를 제공하면서도, 게임 내 가상 세계에 상거래를 매우 깊게 통합하고 있습니다 [1, 5]. 사용자들은 이 플랫폼을 통해 현실 세계와 유사한 경제 및 사회적 상호작용을 경험하게 됩니다 [1].
|
||||
* **하드웨어 제약을 벗어난 유통 플랫폼으로의 진화:** 콘솔이나 특정 하드웨어가 플랫폼과 유통을 통제하던 기존의 산업 패러다임과 대조적으로, Roblox는 플랫폼 자체가 하드웨어에 얽매이지 않는 독자적인 유통 플랫폼으로 작동합니다 [2]. 이는 Roblox가 포트나이트([[Fortnite|Fortnite]])와 함께 향후 게임 산업의 다음 단계를 이끌어갈 리더 위치에 있음을 시사합니다 [2].
|
||||
* **플랫폼 내 폭발적 참여 사례:** 게임 내 경제 및 참여도의 엄청난 잠재력을 보여주는 사례로, UGC와 코지 게이밍(cozy gaming) 트렌드가 결합된 플랫폼 내 히트작 'Grow a Garden'은 2025년 여름 최고 동시 접속자 수 1,600만 명을 기록하기도 했습니다 [4].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[사용자 생성 콘텐츠(UGC)|사용자 생성 콘텐츠(UGC]], 크리에이터 경제(Creator Economy
|
||||
- **Projects/Contexts:** 하드웨어에 구애받지 않는 플랫폼(Hardware-Agnostic Platforms, Grow a Garden
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
|
||||
### 매 Architecture
|
||||
- **Roblox Studio** (Windows/Mac IDE) — 매 build, test, publish.
|
||||
- **Roblox Engine** — proprietary, C++ core + Luau scripting.
|
||||
- **Cloud-hosted servers** — 매 experience 의 instance 의 spin up on demand.
|
||||
- **Cross-platform clients** — Windows, Mac, iOS, Android, Xbox, Quest VR (2024 GA).
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
### 매 Luau Language
|
||||
- Lua 5.1 의 fork + gradual typing.
|
||||
- JIT (native code generation) 의 2023 ship.
|
||||
- Strict / non-strict mode.
|
||||
- `--!strict` 매 file 의 top.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. UGC games — Adopt Me!, Blox Fruits, Brookhaven 의 billion-visit hits.
|
||||
2. Brand activations — Nike Land, Gucci Town, K-pop 의 concert.
|
||||
3. Education — coding camp 의 entry, 매 simple Luau syntax.
|
||||
4. Virtual economy — 매 creator earnings $700M+ in 2024.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Basic part script (Luau)
|
||||
```lua
|
||||
--!strict
|
||||
local Players = game:GetService("Players")
|
||||
local part = script.Parent :: BasePart
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
part.Touched:Connect(function(hit: BasePart)
|
||||
local char = hit.Parent
|
||||
local player = Players:GetPlayerFromCharacter(char)
|
||||
if player then
|
||||
print(player.Name .. " touched the part!")
|
||||
end
|
||||
end)
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### RemoteEvent (server ↔ client)
|
||||
```lua
|
||||
-- ServerScriptService/Main.server.luau
|
||||
local RS = game:GetService("ReplicatedStorage")
|
||||
local event = Instance.new("RemoteEvent", RS)
|
||||
event.Name = "GiveCoins"
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
event.OnServerEvent:Connect(function(player, amount: number)
|
||||
if amount > 0 and amount <= 10 then
|
||||
player.leaderstats.Coins.Value += amount
|
||||
end
|
||||
end)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
-- StarterPlayer/StarterPlayerScripts/Client.client.luau
|
||||
local RS = game:GetService("ReplicatedStorage")
|
||||
RS:WaitForChild("GiveCoins"):FireServer(5)
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
### DataStore (persistent save)
|
||||
```lua
|
||||
local DSS = game:GetService("DataStoreService")
|
||||
local store = DSS:GetDataStore("PlayerData_v2")
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
local function save(player: Player, data: {coins: number})
|
||||
local ok, err = pcall(function()
|
||||
store:SetAsync(tostring(player.UserId), data)
|
||||
end)
|
||||
if not ok then warn("save failed:", err) end
|
||||
end
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Roact UI component (modern)
|
||||
```lua
|
||||
local Roact = require(game.ReplicatedStorage.Roact)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
local function Button(props)
|
||||
return Roact.createElement("TextButton", {
|
||||
Text = props.label,
|
||||
Size = UDim2.new(0, 200, 0, 50),
|
||||
[Roact.Event.Activated] = props.onClick,
|
||||
})
|
||||
end
|
||||
|
||||
Roact.mount(Roact.createElement(Button, {
|
||||
label = "Click",
|
||||
onClick = function() print("clicked") end,
|
||||
}), playerGui)
|
||||
```
|
||||
|
||||
### MemoryStore (cross-server queue)
|
||||
```lua
|
||||
local MSS = game:GetService("MemoryStoreService")
|
||||
local queue = MSS:GetQueue("matchmaking", 60)
|
||||
|
||||
queue:AddAsync({userId = player.UserId, mmr = 1500}, 30)
|
||||
local items, id = queue:ReadAsync(8, false, 0)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Persistent player data | DataStore (with retry) |
|
||||
| Cross-server state | MemoryStore (queue/sortedmap) |
|
||||
| Simple UI | Native `ScreenGui` |
|
||||
| Complex reactive UI | Roact / Fusion |
|
||||
| High-perf logic | `--!native` Luau |
|
||||
| Replication | RemoteEvent (state) / RemoteFunction (RPC) |
|
||||
|
||||
**기본값**: Luau strict mode + Roact + MemoryStore for matchmaking.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Game-Platforms]] · [[UGC]]
|
||||
- 변형: [[Roblox-Studio]] · [[Luau]]
|
||||
- 응용: [[Adopt-Me]] · [[Brand-Metaverse]]
|
||||
- Adjacent: [[Unity]] · [[Unreal]] · [[Minecraft]] · [[Fortnite-UEFN]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Luau snippet 의 generate, Studio API lookup, game design pattern 의 explain.
|
||||
**언제 X**: TOS-violating exploit / Filtering Enabled bypass — 매 platform-ban 의 risk.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **`while true do ... end` without `wait()`**: 매 server crash.
|
||||
- **Trusting client `RemoteEvent` args**: 매 always validate server-side (exploiters 의 send anything).
|
||||
- **DataStore on every change**: 매 6-second SetAsync limit — debounce + session-locking 의 use.
|
||||
- **`script.Parent` 의 deep traversal**: 매 brittle — `WaitForChild` 의 use.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (create.roblox.com docs, Roblox 2024 Investor Day).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Luau patterns + DataStore/MemoryStore + Roact |
|
||||
|
||||
@@ -2,96 +2,159 @@
|
||||
id: wiki-2026-0508-role-of-conflict-in-narrative
|
||||
title: Role of Conflict in Narrative
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-CNAR-001]
|
||||
aliases: [Narrative Conflict, Story Conflict, Dramatic Conflict]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, storytelling, narrative, conflict, Psychology]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [storytelling, writing, narrative, drama]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: english-korean
|
||||
framework: narrative-craft
|
||||
---
|
||||
|
||||
# [[Role of Conflict in Narrative|Role of Conflict in Narrative]]
|
||||
# Role of Conflict in Narrative
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "이야기의 심장 박동: 주인공의 안온한 일상을 깨뜨리고 변화를 강제하는 저항력이자, 독자가 다음 페이지를 넘기게 만드는 서사의 유일한 에너지원."
|
||||
## 매 한 줄
|
||||
> **"매 story 의 engine 의 conflict — desire vs obstacle"**. Aristotle 의 *Poetics* (335 BCE) 의 *agon* 의 origin, 매 modern beat-sheet (Save the Cat, Hero's Journey) 의 same axis 의 reuse. 매 conflict 의 absence 의 narrative 의 dead — character change 의 vehicle 의 obstacle 의 friction.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
서사 내 갈등의 역할은 이야기의 구조를 형성하고 등장인물의 성장을 이끌어내며 주제 의식을 전달하는 핵심 장치입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **갈등의 종류 (4대 고전)**:
|
||||
* **Man vs. Self (내적 갈등)**: 자신의 욕망, 도덕, 공포와의 싸움. (예: 햄릿의 고뇌)
|
||||
* **Man vs. Man (외적 갈등)**: 라이벌이나 악당과의 대립. (예: 셜록 홈즈 vs 모리아티)
|
||||
* **Man vs. Nature/Society**: 가혹한 환경이나 부조리한 사회 시스템과의 싸움.
|
||||
* **Man vs. Technology/Fate**: 통제 불가능한 운명이나 기술적 재앙과의 싸움.
|
||||
2. **기능적 역할**:
|
||||
* **Character Arc**: 갈등을 해결하는 과정에서 인물의 선택이 드러나고 성격이 변화함.
|
||||
* **Pacing & Tension**: 긴장이 고조(Rising Action)되고 절정(Climax)에 이르는 흐름을 결정.
|
||||
* **Theme Revelation**: 무엇을 위해 싸우는가를 보여줌으로써 작가가 말하고자 하는 핵심 가치 투영.
|
||||
3. **게임 시나리오에서의 갈등**:
|
||||
* 플레이어의 목표 달성을 방해하는 '장애물'로서의 역할을 수행하며, 이를 극복했을 때의 '성취감'을 디자인하는 핵심 요소.
|
||||
### 매 Conflict Types (Classical)
|
||||
1. **Person vs Person** — 매 antagonist clash (Iliad, Breaking Bad).
|
||||
2. **Person vs Self** — 매 internal moral struggle (Hamlet, Crime and Punishment).
|
||||
3. **Person vs Society** — 매 institutional pressure (1984, Handmaid's Tale).
|
||||
4. **Person vs Nature** — 매 survival (The Old Man and the Sea, The Martian).
|
||||
5. **Person vs Technology** — 매 modern AI/system conflict (Black Mirror, Ex Machina).
|
||||
6. **Person vs Fate/Supernatural** — 매 destiny challenge (Oedipus, Final Destination).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 선악 구조의 명확한 외부 갈등이 주류였으나, 현대 서사 정책은 '그레이 존(Gray Zone)'에 있는 인물들의 복합적인 내적 갈등과 '시스템적 부조리'로 인한 해결 불가능한 갈등을 다루는 방향으로 진화함(RL Update).
|
||||
- **정책 변화(RL Update)**: 글로벌 미디어 플랫폼들은 다양성 및 포용성(DEI) 지침에 따라, 특정 집단에 대한 고정관념을 강화하는 방식의 갈등 묘사를 지양하고 보다 다각적인 관점에서의 갈등 설계를 장려하는 제작 정책을 시행 중임.
|
||||
### 매 Functional Roles
|
||||
- **Reveals character** — 매 pressure 의 true self.
|
||||
- **Drives plot** — 매 cause-effect chain.
|
||||
- **Creates stakes** — 매 reader 의 emotional investment.
|
||||
- **Forces choice** — 매 character agency 의 demonstrate.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Procedural Narrative Generation|Procedural Narrative Generation]], [[Psychology & Behavior|Psychology & Behavior]], Hero’s Journey Framework, [[Game Design Theory|Game Design Theory]], [[Revenge-Cycle-Dynamics|Revenge-Cycle-Dynamics]]
|
||||
- **Modern Tech/Tools**: Dramatic tension mapping, AI-based script [[Analysis|Analysis]].
|
||||
---
|
||||
### 매 Structure (3-act + conflict escalation)
|
||||
1. **Act 1 setup** — 매 inciting incident 의 conflict 의 introduce.
|
||||
2. **Act 2 confrontation** — 매 rising stakes, midpoint reversal.
|
||||
3. **Act 3 resolution** — 매 climax (peak conflict) → denouement.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Novel/screenplay drafting — 매 each scene 의 micro-conflict 의 require.
|
||||
2. Game narrative — 매 quest design 의 obstacle 의 core.
|
||||
3. Marketing storytelling — 매 customer (hero) vs problem (villain) framing.
|
||||
4. Therapy / personal narrative — 매 reframing internal conflict.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Beat sheet template (Markdown)
|
||||
```markdown
|
||||
# Story: <Title>
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
## Protagonist
|
||||
- Name, want (external goal), need (internal lack).
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
## Antagonist / Obstacle
|
||||
- Force opposing the want.
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
## Beats
|
||||
1. Opening Image — status quo.
|
||||
2. Inciting Incident — conflict introduced (page 10).
|
||||
3. Plot Point 1 — commit to journey (page 25).
|
||||
4. Midpoint — false victory or false defeat.
|
||||
5. Plot Point 2 — all-is-lost moment.
|
||||
6. Climax — peak conflict resolution.
|
||||
7. Closing Image — mirror of opening, transformed.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Conflict density check (Python)
|
||||
```python
|
||||
import re
|
||||
def conflict_score(scene_text: str) -> float:
|
||||
# crude heuristic: conflict verbs per 100 words
|
||||
verbs = re.findall(r"\b(argue|fight|refuse|attack|defy|resist|escape|flee|kill|hate)\b",
|
||||
scene_text, re.I)
|
||||
words = len(scene_text.split())
|
||||
return len(verbs) / max(words, 1) * 100
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
print(conflict_score(open("scene_1.txt").read()))
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Scene goal-conflict-disaster (template)
|
||||
```markdown
|
||||
**Scene 12 — The Confrontation**
|
||||
- Goal: Hero wants to retrieve the key.
|
||||
- Conflict: Antagonist has set a trap.
|
||||
- Disaster: Hero gets the key but loses ally.
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Dialogue subtext (Luau-flavored example for game dev)
|
||||
```lua
|
||||
-- NPC reaction system
|
||||
local function reactToPlayer(npc, action)
|
||||
if npc.relationship < 30 and action == "ask_favor" then
|
||||
npc:say("After what you did? Get out.") -- conflict surfacing
|
||||
elseif npc.relationship > 70 and action == "ask_favor" then
|
||||
npc:say("Anything for you.") -- conflict resolved
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### LLM-assisted conflict generator (Python, Anthropic SDK)
|
||||
```python
|
||||
import anthropic
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
resp = client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=400,
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": "Given a protagonist who fears commitment and an antagonist who is their estranged sibling, generate 3 escalating conflict scenes."
|
||||
}]
|
||||
)
|
||||
print(resp.content[0].text)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Conflict type |
|
||||
|---|---|
|
||||
| Character study | Person vs Self |
|
||||
| Thriller | Person vs Person |
|
||||
| Dystopia | Person vs Society |
|
||||
| Survival | Person vs Nature |
|
||||
| Tech ethics | Person vs Technology |
|
||||
| Tragedy | Person vs Fate |
|
||||
|
||||
**기본값**: 매 layered — 매 external (P vs P) + internal (P vs Self) 의 same character 의 simultaneous.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Storytelling]] · [[Narrative-Theory]]
|
||||
- 변형: [[Three-Act-Structure]] · [[Hero-Journey]] · [[Save-the-Cat]]
|
||||
- 응용: [[Screenwriting]] · [[Game-Narrative]] · [[Marketing-Story]]
|
||||
- Adjacent: [[Character-Arc]] · [[Theme]] · [[Subtext]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: scene 의 brainstorm, conflict beat 의 escalate, antagonist motivation 의 deepen.
|
||||
**언제 X**: real human conflict 의 mediation — 매 fictional craft 의 tool, not therapy.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Manufactured conflict**: 매 character 의 act stupidly 의 plot 의 force — reader 의 feel manipulated.
|
||||
- **No internal conflict**: 매 external action 의 only — 매 character 의 flat.
|
||||
- **Resolved 의 too early**: 매 act 2 의 conflict 의 deflate — sustain 의 climax 의 reach.
|
||||
- **Antagonist 의 motiveless**: 매 generic villain — 매 antagonist 의 own internal logic 의 require.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Aristotle *Poetics*, McKee *Story* 1997, Snyder *Save the Cat* 2005).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 6 conflict types + beat sheet + scene template |
|
||||
|
||||
@@ -2,91 +2,146 @@
|
||||
id: wiki-2026-0508-rule-of-three
|
||||
title: Rule of Three
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Three Strikes Rule, DRY Trigger, Triplication Rule]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [refactoring, dry, software-engineering, code-smell, abstraction]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: agnostic
|
||||
framework: refactoring
|
||||
---
|
||||
|
||||
# [[Rule of Three|Rule of Three]]
|
||||
# Rule of Three
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
인간의 단기 기억 용량 한계를 고려하여 주요 논거나 아이디어를 3개(혹은 최대 3~4개)로 그룹화하여 전달함으로써 기억력과 설득력을 극대화하는 커뮤니케이션 원칙입니다.
|
||||
## 매 한 줄
|
||||
> **"매 첫 두 번의 중복은 참아라. 세 번째에 추상화하라"**. Martin Fowler 가 *Refactoring* (1999) 에서 codify 한 heuristic — 매 premature abstraction 의 cost 가 duplication 의 cost 보다 큰 까닭에, 매 세 번째 instance 에서 야 진짜 pattern 이 보인다는 pragmatic guideline. 매 2026 년 까지 매 senior eng 의 default mental model.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- 인간의 단기 기억은 약 7개(±2개)의 항목만 동시에 보유할 수 있으나, 정보를 그룹화하여 전달할 때 가장 편리하고 마법 같은 숫자는 **'3'**입니다 [61-65].
|
||||
- 피라미드 원칙의 주요 논거(Key arguments)를 구성할 때, 정확히 3개의 상호 배타적인 포인트로 나누어 설명하는 것이 가장 이상적입니다 [65-68].
|
||||
- 3개 미만(예: 1~2개)의 논거는 주장의 엄밀성이 떨어지거나 얇아 보이며, 4개를 초과하면 청중의 인지적 과부하(Cognitive overload)를 일으켜 앞서 말한 내용을 잊어버리게 만듭니다 [65, 67, 68].
|
||||
- 정보가 3개를 넘어가면 뇌는 이를 묶어 기억하기 위해 자연스럽게 논리적 카테고리화를 시도하게 됩니다 [61].
|
||||
## 매 핵심
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Pyramid Principle|Pyramid Principle]], [[MECE Framework|MECE Framework]]
|
||||
- **Projects/Contexts:** 비즈니스 이메일 작성, 프레젠테이션 슬라이드 구성(3 Key Points)
|
||||
- **Contradictions/Notes:** 전달하고자 하는 요점이 5개 이상일 경우, 정보가 덜 요약된(synthesized) 상태임을 의미하므로 이를 다시 상위 3개의 카테고리로 재그룹화(Grouping)해야 합니다 [68, 69].
|
||||
### 매 origin (Don Roberts → Fowler)
|
||||
- Don Roberts 가 처음 articulate, Fowler 가 *Refactoring* (1999) book 에서 popularize.
|
||||
- 매 underlying principle: 매 abstraction 은 매 미래 의 use case 의 prediction. 매 N=2 일 때 prediction 의 sample size 부족. 매 N=3 에서 야 매 commonality 가 진짜 인지 vs 매 우연 인지 distinguishable.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-27*
|
||||
### 매 trade-off
|
||||
- **매 abstraction cost**: 매 wrong abstraction 의 cost ≫ 매 duplication 의 cost (Sandi Metz 의 famous talk: "duplication is far cheaper than the wrong abstraction").
|
||||
- **매 cognitive load**: 매 abstraction 의 매 indirection 추가 → 매 reader 가 매 hop 따라 가야.
|
||||
- **매 lock-in**: 매 abstraction 일찍 commit 시 매 future divergence 시 매 rollback cost 큼.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. **함수 추출**: 매 동일 logic 의 3 번째 copy 시 → extract function.
|
||||
2. **클래스 hierarchy**: 매 3 번째 subclass 의 emerging 시 → introduce base class.
|
||||
3. **Config / parameter**: 매 magic number 의 3 번째 occurrence 시 → constant 화.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Duplication tolerated (N=2)
|
||||
```typescript
|
||||
// 매 OK — 매 2 번 만의 duplication. 매 abstraction X.
|
||||
function calcOrderTotal(items: Item[]) {
|
||||
return items.reduce((sum, i) => sum + i.price * i.qty, 0);
|
||||
}
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
function calcCartPreview(items: Item[]) {
|
||||
// 매 looks similar but 매 different context — leave it.
|
||||
return items.reduce((sum, i) => sum + i.price * i.qty, 0);
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: 3rd occurrence → extract
|
||||
```typescript
|
||||
// 매 3 번째 copy 등장 시 abstract.
|
||||
const sumLineItems = (items: Item[]) =>
|
||||
items.reduce((sum, i) => sum + i.price * i.qty, 0);
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
const calcOrderTotal = sumLineItems;
|
||||
const calcCartPreview = sumLineItems;
|
||||
const calcInvoiceTotal = sumLineItems; // 매 trigger
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Generic-too-early anti-example
|
||||
```typescript
|
||||
// 매 BAD — 매 N=1 에서 매 over-generalize.
|
||||
function processCollection<T, R>(
|
||||
data: T[],
|
||||
reducer: (acc: R, x: T) => R,
|
||||
initial: R,
|
||||
filter?: (x: T) => boolean,
|
||||
mapper?: (x: T) => T
|
||||
): R {
|
||||
// 매 future-proofing 의 환상. 매 actual 사용 = 매 1 case.
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 4: Sandi Metz 의 "prefer duplication"
|
||||
```ruby
|
||||
# 매 duplicate code 는 매 wrong abstraction 보다 매 fix easier.
|
||||
# 매 wrong abstraction = 매 매 caller refactor 필요.
|
||||
class OrderTotal
|
||||
def calculate(items)
|
||||
items.sum { |i| i.price * i.qty }
|
||||
end
|
||||
end
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
class CartPreview
|
||||
def calculate(items)
|
||||
items.sum { |i| i.price * i.qty } # 매 duplicate intentional until N=3
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 5: 매 React component 의 Rule of Three
|
||||
```tsx
|
||||
// 매 1st: inline.
|
||||
<button className="bg-blue-500 px-4 py-2 rounded">Save</button>
|
||||
|
||||
// 매 2nd: 그냥 copy.
|
||||
<button className="bg-blue-500 px-4 py-2 rounded">Cancel</button>
|
||||
|
||||
// 매 3rd: abstract.
|
||||
const PrimaryButton = ({ children, ...rest }) => (
|
||||
<button className="bg-blue-500 px-4 py-2 rounded" {...rest}>{children}</button>
|
||||
);
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 N=1 (one-off) | Inline. 매 abstraction X. |
|
||||
| 매 N=2 (duplication 등장) | Wait. 매 watch for 3rd. |
|
||||
| 매 N=3 (triplication) | Extract — 매 pattern crystallized. |
|
||||
| 매 cross-domain duplication (uncertain pattern) | Wait — 매 4-5 까지 도 OK. |
|
||||
| 매 critical bug-prone duplication | Extract early — 매 correctness ≫ 매 abstraction cost. |
|
||||
|
||||
**기본값**: 매 N=3 까지 wait. 매 doubt 시 duplicate.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[DRY Principle]] · [[Refactoring]]
|
||||
- 변형: [[Premature Abstraction]] · [[YAGNI]]
|
||||
- 응용: [[Extract Function]] · [[Extract Class]]
|
||||
- Adjacent: [[Code Smell]] · [[Sandi Metz Wrong Abstraction]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 codebase 의 duplication 매 detect → 매 N count 후 매 refactor 제안.
|
||||
**언제 X**: 매 N=2 에서 매 LLM 의 over-eager abstraction 제안 — reject.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **DRY 원리주의 (DRY zealotry)**: 매 N=1 에서 매 abstract → 매 wrong shape.
|
||||
- **Forever duplication**: 매 N=10 도 매 ignore — 매 maintenance disaster.
|
||||
- **Hasty generalization**: 매 surface similarity 만 보고 매 abstract — 매 underlying domain 의 different.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Fowler *Refactoring* 1st/2nd ed; Sandi Metz "All the Little Things" RailsConf 2014).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Rule of Three 의 origin/trade-off/patterns/Metz 의 "prefer duplication" 정리 |
|
||||
|
||||
@@ -2,21 +2,31 @@
|
||||
id: wiki-2026-0508-sdlc-ssdlc-소프트웨어-개발-생명주기
|
||||
title: "SDLC & SSDLC (소프트웨어 개발 생명주기)"
|
||||
category: 10_Wiki/Topics
|
||||
status: merged
|
||||
redirect_to: 보안_및_시스템_신뢰성_표준
|
||||
canonical_id: wiki-2026-0507-039
|
||||
status: duplicate
|
||||
canonical_id: sdlc-and-ssdlc
|
||||
duplicate_of: "[[SDLC_and_SSDLC]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, sdlc, ssdlc, software-engineering]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# Redirect
|
||||
# SDLC & SSDLC (소프트웨어 개발 생명주기)
|
||||
|
||||
이 문서는 Canonical 문서인 [[보안_및_시스템_신뢰성_표준]]으로 통합되었습니다.
|
||||
모든 최신 지식과 세부 내용은 위 링크를 참조하십시오.
|
||||
> **이 문서는 [[SDLC_and_SSDLC]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 Korean 표기 variant.
|
||||
- 매 canonical 문서 의 매 SDLC (plan → design → implement → test → deploy → maintain) + SSDLC (security shift-left) 통합 lifecycle 다룸.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[SDLC_and_SSDLC]] (canonical)
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — Korean variant 의 canonical 문서로 redirect |
|
||||
|
||||
+115
-65
@@ -2,91 +2,141 @@
|
||||
id: wiki-2026-0508-sota
|
||||
title: SOTA
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-SOTA-001]
|
||||
aliases: [State of the Art, SOTA Benchmark, Leaderboard]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, sota, State-of-the-art, benchmark, Innovation, Research, peak-performance]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [ml, benchmark, evaluation, research, leaderboard]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: agnostic
|
||||
framework: ml-research
|
||||
---
|
||||
|
||||
# [[SOTA|SOTA]]
|
||||
# SOTA
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "인류 지성의 최전선: 특정 분야에서 현존하는 기술 중 가장 압도적인 성능을 내는 '세계 1위'의 상태이자, 모든 연구자가 넘어서야 할 거대한 벽이자 새로운 출발점."
|
||||
## 매 한 줄
|
||||
> **"매 SOTA = 매 task 의 best 알려진 result"**. State-of-the-Art 의 약자 — 매 ML/research 에서 매 specific benchmark 에 대한 매 highest-scoring approach 의 referrent. 매 2026 년 LLM/diffusion 시대 에서는 매 SOTA 가 매 weeks 단위 로 invalidated 되는 매 fast-moving target.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
SOTA(State-of-the-Art)는 현재까지 발표된 기술이나 연구 중 최고의 성능을 보이는 기술적 수준을 의미합니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **SOTA 증명법**:
|
||||
* **[[Benchmarks|Benchmarks]]**: 공인된 테스트 슈트(예: MMLU, HumanEval)에서 최고 점수 획득.
|
||||
* **Peer Review**: 동료 전문가들의 검증을 거친 논문 발표. ([[Scientific-Method|Scientific-Method]]와 연결)
|
||||
* **Real-world Utility**: 실제 서비스 환경에서의 압도적 효율성 증명. ([[Efficiency|Efficiency]]와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* SOTA를 안다는 것은 '불투명한 안개 속에서 등대'를 찾는 것과 같아, 우리 프로젝트가 헛발질하지 않고 최고의 길로 가고 있는지 확인하는 기준이 되기 때문임.
|
||||
### 매 정의 / scope
|
||||
- **매 task-bound**: 매 SOTA 는 매 always 매 specific benchmark + 매 metric 에 tied. "매 GPT-5 가 SOTA" → 매 vague. "매 GPT-5 가 매 GSM8K 의 SOTA (98.4%)" → 매 valid.
|
||||
- **매 dataset split**: 매 same model 도 매 train/eval split 에 따라 매 ranking 변경 가능.
|
||||
- **매 reproducibility crisis**: 매 SOTA claim 의 매 cherry-picking, 매 hyperparameter tuning, 매 test-set leakage issue 빈번.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 수년간 SOTA가 바뀌지 않았으나, AI 시대에는 자고 일어나면 SOTA가 바뀌는 '광속의 지식 교체 정책' 시대에 진입함(RL Update). (Re[[Search|Search]]와 연결)
|
||||
- **정책 변화(RL Update)**: 단순히 벤치마크 점수 정책만 높은 '숫자용 SOTA 정책'보다는, 실제 사용자의 복합적인 명령 정책을 얼마나 잘 수행하느냐는 '체감형 SOTA 정책(Elo rating 등)'이 더 중요해지고 있음.
|
||||
### 매 modern (2026) landscape
|
||||
- **LLM benchmarks**: MMLU-Pro, GPQA Diamond, SWE-Bench Verified, ARC-AGI-2, HLE (Humanity's Last Exam).
|
||||
- **Coding**: SWE-Bench Verified, LiveCodeBench, Aider polyglot.
|
||||
- **Vision**: ImageNet-2 (재구성 version), COCO 2025, GenAI-Bench (text-to-image).
|
||||
- **매 2026 SOTA 양상**: Claude Opus 4.7, GPT-5, Gemini 3.5 Ultra 의 매 leapfrog. 매 monthly invalidation.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Scientific-Method|Scientific-Method]], [[Efficiency|Efficiency]], [[Research|Research]], [[Innovation|Innovation]], [[Mastery|Mastery]]
|
||||
- **Modern Tech/Tools**: Papers with Code, Hugging Face Leaderboards, Chatbot Arena.
|
||||
---
|
||||
### 매 응용
|
||||
1. **연구 paper**: 매 SOTA result 가 publication 의 매 main currency.
|
||||
2. **Industry adoption**: 매 SOTA model 의 매 production fine-tune 의 base.
|
||||
3. **Investment signal**: 매 lab 의 매 SOTA 달성 = 매 funding signal.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: SOTA evaluation harness
|
||||
```python
|
||||
# 매 evaluation 의 reproducibility 확보.
|
||||
import lm_eval
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
results = lm_eval.simple_evaluate(
|
||||
model="hf",
|
||||
model_args="pretrained=meta-llama/Llama-3.3-70B-Instruct",
|
||||
tasks=["mmlu_pro", "gpqa_diamond", "math_hard"],
|
||||
batch_size=8,
|
||||
num_fewshot=0,
|
||||
)
|
||||
print(results["results"])
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: SOTA leaderboard scrape
|
||||
```python
|
||||
# Papers With Code API.
|
||||
import requests
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
r = requests.get(
|
||||
"https://paperswithcode.com/api/v1/sota/sota-on-mmlu/",
|
||||
headers={"Accept": "application/json"},
|
||||
)
|
||||
top = r.json()["results"][0]
|
||||
print(f"SOTA: {top['paper']['title']} — {top['metrics']}")
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Statistical-significance check
|
||||
```python
|
||||
# 매 SOTA claim 의 매 noise vs 매 real improvement 구분.
|
||||
from scipy.stats import bootstrap
|
||||
import numpy as np
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
baseline = np.array(per_sample_scores_baseline)
|
||||
candidate = np.array(per_sample_scores_candidate)
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
diff = candidate - baseline
|
||||
ci = bootstrap((diff,), np.mean, n_resamples=10_000, confidence_level=0.95)
|
||||
print(f"Δ mean = {diff.mean():.4f}, 95% CI = {ci.confidence_interval}")
|
||||
# 매 CI 가 0 포함 → 매 not significant.
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Pattern 4: Test-set contamination probe
|
||||
```python
|
||||
# 매 model 의 매 train 시 test set 의 leak 확인.
|
||||
from datasets import load_dataset
|
||||
|
||||
test_set = load_dataset("hendrycks/test", split="test")
|
||||
sample = test_set[0]["question"]
|
||||
|
||||
# 매 perplexity test — 매 model 가 매 test sample 의 매 unusually low ppl ?
|
||||
import torch
|
||||
from transformers import AutoModelForCausalLM, AutoTokenizer
|
||||
|
||||
tok = AutoTokenizer.from_pretrained("model-name")
|
||||
mod = AutoModelForCausalLM.from_pretrained("model-name").cuda()
|
||||
inputs = tok(sample, return_tensors="pt").to("cuda")
|
||||
with torch.no_grad():
|
||||
loss = mod(**inputs, labels=inputs.input_ids).loss
|
||||
print(f"PPL = {torch.exp(loss).item()}")
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 새 paper 의 SOTA claim | Significance test + 매 reproduction 확인 |
|
||||
| 매 production model 선택 | 매 SOTA 만 X — latency/cost/license 도 |
|
||||
| 매 research direction | SOTA 의 매 1-2% 차이 chase X — 매 architectural insight 추구 |
|
||||
| 매 benchmark saturated (≥99%) | 매 새 benchmark 로 이동 — Goodhart 회피 |
|
||||
|
||||
**기본값**: 매 SOTA = 매 starting reference, not endpoint. 매 다양 한 axes (latency, cost, robustness) 평가.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Benchmark]] · [[Evaluation Metric]]
|
||||
- 변형: [[Pareto-Frontier SOTA]] · [[Compute-Adjusted SOTA]]
|
||||
- 응용: [[Leaderboard]] · [[Papers With Code]]
|
||||
- Adjacent: [[Goodharts Law]] · [[Reproducibility Crisis]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 task 의 매 current SOTA 의 매 quick lookup, 매 benchmark 추천.
|
||||
**언제 X**: 매 LLM 의 매 training cutoff 후 SOTA — 매 stale info, web search 사용.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **SOTA chasing**: 매 0.1% improvement 만 매 chase — 매 diminishing returns.
|
||||
- **Single-metric tunnel vision**: 매 accuracy 만 — 매 fairness/latency/robustness 무시.
|
||||
- **Benchmark hacking**: 매 test-set tuning, 매 prompt engineering for benchmark only.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Papers With Code; Open LLM Leaderboard; lm-evaluation-harness docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — SOTA 정의/landscape/eval harness/contamination probe 정리 |
|
||||
|
||||
@@ -2,91 +2,155 @@
|
||||
id: wiki-2026-0508-search-space
|
||||
title: Search Space
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-SESP-001]
|
||||
aliases: [State Space, Solution Space, Hypothesis Space]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, Search-space, Optimization, State-Space, configuration-space, combinatorial-explosion]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [algorithms, search, optimization, ai, planning]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: python
|
||||
framework: algorithms
|
||||
---
|
||||
|
||||
# [[Search-Space|Search-Space]]
|
||||
# Search Space
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "가능성의 광활한 대지: 우리가 풀고자 하는 문제의 모든 해답 후보들이 존재할 수 있는 가상의 공간이자, 지능이 가장 효율적인 정답(Global Optimum)을 찾기 위해 탐험해야 할 지적 지도 전체."
|
||||
## 매 한 줄
|
||||
> **"매 search space = 매 algorithm 의 매 explore-able 모든 candidate 의 set"**. 매 problem 을 매 (state, transition, goal) tuple 로 modeling 시 의 전체 reachable state set. 매 search 의 효율 = 매 1) space 의 size 줄이기 + 2) 매 promising region 의 priorit ize.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
탐색 공간(Search-Space)은 알고리즘이 해결책을 찾기 위해 탐색하는 모든 가능한 상태나 경로의 집합입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 도전 (조합 폭발)**:
|
||||
* 변수가 조금만 늘어나도 탐색 공간이 우주적 규모로 커져버리는 현상. ([[Efficiency|Efficiency]]의 적)
|
||||
2. **지능의 대처 (Pruning)**:
|
||||
* 말도 안 되는 경로는 미리 잘라내고(가지치기), 가능성 높은 곳만 집중적으로 뒤짐. (Optimization와 연결)
|
||||
3. **왜 중요한가?**:
|
||||
* 탐색 공간을 어떻게 정의하고 좁히느냐가 알고리즘의 성패를 결정하며, 지능이란 결국 '무한한 공간에서 유한한 시간 내에 최적해를 찾아내는 능력'이기 때문임. ([[Machine Learning (ML)|Machine Learning (ML)]]의 본질)
|
||||
### 매 정의 components
|
||||
- **State**: 매 partial / full solution candidate.
|
||||
- **Initial state**: 매 search 시작 점.
|
||||
- **Successor function**: 매 state → 매 reachable next states.
|
||||
- **Goal test**: 매 state 가 매 valid solution 인지.
|
||||
- **Path cost**: 매 path 의 매 quality metric.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 모든 칸을 다 뒤지는 정책([[Brute-force|Brute-force]])을 선호했으나, 현대 정책은 신경망 정책(Neural nets)이 공간의 고차원 특징 정책을 이해해 '직관적으로' 정답지로 점프하는 '벡터 공간 탐색 정책'으로 진화함(RL Update). ([[Representation-Learning|Representation-Learning]]와 연결)
|
||||
- **정책 변화(RL Update)**: 바둑의 알파고가 수천만 가지 수 중 승리 확률 정책이 높은 곳만 골라낸 것이 바로 탐색 공간 정책을 비약적으로 줄인 현대 AI의 쾌거 정책임. ([[Reinforcement Learning (RL)|Reinforcement Learning (RL)]]와 연결)
|
||||
### 매 size scaling
|
||||
- **Combinatorial explosion**: 매 N-queens 의 N=8 → 매 16M state. N=20 → 매 effectively infinite.
|
||||
- **Branching factor (b)** × **depth (d)** → b^d.
|
||||
- **Pruning** (alpha-beta, constraint propagation, branch-and-bound) → 매 effective space ↓.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Optimization|Optimization]], [[Efficiency|Efficiency]], [[Machine Learning (ML)|Machine Learning (ML)]], [[Representation-Learning|Representation-Learning]], [[Reinforcement Learning (RL)|Reinforcement Learning (RL)]]
|
||||
- **Modern Tech/Tools**: AlphaGo (MCTS), Hyper[[Parameter|Parameter]] tuning, Genetic algorithms.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Pathfinding**: 매 grid/graph 의 매 cell/node space.
|
||||
2. **Game AI**: 매 chess/go 의 매 game tree.
|
||||
3. **Planning**: 매 STRIPS, PDDL 의 매 action sequence space.
|
||||
4. **NAS**: 매 neural architecture 의 매 hyperparameter space.
|
||||
5. **LLM reasoning**: 매 chain-of-thought / tree-of-thought 의 매 reasoning tree.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Generic search space (BFS)
|
||||
```python
|
||||
from collections import deque
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
def bfs(initial, successors, is_goal):
|
||||
frontier = deque([(initial, [])])
|
||||
visited = {initial}
|
||||
while frontier:
|
||||
state, path = frontier.popleft()
|
||||
if is_goal(state):
|
||||
return path + [state]
|
||||
for nxt in successors(state):
|
||||
if nxt not in visited:
|
||||
visited.add(nxt)
|
||||
frontier.append((nxt, path + [state]))
|
||||
return None
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: A* with admissible heuristic (search space reduction)
|
||||
```python
|
||||
import heapq
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def astar(initial, successors, is_goal, heuristic, cost):
|
||||
pq = [(heuristic(initial), 0, initial, [])]
|
||||
seen = {}
|
||||
while pq:
|
||||
_, g, s, path = heapq.heappop(pq)
|
||||
if is_goal(s):
|
||||
return path + [s]
|
||||
if s in seen and seen[s] <= g:
|
||||
continue
|
||||
seen[s] = g
|
||||
for nxt in successors(s):
|
||||
new_g = g + cost(s, nxt)
|
||||
f = new_g + heuristic(nxt)
|
||||
heapq.heappush(pq, (f, new_g, nxt, path + [s]))
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Pattern 3: Constraint propagation (CSP)
|
||||
```python
|
||||
# 매 search space 의 매 prune via 매 arc-consistency.
|
||||
def ac3(domains, constraints):
|
||||
queue = [(x, y) for x in domains for y in constraints.get(x, [])]
|
||||
while queue:
|
||||
x, y = queue.pop(0)
|
||||
if revise(domains, x, y, constraints):
|
||||
if not domains[x]:
|
||||
return False # 매 inconsistent
|
||||
for z in constraints.get(x, []) - {y}:
|
||||
queue.append((z, x))
|
||||
return True
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 4: Tree-of-Thoughts (LLM reasoning space)
|
||||
```python
|
||||
# 매 LLM 의 매 reasoning step 을 매 search node 로.
|
||||
async def tot_search(problem, max_depth=5, beam=3):
|
||||
frontier = [{"state": problem, "trace": []}]
|
||||
for d in range(max_depth):
|
||||
cands = []
|
||||
for node in frontier:
|
||||
thoughts = await llm.expand(node["state"], k=beam)
|
||||
for t in thoughts:
|
||||
cands.append({"state": t, "trace": node["trace"] + [t]})
|
||||
# 매 evaluator (LLM-as-judge) 가 매 top-beam pick.
|
||||
scored = await llm.evaluate(cands)
|
||||
frontier = sorted(scored, key=lambda x: -x["score"])[:beam]
|
||||
if any(is_goal(n["state"]) for n in frontier):
|
||||
break
|
||||
return frontier[0]["trace"]
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 small finite space | BFS / DFS — 매 complete |
|
||||
| 매 large but heuristic-able | A* / IDA* |
|
||||
| 매 huge stochastic | MCTS (UCT) |
|
||||
| 매 continuous space | gradient-based / Bayesian opt |
|
||||
| 매 LLM reasoning | Tree-of-Thoughts / Graph-of-Thoughts |
|
||||
| 매 constraint-rich | CSP solver (Z3, OR-Tools) |
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
**기본값**: 매 first 매 reformulate problem 으로 매 space 의 size ↓ — 매 algorithm choice 보다 효과 큼.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Search Algorithms]] · [[Combinatorial Optimization]]
|
||||
- 변형: [[State Space]] · [[Hypothesis Space]] · [[Game Tree]]
|
||||
- 응용: [[A Star]] · [[MCTS]] · [[Tree of Thoughts]]
|
||||
- Adjacent: [[Branching Factor]] · [[Heuristic Function]] · [[Pruning]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 problem 의 매 search space modeling 의 매 design 도움.
|
||||
**언제 X**: 매 매우 narrow domain (chess engine 등) — specialized solver 가 우위.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **No pruning**: 매 brute-force on b^d=10^15 — 매 wall-clock 의 절망.
|
||||
- **Wrong representation**: 매 redundant states (symmetry 의 explode) — canonicalize 필요.
|
||||
- **Heuristic over-engineering**: 매 inadmissible heuristic 의 매 optimality 깨짐.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Russell & Norvig *AIMA* 4th ed; Yao et al. ToT 2023).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Search Space components/scaling/BFS/A*/CSP/ToT 정리 |
|
||||
|
||||
+134
-41
@@ -2,65 +2,158 @@
|
||||
id: wiki-2026-0508-search
|
||||
title: Search
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-SRCH-001]
|
||||
aliases: [Search Algorithm, Information Retrieval, Lookup]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.98
|
||||
tags: [auto-reinforced, search, information-retrieval, indexing, query, filter, access]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [search, algorithms, ir, retrieval, ai]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: python
|
||||
framework: search-algorithms
|
||||
---
|
||||
|
||||
# [[Search|Search]]
|
||||
# Search
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "현대 지능의 입구: 세상의 모든 정보가 담긴 거대한 인덱스에서 내 질문에 딱 맞는 한 페이지를 찾아내는 과정이자, 인류가 더 이상 '암기'가 아닌 '탐색'으로 지능의 패러다임을 바꾼 결정적 도구."
|
||||
## 매 한 줄
|
||||
> **"매 search = 매 space 의 매 traverse 를 매 objective 의 만족 까지"**. 매 algorithmic search (BFS/DFS/A*) 부터 매 information retrieval (lexical + semantic) 까지 매 unify 하는 매 abstraction. 매 2026 년 의 search 는 매 vector embedding + LLM rerank + agent loop 의 매 hybrid stack.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
검색(Search) 혹은 정보 검색(Information Retrieval)은 방대한 자료 뭉치에서 필요한 정보를 찾아내는 행위와 기술입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **3대 구성 요소**:
|
||||
* **Indexing**: 정보를 미리 정리해서 표(Index)로 만들어둠. ([[Repository|Repository]]와 연결)
|
||||
* **Query**: 사용자가 던지는 질문이나 키워드.
|
||||
* **Ranking**: 수만 개의 결과 중 무엇이 '가장 관련 있는가'를 결정. (Probability와 연결)
|
||||
2. **왜 중요한가?**:
|
||||
* 우리의 뇌는 용량이 유한하지만, 검색이라는 도구를 통해 외부의 무한한 지식을 실시간으로 내 생각에 연결할 수 있기 때문임 (Extended Mind).
|
||||
### 매 search 의 두 의미
|
||||
- **Algorithmic search**: 매 state space 의 매 traverse — 매 BFS, DFS, A*, MCTS.
|
||||
- **Information retrieval (IR)**: 매 corpus 에서 매 query 에 매 relevant document 추출 — 매 BM25, dense vector, hybrid.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 질문한 단어가 들어있는지만 확인하는 '단어 매칭 정책'이었으나, 현대 정책은 단어가 없어도 의미가 통하는 것을 찾아주는 '시맨틱 검색 정책(RAG)'으로 진화함(RL Update). (RAG와 연결)
|
||||
- **정책 변화(RL Update)**: 웹 사이트를 찾는 정책(Search)을 넘어, AI가 검색 결과를 읽고 가공해서 완성된 답변 정책을 내놓는 'Answer Engine 정책(Perplexity 등)'으로 패러다임 정책이 완전히 이동함.
|
||||
### 매 modern stack (2026 IR)
|
||||
- **매 indexing**: BM25 (lexical) + dense embedding (semantic, e.g., voyage-3, text-embedding-3-large).
|
||||
- **매 retrieval**: hybrid (BM25 + ANN) → reciprocal rank fusion (RRF).
|
||||
- **매 rerank**: cross-encoder (e.g., Cohere Rerank 3, BGE-reranker) — top-100 → top-10.
|
||||
- **매 generative answer**: LLM (Claude Opus 4.7 / GPT-5) 의 매 retrieved context 의 매 grounded answer.
|
||||
- **매 agent loop**: 매 multi-hop — 매 search → 매 reason → 매 search again.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Repository|Repository]], [[RAG|RAG]], [[SEO|SEO]], [[Probabilistic-Reasoning|Probabilistic-Reasoning]], [[Efficiency|Efficiency]], [[Information-Society|Information-Society]]
|
||||
- **Modern Tech/Tools**: Google, Elasticsearch, Pinecone (Vector Search), Bing AI.
|
||||
---
|
||||
### 매 응용
|
||||
1. **RAG**: 매 LLM 의 매 long-tail knowledge 보강.
|
||||
2. **Code search**: 매 codebase semantic + AST search.
|
||||
3. **Pathfinding**: 매 robotics, game AI.
|
||||
4. **Game tree**: 매 chess/go 의 매 minimax + MCTS.
|
||||
5. **Web search**: 매 Google, Bing, Perplexity, Exa, Tavily.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Hybrid retrieval (BM25 + dense)
|
||||
```python
|
||||
from rank_bm25 import BM25Okapi
|
||||
import numpy as np
|
||||
from sklearn.metrics.pairwise import cosine_similarity
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
class HybridRetriever:
|
||||
def __init__(self, docs, embeddings, embed_fn):
|
||||
self.docs = docs
|
||||
self.bm25 = BM25Okapi([d.split() for d in docs])
|
||||
self.embs = embeddings
|
||||
self.embed_fn = embed_fn
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
def search(self, query, k=10, alpha=0.5):
|
||||
bm25_scores = self.bm25.get_scores(query.split())
|
||||
q_emb = self.embed_fn(query)
|
||||
dense_scores = cosine_similarity([q_emb], self.embs)[0]
|
||||
# 매 normalize + weighted combine.
|
||||
bm25_n = (bm25_scores - bm25_scores.min()) / (bm25_scores.ptp() + 1e-9)
|
||||
dense_n = (dense_scores - dense_scores.min()) / (dense_scores.ptp() + 1e-9)
|
||||
scores = alpha * dense_n + (1 - alpha) * bm25_n
|
||||
top = np.argsort(-scores)[:k]
|
||||
return [(self.docs[i], scores[i]) for i in top]
|
||||
```
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
### Pattern 2: Reciprocal rank fusion
|
||||
```python
|
||||
def rrf(rankings: list[list[int]], k=60):
|
||||
"""매 rankings: 각 retriever 의 매 doc-id ordered list."""
|
||||
scores = {}
|
||||
for ranking in rankings:
|
||||
for rank, doc_id in enumerate(ranking):
|
||||
scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank)
|
||||
return sorted(scores, key=scores.get, reverse=True)
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 3: LLM rerank
|
||||
```python
|
||||
import anthropic
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
client = anthropic.Anthropic()
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
async def llm_rerank(query: str, candidates: list[str], top_k=5):
|
||||
prompt = f"""Rate each document 1-10 for relevance to query.
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
Query: {query}
|
||||
|
||||
Documents:
|
||||
{chr(10).join(f'[{i}] {c[:300]}' for i, c in enumerate(candidates))}
|
||||
|
||||
Output JSON: {{"scores": [{{"id": 0, "score": 8.5}}, ...]}}"""
|
||||
msg = await client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=1024,
|
||||
messages=[{"role": "user", "content": prompt}],
|
||||
)
|
||||
import json, re
|
||||
data = json.loads(re.search(r"\{.*\}", msg.content[0].text, re.S).group())
|
||||
ranked = sorted(data["scores"], key=lambda x: -x["score"])[:top_k]
|
||||
return [candidates[r["id"]] for r in ranked]
|
||||
```
|
||||
|
||||
### Pattern 4: Agent search loop
|
||||
```python
|
||||
async def agent_search(question, max_steps=5):
|
||||
context = []
|
||||
for step in range(max_steps):
|
||||
plan = await llm.plan(question, context)
|
||||
if plan.action == "answer":
|
||||
return plan.answer
|
||||
if plan.action == "search":
|
||||
results = await retriever.search(plan.query, k=5)
|
||||
context.extend(results)
|
||||
return await llm.answer(question, context)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 keyword-heavy queries | BM25 우위 |
|
||||
| 매 semantic / paraphrase | Dense embedding 우위 |
|
||||
| 매 high-stakes accuracy | Hybrid + cross-encoder rerank |
|
||||
| 매 multi-hop reasoning | Agent loop (search-reason-search) |
|
||||
| 매 small corpus (<10k) | In-memory FAISS / numpy |
|
||||
| 매 large corpus (>1M) | Pinecone / Weaviate / Qdrant / pgvector |
|
||||
|
||||
**기본값**: hybrid (BM25 + dense, RRF fusion) + 매 cross-encoder rerank top-100 → 10.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Information Retrieval]] · [[Search Algorithms]]
|
||||
- 변형: [[BFS]] · [[DFS]] · [[A Star]] · [[MCTS]]
|
||||
- 응용: [[RAG]] · [[Code Search]] · [[Web Search]]
|
||||
- Adjacent: [[Search Space]] · [[Vector Database]] · [[Reranker]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 RAG pipeline 의 매 retrieval / rerank / 매 agent search.
|
||||
**언제 X**: 매 known-key direct lookup — 매 hash table 의 매 LLM 사용 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Dense-only**: 매 keyword 의 매 정확 매칭 의 의미 — BM25 보강 필요.
|
||||
- **No reranker**: top-10 직접 LLM context — 매 noise 많음.
|
||||
- **Unbounded agent loop**: 매 max_steps 없는 agent — 매 cost 폭발.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Lin et al. *Pretrained Transformers for Text Ranking* 2021; RRF Cormack 2009).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Search 의 algorithmic + IR 두 의미, 2026 hybrid stack, BM25/dense/RRF/rerank/agent loop 정리 |
|
||||
|
||||
@@ -2,65 +2,158 @@
|
||||
id: wiki-2026-0508-secondary-research
|
||||
title: Secondary Research
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-SERE-001]
|
||||
aliases: [Desk Research, Literature Review, Existing-Data Analysis]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, secondary-Research, desk-reSearch, literature-review, existing-data, cost-Efficiency]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [research, methodology, literature-review, knowledge-synthesis]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: agnostic
|
||||
framework: research-methods
|
||||
---
|
||||
|
||||
# [[Secondary-Research|Secondary-Research]]
|
||||
# Secondary Research
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "거인들의 어깨 빌리기: 내가 직접 실험실에서 땀 흘리는 대신, 이미 누군가가 고생해서 모아둔 데이터나 논문, 리포트를 수집하고 분석하여 빠르게 결론에 도달하는 '지식의 가성비 사냥'."
|
||||
## 매 한 줄
|
||||
> **"매 secondary research = 매 existing 의 published / collected data 의 매 analysis"**. 매 primary research (raw 새 data 수집) 의 반대. 매 lit review, 매 meta-analysis, 매 industry report 분석, 매 dataset reuse 다 포함. 매 2026 년 LLM-assisted secondary research 가 매 dominant — 매 single researcher 의 매 weeks → 매 hours.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
2차 연구(Secondary-Research) 혹은 데스크 리서치는 이미 발표되거나 수집된 기존 데이터를 가공하여 수행하는 연구입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **장점**:
|
||||
* **Cost-Efficiency**: 직접 실험(Primary)하는 것보다 훨씬 싸고 빠름. (Efficiency와 연결)
|
||||
* **Macroscopic View**: 여러 연구를 합쳐서(Meta-[[Analysis|Analysis]]) 더 큰 흐름 파악 가능. ([[Knowledge synthesis|Knowledge synthesis]]와 연결)
|
||||
* **Baseline Setting**: 새로운 실험을 하기 전, 현재 어디까지 밝혀졌는지 확인.
|
||||
2. **왜 중요한가?**:
|
||||
* 모든 위대한 혁신은 기존 지식의 재해석에서 시작되며, 2차 연구는 그 '재료'를 가장 효율적으로 모으는 과정이기 때문임.
|
||||
### 매 vs primary research
|
||||
- **Primary**: 매 직접 collect — survey, interview, experiment, observation. 매 control 큼, 매 cost 큼.
|
||||
- **Secondary**: 매 already-published 의 reuse — books, papers, gov stats, industry reports, internal docs. 매 cheap, 매 fast, 매 control 작음.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 도서관에서 먼지 쌓인 책을 찾는 정책이었으나, 현대 정책은 AI가 실시간으로 전 세계 웹 정보를 긁어 요약해 주는 'AI 가속 2차 연구 정책'으로 전환됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 본 시스템이 Obsidian을 뒤져 600개 주제 정책을 채우는 과정 자체가 고도로 자동화된 '2차 연구 정책'의 실무 사례이며, 여기서 얻은 통찰 정책이 다시 1차적인 실행(코드 작성 등)으로 이어지는 선순환 구조 정책을 가짐.
|
||||
### 매 source taxonomy
|
||||
- **Academic**: peer-reviewed papers (PubMed, arXiv, Google Scholar, Semantic Scholar, OpenAlex).
|
||||
- **Government**: census, BLS, OECD, World Bank, KOSIS.
|
||||
- **Industry**: Gartner, Forrester, IDC, McKinsey, CB Insights, Statista.
|
||||
- **Internal**: company analytics, post-mortems, design docs.
|
||||
- **Community**: HN, Reddit, GitHub, blog posts (lower trust, higher recency).
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Efficiency|Efficiency]], [[Knowledge synthesis|Knowledge synthesis]], [[Research-Methodology|Research-Methodology]], [[Reference|Reference]], [[Analysis|Analysis]]
|
||||
- **Modern Tech/Tools**: Google Scholar, Statista, McKinsey [[Reports|Reports]], AI Research agents.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Lit review**: 매 새 paper 의 매 background section.
|
||||
2. **Market analysis**: 매 startup 의 매 TAM/SAM/SOM 추정.
|
||||
3. **Competitor research**: 매 product strategy 의 매 input.
|
||||
4. **Meta-analysis**: 매 multiple studies 의 매 effect size 통합.
|
||||
5. **Due diligence**: 매 investment / 매 acquisition 의 매 background.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: LLM-assisted lit review
|
||||
```python
|
||||
import anthropic, asyncio
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
client = anthropic.AsyncAnthropic()
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
async def summarize_paper(abstract: str, question: str):
|
||||
msg = await client.messages.create(
|
||||
model="claude-opus-4-7",
|
||||
max_tokens=512,
|
||||
system="You are a careful research assistant. Cite verbatim.",
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": f"Question: {question}\n\nAbstract:\n{abstract}\n\nIs this relevant? If yes, extract key findings + methodology in 3 bullets.",
|
||||
}],
|
||||
)
|
||||
return msg.content[0].text
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
async def lit_review(question: str, abstracts: list[str]):
|
||||
results = await asyncio.gather(*[summarize_paper(a, question) for a in abstracts])
|
||||
return [r for r in results if "not relevant" not in r.lower()]
|
||||
```
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
### Pattern 2: arXiv / Semantic Scholar fetch
|
||||
```python
|
||||
import requests
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
def search_semantic_scholar(query: str, limit=20):
|
||||
r = requests.get(
|
||||
"https://api.semanticscholar.org/graph/v1/paper/search",
|
||||
params={
|
||||
"query": query,
|
||||
"limit": limit,
|
||||
"fields": "title,abstract,year,authors,citationCount,openAccessPdf",
|
||||
},
|
||||
)
|
||||
return r.json()["data"]
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 3: Citation graph traversal
|
||||
```python
|
||||
def expand_citations(seed_papers, depth=2):
|
||||
frontier = list(seed_papers)
|
||||
seen = set(p["paperId"] for p in seed_papers)
|
||||
for _ in range(depth):
|
||||
next_frontier = []
|
||||
for paper in frontier:
|
||||
r = requests.get(
|
||||
f"https://api.semanticscholar.org/graph/v1/paper/{paper['paperId']}/references",
|
||||
params={"fields": "title,abstract,year,citationCount"},
|
||||
)
|
||||
for ref in r.json().get("data", []):
|
||||
pid = ref["citedPaper"]["paperId"]
|
||||
if pid and pid not in seen:
|
||||
seen.add(pid)
|
||||
next_frontier.append(ref["citedPaper"])
|
||||
frontier = next_frontier
|
||||
return list(seen)
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 4: Source-trust scoring
|
||||
```python
|
||||
def trust_score(source: dict) -> float:
|
||||
base = {
|
||||
"peer-reviewed": 0.9,
|
||||
"preprint": 0.7,
|
||||
"government": 0.85,
|
||||
"industry-paid": 0.6,
|
||||
"blog": 0.4,
|
||||
"social": 0.2,
|
||||
}.get(source["type"], 0.3)
|
||||
age_yrs = 2026 - source["year"]
|
||||
decay = max(0.5, 1 - 0.05 * age_yrs)
|
||||
citations = min(1.0, source.get("citations", 0) / 100)
|
||||
return base * decay * (0.6 + 0.4 * citations)
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 새 topic 빠른 overview | LLM survey + 매 5-10 review papers |
|
||||
| 매 medical / safety claim | Cochrane / systematic review only |
|
||||
| 매 market size estimation | Triangulate 3+ sources (Gartner + government + internal) |
|
||||
| 매 historical trend | Government/longitudinal data |
|
||||
| 매 cutting-edge tech | arXiv (acknowledge non-peer-reviewed) |
|
||||
|
||||
**기본값**: 매 source diversification — 매 single source 의 매 trust X. 매 triangulate ≥3.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Research Methodology]]
|
||||
- 변형: [[Primary Research]] · [[Meta-Analysis]] · [[Systematic Review]]
|
||||
- 응용: [[Literature Review]] · [[Market Research]] · [[Competitor Analysis]]
|
||||
- Adjacent: [[Knowledge Synthesis]] · [[Source-Trust Level]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 abstract 의 매 relevance filter, 매 cross-paper synthesis, 매 lit review draft.
|
||||
**언제 X**: 매 LLM 의 매 hallucinated citations — 매 always 매 source verify.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Single-source bias**: 매 매 1 paper / 매 1 industry report 만 의 매 conclusion.
|
||||
- **Citation laundering**: 매 LLM 생성 citation 의 매 unverified copy-paste.
|
||||
- **Stale data**: 매 fast-moving field (LLM, crypto) 의 매 2-yr-old report 의 매 current 처럼 사용.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Cooper *Research Synthesis and Meta-Analysis* 5th ed; PRISMA 2020 guidelines).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Secondary Research 의 vs primary, source taxonomy, LLM lit-review pipeline, citation graph, trust scoring 정리 |
|
||||
|
||||
@@ -1,25 +1,32 @@
|
||||
---
|
||||
id: wiki-20260508-server-side-rendering-ssr-redir
|
||||
title: Server Side Rendering SSR
|
||||
category: Other
|
||||
status: merged
|
||||
redirect_to: Server Side Rendering (SSR)
|
||||
canonical_id: Server Side Rendering (SSR)
|
||||
category: 10_Wiki/Topics
|
||||
status: duplicate
|
||||
canonical_id: server-side-rendering-ssr
|
||||
duplicate_of: "[[Server-Side Rendering (SSR)]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [redirect]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, ssr, rendering, web-performance, frontend]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-merge 2026-05-08)
|
||||
---
|
||||
|
||||
# Server Side Rendering SSR
|
||||
|
||||
> [!IMPORTANT]
|
||||
> 이 문서는 P-Reinforce Phase 2 자동 MERGE에 의해 **[[Server Side Rendering (SSR)]]**로 통합되었습니다.
|
||||
> **이 문서는 [[Server-Side Rendering (SSR)]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
---
|
||||
*Redirected to: [[Server Side Rendering (SSR)]]*
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 underscore-formatted filename variant.
|
||||
- 매 canonical 문서 의 매 SSR (server-side HTML render) vs CSR/SSG/ISR/RSC trade-offs, Next.js / Remix / SvelteKit 구현 다룸.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Server-Side Rendering (SSR)]] (canonical)
|
||||
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — filename-variant 의 canonical 문서로 redirect |
|
||||
|
||||
@@ -2,93 +2,121 @@
|
||||
id: wiki-2026-0508-sociology-of-knowledge
|
||||
title: Sociology of Knowledge
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-SOKO-001]
|
||||
aliases: [Wissenssoziologie, Social Construction of Knowledge, Mannheim Sociology]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.93
|
||||
tags: [auto-reinforced, sociology, knowledge, Epistemology, social-reality]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [sociology, epistemology, philosophy, knowledge, social-theory]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: agnostic
|
||||
framework: social-theory
|
||||
---
|
||||
|
||||
# [[Sociology of Knowledge|Sociology of Knowledge]]
|
||||
# Sociology of Knowledge
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "무엇을 아느냐는 당신이 어디에 있느냐에 달려 있다: 우리가 진리라고 믿는 것들이 사실은 사회적 위치, 역사적 배경, 권력 관계에 의해 형성된 '사회적 구성물'임을 밝히는 학문."
|
||||
## 매 한 줄
|
||||
> **"매 모든 knowledge 는 매 social context 에 매 embedded"**. Karl Mannheim (*Ideology and Utopia*, 1929) 가 founding 한 매 sub-discipline — 매 truth claims, 매 scientific paradigm, 매 even mathematical conventions 까지 매 producing community 의 매 social structure 의 reflection 이라고 본다. 매 Berger & Luckmann (*Social Construction of Reality*, 1966) 가 매 modern reformulation.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
지식 사회학(Sociology of Knowledge)은 인간의 사고와 지식이 일어나는 사회적 기원을 연구하는 학문입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 명제**:
|
||||
* **Social Construction of Reality**: 현실은 고정된 것이 아니라 사람들의 상호작용과 합의를 통해 만들어짐 (피터 버거, 토마스 루크만).
|
||||
* **Ideology and Utopia**: 지식은 특정 집단의 이해관계를 대변하는 '이데올로기'이거나 변화를 꿈꾸는 '유토피아'적 성격을 가짐 (칼 만하임).
|
||||
2. **분석 대상**:
|
||||
* 상식, 과학적 사실, 종교적 신념 등이 어떻게 정당성을 획득하고 사회적으로 유통되는지 추적.
|
||||
* **Habitus**: 특정 계급적 환경이 개인의 무의식적 성향과 지식 구조를 형성함 (부르디외).
|
||||
3. **현대적 의의**:
|
||||
* 데이터와 알고리즘 역시 개발자의 가치관과 사회적 배경이 투영된 '사회적 산물'임을 인지하게 함.
|
||||
### 매 founders / lineage
|
||||
- **Marx**: 매 economic base → 매 ideological superstructure 의 매 proto-thesis.
|
||||
- **Mannheim** (1929): 매 ideology vs utopia, 매 *Seinsverbundenheit des Wissens* (knowledge's existential bondedness).
|
||||
- **Berger & Luckmann** (1966): 매 reality 의 매 social construction — externalization → objectivation → internalization.
|
||||
- **Kuhn** (1962): 매 paradigm + 매 normal/revolutionary science — 매 scientific knowledge 의 매 community 의 conventions 으로.
|
||||
- **SSK / Strong Programme** (Bloor, Edinburgh, 1976): 매 even successful science 의 매 sociological explanation 가능.
|
||||
- **Latour ANT**: 매 actor-network — 매 human + non-human 의 매 hybrid network 가 매 facts 생산.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 "객관적 진리는 존재한다"는 전제하에 지식을 보았으나, 현대의 포스트모던 지식 정책은 '진리의 다수성'과 '지식의 상대성'을 수용하며 다양한 목소리를 정책에 반영하는 방향으로 선회함(RL Update).
|
||||
- **정책 변화(RL Update)**: AI 모델이 학습하는 데이터가 특정 국가나 계층에 편중되어 '지식의 식민화'를 일으키는 것을 막기 위해, 데이터 수집 단계부터 사회적 다양성을 강제하는 '글로벌 지식 정의 정책'이 글로벌 표준으로 논의 중임.
|
||||
### 매 핵심 thesis
|
||||
- **매 standpoint epistemology**: 매 knower 의 매 social position 이 매 known 에 영향.
|
||||
- **매 paradigm-bound**: 매 "fact" 자체 가 매 prevailing paradigm 안 에서 만 sense 함.
|
||||
- **매 distinction (Bourdieu)**: 매 cultural capital, 매 habitus 가 매 academic / scientific 의 매 selection 좌우.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Social[[Systems Theory|systems Theory]], [[Philosophy|Philosophy]] of Science, [[Ethics & AI|Ethics & AI]], [[Scientific Communication|Scientific Communication]], [[Semantics & Ontology|Semantics & Ontology]]
|
||||
- **Modern Tech/Tools**: Discourse [[Analysis|Analysis]] software, Algorithmic bias auditing tools.
|
||||
---
|
||||
### 매 응용
|
||||
1. **Science studies**: 매 lab ethnography (Latour & Woolgar *Laboratory Life*).
|
||||
2. **Tech history**: 매 silicon valley 의 매 culture 가 매 tech direction 형성.
|
||||
3. **AI ethics**: 매 ML model 의 매 bias 가 매 producing community 의 매 reflection.
|
||||
4. **Knowledge management**: 매 tacit knowledge (Polanyi/Nonaka) 의 매 social embedding.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
(매 mostly conceptual domain — 매 code patterns 적음, but 매 modern computational social science 의 적용)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Citation network analysis (매 paradigm detection)
|
||||
```python
|
||||
import networkx as nx
|
||||
from sklearn.cluster import SpectralClustering
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
# 매 OpenAlex API 의 citation graph build.
|
||||
def build_citation_graph(seed_papers):
|
||||
G = nx.DiGraph()
|
||||
for p in seed_papers:
|
||||
G.add_node(p["id"], **p)
|
||||
for ref in p["referenced_works"]:
|
||||
G.add_edge(p["id"], ref)
|
||||
return G
|
||||
|
||||
## 🧪 검증 상태 (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
|
||||
# 매 community detection — 매 paradigm proxy.
|
||||
def detect_paradigms(G, k=5):
|
||||
A = nx.to_scipy_sparse_array(G.to_undirected())
|
||||
sc = SpectralClustering(n_clusters=k, affinity="precomputed_nearest_neighbors")
|
||||
labels = sc.fit_predict(A)
|
||||
return dict(zip(G.nodes, labels))
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: Bias-in-corpus probe
|
||||
```python
|
||||
# 매 ML training corpus 의 매 socio-demographic bias quantify.
|
||||
from collections import Counter
|
||||
import re
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
def occupation_gender_skew(corpus, occupations, pronouns):
|
||||
counts = {occ: Counter() for occ in occupations}
|
||||
for doc in corpus:
|
||||
for occ in occupations:
|
||||
for match in re.finditer(rf"\b{occ}\b\s+\w+\s+(\w+)", doc, re.I):
|
||||
token = match.group(1).lower()
|
||||
if token in pronouns:
|
||||
counts[occ][pronouns[token]] += 1
|
||||
return counts
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 scientific consensus 의 origin 분석 | Kuhn paradigm + 매 citation network |
|
||||
| 매 ML bias audit | Standpoint epistemology — 매 producer demographics |
|
||||
| 매 organizational tacit knowledge | Polanyi/Nonaka SECI model |
|
||||
| 매 tech adoption pattern | Latour ANT — 매 human + non-human |
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
**기본값**: 매 reflexive — 매 자기 의 분석 도 매 같은 sociological forces 의 subject.
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
## 🔗 Graph
|
||||
- 부모: [[Sociology]] · [[Epistemology]]
|
||||
- 변형: [[Strong Programme]] · [[Actor-Network Theory]] · [[Social Construction of Reality]]
|
||||
- 응용: [[Paradigm Shift]] · [[Bias in ML]] · [[Tacit Knowledge]]
|
||||
- Adjacent: [[Philosophy of Science]] · [[Standpoint Theory]] · [[Bourdieu]]
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 academic discipline 의 매 origin / school mapping, 매 paradigm 식별.
|
||||
**언제 X**: 매 LLM 자체 가 매 producing community 의 매 bias 의 carrier — 매 reflexive caution.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Vulgar relativism**: 매 모든 knowledge 가 매 equally valid — Bloor 의 strong programme 의 매 misreading.
|
||||
- **Reductionism**: 매 모든 fact 의 매 social cause 만 — 매 material/empirical evidence 무시.
|
||||
- **Self-exemption**: 매 sociology of knowledge 의 매 itself 에 매 적용 X — 매 reflexivity 결핍.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Mannheim *Ideology and Utopia*; Berger & Luckmann *Social Construction of Reality*; Bloor *Knowledge and Social Imagery*).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Sociology of Knowledge 의 lineage (Marx → Mannheim → Berger/Luckmann → SSK → ANT), thesis, computational adaptations 정리 |
|
||||
|
||||
@@ -2,68 +2,136 @@
|
||||
id: wiki-2026-0508-soft-skills-development
|
||||
title: Soft Skills Development
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-SKDV-001]
|
||||
aliases: [People Skills, Interpersonal Skills, Power Skills, Durable Skills]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, soft-skills, communication, Leadership, emotional-intelligence, workforce]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [career, professional-development, communication, leadership, eq]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: agnostic
|
||||
framework: career-development
|
||||
---
|
||||
|
||||
# [[Soft-Skills-Development|Soft-Skills-Development]]
|
||||
# Soft Skills Development
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "지식보다 중요한 태도의 기술: 기계가 대신할 수 없는 공감, 협업, 비판적 사고, 적응력을 갈고닦아 복잡한 인간 네트워크 속에서 최고의 성과를 이끌어내는 내면의 근력."
|
||||
## 매 한 줄
|
||||
> **"매 soft skills = 매 hard skills 의 매 force-multiplier"**. 매 communication, 매 emotional intelligence, 매 collaboration, 매 negotiation, 매 leadership 등 매 codify-hard 한 interpersonal skills. 매 2026 년 LLM 시대 에서는 매 hard skills 의 매 commoditize → 매 soft skills 가 매 differentiator. World Economic Forum *Future of Jobs 2025* 의 top-10 의 매 7 가 soft skills.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
소프트 스킬 개발(Soft-Skills Development)은 기술적인 전문 지식(Hard Skills)을 제외한, 타인과 상호작용하고 자신의 업무를 효율적으로 관리하는 비인지적 역량을 강화하는 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 역량 (The Core 4)**:
|
||||
* **Communication**: 복잡한 생각을 명확하게 전달하고, 타인의 말을 경청하며 공감하는 능력.
|
||||
* **Critical Thinking**: 고정관념에서 벗어나 데이터와 논리를 바탕으로 최선의 답을 찾아내는 문제 해결력.
|
||||
* **Collaboration**: 다양한 배경을 가진 팀원과 시너지를 내며 공통의 목표를 향해 나아가는 협업 능력.
|
||||
* **[[Adaptability|Adaptability]]**: 급변하는 기술과 환경 속에서 두려움 없이 배우고 성장하는 유연성.
|
||||
2. **개발 방법론**:
|
||||
* **Role-playing**: 가상의 갈등 상황을 시뮬레이션하며 대응책 연습.
|
||||
* **Feedback Loops**: 주기적인 360도 평가를 통해 자신의 사각지대(Blind Spot) 인지 및 교정.
|
||||
* **Mindfulness**: 감정 조절 및 스트레스 관리 능력 향상.
|
||||
### 매 taxonomy (modern WEF 2025)
|
||||
1. **Analytical thinking**: 매 problem 의 매 decompose, 매 evidence weighing.
|
||||
2. **Resilience / flexibility**: 매 setback 후 의 매 recovery + 매 ambiguity tolerance.
|
||||
3. **Leadership / social influence**: 매 vision casting, 매 buy-in 형성.
|
||||
4. **Curiosity / lifelong learning**: 매 self-directed upskilling.
|
||||
5. **Creativity**: 매 novel combinations 생성.
|
||||
6. **Empathy / active listening**: 매 emotional perspective-taking.
|
||||
7. **Self-efficacy / motivation**: 매 internal drive.
|
||||
8. **Talent management**: 매 team 의 매 develop / 매 retain.
|
||||
9. **Service orientation**: 매 customer empathy.
|
||||
10. **Systems thinking**: 매 cause-effect web 매 mapping.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 "있으면 좋은 것"으로 여겨졌으나, AI가 하드 스킬을 빠르게 대체함에 따라 현대 기업의 인재 채용 정책은 소프트 스킬을 '가장 검증하기 어렵지만 가장 치명적인 핵심 역량'으로 재정의함(RL Update).
|
||||
- **정책 변화(RL Update)**: 국가 교육 정책이 단순 지식 암기에서 '사회정서 학습(SEL)'과 '메타인지 역량 강화'로 대전환을 맞이하며, 공교육 과정에 소프트 스킬 측정 및 인증 제도를 도입하려는 움직임이 활발함.
|
||||
### 매 development modalities
|
||||
- **Deliberate practice**: 매 specific feedback loop, 매 challenge zone (Ericsson).
|
||||
- **Reflection**: 매 journaling, 매 after-action review (AAR).
|
||||
- **Mentorship / coaching**: 매 1:1 의 매 high-bandwidth feedback.
|
||||
- **Cross-functional rotation**: 매 different teams / domains 의 exposure.
|
||||
- **Toastmasters / debate clubs**: 매 communication 의 매 deliberate venue.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Psychology & Behavior|Psychology & Behavior]], [[Performance Psychology|Performance Psychology]], [[Organizational Psychology|Organizational Psychology]], Performance systems]], [[Science of Failure|Science of Failure]]
|
||||
- **Modern Tech/Tools**: VR-based soft skills training, AI communication coaches, EQ measurement tools.
|
||||
---
|
||||
### 매 measurement (어려움)
|
||||
- **360-degree feedback**: 매 peer/manager/report 의 매 anonymous input.
|
||||
- **Behavioral interview**: STAR (Situation-Task-Action-Result) format.
|
||||
- **Peer ratings over time**: 매 trend signal.
|
||||
- **매 caveat**: 매 Goodhart — 매 metric 의 매 game-able.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: After-action review template
|
||||
```markdown
|
||||
# AAR — [Project/Event Name]
|
||||
**Date**: 2026-05-10 **Owner**: [name]
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
## 매 What was supposed to happen?
|
||||
- ...
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
## 매 What actually happened?
|
||||
- ...
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
## 매 What went well?
|
||||
- ... (매 specific behaviors, not vague praise)
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
## 매 What could be improved?
|
||||
- ... (매 systems-level, 매 not blame)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
## 매 Lessons / Action items
|
||||
- [ ] [Action] — owner — by [date]
|
||||
```
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
### Pattern 2: Active-listening framework (HEAR)
|
||||
```text
|
||||
H — Halt: 매 own response generation 의 매 pause.
|
||||
E — Engage: 매 eye contact, 매 verbal acknowledgment ("I see").
|
||||
A — Anticipate: 매 speaker 의 매 emotion / unstated need 의 매 detect.
|
||||
R — Replay: 매 paraphrase back ("So what I'm hearing is...").
|
||||
```
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
### Pattern 3: Feedback delivery (SBI model)
|
||||
```text
|
||||
S — Situation: "In yesterday's standup..."
|
||||
B — Behavior: "...you interrupted Maria three times..."
|
||||
I — Impact: "...which I think made her stop sharing her concerns."
|
||||
|
||||
매 specific + 매 behavioral + 매 impact-focused. 매 not 매 personality attack.
|
||||
```
|
||||
|
||||
### Pattern 4: Negotiation prep (BATNA)
|
||||
```text
|
||||
1. 매 internal: 매 your interests vs positions.
|
||||
2. 매 BATNA: 매 Best Alternative To Negotiated Agreement.
|
||||
3. 매 ZOPA: 매 Zone of Possible Agreement (overlap with counterparty).
|
||||
4. 매 anchor: 매 first offer 의 매 prepare.
|
||||
5. 매 walk-away: 매 reservation point.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 IC 단계 의 시작 | Communication + 매 collaboration 우선 |
|
||||
| 매 senior IC / staff | Influence + 매 mentorship |
|
||||
| 매 manager 전환 | EQ + 매 difficult conversations + 매 delegation |
|
||||
| 매 director+ | Strategic communication + 매 org politics |
|
||||
| 매 founder | All-of-the-above + 매 storytelling + 매 negotiation |
|
||||
|
||||
**기본값**: 매 1 skill 의 매 6 month focus — 매 broad shallow X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Career Development]] · [[Professional Development]]
|
||||
- 변형: [[Emotional Intelligence]] · [[Communication Skills]] · [[Leadership]]
|
||||
- 응용: [[Conflict Resolution]] · [[Negotiation]] · [[Public Speaking]]
|
||||
- Adjacent: [[Deliberate Practice]] · [[Growth Mindset]] · [[Active Listening]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 difficult conversation 의 매 rehearsal, 매 feedback draft 의 매 SBI-frame, 매 written communication 의 매 tone polish.
|
||||
**언제 X**: 매 actual interpersonal interaction — 매 LLM 의 매 substitute X. 매 face-to-face practice 필수.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **"Soft" = unimportant**: 매 misnomer — 매 hard skills 의 매 leverage.
|
||||
- **One-shot training**: 매 weekend workshop 만 — 매 deliberate practice 부족.
|
||||
- **Unmeasured improvement**: 매 feedback loop 없는 self-development — 매 plateau.
|
||||
- **Mimicry only**: 매 charismatic leader 의 매 behavior copy — 매 authenticity 결여.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (WEF *Future of Jobs Report 2025*; Ericsson *Peak* 2016; Goleman *Emotional Intelligence* 1995).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Soft Skills 의 WEF 2025 taxonomy, modalities, AAR/HEAR/SBI/BATNA frameworks 정리 |
|
||||
|
||||
+157
-65
@@ -2,91 +2,183 @@
|
||||
id: wiki-2026-0508-state
|
||||
title: State
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-STAT-001]
|
||||
aliases: [Application State, Program State, Stateful, State Management]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.96
|
||||
tags: [auto-reinforced, state, Logic, context, temporary-data, persistence, transition]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [state, programming, architecture, frontend, backend]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: typescript
|
||||
framework: agnostic
|
||||
---
|
||||
|
||||
# [[State|State]]
|
||||
# State
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "찰나의 스냅샷: 과거에 어떤 일이 벌어졌는지에 대한 기억을 머금고 있는 '지금 이 순간의 데이터'이자, 시스템이 다음에 무엇을 할지 결정하기 위해 참조하는 가장 신선한 정보의 응축."
|
||||
## 매 한 줄
|
||||
> **"매 state = 매 program 의 매 time 의 매 snapshot"**. 매 변하는 모든 데이터 — 매 UI 의 input value, 매 server 의 user session, 매 game 의 entity transform 까지. 매 state management 가 매 software complexity 의 매 dominant source — Rich Hickey 의 famous "state is hard" quote (Strange Loop 2009).
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
상태(State)는 고정된 속성이 아니라, 시간의 흐름이나 사건의 발생에 따라 변할 수 있는 동적인 정보의 집합입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **상태 관리의 층위**:
|
||||
* **Transient State**: 메모리에 잠시 머물다 사라지는 상태 (예: 마우스 클릭 좌표).
|
||||
* **Persistent State**: 데이터베이스에 저장되어 세션이 끝나도 유지되는 상태. ([[Storage|Storage]]와 연결)
|
||||
* **Global State**: 시스템 전체가 공유하는 핵심 설정이나 컨텍스트.
|
||||
2. **왜 중요한가?**:
|
||||
* 상태가 꼬이면(State inconsistency) 시스템이 예상치 못한 행동을 하게 되며(Bug), 상태를 잘 설계하는 것이 곧 '예측 가능한 지능'을 만드는 지름길이기 때문임.
|
||||
### 매 분류
|
||||
- **Local / component state**: 매 React `useState`, 매 Vue `ref` — 매 single component scope.
|
||||
- **Shared / global state**: 매 Redux/Zustand/Pinia/Jotai — 매 multiple components share.
|
||||
- **Server state**: 매 React Query/TanStack Query/SWR — 매 server-of-truth 의 매 cache.
|
||||
- **URL state**: 매 query params, hash — 매 shareable / bookmarkable.
|
||||
- **Persistent state**: 매 localStorage, IndexedDB, DB — 매 across sessions.
|
||||
- **Derived state**: 매 computed from base state — 매 NOT stored separately (single source of truth).
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 모든 상태를 명시적으로 저장하는 방식 정책이었으나, 현대 정책은 '함수형 프로그래밍'이나 'Stateless 아키텍처'를 통해 상태를 최소화하고 예측 가능성 정책을 높이는 방향을 선호함(RL Update).
|
||||
- **정책 변화(RL Update)**: 챗봇(LLM) 또한 이전 대화 내용 정책을 '상태'로 관리하며(Context window), 이 상태를 얼마나 길고 정확하게 유지하느냐가 대화의 지능 정책 수준을 결정함.
|
||||
### 매 state 의 trade-off
|
||||
- **매 mutable** vs **매 immutable**: 매 immutability → 매 reasoning easier, 매 time-travel debug 가능, 매 perf cost 일부.
|
||||
- **매 local** vs **매 global**: 매 global → 매 sharing easy, 매 coupling explosion.
|
||||
- **매 client** vs **매 server**: 매 client → 매 latency 0, 매 inconsistency. 매 server → 매 truth 1, 매 latency.
|
||||
- **매 fine-grained** vs **매 coarse**: 매 fine → 매 selective re-render, 매 bookkeeping cost.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Storage|Storage]], [[Logic|Logic]], [[Reliability|Reliability]], [[Scalability|Scalability]], [[Search-Space|Search-Space]]
|
||||
- **Modern Tech/Tools**: Redux, [[React Context|React Context]], Redis (State store), REST API (Stateless).
|
||||
---
|
||||
### 매 modern (2026) frontend stack
|
||||
- **Local**: useState/useReducer (React 19), `$state` (Svelte 5 runes), `ref/computed` (Vue 3.5).
|
||||
- **Global**: Zustand (most popular React), Jotai (atomic), Pinia (Vue), Redux Toolkit (legacy-heavy).
|
||||
- **Server**: TanStack Query 5 (React/Solid/Svelte/Vue), SWR (Vercel), Apollo Client (GraphQL).
|
||||
- **URL**: TanStack Router, Next.js useSearchParams, nuqs.
|
||||
- **Form**: React Hook Form + Zod (de facto), TanStack Form.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Pattern 1: Local state (React)
|
||||
```tsx
|
||||
import { useState } from "react";
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
function Counter() {
|
||||
const [count, setCount] = useState(0);
|
||||
return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Pattern 2: Global state (Zustand)
|
||||
```typescript
|
||||
import { create } from "zustand";
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
interface CartState {
|
||||
items: { id: string; qty: number }[];
|
||||
add: (id: string) => void;
|
||||
remove: (id: string) => void;
|
||||
total: () => number;
|
||||
}
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
export const useCart = create<CartState>((set, get) => ({
|
||||
items: [],
|
||||
add: (id) => set(s => {
|
||||
const existing = s.items.find(i => i.id === id);
|
||||
if (existing) return { items: s.items.map(i => i.id === id ? { ...i, qty: i.qty + 1 } : i) };
|
||||
return { items: [...s.items, { id, qty: 1 }] };
|
||||
}),
|
||||
remove: (id) => set(s => ({ items: s.items.filter(i => i.id !== id) })),
|
||||
total: () => get().items.reduce((s, i) => s + i.qty, 0),
|
||||
}));
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Pattern 3: Server state (TanStack Query)
|
||||
```tsx
|
||||
import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query";
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
function useUser(id: string) {
|
||||
return useQuery({
|
||||
queryKey: ["user", id],
|
||||
queryFn: () => fetch(`/api/users/${id}`).then(r => r.json()),
|
||||
staleTime: 60_000,
|
||||
});
|
||||
}
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
function useUpdateUser() {
|
||||
const qc = useQueryClient();
|
||||
return useMutation({
|
||||
mutationFn: (u: User) => fetch(`/api/users/${u.id}`, { method: "PUT", body: JSON.stringify(u) }),
|
||||
onSuccess: (_, u) => qc.invalidateQueries({ queryKey: ["user", u.id] }),
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
### Pattern 4: URL state (nuqs)
|
||||
```tsx
|
||||
import { useQueryState, parseAsInteger } from "nuqs";
|
||||
|
||||
function ProductList() {
|
||||
const [page, setPage] = useQueryState("page", parseAsInteger.withDefault(1));
|
||||
const [sort, setSort] = useQueryState("sort", { defaultValue: "name" });
|
||||
// 매 URL = ?page=2&sort=price → 매 shareable, 매 back-button works.
|
||||
}
|
||||
```
|
||||
|
||||
### Pattern 5: Derived state (NEVER duplicate base)
|
||||
```tsx
|
||||
// 매 BAD — 매 fullName 의 매 별도 state.
|
||||
const [first, setFirst] = useState("");
|
||||
const [last, setLast] = useState("");
|
||||
const [fullName, setFullName] = useState(""); // 매 anti-pattern
|
||||
|
||||
// 매 GOOD — 매 derive on render.
|
||||
const fullName = `${first} ${last}`;
|
||||
|
||||
// 매 expensive case → useMemo.
|
||||
const expensiveResult = useMemo(() => heavyCompute(first, last), [first, last]);
|
||||
```
|
||||
|
||||
### Pattern 6: State machine (XState)
|
||||
```typescript
|
||||
import { setup } from "xstate";
|
||||
|
||||
const trafficLight = setup({}).createMachine({
|
||||
initial: "red",
|
||||
states: {
|
||||
red: { on: { TICK: "green" } },
|
||||
green: { on: { TICK: "yellow" } },
|
||||
yellow: { on: { TICK: "red" } },
|
||||
},
|
||||
});
|
||||
// 매 invalid transition 의 매 compile-time prevention.
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 component-local UI | useState |
|
||||
| 매 2-3 component shared | Lift state up / Context |
|
||||
| 매 app-wide global | Zustand / Jotai |
|
||||
| 매 server data | TanStack Query (NOT global state) |
|
||||
| 매 form | React Hook Form + Zod |
|
||||
| 매 URL-bound | nuqs / TanStack Router |
|
||||
| 매 complex transitions | XState (state machine) |
|
||||
| 매 persistent | Zustand persist middleware / IndexedDB |
|
||||
|
||||
**기본값**: 매 derive whenever possible. 매 store 만 base state. 매 server state 의 매 global state X (TanStack Query 사용).
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[State Management]] · [[Architecture]]
|
||||
- 변형: [[Local State]] · [[Global State]] · [[Server State]] · [[URL State]]
|
||||
- 응용: [[React]] · [[Zustand]] · [[TanStack Query]] · [[XState]]
|
||||
- Adjacent: [[Immutability]] · [[State Machine]] · [[Single Source of Truth]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 state shape 의 매 design 추천, 매 derived vs base 의 매 audit.
|
||||
**언제 X**: 매 LLM 의 매 over-eager Redux 추천 — 매 modern projects 에서 의 outdated.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **State duplication**: 매 derivable 의 매 별도 store — 매 sync bugs.
|
||||
- **Server state in global store**: 매 cache invalidation 손수 reimplement — 매 TanStack Query 사용.
|
||||
- **Prop drilling depth >3**: 매 Context / state lib 의 매 trigger.
|
||||
- **Premature global**: 매 1 component scope 의 매 Zustand store — 매 over-engineering.
|
||||
- **Mutable update**: 매 `state.items.push(x)` (Redux) — 매 React 의 매 re-render miss.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (React 19 docs, TanStack Query v5 docs, Zustand 4.x, XState v5 docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — State 의 분류, 2026 modern stack, useState/Zustand/TanStack Query/nuqs/XState 패턴 + 기본값 결정표 정리 |
|
||||
|
||||
@@ -2,91 +2,165 @@
|
||||
id: wiki-2026-0508-statistical-analysis
|
||||
title: Statistical Analysis
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-STAN-001]
|
||||
aliases: [Statistics, Inferential Statistics, Data Analysis]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [auto-reinforced, statistical-Analysis, inference, p-value, correlation, causation, data-science]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [statistics, hypothesis-testing, regression, bayesian]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Python / R
|
||||
framework: scipy / statsmodels / pymc / R-tidyverse
|
||||
---
|
||||
|
||||
# [[Statistical-Analysis|Statistical-Analysis]]
|
||||
# Statistical Analysis
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "데이터의 속삭임을 듣는 법: 수천 개의 숫자 파편 속에서 우연과 필연을 가려내고, '이 결과가 진짜로 의미 있는지(Significance)' 아니면 운 좋게 한 번 맞은 것인지 수학적으로 판정하는 냉철한 진실 검출기."
|
||||
## 매 한 줄
|
||||
> **"매 데이터의 uncertainty 를 정량화"**. Fisher–Neyman frequentist framework 부터 Gelman 2020s Bayesian workflow까지, 2026 현재 표준은 statsmodels + PyMC 5.x + ArviZ pipeline 으로 reproducible inference를 빌드하는 것이다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
통계 분석(Statistical-Analysis)은 데이터로부터 수치적 특성을 도출하고, 이를 통해 현상을 설명하거나 미래를 예측하는 과정입니다.
|
||||
## 매 핵심
|
||||
|
||||
1. **핵심 도구상자**:
|
||||
* **Descriptive [[Statistics|Statistics]]**: 평균, 분산 등을 통해 데이터의 생김새 요약. (Statistics와 연결)
|
||||
* **Inferential Statistics**: 표본을 통해 모집단의 특성을 추론 (가설 검정). ([[Scientific-Method|Scientific-Method]]와 연결)
|
||||
* **Regression Analysis**: 변수들 간의 관계를 수식으로 표현해 미래값 예측.
|
||||
2. **왜 중요한가?**:
|
||||
* 데이터는 거짓말을 하지 않지만, 분석가는 보고 싶은 대로 데이터를 왜곡할 수 있음. 통계 분석은 이러한 주관을 배제하고 '숫자가 말하는 진실'에 접근하게 돕기 때문임. ([[Reliability|Reliability]]의 핵심)
|
||||
### 매 두 paradigm
|
||||
- **Frequentist**: parameter 는 fixed, data 가 random. p-value, confidence interval, MLE.
|
||||
- **Bayesian**: parameter 도 random, prior + likelihood → posterior. Credible interval, posterior predictive.
|
||||
- **2026 합의**: 매 둘 다 도구 — small n / strong prior 면 Bayesian, large n / regulated 면 frequentist.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌**: 과거에는 작은 표본 데이터 정책(Small data)에 집착했으나, 현대 정책은 방대한 데이터 정책을 실시간으로 분석하는 '빅데이터 통계 정책'과 '머신러닝 알고리즘 정책'이 결합하여 분석의 깊이와 속도 정책이 비약적으로 향상됨(RL Update).
|
||||
- **정책 변화(RL Update)**: 상관관계(Correlation) 정책만 보는 수준을 넘어, 실제로 무엇이 원인인지 밝혀내는 '인과 추론(Causal Inference) 정책'이 현대 비즈니스 통계 분석의 꽃으로 떠오름.
|
||||
### 매 핵심 절차
|
||||
- **EDA**: distribution, missing, outlier, correlation matrix.
|
||||
- **Hypothesis test**: t-test, χ², Mann-Whitney, permutation. Effect size + CI 동봉.
|
||||
- **Regression**: OLS → GLM → mixed-effects → hierarchical Bayesian.
|
||||
- **Model checking**: residual diagnostics, posterior predictive checks, k-fold CV.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Statistics|Statistics]], [[Scientific-Method|Scientific-Method]], [[Reliability|Reliability]], [[Analysis|Analysis]], [[Probabilistic-Reasoning|Probabilistic-Reasoning]], Evidence-Based-Thinking
|
||||
- **Modern Tech/Tools**: R, Python (Pandas/Statsmodels), SPSS, A/B [[Testing|Testing]] buckets.
|
||||
---
|
||||
### 매 응용
|
||||
1. A/B test 분석 (web, ML model rollout).
|
||||
2. Clinical trial efficacy.
|
||||
3. Causal inference (DiD, IV, RDD, double ML).
|
||||
4. Risk modeling (insurance, finance).
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 💻 패턴
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
### Welch's t-test + effect size + CI (scipy 1.13+)
|
||||
```python
|
||||
import numpy as np
|
||||
from scipy import stats
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(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
|
||||
def welch_with_effect(a, b):
|
||||
t, p = stats.ttest_ind(a, b, equal_var=False)
|
||||
n1, n2 = len(a), len(b)
|
||||
s1, s2 = a.var(ddof=1), b.var(ddof=1)
|
||||
pooled = np.sqrt(((n1-1)*s1 + (n2-1)*s2) / (n1+n2-2))
|
||||
cohen_d = (a.mean() - b.mean()) / pooled
|
||||
df = (s1/n1 + s2/n2)**2 / ((s1/n1)**2/(n1-1) + (s2/n2)**2/(n2-1))
|
||||
se = np.sqrt(s1/n1 + s2/n2)
|
||||
crit = stats.t.ppf(0.975, df)
|
||||
diff = a.mean() - b.mean()
|
||||
return dict(t=t, p=p, d=cohen_d, ci=(diff - crit*se, diff + crit*se))
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### OLS regression with diagnostics (statsmodels)
|
||||
```python
|
||||
import statsmodels.api as sm
|
||||
import statsmodels.formula.api as smf
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
model = smf.ols("y ~ x1 + x2 + C(group)", data=df).fit(cov_type="HC3")
|
||||
print(model.summary())
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# diagnostics
|
||||
from statsmodels.stats.diagnostic import het_breuschpagan
|
||||
bp = het_breuschpagan(model.resid, model.model.exog)
|
||||
print("Breusch-Pagan p:", bp[1])
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Hierarchical Bayesian (PyMC 5.x)
|
||||
```python
|
||||
import pymc as pm
|
||||
import arviz as az
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
with pm.Model() as hier:
|
||||
mu_a = pm.Normal("mu_a", 0, 5)
|
||||
sigma_a = pm.HalfNormal("sigma_a", 1)
|
||||
a = pm.Normal("a", mu_a, sigma_a, shape=n_groups)
|
||||
b = pm.Normal("b", 0, 1)
|
||||
sigma = pm.HalfNormal("sigma", 1)
|
||||
mu = a[group_idx] + b * x
|
||||
pm.Normal("y_obs", mu, sigma, observed=y)
|
||||
idata = pm.sample(2000, tune=1000, target_accept=0.95)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
az.plot_trace(idata)
|
||||
az.summary(idata, var_names=["mu_a", "sigma_a", "b"])
|
||||
```
|
||||
|
||||
### Bootstrap CI
|
||||
```python
|
||||
import numpy as np
|
||||
def bootstrap_ci(data, stat=np.mean, n=10_000, alpha=0.05, rng=None):
|
||||
rng = rng or np.random.default_rng(42)
|
||||
boots = stat(rng.choice(data, size=(n, len(data)), replace=True), axis=1)
|
||||
lo, hi = np.quantile(boots, [alpha/2, 1-alpha/2])
|
||||
return stat(data), (lo, hi)
|
||||
```
|
||||
|
||||
### Multiple testing correction
|
||||
```python
|
||||
from statsmodels.stats.multitest import multipletests
|
||||
reject, pvals_corr, _, _ = multipletests(pvals, alpha=0.05, method="fdr_bh")
|
||||
```
|
||||
|
||||
### Causal inference: doubly robust (EconML / DoubleML)
|
||||
```python
|
||||
from econml.dml import LinearDML
|
||||
from sklearn.ensemble import GradientBoostingRegressor
|
||||
|
||||
dml = LinearDML(
|
||||
model_y=GradientBoostingRegressor(),
|
||||
model_t=GradientBoostingRegressor(),
|
||||
discrete_treatment=False,
|
||||
cv=5,
|
||||
)
|
||||
dml.fit(Y, T, X=X, W=W)
|
||||
print(dml.effect(X), dml.effect_interval(X))
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 2-group mean compare, normal-ish | Welch's t-test |
|
||||
| Non-parametric, small n | Mann-Whitney / permutation |
|
||||
| Multi-level data | Mixed-effects (lme4 / statsmodels) |
|
||||
| Strong prior, small n | Bayesian (PyMC) |
|
||||
| Causal effect from observational | DML / IV / RDD |
|
||||
| Many comparisons | FDR (BH), not Bonferroni unless ≤10 tests |
|
||||
|
||||
**기본값**: statsmodels for frequentist, PyMC 5 + ArviZ for Bayesian, EconML for causal.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Mathematics]] · [[Probability Theory]]
|
||||
- 변형: [[Frequentist Statistics]] · [[Bayesian Inference]] · [[Causal Inference]]
|
||||
- 응용: [[A-B Testing]] · [[Clinical Trials]] · [[Econometrics]]
|
||||
- Adjacent: [[Machine Learning]] · [[Experimental Design]] · [[Power Analysis]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: pipeline scaffolding, EDA narrative, model spec translation, plot 코드 생성.
|
||||
**언제 X**: numerical p-value computation 직접 — library 사용. 매 LLM의 hallucinated stat 의 X.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **p-hacking**: 매 multiple test 후 cherry-pick — pre-registration + correction 필수.
|
||||
- **CI vs PI 혼동**: confidence interval ≠ prediction interval. 매 명확히 구분.
|
||||
- **HARKing**: hypothesis after results — exploratory vs confirmatory 분리.
|
||||
- **Naive default prior**: PyMC `Normal(0, 100)` 의 X — domain-informed weakly-informative prior.
|
||||
- **n=30 rule**: 매 myth — distribution shape 기반 결정.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Wasserman "All of Statistics", Gelman BDA3, statsmodels docs 0.14+, PyMC 5.x docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — frequentist + Bayesian + causal patterns |
|
||||
|
||||
@@ -2,69 +2,33 @@
|
||||
id: wiki-2026-0508-supercell의-모바일-게임-개발
|
||||
title: Supercell의 모바일 게임 개발
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
status: duplicate
|
||||
canonical_id: wiki-2026-0508-mobile-game-development
|
||||
duplicate_of: "[[Mobile Game Development]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, mobile-games, supercell, game-dev]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
---
|
||||
|
||||
# [[Supercell의 모바일 게임 개발|Supercell의 모바일 게임 개발]]
|
||||
# Supercell의 모바일 게임 개발
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Supercell(슈퍼셀)은 '클래시 로얄(Clash Royale)'과 같은 모바일 게임을 통해 경제적이고 효율적인 게임 디자인의 정수를 보여줍니다 [1, 2]. 이들의 개발 방식은 제한된 자원인 엘릭서를 활용한 실시간 전략과 기본 자산(Asset)의 영리한 재사용을 중심으로 이루어집니다 [2-4]. 이를 통해 개발 비용과 앱 용량을 최적화하는 동시에, 플레이어에게는 직관적인 학습과 깊이 있는 전략적 딜레마를 제공하여 성공적인 게임 경제 밸런스 및 구조적 무결성을 달성했습니다 [4, 5].
|
||||
> **이 문서는 [[Mobile Game Development]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **경제적인 콘텐츠 재사용(Content Reuse)과 생산성:**
|
||||
Supercell은 기본 유닛의 모델, 텍스처, 사운드 등 기존 자산을 재사용 및 변형하여 다양한 카드를 효율적으로 생산합니다 [3, 6]. 예를 들어, 가장 약하고 저렴한 유닛인 '스켈레톤(1 엘릭서)'을 기반으로 '스켈레톤 군대(3 엘릭서)', '마녀(주기적으로 스켈레톤 소환)', '무덤(마법)' 등의 각기 다른 전략적 카드를 파생시켰습니다 [6-8]. 이러한 재사용 접근 방식은 와이파이 없이 다운로드 가능한 최대 용량인 100MB 이하로 게임 크기를 유지하고 메모리 공간을 절약하며, 개발 일정을 크게 단축하는 이점을 제공합니다 [3].
|
||||
## 핵심 요약 (Supercell-specific aspects)
|
||||
- **Cell 조직**: 매 small autonomous team (5-7명) — 매 game 단위 cell. 매 kill switch culture (Clash Mini, Rush Wars 종료).
|
||||
- **Long-tail live-ops**: Clash of Clans (2012), Hay Day (2012), Clash Royale (2016), Brawl Stars (2017), Squad Busters (2024) — 매 decade-long retention 의 representative case.
|
||||
- **Tech stack**: 매 자체 engine (C++), AWS infra, ML matchmaking (TrueSkill 변형).
|
||||
- **Soft launch playbook**: Canada/Finland/Australia 3-6개월 telemetry → global launch or kill.
|
||||
|
||||
* **직관적인 플레이어 경험과 밸런싱의 단순화:**
|
||||
유닛 자산의 재사용은 플레이어가 새로운 카드를 접했을 때 그 강점과 약점을 쉽게 유추하고 반응할 수 있게 해줍니다 [5]. 또한, 개별 유닛의 기본 유형을 일관되게 유지함으로써 게임 밸런스 조정이 매우 직관적으로 이루어집니다. 가령 '스켈레톤 군대'를 하향(nerf)할 때 단순히 소환되는 스켈레톤의 수를 하나 줄이는 것만으로 밸런싱이 가능합니다 [5]. 나아가, 카드 업그레이드 비용과 레벨당 체력/데미지 상승률을 희귀도에 관계없이 일정한 비율로 표준화하여 대칭성을 확보하고 밸런싱 난이도를 크게 낮췄습니다 [4].
|
||||
## 🔗 Graph
|
||||
- 부모: [[Mobile Game Development]] (canonical)
|
||||
|
||||
* **엘릭서(Elixir) 기반의 자원 관리와 위험-보상(Risk-Reward) 구조:**
|
||||
클래시 로얄의 핵심 경제 자원은 전투 중 실시간으로 차오르는 '엘릭서'입니다 [4, 9, 10]. 1코스트부터 9코스트까지 다양한 비용의 카드를 순환시키는 구조는 플레이어로 하여금 한정된 자원 내에서 최적의 결정을 내려야 하는 단순 및 다중 선택의 딜레마를 지속적으로 제공합니다 [4, 11-14]. 챔피언십 경기의 데이터 분석에 따르면, 플레이어는 평균 엘릭서 비용이 높은 덱을 운영하는 등 더 큰 위험(Risk)을 감수할 때 더 높은 보상(Reward)을 얻어 승리할 수 있는 구조적 특성이 잘 나타나며, 이는 훌륭한 게임플레이의 기반이 됩니다 [15-19].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[게임 경제 설계(Game Economy Design)|게임 경제 설계(Game Economy Design]], 위험과 보상(Risks and Rewards), 자원 관리(Resource [[Management|Management]], 콘텐츠 재사용(Content Reuse
|
||||
- **Projects/Contexts:** [[클래시 로얄(Clash Royale)|클래시 로얄(Clash Royale]]
|
||||
- **Contradictions/Notes:** 자산의 재사용이 자칫 플레이어에게 반복적인 지루함을 유발할 수 있다는 일반적인 우려가 있을 수 있으나, Supercell은 수량, 경제성, 배치 방식 등의 영리한 조정을 통해 이를 극복하고 오히려 플레이어에게 구별되는 다양한 전략을 제공하는 장점으로 승화시켰습니다 [20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-29*
|
||||
|
||||
## 🤖 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 |
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
@@ -2,116 +2,31 @@
|
||||
id: wiki-2026-0508-team-culture-onboarding-팀-문화-및-온
|
||||
title: "Team Culture & Onboarding (팀 문화 및 온보딩)"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
status: duplicate
|
||||
canonical_id: team-culture-and-onboarding
|
||||
duplicate_of: "[[Team Culture and Onboarding]]"
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
confidence_score: 0.9
|
||||
verification_status: redirected
|
||||
tags: [duplicate, culture, onboarding, korean]
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Team Culture & Onboarding (팀 문화 및 온보딩)|Team Culture & Onboarding (팀 문화 및 온보딩]]
|
||||
# Team Culture & Onboarding (팀 문화 및 온보딩)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
팀 문화 및 온보딩은 새로운 구성원이 조직에 신속히 적응하고, 기존 팀원들이 비난 없이 소통하며 지속적으로 성장할 수 있는 환경을 구축하는 활동입니다 [1]. 심리적 안전감(Psychological Safety)을 기반으로 코드 리뷰를 학습의 장으로 활용하며, 온보딩 프로세스를 통해 팀의 기술 표준과 협업 방식을 전수합니다 [4]. 특히 장애 발생 시 블레임리스 포스트모템(Blameless Post-mortem)을 수행하여 비난 대신 시스템적 개선을 도모하는 성숙한 문화를 지향합니다.
|
||||
> **이 문서는 [[Team Culture and Onboarding]] 의 중복본입니다.** Canonical 문서로 redirect.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **심리적 안전감 (Psychological Safety):**
|
||||
* **정의:** 비난받을 두려움 없이 의견을 공유하고 실수를 인정할 수 있는 팀 환경입니다 [1].
|
||||
* **조성 방법:** 피드백을 '사람'이 아닌 '코드'에 집중하고, 질문과 제안의 형태를 활용하여 방어적 태도를 최소화합니다 [1, 5].
|
||||
* **온보딩 프로세스 (Onboarding Process):**
|
||||
* **목적:** 신규 입사자가 팀의 기술 스택, 코딩 컨벤션, 개발 워크플로우를 익히고 실질적인 기여를 시작하도록 돕습니다 [48].
|
||||
* **코드 리뷰의 역할:** 주니어의 PR에 대한 친절하고 교육적인 피드백은 가장 효과적인 실무 교육(OJT) 수단입니다 [8, 9].
|
||||
* **블레임리스 포스트모템 (Blameless Post-mortem):**
|
||||
* **핵심 원칙:** 장애의 원인을 개인의 실수가 아닌 시스템적 결함에서 찾습니다. "누가" 잘못했는가가 아니라 "어떻게" 재발을 방지할 것인가에 집중하여 조직의 복원력을 높입니다.
|
||||
* **멘토링 (Mentoring):** 시니어와 주니어가 짝을 이루어 기술적 역량뿐만 아니라 팀의 문화와 철학을 공유하는 지속적인 파트너십을 형성합니다.
|
||||
## 핵심 요약 (specialization aspects)
|
||||
- 매 한국어 title variant 의 same topic.
|
||||
- 매 팀 문화 + 신규 입사자 onboarding flow 의 내용 의 canonical 의 동일.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **안전감 vs 명확성:** 기분을 상하게 하지 않으려다 피드백이 너무 모호해지는 '피드백 샌드위치'의 함정을 경계해야 합니다 [10]. 진정한 안전감은 어른들 간의 프로페셔널한 소통처럼 "친절하면서도 직접적인" 의견 교환이 가능할 때 완성됩니다 [5, 11].
|
||||
* **온보딩 비용:** 체계적인 온보딩은 초기 리소스 소모가 크지만, 장기적으로 신규 입사자의 생산성 도달 시간(Time to Productivity)을 단축하여 팀 전체의 효율을 높입니다.
|
||||
* **비난 없는 문화의 오해:** 블레임리스(Blameless)가 '책임 없음(Accountability-free)'을 의미하지는 않습니다. 결과에 대한 책임은 팀 전체가 공유하되, 개선의 초점을 시스템에 두는 것입니다.
|
||||
## 🔗 Graph
|
||||
- 부모: [[Team Culture and Onboarding]] (canonical)
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
* **Egoless Programming**: 자신의 코드와 자신을 동일시하지 않는 태도("You are not your code")로 리뷰 수용성을 높이는 철학입니다.
|
||||
* **Constructive Feedback**: 방어적 반응을 유발하지 않으면서 코드 품질을 높이는 구체적인 소통 기술입니다.
|
||||
* **Conventional Comments**: 피드백의 의도를 라벨링하여 오해를 줄이고 안전감을 높이는 시스템적 도구입니다.
|
||||
* **I-Messages (나-전달법**: "너"가 아닌 "나"를 주어로 사용하여 부드럽게 의견을 전달하는 기법입니다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 팀 내 심리적 안전감이 결여되었을 때 코드 리뷰 프로세스에서 발생하는 구체적인 기술적 부채와 이직률 사이의 상관관계는 무엇인가?
|
||||
* 원격/분산 근무 환경에서 텍스트 기반 소통만으로 신규 입사자에게 심리적 유대감과 안전감을 부여하기 위한 커뮤니케이션 전략은 무엇인가?
|
||||
* 주니어가 시니어의 코드를 자유롭게 리뷰할 수 있도록 심리적 장벽을 허물어주는 구체적인 조직적 장치(예: 리버스 멘토링)는 어떻게 운영하는가?
|
||||
* 블레임리스 포스트모템 결과를 실제 시스템 아키텍처 개선으로 자동 연결하는 '피드백-조치' 루프는 어떻게 설계하는가?
|
||||
* 문화적 배경이 다양한 글로벌 팀에서 '직접적 피드백'에 대한 수용도 차이를 극복하기 위한 팀 그라운드 룰(Ground Rules)은 어떻게 설정하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 피드백 작성 시 "너"라는 단어를 배제하고 코드의 동작과 사실에만 집중하여 코멘트를 작성합니다 [45].
|
||||
* **System Design:** PR 크기 제한, 피드백 형식 규정 등 예측 가능한 프로세스를 설계하여 팀원들이 리뷰 과정에서 안정감을 느끼게 합니다 [46].
|
||||
* **Operation / Maintenance:** 장애 발생 후 비난 없는 회고 세션을 운영하고, 도출된 개선 사항을 티켓화하여 시스템을 강화합니다.
|
||||
* **Learning Path:** 온보딩 시 "코드 리뷰는 개인 평가가 아닌 공동 학습의 장"임을 명확히 인지시켜 리뷰에 대한 공포를 제거합니다 [48].
|
||||
* **My Project Relevance:** Conventional Comments와 멘토링 제도를 도입하여 상호 존중과 신뢰 기반의 건강한 엔지니어링 문화를 구축합니다 [49].
|
||||
|
||||
### Adjacent Topics
|
||||
* **DORA Metrics (Cultural Dimension**: 팀 문화가 소프트웨어 배포 성과에 미치는 정량적 영향을 탐구합니다.
|
||||
* **[[Cognitive Load Theory|Cognitive Load Theory]]**: 온보딩 과정에서 신규 입사자에게 전달되는 정보량을 조절하여 학습 효율을 높이는 이론적 배경입니다.
|
||||
|
||||
---
|
||||
*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
## 🕓 변경 이력
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | 중복 처리 — canonical 문서로 redirect |
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user