Evolution: Function Calling → MCP
2023-06 OpenAI function calling에서 2024-11 MCP까지 18개월. 각 단계는 이전 단계의 결정이 만든 문제에 대한 응답이다. ① fundamentals 4축으로 보면 — 각 단계가 기계적으로 설명된다. agent tool/protocol 진화는 layer가 점점 명확해지는 과정이다.
1. 철학
역사는 직선이 아니라 결정의 연쇄다. 각 단계는 이전 단계의 결정이 만든 문제에 대한 응답이다.
핵심 thesis 한 줄:
agent tool/protocol 진화는 layer가 점점 명확해지는 과정이다.
처음엔 layer가 섞여 있었다 — function calling = LLM의 능력 + tool 정의 + 호출 protocol이 한 덩어리. 시간이 가면서 layer가 분리됐다. 분리의 압력은 무엇이었는가? — ① 4축이 미충족된 영역에서 압력이 발생했다. layer가 섞여 있으면 단순함을 잃고, 권력이 분산되고, 관대함이 깨진다. 그 압력이 다음 단계를 만든다.
각 단계를 ① 4축으로 해석하는 게 이 노트의 목적이다.
2. 추상 작동 구조 — 4단계의 진화
시간축
Layer 분리도의 점진성
각 화살표 위의 압력이 진화의 동력. 압력의 출처는 ① 4축이 어떤 측면에서 미충족인지.
단계별 ① 4축 분석
| 단계 | 단순함 | layer 분리 | 권력 형성 | 관대함 | 평가 |
|---|---|---|---|---|---|
| 1. function calling | △ vendor-specific | ✗ 한 덩어리 | △ OpenAI 단독 | △ JSON schema strict | 시드는 됐으나 표준 아님 |
| 2. vendor 분기 | ✗ vendor마다 다름 | ✗ 여전히 한 덩어리 | ✗ 권력 분산 | ✗ 각자 strict | fragmentation — 표준 아님 |
| 3. framework adapter | △ 추상화 비용 | △ tool 정의만 분리 | △ framework 단독 | △ adapter가 흡수 | 임시 답 — 표준 아님 |
| 4. MCP | ✓ JSON-RPC + stdio | ✓ transport 분리 | ✓ Anthropic + 합의 | ✓ JSON-RPC robust | 표준 — 4축 모두 ✓ |
핵심 — 4축이 모두 ✓가 된 단계에서만 표준이 자리 잡았다. 1, 2, 3 단계는 어느 한 축이 미충족이었기 때문에 표준 못 됨. MCP는 4축을 모두 충족시킨 첫 시도.
3. 약점 (역사가 가르치는 약점)
Trap 1 — Vendor lock-in의 비용
2023-24의 vendor 분기는 사용자에게 cross-vendor migration cost를 폭증시켰다. agent app이 한 vendor를 선택하면 다른 vendor로 옮기기 어려움. 이 고통이 MCP가 등장해야 했던 trigger. 그러나 그 고통의 시간이 1년 넘게 걸렸다 — ecosystem 자원이 vendor 분기에 낭비된 시간.
Trap 2 — Framework adapter의 한계
LangChain/LlamaIndex가 tool 정의만 통합. transport는 여전히 vendor 종속. adapter는 임시 layer다. 어떤 vendor가 새 feature를 추가하면 adapter도 따라가야 함 → maintainence 부담이 framework에 누적. ⚠️ AI 추정: framework는 자기 권력 출처가 vendor 차이의 흡수인데, 표준이 등장하면 그 권력이 사라진다. 그래서 framework는 표준화에 모호한 입장. 이게 framework adapter가 영구 답이 될 수 없는 이유.
Trap 3 — OpenAPI가 tool spec으로 채택되지 못한 이유
OpenAPI는 기술적으로 우월했다. type system, schema validation, 다양한 transport. 그러나 ecosystem 못 잡음. ⚠️ AI 추정: ① 4축 중 단순성을 만족 못 함. 비개발자가 OpenAPI 작성 어려움. The Right Thing의 함정 — SOAP의 운명을 따라감. 기술적 우월성이 ecosystem 권력으로 변환되지 않은 사례.
Trap 4 — MCP의 현재 약점
MCP는 transport만 다룬다. orchestration, skill management, agent loop은 vendor-specific. 그래서 MCP 위에서 다시 분기가 시작될 수 있음. 2025의 Skills lazy loading, ACP, agent-as-MCP-server는 이 약점에 대한 응답.
→ 다음 노트 evolution-mcp-to-skills에서 깊이 다룸.
Trap 5 — 시간의 비대칭
표준이 너무 일찍 나오면 ecosystem이 충분히 고통받지 못함 → 채택 동력 없음. 표준이 너무 늦게 나오면 다른 표준이 먼저 자리 잡음 → 채택 불가. MCP의 2024-11은 우연히 적절한 시점. ⚠️ AI 추정: 2024-06이면 vendor 분기 고통이 부족, 2025-06이면 다른 표준이 자리 잡음. 표준화는 때가 결정적인데, 때는 사후에만 알 수 있다.
4. 대안 흐름
가상: 다른 길로 갔다면?
| 가상 path | 결과 (⚠️ AI 추정) |
|---|---|
| Vendor 합의로 common tool format (위원회) | 너무 느려서 ecosystem이 다른 곳으로 갔을 것. SOAP의 운명 |
| gRPC를 transport로 | 너무 무거움. 단순성 부족 → Worse is Better trap |
| OpenAPI 표준화 (실제 시도) | 정교함의 trap. ecosystem 못 잡음 (실제로 일어남) |
| No standard, framework adapter forever | cross-everything 호환 X. ecosystem 파편화 |
| Anthropic이 MCP 안 만들었으면 | ⚠️ 다른 vendor가 비슷한 시도 했을 가능성. 그러나 때가 안 맞으면 fail |
핵심 — MCP가 우연인가, 필연인가? 4축 압력은 필연이었다. 그러나 MCP라는 specific spec은 우연. 다른 spec이 4축을 충족했어도 같은 결과 가능했음. 표준의 형태는 우연, 표준의 등장은 필연.
실제 progression 분석
각 단계의 결정자와 결정의 logic:
각 단계의 결정 logic이 이전 단계의 미해결 문제에 응답. 이게 진화의 mechanism.
5. 인사이트
5.1 각 단계는 이전 단계의 결정이 만든 문제에 대한 응답이다
function calling → vendor 분기 (각자 lock-in 시도) → cross-vendor 고통 → framework adapter (tool 정의 통합) → adapter 한계 → MCP (transport 분리). 각 단계가 논리적. 4축이 미충족 영역을 메우려는 압력이 다음 단계를 만든다. 진화는 random하지 않다.
5.2 Layer 분리의 점진성 — 한 번에 layer 분리 안 됨
2023의 한 덩어리 → 2024의 transport 분리 → 2025의 skill 분리 (다음 노트). 단계별로 압력이 쌓이고 분리됨. 학내 marketplace도 처음부터 완벽한 layer 분리를 기대하면 안 됨. 진화 path를 design — v1.0은 불완전하지만 진화 가능한 layer 분리, v2.0에서 다음 layer 분리.
5.3 Vendor lock-in이 표준화의 forcing function이었다
사용자가 cross-vendor 고통을 충분히 느꼈을 때 표준화가 가능했다. 학내 marketplace에서도 — 단일 vendor lock-in이 충분히 고통스러워야 표준화 동력이 생긴다. v1.0에서 cross-context migration이 자유롭도록 design하면 — 표준화 압력을 처음부터 흡수. lock-in을 피하는 것이 표준 형성의 첫 조건.
5.4 OpenAPI 실패가 가르치는 것 — 비개발자 진입성이 표준 결정의 핵심
OpenAPI는 기술적으로 우월했다. 그러나 ecosystem 못 잡음. 이유: 비개발자 진입 장벽. 기술적 우월성 ≠ 표준화 우위. 학내 marketplace에서 기술적 우월성보다 비개발자 진입성이 결정적. 이건 ① 4축의 단순성이 비개발자 segment에서 극도로 결정적인 이유.
5.5 표준의 때는 사후에만 알 수 있다
MCP는 2024-11이라는 시점이 결정적. ⚠️ 2024-06이면 vendor 분기 고통이 부족, 2025-06이면 다른 표준이 자리 잡음. 학내 marketplace의 발표 시점도 중요. 사용자가 현재 도구의 한계를 충분히 느꼈을 때 발표해야 채택. v1.0 발표 직전의 사용자 인터뷰가 기술 design만큼 중요한 이유.
5.6 Framework adapter는 과도기 패턴. 표준이 등장하면 adapter는 사라진다
LangChain의 tool abstraction은 transport 표준 부재가 만든 임시 답. MCP가 자리잡으면서 LangChain도 MCP를 채택. 학내 marketplace 초기에 framework 의존하는 건 ok. 그러나 영구 의존하면 표준 등장 시 migration cost. 답: anti-corruption layer를 박아서 framework 의존을 isolate. framework가 사라져도 marketplace는 살아남게.
5.7 ① 4축이 모두 충족되어야 표준이 된다 — MCP가 그 첫 사례
1, 2, 3 단계는 어느 한 축이 미충족이었다. 부분적 답은 표준이 못 된다. 4축이 동시에 작동한 MCP만 표준이 됐다.
- 단순함 (Worse is Better): JSON-RPC + stdio
- layer 분리 (Tanenbaum): transport만 다룸
- de facto 권력 (정치경제학): Anthropic 명성 + 합의 + 빠른 채택
- 관대함 (Postel): JSON-RPC error handling, capability negotiation
학내 marketplace의 v1.0이 표준이 되려면 — 4축을 모두 충족해야 한다. 하나라도 빠지면 lose. 이게 v1.0 design의 checklist.
5.8 표준화의 형태는 우연, 표준화의 등장은 필연
4축 압력은 필연. 그러나 어떤 spec이 표준이 되는지는 우연. 학내 marketplace에서도 — 표준화가 언젠가 일어날 건 필연 (4축 압력이 작동). 그러나 어떤 형태인지는 우연. v1.0이 그 우연을 결정짓는 자리. 즉 v1.0의 결정이 향후 학내 segment의 표준 grammar를 정한다.
6. ② Evolution 진행 — 다음 단계로
이 노트로 2023-06 ~ 2024-11의 진화를 ① 4축으로 해석했다.
다음 노트 — evolution-mcp-to-skills:
- 2024-11 ~ 2025: MCP가 자리잡은 후에 등장한 새 압력
- token 부담이 trigger한 진화 — Skills lazy loading 패턴
- AGENTS.md, agentskills.io, ACP의 동시 등장
- 4축이 MCP 위에서 어떻게 다시 작동하는가 — layer 위의 layer
이게 박히면 ②가 완성. 그 다음 ③ Frontier로.
참조
- OpenAI function calling 발표 (2023-06)
- Anthropic Tool Use 발표 (Claude, XML 기반)
- LangChain tool abstraction 문서
- Anthropic MCP 발표 (2024-11): modelcontextprotocol.io
- IETF의 표준 진화 패턴 — running code and rough consensus
연결:
-
- worse-is-better — 4축 ① — MCP의 단순함
- protocol-theory-lamport-tanenbaum — 4축 ② — transport layer 분리
- standardization-political-economy — 4축 ③ — Anthropic의 권력 형성
- postels-law-and-robustness — 4축 ④ — JSON-RPC robustness
- tool-vs-mcp-research — 이 evolution이 도달한 layer 분리 결과