#MCP와 A2A는 도대체 어떻게 선택하는가

MCP는 「모델이 도구와 리소스에 연결하는」 쪽에 가깝고, A2A는 「Agent 사이의 발견·위임·인계」 쪽에 가깝다. 둘은 대체 관계가 아니라 중첩 관계다.

#장면

• 고객센터 Agent가 주문 도구를 호출하고(MCP 측면), 법무 Agent로 전환한다(A2A 측면).
• 이 장면을 둘러싸고 네 가지를 명확히 해야 한다:
  1. 데이터는 어디서 오는가
  2. 상태는 어떻게 확인하는가
  3. 실패는 어떻게 처리하는가
  4. 최종 결과는 어떻게 검증되는가
• 유의: 성공한 것처럼 보이는 많은 동작들이 결국 상태, 감사, 재생으로 돌아가 확인되어야 한다. 그렇지 않으면 「결과만 알 뿐 과정을 증명할 방법이 없다」.

#MCP 경계

• 주문 조회 / 지식베이스 읽기 / 사용자 자료 가져오기 — 이것들은 도구와 리소스 접속 문제에 가까우므로 MCP로 표준 연결하는 것이 적합하다
• 상용 후 반드시 기록해야 할 4항 (없으면 프로토콜 계층에서 문제가 생겼을 때 어느 쪽이 약속을 어겼는지 판단하기 어렵다)
  • 요청자
  • 리소스 범위
  • 작업 상태
  • 에러 경로
• 위치: 이 단계가 시스템이 먼저 자리를 잡고 나서 최적화를 논할 수 있는지를 결정하는 경우가 많다

#A2A 경계

• 장면: 고객센터 Agent가 계약 분쟁을 처리하지 못함 → 작업 인계 → 법무 Agent가 인수해 처리
• 인계 시 반드시 세 가지를 동반해야 한다: 컨텍스트 / 권한 / 기대 결과
• 함정 회피 지침: 개념 하나만 답하지 말고 필드, 상태, 시간, 권한 같은 공학적 제약을 보충할 것. 그렇지 않으면 답이 데모 수준에 머문다

#선택 순서

• 대부분의 프로젝트는 먼저 도구 접속, 권한, 감사를 해결하고 나서 정말로 여러 Agent가 서로 통신해야 하는지 판단한다.
• 상용 시스템이 반드시 고려해야 할 이상 경로
  • 타임아웃
  • 충돌
  • 낡은 데이터
  • 사용자의 기준 변경
  • 외부 시스템 상태 변화
• 판단 기준: 가장 순조로운 한 경로만 덮어서는 안 된다. 이상 경로가 없는 방안은 기본적으로 시연용이지 상용에 적합하지 않다.

#운영 거버넌스

• 프로토콜 자체가 시스템을 거버넌스해주지는 않는다. 이는 당신이 어떻게 하는지뿐 아니라 그것이 잘못했음을 어떻게 발견하는지도 안다는 것을 보여준다
• 어떤 프로토콜이든 다음이 있어야 한다:
  • 신원
  • 권한
  • 로그
  • 취소
  • 오류 복구
• 실제 프로젝트에서 결국 문제가 되는 것은 「돌아가는가」가 아니라 「나쁜 상황에서 제때 멈추고, 제때 알리고, 제때 보완할 수 있는가」다
• 이 단계를 제대로 설계하지 않으면 앞을 아무리 예쁘게 만들어도 헛수고가 된다

#마무리 보충: 상용 전 그레이 리플레이

상용 전에 그레이 리플레이를 한 번 더 해서 경계 샘플이 우연히 통과한 것이 아니라 이 링크가 정말 안정적임을 확인하는 것이 좋다. 성공률만 보지 말고 실패 경로, 재생 결과, 회귀 관문을 함께 볼 것.

#핵심 통찰

1. 프로토콜은 「어떻게 연결하는가」만 해결하지 「연결해도 되는가」는 해결하지 않는다 — MCP/A2A는 연결과 상호작용의 형식만 규정하며, 권한·컨텍스트·감사 이 세 가지는 어떤 프로토콜도 대신 해주지 않는다. 이 말을 꺼내는 순간 개념 문제에서 공학 문제로 진입한다.
2. MCP와 A2A는 세로로 중첩되는 것이지 가로로 양자택일하는 것이 아니다 — MCP는 「모델↔도구/리소스」라는 세로축을, A2A는 「Agent↔Agent」라는 가로축을 관장한다. 「어떻게 고르나」를 물으면 올바른 자세는 먼저 계층을 나누고 프로토콜을 정하는 것이지 우열을 비교하는 것이 아니다. 한 줄 암기: MCP는 도구를 잇고, A2A는 동료를 잇는다.
3. 표준화될수록 신뢰 경계를 더 확실히 못 박아야 한다 — 표준화 접속은 접속 비용을 낮추는 동시에 「오접속」의 비용도 낮춘다. 매끄럽게 붙일수록 명시적인 신뢰 경계 문서가 필요하며, 그렇지 않으면 리스크가 접속 수에 비례해 확대된다.
4. 권한은 객체 생명주기를 따라 단순 상속시키면 안 된다 — 리소스, 도구, 작업, 샘플링 요청 네 종류의 객체는 생명주기가 각각 다르며, 상류 권한을 하류로 그대로 흘려보내는 것이 가장 흔한 월권의 원인이다.
5. 접속 계층의 오류는 하류에서 「세탁된다」 — MCP 접속 계층이 잘못된 데이터를 가져와도 Prompt 조립, 리랭크, 도구 호출이 줄곧 정상적으로 실행되어 최종 출력은 유창하지만 업무적으로는 극히 은밀하게 틀린다. 유창함은 정확성의 증거가 아니다.
6. 「돌아가는가」는 데모 기준이고, 「나쁜 상황에서 제때 멈추고/알리고/보완할 수 있는가」가 상용 기준이다 — 이 문서에서 가장 이식성 높은 판단 기준이며, 모든 Agent 시스템 리뷰에 적용된다.
7. 이상 경로 설계가 없는 방안 = 시연품 — 타임아웃, 충돌, 낡은 데이터, 사용자의 기준 변경, 외부 시스템 상태 변화 이 다섯 종류가 최소한의 이상 목록이다.
8. 답이 폐루프를 이뤄야 높은 점수를 받는다 — 설계 → 실행 → 모니터링 → 복기. 모니터링과 복기(평가, 알람, 재생)가 빠지면 반드시 추가 질문이 들어온다.

#엔지니어링 실전 Tips

• 감사 가능성 — 프로토콜 호출마다 4요소를 남길 것: 요청자 / 리소스 범위 / 작업 상태 / 에러 경로. 문제가 생겼을 때 어느 쪽이 약속을 어겼는지 위치를 특정할 수 있다
• 권한 모델 — 객체별로 각각 인가할 것(리소스, 도구, 작업, 샘플링 요청이 각자 독립). 객체 간 상속 금지
• 트러블슈팅 순서 — 결과가 틀리면 먼저 접속 계층의 전제를 의심하고, 그다음 Prompt / 리랭크 / 도구 호출을 의심하며, 모델은 마지막에 의심할 것
• A2A 메시지 본문 — 인계 메시지는 최소한 컨텍스트, 권한, 기대 결과 3단을 포함하고, 여기에 필드 / 상태 / 시간 3종의 메타 정보를 보충할 것
• 상용 관문 — 성공률 외에 실패 경로 재생 + 회귀 관문이 반드시 있어야 하며, 그레이 리플레이로 경계 샘플을 검증할 것
• 복잡도 통제 — 여러 Agent 간 통신은 후순위 옵션이지 기본 아키텍처가 아니다. 먼저 단일 Agent의 도구 접속, 권한, 감사를 탄탄히 할 것