업무 시나리오로 보는 A2A의 가치

프로토콜의 가치는 업무 흐름에서 보인다

A2A의 가치는 명세 문서의 필드 목록만으로는 잘 드러나지 않는다. 실제 가치는 한 부서의 에이전트가 다른 부서나 외부 회사의 에이전트에게 일을 맡기고, 진행 상태를 확인하고, 필요한 승인을 요청하고, 최종 산출물을 다시 업무 시스템에 연결할 때 나타난다.

기업 업무는 보통 한 번의 답변으로 끝나지 않는다. 채용은 후보자 발굴, 일정 조율, 평가, 백그라운드 체크를 거친다. 고객지원은 문의 분류, 지식 검색, 주문 확인, 가격 정책 확인, 환불 승인으로 이어진다. 공급망 업무는 상품 정보, 재고, 판매 리드, 거래 조건을 여러 조직이 나누어 가진다.

이런 흐름에서 A2A는 "모든 일을 한 에이전트가 처리하라"고 요구하지 않는다. 대신 각 에이전트가 자기 전문성과 권한을 유지한 채 서로 협업할 수 있게 한다. 핵심은 세 가지다.

• 적합한 에이전트를 발견한다.

• 업무를 Task로 위임하고 상태를 추적한다.

• 결과를 Artifact로 받아 다음 단계에서 재사용한다.

이제 몇 가지 시나리오로 살펴보자.

AI 생성 이미지

채용 자동화: 한 명의 담당자 뒤에 여러 전문 에이전트가 있다

채용 담당자 에이전트를 생각해 보자. 사용자는 "시니어 데이터 엔지니어 후보자 10명을 찾고, 다음 주 면접 가능 일정을 잡아 줘"라고 말한다. 겉으로는 하나의 요청처럼 보이지만 실제로는 여러 업무가 들어 있다.

첫째, 후보자 소싱 에이전트가 필요하다. 이 에이전트는 채용 공고의 필수 조건, 선호 기술, 지역, 경력 수준을 해석하고 후보자 목록을 만든다. 둘째, 면접 일정 에이전트가 필요하다. 이 에이전트는 면접관 캘린더와 후보자 가능 시간을 비교하고 일정을 제안한다. 셋째, 백그라운드 체크 에이전트가 필요하다. 이 에이전트는 회사 정책에 따라 후보자 동의 여부, 검증 범위, 외부 검증 서비스 호출 조건을 확인한다.

A2A를 사용하면 채용 담당자 에이전트는 각 전문 에이전트의 Agent Card를 보고 무엇을 맡길 수 있는지 판단한다. 후보자 소싱 에이전트에는 "요구 조건에 맞는 후보자 목록 생성" Task를 보낸다. 결과는 이름, 경력 요약, 추천 근거, 다음 단계 가능 여부를 담은 Artifact로 돌아온다.

그다음 면접 일정 에이전트에는 후보자별 가능 일정 조율 Task를 보낸다. 이때 일정 에이전트가 input-required 상태를 반환할 수 있다. 예를 들어 "면접관 A의 대체 가능 여부를 확인해야 한다"거나 "후보자에게 야간 면접 가능 여부를 물어야 한다"는 식이다. 이는 실패가 아니다. 사람의 확인이 필요한 정상적인 대기 상태다.

마지막으로 백그라운드 체크 에이전트는 더 강한 권한과 감사 로그가 필요하다. 채용 담당자 에이전트가 모든 개인정보 처리 권한을 직접 가질 필요는 없다. 백그라운드 체크 에이전트가 자기 정책 안에서 검증 가능 여부를 판단하고, 승인된 범위의 결과만 반환하면 된다. A2A의 장점은 여기서 분명해진다. 협업은 가능하지만 내부 도구, 검증 로직, 민감 데이터 전체를 노출할 필요는 없다.

구매 컨시어지: 학습용 예제로 보는 발견과 위임

Google의 A2A 학습 예제에는 구매 컨시어지와 원격 판매자 에이전트가 등장한다. 사용자는 구매 컨시어지와만 대화한다. 컨시어지는 A2A 클라이언트가 되고, Burger 판매자와 Pizza 판매자는 각각 원격 A2A 서버로 동작한다. 각 판매자 에이전트는 /.well-known/agent.json 위치에 Agent Card를 노출하고, 컨시어지는 이를 읽어 어떤 판매자에게 어떤 요청을 보낼지 결정한다.¹

이 예제가 중요한 이유는 음식 주문 자체가 복잡해서가 아니다. 서로 다른 프레임워크로 만든 에이전트가 같은 업무 흐름에 참여할 수 있음을 보여 주기 때문이다. 예제에서 구매 컨시어지는 Google ADK로, Burger 판매자는 CrewAI로, Pizza 판매자는 LangGraph로 구현된다. 사용자는 "버거와 피자 메뉴를 보여 줘"라고 말하지만, 내부에서는 컨시어지가 두 판매자 에이전트를 발견하고 각각에 A2A 요청을 보낸다.¹

이 흐름은 기업 업무에도 그대로 확장된다. 구매 컨시어지는 사내 구매 포털이 될 수 있고, Burger와 Pizza 판매자는 실제 공급업체의 견적 에이전트가 될 수 있다. 한 공급업체는 즉시 주문을 받을 수 있고, 다른 공급업체는 재고 확인이나 승인 때문에 추가 확인을 요구할 수 있다. A2A는 이런 차이를 하나의 거대한 통합 API로 숨기지 않는다. 대신 각 판매자 에이전트가 자신의 상태와 요구사항을 표준 방식으로 표현하게 한다.

실무에서 중요한 것은 "누가 최종 주문 권한을 갖는가"다. 컨시어지가 메뉴 조회만 할 수 있는지, 장바구니 구성까지 할 수 있는지, 실제 결제와 발주까지 할 수 있는지는 별도 정책으로 정해야 한다. A2A는 요청과 상태를 주고받는 방식을 제공하지만, 회사의 구매 승인 규칙을 대신 정해 주지는 않는다.

고객지원: 답변 생성보다 중요한 것은 책임 있는 조율이다

고객지원 에이전트는 A2A가 특히 잘 맞는 영역이다. 고객 문의는 단순 FAQ로 끝나지 않는 경우가 많다. 예를 들어 고객이 "지난주 주문이 아직 도착하지 않았고, 할인 적용도 잘못된 것 같습니다. 환불 가능한가요?"라고 묻는다고 하자.

하나의 고객지원 에이전트가 모든 시스템 권한을 갖는 방식은 위험하다. 대신 고객지원 에이전트가 조율자 역할을 맡고, 다음 에이전트들과 협업하는 구조가 더 안전하다.

• 지식 검색 에이전트: 배송 지연, 할인 정책, 환불 규정 문서를 찾는다.

• 가격 정책 에이전트: 고객 등급, 프로모션 기간, 쿠폰 적용 가능성을 확인한다.

• 주문 상태 에이전트: 주문 번호, 배송사, 현재 위치, 지연 사유를 조회한다.

• 환불 승인 에이전트: 환불 가능 여부와 승인 한도를 판단한다.

이 구조에서 고객지원 에이전트는 고객과 대화하는 단일 접점이다. 하지만 실제 판단은 전문 에이전트에게 위임한다. 주문 상태 에이전트는 배송 데이터에 접근할 수 있지만 가격 정책을 바꾸지는 못한다. 환불 승인 에이전트는 환불 권한을 갖지만 고객 응대 문구를 직접 작성하지 않을 수 있다.

A2A의 Task 모델은 이 흐름을 추적 가능하게 만든다. 고객지원 에이전트는 각 하위 Task의 상태를 확인한다. 주문 조회가 완료되었는지, 가격 검토가 추가 입력을 요구하는지, 환불 승인이 거절되었는지 구분할 수 있다. 최종 답변은 단순한 자연어 문장이 아니라 여러 Artifact를 바탕으로 만들어진다. 배송 상태 JSON, 정책 근거 요약, 환불 승인 결과가 함께 남으면 나중에 감사와 품질 평가가 가능하다.

이런 구조는 고객 경험에도 영향을 준다. 고객에게 "확인 중입니다"라고만 말하는 대신, "배송 상태는 확인되었고, 현재 할인 정책 검토가 진행 중입니다"처럼 더 정확한 진행 상황을 알려 줄 수 있다. 단, 모든 내부 상태를 고객에게 노출해야 한다는 뜻은 아니다. 외부에 보여 줄 상태와 내부 감사용 상태는 구분해야 한다.

공급망 협업: 회사 경계를 넘는 에이전트 상호작용

A2A의 더 큰 가능성은 회사 경계를 넘을 때 드러난다. Google Cloud의 Gordon Food Service 사례는 Tyson Foods, Google Cloud와 함께 상품 검색과 영업 추적을 위한 조직 간 에이전트 협업 파일럿을 다룬다. 이 사례에서 ADK는 에이전트를 만드는 데 사용되고, A2A는 서로 다른 회사의 에이전트가 내부 구현을 노출하지 않고 안전하게 상호운용하도록 돕는 역할을 맡았다.²

공급망에서는 정보가 한곳에 모여 있지 않다. 제조사는 상품 속성, 대체 상품, 공급 가능량, 신제품 정보를 갖고 있다. 유통사는 고객 수요, 영업 기회, 지역별 판매 흐름을 갖고 있다. 양쪽이 모든 시스템을 직접 연결하려 하면 통합 범위가 빠르게 커지고, 보안 검토도 복잡해진다.

A2A 기반 접근은 다르다. 제조사 에이전트는 "이 조건에 맞는 상품을 찾아 달라"는 요청에 답하고, 유통사 에이전트는 "이 고객군에 제안할 수 있는 상품 후보가 있는가"를 묻는다. 각 회사는 자기 내부 데이터와 도구를 계속 통제한다. 상대에게 필요한 것은 내부 데이터베이스 접속권이 아니라, 표준화된 요청과 응답, 그리고 신뢰할 수 있는 결과다.

Google은 A2A 기반 협업 시스템이 Tyson Foods와 Gordon Food Service 사이에서 상품 데이터와 영업 리드를 실시간으로 공유하는 채널을 만들고, 공급망 마찰을 줄이는 방식으로 활용될 수 있다고 설명한다.³ 여기서 중요한 표현은 "실시간 공유"보다 "통제된 공유"다. 어떤 상품 정보를 공유할지, 어떤 리드를 어느 범위까지 전달할지, 어떤 결과를 영업 시스템에 기록할지는 각 조직의 정책으로 관리되어야 한다.

이 패턴은 식품 유통에만 머물지 않는다. 제조와 유통, 보험사와 병원, 금융사와 외부 심사 기관, 여행사와 항공·호텔 공급자 사이에도 비슷한 구조가 가능하다. A2A는 회사 간 업무를 하나의 중앙 시스템으로 합치지 않고도 협업할 수 있는 연결 방식을 제공한다.

지연 시간을 고려한 에이전트 선택

모든 에이전트가 같은 품질과 속도를 제공하지는 않는다. 특히 음성 상담, 실시간 채팅, IVR 같은 고객 접점에서는 몇 초의 지연도 경험을 크게 바꾼다. 이때는 "기능을 수행할 수 있는가"뿐 아니라 "지금 이 상황에서 충분히 빠른가"도 선택 기준이 된다.

Twilio는 A2A Agent Card 확장을 사용해 원격 에이전트의 예상 지연 시간을 노출하는 패턴을 제시했다. 예를 들어 특정 skill에 대해 최소·최대 지연 시간이나 p50, p95, p99 같은 지연 시간 백분위 값을 Agent Card에 담을 수 있다. 클라이언트 에이전트는 사용자의 요청과 실시간 응답 요구 수준을 비교해 가장 적합한 원격 에이전트로 라우팅한다.⁴

이 방식은 Agent Card를 단순한 소개서가 아니라 라우팅 판단의 입력으로 활용한다는 점에서 중요하다. 고객이 전화로 "주문 상태를 알려 달라"고 말했을 때, 시스템은 주문 조회 skill을 가진 에이전트 중 응답 지연이 가장 낮은 에이전트를 선택할 수 있다. 반대로 정확도는 높지만 처리 시간이 긴 에이전트를 선택해야 한다면, 고객에게 대기 안내를 재생하거나 비동기 후속 알림으로 전환할 수 있다.

이런 확장 정보는 지연 시간에만 한정되지 않는다. 비용, 지원 언어, 지역, 데이터 보관 위치, 규제 등급, 현재 부하 상태도 라우팅 기준이 될 수 있다. 다만 확장 정보가 많아질수록 거버넌스가 필요하다. 어떤 필드를 표준으로 인정할지, 누가 값을 검증할지, 잘못된 지연 시간 광고를 어떻게 탐지할지 정해야 한다.

좋은 시나리오는 역할과 경계를 분명히 한다

A2A 시나리오를 설계할 때 먼저 물어야 할 질문은 "어떤 에이전트를 만들 수 있는가"가 아니다. "이 업무에서 책임이 나뉘는 지점은 어디인가"다.

채용에서는 후보자 발굴, 일정 조율, 검증이 나뉜다. 고객지원에서는 지식 검색, 주문 조회, 가격 판단, 환불 승인이 나뉜다. 공급망에서는 제조사와 유통사의 데이터 소유권이 나뉜다. 실시간 상담에서는 같은 기능을 가진 에이전트 중 응답 시간과 품질에 따라 선택이 나뉜다.

A2A는 이 경계를 없애지 않는다. 오히려 경계를 유지한 채 협업하게 한다. 이것이 실무에서의 가치다. 각 에이전트는 자신이 잘하는 일을 하고, 다른 에이전트는 그 결과를 신뢰 가능한 업무 단위로 받아 다음 단계에 사용한다.

따라서 성공적인 A2A 도입은 프로토콜 구현만으로 끝나지 않는다. Agent Card를 정확히 관리해야 하고, Task 상태를 업무 언어로 설계해야 하며, Artifact가 다음 시스템에서 재사용 가능한 구조를 가져야 한다. 또한 인증, 승인, 감사 로그, 품질 평가가 함께 준비되어야 한다.

A2A는 기업 업무를 자동으로 단순하게 만들지 않는다. 하지만 복잡한 업무를 여러 전문 에이전트가 나누어 처리할 수 있는 공통 방식을 제공한다. 그 차이가 중요하다. 프로토콜의 진짜 가치는 명세의 아름다움이 아니라, 부서와 시스템과 회사의 경계를 가로지르는 업무가 끊기지 않고 이어질 때 드러난다.

참고

¹Agent2Agent (A2A) 프로토콜 시작하기: Cloud Run 및 Agent Engine에서 구매 컨시어지와 원격 판매자 에이전트 상호작용

²Gordon Food Service case study

³Announcing a complete developer toolkit for scaling A2A agents on Google Cloud

⁴Latency Extension for A2A: Optimizing Agent Routing for Real-Time Communications