A2A

고급

A2A는 AI 문맥에서 자주 등장하는 개념입니다. 이 페이지는 고급 난이도로 A2A의 뜻과 쓰임을 빠르게 이해할 수 있도록 정리한 AI 용어사전 항목입니다.

A2A를 처음 보는 독자도 헷갈리지 않도록 정의와 맥락를 한 페이지에 묶었습니다. 아래 설명을 먼저 읽고, 이어서 연결된 개념과 글까지 보면 이해가 훨씬 빨라집니다.

A2A(Agent2Agent)는 서로 다른 회사와 프레임워크에서 만든 AI 에이전트끼리 직접 통신하고 협업하게 해주는 오픈 프로토콜입니다. 구글이 2025년 4월 9일 공개했고, 같은 해 6월 Linux Foundation(리눅스 재단)에 기증돼 특정 회사에 종속되지 않는 중립 표준으로 운영되고 있습니다. 한 회사의 일정 관리 에이전트가 다른 회사의 항공권 예약 에이전트에게 "다음 주 화요일 출장 잡아줘"라고 일을 넘기는 식의 협업을, 둘이 같은 플랫폼이 아니어도 가능하게 만드는 약속입니다.

A2A가 중요한 이유는 에이전트가 늘어날수록 서로 말이 안 통하는 문제가 커지기 때문입니다. 회사마다 에이전트를 따로 만들면 각자 다른 언어를 쓰는 것과 같아서, 협업하려면 일일이 연결 코드를 짜야 합니다. 예를 들어 어떤 회사는 자기 채용 에이전트가 외부 인사 평가 에이전트에게 지원자 검토를 맡기고 싶어도, 둘의 통신 방식이 다르면 매번 새로 맞춤 작업을 해야 했습니다. A2A는 이 연결 방식을 표준으로 정해 누가 만든 에이전트든 같은 규칙으로 대화하게 합니다. 발표 시점에 50여 곳이던 참여 기업은 2026년 들어 마이크로소프트, AWS, 세일즈포스, SAP, 서비스나우, IBM 등 150곳 이상으로 늘었고, Azure AI Foundry나 Amazon Bedrock 같은 클라우드 서비스에도 기본 기능으로 들어갔습니다.

쉽게 비유하면 A2A는 에이전트들이 주고받는 명함과 업무 의뢰서의 양식입니다. 각 에이전트는 Agent Card(에이전트 카드)라는 명함으로 "나는 무엇을 할 수 있고 어떻게 연락하면 되는지"를 공개합니다. 상대는 이 명함을 보고 일을 맡길 수 있는지 판단한 뒤, Task(작업)라는 정해진 양식에 의뢰 내용을 담아 보냅니다. 작업이 끝나면 결과물은 Artifact(산출물)라는 형태로 돌려받습니다. 통신은 웹에서 흔히 쓰는 HTTP와 JSON-RPC 위에서 오가고, 시간이 오래 걸리는 작업은 진행 상황을 중간중간 흘려보내는 방식도 지원합니다.

실제 동작은 크게 세 단계로 흐릅니다. 먼저 일을 맡기려는 에이전트가 상대의 Agent Card를 읽어 "이 일을 할 수 있는 상대인지" 확인합니다. 다음으로 정해진 양식에 작업을 담아 보내고 신원을 검증합니다. 마지막으로 상대가 작업을 처리해 결과를 돌려줍니다. 예를 들어 출장 준비 에이전트가 항공권 에이전트, 호텔 에이전트, 경비 정산 에이전트에게 각각 다른 일을 동시에 맡기고, 돌아온 결과를 모아 하나의 일정으로 묶는 식의 협업이 가능합니다. 사람이 여러 부서에 메일을 돌리고 답을 취합하는 과정을 에이전트끼리 자동으로 하는 셈입니다.

가장 헷갈리는 개념은 MCP입니다. 둘은 경쟁이 아니라 서로를 채웁니다. MCP가 에이전트와 도구를 잇는 약속이라면, A2A는 에이전트와 에이전트를 잇는 약속입니다. 한 에이전트가 날씨 API나 데이터베이스 같은 도구를 부를 때는 MCP를 쓰고, 다른 에이전트에게 일을 위임할 때는 A2A를 씁니다. 그래서 멀티에이전트 시스템을 제대로 만들려면 보통 두 프로토콜을 같이 깝니다. 업계에서는 도구 연결은 MCP, 에이전트 연결은 A2A, 웹 접근은 WebMCP로 나누는 세 층 구조를 사실상 표준 조합으로 받아들이는 분위기입니다.

💡한 줄 정리

MCP는 에이전트가 도구를 쓰게 하고, A2A는 에이전트끼리 일을 나누게 합니다. 도구를 부르는 손과 동료에게 말을 거는 입이 따로 있다고 보면 됩니다.

하지만 표준이 있다고 모든 게 자동으로 안전해지지는 않습니다. 다른 회사 에이전트에게 일을 맡긴다는 건 신원 확인과 권한 관리가 까다로워진다는 뜻입니다. 엉뚱한 에이전트에게 민감한 작업을 넘기거나, 권한을 너무 넓게 열어두면 사고로 이어질 수 있습니다. 실제로 2026년 조사에서 에이전트 운영을 제대로 통제할 거버넌스 체계를 갖춘 기업은 다섯 곳 중 한 곳 정도에 그쳤습니다. 그래서 A2A는 신원 확인과 권한 범위 지정을 프로토콜 안에 포함하고 있고, 도입하는 쪽에서도 어떤 에이전트에게 무엇까지 허용할지 사람이 먼저 설계하는 단계가 필요합니다. 결국 A2A는 에이전트 협업을 가능하게 하는 출발점이지, 그 자체로 안전을 보장하는 장치는 아닙니다. 표준을 깔되 통제는 따로 챙겨야 한다는 점이 도입의 핵심입니다.