AI·자동화 트렌드
MCP·ACP·AP2 차이 헷갈리는 AI 에이전트 표준, 도입 순서까지 한 방에 정리
MCP·ACP·AP2 차이와 도입 순서 — AI 에이전트 프로토콜, 기업은 무엇부터 대응해야 하나
MCP를 먼저 깔고, 에이전트 간 통신은 파일럿, AP2는 계약서로 대응하세요.
2024년 말에 "MCP 서버 구축"으로 품의를 올렸는데, 이듬해 봄엔 "A2A도 봐야 한다"는 말이 돌더니, 2025년 9월엔 결제팀에서 "AP2는 어떻게 되냐"는 메일이 왔습니다. 벤더 세 곳이 각각 다른 약자를 들고 와 "이게 표준입니다"라고 말하는 회의, 한 번쯤 앉아보셨을 거예요.
세 이름은 경쟁자가 아니라 서로 다른 층입니다. 이 구분을 놓치면 안 급한 걸 먼저 삽니다.
한눈 요약
- MCP — 에이전트를 도구·데이터에 잇는 층. 이번 분기 예산을 넣을 유일한 자리.
- 에이전트 간 통신(ACP·A2A 등) — 에이전트가 서로 일을 넘기는 층. 파일럿 하나면 충분.
- AP2 — 에이전트가 돈을 쓰는 층. 개발이 아니라 계약 조항으로 대응.
MCP·ACP·AP2는 정확히 무엇이 다른가요?
해결하는 문제가 다릅니다. MCP는 연결, ACP·A2A 계열은 위임, AP2는 책임을 다룹니다.
용어부터 털고 가죠. MCP(Model Context Protocol)는 에이전트를 사내 도구·데이터에 붙이는 규격이고, 이름이 하나로 고정돼 있어요. ACP는 사정이 다릅니다. 같은 약자에 서로 다른 규격이 여럿 걸려 있어서, 약자만 듣고는 무슨 얘긴지 알 수 없습니다. AP2(Agent Payments Protocol)는 에이전트가 결제를 대행할 때 권한과 책임을 정리하는 규격이고요.
| 층 | 해결하는 문제 | 확인된 상태 (2026년 9월) | 이번 분기 할 일 |
|---|---|---|---|
| MCP | 에이전트 ↔ 도구·데이터 연결 | Linux Foundation 산하 프로젝트, Apache 2.0 배포1 | 사내 시스템 MCP 서버화 + 접근 권한 설계 |
| 에이전트 간 통신 | 에이전트 ↔ 에이전트 위임·호출 | 동음이의 약자에 복수 규격 공존, 단일화 미확인 | 부서 간 파일럿 1건으로 한정 |
| AP2 | 에이전트 결제의 권한·진정성·책임 | 2025년 9월 17일 공개, 60개 넘는 조직 참여2 | PG·카드사 계약서에 위임 조항 반영 |
보충. 회의에서 ACP가 나오면 "에이전트끼리 통신하는 쪽인가요, 커머스 쪽인가요"부터 물으세요. 질문 하나로 30분을 아낍니다.
왜 갑자기 표준이 세 개나 생겼나요?
에이전트가 하는 일이 "대답"에서 "실행"으로 넘어갔기 때문입니다.
대답만 하는 모델에는 표준이 필요 없어요. 프롬프트 넣고 텍스트 받으면 끝이니까요. 그런데 에이전트가 사내 DB를 조회하고, 옆 팀 에이전트에 작업을 넘기고, 법인카드로 물건을 사기 시작하면 질문 세 개가 순서대로 터집니다. 뭘 만질 수 있나. 누구에게 넘길 수 있나. 얼마까지 쓸 수 있나.
프로토콜 세 개는 그 세 질문에 각각 대응해 생겼습니다. 순서가 있다는 뜻이에요. 도구에 닿지 못하는 에이전트는 남에게 위임할 일도 없고, 위임 기록이 없는 에이전트에 결제 권한을 주는 건 그냥 사고입니다.
AX Lab이 비개발자 실무자를 대상으로 클로드 바이브 코딩 원데이 클래스를 운영하면서 반복해 보는 장면도 같아요. 참가자들이 5시간 안에 막히는 지점은 모델 성능이 아니라, 거의 늘 "내 데이터에 어떻게 닿게 하지"입니다. 기업 도입도 똑같은 벽에서 시작합니다.
MCP는 이미 업계 표준이 된 건가요?
사실상 그렇습니다. 단일 벤더 규격이니 미루자는 논리는 더 이상 성립하지 않아요.
근거가 셋입니다. 첫째, 거버넌스가 회사를 떠났습니다. MCP는 "Model Context Protocol a Series of LF Projects, LLC"로 설립돼 Linux Foundation 정책을 따르고, 스펙과 코드는 Apache License 2.0으로 배포됩니다. 유지보수 멤버십은 회사가 아니라 개인 자격으로 부여되고, 특정 기업 지정석이 없습니다.1
둘째, 경쟁 진영이 쓰고 있습니다. 공식 문서는 Claude와 ChatGPT, VS Code, Cursor가 모두 MCP를 지원한다고 적고 있고3, Google은 2025년 4월 Agent Development Kit의 MCP 지원을 발표했어요.4 남의 표준을 자기 개발 키트에 넣는 건 상업적으로 유쾌한 결정이 아닙니다. 그걸 했다는 게 신호예요.
셋째, 개정 속도입니다. 정식 스펙은 2024-11-05로 시작해 2025-03-26, 2025-06-18, 2025-11-25를 거쳐 2026-07-28까지 다섯 번 나왔습니다.5 초안이 아니라 운영되는 규격이라는 뜻이고, 동시에 "한 번 붙이면 끝"이 아니라 버전 추적 담당자가 필요하다는 뜻이기도 해요.
MCP를 "USB-C 포트"에 비유하는 건 공식 문서 자신의 표현입니다.3 다만 USB-C도 케이블마다 전력과 속도가 다르다는 건 우리 모두 알죠. 꽂히는 것과 안전한 것은 다릅니다.
ACP는 MCP와 경쟁 관계인가요?
아니요, 보완 관계입니다. 층이 달라서 애초에 같은 자리를 다투지 않아요.
MCP가 에이전트를 도구에 연결하는 규격이라면, 에이전트 간 통신 규격은 에이전트가 다른 에이전트를 호출하고 작업을 넘기는 방식을 정합니다. 사내 비유로는 이렇습니다. MCP는 직원 한 명에게 ERP 계정을 주는 일이고, ACP는 그 직원이 옆 팀에 업무를 이관하는 결재선을 만드는 일이에요.
그래서 우선순위가 밀립니다. 에이전트가 아직 하나뿐인 조직에 에이전트 간 통신 규격은 쓸 자리가 없어요. 게다가 이 층은 재단 거버넌스와 다섯 차례 정식 개정 같은 흔적을 MCP만큼 보여주는 규격이 아직 없습니다.
전략적으로 의미 있는 건, 이 층이 결제층의 전제라는 점이에요. Google은 AP2를 발표하면서 A2A와 MCP를 확장하는 프로토콜이라고 명시했습니다.2 지금 살 물건은 아니고, 지금 읽어둘 문서입니다.
AP2는 에이전트 결제의 무엇을 보증하나요?
권한·진정성·책임 세 가지입니다. 사용자가 진짜로 권한을 줬는가(authorization), 에이전트의 요청이 사용자 의도와 같은가(authenticity), 사고가 나면 누가 책임지는가(accountability).2
AP2는 2025년 9월 17일 Google이 60개 넘는 조직과 함께 공개했고, Mastercard와 PayPal, American Express, Coinbase, Adyen, Worldpay, UnionPay International, JCB, Etsy, Intuit, Salesforce, ServiceNow 등이 참여사로 발표문에 이름을 올렸습니다.2 핵심은 기술이 아니라 책임 배분이에요. 그 답이 "Mandate"라는 암호학적으로 서명된 계약서 석 장입니다.
| Mandate | 봉인하는 것 | 조달 담당자가 볼 지점 |
|---|---|---|
| Intent Mandate | 최초 지시와 조건(가격 상한·시점·조건) | 위임 한도가 규칙으로 남고, 초과 시 기술적으로 차단되는가 |
| Cart Mandate | 승인된 품목과 가격의 불변 기록 | 사용자가 본 화면 금액과 실제 결제액이 일치 보증되는가 |
| Payment Mandate | 결제수단과 검증된 장바구니의 연결 | 부인 불가(non-repudiable) 감사 기록의 보존 주체와 기간 |
Intent Mandate에 가격 상한과 시점·조건을 규칙으로 지정한다는 개념이 들어 있다는 점이 실무에서 제일 중요합니다.2 승인 포인트는 "에이전트가 결제할 수 있느냐"가 아니라 "한도가 기술적으로 강제되느냐"예요. 사람이 나중에 로그를 읽고 판단하는 구조라면, 그건 통제가 아니라 사후 변명입니다.
무엇부터 손대야 하나요 — AX Lab 에이전트 3층 원칙
원칙은 한 줄입니다. 아래층이 감사 가능해지기 전에 위층을 올리지 마세요.
1층은 배선입니다. MCP로 사내 데이터와 도구를 에이전트에 연결하는 단계예요. 지금 예산과 사람을 넣을 곳은 여기 하나입니다. 완료 기준은 "붙었다"가 아니라 "누가 무엇에 접근했는지 조회된다"입니다.
2층은 대화예요. 에이전트가 다른 에이전트에 일을 넘기는 층. 여기는 파일럿 하나로 충분합니다. 부서 두 곳, 업무 하나, 기한 3개월. 규격을 고르는 게 목적이 아니라 위임 로그가 어떻게 생기는지 조직이 배우는 게 목적이에요.
3층은 결제입니다. AP2가 사는 층이고, 지금 할 일은 구축이 아니라 문서 작업입니다. PG사·카드사 계약 갱신 때 에이전트 위임 한도와 분쟁 책임 조항을 넣고, 내부 전결 규정에 에이전트 결제 한도를 신설하는 정도. 개발 예산은 아직 넣지 마세요.
이 원칙의 진짜 쓸모는 거절 근거가 된다는 데 있어요. 벤더가 3층 제품을 들고 왔을 때 1층 감사 로그를 못 보여주면, 그 자리에서 보류할 수 있습니다.
벤더 계약서에 넣어야 할 리스크 3가지는?
| 리스크 | 터지는 장면 | 합격/불합격 기준 |
|---|---|---|
| 인증이 선택 사항 | MCP에서 인가는 OPTIONAL이고, stdio 전송은 환경변수에서 자격증명을 가져옵니다6 | HTTP 전송 서버가 OAuth 2.1 + RFC 9728 Protected Resource Metadata 미구현이면 반려 |
| 토큰 오용 | 남의 용도로 발급된 토큰을 서버가 받아 하위 API로 그대로 넘기는 "혼란한 대리인" 문제. 스펙은 토큰 패스스루를 명시적으로 금지합니다6 | 토큰 audience 검증 100%, 상류 API 호출 시 별도 토큰 발급, 패스스루 0건 |
| 버전 종속 | 정식 스펙이 2024-11-05부터 2026-07-28까지 다섯 번 갱신됐습니다5 | 지원 스펙 버전이 계약서에 명기되고, 상위 버전 대응 기한이 SLA로 수치화돼 있을 것 |
RFC 8707 리소스 인디케이터와 토큰 audience 바인딩은 MCP 스펙이 MUST로 못 박은 항목입니다.6 벤더 제안서에 이 두 단어가 없으면 보안 검토를 안 했거나 스펙을 안 읽은 거예요. 질문 하나로 걸러집니다.
자주 묻는 질문
Q. MCP를 안 붙이고 그냥 API 연동으로 가면 안 되나요? A. 됩니다. 다만 연동 대상이 늘 때마다 같은 일을 다시 해요. 공식 문서는 MCP를 "한 번 만들어 어디서나 연결"로 설명합니다.3 대상이 세 개 이하면 직접 연동이 빠르고, 그 이상이면 MCP가 싸집니다.
Q. AP2가 표준으로 굳을까요? 기다리는 게 낫지 않나요? A. 결제층은 기다려도 됩니다. 단, 계약은 지금 손보세요. 카드사·PG 계약은 보통 연 단위라, 위임 조항을 못 넣고 갱신하면 1년을 그냥 보냅니다.
Q. 우리 회사는 에이전트가 없는데 지금 검토할 필요가 있나요? A. 있습니다. 검토 대상이 에이전트가 아니라 접근 권한이라서요. MCP 도입에서 어려운 부분은 서버 코드가 아니라 "어느 데이터를 어느 계정에 열어줄지"이고, 이건 에이전트 없이도 지금 정리할 수 있는 일입니다.
Q. MCP·ACP·AP2 중 하나만 고르라면요? A. MCP입니다. 거버넌스가 Linux Foundation 산하로 옮겨졌고1, 경쟁 진영 제품이 이미 지원하고34, AP2조차 MCP를 확장한다고 밝히고 있어요.2 나머지 둘의 전제라 고민할 여지가 적습니다.
세 개를 동시에 대응하려다 아무것도 못 하는 조직을 자주 봅니다. 층을 나누면 이번 분기 할 일이 하나로 줄어요. 1층부터, 그러니까 사내 데이터에 닿는 일부터 시작하세요. 🔌 비개발자 실무자가 5시간 안에 직접 AI 도구를 만들어보는 과정은 AX Lab 클로드 바이브 코딩 원데이 클래스에서 확인하세요.
출처
참고로 이전에 막혔던 두 건(ACP의 IBM/BeeAI 계열 거버넌스, Anthropic의 MCP 최초 공개 발표문)은 여전히 원문 확인이 안 돼서 이번 본문에서도 단정하지 않고, ACP를 "동음이의 약자가 걸린 에이전트 간 통신 계층"으로만 다뤘습니다. anthropic.com·agentcommunicationprotocol.dev에 WebFetch를 허용해 주시면 해당 섹션을 1차 자료로 다시 채우겠습니다.
Footnotes
-
MCP 공식 문서, 『Governance and Stewardship』 — "Model Context Protocol a Series of LF Projects, LLC" 설립, Apache License 2.0, 개인 자격 멤버십·기업 지정석 없음. https://modelcontextprotocol.io/community/governance ↩ ↩2 ↩3
-
Google Cloud Blog, 2025년 9월 17일 — 『Announcing Agent Payments Protocol (AP2)』, 60개 이상 조직 참여, Intent·Cart·Payment Mandate, A2A·MCP 확장 명시. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
MCP 공식 문서, 『What is the Model Context Protocol (MCP)?』 — USB-C 비유, Claude·ChatGPT·VS Code·Cursor 지원 명시. https://modelcontextprotocol.io/docs/getting-started/intro ↩ ↩2 ↩3 ↩4
-
Google Cloud Blog, 2025년 4월 10일 — Agent Development Kit의 MCP 지원 발표. https://cloud.google.com/blog/products/ai-machine-learning/build-and-manage-multi-system-agents-with-vertex-ai ↩ ↩2
-
MCP 스펙 버전 목록 — 정식 릴리스 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, 2026-07-28 및 draft. https://modelcontextprotocol.io/specification/2026-07-28/ ↩ ↩2
-
MCP Specification 2025-06-18, 『Authorization』 — 인가는 OPTIONAL, OAuth 2.1·RFC 9728·RFC 8707 요구사항, 토큰 패스스루 금지 및 혼란한 대리인 문제. https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization ↩ ↩2 ↩3