에이전트 스택(agent stack)에서 누락된 계층에 대한 현장 노트.

개발 도구 역사상 가장 빠른 표준화

18개월 전, "에이전트가 도구를 어떻게 호출하는가?"에 대한 표준화된 답변은 없었습니다. 모든 프레임워크가 자신만의 방식을 만들어냈습니다. 그러다 업계는 한 가지 방식을 매우 빠르게 채택했습니다:

• 2024년 11월. Anthropic이 MCP를 오픈 소스로 공개합니다.
• 2025년 3월. OpenAI가 ChatGPT와 Agents SDK 전반에 이를 채택합니다.
• 2025년 4월. Google이 50개 이상의 출시 파트너와 함께 A2A를 발표합니다.
• 2025년 8월. IBM의 ACP가 A2A로 통합됩니다. 프로토콜들이 이미 통합되고 있습니다.
• 2025년 말. MCP와 A2A 모두 Linux Foundation에 안착합니다.

2025년 12월까지, Anthropic의 생태계 업데이트는 10,000개 이상의 활성 공개 MCP 서버와 9,700만 회 이상의 월간 SDK 다운로드를 기록했습니다. 공식 레지스트리는 1만 개에 가까운 기록을 보유하고 있습니다. 약 16,000개의 GitHub 저장소가 mcp-server 토픽을 포함하고 있습니다. A2A는 2026년 4월까지 150개의 지원 조직을 넘어섰습니다.

프로토콜이 승리했습니다. 대부분의 척도로 볼 때, REST보다 더 빠르게 승리했습니다.

그럼에도 불구하고 모든 실제 스택은 수작업으로 유지되고 있다

채택 수치가 숨기고 있는 사실은 이것입니다: 아무도 단 하나의 프로토콜만 사용하지 않습니다.

업계 조사 데이터에 따르면 전형적인 MCP 환경은 2개에서 7개의 구성된 서버를 가집니다. 본격적인 배포 환경에서는 수명이 긴 에이전트 간(agent to agent) 작업, 즉 A2A가 존재하는 이유 그 자체를 실행합니다. MCP는 상태 유지(stateful)가 필요한 다회차 위임(multi-turn delegation)에는 적합한 형태가 아니기 때문입니다. 또한 API가 전혀 없어 컴퓨터 사용(computer use)을 통해 구동되는 소프트웨어들의 롱테일(long tail)도 존재합니다.

이러한 각 쌍은 수작업으로 작성된 글루 코드(glue code)로 연결됩니다. 맞춤형 라우팅(Bespoke routing). 맞춤형 인증 핸드오프(Bespoke auth handoffs). 맞춤형 출력 파싱(Bespoke output parsing). 맞춤형 재시도 로직(Bespoke retry logic). 모든 팀이 이를 작성하고, 모든 팀이 이를 유지 관리하지만, 그 중 어느 것도 공유되지 않습니다.

커뮤니티는 이를 예견했습니다. A2A가 출시되었을 때, 가장 주된 반응은 본질적으로 다음과 같았습니다: "우리는 이미 MCP가 있는데, 왜 또 다른 표준이 필요한가요?" 솔직한 답변은 이들이 문제의 서로 다른 절반을 해결한다는 것입니다. 진짜 문제는 그것들을 조합(compose)하는 계층을 표준화한 사람이 아무도 없다는 점입니다.

그리고 이는 이론적인 고통이 아닙니다. Zuplo의 'State of MCP 2025' 보고서에 따르면, 기능적 격차보다 보안 및 액세스 제어(access control)가 프로덕션 환경에서 MCP 도입을 가로막는 1순위 장애물인 것으로 나타났습니다. 도구들은 작동합니다. 하지만 그것들을 함께 운영하는 것은 작동하지 않습니다.

병목 현상은 이동했고, 거의 아무도 이를 따르지 않았다

2026년 "루프 엔지니어링 (loop engineering)" 담론에서 가장 유용한 아이디어는 이것입니다:

어떤 에이전트 루프(agent loop)에서도 병목 현상은 검증자(verifier)이지, 모델이 아니다.

생성(Generation)은 저렴하며 무한히 돌아갑니다. 루프는 무언가가 _전송할지, 재시도할지, 아니면 중단할지_를 판단할 수 있는 속도만큼만 가치를 창출합니다. Andrew Ng는 평가자(evaluators)에 대해 이야기합니다. Karpathy는 이 기술 전체를 생성(generation)과 검증(verification)의 틀로 정의합니다. 루프 엔지니어링에 대해 글을 쓰는 실무자들은 모두 동일한 관문에 도달합니다.

이제 여기에 조합(composition)을 곱해 보십시오.

하나의 에이전트, 하나의 루프, 하나의 검증자. 어렵지만 이해할 수 있습니다. 단일 목표 내에서 M개의 프로토콜을 사용하는 N개의 에이전트라고요? 검증 범위(verification surface)가 폭발적으로 증가합니다. 어떤 단계에서 실패했나요? 출력이 구조화되어 있었나요? 올바른 에이전트가 호출되었나요? 그것이 그렇게 하는 것이 허용되었나요? 단일 에이전트 루프 도구들은 이러한 질문에 답하지 못합니다. 왜냐하면 그러한 질문을 받은 적이 없기 때문입니다.

채팅 출력은 상황을 더 악화시킨다

멀티 에이전트 실행이 성공하더라도, 결과는 산문(prose) 형태로 전달됩니다.

채팅 말풍선은 스키마 (schema)를 기준으로 검증할 수 없습니다. 실행 간에 차이점 (diff)을 비교할 수도 없습니다. 모니터링할 수도 없습니다. 스크롤하는 순간 증발해 버립니다. 만약 검증기 (verifier)가 병목 구간이라면, 검증할 수 없는 출력은 신뢰할 수 없는 출력입니다. 산문 (prose)은 우리 업계가 대규모로 출시한 형식 중 검증 가능성이 가장 낮은 형식입니다.

구조화된 출력 (Structured output)은 UX 선호도의 문제가 아닙니다. 그것은 검증을 위한 전제 조건입니다.

그렇다면 누락된 계층은 어떤 모습이어야 하는가?

문제를 충분히 오래 들여다보고 있으면 명세 (spec)가 스스로 작성되기 시작합니다. MCP와 A2A는 메시지가 A에서 B로 전달되는 방식을 표준화합니다. 하지만 독립적으로 실행되는 수십 개의 에이전트가 어떻게 하나의 목표로 계획되고, 올바른 순서로 호출되며, 인증 및 검증되고, 렌더링되는지에 대해서는 아무것도 말하지 않습니다. 그 누락된 계층이 바로 **에이전트 하네스 (agent harness)**입니다. 여기에는 다음과 같은 것들이 필요합니다:

1. 프로토콜 불가지론적 디스패치 (Protocol agnostic dispatch). 오늘은 MCP와 A2A, 내일은 n8n이나 OpenAPI 또는 LangGraph 서버를 대상으로 하되, 프로토콜마다 새로 구축하는 대신 인증 (auth), 재시도 (retries), 결제 (payments)를 상속받는 얇은 브릿지 (bridge)를 통해 구현합니다. MCP와 A2A는 단지 첫 두 개의 브릿지여야 합니다.
2. 검색 (retrieval)으로 취급되는 디스커버리 (Discovery).

질문

프로토콜들이 18개월 만에 표준화되었습니다. 컴포지션 레이어 (composition layer)는 대략 2024년 말의 MCP가 처했던 상황과 비슷합니다. 모두가 그것을 필요로 하지만, 아무도 이름을 붙이지 않았으며, 글루 코드 (glue code)가 쌓여가고 있습니다.

그래서 저는 제가 스스로에게 던져왔던 질문을 여러분께 묻고자 합니다.

하네스 레이어 (harness layer)에는 무엇을 담아야 할까요? 다중 프로토콜 에이전트 실행 (multi protocol agent runs)을 프로덕션 환경에서 신뢰할 수 있게 만들기 위해 제가 놓치고 있는 속성은 무엇일까요? 그리고 제 목록 중에서 여러분이 틀렸다고 생각하는 것은 무엇인가요?

저는 한동안 하나의 해답을 구축해 오고 있습니다. 이에 대해서는 이번 주에 더 자세히 다루겠습니다.

출처 및 추가 읽을거리:

• Model Context Protocol, Wikipedia (출시 타임라인, OpenAI 채택, Linux Foundation 이전)
• The State of MCP and A2A in 2025, O. Glukhov (1만 개 이상의 서버, 월간 9,700만 회 다운로드, A2A 생태계 수, "우리는 이미 MCP를 가지고 있다"는 논쟁)
• MCP usage statistics roundup, MCPManager
• State of MCP 2025, Zuplo (보안이 프로덕션의 1순위 차단 요소)
• Loop Engineering in AI Agents, AI Builder Club, 2026 (검증기 (verifier)가 병목 구간이라는 프레임)