MCP와 A2A를 함께 쓰는 엔터프라이즈 Agent 통합 아키텍처: Tool 호출과 Agent 위임 경계를 분리하는 법

목차

1. 프로토콜 선택보다 책임 경계를 먼저 정한다
2. MCP와 A2A의 차이를 한 문장으로 구분한다
3. 엔터프라이즈 참조 아키텍처를 그린다
4. Tool과 Remote Agent의 선택 기준을 세운다
5. Agent Card를 실행 계약으로 관리한다
6. Discovery와 Registry를 신뢰 경계 안에 둔다
7. Message·Task·Artifact·Context를 분리한다
8. Task 상태를 업무 상태와 연결한다
9. A2A Task와 MCP Tasks를 같은 것으로 보지 않는다
10. Orchestrator의 책임을 제한한다
11. 위임 계약에 목적·범위·예산을 고정한다
12. 사용자 Token을 Agent Chain에 그대로 전달하지 않는다
13. Tenant Routing과 Tenant Authorization을 분리한다
14. 승인과 추가 인증을 Task 상태로 중단한다
15. Artifact와 파일 전달을 최소 권한으로 설계한다
16. Polling·Streaming·Webhook의 역할을 나눈다
17. Timeout·Cancel·Retry·보상 작업을 계약으로 만든다
18. A2A와 MCP 경계를 하나의 Trace로 연결한다
19. Trace·Audit·Evaluation의 저장 목적을 분리한다
20. Multi-Agent 평가는 위임 선택까지 검사한다
21. 합성 장애 사례로 전체 흐름을 읽어 본다
22. 단계적으로 도입한다
23. 흔한 안티패턴
24. 운영 체크리스트
25. 마무리
26. 공식 참고자료

사용자가 다음과 같이 요청했다고 가정해 보겠습니다.

“지난 회의에서 결정한 운영 개선 사항을 찾아 담당 조직과 일정을 확인하고,
승인받은 항목만 업무 시스템에 등록해 줘.”

하나의 Agent가 회의록을 검색하고, 조직 정보를 확인하고, 일정 충돌을 검사하고, 승인받은 뒤 업무를 등록할 수도 있습니다. 하지만 조직마다 Agent가 별도 제품·Framework·보안 경계로 운영된다면 하나의 거대한 Agent에 모든 Tool과 데이터를 모으는 방식은 빠르게 한계에 도달합니다.

이때 두 개의 공개 프로토콜이 자주 함께 등장합니다.

• MCP(Model Context Protocol) 는 Agent 애플리케이션이 Tool·Resource·Prompt와 연결되는 계약을 표준화합니다.
• A2A(Agent2Agent Protocol) 는 서로 독립적이고 내부 구현이 보이지 않는 Agent가 능력을 발견하고 업무를 위임하며 결과를 교환하는 계약을 표준화합니다.

둘은 경쟁 관계가 아닙니다. 문제는 “둘 다 연결 프로토콜”이라는 이유로 Remote Agent를 MCP Tool처럼 만들거나, 단순 API Tool을 A2A Agent로 감싸면서 시작됩니다. 그렇게 되면 Task 수명주기, 권한 위임, 취소, Trace와 장애 책임이 모호해집니다.

이 글은 MCP 기본 구조, 메시지 버스 기반 Multi-Agent 협업, AI Agent 관측성 설계, AI Agent 메모리 아키텍처, AI Agent 평가 아키텍처를 바탕으로 MCP와 A2A를 함께 쓰되 책임을 섞지 않는 엔터프라이즈 통합 경계를 정리합니다.

이 글의 Agent, 사용자, Tenant, Task, Artifact, URL, Token, 조직과 업무 Record는 모두 교육용 합성 예시입니다. 특정 회사·고객·제품의 실제 구성이나 성과를 나타내지 않습니다. A2A와 MCP 명세 및 SDK는 빠르게 바뀔 수 있으므로 실제 구현에서는 사용하는 Protocol Version과 공식 명세를 다시 확인해야 합니다.

1. 프로토콜 선택보다 책임 경계를 먼저 정한다

통합 설계의 첫 질문은 “MCP인가 A2A인가”가 아닙니다.

호출 대상이 정해진 기능을 실행하는가?
아니면 목표를 받아 자체적으로 계획하고 상태를 관리하는가?

기능 호출은 이름, 입력 Schema, 결과와 오류 계약을 중심으로 설계합니다. 반면 Agent 위임은 상대 Agent의 능력, Task 상태, 추가 질문, 중간 산출물, 장기 실행, 취소와 책임까지 다뤄야 합니다.

두 경계를 나누면 다음 질문이 명확해집니다.

• 누가 업무 계획을 세우는가?
• 누가 어떤 Tool을 선택하는가?
• 장기 실행 상태는 누가 보존하는가?
• 추가 입력이나 승인은 어느 Task에서 요청하는가?
• 외부 Side Effect의 최종 책임은 누구에게 있는가?
• 장애 시 재시도와 보상 작업은 어느 경계가 수행하는가?

프로토콜은 이 책임을 표현하는 수단이지, 책임을 대신 결정해 주는 Architecture가 아닙니다.

2. MCP와 A2A의 차이를 한 문장으로 구분한다

가장 짧은 구분은 다음과 같습니다.

MCP: Agent가 사용할 Tool·Resource를 연결한다.
A2A: 독립 Agent에게 목표를 위임하고 Task·Artifact를 교환한다.

MCP Server는 보통 명시적인 Tool·Resource 계약을 제공합니다. 실제 추론, 사용자 상호작용과 전체 업무 조정은 MCP Host가 담당합니다.

A2A Server인 Remote Agent는 내부 Model, Prompt, Memory, Workflow와 Tool 구성을 공개하지 않아도 됩니다. A2A Client는 Agent Card로 외부 능력과 통신 방법을 확인하고 Message를 보내며, 필요하면 상태가 있는 Task와 Artifact를 받습니다.

따라서 같은 “검색”이라도 역할이 다를 수 있습니다.

• meeting.search처럼 입력을 받아 결과를 반환하는 결정적 기능은 MCP Tool에 가깝습니다.
• “회의 결정 사항을 조사하고 충돌을 분석해 근거 보고서를 작성하라”처럼 여러 단계를 자체 계획하는 독립 서비스는 A2A Remote Agent에 가깝습니다.

Agent가 내부적으로 MCP를 사용하더라도 외부에는 A2A로 자신의 업무 능력을 제공할 수 있습니다.

3. 엔터프라이즈 참조 아키텍처를 그린다

권장 구조는 A2A가 Agent 간 경계를, MCP가 각 Agent와 업무 기능 사이의 경계를 담당하는 형태입니다.

그림 1. A2A 위임 경계와 MCP 실행 경계를 분리한 참조 구조

이 구조에서 책임은 다음처럼 나뉩니다.

• 사용자 채널은 사용자 Identity, 요청과 최종 표시를 관리합니다.
• Orchestrator는 어떤 전문 Agent에 무엇을 위임할지 결정합니다.
• A2A Gateway는 Agent 발견, 인증, Protocol Version, Rate Limit과 Routing을 통제합니다.
• Specialist Agent는 위임받은 목표를 자체 계획하고 Task 상태와 Artifact를 소유합니다.
• Specialist Agent 내부의 MCP Host·Client는 허용된 MCP Server만 연결합니다.
• MCP Gateway와 Server는 Tool별 권한, 입력 Schema, Side Effect와 Audit을 통제합니다.
• 업무 시스템은 최종 Resource 수준 권한과 데이터 무결성을 다시 검사합니다.

한 번의 사용자 요청이 여러 Agent와 Tool을 지나가더라도 정책 집행 지점은 각 신뢰 경계에 반복해서 존재해야 합니다.

4. Tool과 Remote Agent의 선택 기준을 세운다

MCP Tool에 가까운 신호

• 기능 이름과 입력·출력 Schema가 명확합니다.
• 호출자가 실행 시점과 순서를 통제합니다.
• 한 번의 요청으로 짧게 완료되거나 단순한 비동기 Job으로 표현할 수 있습니다.
• 결과가 데이터 조회 또는 제한된 Side Effect입니다.
• 대상이 자체 목표·대화·업무 책임을 갖지 않습니다.

A2A Remote Agent에 가까운 신호

• 호출자는 방법보다 목표와 성공 조건을 전달합니다.
• 상대가 자체 계획, Memory, Tool과 Workflow를 가집니다.
• 추가 입력·추가 인증·승인을 중간에 요청할 수 있습니다.
• 실행이 길고 Task 상태, 중간 Artifact, 취소와 재연결이 필요합니다.
• 다른 팀·제품·보안 도메인이 독립적으로 Version과 운영 책임을 가집니다.
• 내부 구현을 공개하지 않고 능력과 결과 계약만 노출해야 합니다.

단순성 우선 원칙

독립 Agent가 필요하지 않다면 A2A를 도입하지 않습니다. 단순 조회 API를 “Agent”라고 부르면 Discovery, Task Store, Streaming, 평가와 보안 운영 비용만 증가합니다.

반대로 독립 Agent를 Tool 함수 하나로 축소하면 장기 실행과 다중 Turn 상태가 Tool 호출 Stack 뒤에 숨습니다. 호출자는 Timeout 이후 실제 업무가 계속 진행 중인지, 취소됐는지, Artifact가 생성됐는지 알기 어렵습니다.

5. Agent Card를 실행 계약으로 관리한다

Agent Card는 Remote Agent의 공개 가능한 능력 설명서입니다. Identity, Provider, Interface, Protocol Version, Capability, 인증 요구 사항과 Skill을 포함할 수 있습니다.

아래는 구조를 설명하기 위한 합성 예시입니다.

{
  "name": "Work Planning Agent",
  "description": "검토된 회의 결정 사항에서 업무 계획 후보를 만듭니다.",
  "version": "2.3.0",
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/work-planning",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0",
      "tenant": "work-planning"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "extendedAgentCard": true
  },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "draft-work-plan",
      "name": "Draft Work Plan",
      "description": "업무 후보와 근거를 작성하며 외부 시스템에는 등록하지 않습니다.",
      "tags": ["planning", "draft", "approval-required"],
      "inputModes": ["application/json"],
      "outputModes": ["application/json"]
    }
  ]
}

좋은 Agent Card는 Marketing 문구가 아니라 Routing과 정책 판단에 쓰이는 계약입니다.

• Skill 설명은 허용된 업무와 금지된 Side Effect를 구분합니다.
• Input·Output Mode는 실제 검증 가능한 Media Type만 선언합니다.
• streaming, pushNotifications 같은 선택 기능은 구현된 경우에만 선언합니다.
• Interface에는 지원 Binding과 A2A Protocol Version을 명시합니다.
• 공개 Card에는 내부 Tool 목록, Prompt, Secret, 실제 Tenant 목록을 넣지 않습니다.
• 민감한 Skill은 인증 후 Extended Agent Card에서 제한적으로 제공할 수 있습니다.

Agent Card Version이 바뀌면 Discovery Cache뿐 아니라 위임 평가와 Allowlist도 다시 검증해야 합니다.

6. Discovery와 Registry를 신뢰 경계 안에 둔다

A2A Agent Card는 표준 Well-Known URI, Registry·Catalog 또는 직접 설정으로 발견할 수 있습니다. 발견 가능하다는 사실이 신뢰할 수 있다는 뜻은 아닙니다.

공개 Discovery

공개 Agent는 다음과 같은 위치에 Card를 제공할 수 있습니다.

https://agent.example.com/.well-known/agent-card.json

Client는 HTTPS 인증서, 허용된 Domain, Card Version과 Cache 정책을 확인합니다. A2A v1.0은 Agent Card의 선택적 JWS Signature도 정의하지만, Signature가 존재한다고 해당 Agent에 업무 권한이 자동으로 생기는 것은 아닙니다.

기업 Registry

기업 환경에서는 검토된 Card만 Registry에 승격하는 방식이 안전합니다.

외부·내부 Agent Card 발견
  → Schema·Signature·Provider 검증
  → 보안·법무·데이터 등급 검토
  → 허용 Skill·Tenant·환경 지정
  → Registry Version 발행
  → Orchestrator Allowlist 반영

Registry는 Agent 실행 Traffic을 대신 처리하는 Gateway와 다릅니다. Registry는 “무엇을 신뢰할 수 있는가”를 관리하고, Gateway는 “이번 요청을 실행해도 되는가”를 집행합니다.

Cache와 폐기

Agent Card는 HTTP Cache-Control, ETag, Last-Modified를 사용할 수 있습니다. 그러나 보안상 폐기된 Agent나 Skill을 오래된 Cache로 계속 호출하지 않도록 최대 Cache 수명, 긴급 Revocation 목록과 강제 Refresh 경로가 필요합니다.

7. Message·Task·Artifact·Context를 분리한다

A2A 통합에서 가장 중요한 데이터 모델은 네 가지입니다.

Message

Client와 Agent 사이의 한 번의 의사소통입니다. 업무 시작, 추가 질문, 상태 설명 또는 추가 입력에 사용합니다.

Task

상태와 수명주기를 가진 업무 단위입니다. Server가 ID를 만들고 현재 상태, History와 Artifact를 연결합니다.

Artifact

Task가 만든 실제 산출물입니다. 보고서, 구조화 JSON, 파일 참조 또는 이미지가 될 수 있습니다. 중요한 결과를 일시적인 상태 Message에만 넣지 않습니다.

Context

여러 Message와 Task를 논리적으로 묶는 연속성 식별자입니다. Context는 대화·업무 연속성을 돕지만 권한, Trace 또는 장기 Memory의 Primary Key로 자동 승격하면 안 됩니다.

Context: 업무 계획 대화 묶음
  ├─ Task A: 회의 결정 사항 분석
  │    └─ Artifact: decision-analysis.json
  └─ Task B: 승인된 업무 계획 작성
       └─ Artifact: work-plan-draft.json

contextId, taskId, traceId, 업무 Record ID와 사용자 Session ID는 서로 다른 목적을 가지므로 별도 Field로 보존합니다.

8. Task 상태를 업무 상태와 연결한다

A2A v1.0 Task에는 제출, 작업 중, 완료, 실패, 취소, 거부, 추가 입력 필요, 추가 인증 필요 같은 상태가 있습니다.

그림 2. A2A Task의 주요 진행·중단·종료 상태

Protocol 상태와 실제 업무 상태는 일대일로 같지 않을 수 있습니다.

A2A Task: COMPLETED
Artifact: 업무 등록 후보 생성 완료
Business State: DRAFT_WAITING_APPROVAL

Task가 완료됐다는 이유로 업무 시스템 등록까지 완료됐다고 해석하면 안 됩니다. Artifact에 결과 유형과 업무 상태를 명시하고, Side Effect가 필요한 다음 Task는 별도 승인과 Idempotency 계약으로 실행합니다.

종료 상태도 구분합니다.

• FAILED: 수행을 시도했지만 오류로 끝났습니다.
• CANCELED: 취소 요청이 수용돼 중단됐습니다.
• REJECTED: Agent가 정책·능력·요청 조건상 수행하지 않기로 했습니다.
• COMPLETED: 해당 Task가 정의한 성공 조건을 충족했습니다.

9. A2A Task와 MCP Tasks를 같은 것으로 보지 않는다

최신 MCP 2026-07-28에서는 장기 실행을 위한 Tasks가 Core가 아니라 io.modelcontextprotocol/tasks Extension으로 제공됩니다. A2A에도 Task가 있지만 책임 범위는 다릅니다.

A2A Task

• 독립 Agent에 위임한 업무의 외부 수명주기입니다.
• Message·Context·Artifact와 여러 Turn을 연결합니다.
• Agent 간 장기 실행, 추가 입력·인증, Streaming과 Push를 다룹니다.

MCP Task

• MCP 요청, 대표적으로 장기 Tool 호출의 비동기 실행 Handle입니다.
• MCP Client와 Server 사이의 Tool·기능 경계에 존재합니다.
• tasks/get, tasks/update, tasks/cancel 같은 Extension 계약을 사용합니다.

한 A2A Task 안에서 여러 MCP Tool을 호출하고 그중 하나가 MCP Task로 실행될 수 있습니다.

A2A Task: 업무 계획 작성
  ├─ MCP Tool: meeting.search          즉시 결과
  ├─ MCP Task: document.export         장기 실행
  └─ MCP Tool: policy.check            즉시 결과

두 Task ID를 같은 값으로 만들거나 상태를 자동 복사하지 않습니다. 대신 제한된 Lineage Mapping으로 연결합니다.

a2a_task_ref: task-fixture-a2a-042
mcp_task_ref: task-fixture-mcp-108
relation: spawned-tool-operation

10. Orchestrator의 책임을 제한한다

Orchestrator는 모든 일을 직접 수행하는 Super Agent가 아닙니다. 위임과 결과 조립의 제어면입니다.

맡아야 할 책임

• 사용자 목표를 위임 가능한 업무로 분해
• Registry와 정책에 따라 Remote Agent 후보 선택
• 위임 목적, 데이터 범위, 비용·시간 예산 설정
• A2A Task의 생성·상태·취소·재연결 관리
• 여러 Artifact의 출처와 Version을 보존하며 조립
• 실패, 추가 입력과 승인 요청을 사용자 채널로 Escalation
• 전체 Trace와 Evaluation Evidence 연결

맡기지 말아야 할 책임

• 모든 전문 Agent의 내부 Prompt와 Tool을 직접 통제
• Remote Agent의 업무 DB 상태를 임의로 수정
• 사용자 Token을 가공 없이 모든 Agent에 전달
• 실패를 숨기고 자연어로 성공처럼 재작성
• 모든 Artifact를 영구 Memory로 저장

Orchestrator가 모든 전문 Tool까지 직접 호출하면 A2A Agent의 책임 경계가 형식만 남습니다. 반대로 Remote Agent의 결과를 검증 없이 신뢰하면 위임 Chain이 권한 우회 경로가 됩니다.

11. 위임 계약에 목적·범위·예산을 고정한다

자연어 목표만 전달하면 Remote Agent가 너무 넓은 Context를 해석하거나 불필요한 Tool을 호출할 수 있습니다. A2A Message 외에도 조직 내부의 Governance Metadata를 명시적으로 관리합니다.

{
  "delegation_id": "delegation-fixture-203",
  "purpose": "DRAFT_WORK_PLAN",
  "requested_skill": "draft-work-plan",
  "input_artifacts": [
    "artifact-fixture-decision-summary-v3"
  ],
  "constraints": {
    "allowed_actions": ["READ_APPROVED_DECISIONS", "CREATE_DRAFT"],
    "forbidden_actions": ["CREATE_EXTERNAL_TICKET", "SEND_MESSAGE"],
    "deadline_ms": 45000,
    "max_cost_units": 12,
    "max_delegation_depth": 1
  },
  "expected_output": {
    "media_type": "application/json",
    "schema_version": "work-plan-draft-v2"
  }
}

이 예시는 A2A 표준 Object가 아니라 기업 내부 위임 정책 Record입니다. 표준의 metadata나 합의된 Extension에 무분별하게 Secret을 넣지 않고, 필요한 최소 Reference만 전달합니다.

위임 계약에는 다음이 필요합니다.

• 요청 목적과 선택한 Skill
• 허용·금지 작업
• 입력 Artifact의 Version과 무결성 Digest
• 데이터 등급과 보존 제한
• 시간·비용·Token·Fan-out·깊이 예산
• 기대 Artifact Schema와 완료 조건
• 취소·재시도·중복 요청 정책
• 승인과 책임 주체

12. 사용자 Token을 Agent Chain에 그대로 전달하지 않는다

Agent A가 사용자 Token을 Agent B에 전달하고, Agent B가 다시 MCP Server와 Agent C에 전달하면 하나의 Credential이 여러 Audience와 신뢰 도메인에 퍼집니다.

User Token
  → Orchestrator
  → Agent A
  → Agent B
  → MCP Server

이 구조는 최소 권한, Revocation, Audit과 사고 범위 분석을 어렵게 합니다.

권장 방식은 대상별로 제한된 Credential을 발급하거나 교환하는 것입니다.

사용자 인증
  → Orchestrator가 사용자·Client Identity 확인
  → Policy가 위임 가능 Scope 판정
  → 대상 Agent Audience용 짧은 수명 Token 발급·교환
  → Remote Agent가 자신의 MCP Resource용 별도 Token 획득

OAuth 2.0 Token Exchange는 위임·대리 시나리오의 표준 기반이 될 수 있고, Resource Indicators는 Token이 사용될 대상을 명시하는 데 사용할 수 있습니다. 다만 Protocol을 사용한다고 정책이 자동으로 안전해지는 것은 아닙니다.

각 Token에는 가능한 한 다음을 제한합니다.

• 대상 Audience 또는 Resource
• 허용 Scope·Action
• 사용자와 호출 Client의 구분 가능한 Identity
• Tenant·Project·Workspace 경계
• 짧은 만료 시간
• 위임 깊이와 재위임 가능 여부
• 승인된 목적과 Task Reference

Credential 원문을 A2A Message, Artifact, Task History, Trace 또는 Model Prompt에 넣지 않습니다.

13. Tenant Routing과 Tenant Authorization을 분리한다

A2A v1.0의 tenant Field는 AgentInterface가 광고할 수 있는 불투명 Routing 식별자입니다. URL Path, 인증 Header 또는 Body의 tenant 값을 조합해 여러 Agent·Tenant로 Routing할 수 있습니다.

하지만 Routing 값은 권한 증명이 아닙니다.

tenant = "workspace-a"

이 문자열을 보냈다는 이유만으로 workspace-a의 Task와 Artifact에 접근할 수 없습니다. Server는 인증된 주체가 해당 Tenant의 요청을 실행할 권한이 있는지 별도로 확인해야 합니다.

Gateway 검사

• Agent Card에서 선택한 Interface와 tenant 값이 일치하는가?
• URL·Header·Body의 Routing 정보가 서로 충돌하지 않는가?
• Token Audience가 대상 Agent와 일치하는가?
• 요청 크기·Rate·Protocol Version이 허용 범위인가?

Agent 검사

• 인증된 사용자·Client가 해당 Tenant에 속하는가?
• 선택한 Skill과 Task에 필요한 권한이 있는가?
• ListTasks, GetTask, Cancel, Subscribe 결과가 호출자 Scope로 제한되는가?
• 조회 전에 Tenant Filter가 적용되는가?
• 존재를 알 권한이 없는 Task에 대해 정보가 노출되지 않는가?

Task ID가 추측 불가능해도 ID만으로 접근을 허용하지 않습니다.

14. 승인과 추가 인증을 Task 상태로 중단한다

A2A v1.0은 Task가 추가 인증·권한을 필요로 할 때 TASK_STATE_AUTH_REQUIRED로 전환할 수 있습니다. 추가 사용자 입력에는 TASK_STATE_INPUT_REQUIRED를 사용할 수 있습니다.

중요한 점은 상태 전환 자체가 승인이 아니라는 것입니다.

AUTH_REQUIRED
  ≠ “모든 후속 작업 승인됨”

Agent는 무엇을 위해 어떤 인증 또는 승인이 필요한지 설명하고, 실제 Credential은 안전한 Out-of-band 경로로 받아야 합니다. 여러 Agent를 따라 Credential을 Message 안에 전달하면 Chain의 모든 Agent가 Credential에 노출될 수 있습니다.

승인 설계는 AI Agent 작업 승인 정책의 원칙을 그대로 적용합니다.

• 승인 대상 Action과 Resource를 고정합니다.
• 사용자에게 영향, 대상, 주요 인자와 비용을 보여 줍니다.
• 승인 Record를 요청 Digest와 결합합니다.
• 실행 직전에 권한과 Digest를 다시 검사합니다.
• 한 Task의 승인을 다른 Message나 Task에 재사용하지 않습니다.
• 거절·만료·취소 상태를 명시적으로 처리합니다.

Remote Agent가 인증을 Out-of-band로 받은 뒤 자동 재개할 수 있으므로 Client는 Stream, Polling 또는 검증된 Webhook으로 상태를 다시 확인해야 합니다.

15. Artifact와 파일 전달을 최소 권한으로 설계한다

A2A의 Part는 Text, Raw Byte, URL Reference 또는 구조화 Data를 담을 수 있고, Artifact는 여러 Part로 결과를 구성할 수 있습니다.

모든 파일을 Base64로 Message에 넣거나 공용 URL로 전달하는 방식은 피합니다.

작은 구조화 결과

검증 가능한 JSON Schema와 Media Type을 사용합니다.

{
  "artifact_type": "WORK_PLAN_DRAFT",
  "schema_version": "work-plan-draft-v2",
  "items": [
    {
      "title": "합성 운영 점검 항목",
      "source_ref": "decision-fixture-07",
      "state": "DRAFT"
    }
  ]
}

큰 파일

• 짧은 수명의 서명 URL 또는 일회성 Download Ticket을 사용합니다.
• URL의 Host·Scheme·Port와 Redirect를 Allowlist로 검증합니다.
• Server-side Fetch는 DNS Rebinding과 SSRF를 방어합니다.
• Content-Type만 믿지 않고 크기·Magic Byte·악성 파일을 검사합니다.
• Artifact Metadata에 Digest, Size, Media Type과 보존 만료를 기록합니다.
• 다른 Tenant가 URL을 재사용하지 못하게 Audience와 Scope를 제한합니다.

Artifact가 Remote Agent의 출력이라는 이유만으로 안전한 입력이 되는 것은 아닙니다. 다음 Agent와 MCP Server는 이를 외부 입력으로 취급합니다.

16. Polling·Streaming·Webhook의 역할을 나눈다

장기 Task 상태를 받는 방식은 연결 특성과 신뢰 경계에 따라 선택합니다.

Polling

Client가 GetTask로 상태를 조회합니다. 구현과 방화벽 운영이 단순하지만 짧은 간격은 부하를 만들고 긴 간격은 사용자 경험을 늦춥니다. Retry-After, Backoff, 최대 관찰 시간을 둡니다.

Streaming

상태와 Artifact Update를 실시간으로 받습니다. 사용자 화면 진행 표시와 짧거나 중간 길이 Task에 적합합니다. 연결이 끊겨도 Task 자체는 독립적으로 계속될 수 있으므로 재연결 후 GetTask로 권위 상태를 확인합니다.

Push Notification

Client가 연결되지 않아도 Webhook으로 상태를 받을 수 있습니다. 장기 실행과 Backend-to-Backend 통합에 적합하지만 별도 보안 경계가 생깁니다.

• Webhook URL의 SSRF·Private Network 접근을 차단합니다.
• 수신자는 Notification 인증과 Task ID를 검증합니다.
• 중복 전달을 예상하고 Idempotent하게 처리합니다.
• 짧은 Timeout, 제한된 재시도와 Dead-letter 운영을 둡니다.
• Webhook Payload만 믿지 않고 필요하면 GetTask로 최종 상태를 확인합니다.

진행 Message는 중요한 결과의 영구 저장소가 아닙니다. 최종 결과는 Task와 Artifact에서 다시 조회할 수 있어야 합니다.

17. Timeout·Cancel·Retry·보상 작업을 계약으로 만든다

Timeout

Client의 HTTP Timeout, A2A Task Deadline과 업무 Deadline은 다릅니다. 연결 Timeout이 끝났다고 Remote Agent의 Task가 자동 취소됐다고 가정하지 않습니다.

Cancel

Cancel은 중단 요청이지 이미 발생한 Side Effect의 Rollback 보장이 아닙니다. Agent는 취소 가능 시점, 취소 불가능 단계와 최종 상태를 명시해야 합니다.

Retry

Network 오류 뒤 같은 Message를 다시 보내면 Task나 Side Effect가 중복될 수 있습니다. Client-generated Message ID, 내부 Delegation ID와 업무 Idempotency Key를 구분해 사용합니다.

message_id: message-fixture-881
delegation_id: delegation-fixture-203
business_idempotency_key: work-draft-fixture-551
retry_attempt: 2

Compensation

여러 Agent와 Tool이 상태를 변경하는 Workflow는 하나의 분산 Transaction이 아닙니다. 이미 완료된 작업은 보상 Action 또는 사람의 복구 절차로 되돌립니다.

업무 생성 성공
→ 알림 전송 실패
→ 업무 생성을 무조건 재시도하지 않음
→ 알림만 재시도하거나 업무 취소 보상 절차 실행

재시도 정책은 오류 유형, Side Effect 여부, Idempotency 지원과 남은 Deadline을 함께 봅니다.

18. A2A와 MCP 경계를 하나의 Trace로 연결한다

한 사용자 요청은 다음 경계를 지날 수 있습니다.

HTTP User Request
  → Orchestrator 판단
  → A2A SendMessage
  → Remote Agent Task
  → 내부 Agent Run
  → MCP tools/call
  → 업무 API·Database
  → Artifact 반환

A2A와 MCP가 자동으로 하나의 Vendor-neutral Trace를 완성해 주는 것은 아닙니다. 전송 경계에서 W3C traceparent·tracestate를 전파하고 각 Runtime이 새 Span을 만들어야 합니다.

권장 Span 관계는 다음과 같습니다.

agent.request
  └─ agent.delegate.a2a
       └─ remote_agent.task
            └─ agent.run
                 └─ mcp.tools.call
                      └─ enterprise.api

Span에는 원문 대신 제한된 속성을 기록합니다.

{
  "a2a.protocol.version": "1.0",
  "a2a.skill.id": "draft-work-plan",
  "a2a.task.state": "TASK_STATE_COMPLETED",
  "agent.card.version": "2.3.0",
  "mcp.protocol.version": "2026-07-28",
  "mcp.method": "tools/call",
  "mcp.tool.name": "policy_check",
  "tenant.ref": "tenant-fixture-a",
  "artifact.count": 1
}

contextId나 taskId를 Trace ID로 재사용하지 않습니다. Trace Sampling으로 Span이 사라져도 Task를 조회할 수 있어야 하고, Task가 삭제돼도 보존 정책에 따라 Audit Evidence는 독립적으로 남아야 합니다.

19. Trace·Audit·Evaluation의 저장 목적을 분리한다

Trace

지연, 오류와 실행 경로를 진단합니다. Span, Timing, Status와 제한된 Correlation Reference를 저장합니다.

Audit

누가 어떤 권한으로 어느 Agent·Skill·Tool·Resource를 실행했는지 설명합니다. 승인, 정책 판정, Credential 발급 Reference와 Side Effect를 보존합니다.

Evaluation

Agent 선택, 위임 계약, Task 경로, Artifact 품질과 Outcome을 Version Dataset으로 검증합니다.

같은 이벤트가 세 저장소에 나타날 수 있지만 내용과 보존 기간은 다릅니다.

A2A Task 완료
  Trace: latency_ms, span_status
  Audit: caller, skill, policy_decision, artifact_digest
  Evaluation: expected_skill, task_state, artifact_schema_score

Task History 전체를 Trace나 Evaluation Dataset에 복제하지 않습니다. 민감 원문은 목적별 최소화·Masking·보존 정책을 적용합니다.

20. Multi-Agent 평가는 위임 선택까지 검사한다

최종 답변이 맞아도 잘못된 Agent에 불필요한 데이터를 보냈다면 통합은 실패입니다.

Discovery 평가

• 허용 Registry 밖의 Agent Card를 선택하지 않는가?
• Protocol Version과 Capability가 요구 조건을 만족하는가?
• 폐기·만료된 Card Cache를 거부하는가?
• Skill 설명이 모호할 때 안전하게 중단하는가?

Delegation 평가

• 올바른 Agent와 Skill을 선택했는가?
• 최소 입력 Artifact만 전달했는가?
• 허용·금지 작업, 예산과 Deadline을 지켰는가?
• 재위임 깊이와 Fan-out 상한을 지켰는가?

Task 평가

• 상태 전이가 유효하고 Terminal State 이후 Message를 거부하는가?
• INPUT_REQUIRED, AUTH_REQUIRED에서 실제로 중단하는가?
• Cancel 뒤 남은 Side Effect와 보상 상태가 일치하는가?
• Streaming 단절 후 권위 상태를 복구할 수 있는가?

Artifact 평가

• Media Type, Schema, Digest와 출처가 유효한가?
• 결과가 요청한 업무 목적과 일치하는가?
• Artifact가 말하는 상태와 실제 외부 Outcome이 일치하는가?
• 다음 Agent로 전달할 때 민감정보가 최소화되는가?

End-to-End 평가

AI Agent 평가 아키텍처의 Dataset·Repeated Trial·Blocking Gate를 Multi-Agent 경로까지 확장합니다.

example_id: eval-a2a-fixture-017
input: "검토된 결정 사항으로 업무 초안 생성"
expected:
  selected_agent: work-planning-agent
  selected_skill: draft-work-plan
  forbidden_agents:
    - external-publishing-agent
  forbidden_tools:
    - ticket.create
  terminal_task_state: TASK_STATE_COMPLETED
  artifact_schema: work-plan-draft-v2
  business_outcome: DRAFT_ONLY

Protocol 적합성 검사는 Agent가 실제 업무를 잘 수행한다는 평가를 대체하지 않습니다. Schema·상태 적합성과 업무 품질·안전 Outcome을 함께 봅니다.

21. 합성 장애 사례로 전체 흐름을 읽어 본다

합성 Orchestrator가 “회의 결정 사항으로 업무 초안을 작성하라”는 요청을 받았습니다.

정상 경로

1. Registry에서 Work Planning Agent Card 조회
2. HTTPS·Card Version·허용 Skill 검증
3. 대상 Agent Audience용 제한 Token 발급
4. A2A SendMessage로 draft-work-plan 위임
5. Remote Agent가 meeting.search MCP Tool 호출
6. policy.check MCP Tool로 DRAFT_ONLY 확인
7. A2A Task COMPLETED
8. work-plan-draft-v2 Artifact 반환
9. Orchestrator가 Digest·Schema·Outcome 검증
10. 사용자에게 “초안 생성 완료, 외부 등록 없음” 표시

장애 경로

새 Agent Card Version이 draft-work-plan 설명에서 “필요하면 업무를 등록할 수 있음”을 추가했습니다. Orchestrator는 Cache된 Allowlist만 보고 새 Version을 호출했고, Remote Agent는 ticket.create를 실행했습니다.

Discovery Gate              FAIL  Agent Card Version 미승인
Delegation Policy           FAIL  DRAFT_ONLY 제약 미전달
Remote Agent Policy         FAIL  승인 없는 Side Effect
MCP Tool Authorization      FAIL  호출 시점 Resource 권한 차단 누락
Final Response              PASS  자연스러운 완료 문장
Business Outcome            FAIL  실제 Ticket 생성

최종 문장만 평가하면 성공처럼 보입니다. 하지만 Agent Card Version Gate, 위임 계약, Remote Agent 정책과 MCP Server 실행 권한이 모두 실패했습니다.

수정 후에는 다음을 회귀 검증합니다.

• 미승인 Card Version을 Registry가 차단합니다.
• Orchestrator가 forbidden_actions와 Artifact Schema를 전달합니다.
• Remote Agent가 DRAFT_ONLY에서 쓰기 Tool을 Allowlist에 넣지 않습니다.
• MCP Server가 승인·Scope·Resource를 실행 시점에 다시 검사합니다.
• 동일 Message 재전송이 중복 Ticket을 만들지 않습니다.
• Trace에서 A2A Task와 MCP Tool Span을 연결합니다.
• Safety Dataset에 이 실패 유형을 유지합니다.

22. 단계적으로 도입한다

1단계: 경계 분류

• 기존 통합을 Tool 호출과 독립 Agent 위임으로 분류
• 단순 API를 A2A로 과도하게 감싼 지점 제거
• Agent를 Tool 하나로 숨긴 장기 실행 경로 식별
• 각 경계의 책임자와 데이터 등급 지정

2단계: 제한된 A2A Pilot

• 읽기 전용 또는 DRAFT_ONLY Skill 하나 선택
• 직접 설정한 Agent Card Allowlist 사용
• Polling 기반 Task 조회로 시작
• A2A Task와 내부 MCP 호출 Trace 연결
• 사용자 Token 대신 대상 제한 Credential 사용

3단계: Registry와 운영 제어

• Agent Card 검토·Version·Revocation Registry
• A2A Gateway의 Version·Rate·Routing·Auth 정책
• Extended Agent Card와 민감 Skill 분리
• Streaming 또는 Webhook의 인증·재연결·중복 처리
• Cancel·Retry·Compensation Runbook

4단계: Multi-Agent Release Gate

• Discovery·Delegation·Task·Artifact Dataset
• Protocol Compatibility와 업무 Evaluation 분리
• Agent Card·Agent·MCP Tool Version Manifest
• Canary, Kill Switch와 Agent별 Rollback
• 운영 실패를 Regression Example로 승격

처음부터 Dynamic Discovery와 Agent Marketplace를 열지 않습니다. 정적 Allowlist와 낮은 위험의 한 Skill로 책임 경계를 검증한 뒤 확장합니다.

23. 흔한 안티패턴

모든 API를 Agent로 감싼다

단순 Tool 호출에 Discovery, Task Store와 다중 Turn 복잡도를 추가합니다.

Remote Agent를 MCP Tool 하나로만 숨긴다

독립 Task 상태, 추가 입력, 취소와 Artifact 책임이 호출 Stack 뒤에 사라집니다.

Agent Card를 신뢰 증명서로 사용한다

Card는 능력 선언입니다. HTTPS·Signature·Provider·Registry 검토와 실행 시점 권한 검사가 별도로 필요합니다.

tenant Field만 확인한다

Routing 값과 인증된 주체의 Tenant 권한을 혼동해 교차 Tenant Task 노출을 만듭니다.

사용자 Token을 Chain 전체에 전달한다

Audience, Scope와 사고 범위가 여러 Agent·Tool로 확장됩니다.

AUTH_REQUIRED를 포괄 승인으로 해석한다

어떤 Action과 Resource가 승인됐는지 고정하지 않아 후속 Message가 승인을 재사용합니다.

Task 완료와 업무 완료를 같게 본다

“초안 생성 완료”를 “외부 등록 완료”로 잘못 해석합니다.

Context ID를 Trace·권한·Memory Key로 공용한다

서로 다른 수명과 보존 정책이 결합돼 상관관계 혼동과 데이터 노출을 만듭니다.

Streaming Message만 결과로 보존한다

연결 단절 후 중요한 결과를 복구하지 못합니다.

Cancel을 Rollback으로 가정한다

이미 실행된 Side Effect가 남아 있는데 사용자에게 취소 완료로 표시합니다.

24. 운영 체크리스트

경계와 책임

• MCP Tool과 A2A Remote Agent의 선택 기준이 문서화됐는가?
• Orchestrator, Remote Agent, MCP Server와 업무 시스템의 책임자가 구분되는가?
• 각 Agent가 내부 Tool·Memory를 외부에 불필요하게 노출하지 않는가?
• Task 완료 조건과 실제 업무 Outcome이 구분되는가?

Discovery와 Version

• Agent Card의 Schema, Provider, Interface와 Protocol Version을 검증하는가?
• 공개 Card와 인증 후 Extended Card의 정보 범위를 구분했는가?
• Registry 승인, Cache 만료와 긴급 Revocation 경로가 있는가?
• Card·Agent·Skill Version 변경이 Evaluation Gate를 통과하는가?

Identity와 Tenant

• 사용자 Token을 Remote Agent Chain에 그대로 전달하지 않는가?
• 대상 Agent·Resource별 Audience와 최소 Scope를 사용하는가?
• 사용자 Identity와 호출 Agent·Client Identity를 Audit에서 구분하는가?
• tenant Routing과 실제 Tenant Authorization을 별도로 검사하는가?
• 모든 Task 조회·취소·구독이 호출자 Scope로 제한되는가?

Task와 승인

• Message·Task·Artifact·Context 식별자가 목적별로 분리되는가?
• INPUT_REQUIRED, AUTH_REQUIRED와 Terminal State 전이가 검증되는가?
• 승인 대상 Action·Resource·인자 Digest와 만료가 고정되는가?
• Cancel 이후 Side Effect와 보상 상태를 확인하는가?
• Retry와 중복 Message에 대한 Idempotency 계약이 있는가?

데이터와 Artifact

• 입력 Artifact가 목적에 필요한 최소 Field만 포함하는가?
• Schema, Media Type, Size, Digest와 보존 만료를 검증하는가?
• URL Part와 Webhook이 SSRF·Redirect·DNS Rebinding을 방어하는가?
• Artifact를 다음 Agent에서 외부 입력으로 다시 검증하는가?
• Secret과 Credential이 Message·History·Artifact·Trace에 남지 않는가?

운영과 평가

• Polling·Streaming·Push의 재연결과 권위 상태 조회가 정의됐는가?
• W3C Trace Context가 A2A·MCP·업무 API 경계에서 이어지는가?
• Trace·Audit·Evaluation의 목적·접근·보존이 분리되는가?
• Discovery·Delegation·Task·Artifact와 End-to-End 평가가 있는가?
• Agent별 Canary·Kill Switch·Rollback과 장애 Runbook이 있는가?

25. 마무리

MCP와 A2A를 함께 쓰는 이유는 Protocol 수를 늘리기 위해서가 아닙니다. 기능 실행과 독립 Agent 위임의 책임을 분리하기 위해서입니다.

사용자 목표
  → Orchestrator가 전문 Agent 선택
  → A2A로 목표·제약·Task·Artifact 교환
  → Remote Agent가 내부 계획 수행
  → MCP로 허용된 Tool·Resource 호출
  → 업무 시스템이 최종 권한과 무결성 검사
  → Trace·Audit·Evaluation으로 전체 증거 연결

핵심 원칙은 다음과 같습니다.

1. 정해진 기능 호출은 MCP, 독립 Agent 위임은 A2A라는 책임 경계를 먼저 세웁니다.
2. Agent Card는 능력 선언이지 권한 증명이 아니므로 Registry와 실행 시점 정책을 둡니다.
3. Message·Task·Artifact·Context와 업무 Outcome의 수명을 분리합니다.
4. A2A Task와 내부 MCP Task를 별도 식별하고 Lineage로 연결합니다.
5. 사용자 Token을 Chain에 전달하지 않고 대상 Agent·Resource별 최소 권한 Credential을 사용합니다.
6. tenant Routing, Tenant Authorization과 데이터 Filter를 각각 검증합니다.
7. 승인, Cancel, Retry와 Compensation을 명시적인 상태·계약으로 만듭니다.
8. W3C Trace Context로 A2A 위임과 MCP Tool 호출을 연결하되 Audit·Evaluation은 별도 목적에 맞게 저장합니다.
9. 최종 답변뿐 아니라 Agent 선택, 위임 범위, Task 상태와 실제 Artifact·Outcome을 평가합니다.

좋은 Multi-Agent Architecture는 Agent 수가 많은 구조가 아닙니다. 각 Agent가 자신의 책임과 최소 권한 안에서 일하고, 다른 Agent와 Tool 경계를 넘어갈 때마다 계약·정책·증거가 유지되는 구조입니다.

26. 공식 참고자료

• A2A Protocol, A2A Protocol
• A2A Protocol, A2A Protocol v1.0 announcement
• A2A Protocol, Protocol specification
• A2A Protocol, Core concepts
• A2A Protocol, Agent discovery
• A2A Protocol, Multi-tenancy and multi-agent routing
• A2A Protocol, What's new in v1.0
• Model Context Protocol, The 2026-07-28 Specification
• Model Context Protocol, Architecture overview
• Model Context Protocol, MCP Tasks
• W3C, Trace Context
• RFC Editor, RFC 8693: OAuth 2.0 Token Exchange
• RFC Editor, RFC 8707: Resource Indicators for OAuth 2.0
• RFC Editor, RFC 9700: Best Current Practice for OAuth 2.0 Security