Trade-off: Five Options

paradigm-comparison에서 잡은 5 옵션 (Hybrid · MCP 단일화 · Tool only · Tool as API · MCP+Skills lazy)을 9 차원으로 깊이 분석. ①②③의 모든 lens가 모이는 자리. 5 옵션은 동일 차원에서 비교되지 않는다 — 각자 다른 우선순위 ordering을 가진다. 따라서 어느 옵션이 좋은가가 아니라 어느 차원이 결정적인가가 답을 정한다.

1. 철학

이 노트는 결정 도구다. v1.0이 무엇을 채택할지에 직접 입력된다. 그러나 답은 아니다 — 사용자가 결정한다. 이 노트는 결정의 차원과 각 차원의 trade-off mechanism만 박는다.

핵심 thesis 한 줄:

5 옵션은 동일 차원에서 비교되지 않는다. 각 옵션이 다른 우선순위 ordering을 가진다. 따라서 어느 옵션이 가장 좋은가가 아니라 어느 차원이 결정적인가가 답을 정한다.

이게 paradigm-comparison과 본 노트의 차이 — paradigm-comparison은 옵션을 나열했다면, 이 노트는 옵션의 trade-off mechanism을 박는다. 왜 그런 trade-off가 발생하는지가 ①②③ lens에 닿게.

2. 추상 작동 구조

평가 mechanism

각 옵션의 평가 = 9 차원 × 5 옵션 = 45 셀. 그러나 결정은 모든 셀이 동등 가중치가 아님. segment에 따라 차원 우선순위 다름. 이게 답이 segment-dependent인 이유.

차원별 ①②③ lens 매핑

각 차원이 어느 lens로 분석되는지가 명시되어야 평가가 기계적이 된다.

3. 5 옵션 × 9 차원 평가표

⭕⭕ = 결정적 강점 / ⭕ = 강점 / 🔶 = 중간 / 🔻 = 약점 / 🔻🔻 = 결정적 약점

평가의 왜 — 핵심 셀 해설

MCP+Skills lazy의 token ⭕⭕ (frontier-tool-gateway-and-compression lens)

• skill index만 prompt에, full description은 lazy load
• 90% token 절약. 학내 1000 req/day quota에서 5x turn 수 차이

Tool only의 ecosystem 🔻🔻 (standardization-political-economy lens)

• 자체 정의는 de facto 권력 형성 못 함. 다른 곳에서 호출 X
• ecosystem 형성의 mechanism (네트워크 효과, 합의 비용 outsource)이 작동 안 함

Tool as API의 product 호환 🔻 (evolution-function-calling-to-mcp Stage A vendor 분기 lens)

• pi-mono 같은 language-specific API는 cross-language 호환 X
• ② evolution의 vendor 분기 패턴 재현 — 이미 지난 단계로 회귀

MCP+Skills lazy의 진입장벽 ⭕⭕ (worse-is-better + postels-law-and-robustness lens)

• Markdown 한 장으로 skill 작성 가능
• frontmatter optional, body 자유 → 비개발자 진입
• Worse is Better + Liberal receiver의 합산 효과

Hybrid의 복잡도 🔻 (protocol-theory-lamport-tanenbaum lens)

• 두 layer 동시 관리 → ACL 비용 큼
• 새 tool마다 어느 layer에 박을지 결정 부담

4. 약점 — 각 옵션의 깊은 trap

Hybrid의 결정 부담

새 tool마다 어느 layer에 박을지 결정 필요. governance 부담 큼. 학내 marketplace에서 결정자 부재 → 카오스. Hybrid는 큰 조직에 적합, 학내엔 부담.

MCP 단일화의 비개발자 진입장벽

MCP server 직접 만들기 = 개발자만 가능. Skills layer 없으면 작성 진입 어려움. 학내 비개발자가 기여할 자리가 없음. 이게 결정적 약점 — marketplace 형성 mechanism이 깨짐.

Tool only의 학내 marketplace 형성과 직접 충돌

ecosystem 못 만들음. 학내 segment의 왜 protocol을 요구하는가에 답 못 함. ⑤ Segment 적용에서 가장 약한 옵션. 학내가 마이크로 ecosystem을 형성하려면 — Tool only는 시작부터 잘못된 path.

Tool as API의 vendor / 언어 lock-in

pi-mono 같은 패턴은 한 언어에 lock-in. 학내 segment는 비개발자가 다수 → 언어 자유 필요. 진입장벽이 두 배. ② evolution Stage A의 vendor 분기 패턴 재현 — 역사가 가르친 trap에 들어감.

MCP+Skills lazy의 learning curve (가파른 시작)

Skills 패턴이 새로움. 표준화 진행 중. 처음 진입은 가파름. 그러나 진입 후 다른 옵션보다 쉬움. 학내 segment에서 seed skill이 결정적인 이유 — learning curve의 시작점을 낮추는 도구. 또 governance 표준 부재 (skill rating, review)는 v2.0 압력으로 등장할 것.

5. 대안 흐름

5 옵션 외 path

⚠️ AI 추정: 5 옵션이 현재 production에서 유의미한 옵션. 다른 path는 학술적이거나 niche.

Production maturity 가중치

research-to-production-gap thesis 적용 — production maturity 높은 패턴을 채택하는 게 안전.

6. 학내 Segment 적용 — 차원 우선순위

차원이 동등 가중치가 아니다. 학내 segment의 우선순위 (⚠️ AI 추정):

왜 이 순위인가 — 학내 segment의 특성:

• 진입장벽 1순위 — 비개발자가 다수. 진입 못 하면 ecosystem 형성 X
• token 비용 2순위 — 1000 req/day quota가 hard constraint
• ecosystem 3순위 — marketplace 형성이 왜 protocol을 요구하는가의 답
• product 호환 4순위 — cross-everything이 학내 segment의 lever
• learning curve 5순위 — 빠른 채택이 critical mass의 시드
• 6-9순위 — 결정적 약점이 없으면 통과

우선순위 가중 평가

3개 핵심 차원 (진입장벽, token, ecosystem)에서 *모두 ⭕*인 옵션이 답:

⚠️ AI 추정: 학내 segment에서 MCP+Skills lazy가 결정. 그러나 사용자 결정 — paradigm-comparison에서.

7. 인사이트

7.1 5 옵션은 동일 차원에서 비교되지 않는다

각 옵션이 다른 우선순위 ordering. 어느 옵션이 좋은가가 아니라 어느 차원이 결정적인가가 답을 정한다. 학내 segment의 차원 우선순위 = 진입장벽 > token > ecosystem > product 호환 > learning curve. 이 우선순위가 옵션을 결정한다.

7.2 MCP+Skills lazy가 ① 4축을 모두 충족하는 유일 옵션

• 단순함 (worse-is-better): MCP 단순 + Skills Markdown
• layer 분리 (protocol-theory-lamport-tanenbaum): transport / skill management 분리
• de facto 권력 (standardization-political-economy): Anthropic + agentskills.io
• 관대함 (postels-law-and-robustness): Markdown frontmatter optional

다른 4 옵션은 어느 한 축이 약함. 4축 모두 충족하는 옵션이 살아남는 표준이라는 ① 합산 thesis 직접 적용.

7.3 Hybrid는 결정 부담이 hidden 비용

새 tool마다 layer 선택 → governance 부담. 학내 marketplace에서 결정자 부재 → 카오스. Hybrid는 큰 조직에 적합, 학내엔 부담. 표면적으로 "두 시스템의 장점 다 누리기"처럼 보이지만 — 실제로는 결정 부담의 누적.

7.4 Tool only는 학내 marketplace 형성과 직접 충돌

ecosystem 못 만들음. 왜 학내 segment가 protocol을 요구하는가에 답 못 함. 학내가 마이크로 ecosystem을 형성하려면 — Tool only는 시작부터 잘못된 path. ⑤ Segment 적용에서 가장 약한 옵션.

7.5 Tool as API는 ② evolution Stage A로 회귀

② Stage A의 vendor 분기 패턴 재현. 역사가 이미 가르친 trap. pi-mono의 registerTool 같은 language-specific 패턴은 — agent ecosystem이 겪고 극복한 단계로 다시 들어가는 것.

7.6 MCP 단일화는 비개발자 진입장벽이 결정적

MCP server 직접 만들기 = 개발자만 가능. Skills layer 없으면 작성 진입 어려움. 학내 비개발자가 기여할 자리가 없음. marketplace 형성 mechanism이 깨짐. 이게 MCP 단일화가 학내 segment에 적합 안 한 결정적 이유.

7.7 MCP+Skills lazy의 learning curve는 진입 후 보상

처음 진입은 가파름 (Skills 패턴 학습). 그러나 진입 후 다른 옵션보다 빠름. 학내 segment에서 seed skill이 결정적 — learning curve의 시작점을 낮추는 도구. v1.0의 첫 10개 skill이 ecosystem grammar 정한다는 standardization-political-economy 인사이트와 직접 연결.

7.8 차원 사이의 상관관계 — 9 차원은 독립이 아님

• token 비용 ↔ ecosystem (lazy loading 같은 패턴이 둘 다 향상)
• 진입장벽 ↔ learning curve (강한 상관)
• 복잡도 ↔ debugging (강한 상관)
• ecosystem ↔ product 호환 (강한 상관)

9 차원을 묶음으로 평가. 독립 9 차원으로 보면 잘못된 결론. 옵션 평가 시 상관 차원을 함께 본다.

7.9 의사결정의 Reversibility — MCP+Skills lazy가 가장 reversible

• v1.0에서 MCP+Skills lazy 채택 → 다른 옵션 추가 가능 (Hybrid 변형)
• 다른 옵션 채택 후 MCP+Skills로 옮기는 건 어려움 (이미 ecosystem 형성됐는데 옮기기)
• ⚠️ AI 추정: MCP+Skills lazy가 가장 reversible. design-principles reversibility 직접 적용

7.10 학내 segment의 결정 도구 = 진입장벽 + token + ecosystem 3축

9 차원 중 학내에 결정적인 3축. 이 3축에서 모두 ⭕인 옵션이 답. MCP+Skills lazy만 그 자격 (⚠️ AI 추정). 9 차원 모두 보지 말고 3축에 집중.

7.11 결정의 근거가 원리에 닿는 mechanism

왜 MCP+Skills lazy인가에 답하려면 ① 4축까지 거슬러 가야 한다. ②③의 lens가 현재 frontier 평가까지 보강. 이게 v1.0 결정이 근거를 갖는 mechanism — strategic decision은 이유가 fundamentals에 닿아야 한다 (software-fundamentals-thesis).

7.12 옵션이 답이 아니다 — 차원 우선순위가 답이다

이 노트의 가장 중요한 thesis: 답은 옵션 선택이 아니라 차원 우선순위 결정. 사용자가 학내 segment의 차원 우선순위만 정하면 옵션은 기계적으로 도출된다. v1.0 결정은 옵션 선택 회의가 아니라 segment 우선순위 결정 회의가 적절.

8. 다음으로의 연결

이 노트로 ④ Synthesis가 박혔다. 남은 것:

• segment-application-non-developer-majority — 위 분석을 학내 segment 추상 구조로 적용. 비개발자 다수 segment에서 왜 protocol이 결정적인가의 답. marketplace 형성 mechanism. 다른 segment로 복제 시 공유 layer.
• synthesis-for-v1 — 모든 ①②③④⑤ 분석을 v1.0 결정 근거로 종합.

⑤ Segment 적용은 ④의 학내 segment 특화. 차원 우선순위와 segment 특성을 명시적으로 연결.

참조

• paradigm-comparison — 5 옵션 원본 (이전 chat). 이 노트는 그 trade-off의 mechanism
• research-to-production-gap — production maturity 평가 lens
• design-principles — reversibility 원칙

연결:

• worse-is-better · protocol-theory-lamport-tanenbaum · standardization-political-economy · postels-law-and-robustness — ① 4축
• evolution-function-calling-to-mcp · evolution-mcp-to-skills — ② 두 단계
• frontier-tool-gateway-and-compression · frontier-rl-skill-generation · frontier-acp-and-agent-as-server — ③ 세 영역