지난 1년 동안 6개의 에이전트 프로토콜이 출시되었습니다. 모두가 모델 선택에 집착하고 있습니다. 하지만 실제로 무너지는 지점은 모델 주변의 운영 표면(Operating surface)입니다. 오늘 Google I/O는 에이전트 데모의 홍수와 함께 시작되었습니다. 프롬프트가 앱이 되고, 바이브 코딩(Vibe coding)이 프로덕션 단계로 넘어갑니다. 그 장관은 실재합니다. 하지만 이 모든 것이 작동할지 여부를 결정하는 요소는 무대 위에 있지 않습니다. 그것은 그 아래에 숨겨진 조용한 프로토콜 스택(Protocol stack) — MCP, A2A, AGUI, 그리고 논쟁 중인 그 사촌들입니다. 대부분의 팀은 자신이 어떤 LLM을 사용하는지는 말할 수 있습니다. 하지만 거의 아무도 다음 질문에 답하지 못합니다: 에이전트가 어떤 도구(Tools)를 봐야 하는가? 누구에게 권한을 위임할 수 있는가? 인간은 어디에서 승인하거나 취소하는가? 이 세 가지 질문이 바로 스택입니다. 각 계층에 무엇이 있는지 살펴보겠습니다.
MCP: 도구는 기능 토글(Feature toggle)이 아니라 보안 경계입니다
MCP는 단연코 가장 성공적인 에이전트 프로토콜입니다. 이 태그가 달린 GitHub 저장소는 14,000개에 달합니다. 모든 주요 에이전트 플랫폼이 이를 지원합니다. 에이전트는 MCP 서버에 연결하여 호출 가능한 도구 목록을 가져오고, 단순히 채팅만 하는 대신 실제로 작업을 수행할 수 있습니다. 하지만 아무도 공개적으로 말하지 않는 사실이 있습니다: 레지스트리(Registry)가 없다는 것입니다. MCP 검색 기능도 없습니다. 에이전트가 프로그래밍 방식으로 서버를 발견할 방법도 없습니다. 14,000이라는 숫자는 GitHub 태그 집계일 뿐, 등록된 디렉토리가 아닙니다. Smithery.ai는 약 6,700개를 나열하고 있지만, 이는 API가 아니라 사용자가 직접 눈으로 찾아보는 방식입니다. 에이전트는 "Salesforce를 위한 MCP 서버를 찾아줘"라고 요청하고 답변을 얻을 수 없습니다. 발견(Discovery)은 사람이 목록을 읽는 행위입니다. 그것은 프로토콜이 아닙니다. 그것은 보물찾기입니다. 도구 접근은 임의의 코드 실행(Arbitrary code execution)과 임의의 데이터 접근을 가능하게 합니다. MCP는 높은 신뢰 환경을 위해 설계되었습니다. 하지만 이제는 어디에나 있습니다. Invariant Labs는 도구 포이즈닝(Tool poisoning)에 관한 연구를 발표했습니다. 이는 도구를 발견 가능하게 만들기 위한 바로 그 메타데이터를 통해 에이전트에 영향을 미치는, 도구 설명에 숨겨진 악의적인 지침을 의미합니다. MCP는 에이전트를 작업에 가깝게 가져다주지만, 에이전트가 그 작업을 수행해야 하는지 여부를 결정하지는 않습니다. 그것은 여러분의 몫입니다.
A2A: 조정(Coordination)은 공짜가 아닙니다
단일 에이전트가 모든 것을 수행할 수는 없습니다. 조달 에이전트(Procurement agent)에는 공급업체 에이전트(Supplier agent)가 필요합니다.
여행사 에이전트(Travel agent)에는 호텔 에이전트(Hotel agent)가 필요합니다. 소프트웨어 에이전트(Software agent)에는 보안 검토자(Security reviewer)가 필요합니다. 작업은 소유자, 도메인, 전문 지식 전반에 걸쳐 분산됩니다. A2A는 이러한 분산을 에이전트가 추론할 수 있는 무언가로 전환합니다. 에이전트 카드(Agent card)가 그 기본 단위(Primitive)입니다. 이는 원격 에이전트가 무엇인지, 무엇을 하는지, 어떤 기술(Skills)을 노출하는지, 그리고 어떻게 상호작용하는지를 설명하는 공개된 계약(Contract)입니다. 비용 측면에서는, 조정(Coordination) 과정에서 지연 시간(Latency), 실패(Failure), 권한(Permissions), 관찰 가능성(Observability)이 문제를 일으킬 수 있는 또 다른 접점이 추가됩니다. 만약 당신의 에이전트가 다른 에이전트에게 작업을 위임(Delegate)한다면, 워크플로(Workflow)는 더 유연해지는 동시에 예측 불가능해집니다. A2A가 모든 제품에 적합한 것은 아닙니다. 작은 도구 세트를 가진 단일 에이전트는 조정이 전혀 필요하지 않을 수도 있습니다. 올바른 질문은 이것입니다: 이 워크플로가 기본 에이전트 외부의 위임된 전문 지식이나 권한을 필요로 하는가?
AGUI: 너무 늦을 때까지 아무도 구축하지 않는 인간 제어 계층(Human control layer)
장시간 실행되고, 비결정론적(Non-deterministic)이며, 외부 시스템을 건드리는 에이전트에는 최종 답변 이상의 것이 필요합니다. 인간은 에이전트가 작동하는 것을 관찰하고, 민감한 단계를 승인하며, 상태(State)를 점검하고, 왜 대기 중인지 이해해야 합니다. 챗봇(Chatbots)은 이를 처리하지 못합니다. 요청-응답(Request-response) 방식으로 구축된 전통적인 웹 앱(Web apps)도 마찬가지입니다. AGUI는 이 계층을 위한 개방형 후보입니다: 스트리밍(Streaming), 공유 상태(Shared state), 프론트엔드 도구 호출(Front-end tool calls), 커스텀 이벤트(Custom events), 조종(Steering), 취소(Cancellation) 등이 포함됩니다. 이는 대부분의 팀이 에이전트가 실제 작업을 수행하고 실제 버그를 생성하기 시작할 때까지 무시하게 될 프로토콜입니다. 그들은 모델을 도구에 연결하고 멋진 채팅 컴포넌트(Chat component)를 구축한 다음, 에이전트가 실제로 무엇을 하고 있는지 발견하게 될 것이며, 그제야 사후적으로 승인 버튼, 로그, 진행률 스피너(Progress spinners)를 덧붙이게 될 것입니다. 이 중 그 어떤 것도 근본적인 문제에 대한 해결책은 아닙니다. 근본적인 문제는 적절한 제어 지점(Control points)을 찾고, 에이전트가 무엇을 하려고 하는지 이해하며, 인간이 어디에서 승인, 거부, 편집 또는 취소해야 하는지를 파악하는 것입니다.
아직 표준이 아닌 세 가지: A2UI, AP2, 그리고 X402는 모두 실제 사용 사례가 있지만 논쟁 중인 영역에 놓여 있습니다. A2UI는 에이전트 생성 인터페이스(Agent-generated interfaces)에 대한 Google의 해답으로, 임의의 HTML 대신 선언적 UI(Declarative UI)를 사용합니다.
올바른 방향이며, 완전한 인간 제어(human control) 문제보다 범위가 좁습니다. AP2와 X402는 모두 에이전트 결제(agent payments) 문제를 다룹니다. AP2는 상업적 신뢰와 사용자 권한 부여(authorization)를 처리합니다 (Mastercard, PayPal, American Express를 포함한 60명 이상의 협력자 참여). X402는 Coinbase의 HTTP 네이티브 머신 간 결제(machine-to-machine settlement)입니다. 결제(Payments)는 가장 가치 있는 영역이기 때문에 가장 혼잡한 레이어(layer)입니다. 모두가 참여하고 싶어 합니다. 지루한 것이 승리합니다. 팀들은 모델 선택에 과도하게 집중하고 그 주변의 모든 것을 불분명하게 정의합니다. 그들은 어떤 LLM을 원하는지는 압니다. 하지만 에이전트가 어떤 도구(tools)를 볼 수 있는지, 혹은 보아야 하는지는 모릅니다. 그들은 API를 호출하는 프로토타입(prototype)은 가지고 있지만, 사용자 승인을 위한 상호작용 모델(interaction model)은 없습니다. 여러 에이전트가 협력하는 모습은 상상할 수 있지만, 이를 강제하거나 검증할 방법은 없습니다. 실제 작업은 바로 그러한 질문들에 달려 있습니다. 프로토콜 스택(protocol stack)은 화려하지 않습니다. 인프라(infrastructure)도 마찬가지입니다. 하지만 6개월 후, 자신들의 운영 표면(operating surface)을 파악한 팀들이 에이전트를 계속 실행하고 있을 것입니다. 단순히 모델만 선택한 팀들은 무엇이 자신들을 덮쳤는지조차 모를 것입니다.