Agentic AI Foundation의 표준 스택: MCP, A2A, 및 Goose

Agentic AI Foundation은 대부분의 팀이 첫 번째 에이전트 개념 증명(PoC) 이후에 직면하는 문제를 해결하기 위해 표준 스택을 구축하고 있습니다. 즉, 서로 다른 공급업체의 에이전트를 어떻게 연결하고, 이들이 도구를 공유하며, 모든 통합마다 사용자 지정 접착 코드(glue code)를 작성하지 않고도 다단계 워크플로우를 조정할 수 있을까요?

이 노력의 핵심에는 세 가지 프로토콜이 자리 잡고 있습니다. MCP (Model Context Protocol)는 에이전트가 도구를 발견하고 호출하는 방식을 표준화합니다. A2A (Agent-to-Agent)는 조직 경계를 넘어 에이전트가 인증하고, 메시지를 라우팅하며, 상태를 동기화하는 방법을 정의합니다. Goose는 이러한 표준을 기반으로 구축된 에이전트들이 실제로 상호 운용되는지 검증하기 위한 참조 구현 및 테스트 하우스를 제공합니다.

이는 제품 출시가 아닌 인프라 작업입니다. 이 재단은 오케스트레이션 프레임워크와 배포하는 에이전트 사이에 위치하는 배관(plumbing) 계층을 설계하고 있습니다.

3계층 표준 스택

MCP: 도구 경계 프로토콜 (Tool Boundary Protocol)

MCP는 에이전트와 외부 도구 간의 인터페이스를 표준화합니다. 각 에이전트 런타임이 자체 함수 호출 형식을 구현하는 대신, MCP는 다음을 정의합니다:

• 도구 발견 및 호출을 위한 JSON-RPC 2.0 전송 방식
• 도구 기능 및 매개변수 유형을 위한 스키마 레지스트리
• 도구 호출 간 상태를 전달하기 위한 컨텍스트 첨부 메커니즘

MCP 서버는 도구를 리소스로 노출합니다. 에이전트는 서버에 사용 가능한 도구를 쿼리하고, 스키마를 검사하며, 메서드를 호출합니다. 이 프로토콜은 에이전트가 어떤 도구를 호출할지 결정하는 방법이나 결과를 해석하는 방법을 지시하지 않습니다. 이는 오케스트레이션 계층에 남아 있습니다.

A2A: 에이전트 조정 프로토콜 (Agent Coordination Protocol)

A2A는 서로 다른 플랫폼, 서로 다른 조직 또는 서로 다른 보안 컨텍스트에서 실행될 수 있는 에이전트 간의 통신을 처리합니다. 주요 책임은 다음과 같습니다:

• 인증: 에이전트 경계에서의 상호 TLS(Mutual TLS) 또는 OAuth 2.0 토큰 교환
• 상태 동기화: 에이전트 핸드오프를 거쳐 워크플로우 진행 상황, 결정 및 중간 결과를 추적하는 공유 컨텍스트 객체

A2A는 특정 오케스트레이션 패턴을 강제하지 않습니다. 따라서 코레오그래피(choreography, 에이전트가 이벤트에 반응하는 방식)를 구축할 수도 있고, 오케스트레이션(orchestration, 중앙 조정자가 작업을 분배하는 방식)을 구축할 수도 있습니다. 이 프로토콜은 메시지 버스와 상태 저장소(state store)를 제공하며, 제어 흐름(control flow)은 사용자가 선택합니다.

Goose: 레퍼런스 구현 및 하네스 (Reference Implementation and Harness)

Goose는 작동하는 에이전트 런타임이자 동시에 규정 준수 테스트 스위트입니다. 이는 MCP와 A2A를 구현하며, 사용자 지정 도구 제공자(tool providers) 및 에이전트 로직을 위한 후크(hooks)를 노출합니다. 팀들은 Goose를 사용하여 다음 작업을 수행합니다:

• MCP 서버가 잘 구성된 스키마(well-formed schemas)를 반환하는지 검증
• 네트워크 분할(network partitions)이나 인증 실패 상황에서 A2A 메시지 라우팅을 테스트
• 프로토콜 어댑터(protocol adapters)를 작성하지 않고도 개념 증명(proof-of-concept) 다중 에이전트 워크플로우 구축

Goose는 프로덕션 오케스트레이션 프레임워크가 아닙니다. 이는 표준이 작동함을 입증하는 레퍼런스이자, 상용 환경에 도달하기 전에 상호 운용성 버그(interoperability bugs)를 포착하는 하네스입니다.

아키텍처: 프로토콜 간의 연결 방식 (How the Protocols Wire Together)

┌─────────────────────────────────────────────────────────┐
│                   오케스트레이션 레이어 (Orchestration Layer)                    │
│          (LangGraph, Temporal, 사용자 지정 코드)              │
... 

다중 에이전트 작업 흐름:

1. 오케스트레이터가 Agent A에게 작업을 할당합니다.
2. Agent A는 사용 가능한 도구를 확인하기 위해 MCP 서버에 질의(query)합니다.
3. Agent A가 도구를 호출하고 부분적인 결과를 받습니다.
4. Agent A는 A2A 브로커에

• 스키마 드리프트 (Schema drift): 에이전트가 MCP 서버가 더 이상 제공하지 않는 도구 매개변수를 예상함. 에이전트는 충돌하거나 무한히 재시도함.
• 라우팅 루프 (Routing loops): 에이전트 A가 에이전트 B에 위임하고, B가 다시 에이전트 A로 위임함. A2A 브로커는 기본적으로 사이클을 감지하지 못함.
• 토큰 만료 (Token expiration): 장시간 실행되는 워크플로우가 작업 중간에 OAuth 토큰 만료를 겪음. A2A는 자동 새로고침을 하지 않으므로, 에이전트가 재인증을 처리해야 함.
• 부분 상태 손실 (Partial state loss): 에이전트가 A2A 메시지를 게시한 후 로컬 상태를 영속화하기 전에 충돌함. 수신하는 에이전트는 메시지를 처리하지만, 전송하는 에이전트는 요청 기록이 없음.

구현 고려 사항 (Implementation Considerations)

MCP 채택 시점:

• 도구를 공유해야 하는 여러 에이전트 런타임(LangChain, AutoGen, 사용자 정의)을 가지고 있을 때
• 도구 개발과 에이전트 로직을 분리하고 싶을 때
• 에이전트가 런타임에 조회할 수 있는 사용 가능한 도구 레지스트리가 필요할 때

A2A 채택 시점:

• 에이전트들이 서로 다른 프로세스나 조직에서 실행되는 다중 에이전트 워크플로우를 구축하고 있을 때
• 하드코딩된 라우팅 없이 에이전트가 서로 발견하고 위임해야 할 필요가 있을 때
• 에이전트 간의 직접적인 HTTP 호출 대신 메시지 버스 추상화(abstraction)를 원할 때

Goose 사용 시점:

• 다중 에이전트 시스템을 프로토타이핑하고 상호 운용성을 조기에 검증하고 싶을 때
• MCP 또는 A2A 구현에 대한 적합성 테스트 스위트(conformance test suite)가 필요할 때
• 프로덕션 어댑터를 구축하기 전에 연구해 볼 작동 예제가 필요할 때

이 표준들을 피해야 할 경우:

• 단일 에이전트 시스템은 고정된 도구 세트를 가집니다. 직접적인 함수 호출(Direct function calls)이 더 간단합니다.
• 에이전트는 단일 프로세스에서 실행되며 메모리를 공유합니다. A2A는 이점 없이 네트워크 오버헤드를 추가합니다.
• 100ms 미만의 지연 시간(latency)이 필요합니다. 프로토콜 협상 및 메시지 라우팅은 호프당 수십 밀리초를 추가합니다.

보안 경계 (Security Boundaries)

MCP와 A2A는 에이전트가 신뢰할 수 있는 환경에서 작동한다고 가정합니다. 이 프로토콜들은 다음을 강제하지 않습니다:

• 입력 유효성 검사(Input validation): 에이전트는 MCP 서버를 호출하기 전에 도구 매개변수를 정화(sanitize)해야 합니다.
• 속도 제한(Rate limiting): MCP 서버는 수천 개의 도구 호출을 하는 에이전트에 의해 과부하될 수 있습니다.
• 기능 격리(Capability isolation): 하나의 MCP 서버에 접근할 수 있는 에이전트는 해당 서버가 노출하는 모든 도구를 호출할 수 있습니다.

운영 환경 배포(Production deployments)에는 추가 계층이 필요합니다:

• 속도 제한 및 인증을 강제하기 위한 MCP 서버 앞단의 API 게이트웨이(API gateways)
• 어떤 에이전트가 어떤 도구를 호출할 수 있는지 제한하는 정책 엔진(Policy engines)
• 모든 A2A 메시지 및 MCP 도구 호출에 대한 감사 로그(Audit logs)

기반 구조는 와이어 프로토콜을 제공합니다. 보안 제어는 사용자가 제공해야 합니다.

관측 가능성 격차 (Observability Gaps)

MCP나 A2A 어느 쪽도 분산 추적(distributed tracing)에 대한 표준을 포함하지 않습니다. 만약 Agent A가 MCP를 통해 도구를 호출하고, 이를 A2A를 통해 Agent B에게 위임하며, Agent B가 또 다른 도구를 호출한다면, 이 모든 이벤트를 단일 트레이스(single trace)로 상관관계 분석할 자동적인 방법이 없습니다.

옵션:

• MCP 도구 매개변수와 A2A 메시지 헤더에 추적 컨텍스트(trace context) 주입. 모든 에이전트 및 도구 서버에 사용자 지정 계측(custom instrumentation)이 필요합니다.
• MCP 및 A2A 트래픽을 가로채서 식별자를 추출하고 OpenTelemetry로 트레이스를 방출하는 사이드카 프록시(sidecar proxy) 사용. 배포 복잡성을 증가시킵니다.
• 오케스트레이션 계층에서 **로그 상관관계 ID(Log correlation IDs)**를 기록하고 스택 전체에 전달합니다. 에이전트가 ID를 전파하고 구조화된 로그를 방출하도록 요구합니다.

이 표준들은 관측 가능성 문제를 해결하지 못합니다. 스스로 구축할 수 있는 후크(hooks)만 제공할 뿐입니다.

기술적 결론 (Technical Verdict)

MCP를 사용해야 하는 경우는 공급업체 중립적인(vendor-neutral) 도구 레지스트리가 필요하고 모든 에이전트 런타임마다 사용자 지정 어댑터를 작성하는 것을 피하고 싶을 때입니다. 이 프로토콜은 안정적이며, 참고 서버들은 운영 환경에 바로 투입할 수 있을 정도로 준비되어 있고, 생태계가 성장하고 있습니다.

A2A를 사용해야 하는 경우는 에이전트들이 서로 발견하고 동적으로 조정해야 하는 다중 에이전트 시스템을 구축하는 경우입니다. 이 프로토콜은 MCP보다 더 새롭고 실전 테스트가 덜 되었지만, 오케스트레이션 프레임워크가 해결하지 못하는 실제 문제를 해결합니다.

Goose를 사용해야 하는 경우는 프로토타이핑 및 규격 준수 테스트(conformance testing)용입니다. 이를 운영 환경에 배포해서는 안 됩니다. MCP와 A2A 위에 자체 에이전트 런타임을 구축하고, Goose를 참고 자료로 활용하십시오.

단순한 단일 에이전트 시스템을 가지고 있거나 절대적으로 낮은 지연 시간(latency)이 필요한 경우 이러한 표준은 피해야 합니다. 이 프로토콜들은 복잡성과 오버헤드를 추가합니다. 대안이 모든 통합에 대해 사용자 지정 접착 코드(glue code)를 작성하는 것이라면, 이들을 사용하십시오.

Agentic AI Foundation은 다중 에이전트 시스템을 위한 배관 계층(plumbing layer)을 구축하고 있습니다. 표준들은 완성되지 않았고, 툴링도 세련되지 않았으며, 실패 모드(failure modes)가 모두 문서화된 것도 아닙니다. 하지만 대규모로 에이전트를 배포할 계획이라면, 이것은 반드시 논의해야 할 인프라 관련 주제입니다.

소스 링크

• Practical AI Podcast: Agentic AI 시대의 기반 구축
• Agentic AI Foundation