[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,127 +2,136 @@
|
||||
id: wiki-2026-0508-keeper-of-the-vision
|
||||
title: Keeper of the Vision
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-REINFORCE-WIKI-487AD228]
|
||||
aliases: [Keeper of the Vision, Vision Keeper, 비전 수호자, Architect Role]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.95
|
||||
tags: [keeper-of-the-vision, conceptual-integrity, "conway's-law", software-architecture-erosion, software-architecture-evolution, cognitive-engineering]
|
||||
confidence_score: 0.85
|
||||
verification_status: applied
|
||||
tags: [architecture, leadership, role, organization, technical-direction]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-02
|
||||
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: organizational
|
||||
---
|
||||
|
||||
# [[Keeper of the Vision]]
|
||||
# Keeper of the Vision
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
'Keeper of the Vision(비전의 수호자)'은 소프트웨어 시스템의 전체적인 비전과 개념적 무결성(Conceptual integrity)을 유지하는 소프트웨어 아키텍트의 핵심 역할을 의미합니다 [1]. 이는 Fred Brooks가 1975년 저서 *The Mythical Man-Month*에서 처음 도입한 개념입니다 [1]. 아키텍트는 시스템에 새롭게 추가되는 요소들이 기존 아키텍처의 방향성과 일치하도록 보장하는 책임을 가집니다 [1].
|
||||
## 매 한 줄
|
||||
> **"매 architect 의 most-underrated 의무"**. Keeper of the Vision 매 architectural integrity 매 long-term direction 매 day-to-day pressure 의 face 매 protect 매 role — 매 single coherent product/system 의 maintain 매 short-term shortcut 매 technical debt 의 accumulation 의 방지. Brooks ("Mythical Man-Month"), Fowler 매 emphasized.
|
||||
|
||||
## 📖 Core 소스 Content
|
||||
- **비전과 구현의 분리:** 소프트웨어 시스템의 아키텍처는 시스템이 '무엇을 해야 하고(what it should do)', '어떻게 해야 하는지(how it should do it)'에 대한 전반적인 비전을 나타냅니다. 이 비전은 실제 구현(Implementation)과는 철저히 분리되어야 합니다 [1].
|
||||
- **아키텍트의 주요 역할:** 소프트웨어 아키텍트는 이 비전을 수호하는 'Keeper of the Vision' 역할을 수행합니다 [1].
|
||||
- **개념적 무결성 보존:** 시스템에 어떠한 요소나 기능이 추가될 때, 아키텍트는 그것이 원래 설계된 아키텍처와 일치하는지 확인하여 시스템 전체의 '개념적 무결성(Conceptual integrity)'이 보존되도록 만듭니다 [1].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
소스에 관련 정보가 부족합니다. (제공된 소스에는 'Keeper of the Vision' 역할 자체에 따른 구체적인 부작용, 제약 사항 또는 트레이드오프에 대한 명시적인 설명이 포함되어 있지 않습니다.)
|
||||
### 매 What the Keeper does
|
||||
- **Conceptual integrity**: 매 system 매 단일 mind 의 product 처럼 feel 하도록.
|
||||
- **Veto authority**: 매 vision-violating change 의 block (or escalate).
|
||||
- **Trade-off articulation**: 매 short-term gain vs long-term cost 의 명확.
|
||||
- **Mentorship**: 매 team 매 vision 의 internalize 하도록.
|
||||
- **Public memory**: 매 ADR (Architecture Decision Record) 매 maintain.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
### 매 Tensions
|
||||
- **Speed vs coherence**: 매 PM 매 ship now, 매 keeper 매 do it right.
|
||||
- **Local vs global**: 매 team A 매 best for them, 매 worst for system.
|
||||
- **Innovation vs consistency**: 매 new framework 매 cool, 매 다양 ization 매 maintenance burden.
|
||||
|
||||
#### [관계 유형 A (개념적 기반)]
|
||||
- [[Conceptual integrity]]
|
||||
- 연결 이유: 'Keeper of the Vision'으로서 아키텍트가 궁극적으로 지키고 보존하고자 하는 시스템의 가장 핵심적인 설계 목표이자 속성이기 때문입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍처의 비전이 구현과 분리되어 시스템 전체의 일관성을 유지하는 근본적인 원리.
|
||||
### 매 응용
|
||||
1. **Tech lead role**: 매 small team 매 lead 의 explicit responsibility.
|
||||
2. **Staff/Principal engineer**: 매 cross-team 매 keeper.
|
||||
3. **Game director / Lead designer**: 매 product vision (Miyamoto, Sid Meier model).
|
||||
4. **Open source BDFL**: 매 Linus, Guido, Matz — 매 codified extreme.
|
||||
|
||||
#### [관계 유형 B (조직 및 유지보수 환경)]
|
||||
- [[Conway's Law]]
|
||||
- 연결 이유: Fred Brooks가 *The Mythical Man-Month*에서 함께 언급한 개념으로, 시스템을 설계하는 조직은 그 조직의 커뮤니케이션 구조를 복제한 설계를 낳게 된다는 인지적 제약(Cognitive constraints)을 설명합니다 [1, 2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 아키텍트가 비전을 수호할 때, 개발 팀이나 조직의 구조적 한계와 커뮤니케이션 방식이 아키텍처 설계에 미치는 영향을 파악할 수 있습니다.
|
||||
- [[Software architecture erosion]]
|
||||
- 연결 이유: 아키텍트가 비전을 제대로 수호하지 못했을 때 발생하는 현상으로, 의도된 아키텍처와 실제로 구현된 아키텍처 간의 점진적인 격차가 벌어지는 것을 의미합니다 [3].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비전 유지가 실패할 경우 시스템 품질 저하 및 진화 비용 증가에 미치는 악영향.
|
||||
## 💻 패턴
|
||||
|
||||
### Deeper Research Questions
|
||||
- Fred Brooks가 주창한 '개념적 무결성(Conceptual integrity)'을 현대의 대규모 분산 소프트웨어 프로젝트에서 어떻게 정량적 또는 정성적으로 측정하고 보장할 수 있는가?
|
||||
- 시스템의 '비전'과 '구현'을 분리하는 과정에서 아키텍트와 개발팀 간의 커뮤니케이션 병목 현상이나 오해를 최소화하는 방법은 무엇인가?
|
||||
- 'Keeper of the Vision'이 비전을 유지하지 못했을 때 나타나는 소프트웨어 아키텍처 침식(Erosion)의 초기 징후를 어떻게 자동화된 도구로 포착할 수 있는가?
|
||||
- 비즈니스 요구사항이 급변하는 애자일(Agile) 환경에서 아키텍트가 비전의 수호자 역할을 수행하면서, 지나친 사전 설계(Big design up front)를 피하고 유연성을 확보하는 전략은 무엇인가?
|
||||
- 아키텍처의 일관된 비전을 유지하는 것이 레거시 시스템의 기술 부채(Technical debt) 청산 속도와 충돌할 때 아키텍트는 어떤 기준점(Trade-off)을 가져야 하는가?
|
||||
### Architecture Decision Record (ADR)
|
||||
```markdown
|
||||
# ADR-0042: Use SQLite for embedded analytics, not Postgres
|
||||
|
||||
### Practical Application Contexts
|
||||
- **Implementation:** 아키텍처의 전체적인 비전과 실제 코딩(구현) 작업의 경계를 분리하고, 개발자들이 비전을 벗어나지 않게 구현하도록 명확한 설계 규칙 적용 [1].
|
||||
- **System Design:** 시스템이 무엇을 어떻게 처리해야 하는지에 대한 포괄적이고 일관된 청사진(Vision)을 설계 초기 단계에 확립 [1].
|
||||
- **Operation / Maintenance:** 운영 중 시스템에 새로운 기능이나 모듈을 추가할 때, 그것이 기존 아키텍처의 개념적 무결성을 훼손하지 않는지 지속적으로 감독 및 통제 [1, 3].
|
||||
- **Learning Path:** Fred Brooks의 고전 *The Mythical Man-Month* 학습을 통해 소프트웨어 아키텍트의 근본적인 책임과 역할 파악 [1].
|
||||
- **My Project Relevance:** 프로젝트 내에서 리드 아키텍트 또는 테크 리드 역할을 수행하며, 팀원들의 산출물 및 추가 기능이 초기 아키텍처의 방향성과 일치하도록 유지하는 업무에 적용.
|
||||
|
||||
### Adjacent Topics
|
||||
- [[Software Architecture Evolution]]
|
||||
- 확장 방향: 아키텍처의 기본 비전을 유지하면서도, 변화하는 요구사항과 환경에 맞춰 기존 기능과 시스템 동작을 점진적으로 발전시키고 유지보수하는 아키텍처 진화 과정 탐구 [4].
|
||||
- [[Architecture Decision Records (ADR)]]
|
||||
- 확장 방향: 아키텍트가 비전을 수호하는 과정에서 내리는 핵심적인 설계 결정, 근거, 대안 및 타협점(Trade-offs)을 팀과 공유하고 장기적으로 투명하게 문서화하는 방법론 [5-7].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-02*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
Status: Accepted
|
||||
Date: 2026-04-12
|
||||
Context: Edge devices need local analytics queries...
|
||||
Decision: SQLite + Litestream replication.
|
||||
Consequences:
|
||||
+ zero ops, single binary
|
||||
- no advanced window functions until SQLite 3.45
|
||||
Vision alignment: "operate offline-first" pillar #2.
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Vision artifact (one-pager)
|
||||
```markdown
|
||||
# Product North Star (2026)
|
||||
1. Offline-first: every feature works without network.
|
||||
2. Single-binary deploy: no docker required for self-host.
|
||||
3. Plain-text data: SQLite + JSON, no proprietary blobs.
|
||||
4. Pluggable AI: vendor-neutral, swap Anthropic ↔ local Llama.
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Keeper review checklist (PR template)
|
||||
```markdown
|
||||
- [ ] Aligns with North Star pillars (#1–4)?
|
||||
- [ ] Introduces new dependency? Justify.
|
||||
- [ ] Adds DB migration? Reversible?
|
||||
- [ ] Public API change? ADR required.
|
||||
- [ ] Latency impact measured?
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Conceptual integrity test
|
||||
```python
|
||||
def integrity_smell(diff: Diff) -> list[str]:
|
||||
smells = []
|
||||
if introduces_new_pattern(diff) and not has_adr(diff):
|
||||
smells.append("New pattern w/o ADR")
|
||||
if duplicates_existing(diff):
|
||||
smells.append(f"Duplicates {diff.similar_to}")
|
||||
if cross_layer_import(diff):
|
||||
smells.append("Layer boundary violated")
|
||||
return smells
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Office-hours protocol
|
||||
```
|
||||
Weekly architect office hours (1h):
|
||||
- Anyone bring design Q
|
||||
- Whiteboard walkthrough
|
||||
- Output: ADR draft or "go ahead"
|
||||
Cost: 1h/week. Benefit: prevents 10× cost of misalignment.
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 small team (≤5) | 매 tech lead 매 implicit keeper |
|
||||
| 매 medium (5–20) | 매 explicit "architect" role 매 part-time |
|
||||
| 매 large (>20) | 매 architecture guild + Staff/Principal 매 keeper |
|
||||
| 매 OSS project | 매 BDFL or 매 core team 매 vote |
|
||||
| 매 startup early | 매 founder/CTO 매 keeper |
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
**기본값**: 매 ADR + weekly office hours + 매 명시적 vision document.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software-Architect-Role]] · [[Conceptual-Integrity]]
|
||||
- 변형: [[Tech-Lead]] · [[Staff-Engineer]] · [[BDFL]]
|
||||
- 응용: [[ADR-Architecture-Decision-Record]] · [[North-Star-Document]]
|
||||
- Adjacent: [[Mythical-Man-Month]] · [[Conways-Law]] · [[Technical-Debt]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 architect role responsibilities 의 articulate; 매 ADR template; 매 architecture review checklist.
|
||||
**언제 X**: 매 individual contributor 의 day-to-day coding (다른 layer); 매 PM/product strategy (overlap 있지만 scope 다름).
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Ivory tower architect**: 매 코드 매 안 짜고 매 mandate 만 — 매 lose credibility.
|
||||
- **Veto-only**: 매 block 만 하고 매 alternatives 매 propose 안 함.
|
||||
- **Vision drift**: 매 6 months 매 vision 매 silent 변경 — 매 team 매 confused.
|
||||
- **Hero dependency**: 매 keeper 떠나면 매 collapse — 매 succession plan 필요.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Brooks "Mythical Man-Month" Ch.4 conceptual integrity, Fowler "Who Needs an Architect?", Kruchten ADR origin 2011).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full content (architect role, ADR patterns) |
|
||||
|
||||
Reference in New Issue
Block a user