MCP만 붙이면 AI가 일한다는 착각: A2A와 에이전트 협업의 진짜 경계

 

MCP와 A2A는 AI 에이전트의 연결을 표준화하지만, 업무의 성공까지 보장하지는 않습니다. MCP는 도구와 컨텍스트를 연결하고 A2A는 독립된 에이전트 사이의 상호작용을 다룹니다. 두 프로토콜의 차이와 함께 작업 상태, 결과물, 권한, 프롬프트와 운영 책임을 어떻게 설계해야 하는지 실제 업무 흐름으로 살펴봅니다.

 

AI 에이전트 데모에서 가장 인상적인 순간은 여러 서비스가 한 번에 움직일 때입니다. 사용자가 “다음 분기 장비 구매안을 정리해 줘”라고 말하면 자료를 찾고, 견적을 비교하고, 문서를 만들어 줍니다. 이 장면만 보면 MCP 서버를 연결하고 A2A를 지원하는 에이전트를 붙이는 것으로 업무 자동화가 완성될 것 같습니다.

 

그러나 연결에 성공했다는 말과 구매 검토가 끝났다는 말은 다릅니다. 도구 목록을 읽었다고 올바른 견적을 고르는 것은 아니고, 다른 에이전트에게 요청을 보냈다고 담당 부서가 검토를 완료한 것도 아닙니다. 형식이 맞는 메시지와 믿고 사용할 수 있는 업무 결과 사이에는 여전히 설계해야 할 영역이 남아 있습니다.

 

이 차이를 이해하면 MCP와 A2A의 가치가 더 선명해집니다. 두 기술을 과대평가할 필요도, “결국 API일 뿐”이라며 무시할 필요도 없습니다. 연결 규칙을 공통으로 만드는 것은 중요한 진전입니다. 다만 그 위에서 무엇을 맡기고 어떤 결과를 받아들일지는 제품과 조직이 결정해야 합니다.

 

이 글은 2026년 10월 21일 확인한 MCP 공식 아키텍처·보안 문서, A2A 공식 개념·작업 수명주기 문서와 한국어 기술 블로그를 바탕으로 작성했습니다. MCP 문서에는 2026-07-28 버전이 표시돼 있었고 A2A는 당시 latest 문서를 확인했습니다. 아래의 구매 업무는 설명을 위한 가상 사례이며 실제 기업의 구축 성과나 성능 실험이 아닙니다.

먼저 읽는 핵심

• MCP는 AI 애플리케이션이 외부 도구와 자료를 이용하는 공통 인터페이스를 제공합니다.

• A2A는 내부 구현이 다른 에이전트 사이에서 요청과 상태, 결과물을 주고받는 상호작용을 다룹니다.

• 두 기술은 함께 사용할 수 있으며 모든 시스템에 두 기술이 모두 필요한 것은 아닙니다.

• 지원 프로토콜이 같아도 권한과 업무 의미, 결과 검증이 자동으로 일치하지는 않습니다.

• 좋은 에이전트 연동은 서버 개수보다 검증 가능한 업무 결과로 평가해야 합니다.

이 글의 흐름

연결과 협업의 차이 → MCP 아키텍처 → A2A 작업 모델 → 구매 업무 예시 → 프롬프트와 권한 → 운영·도입 기준 → 자주 묻는 질문

연결은 됐는데 업무가 끝나지 않는 이유

기존 소프트웨어 통합에서도 API를 호출할 수 있다는 사실만으로 업무가 완성되지는 않았습니다. 고객 번호가 어떤 체계를 따르는지, 금액에 부가세가 포함되는지, 어떤 상태부터 취소 가능한지를 합의해야 했습니다. AI 에이전트의 등장으로 이 문제가 사라진 것은 아닙니다. 자연어가 인터페이스에 추가되면서 의미를 잘못 해석할 여지도 함께 생깁니다.

 

예를 들어 한 시스템의 “승인”은 담당자가 내용을 읽었다는 뜻이고, 다른 시스템의 “승인”은 예산 집행을 허가했다는 뜻일 수 있습니다. 메시지 형식이 완전히 호환돼도 두 상태를 같은 것으로 해석하면 실제 업무는 잘못 진행됩니다. 전송 규칙과 업무 의미의 호환성을 따로 확인해야 하는 이유입니다.

도구 설명에 “구매 요청 생성”이라고 적혀 있어도 그것이 초안 저장인지, 부서 검토 요청인지, 외부 업체에 주문서를 발송하는지 알아야 합니다. 이 구분을 모델의 상식에만 맡기면 같은 문장을 다른 실행 범위로 해석할 수 있습니다. 명칭과 설명, 입력 항목과 반환 상태를 함께 설계해야 합니다.

 

협업에는 책임의 경계도 필요합니다. 분석 에이전트가 견적 비교를 끝냈지만 재무 에이전트가 비용 항목을 확인하지 못했다면 전체 요청은 완료일까요? 사용자에게 보여 줄 상태를 누가 결정하고, 어디까지 자동으로 진행할지 정해져 있어야 합니다. 에이전트가 늘어날수록 이러한 판단의 중요성은 커집니다.

 

따라서 프로토콜 도입의 첫 질문은 “무엇을 연결할 수 있나?”와 함께 “어떤 결과를 완료로 인정할 것인가?”여야 합니다. 완료 조건이 분명해야 도구 호출을 구성할지, 다른 에이전트에게 업무를 맡길지, 사람이 검토할 구간을 어디에 둘지 판단하기 쉬워집니다.

MCP란 무엇인가: 모델의 능력과 연결 규칙을 구분하기

MCP는 Model Context Protocol의 약자입니다. 공식 문서는 MCP가 컨텍스트 교환을 위한 프로토콜에 초점을 맞추며, AI 애플리케이션이 LLM을 어떻게 사용하거나 제공된 컨텍스트를 어떻게 관리할지까지 정하지는 않는다고 설명합니다. 이 범위가 MCP를 이해하는 중요한 출발점입니다.

 

MCP를 지원하는 서버가 존재하면 호환되는 애플리케이션이 그 서버가 제공하는 기능과 자료를 정해진 방식으로 발견하고 사용할 수 있습니다. 도구 제공자가 애플리케이션마다 전혀 다른 연결 방식을 구현해야 하는 부담을 줄일 수 있습니다. 하지만 어떤 도구를 언제 선택할지는 애플리케이션과 모델의 동작에 달려 있습니다.

 

공식 아키텍처에는 호스트, 클라이언트와 서버가 나옵니다. 호스트는 여러 연결을 조율하는 AI 애플리케이션입니다. 클라이언트는 특정 MCP 서버와 연결해 기능과 컨텍스트를 받아오는 구성 요소입니다. 서버는 클라이언트에 도구와 자료 등을 제공하는 프로그램입니다. 사용자 눈에 이 구분이 모두 드러날 필요는 없지만 개발할 때는 책임을 구분하는 데 유용합니다.

 

서버의 위치도 하나로 고정돼 있지 않습니다. 같은 컴퓨터에서 동작하는 로컬 서버도 있고 네트워크 너머에서 서비스를 제공하는 원격 서버도 있습니다. 공식 문서는 로컬 프로세스 통신에 쓰는 stdio와 원격 연결에 사용하는 Streamable HTTP를 설명합니다. 실제 지원 방식과 인증 구성은 사용하는 구현에서 확인해야 합니다.

 

여기서 자주 생기는 오해가 있습니다. MCP 서버가 로컬에 있다고 모델까지 반드시 로컬에서 실행되는 것은 아닙니다. 로컬 파일의 내용이 호스트를 거쳐 외부 모델 서비스로 전달되는 구성도 가능합니다. 데이터가 어디에서 읽히는지뿐 아니라 어떤 경로로 추론에 사용되는지도 확인해야 합니다.

 

또 MCP가 기존 API나 SDK를 모두 없애는 것은 아닙니다. MCP 서버 뒤에서는 여전히 기존 서비스의 API나 SDK를 호출할 수 있습니다. 표준화되는 연결 계층과 실제 업무 기능을 제공하는 계층이 함께 존재하는 것입니다. 서버를 만든 뒤에도 원천 API의 변경, 오류와 사용 제한을 관리해야 합니다.

Tools·Resources·Prompts를 같은 기능으로 보면 놓치는 것

MCP 공식 문서는 서버가 제공할 수 있는 핵심 요소로 Tools, Resources와 Prompts를 설명합니다. 세 요소는 AI 애플리케이션에 정보를 주거나 기능을 제공한다는 공통점이 있지만 목적이 다릅니다. 도구만 기억하면 MCP가 제공하는 연결 범위를 지나치게 좁게 이해할 수 있습니다.

 

Tools는 애플리케이션이 호출할 수 있는 실행 기능입니다. 데이터베이스 질의, 파일 작업과 외부 API 호출 등을 생각할 수 있습니다. 조회와 상태 변경이 모두 도구로 노출될 수 있으므로, 도구라는 이름만으로 영향 범위가 작다고 판단하면 안 됩니다.

 

Resources는 애플리케이션이 컨텍스트로 활용할 수 있는 자료입니다. 데이터베이스 구조나 문서 내용처럼 판단에 필요한 정보를 제공하는 역할을 할 수 있습니다. 다만 자료를 읽을 수 있다는 사실과 자료가 최신이고 정확하다는 사실은 별개입니다. 출처와 적용 시점 같은 정보가 필요할 수 있습니다.

 

Prompts는 모델과의 상호작용을 구성하는 재사용 가능한 템플릿입니다. 조직에서 자주 쓰는 검토 절차나 출력 구성을 안내하는 데 활용할 수 있습니다. 이것도 템플릿을 제공하는 기능이지, 그 지시가 모든 상황에서 정확한 결과를 만든다는 품질 보장은 아닙니다.

 

가상의 구매 시스템이라면 견적 조회는 도구, 구매 규정 문서는 자료, 비교 보고서 작성 안내는 프롬프트로 나눌 수 있습니다. 실제 구성은 서비스의 성격에 맞게 달라질 수 있습니다. 중요한 것은 사용자가 기대하는 동작과 각 기능의 책임을 설명할 수 있어야 한다는 점입니다.

 

정보를 너무 많이 노출하는 것도 좋은 연결은 아닙니다. 이름이 비슷한 도구가 겹치거나 필요 없는 자료가 한꺼번에 들어오면 모델의 선택이 어려워질 수 있습니다. 공통 프로토콜은 발견과 호출의 형식을 정리해 주지만, 무엇을 얼마나 보여 줄지는 여전히 컨텍스트 엔지니어링의 과제입니다.

A2A란 무엇인가: 도구 호출에서 독립된 업무 상대에게

A2A는 Agent2Agent 프로토콜입니다. 공식 문서는 독립적이며 내부가 불투명할 수 있는 에이전트들이 서로 상호작용하는 문제를 다룹니다. 다른 팀이나 다른 회사의 에이전트가 어떤 프레임워크와 모델, 도구를 쓰는지 모두 공유하지 않아도 정해진 인터페이스로 요청과 결과를 교환할 수 있게 하는 것이 핵심입니다.

 

여기서 원격 에이전트는 단순히 다른 LLM을 한 번 더 호출한다는 뜻으로만 이해하면 부족합니다. 요청을 해석하고 필요한 도구를 사용하며, 시간이 걸리는 일을 추적하고 추가 정보를 요구하는 시스템일 수 있습니다. 호출하는 쪽은 상대방의 내부 구현보다 제공하는 능력과 상태, 반환 결과에 관심을 갖습니다.

 

공식 개념 문서는 A2A 클라이언트가 요청을 시작하고 A2A 서버 또는 원격 에이전트가 이를 받아 처리한다고 설명합니다. 클라이언트 역할은 다른 AI 에이전트뿐 아니라 애플리케이션이나 서비스가 맡을 수도 있습니다. 따라서 A2A를 “LLM끼리 채팅하는 규격”으로만 축소하면 실제 적용 범위를 놓치게 됩니다.

 

상대방을 이해하는 데 쓰이는 정보가 Agent Card입니다. 정체성, 기능과 스킬, 엔드포인트와 인증 요구 등을 기술하는 JSON 메타데이터 문서입니다. 어떤 일을 지원하고 어떻게 요청해야 하는지 파악하는 데 유용하지만, 카드가 존재한다고 그 서비스의 품질과 신뢰가 검증된 것은 아닙니다.

Agent Card는 명함에 비유할 수 있습니다. 명함에 직무와 연락처가 있다고 그 사람에게 모든 자료를 넘겨도 되는 것은 아닙니다. 서비스 운영 주체, 접근 권한과 사용 조건을 별도로 확인해야 합니다. 발견 가능한 기능과 실제로 사용을 허가한 기능은 구분돼야 합니다.

 

다른 에이전트에게 업무를 맡긴다고 원래 요청을 받은 시스템의 책임이 사라지지도 않습니다. 최종 결과를 사용자에게 어떻게 설명할지, 여러 결과가 충돌하면 누가 판단할지, 실패한 하위 작업을 어떻게 표시할지는 조율하는 애플리케이션이 설계해야 합니다.

Task·Message·Artifact: 대화와 작업과 결과물은 다르다

A2A를 이해할 때는 메시지, 작업과 결과물을 나눠 보는 것이 좋습니다. 공식 문서에서 Message는 상호작용의 한 차례를 표현합니다. 요청과 질문, 답변이나 상태 설명처럼 대화의 내용을 전달할 수 있습니다. 모든 메시지가 최종 납품물인 것은 아닙니다.

 

Task는 식별자와 수명주기를 가진 작업 단위입니다. 시간이 걸리는 일을 추적하고 추가 입력이 필요한 상태나 종료 상태를 구분하는 데 쓰입니다. “요청을 받았다”, “진행 중이다”, “사용자 정보가 더 필요하다”, “완료했다”를 같은 응답 문장으로 뭉개지 않을 수 있다는 점이 중요합니다.

 

Artifact는 문서, 이미지나 구조화된 데이터처럼 작업에서 나온 구체적인 결과물입니다. “분석을 완료했습니다”라는 메시지와 실제 분석 보고서는 다릅니다. 보고서 파일과 비교 데이터, 근거 목록이 실제 반환됐는지 확인해야 다음 단계에서 사용할 수 있습니다.

 

Message와 Artifact의 내용은 Part라는 구성 단위로 담을 수 있습니다. 공식 개념 문서는 텍스트, 파일을 가리키는 주소나 데이터, 구조화된 값 등을 설명합니다. 이렇게 다양한 내용을 표현할 수 있어도 수신자가 어떤 형식을 처리할 수 있는지와 결과물의 의미는 별도로 맞춰야 합니다.

 

contextId와 taskId도 같은 것으로 취급하면 안 됩니다. 공식 수명주기 문서에서 contextId는 관련된 여러 상호작용과 작업을 묶는 식별자이고, taskId는 특정 작업을 가리킵니다. 같은 업무의 후속 요청이라도 새 작업이 생길 수 있습니다. 관련 대화의 연속성과 개별 실행의 구분을 함께 관리하는 구조입니다.

 

또 공식 문서는 완료·취소·거절·실패 같은 종료 상태에 도달한 작업을 다시 시작하지 않는다고 설명합니다. 후속 수정은 같은 맥락 안의 새로운 작업으로 다룹니다. 개발할 때는 설명용 용어를 그대로 코드에 옮기기보다 사용 중인 명세와 SDK의 실제 상태값과 필드를 확인해야 합니다.

 

이 모델이 있어도 완료의 업무 의미가 저절로 정해지는 것은 아닙니다. 견적 분석 작업의 completed는 분석 결과물이 나왔다는 뜻일 수 있습니다. 구매 승인과 발주 완료까지 끝났다는 뜻인지는 별개의 계약입니다. 프로토콜 상태와 도메인의 상태를 연결하는 정의가 필요합니다.

MCP와 A2A의 차이는 단순한 경쟁 구도가 아니다

A2A 공식 비교 문서는 두 프로토콜을 수직과 수평 연결이라는 관점으로 설명합니다. MCP는 한 애플리케이션의 에이전트가 도구와 자료를 이용하도록 능력을 깊게 하고, A2A는 그 경계를 넘어 다른 에이전트와 상호작용하도록 범위를 넓힌다는 비유입니다.

이 비유는 출발점으로 유용하지만 절대적인 물리 경계는 아닙니다. MCP 서버도 원격에서 실행될 수 있고 뒤에서 복잡한 시스템을 호출할 수 있습니다. A2A 에이전트도 간단한 요청에는 즉시 메시지를 반환할 수 있습니다. 네트워크를 넘는가, 처리 시간이 긴가 하나만으로 둘을 구분하면 부정확합니다.

 

특히 “MCP는 동기 호출만 하고 A2A만 비동기 작업을 지원한다”는 식의 설명은 피하는 편이 좋습니다. 확인한 MCP 아키텍처 문서에는 오래 걸리는 요청의 상태와 결과를 나중에 조회할 수 있게 하는 선택적 Tasks 확장도 소개돼 있습니다. 실제 지원 여부와 호환성은 구현과 버전에 따라 확인해야 합니다.

 

따라서 선택의 핵심은 어떤 상호작용 계약을 노출하려는지입니다. 명확한 입력과 출력의 기능을 제공하려면 도구 인터페이스가 자연스러울 수 있습니다. 독립된 업무 상대와 범위를 조율하고 상태와 결과물을 교환해야 한다면 A2A의 작업·메시지 모델이 검토 대상이 됩니다.

 

두 프로토콜을 함께 쓰는 구성도 가능합니다. 중앙 에이전트가 A2A로 재무 검토 에이전트에 업무를 맡기고, 재무 에이전트는 내부에서 MCP로 비용 자료와 구매 규정을 조회할 수 있습니다. 외부에 보이는 협업 계약과 내부 도구 사용을 나눠 구성하는 방식입니다.

 

반대로 하나의 애플리케이션 안에서 모든 기능을 안정적으로 처리한다면 굳이 원격 에이전트 계층을 추가할 필요가 없을 수 있습니다. 단순한 API 호출이나 기존 워크플로가 더 적절한 경우도 있습니다. 표준을 지원하는 것과 모든 문제에 그 표준을 적용하는 것은 다른 결정입니다.

가상 사례: 장비 구매 검토를 에이전트에게 맡긴다면

한 회사에서 개발 장비 구매안을 검토한다고 가정해 보겠습니다. 사용자는 필요한 수량과 용도, 예산 범위를 제시하고 후보 제품과 견적을 비교해 달라고 요청합니다. 이때 최초 목표는 검토용 보고서 작성으로 정하고 실제 주문은 별도의 절차로 둡니다.

 

먼저 조율하는 에이전트가 요청을 정리합니다. 비교할 사양, 예산의 통화, 부가세와 배송비 포함 여부, 견적 유효기간과 원하는 완료 시점이 필요합니다. 빠진 정보가 결과에 큰 영향을 주면 추가 확인을 요청해야 합니다. 아무 조건 없이 “가장 좋은 장비를 골라라”는 목표만 전달하면 기준이 제각각일 수 있습니다.

 

조달 자료 조회가 명확한 기능이라면 MCP 도구로 노출할 수 있습니다. 후보 목록과 견적을 가져오고, 구매 규정은 자료로 제공하며, 조회 시각과 출처를 결과에 포함하도록 설계합니다. 이미 존재하는 구매 시스템 API를 MCP 서버가 감싸는 구성도 가능합니다.

 

재무 검토가 별도 팀의 독립 서비스라면 A2A로 요청하는 방안을 검토할 수 있습니다. 상대 에이전트가 어떤 검토를 제공하고 어떤 입력이 필요한지 확인한 뒤, 보고서 작성에 필요한 범위만 전달합니다. 단순 예산 조회만 필요하다면 굳이 업무를 위임하지 않고 조회 도구로 처리할 수도 있습니다.

 

재무 에이전트가 추가 분류가 필요하다고 응답하면 전체 흐름은 잠시 멈출 수 있습니다. “견적 비교는 완료, 비용 항목 확인 대기”처럼 부분 상태를 드러내야 합니다. 일부 하위 작업이 끝났다는 이유로 전체 검토가 완료됐다고 표시하면 사용자는 다음 단계로 잘못 넘어갈 수 있습니다.

최종적으로는 비교 보고서와 계산에 사용한 견적 자료, 적용 규정과 미확인 항목을 받습니다. 결과물에는 추천 이유와 대안, 유효기간이 포함될 수 있습니다. 이 구성은 예시이며 실제 요구사항에 맞춰 조정해야 합니다. 중요한 것은 사람이 판단할 근거가 결과물에 남는 것입니다.

 

여기까지가 성공해도 구매 주문이 실행된 것은 아닙니다. 보고서 생성, 예산 검토, 구매 승인과 발주는 다른 업무 상태입니다. 하나의 “완료” 표시로 덮기보다 실제로 끝난 범위를 보여 주면 에이전트의 자율성을 늘리더라도 사용자와 시스템이 같은 상황을 이해하기 쉬워집니다.

프롬프트 엔지니어링은 연결 뒤에서 더 구체적이어야 한다

MCP와 A2A가 등장했다고 프롬프트 엔지니어링이 불필요해지는 것은 아닙니다. 모델이 도구와 다른 에이전트의 기능을 구분하고 언제 무엇을 요청할지 판단하려면 명확한 목표와 제약이 필요합니다. 연결 대상이 늘면 모호한 지시가 영향을 주는 범위도 커질 수 있습니다.

 

가상의 구매 검토에서는 “추천안을 작성하되 외부 주문을 생성하지 않는다”, “비교 가격의 통화와 세금 포함 여부를 맞춘다”, “확인하지 못한 수치는 추정값과 구분한다”처럼 행동과 결과 기준을 제시할 수 있습니다. 이는 복사해서 쓰는 만능 프롬프트가 아니라 업무 정의를 구체화하는 예시입니다.

 

다른 에이전트에게 넘기는 요청에도 목적과 완료 조건이 있어야 합니다. 원래 대화 전체를 무조건 전달하기보다 검토 대상, 필요한 자료와 반환 형식, 남은 의문점을 정리할 수 있습니다. 상대방이 알아서 맥락을 복원하리라고 기대하면 중요한 제약이 누락될 수 있습니다.

 

반환 결과의 계약도 필요합니다. 자유로운 설명만 받으면 통화와 기간, 미확인 항목을 다음 단계에서 다시 추출해야 할 수 있습니다. 구조화된 필드를 사용하더라도 빈 값의 의미와 오류 처리, 숫자의 단위를 함께 정해야 실제로 활용할 수 있습니다.

 

지시의 우선순위와 외부 데이터의 신뢰 경계도 중요합니다. 견적 문서나 외부 에이전트가 보낸 텍스트에 원래 사용자 목표를 바꾸는 문장이 있다고 해서 그것이 새로운 권한이 되는 것은 아닙니다. 외부 자료는 업무 판단의 입력으로 다루고 실행 범위를 바꾸는 명령과 구분해야 합니다.

 

다만 중요한 제약을 프롬프트에만 적어 두면 충분하지 않습니다. 발주 금지나 금액 한도처럼 강제해야 하는 규칙은 실행 계층과 권한 검사에서도 적용해야 합니다. 프롬프트는 바람직한 행동을 안내하고 서버는 허용된 행동의 경계를 확인하는 구성이 견고합니다.

인증됐다는 사실이 모든 업무 권한을 뜻하지는 않는다

연결 대상이 늘어날수록 누가 누구를 대신해 행동하는지 분명해야 합니다. 사용자가 호스트에 로그인한 상태, 호스트가 MCP 서버에 접근하는 상태, 원격 에이전트가 원천 시스템에 접근하는 상태는 서로 다른 관계입니다. 한 곳의 로그인 성공을 전체 권한으로 해석하면 안 됩니다.

 

인증은 요청 주체를 확인하는 문제이고 인가는 그 주체가 어떤 행동을 할 수 있는지 판단하는 문제입니다. 견적을 읽을 수 있어도 구매 승인 권한은 없을 수 있습니다. 같은 부서의 자료를 조회할 수 있어도 다른 고객이나 다른 조직의 자료에는 접근할 수 없을 수 있습니다.

A2A Agent Card는 인증 요구를 설명하는 역할을 하지만, 카드 자체가 사용자의 업무 승인을 대신하지 않습니다. 서비스가 어떤 인증 방식을 요구하는지 아는 것과 그 서비스에 특정 자료를 전달하거나 변경 작업을 맡길 권한을 갖는 것은 구분해야 합니다.

 

MCP 공식 보안 문서는 검증되지 않은 토큰을 받아 하위 API로 그대로 넘기는 token passthrough를 금지된 안티패턴으로 설명합니다. 접근 토큰이 어떤 서비스를 대상으로 발급됐는지와 필요한 범위를 확인해야 한다는 뜻입니다. 한 서비스의 자격 증명을 다른 서비스에 무작정 재사용하는 것은 안전한 권한 위임이 아닙니다.

 

실무적으로는 자료 조회, 초안 생성, 내부 상태 변경과 외부 발송의 권한을 구분할 수 있습니다. 모든 호출에 같은 확인 절차를 붙일 필요는 없지만 영향과 되돌릴 수 있는 정도에 맞게 경계를 정해야 합니다. 사용자도 현재 요청이 어느 범위까지 실행될 수 있는지 이해할 수 있어야 합니다.

 

외부 에이전트에 전달할 정보도 최소한으로 구성하는 편이 좋습니다. 견적 비교에 필요 없는 개인 정보나 내부 문서 전체를 넘길 이유는 없을 수 있습니다. 자료를 참조하는 링크를 보낼 때도 상대방의 접근 범위와 유효기간, 이후 보관 조건을 확인해야 합니다.

작업 상태와 결과물을 운영 가능한 증거로 만들기

분산된 에이전트 시스템에서는 “어디까지 끝났는가”를 알 수 있어야 합니다. 요청을 보낸 시각, 하위 작업 식별자, 상대 서비스와 현재 상태, 생성된 결과물의 관계를 연결해 두면 실패와 지연을 추적하기 쉽습니다. 다만 로그에 민감한 원문을 모두 남기는 것이 좋은 관찰 가능성은 아닙니다.

 

A2A의 contextId가 있다고 전체 요청의 모든 추적이 자동으로 해결되는 것도 아닙니다. 원격 서비스의 작업 식별자와 내부 요청, 실제 원천 API 호출의 관계를 애플리케이션에서 연결해야 할 수 있습니다. 무엇을 어느 단계에서 보관할지는 운영 목표와 데이터 정책에 맞게 정합니다.

 

상태 업데이트와 결과물은 따로 다뤄야 합니다. 진행률이 높다고 결과가 올바른 것은 아니고, completed가 왔다고 사용 가능한 보고서가 있다고 단정할 수 없습니다. 필수 자료가 포함됐는지와 내용의 일관성을 확인한 뒤 다음 업무 단계로 넘기는 것이 좋습니다.

 

취소 요청도 전체 업무의 원상복구와 같지 않습니다. 일부 하위 작업이 이미 문서를 만들거나 외부 상태를 변경했다면 별도의 정리 절차가 필요할 수 있습니다. 어떤 작업을 중단할 수 있고 무엇이 남는지 정의해야 사용자에게 실제 상태를 설명할 수 있습니다.

 

재시도 역시 프로토콜 식별자만으로 안전해지는 것은 아닙니다. 통신 요청의 식별과 실제 업무의 중복 방지는 다른 문제입니다. 특히 변경 작업은 기존 처리 상태를 확인하고 중복 실행을 막는 별도의 설계가 필요합니다. 이 부분은 연결 표준 위에서 도메인 서비스가 책임져야 할 영역입니다.

 

결과물을 수정할 때는 어느 버전을 최종으로 채택했는지도 남겨야 합니다. A2A 수명주기 문서는 후속 작업에서 나온 결과물의 연결과 수용 여부를 클라이언트 측에서 관리하는 관점을 설명합니다. 가장 최근에 생성된 파일과 사용자가 실제 승인한 파일이 항상 같은 것은 아닙니다.

호환성은 로고가 아니라 버전과 기능의 조합이다

제품 소개에 “MCP 지원” 또는 “A2A 지원”이라고 적혀 있어도 구현 범위가 같다는 뜻은 아닙니다. 사용한 명세 버전, 전송 방식과 인증 구성, 선택적 기능과 확장의 지원 여부를 확인해야 합니다. 기본 요청이 통과해도 스트리밍이나 오래 걸리는 작업에서 차이가 드러날 수 있습니다.

 

문서의 작성일도 중요한 단서입니다. 이번에 조사한 한국어 글들은 2025년 초기 생태계의 설명을 담고 있었습니다. 개념을 이해하는 데 유용하지만 당시의 예제 주소나 필드, 지원 범위를 현재 구현에 그대로 적용하면 맞지 않을 수 있습니다.

 

따라서 블로그의 쉬운 비유와 공식 명세의 구체적인 계약을 함께 읽는 것이 좋습니다. “도구에서 동료로” 같은 표현은 목적의 차이를 이해하는 데 도움이 됩니다. 그러나 구현 단계에서는 메시지와 작업의 구분, 기능 탐색과 권한 처리 같은 실제 동작을 확인해야 합니다.

 

업데이트할 때는 정상적인 호출 한 번만 확인하지 마세요. 지원하지 않는 기능을 요청했을 때, 필요한 입력이 빠졌을 때, 권한이 만료됐을 때와 작업 중 연결이 끊겼을 때의 처리가 중요합니다. 사용자가 받는 상태와 개발자가 보는 기록이 서로 맞는지도 확인해야 합니다.

 

표준 프로토콜은 맞춤형 통합을 줄일 기회를 주지만 유지보수 자체를 없애지는 않습니다. 원천 서비스와 클라이언트, 서버와 SDK가 각각 바뀔 수 있기 때문입니다. 지원 버전과 책임자를 정리해 두면 장애가 났을 때 조사 범위를 좁힐 수 있습니다.

처음 도입하는 팀은 어떤 순서로 결정하면 좋을까

먼저 반복되는 업무 하나를 정하고 현재 사람이 사용하는 자료와 완료 조건을 적습니다. 그다음 작업을 명확한 기능 호출로 표현할 수 있는지, 독립된 업무 상대에게 맡겨야 하는지 구분합니다. 이 질문이 MCP와 A2A를 선택하는 데 기술 유행보다 유용합니다.

 

필요한 기능이 몇 개의 안정적인 조회와 계산이라면 기존 API나 간단한 워크플로로 기준선을 만들 수 있습니다. 여러 AI 애플리케이션에서 같은 기능을 재사용할 필요가 있다면 MCP가 연결 비용을 줄이는지 검토합니다. 하나의 앱을 위해 복잡한 계층을 추가하는 것이 언제나 이득은 아닙니다.

 

서로 다른 팀이 운영하는 에이전트와 요청 범위를 조율하고 오래 걸리는 작업을 주고받아야 한다면 A2A의 모델을 검토할 수 있습니다. 이때 상대의 내부 구현을 공유하지 않아도 되는 점과 작업 상태·결과물을 교환하는 방식이 실제 문제를 줄이는지 확인합니다.

 

평가는 연결 성공률에 머물지 않아야 합니다. 검증된 업무 성공률, 처리 시간과 사람의 재작업, 잘못된 권한 사용 여부와 작업당 비용을 함께 봅니다. 서버와 에이전트를 추가한 뒤 품질이 나아졌는지 같은 기준으로 비교해야 합니다.

 

가상의 구매 검토라면 보고서에 필요한 견적이 빠지지 않았는지, 비교 조건이 맞는지와 미확인 항목이 표시됐는지 확인할 수 있습니다. 사용자가 결과를 검토하는 시간도 측정할 수 있습니다. 이 지표들은 예시이며 실제 업무에서 중요하게 보는 결과를 기준으로 정해야 합니다.

 

확장할 때도 실패의 원인을 나눠 봅니다. 연결 실패인지, 도구 설명의 문제인지, 원천 자료의 오류인지, 위임 범위가 모호했는지와 결과 검증이 빠졌는지 구분해야 합니다. 모든 실패에 에이전트를 하나 더 붙이는 방식으로는 근본 원인을 해결하기 어렵습니다.

MCP와 A2A를 이해할 때 자주 나오는 질문

Q. MCP 서버가 있으면 AI 에이전트가 자동으로 생기나요?

아닙니다. MCP 서버는 도구와 컨텍스트를 제공하는 인터페이스입니다. 목표를 이해하고 도구를 선택하며 결과를 확인하는 동작은 호스트와 모델, 애플리케이션의 실행 구조에 달려 있습니다.

Q. MCP와 A2A 중 하나가 다른 하나를 대체하나요?

목적이 다르고 함께 사용할 수 있습니다. 다만 실제 기능의 일부는 겹치거나 확장될 수 있으므로 “도구냐 에이전트냐”라는 이름만 보지 말고 어떤 상호작용 계약이 필요한지 판단하는 것이 좋습니다.

Q. 여러 에이전트를 쓰려면 반드시 A2A가 필요한가요?

그렇지 않습니다. 같은 애플리케이션 안에서 내부 호출이나 기존 메시지 시스템으로 여러 에이전트를 구성할 수 있습니다. 독립된 시스템과 공통 규약으로 상호작용해야 하는지에 따라 A2A 도입의 가치를 평가해야 합니다.

Q. MCP는 짧은 동기 작업, A2A는 긴 비동기 작업이라는 구분이 맞나요?

충분한 구분은 아닙니다. A2A는 즉시 응답하는 메시지도 다루며, 확인한 MCP 문서에는 오래 걸리는 작업을 위한 선택적 Tasks 확장도 있습니다. 구현과 버전의 지원 범위, 상태와 결과물의 계약을 함께 확인해야 합니다.

Q. 로컬 MCP 서버를 사용하면 자료가 외부로 나가지 않나요?

서버의 위치만으로 판단할 수 없습니다. 호스트가 외부 모델을 사용하는지, 읽은 자료를 어디로 전달하는지와 원격 서비스를 호출하는지를 확인해야 합니다. 전체 데이터 흐름을 기준으로 판단하는 것이 정확합니다.

Q. Agent Card가 있으면 그 에이전트를 믿고 사용해도 되나요?

Agent Card는 기능과 연결·인증 요구를 설명하는 메타데이터입니다. 서비스의 실제 운영 주체, 권한과 데이터 처리 조건, 결과 품질의 검증은 별도로 필요합니다. 발견 가능성과 신뢰성은 같은 의미가 아닙니다.

Q. 프롬프트 엔지니어링과 프로토콜 설계는 어느 쪽이 먼저인가요?

업무의 목표와 완료 조건을 먼저 정의하는 것이 좋습니다. 그다음 지시와 입력·출력 계약, 연결 방법과 실행 권한을 함께 구체화합니다. 프롬프트의 정확성과 시스템의 강제 가능한 규칙은 서로 보완하는 역할입니다.

AI 에이전트의 미래는 연결 다음에서 결정된다

MCP와 A2A는 서로 다른 도구와 에이전트를 재사용하고 조합할 수 있는 기반을 넓힙니다. 개별 애플리케이션마다 모든 연결을 새로 만드는 부담을 줄이고, 내부 구현이 다른 시스템 사이에 공통의 상호작용 모델을 마련한다는 점에서 가치가 있습니다.

 

그러나 공통 언어가 생겼다고 협업의 목표와 책임까지 저절로 정해지지는 않습니다. 어떤 자료를 넘기고 어떤 행동을 허용할지, 무엇을 완료로 인정하고 어떤 결과물을 채택할지는 여전히 제품의 설계입니다. AI가 대신 판단할 범위가 넓을수록 이 계약은 더 중요해집니다.

 

지금 도입을 검토한다면 서버 개수와 지원 로고보다 업무 하나의 흐름을 먼저 그려 보세요. 입력에서 권한, 실행과 상태, 결과물과 검증까지 연결해 보고 어느 경계에서 MCP나 A2A가 실제 통합 비용을 줄이는지 확인하면 됩니다.

 

잘 연결되는 시스템은 출발점입니다. 사용자가 믿고 일을 맡길 수 있는 시스템은 그 연결 위에 분명한 목표와 권한, 확인 가능한 결과를 쌓아 만든 것입니다. 에이전트 협업의 경쟁력은 서로 대화할 수 있다는 사실을 넘어, 그 대화가 정확한 업무 결과로 이어지게 하는 데서 나옵니다.

참고 자료와 조사한 한국어 기술 블로그

MCP 공식 문서 — Architecture overview. 호스트·클라이언트·서버, Tools·Resources·Prompts, 연결 방식과 MCP의 범위, 선택적 Tasks 확장을 확인했습니다. 열람 시 버전 표시는 2026-07-28이었습니다.

 

https://modelcontextprotocol.io/docs/learn/architecture

Architecture overview - Model Context Protocol

 

A2A 공식 문서 — A2A and MCP: Detailed Comparison. 수직·수평 연결의 비유, 독립된 에이전트와 도구의 상호보완적 관계를 참고했습니다.

 

https://a2a-protocol.org/latest/topics/a2a-and-mcp/

A2A and MCP - A2A Protocol

 

A2A 공식 문서 — Core Concepts. Agent Card, Task, Message, Part와 Artifact의 역할을 확인했습니다.

 

https://a2a-protocol.org/latest/topics/key-concepts/

Core Concepts - A2A Protocol

 

A2A 공식 문서 — Life of a Task. contextId와 taskId, 즉시 메시지와 상태를 가진 작업, 종료된 작업의 후속 처리와 결과물 버전 관리의 설명을 참고했습니다.

 

https://a2a-protocol.org/latest/topics/life-of-a-task/

Life of a Task - A2A Protocol

 

MCP 공식 문서 — Security Best Practices. 인증·인가 경계와 token passthrough 관련 설명을 확인했습니다.

 

https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices

Security Best Practices - Model Context Protocol

 

카카오벤처스 — 「MCP에 이어 A2A, 이제 AI도 조립해서 쓴다」, 2025년 5월 28일. 개념을 업무 예시와 연결하고 비교하는 한국어 기술 블로그 구성을 조사했습니다. 초기 생태계에 대한 전망과 현재 명세의 기능을 구분해 참고했습니다.

 

https://www.kakao.vc/blog/mcp-to-a2a

MCP에 이어 A2A, 이제 AI도 조립해서 쓴다 - kakaoventures blog

 

Logto 한국어 블로그 — 「A2A vs MCP: 새로운 에이전트 생태계를 위한 두 개의 보완적 프로토콜」, 페이지 표기 2025년 4월 11일. 역할별 아키텍처 설명과 업무 흐름의 비교 방식을 조사했습니다. 초기 예제와 서비스 소개를 공식 명세의 현재 동작과 동일하게 취급하지 않았습니다.

 

https://blog.logto.io/ko/a2a-mcp

A2A vs MCP: 새로운 에이전트 생태계를 위한 두 개의 보완적 프로토콜 · Logto 블로그

 

자료 확인일: 2026년 10월 21일. 본문은 공개 문서를 바탕으로 새로 구성한 기술 해설입니다. 실제 구현에서는 고정한 프로토콜 버전과 SDK 문서를 기준으로 기능·상태값·인증 요구를 확인해야 합니다.