Synthesis for v1.0
이 연구의 마지막 노트. 이전 11개 노트의 모든 분석을 v1.0 결정으로 변환. 연구는 결정을 대신하지 않는다. 결정의 근거가 fundamentals에 닿게 만든다. 이게 strategic decision의 본질 (software-fundamentals-thesis) — 사람이 결정하고, 그 근거가 깊이 있게 박혀 있는 것.
1. 철학
연구의 결과물 — 5 lens:
| Lens | 역할 | 합산 thesis |
|---|---|---|
| ① 4축 | 살아남는 표준의 조건 lens | 단순함 + layer 분리 + de facto + 관대함 |
| ② 두 단계 | 진화의 역사 lens | layer 분리 → layer 추가 |
| ③ 세 영역 | frontier의 production maturity lens | layer 위의 layer. ACL 결정적 |
| ④ 5 옵션 trade-off | 차원 우선순위의 결정 lens | 답은 옵션이 아니라 차원 우선순위 |
| ⑤ Segment 적용 | 비개발자 segment의 추상 구조 lens | protocol 요구. 추상 구조가 진짜 자산 |
이 5 lens가 v1.0 결정의 근거. 결정 자체는 사용자가 박는다 — paradigm-comparison 또는 설계하자의 docs/decisions.md에서.
핵심 thesis 한 줄:
차원 우선순위가 결정의 진짜 자리다. 옵션 비교는 그 다음 자동이다.
사용자가 직접 결정해야 하는 건 옵션이 아니라 차원 우선순위. 우선순위만 박히면 옵션은 ④의 평가표에서 기계적으로 도출.
2. v1.0 결정 path — Q1~Q7
Q1 — 차원 우선순위 결정 (사용자 자리)
학내 segment의 차원 우선순위를 결정. 9 차원 중 결정적 차원 1~5순위 박기.
⚠️ AI 추정 후보 (사용자 검토):
- 진입장벽 — 비개발자 다수
- token 비용 — 1000 req/day quota
- ecosystem — marketplace 형성 필수
- product 호환 — cross-everything
- learning curve — 빠른 채택
사용자 결정 자리: 이 우선순위가 학내 segment에 맞는가? 가중 비율은 어떻게?
Q2 — 옵션 도출 (기계적)
Q1 우선순위 → trade-off-five-options 평가표 적용 → 옵션 자동 도출.
⚠️ AI 추정: 학내 segment 우선순위에서 MCP+Skills lazy (3축 모두 ⭕⭕).
사용자 결정 자리: 도출된 옵션을 v1.0으로 채택? 아니면 차원 우선순위 재검토?
Q3 — Layer 박기 (① 4축 + ③ frontier 적용)
박을 layer (위에서 아래로):
| Layer | 박는 내용 | 근거 lens |
|---|---|---|
| Application | use case별 agent app | ⑤ |
| Configuration | AGENTS.md 표준 | evolution-mcp-to-skills |
| Skill management | Markdown skill + lazy loading | ① 4축 |
| Transport | MCP | evolution-function-calling-to-mcp |
| Tool execution | 외부 API · 함수 | tool-vs-mcp-research |
| Capability | LLM function calling | tool-vs-mcp-research |
| Cross-cutting | Tool gateway · ACL · 측정 · cost tracking | frontier-tool-gateway-and-compression |
각 layer가 분리되어 있어야 진화 가능 (protocol-theory-lamport-tanenbaum).
Q4 — 진화 hook 박기 (② + ③)
미래 압력을 의식. 빈 hook이라도 v1.0에 박아두기:
| Hook | 미래 압력 | 근거 lens |
|---|---|---|
| Skill governance | rating · review · trust | ⓘ frontier 미래 |
| RL skill 생성 | AutoSkill · RL이 production 도달 시 | frontier-rl-skill-generation |
| Agent 노출 | ACP / MCP server (학내 v3.0+) | frontier-acp-and-agent-as-server |
| Cross-skill orchestration | skill끼리 호출 | ⓘ 다음 frontier |
| Skill versioning | spec 진화 시 | ⓘ 다음 frontier |
각 hook이 빈 자리라도 처음부터. design-principles reversibility 직접 적용.
Q5 — ACL pattern 박기 (② + ③)
ACL 자리 — vendor 변형을 흡수:
| ACL 자리 | 흡수 대상 | 근거 lens |
|---|---|---|
| MCP server 변형 | vendor마다 다른 MCP 구현 | evolution-mcp-to-skills |
| Framework 변형 | LangChain 등 framework adapter 변형 | evolution-function-calling-to-mcp |
| ACP 변형 | ACP가 자리 잡으면 흡수 | frontier-acp-and-agent-as-server |
| Skill format 변형 | agentskills.io 외 형식 | postels-law-and-robustness |
| Tool gateway 표준 부재 | gateway 표준 등장 시 흡수 | frontier-tool-gateway-and-compression |
ACL이 layer 위의 layer가 만드는 자리. 외부 다양성을 흡수해서 내부에 일관된 표현 (postels-law-and-robustness 5.5).
Q6 — Cold start seed design (⑤)
학내 segment specific 결정:
| 결정 자리 | ⚠️ AI 추정 / 사용자 결정 |
|---|---|
| Seed 출처 | 기술 능력자 1-2명 |
| Re-seeding mechanism | 졸업 cycle 대비 onboarding 자리 |
| 시드 grammar | 첫 10 skill의 형태 — 향후 모든 skill의 grammar (standardization-political-economy) |
| Critical mass 목표 | ⚠️ ~20-50 active 사용자 |
| Governance | 학내 졸업 cycle에 맞춤 |
이게 학내 specific 결정 — 다른 segment에 복제 시 segment specific 부분만 변경.
Q7 — 측정 hook (③ + ⑤)
진화의 데이터 자리. 처음부터 박아두기:
| 측정 hook | 사용처 | 근거 lens |
|---|---|---|
| Tool 선택 accuracy | 압축 trade-off 측정 | frontier-tool-gateway-and-compression 5.9 |
| Skill 사용 빈도 | lazy loading index 정제 | frontier-tool-gateway-and-compression |
| Token 사용 분포 | 1000 req/day 분포 분석 | segment-application-non-developer-majority 5.10 |
| Cost attribution | multi-agent 미래 대비 | frontier-acp-and-agent-as-server 5.6 |
| 잘못된 skill selection 패턴 | standardized liberal 영역 정의 | postels-law-and-robustness 5.6 |
| Cold start re-seeding 시점 | governance 압력 측정 | segment-application-non-developer-majority |
v1.0의 측정 hook이 v2.0 진화의 학습 데이터. AutoSkill을 v2.0에 추가하려면 — v1.0의 사용 데이터가 필요.
3. 5 lens의 결정 도구 매핑
각 lens가 어떤 결정에 어떻게 작동하는가:
각 Q1~Q7 단계가 어느 lens를 호출하는지 명시. 이게 근거가 fundamentals에 닿는 mechanism.
Lens별 결정 적용 cheat sheet
Lens 1 — ① 4축 (단순함, layer 분리, de facto, 관대함)
- 모든 결정의 checklist
- 새 기능, 새 layer, 새 표준 채택 시 — 4축 모두 충족하는가?
- 4축 동시 충족이 살아남는 표준의 조건
Lens 2 — ② Evolution
- 진화 path에 결정이 있는가? 의 lens
- ② Stage A의 vendor 분기 trap 회피 (Tool as API 옵션 ✗)
- ② Stage B의 layer 추가 인지 (skill management layer를 지금 박아야)
Lens 3 — ③ Frontier
- production maturity 평가 lens
- gateway · lazy loading: 직접 채택 (maturity 95-100%)
- RL skill 생성: future hook만 (maturity <30%)
- ACP / agent 노출: future hook만 (maturity <60%)
Lens 4 — ④ 5 옵션 trade-off
- 옵션 선택의 lens
- 9 차원 평가 + 차원 우선순위 → 옵션 기계적 도출
- 학내 segment에서 MCP+Skills lazy (⚠️ AI 추정)
Lens 5 — ⑤ Segment 적용
- segment 적합성의 lens
- 비개발자 다수 가정 → quota → 차원 우선순위 도출
- 추상 구조 공유 + 구체 spec 분리
4. 약점 — 이 종합의 약점
이 종합도 약점을 가진다. 의식해야 함.
Trap 1 — 답이 정해진 것처럼 보일 위험
"MCP+Skills lazy"가 결정처럼 박혀 있음. 그러나 ⚠️ AI 추정. 사용자가 직접 차원 우선순위를 결정해야 함. 잘못 읽으면 답이 정해진 것처럼 보이는 trap.
Trap 2 — 5 lens가 상호 의존인데 분리되어 있음
실제 결정에서 lens가 함께 작동. 노트 분리가 분석 도구로는 좋지만 적용 도구로는 부담. 이 노트가 통합 자리인 이유.
Trap 3 — Frontier가 빠르게 변함
2026-05의 frontier 평가는 6개월 후 다를 수 있음. 이 종합은 현재 시점 기반. 진화 압력은 그대로지만 사례는 변함. v1.0 design은 frontier 변동에 reversible해야.
Trap 4 — 학내 segment 가정의 변동성
비개발자 비율, quota, 기술 능력자 시드 — 모두 변함. v1.0 결정이 변동에 강한 형태여야. ⚠️ AI 추정: 5-10년 내 비개발자/개발자 구분 자체가 약해질 가능성.
Trap 5 — 종합이 결정을 강요할 위험
"이대로 하면 됩니다" 톤이 들 수 있음. 그러나 v1.0 결정은 paradigm-comparison이나 설계하자 docs/decisions.md에서. 이 노트는 근거 lens만 제공한다, 결정은 사용자가 박는다.
5. 대안 흐름 — 다른 종합 방식
본 노트의 axis는 "결정 path Q1~Q7". 다른 axis 가능:
| Axis | 종합 방식 |
|---|---|
| 시간 axis | 2024 → 2025 → 2026 → 2027 진화 시나리오 |
| 층위 axis | 각 layer 별로 결정 (LLM / Tool / Transport / Skill / App) |
| 사용자 axis | 비개발자 / 시드 / 운영자 별로 결정 |
| 결정 path axis (본 노트) | 사용자가 따르는 순서 |
⚠️ AI 추정: 결정 path axis가 가장 운영 가능한 종합. 시간/층위/사용자 axis는 부가 lens. 사용자가 지금 무엇을 정해야 하는가를 명시하는 게 결정 path의 강점.
6. 인사이트 — v1.0 결정의 근거 정리
6.1 연구는 결정을 대신하지 않는다 — 근거가 fundamentals에 닿게 만든다
이게 strategic decision의 본질 (software-fundamentals-thesis). 사람이 결정하고, 그 근거가 fundamentals에 닿아 있는 것. 이 종합 노트는 근거 lens만 제공.
6.2 차원 우선순위가 결정의 진짜 자리
옵션 비교는 자동. 사용자가 직접 결정해야 하는 건 학내 segment의 차원 우선순위. 이게 v1.0 결정의 첫 자리.
6.3 MCP+Skills lazy가 학내 segment에 ⭕⭕ — 그러나 사용자 결정
⚠️ AI 추정. 차원 우선순위에 따라 다른 옵션이 답일 수 있음. paradigm-comparison에서 사용자 결정.
6.4 Layer 박기 7단계가 v1.0 design의 sequence
Q1~Q7. 각 단계가 어느 lens를 호출하는지 명시. 결정의 재현 가능성이 mechanism의 본질.
6.5 Production maturity가 frontier 결정의 lens
gateway · lazy loading은 ✓. RL · agent 노출은 hook만. production 도달한 것을 채택, 아닌 건 미래 흡수 자리만.
6.6 ACL pattern은 모든 layer에서 결정적
vendor 변형, framework 변형, 표준 변형 — 모두 ACL이 흡수. v1.0의 진짜 architecture 결정은 ACL 자리들. design-principles #7과 직접 연결.
6.7 Cold start re-seeding이 학내 specific design 자리
졸업 cycle로 시드가 매년 바뀜. v1.0이 재seeding mechanism을 처음부터 design. 학내 specific이지만 추상 구조는 다른 segment에 복제 가능.
6.8 측정 hook이 v2.0 진화의 데이터 자리
처음부터 박아두기. v1.0의 측정 데이터가 v2.0 진화 (RL skill 생성, governance, lazy index 정제)의 학습 데이터. 측정 없으면 진화 불가능.
6.9 Reversibility가 모든 결정의 평가 차원
9번째 차원이 사실상 0순위. 돌이킬 수 없는 결정은 — fundamentals 4축 충족해도 위험. 학내 segment의 사용자 변동성을 의식. design-principles reversibility.
6.10 추상 구조 공유 + 구체 spec 분리가 v1.0의 진짜 자산
학내 segment-specific 부분은 학내에만 가치. 그러나 protocol layer + skill format + ACL pattern + seed-ripple-fork mechanism은 모든 비개발자 segment에 가치. v1.0의 진짜 가치는 복제 가능한 추상 구조에 있음.
6.11 Privacy 보호가 abstraction의 동력 — 우연한 효익
학내 노트에서 학교명, 실명 X. 일반화 강제. 일반화된 추상 구조가 다른 segment에 복제 가능. 우연한 효익이지만 결정적.
6.12 연구 종료가 결정의 시작
이 종합이 박혔으니 — 사용자가 결정 자리로 이동.
- v1.0 옵션 결정 → paradigm-comparison 또는 설계하자 docs/decisions.md
- ① 4축은 향후 모든 결정의 checklist
- ②③④⑤은 결정 lens. 새 결정마다 호출
- 측정 hook 결과는 v2.0 진화의 데이터 자리
7. 연구 완성 — 11+1 노트 합산
| 영역 | 노트 수 | 핵심 thesis 1 줄 |
|---|---|---|
| ① Fundamentals | 4 | 단순함 + layer 분리 + de facto + 관대함 = 살아남는 표준 |
| ② Evolution | 2 | layer 분리 → layer 추가. 해결이 다음 문제 가시화 |
| ③ Frontier | 3 | layer 위의 layer. ACL이 결정적 |
| ④ Synthesis | 1 | 차원 우선순위가 답을 결정 |
| ⑤ Segment | 1 | 비개발자 segment는 protocol을 요구. 추상 구조가 진짜 자산 |
| 종합 | 1 (이 노트) | 결정 path Q1~Q7. 근거가 fundamentals에 닿는 mechanism |
총 12개 노트. 모두 5요소 구조 — 철학 · 추상 작동 구조 · 약점 · 대안 흐름 · 인사이트.
이게 v1.0 결정의 근거 lens 전체. 사용자가 이 lens를 가지고 결정으로 이동.
8. 다음 자리 — 연구 종료, 결정 시작
이 노트로 연구가 완성. 다음은 다른 프로젝트로:
설계하자 (docs/decisions.md)
v1.0 결정을 ADR로 박는 자리. 이 연구의 결과를 기반으로 — 왜 MCP+Skills lazy인가 (또는 사용자가 결정한 옵션) ADR 작성.
Claude Code (구현)
v1.0 spec을 따라 구현. AC 박힌 feature 단위로 TDD. 이 연구가 구현의 fundamentals 근거.
연구하자 (이 프로젝트)
이 연구의 연장. v1.0 운영 시작 후 새 spike가 등장하면 다시 호출.
- governance 표준화 (skill rating, review)
- AutoSkill production 도달 시점
- ACP가 자리 잡을 때
- Cross-skill orchestration 압력 등장 시
공부하자 (개념 질문)
이 연구의 지식은 경험이 아니다. 새 segment 만나면 — 이 추상 구조를 적용하는 것은 학습 자리.
참조
이전 chat의 결과:
- tool-vs-mcp-research — 이 연구의 출발점
- paradigm-comparison — v1.0 옵션 결정의 자리
- references-goose · references-claude-code · references-codex · references-pi-mono · references-gemini-cli
- research-to-production-gap — production maturity의 결정적 영향
- industry-hot-issues-2026 — 산업 issue 맥락
- software-fundamentals-thesis — Matt thesis (사람=strategic, AI=tactical)
- design-principles — 7 원칙 (특히 #4, #7, reversibility)
이 연구의 12개 노트: