Frontier: Tool Gateway and Compression
Token 부담이 예상치 못한 lever가 됐다. MCP는 transport만 다룬다 — tool 묶음, 압축, 보안, observability 같은 cross-cutting concern은 어느 layer에서 다뤄야 하는가? 답은 별 layer, 즉 tool gateway. Cross-cutting concern은 tool layer에도 transport layer에도 속하지 않는다 — 옆에 있는 layer에 속한다.
1. 철학
evolution-mcp-to-skills에서 본 4 압력 중 하나가 token 부담이었다. 그러나 token 부담만 있는 게 아니다 — 보안, audit, rate limit, observability, caching도 함께 있다. 이것들은 모든 tool 호출에 공통이지만 어느 한 layer에 속하지 않는다. 이걸 protocol-theory-lamport-tanenbaum Trap 5에서 cross-cutting concern이라 불렀다.
핵심 thesis 한 줄:
Cross-cutting concern은 별 layer에 속한다. 그 자리가 tool gateway다.
이게 software 일반에서 sidecar 패턴이라 불리는 것. agent 영역에서는 tool gateway / proxy로 등장. transport layer (MCP)와 tool execution layer 사이에 옆으로 끼어드는 layer.
Tool description 압축은 cross-cutting concern의 특수 사례. tool description token이 모든 호출에서 공통 비용. 이 비용을 어디서 줄일지가 결정.
2. 추상 작동 구조
Gateway 없는 기본 흐름
각 호출마다 모든 cross-cutting concern을 반복. 보안 검증도, audit log도, rate limit도 — 각 server가 따로 처리해야 함. 이게 비효율.
Gateway가 들어오면
Gateway가 옆 layer에서 cross-cutting concern을 처리. 각 MCP server는 자기 일만 함. 직교성 회복.
Tool description 압축의 두 방향
⚠️ AI 추정: lazy loading이 static 압축보다 효과 큼. static은 표현력과 이해도의 trade-off가 가파르다 — 압축할수록 LLM이 잘못된 tool을 선택할 확률이 빠르게 상승. lazy loading은 전체 표현을 줄이지 않고 현재 노출을 줄이는 방향이라 trade-off가 완만.
학술 frontier — 진행 중인 압축 연구
⚠️ AI 추정 — 진행 중인 방향:
| 방향 | 핵심 | 한계 |
|---|---|---|
| Tool retrieval (RAG-based) | vector DB에서 관련 tool만 retrieve | accuracy 낮음 |
| Tool clustering | 비슷한 tool 묶어 description 공유 | 사용자 정의 tool은 cluster 모호 |
| Tool routing | supervisor agent가 subset 선택 | supervisor도 token 비용 |
| Hierarchical description | 큰 카테고리 → 세부 tool | 표현 부담 큼 |
각자 부분적 답. 완벽한 답은 부재. 그래서 lazy loading이 현재 best. 학술이 따라잡으면 다른 답이 등장할 수 있음.
3. 약점
Trap 1 — Gateway가 single point of failure
모든 tool 호출이 gateway 통과 → 가용성 risk. gateway가 죽으면 모든 tool이 안 됨. 답: gateway HA design. 그러나 비개발자 segment에서 HA 구성 어려움. ⚠️ AI 추정: 학내 marketplace는 단일 gateway로 시작하되, 분산 가능하게 design.
Trap 2 — Gateway가 layer 누설 위험
gateway가 너무 많은 cross-cutting concern을 처리 → 모놀리식화. 보안, audit, rate limit, caching, 압축 — 다 한 곳에 몰리면 — gateway 자체가 protocol-theory-lamport-tanenbaum Trap 1 (layer 누설)의 자리가 됨. 답: gateway 안에서도 layer 분리.
Trap 3 — Description 압축의 trade-off
- 압축 ↑ → token ↓ → 그러나 LLM 이해도 ↓ → 잘못된 tool 선택 확률 ↑
- accuracy 비용을 측정하기 어려움
- 학내 segment에서 어느 정도가 적절인지는 경험적
이게 측정 hook을 처음부터 박아야 하는 이유. v1.0에서 어떤 tool이 잘못 선택되는지 추적 안 하면 — 압축 정도를 정할 수 없음.
Trap 4 — Tool gateway의 표준 부재
MCP는 transport 표준. Gateway는 표준 없음. 각자 자기 gateway 만듦 → vendor lock-in 가능. ⚠️ AI 추정: 2026~2027에 gateway 표준 등장 가능성. 그때까지는 anti-corruption layer로 자기 gateway를 isolate.
Trap 5 — Lazy loading의 skill index 표현 비용
skill index는 prompt에 항상 있음. index 자체가 너무 많으면 — full prompt와 큰 차이 없음. 답: agentskills.io의 description field가 trigger 역할. 짧은 한 줄이 적절한 skill을 trigger. ⚠️ AI 추정: 1000+ skill에서는 index 자체가 부담. 다음 layer (skill index의 lazy loading?)가 등장할 가능성.
Trap 6 — Gateway가 권력 집중
Gateway가 모든 tool 호출의 gateway → 누가 gateway를 통제하는가가 권력 자리. 학내 marketplace에서 — gateway 운영자가 통제권을 가짐. 이건 standardization-political-economy에서 본 권력 mechanism의 직접 적용. governance 의식 필요.
4. 대안 흐름
다른 방향들과 그 운명:
| 가상 path | 결과 (⚠️ AI 추정) |
|---|---|
| Context window 폭증 (1M+ token) | 비용 폭증 + Context Rot. lazy loading 대체 못함 |
| Tool 자체를 줄이기 (필요한 tool만 미리 선택) | 동적 task에 안 맞음 |
| Multi-turn tool discovery (agent가 물어가며 사용) | turn 수 ↑ → latency 비용 |
| Embedding-based tool retrieval (RAG) | accuracy 낮음 |
| Cross-cutting concern을 각 server가 처리 | 모든 server가 재발명 → 비용 폭증 |
| Cross-cutting concern을 transport layer에 박기 | MCP 단순성 깨짐 → 표준 위협 |
핵심 — gateway가 옆으로 끼어드는 패턴이 거의 유일한 답. 다른 방향은 fundamentals 4축 어느 하나를 깬다.
Agent 영역 매핑
| 시스템 | Tool gateway | 압축 방식 |
|---|---|---|
| Claude Code | bundled gateway | Skills lazy loading (90% 절약) |
| Goose | extension manager | partial — 전체 tool 노출 |
| Cursor | inline | 거의 없음 |
| OpenClaw | workspace > global > bundled | hierarchical |
| 학내 marketplace v1.0 | ⚠️ design 자리 | ⚠️ lazy loading 채택 권장 |
⚠️ AI 추정: Claude Code의 lazy loading + bundled gateway 패턴이 production maturity 가장 높음. 학내 marketplace의 복제 대상.
5. 인사이트
5.1 Cross-cutting concern은 별 layer로 분리 — Gateway가 그 자리
보안, observability, 권한, rate limit, caching, 압축 — 어느 한 layer에 박을 수 없다. 별 layer (gateway / sidecar)로 분리하는 게 protocol-theory-lamport-tanenbaum Trap 5에 대한 답. 학내 marketplace에서 tool gateway는 반드시 design해야 할 layer. 빈 gateway라도 v1.0에 박아두기. 나중에 추가하기 어려움.
5.2 Lazy loading이 static 압축보다 효과 큼
- 90% token 절약 vs 표현력-이해도 trade-off
- Anthropic Claude Code 패턴이 production 사례
- 학내 segment에서 그대로 채택. 새로 발명할 필요 없음
- 이게 research-to-production-gap thesis의 직접 적용 — production 패턴을 채택, research 답을 기다리지 않음
5.3 Gateway는 anti-corruption layer의 자연스러운 자리
- 외부 vendor의 다양한 tool format → gateway가 흡수 → 내부에 일관된 표현
- design-principles #7과 직접 연결
- 학내 marketplace가 외부 MCP server를 받아들일 때 gateway가 흡수
- vendor가 변하거나 새 vendor가 등장해도 gateway가 보호
5.4 Token 부담은 layer 비용이다 — 어느 layer에서 처리할지가 결정
| Layer | 답 | 비용 |
|---|---|---|
| LLM layer | context window 폭증 | 비용 폭증 + Context Rot |
| transport layer | MCP가 압축 지원? | 표준 깨짐 |
| gateway layer | lazy loading + 압축 | 현재 best |
| skill layer | description 짧게 | 표현력 ↓ |
답: gateway layer + skill layer의 조합. 이게 학내 marketplace의 v1.0 설계 자리.
5.5 학내 1000 req/day quota → lazy loading 결정적
- 70 extension full prompt = 200 turn/day
- 70 extension lazy = 1000+ turn/day
- 5x 차이. user 경험에 직결.
- v1.0의 기본값 lazy loading. 옵션 X — 처음부터 박아두기.
5.6 Gateway가 권력 집중 자리 — governance를 의식
Gateway는 모든 tool 호출의 gateway. 운영자가 통제권을 가진다. 학내 marketplace에서 — gateway 운영을 어떻게 분산할지가 질문. 한 명이 통제하면 권력 집중. 분산하면 복잡도. ⚠️ AI 추정: 학내 segment는 작은 운영 그룹이 적절. 너무 분산하면 governance 부담.
5.7 Gateway 표준 부재 → anti-corruption layer가 더 결정적
- MCP는 표준. Gateway는 표준 없음.
- 학내 marketplace도 자기 gateway 만들 수밖에 없음
- 그러나 gateway 표준이 등장하면 채택 가능하게 design
- anti-corruption layer 안에 gateway를 isolate. gateway 자체를 vendor 종속 layer로 보고 내부의 추상을 따로 둠
5.8 Lazy loading은 Worse is Better + Postel's Law의 합산
- 단순함 (worse-is-better): skill index만 prompt에. 단순한 메커니즘
- 관대함 (postels-law-and-robustness): description optional, body 자유
- 두 원리가 합쳐져 ecosystem 채택 → 학내 marketplace의 처음부터 이 패턴
5.9 Description 압축의 trade-off는 경험적 측정이 답
- 압축 ↑ → token ↓ → accuracy ↓
- 얼마나 압축할지는 segment 별로 다름
- 학내 비개발자 segment의 use case가 복잡하지 않으면 강한 압축 가능
- v1.0에서 측정 hook 박아두기 — 어떤 tool이 잘못 선택되는지 추적
- 이게 진화 기반 design — 답을 결정하지 않고 측정해서 조정
5.10 Cross-cutting concern을 처음부터 의식하라
- 보안, audit, rate limit은 나중에 추가하기 어렵다
- 한 번 ecosystem이 자리 잡으면 behavior 변경이 사용자 경험을 깸
- v1.0에서 gateway 자리를 비워두지 말 것. 빈 gateway라도 박아두기
- 이게 design-principles reversibility 원칙 — 미래의 변경을 위한 hook
6. 다음으로의 연결
이 노트로 ③ Frontier의 cross-cutting concern 영역이 박혔다. ③ 남은 sub-노트:
-
frontier-rl-skill-generation — RL로 skill 자동 생성. gateway 위에 skill 생성 layer 추가하는 방향.
- AutoSkill, WebRL, SkillRL의 production maturity
- 학내 segment에서 automation 가능성
-
frontier-acp-and-agent-as-server — agent를 tool로 노출. gateway의 수신 측면 확장.
- ACP — agent ↔ client 표준
- agent-as-MCP-server — agent 자체를 tool로
- multi-agent 시대의 layer 추가
내 추천 — frontier-rl-skill-generation 다음. skill 자동 생성은 gateway 위의 새 layer — 같은 mechanism으로 lens 적용 가능. 그 다음 ACP/agent-as-server (multi-agent는 학내 v2.0 이후 자리).
참조
- Anthropic Claude Code — bundled gateway + Skills lazy loading. production 사례.
- agentskills.io SKILL.md — description field가 trigger
- ⚠️ Tool description distillation 학술 — 진행 중인 방향
- Service Mesh / Sidecar 패턴 — software 일반의 cross-cutting concern 패턴
- Anthropic Context Rot 발견 — token 부담의 hidden 비용
연결:
-
- evolution-mcp-to-skills — token 부담이 등장한 단계
- protocol-theory-lamport-tanenbaum — Trap 5가 cross-cutting concern. 이 노트는 그 답
- postels-law-and-robustness — gateway = liberal receiver의 자리
- design-principles #7 Anti-Corruption Layer — gateway의 직접 적용
- research-to-production-gap — production 패턴 채택, research 답 기다리지 않음
- standardization-political-economy — gateway가 권력 집중 자리