설계 원칙으로 읽는 A2A

원칙을 알면 구조가 보인다

프로토콜은 단순한 메시지 형식의 묶음이 아니다. 어떤 문제를 중요하게 보았는지, 어떤 위험을 피하려 했는지, 어떤 환경에서 오래 쓰이도록 만들었는지가 구조에 남는다. A2A도 마찬가지다.

앞 장에서는 A2A가 에이전트의 내부 추론 방식이나 도구 호출 방식을 표준화하지 않는다고 보았다. 이번 장의 질문은 한 걸음 더 들어간다. 왜 A2A는 에이전트를 함수처럼 호출하지 않고, 작업 상태와 산출물, 스트리밍, 인증, 발견 정보를 함께 다루는가?

답은 설계 원칙에 있다. A2A는 서로 다른 에이전트가 기업 환경에서 협업할 때 필요한 최소한의 공통 바닥을 만들려 한다. 그 바닥은 다섯 방향으로 정리할 수 있다. 에이전트를 협업 주체로 인정하기, 기존 표준을 재사용하기, 비동기 작업을 기본값으로 삼기, 콘텐츠 형식에 중립적이기, 엔터프라이즈 보안과 운영을 처음부터 전제하기다.

AI 생성 이미지

에이전트를 단순 도구로 보지 않는다

가장 중요한 원칙은 에이전트를 단순한 도구로 축소하지 않는다는 점이다. 도구는 보통 입력을 받고 결과를 돌려준다. "이 문서를 요약해 줘", "이 고객 번호로 주문 내역을 조회해 줘"처럼 요청과 응답의 경계가 비교적 선명하다.

하지만 에이전트는 그보다 넓은 역할을 맡는다. 목표를 해석하고, 필요한 정보를 추가로 요청하고, 중간 상태를 설명하고, 실패하면 이유를 알리고, 때로는 사람의 승인을 기다린다. 예를 들어 구매 에이전트가 공급망 에이전트에게 "이 부품을 다음 달까지 확보할 수 있는지 확인해 달라"고 요청한다고 하자. 공급망 에이전트는 단순 재고 조회만 하지 않는다. 대체 공급처를 확인하고, 리드타임을 비교하고, 특정 조건에서는 구매 담당자의 승인이 필요하다고 판단할 수 있다.

A2A가 에이전트를 협업 주체로 다룬다는 말은, 상대 에이전트의 내부 사고 과정을 모두 들여다본다는 뜻이 아니다. 오히려 반대에 가깝다. 최신 명세는 독립적이고 때로는 내부가 불투명한 에이전트들이 서로의 메모리, 내부 상태, 도구 구현을 공유하지 않고도 협업할 수 있게 하는 것을 목표로 한다고 설명한다.¹

이 원칙은 기업 환경에서 특히 중요하다. 각 부서의 에이전트는 다른 권한, 다른 데이터, 다른 정책 아래에서 동작한다. 모든 것을 공개해야만 협업할 수 있다면 실제 도입은 어려워진다. A2A는 에이전트가 자신이 할 수 있는 능력과 필요한 입력, 진행 상태, 결과를 표현하게 하되 내부 구현은 캡슐화한다. 그래서 협업은 가능하게 만들고, 불필요한 노출은 줄인다.

이미 검증된 표준 위에 쌓는다

두 번째 원칙은 새 전송 체계를 발명하지 않는 것이다. A2A는 HTTP, JSON-RPC 2.0, Server-Sent Events 같은 널리 쓰이는 웹 표준을 재사용한다. 최신 명세에서도 프로토콜 바인딩 계층에 JSON-RPC, gRPC, HTTP+JSON/REST 같은 방식을 포함한다.¹

이 선택은 개발자 편의만을 위한 것이 아니다. 기업 IT 환경에는 이미 API 게이트웨이, 로드 밸런서, 인증 프록시, 방화벽, 로깅 시스템, 모니터링 도구가 있다. 프로토콜이 기존 표준 위에서 움직이면 이 인프라에 자연스럽게 들어갈 수 있다.

예를 들어 JSON-RPC는 구조화된 원격 호출을 표현하기 쉽다. HTTP는 기업 네트워크에서 가장 익숙한 통신 기반이다. Server-Sent Events는 서버가 클라이언트로 진행 상황을 흘려보내는 데 적합하다. gRPC는 서비스 간 통신이 많은 클라우드 네이티브 환경에서 낮은 지연 시간과 명확한 인터페이스를 제공하는 방식으로 활용될 수 있다.

여기서 중요한 점은 A2A가 특정 기술 하나만 강제하지 않는다는 것이다. 프로토콜의 중심에는 데이터 모델과 작업 의미가 있고, 전송 방식은 그것을 실어 나르는 바인딩으로 분리된다. 이는 여러 언어, 프레임워크, 클라우드 환경에서 A2A를 구현하기 쉽게 만든다. Google이 주도했지만 A2A가 특정 Google Cloud 서비스에 종속되지 않는 이유도 여기에 있다.

장시간 작업을 기본으로 생각한다

세 번째 원칙은 비동기 우선이다. 일반적인 API 호출은 짧은 시간 안에 끝나는 요청을 전제로 한다. 요청을 보내고, 응답을 받고, 연결을 닫는다. 그러나 에이전트 협업은 그렇게 단순하지 않다.

견적 비교, 계약 검토, 장애 원인 분석, 보안 승인, 대량 데이터 정리 같은 일은 몇 초 안에 끝나지 않을 수 있다. 중간에 다른 시스템을 조회해야 하고, 사람이 결정을 내려야 하며, 외부 파트너의 응답을 기다려야 할 수도 있다. Google의 A2A 발표에서도 짧은 작업뿐 아니라 몇 시간 또는 며칠에 걸친 작업, 실시간 피드백, 알림, 상태 업데이트를 지원하는 것이 핵심 원칙으로 제시되었다.²

그래서 A2A에서 작업은 단순 응답이 아니라 상태를 가진 단위로 다뤄진다. 요청은 즉시 최종 결과를 돌려주지 않을 수 있다. 대신 작업이 생성되고, 진행 중 상태가 전달되며, 산출물이 단계적으로 추가될 수 있다. 스트리밍 연결을 통해 상태 변화나 산출물 업데이트를 받을 수도 있고, 연결이 끊긴 상황에서는 나중에 작업 상태를 다시 조회하거나 알림을 받을 수 있다.

이 설계는 휴먼 인 더 루프(Human-in-the-loop), 즉 사람이 중간 의사결정에 참여하는 흐름과도 잘 맞는다. 예를 들어 재무 에이전트가 예산 초과 구매 요청을 검토하다가 "관리자 승인 필요" 상태로 작업을 멈출 수 있다. 이때 A2A의 역할은 승인을 대신 내리는 것이 아니다. 현재 작업이 왜 멈췄는지, 어떤 입력이 필요한지, 이후 어떤 상태로 이어질 수 있는지를 공통 방식으로 표현하게 하는 것이다.

콘텐츠 형식에 중립적이다

네 번째 원칙은 모달리티 중립성이다. 모달리티(Modality)는 정보가 표현되는 형식을 뜻한다. 텍스트, 표, 이미지, 오디오, 비디오, 파일, 양식 데이터가 모두 모달리티의 예다.

초기 챗봇 경험에 익숙하면 에이전트 간 대화를 텍스트 메시지로만 생각하기 쉽다. 그러나 실제 업무에서는 텍스트만으로 부족한 경우가 많다. 보험 심사 에이전트는 사고 사진이나 PDF 문서를 다뤄야 한다. 제조 품질 에이전트는 센서 데이터와 검사 영상을 참조해야 한다. 고객지원 에이전트는 통화 녹취, 상담 요약, 환불 신청 양식을 함께 전달해야 할 수 있다.

A2A는 메시지를 단일 문자열로 고정하지 않는다. 메시지와 산출물은 여러 부분으로 구성될 수 있고, 각 부분은 텍스트일 수도, 구조화 데이터일 수도, 파일 참조일 수도 있다. 최신 명세는 텍스트뿐 아니라 파일 참조를 통한 오디오·비디오, 구조화 데이터와 폼, 잠재적인 임베디드 UI 구성 요소까지 고려한다.¹

이 원칙은 앞으로의 에이전트 경험을 위해 중요하다. 사용자는 항상 채팅창에서만 일하지 않는다. 때로는 승인 버튼이 있는 카드가 필요하고, 때로는 수정 가능한 양식이 필요하며, 때로는 보고서 파일 자체가 결과가 된다. A2A가 모달리티를 특정 형식으로 제한하지 않으면, 에이전트는 업무 맥락에 맞는 산출물을 더 자연스럽게 교환할 수 있다.

다만 모달리티 중립성이 모든 파일 처리 방식을 표준화한다는 뜻은 아니다. A2A는 콘텐츠를 어떻게 표현하고 참조할 수 있는지의 공통 틀을 제공한다. 파일 저장소, 미디어 처리 파이프라인, 보존 정책, 바이러스 검사 같은 세부 운영은 각 조직의 인프라와 정책에 따라 설계해야 한다.

보안과 운영은 나중에 붙이는 기능이 아니다

다섯 번째 원칙은 엔터프라이즈 준비성이다. 기업에서 에이전트는 단순 자동응답 프로그램이 아니다. 고객 정보에 접근하고, 주문을 변경하고, 비용을 발생시키며, 규제 대상 데이터를 다룰 수 있다. 따라서 "일단 연결한 뒤 보안은 나중에 붙인다"는 접근은 위험하다.

A2A는 인증(Authentication), 인가(Authorization), 보안, 개인정보 보호, 추적, 모니터링을 기본 전제로 둔다.¹ 인증은 상대가 누구인지 확인하는 절차다. 인가는 확인된 주체가 어떤 작업을 할 수 있는지 판단하는 절차다. 추적과 모니터링은 누가 어떤 요청을 했고, 작업이 어디에서 지연되었으며, 어떤 결과로 끝났는지 운영자가 확인할 수 있게 하는 기반이다.

다중 에이전트 환경에서는 이 전제가 더 중요하다. 하나의 요청이 여러 에이전트를 거쳐 처리되면 책임 경계가 흐려질 수 있다. 고객지원 에이전트가 환불 가능성을 묻고, 주문 에이전트가 결제 정보를 확인하며, 재무 에이전트가 최종 승인 조건을 판단한다고 하자. 문제가 생겼을 때 어느 에이전트가 어떤 근거로 어떤 행동을 했는지 추적할 수 있어야 한다.

A2A의 보안 원칙은 모든 보안 문제를 프로토콜 하나로 해결한다는 뜻이 아니다. 키 관리, 네트워크 격리, 데이터 분류, 감사 로그 보존, 접근 정책은 여전히 조직이 책임져야 한다. 그러나 프로토콜이 보안과 운영을 기본 요구사항으로 인정하면 구현체와 플랫폼은 그 요구에 맞춰 설계될 가능성이 높아진다. 이것이 실험용 데모와 운영 환경의 차이다.

다섯 원칙이 만드는 하나의 방향

다섯 원칙은 따로 움직이지 않는다. 에이전트를 협업 주체로 인정하기 때문에 내부 실행을 모두 공개하지 않는 불투명 실행이 필요하다. 장시간 작업을 다루기 때문에 작업 상태, 스트리밍, 알림이 중요해진다. 다양한 업무 산출물을 다루기 때문에 텍스트를 넘어선 모달리티 중립성이 필요하다. 기업 환경에 들어가야 하므로 기존 웹 표준과 보안·관측 가능성 체계를 재사용해야 한다.

이 관점으로 보면 A2A의 세부 구조는 임의의 선택이 아니다. Agent Card는 상대가 누구이고 무엇을 할 수 있는지 발견하기 위한 장치다. Task는 긴 업무를 상태와 함께 관리하기 위한 단위다. Message, Part, Artifact는 다양한 입력과 산출물을 담기 위한 구조다. JSON-RPC, HTTP, SSE, gRPC 같은 바인딩은 기존 인프라와 연결되기 위한 통로다.

A2A의 철학은 거대한 단일 에이전트를 만드는 데 있지 않다. 각 에이전트가 자신의 전문성, 권한, 내부 구현을 유지한 채 협업할 수 있는 공통 방식을 만드는 데 있다. 이 원칙을 이해하면 다음 장에서 다룰 기본 등장인물과 객체 모델이 훨씬 자연스럽게 보인다.

참고

¹A2A Protocol 최신 명세

²Google Developers Blog의 A2A 발표