들어가며

이해를 돕기 위해 가상의 장면을 하나 떠올려 보겠습니다. 우리 회사 구매팀이 사내 업무를 돕는 AI 에이전트를 도입했습니다. 마침 오랜 기간 포장재를 납품해 온 협력사도 영업팀을 위해 견적 산출 AI 에이전트를 구축했다고 합니다. 그렇다면 굳이 사람이 이메일을 쓰고 전화를 돌릴 것 없이 우리 구매 에이전트가 협력사 에이전트에 직접 요청해 견적을 받아 오게 하면 어떨까요.

겉으로 보기에는 두 에이전트를 연결하기만 하면 당장이라도 자동화가 끝날 것처럼 보입니다. 구매 담당자가 “친환경 완충재 500개 견적 받아 줘"라고 지시하면 우리 AI가 협력사 AI에 요청을 보내고 잠시 뒤 견적서가 도착하는 그림이죠.

하지만 실제 기업 간 거래를 떠올려 보면 현실적인 질문들이 곧바로 뒤따릅니다. 우리 AI가 견적을 요청할 때 사내에서 나눈 예산 상한선 대화까지 넘기지는 않을까요. 협력사 AI가 말한 ‘500개’가 낱개 기준인지 박스 기준인지는 누가 확인해야 할까요. 상대방 AI가 견적서 작성을 완료했다고 알렸을 때 그것만으로 우리 회사가 그 조건을 채택하고 발주까지 진행한 셈이 되는 걸까요.

최근 기업들이 각자 에이전트를 도입하면서 서로 다른 조직이나 팀이 만든 독립된 에이전트끼리 어떻게 일을 주고받을 것인지가 중요한 화두로 떠올랐습니다. 이때 자주 언급되는 규약이 에이전트 간 통신 프로토콜인 A2A(Agent2Agent)입니다.

A2A는 내부 구현을 공개하지 않는 독립된 에이전트들이 업무를 접수하고 진행 상태를 확인하고 결과물을 주고받는 공통의 절차와 형식을 정해 줍니다. 하지만 통신 규약이 같다고 해서 용어의 의미나 실행 권한, 검수 기준까지 알아서 합의되지는 않습니다. 가상의 구매 견적 요청 흐름을 따라가며 A2A가 해 주는 역할과 우리 조직이 직접 정해야 하는 운영 기준을 짚어 보겠습니다.

업무 안내서와 접수 번호로 이해하는 A2A의 기본 구조

다른 회사에 업무를 맡길 때 우리는 상대방의 사내 전산망 비밀번호를 달라고 하거나 직원의 업무 수첩을 전부 들여다보지 않습니다. 대신 협력사 창구의 업무 안내서를 보고 요청서를 접수한 뒤, 접수 번호로 진행 상황을 확인하고 결과물을 전달받습니다.

A2A 공식 명세 가 하는 일도 이 창구 업무와 맞닿아 있습니다. 각 에이전트가 내부 메모리나 고유한 추론 로직, 사내 도구를 외부에 공개하지 않으면서도 서로 다른 환경에서 만들어진 에이전트와 핵심 개념을 공유하며 소통할 수 있게 해 줍니다.

첫째는 에이전트 카드(Agent Card)입니다. 상대 에이전트가 창구에 비치해 둔 기계 판독용 업무 안내서이자 명함이라고 보면 됩니다. 여기에는 에이전트의 이름과 설명, 지원하는 업무 기능, 접속 인터페이스, 요구하는 인증 방식이 적혀 있습니다. 우리 에이전트는 에이전트 탐색 가이드 에 나온 것처럼 약속된 웹 주소나 사내외 등록 목록, 사전 설정을 통해 이 안내서를 읽고 상대가 견적 산출 기능을 제공하는지 확인합니다.

둘째는 메시지(Message)와 작업(Task)입니다. 구매 에이전트가 품목과 수량을 적어 보내는 요청이나 보충 설명이 메시지입니다. 짧은 질의는 메시지로만 오가기도 하지만 재고 확인과 단가 계산처럼 상태 관리가 필요한 요청은 고유 식별자가 붙은 ‘작업’ 단위로 다룹니다.

셋째는 작업 상태(Task Status)와 결과물(Artifact)입니다. 작업 생애주기 문서 를 보면 요청이 처리 중인지, 추가 입력이 필요한지, 완료되었는지를 상태로 알려 줍니다. 결과물은 작업을 수행하는 과정에서 만들어지거나 조각 단위로 전달되는 산출물입니다. 가상의 구매 시나리오라면 통화, 단가, 세금, 운송비, 유효기간 등이 담긴 견적 문서나 정형 데이터가 바로 이 결과물로 전달됩니다.

여기서 또 다른 표준 규약인 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)와의 차이를 궁금해하시는 분이 많습니다. A2A와 MCP를 비교한 공식 문서 는 두 규약이 서로를 대체하는 것이 아니라 함께 쓰이는 상호보완 관계라고 설명합니다.

비유하자면 MCP는 실무자가 계산기를 두드리거나 창고 장부를 조회하듯 에이전트가 데이터베이스나 API(애플리케이션 프로그래밍 인터페이스), 업무 도구를 연결해 쓰는 규약입니다. 반면 A2A는 독립적으로 판단하고 일하는 다른 에이전트와 협업하는 규약입니다.

이를 두고 MCP는 사내 전용이나 단발성 응답용이고 A2A는 사외 전용이라고 나누면 부정확합니다. 구분 기준은 회사 경계가 아니라 호출 상대의 역할입니다. 한 회사 안에서도 독립된 팀의 에이전트끼리 A2A로 일을 주고받을 수 있습니다. 반대로 협력사의 견적 에이전트가 우리 에이전트의 요청을 A2A로 접수한 뒤, 자기 회사 내부의 재고 데이터베이스와 가격 계산 도구를 호출할 때는 MCP를 쓰는 식으로 두 규약을 자연스럽게 결합할 수 있습니다.

기능을 발견하는 것과 실행을 허락하는 것은 다릅니다

다시 가상의 구매팀 이야기로 돌아가 보겠습니다. 구매팀 에이전트가 협력사 에이전트의 안내서(에이전트 카드)를 확인했더니 ‘포장재 단가 및 납기 견적 산출’ 기능이 적혀 있습니다. 그렇다면 이제 바로 요청을 보내서 일을 처리하면 될까요.

여기서 경영진과 리더는 중요한 원칙 하나를 분명히 해 두어야 합니다. 상대 에이전트가 어떤 기능을 “할 수 있다(capability)“고 안내서에 적어 둔 것과 실제로 그 작업을 “해도 된다(authorization)“고 허락하는 것은 별개의 문제입니다.

우선 에이전트 카드는 모든 공급업체를 자동으로 검색해 신뢰할 수 있는 거래 상대를 골라 주는 보편적 시장이 아닙니다. 이미 검증된 협력사의 주소를 사전에 등록하거나 지정된 목록을 통해 확인해야 합니다.

안내서를 찾은 뒤에도 실제 업무가 오가려면 몇 가지 판단을 분리해야 합니다. 상대가 견적 작성 기능을 제공하는지 확인하는 일과, 접속한 상대가 등록된 협력사인지 검증하는 일, 그리고 현재 요청자가 그 품목과 조건을 조회할 자격이 있는지 판단하는 일입니다. 에이전트 카드는 첫 번째 기능 확인과 접속 설정을 도울 뿐, 그 자체로 실행 권한이 되지는 않습니다. 엔터프라이즈 가이드 에 정리된 것처럼 서버는 구성된 인증 체계와 내부 권한 정책에 따라 호출자의 신원과 실행 자격을 직접 검증해야 합니다.

이와 함께 ‘최소 데이터 공유 원칙’도 반드시 챙겨야 합니다. 구매 담당자가 협력사에 전화를 걸 때는 사내에서 나눈 예산 상한선이나 경쟁사 비교 견적 대화를 그대로 들려주지 않습니다. 에이전트 간 연결에서도 똑같은 기준을 적용해야 합니다.

마이크로소프트의 Copilot Studio 외부 A2A 에이전트 연결 문서 에 수록된 샘플 페이로드를 보면 요청 메타데이터에 사용자의 전체 대화 이력이 포함되는 예시가 나와 있습니다. 물론 모든 A2A 구현체가 똑같은 방식으로 대화 이력을 넘기는 것은 아닙니다. 다만 이 예시는 외부 에이전트로 실제로 어떤 범위의 데이터가 전송되는지 사전에 점검하지 않으면 굳이 밖으로 나갈 필요가 없는 사내 맥락까지 함께 넘어갈 수 있음을 보여 줍니다.

따라서 가상의 구매 견적 흐름을 설계할 때도 내부 예산이나 전체 대화창은 기본 입력에서 제외하고 품목 코드, 수량, 납품 장소, 희망일처럼 합의된 최소 항목만 내보내도록 송신 범위를 제한해야 합니다.

작업 완료 신호가 곧 업무 승인과 거래 성립을 뜻하지는 않습니다

최소 정보만 담아 협력사 에이전트에 견적 요청을 보냈다면 이제 두 에이전트 사이에서 작업이 진행됩니다. 이 단계에서도 프로토콜이 표시하는 상태와 우리 회사의 실제 업무 결정을 구분해야 합니다.

먼저 용어 의미의 차이와 ‘추가 입력 대기’ 상황을 마주칠 수 있습니다. 우리 구매 에이전트가 “친환경 완충재 500개"를 요청했는데 협력사에서는 이 품목을 낱개가 아니라 박스 단위로만 출고할 수 있습니다. 같은 통신 규약을 쓴다고 해서 두 회사가 쓰는 단위의 의미까지 자동으로 맞춰지지는 않습니다.

이때 협력사 에이전트가 포장 단위를 확인해 달라고 요청하면 작업은 ‘추가 입력 대기(input-required)’ 상태로 멈춥니다. 그러면 우리 측 구매 담당자가 박스 기준인지 낱개 기준인지 단위를 정해 같은 작업에 회신해 주어야 다음 계산으로 넘어갈 수 있습니다.

상대 에이전트의 ‘작업 완료(completed)‘와 우리 회사의 ‘업무 수락(acceptance)‘을 구분하는 일은 더 중요합니다. 협력사 에이전트가 단가와 납기를 계산해 견적 결과물을 돌려주면서 작업 상태를 완료로 표시했다고 해 보겠습니다. 프로토콜 관점에서는 해당 작업이 종료된 상태입니다. 종료된 작업은 재개하지 않고 후속 논의가 필요할 때 새 작업을 엽니다.

하지만 상대 에이전트가 완료를 표시한 것과 우리 구매팀이 그 조건을 검수해 받아들이는 것은 전혀 다른 사건입니다. 돌아온 견적 결과물에 통화, 단가, 세금, 운송비, 유효기간, 납기 같은 필수 항목이 제대로 들어 있는지 확인하고 채택 여부를 판단하는 기준은 회사가 직접 세워야 합니다.

또한 이 시나리오에서는 견적을 받아 검토하는 작업이 곧바로 발주 실행으로 이어지지 않도록 분리해야 합니다. 견적 수령과 실제 주문은 다른 업무이므로 발주는 별도로 승인된 절차를 거치도록 설계하는 것이 안전합니다. 계약 성립 여부는 통신 프로토콜이 다루는 범위 밖이기 때문입니다.

지연과 취소 상황도 마찬가지입니다. 네트워크 응답 대기 시간이 지났다는 사실만으로 상대 시스템이 실패했는지는 알 수 없습니다. 작업 취소(cancel) 역시 상대에게 중단을 요청하는 신호일 뿐 이미 발생한 외부 처리까지 자동으로 되돌려 주지는 않습니다. 그러므로 취소 요청이 늦게 도착했을 때 누가 상태를 확인하고 조정할지 미리 정해 두어야 합니다.

현장의 파일럿과 운영 사례가 보여 주는 현실적인 교훈

독립된 에이전트와 업무를 연결할 때 실제로 어떤 점을 챙겨야 하는지는 공개된 기업 간 파일럿과 엔지니어링 운영 보고서에서 구체적으로 살펴볼 수 있습니다.

먼저 북미 식품 유통사 고든 푸드 서비스(Gordon Food Service)와 식품 공급업체 타이슨 푸즈(Tyson Foods)의 시범 협력 사례가 있습니다. 구글 클라우드의 고객 사례 에 따르면 두 회사는 에이전트 개발 키트(ADK)와 A2A를 이용해 상품 검색과 판매 추적을 위한 조직 간 에이전트 협업을 파일럿으로 구현했습니다. 아울러 향후 본운영으로 전환하고 다른 공급업체로 확대할 계획을 제시하고 있습니다. 처음부터 공급망 전체의 거래를 한꺼번에 묶기보다 상품 검색과 판매 추적처럼 경계가 뚜렷한 과제를 골라 기업 간 연결을 시범 검증한 것이죠.

한편 클라우드 데이터 플랫폼 기업 이온(Eon)이 2026년 8월에 발표한 1인칭 운영 엔지니어링 보고서 에는 에이전트 경계를 넘을 때 겪는 실무적 과제가 잘 드러나 있습니다. 이 보고서는 자사 어시스턴트 ‘버즈(Buzz)‘를 운영하면서 얻은 교훈을 다룹니다. 독립된 전문 서비스들과 고객사(테넌트)가 자체 프레임워크로 만들어 제공하는 에이전트를 A2A 경계 너머로 연결한 사례입니다.

비록 기업 간 구매 조달을 구축한 사례는 아니지만 작업이 에이전트 경계를 넘는 순간 무엇이 빠져나가는지를 명확히 보여 줍니다. ‘근거(provenance)와 호출자 신원의 소실’을 가장 큰 문제로 다뤘습니다. 원격 에이전트가 결과만 돌려주면 받는 쪽에서는 그 답변이 얼마나 최신 데이터에 기반했는지, 출처와 신뢰도가 어떠한지 알 수 없었습니다. 원래 누가 요청한 작업인지도 경계 너머로 전달되지 않았습니다. 정답 텍스트만 오가는 것으로는 충분하지 않아 답변과 함께 근거 맥락이 전달되도록 별도의 보완이 필요했습니다.

또한 긴 작업이 게이트웨이 타임아웃에 걸리거나 원격 에이전트의 오류가 경계 너머로 투명하게 전달되지 않을 때, 앞단의 조정 에이전트가 실패 사실을 모른 채 임의로 답을 추측해 내는 문제도 확인되었습니다. 그래서 에이전트를 연결할 때는 정상 응답뿐만 아니라 근거 전달과 오류 가시성까지 함께 설계해야 합니다.

첫 파일럿을 준비할 때 먼저 합의해야 할 다섯 가지 운영 기준

지금까지 살펴본 내용을 바탕으로 독립된 에이전트나 협력사 시스템과 처음 업무 인계를 시도하려는 조직에 다섯 가지 운영 설계 기준을 제안합니다. 보편적으로 실증된 유일한 공식이라기보다 초기 파일럿의 위험을 줄이기 위한 실무적인 출발점입니다.

첫째, 이미 거래 관계가 검증된 협력사 한 곳과 범위가 명확한 단일 업무로 시작하는 것입니다. 처음부터 자동 발주처럼 외부 효력이 발생하는 일을 맡기기보다 상품 사양 확인이나 견적 초안 조회처럼 잘못된 응답이 오더라도 사람이 쉽게 검수할 수 있는 한 가지 업무로 범위를 좁히는 편이 좋습니다.

둘째, 단위와 결과물 양식을 사전에 합의해야 합니다. 품목 코드와 포장 단위, 통화 기준을 맞추고 상대 에이전트가 돌려줄 결과물에 단가, 세금, 운송비, 유효기간, 납기뿐 아니라 기준 시점 같은 근거 항목이 함께 담기도록 약속해야 합니다.

셋째, 외부로 보내는 데이터를 최소한으로 제한해야 합니다. 사내 예산이나 타사 견적, 전체 대화 이력은 제외하고 요청에 꼭 필요한 항목만 전달되도록 송신 범위를 고정해야 합니다.

넷째, 기능 확인과 실제 권한을 분리해야 합니다. 상대 에이전트의 안내서에 여러 기능이 열려 있더라도 파일럿 단계에서는 조회와 견적 요청만 가능하도록 인증 자격과 권한 정책을 설정하고 발주 권한은 부여하지 않는 식입니다.

다섯째, 결과물을 최종 수락하고 예외를 처리할 담당자를 지정해야 합니다. 돌아온 견적을 검수해 채택하고 추가 입력 대기나 지연·취소 예외를 조율할 실무 책임자가 반드시 있어야 합니다. 앞서 Copilot Studio 문서 에서도 외부 에이전트 연결 시 데이터 처리와 권한 경계, 사람의 감독을 사용자가 직접 검토해야 한다고 안내했습니다.

나가며

창구마다 제각각이던 업무 안내서와 접수 번호 형식을 맞추면 두 조직이 대화를 시작하기가 한결 수월해집니다. A2A 역시 서로 다른 환경에서 만들어진 AI 에이전트들이 상대의 기능을 확인하고 작업을 요청하고 진행 상태와 결과물을 주고받는 공통의 형식을 마련해 준다는 점에서 의미 있는 도구입니다.

하지만 대화 형식을 맞췄다고 해서 거래 조건의 의미나 업무 승인 기준까지 저절로 정해지지는 않습니다. 결국 AX(인공지능 전환) 과정에서 에이전트 간 협업의 성패는 연결 기술 그 자체보다 우리 조직의 운영 설계에 달려 있습니다. 누구에게 어떤 범위의 일을 맡기고 어떤 최소 정보만 내보내며 돌아온 결과물을 어떤 기준으로 검수해 수락할 것인가를 정하는 일이죠.

사내의 독립된 에이전트들이나 외부 파트너 시스템과 업무를 어떻게 안전하게 연결할지, 혹은 첫 파일럿의 범위와 권한·검수 절차를 어떻게 설계해야 할지 고민하고 계신다면 언제든 엡실론델타와 상의해 주시기 바랍니다. 현업 업무 흐름 분석부터 에이전트 아키텍처 설계와 운영 기준 수립까지, contact@epsilondelta.ai 로 메일 주시면 여러분의 조직 상황에 맞게 실질적인 해법을 함께 고민하겠습니다.