Frontier: ACP and Agent-as-MCP-Server

ACP와 agent-as-MCP-server는 다른 frontier지만 같은 thesis를 가진다 — agent의 경계가 흐려지고 있다. agent가 client인지 server인지, tool인지 orchestrator인지 — 하나의 정체성이 아니라 역할에 따라 변하는 것. multi-agent 시대에 agent는 경계가 있는 객체가 아니라 역할에 따라 변하는 layer다.

1. 철학

frontier-rl-skill-generation에서 본 skill을 누가 만드는가 압력에 이어, 또 다른 압력이 가시화된다 — agent가 무엇인가.

전통적으로 agent는 정체성 있는 객체였다. chatbot이거나 코딩 agent. client (IDE)와 분리되고, tool은 server에 있었다. 이 경계가 흐려지고 있다.

핵심 thesis 한 줄:

multi-agent 시대에는 agent가 경계가 있는 객체가 아니라 역할에 따라 변하는 layer다.

같은 agent가 여러 역할을 동시에 가질 수 있다:

• ACP server face — Zed/JetBrains/Neovim에서 호출 가능
• MCP server face — 다른 agent의 tool로 사용 가능
• ACP client face — 다른 agent를 호출
• MCP client face — MCP server 호출

이게 evolution-mcp-to-skills의 layer 위의 layer 패턴이 또 한 번 작동하는 자리. 그러나 이번엔 agent 자체가 layer로 분해된다.

2. 추상 작동 구조

Agent의 4 페이스

각 face가 다른 layer에서 작동. 한 agent가 동시에 4 face를 가질 수 있음 (Goose 패턴).

Multi-agent layer의 점진적 등장

진화는 agent가 단일 객체에서 agent가 layer 안의 한 점으로 옮겨가는 과정.

ACP — Agent Client Protocol

⚠️ AI 추정: ACP는 de facto 표준이 되려는 단계. 채택 속도 빠름. 그러나 VS Code 미채택은 분기 가능성.

agent-as-MCP-server

본질: agent를 MCP tool로 변환. multi-agent 호출이 MCP 위에서 일어남.

Goose의 양방향 ACP — multi-agent의 진짜 상태

가장 흥미로운 사례:

• ACP server: Zed/JetBrains에서 Goose 직접 호출
• ACP client: Goose가 Claude Code/Codex를 provider로 사용

→ agent가 동시에 server이자 client. 이게 multi-agent ecosystem이 자리잡으면 대부분 agent의 정상 상태가 될 것 (⚠️ AI 추정).

3. 약점

Trap 1 — Agent 경계 모호의 trap

agent가 어디까지가 자기인지 모호해짐. 권한, 책임, audit이 어려워짐. delegated execution의 권한 chain이 깨질 수 있음. 학내 segment에서 누가 무엇을 할 권한이 있는지가 더 모호해짐.

Trap 2 — Latency 누적

agent A → agent B → agent C → tool. 각 호출마다 LLM inference + transport. latency가 덧셈적으로 누적. 사용자 경험에 결정적. 학내 segment에서 느린 multi-agent는 채택 안 됨.

Trap 3 — Token 부담의 폭증

각 agent가 자기 context. multi-agent는 context가 곱해짐. token 부담이 frontier-tool-gateway-and-compression에서 본 것보다 더 결정적. 학내 1000 req/day quota가 multi-agent에서 100 turn 미만으로 줄어듦. 이게 multi-agent를 학내 segment에서 멀리 두는 결정적 이유.

Trap 4 — Cost attribution

multi-agent에서 누가 비용을 지불하는지 모호. 학내 segment에서 예산 추적이 multi-agent에서 깨짐. v1.0에서 cost tracking hook이 없으면 — 학내 quota가 어디서 소진됐는지 불명.

Trap 5 — 표준이 자리 잡지 않음

ACP는 자리 잡는 중. Registry 출범 아직 초기. VS Code 미채택은 분기 가능성. 학내 marketplace에서 ACP 직접 채택은 risk. anti-corruption layer로 격리 필수.

Trap 6 — Multi-agent의 디버깅 지옥

한 agent의 행동을 다른 agent의 행동과 분리해서 보기 어려움. ⚠️ AI 추정: 이게 production 도달을 막는 큰 lever. 학내 segment에서 디버깅 가능한 single agent가 적절.

Trap 7 — Loop 위험

agent A가 agent B를 호출, agent B가 agent A를 호출 → infinite loop. timeout 없으면 quota 즉시 소진. 1000 req/day quota는 몇 분 안에 소진 가능. v1.0에서 circuit breaker가 protocol-theory-lamport-tanenbaum partial failure thesis의 직접 적용.

4. 대안 흐름

multi-agent 대신 다른 방향들:

⚠️ AI 추정: 학내 segment v1.0은 single agent + many tools가 적절. multi-agent는 v3.0 이후.

Production maturity 평가

학내 v1.0은 single agent. ACP/MCP server 노출은 future hook만.

5. 인사이트

5.1 agent의 경계가 layer로 분해되고 있다

전통: agent = 정체성 있는 객체. 현재: agent = 역할에 따라 변하는 layer 안의 한 점. ACP face / MCP server face / MCP client face / ACP client face — 다 같은 agent의 다른 layer. 학내 segment는 지금 이 변화를 따라잡을 필요 없음. 그러나 그 방향으로 진화한다는 사실을 의식.

5.2 Goose의 양방향 ACP가 보여주는 미래

agent가 동시에 server이자 client. 다른 agent를 호출하면서 다른 agent에게 호출됨. 이게 multi-agent의 정상 상태. 학내 segment의 언젠가의 미래. v1.0은 그 미래로 가는 path 위에 있어야 함, 목적지에 도달할 필요 없음.

5.3 학내 v1.0은 single agent + many tools가 적절

• multi-agent는 production maturity 낮음
• 학내 1000 req/day quota는 multi-agent에 부적합 (turn 수 1/10로 감소)
• latency 누적이 사용자 경험 깸
• 디버깅 지옥
• v1.0은 single agent. 이게 research-to-production-gap thesis 직접 적용

5.4 그러나 agent 노출 hook은 처음부터 박아두기

• v1.0에서 agent를 call할 수 있게 만들어두면 — 미래의 ACP/MCP server 노출이 수월
• 외부에서 agent를 호출하는 가능성을 처음부터 의식
• 이게 design-principles reversibility 적용
• 빈 hook이라도 v1.0에 박아두기

5.5 Latency 누적과 Token 폭증이 multi-agent의 결정적 비용

• 각 호출마다 LLM inference + transport (latency)
• 각 agent가 자기 context (token 곱셈)
• 두 비용이 agent 수 비례로 누적
• 학내 segment의 느린 + token 폭증 multi-agent는 채택 안 됨
• 학내 답: single agent + many tools. 빠르고 예측 가능.

5.6 Cost attribution이 multi-agent의 governance 자리

누가 비용을 지불하는지 — multi-agent에서 깨짐. 학내 segment에서 예산 추적이 결정적 (1000 req/day quota). v1.0에서 cost tracking hook 박아두기. multi-agent를 나중에 추가하더라도 governance가 처음부터.

5.7 Multi-agent의 디버깅 지옥 — production 도달의 결정적 lever

한 agent의 행동 추적이 어려움. ⚠️ AI 추정: 이게 production 도달을 막는 큰 lever. single agent도 디버깅이 어려운데 multi-agent는 지수적 어려움. 학내 segment에서 디버깅 가능한 single agent가 정답. v3.0 이후 multi-agent 도입 시 추적 가능한 형태로 design.

5.8 표준 자리 잡는 중 → anti-corruption layer로 격리

• ACP는 자리 잡는 중. Registry 출범 초기.
• VS Code 미채택. 분기 가능성.
• v1.0에서 ACP가 자리 잡으면 흡수 가능하게 design. 직접 채택 X. anti-corruption layer로 hook.
• 이게 design-principles #7의 직접 적용

5.9 Loop 위험 — Lamport thesis의 직접 적용

agent A → agent B → agent A → ... infinite. timeout 없으면 1000 req 즉시 소진. v1.0에서 circuit breaker 박아두기. 이게 protocol-theory-lamport-tanenbaum partial failure thesis의 직접 적용 — 분산 호출의 timeout/retry는 protocol 결정이지 application 결정 아님. multi-agent를 나중에 추가해도 이 hook은 처음부터 필요.

5.10 Sentry의 sub-agent as tool 패턴이 학내 현실적 답

양방향 ACP는 너무 이르다. single agent + sub-agent로 위임 (Sentry 패턴)이 적절. v2.0의 현실적 multi-agent. agent를 완전히 동등한 peer로 보지 않고, 제한된 sub-task 위임으로 보는 view. 학내 segment의 complexity 한도에 적합.

5.11 agent 경계의 분해는 Anti-Corruption Layer가 더 결정적임을 보여줌

agent face가 4개. 각 face가 다른 vendor의 다른 표준과 만남. 변형이 4 layer에서 동시에 일어날 수 있음. 학내 marketplace에서 각 face마다 ACL. v1.0이 모든 face를 노출할 필요 없지만, 어떤 face를 노출할 때 ACL이 처음부터 있어야 함.

5.12 ③ Frontier의 통일된 thesis

세 영역 합산 — gateway·압축, RL skill 생성, agent 경계 분해 — 가 같은 mechanism을 보여준다:

layer가 자리 잡으면 그 위에서 새 layer가 등장한다. 그 layer는 기존 layer를 대체하지 않고 위에 추가된다. 그래서 ACL이 결정적이다.

이 thesis가 ④ Synthesis로 가는 가장 중요한 다리.

6. ③ Frontier 완성 — 세 영역 합산

이 노트로 ③ Frontier가 완성됐다.

③ 합산 thesis:

layer가 자리 잡으면 그 위에서 새 layer가 등장한다. 새 layer는 기존을 대체하지 않고 위에 추가된다. 그래서 anti-corruption layer가 결정적이다.

학내 marketplace v1.0의 적용:

• gateway · lazy loading: 직접 채택 (production maturity 100%)
• RL skill 생성: future hook만 (production maturity <30%)
• agent 노출: future hook만 (production maturity <60%)

이 lens가 박혔으니 ④ Synthesis로 — 5 옵션의 깊은 trade-off. ①②③의 모든 lens가 모이는 자리.

7. 다음으로 — ④ Synthesis

trade-off-five-options — 5 옵션 (Hybrid · MCP 단일화 · Tool only · Tool as API · MCP+Skills lazy)의 깊은 trade-off:

차원 (이전 chat에서 제시된):

• token 비용
• ecosystem
• 속도
• 언어 호환
• product 호환
• 복잡도
• 진입장벽
• learning curve
• debugging

각 차원을 ① 4축 + ② 두 단계 + ③ 세 영역으로 기계적으로 분석. 각 옵션의 trade-off 이유가 원리에 닿게.

참조

• ACP 공식 — agentclientprotocol.com
• ACP Registry — zed.dev/blog/acp-registry (2026-01-28)
• Microsoft Agent Framework — agent-as-MCP-tool 패턴
• agno (agno-agi/agno) — enable_mcp_server=True
• Sentry sub-agent 패턴 — cra.mr 글
• Goose 양방향 ACP — github.com/block/goose

연결:

• evolution-mcp-to-skills — layer 위의 layer 패턴이 또 한 번 적용
• frontier-tool-gateway-and-compression — gateway가 multi-agent에서 더 결정적
• frontier-rl-skill-generation — agent 경계 분해와 같은 production maturity 평가 lens
• protocol-theory-lamport-tanenbaum — partial failure / loop / circuit breaker thesis 직접 적용
• design-principles #7 Anti-Corruption Layer — agent 4 face마다 ACL 필요
• standards-and-protocols — ACP가 v1 선택적, v2에서 외부 IDE 통합 시 추가
• research-to-production-gap — multi-agent의 production 도달 어려움