먼저 '호출'이 아니라 '협업'으로 보기
A2A를 처음 볼 때 가장 흔한 오해는 이것을 또 하나의 API 호출 규칙으로만 이해하는 것이다. 물론 A2A도 네트워크를 통해 요청과 응답을 주고받는다. 그러나 A2A의 핵심 모델은 단순한 함수 호출보다 업무 위임에 가깝다.
일반 API에서는 호출자가 "이 입력을 줄 테니 이 출력을 돌려줘"라고 말한다. 예를 들어 summarize(text) 같은 함수를 부르면 결과 문자열이 돌아온다. 반면 A2A에서는 한 에이전트가 다른 에이전트에게 "이 일을 맡아 줄 수 있나?"라고 요청한다. 상대 에이전트는 즉시 답할 수도 있고, 시간이 걸린다고 말할 수도 있고, 추가 정보가 필요하다고 요청할 수도 있다. 결과가 텍스트 하나가 아니라 문서, 표, 이미지, 파일 묶음일 수도 있다.
그래서 A2A의 기본 단어는 "엔드포인트", "메서드", "응답 코드"보다 먼저 "에이전트", "태스크", "메시지", "산출물"이다. 공식 스펙도 A2A를 서로 독립적이고 때로는 내부가 보이지 않는 AI 에이전트 시스템 사이의 통신과 상호운용을 위한 프로토콜로 설명한다.1
이 관점을 잡아야 뒤에서 나오는 객체들이 자연스럽게 연결된다.
에이전트는 일을 이해하고 처리하는 협업자다.
태스크는 에이전트에게 맡긴 하나의 업무 단위다.
메시지는 업무를 진행하며 오가는 대화 차례다.
Part는 메시지나 산출물을 이루는 내용 조각이다.
산출물은 태스크의 결과로 만들어진 문서, 데이터, 파일 같은 결과물이다.
컨텍스트는 서로 관련된 요청들을 한 묶음으로 보는 업무 폴더다.
공식 스펙은 이들을 더 넓게 데이터 모델, 작업, 프로토콜 바인딩이라는 층으로 나누어 설명한다. 데이터 모델에는 Task, Message, Agent Card, Part, Artifact 같은 객체가 들어가고, 작업에는 메시지 보내기, 태스크 조회, 태스크 취소 같은 행위가 들어간다. 그리고 이 행위들이 JSON-RPC, gRPC, HTTP/REST 같은 구체적인 통신 방식 위에 올라간다. 하지만 처음부터 이 층을 모두 외우려 하기보다, 먼저 "에이전트들이 같은 업무 언어로 협업한다"는 그림을 잡는 편이 훨씬 쉽다.
A2A는 이 단어들을 공통 언어로 만든다. 각 에이전트가 어떤 모델을 쓰는지, 어떤 프레임워크로 만들어졌는지, 내부에서 어떤 도구를 호출하는지는 다를 수 있다. 하지만 밖으로 드러나는 협업 방식은 맞출 수 있다.
AI 생성 이미지
클라이언트와 서버보다 중요한 것: 요청 에이전트와 수행 에이전트
네트워크 프로토콜의 언어로 말하면 A2A에는 요청을 보내는 쪽과 요청을 받는 쪽이 있다. 이를 클라이언트와 서버라고 부를 수 있다. 공식 용어로는 요청을 시작하는 쪽을 A2A Client, A2A 호환 엔드포인트를 노출하고 작업을 처리하는 쪽을 A2A Server 또는 원격 에이전트(Remote Agent)라고 부른다.1 하지만 A2A를 이해할 때는 이보다 에이전트 협업 관점이 더 중요하다.
A2A에서 요청을 보내는 쪽은 보통 클라이언트 에이전트다. 여기서 클라이언트는 단순히 HTTP 요청을 보내는 프로그램이라는 뜻만이 아니다. 사용자의 목표를 이해하고, 필요한 일을 나누고, 적절한 상대에게 맡기는 조율자다. 회사 업무에 비유하면 프로젝트 매니저에 가깝다.
요청을 받는 쪽은 원격 에이전트다. 원격이라는 말은 반드시 다른 지역의 서버라는 뜻이 아니다. 핵심은 "내부를 직접 제어하지 않고, 표준 인터페이스를 통해 협업하는 상대"라는 점이다. 같은 클라우드 안에 있을 수도 있고, 다른 회사의 서비스일 수도 있으며, 같은 애플리케이션 안의 별도 에이전트일 수도 있다.
예를 들어 사용자가 "다음 분기 일본 시장 진출 가능성을 검토해 줘"라고 요청했다고 하자. 클라이언트 에이전트는 이 목표를 다음처럼 나눌 수 있다.
시장 규모를 조사하는 에이전트에게 자료 수집을 맡긴다.
법무 에이전트에게 규제 이슈를 확인하게 한다.
재무 에이전트에게 비용 추정과 손익 시나리오를 요청한다.
마지막으로 보고서 작성 에이전트에게 결과를 종합하게 한다.
이때 클라이언트 에이전트는 모든 원격 에이전트의 내부 프롬프트, 메모리, 도구 목록을 알 필요가 없다. "무엇을 할 수 있는지"와 "어떤 방식으로 일을 요청하고 결과를 받을지"만 알면 된다. 이것이 A2A의 협업 모델이다.
Google이 A2A를 제안할 때 강조한 문제도 여기에 있다. 기업 환경에서는 서로 다른 벤더와 프레임워크로 만든 에이전트가 함께 일해야 한다. A2A는 이런 에이전트들이 내부 구현을 공유하지 않고도 안전하게 협업하도록 만드는 공통 접점으로 설계되었다.2
태스크: A2A에서 일이 흘러가는 중심축
A2A에서 가장 먼저 이해해야 할 객체는 태스크(Task)다. 태스크는 에이전트에게 맡긴 하나의 업무 단위다. 쉽게 말하면 업무 티켓이다. 회사에서 "고객 불만 원인 분석", "계약서 위험 조항 검토", "경쟁사 가격표 정리" 같은 티켓을 만들고 담당자에게 배정하는 것과 비슷하다.
태스크가 중요한 이유는 에이전트 간 협업이 항상 한 번의 응답으로 끝나지 않기 때문이다. 어떤 일은 몇 초 만에 끝난다. 어떤 일은 여러 단계가 필요하다. 어떤 일은 중간에 추가 정보가 필요하다. 어떤 일은 실패하거나 거절될 수도 있다.
일반 채팅 API 호출은 대개 이런 형태다.
사용자가 메시지를 보낸다.
모델이 답변을 돌려준다.
호출은 끝난다.
물론 채팅 API도 대화 기록을 붙여 여러 턴을 만들 수 있다. 하지만 기본 단위는 여전히 "메시지를 넣고 응답을 받는 호출"에 가깝다.
A2A의 태스크 중심 모델은 다르다.
클라이언트 에이전트가 업무를 맡긴다.
원격 에이전트가 필요하면 태스크를 만들고, 단순한 요청이면 직접 메시지로 응답할 수도 있다.
태스크가 만들어졌다면 그 태스크는 진행 상태를 가진다.
필요하면 메시지가 더 오간다.
처리 과정에서 산출물이 추가된다.
마지막에 완료, 실패, 취소, 거절 같은 상태로 끝난다.
여기서 한 가지를 정확히 짚고 가자. A2A는 모든 상호작용을 반드시 태스크로 만들라고 강제하지 않는다. 공식 스펙의 메시지 전송 작업은 결과로 태스크를 돌려줄 수도 있고, 간단한 상호작용이라면 직접 응답 메시지를 돌려줄 수도 있다.1 다만 상태 추적이 필요하고, 오래 걸리고, 중간 결과가 생기고, 추가 입력이 오갈 수 있는 업무라면 태스크가 중심축이 된다.
이 차이는 작아 보이지만 실제 시스템에서는 크다. 태스크가 있으면 "그 일이 지금 어디까지 진행됐는가?"를 물을 수 있다. 중간 결과를 받을 수 있다. 작업이 오래 걸릴 때 비동기적으로 기다릴 수 있다. 같은 업무 안에서 추가 지시를 이어 붙일 수 있다.
예를 들어 "첨부한 50쪽짜리 제안서를 검토하고 위험 요소를 정리해 줘"라는 요청은 단순한 한 줄 답변으로 끝나기 어렵다. 원격 에이전트는 파일을 읽고, 항목을 분류하고, 누락된 정보를 묻고, 최종 검토표를 만들어야 할 수 있다. 이때 태스크는 그 모든 과정을 묶는 업무 단위가 된다.
태스크에는 보통 고유한 id, 현재 상태를 담은 status, 관련 메시지 이력, 그리고 만들어진 산출물이 연결된다. 스펙이나 예제에서 taskId라는 표현을 볼 때도 있지만, 실제 Task 객체 안에서는 보통 id 필드가 업무 티켓 번호 역할을 한다고 이해하면 된다.
메시지: 태스크 안팎에서 오가는 대화 차례
메시지(Message)는 에이전트 사이에서 오가는 하나의 대화 차례다. 메시지는 역할을 가진다. A2A에서 메시지 역할은 크게 user와 agent로 표현된다.1
여기서 user를 반드시 사람으로 이해하면 안 된다. A2A 메시지에서 user 역할은 요청하는 쪽의 발화에 가깝다. 클라이언트 에이전트가 원격 에이전트에게 보내는 지시나 질문이 user 역할의 메시지가 될 수 있다. 반대로 agent 역할은 원격 에이전트가 처리 결과, 질문, 설명을 돌려주는 발화다.
메시지는 태스크와 함께 생각하면 더 이해하기 쉽다. 태스크가 업무 티켓이라면 메시지는 그 티켓에 남기는 댓글이다. 다만 A2A에서는 태스크가 만들어지기 전의 간단한 요청과 응답도 메시지로 표현될 수 있다. 그러므로 메시지는 "태스크 안에서만 존재하는 기록"이라기보다, 클라이언트와 원격 에이전트가 내용을 주고받는 기본 단위라고 보는 편이 정확하다.
예를 들어 다음과 같은 흐름을 생각해 보자.
클라이언트 에이전트가 원격 에이전트에게 "이 계약서를 검토해 줘"라고 메시지를 보낸다.
원격 에이전트는 태스크를 만들고 "검토를 시작했다"고 답한다.
원격 에이전트가 "준거법 정보가 필요하다"고 메시지를 보낸다.
클라이언트 에이전트가 "대한민국 법 기준으로 검토해 달라"고 답한다.
원격 에이전트가 최종 검토 결과를 산출물로 제공한다.
이 과정에서 메시지는 단순한 채팅 기록이 아니다. 태스크를 진행시키는 입력이자, 상태를 설명하는 수단이며, 필요한 정보를 보완하는 통로다.
메시지 안에는 하나 이상의 Part가 들어갈 수 있다. Part는 메시지나 산출물을 구성하는 가장 작은 내용 조각이다. 텍스트일 수도 있고, 파일 참조일 수도 있고, 구조화된 데이터일 수도 있다. 이메일 한 통에 본문, 첨부파일, 표가 함께 들어갈 수 있는 것처럼, A2A 메시지도 여러 종류의 내용을 함께 담을 수 있다.
컨텍스트: 관련된 일을 같은 폴더에 넣기
컨텍스트(Context)는 서로 관련된 태스크와 메시지를 논리적으로 묶는 식별자다. 쉽게 말하면 업무 폴더다.
하나의 사용자 목표가 여러 태스크로 나뉘는 경우가 많다. "일본 시장 진출 보고서 작성"이라는 큰 목표 안에는 시장 조사, 경쟁사 분석, 법률 검토, 재무 추정, 최종 보고서 작성이 들어갈 수 있다. 각각은 별도 태스크일 수 있지만, 모두 같은 목표에 속한다.
컨텍스트는 이런 관련성을 표현한다. 같은 컨텍스트 안에 있는 태스크들은 같은 프로젝트나 같은 대화 흐름에 속한다고 볼 수 있다. 덕분에 클라이언트 에이전트는 여러 원격 에이전트에게 일을 나누어 맡기더라도 전체 목표를 잃지 않는다.
실제 흐름에서는 처음 상호작용할 때 원격 에이전트가 새 컨텍스트 식별자를 알려주고, 이후 클라이언트가 같은 contextId를 포함해 후속 메시지를 보낼 수 있다. 그러면 원격 에이전트는 "이 요청은 앞의 일과 이어지는구나"라고 이해할 수 있다. 물론 어떤 방식으로 컨텍스트를 만들고 유지할지는 구현과 바인딩에 따라 달라질 수 있으므로, 컨텍스트를 에이전트의 내부 기억 그 자체로 보면 안 된다.
컨텍스트 식별자는 "이 일들이 서로 관련되어 있다"는 외부 협업상의 표시다. 원격 에이전트가 내부적으로 어떤 장기 기억을 저장하는지, 어떤 추론 과정을 거치는지는 별개의 문제다. A2A는 그 내부를 직접 열어 보려 하지 않는다.
산출물: 답변이 아니라 결과물
산출물(Artifact)은 태스크의 결과로 만들어진 출력이다. 단순 텍스트 답변도 결과가 될 수 있지만, A2A에서 산출물은 더 넓은 개념이다. 문서, 이미지, JSON 데이터, 표, 코드 파일, 분석 리포트처럼 업무 결과로 남길 수 있는 것이 모두 산출물이 될 수 있다.
태스크와 메시지의 차이를 이해하려면 이 지점을 잘 봐야 한다.
메시지는 진행 중 오가는 말이다. 산출물은 일이 끝나거나 진행되는 과정에서 만들어진 결과물이다.
예를 들어 원격 에이전트가 이렇게 말할 수 있다.
"초안 분석을 완료했습니다. 위험 조항 요약표를 첨부합니다."
여기서 문장 자체는 메시지다. 첨부된 위험 조항 요약표는 산출물이다. 사용자가 실제로 재사용하거나 저장하거나 다음 에이전트에게 넘길 수 있는 결과는 보통 산출물 쪽에 가깝다.
이 구분은 멀티 에이전트 시스템에서 중요하다. 보고서 작성 에이전트는 법무 에이전트의 메시지를 읽기보다, 법무 검토 산출물을 입력으로 받는 편이 더 안정적이다. 재무 에이전트의 중간 설명보다 구조화된 비용 추정표를 받는 것이 다음 단계 처리에 유리하다.
A2A는 산출물을 Part의 묶음으로 표현할 수 있게 한다. 그래서 하나의 산출물이 텍스트 설명과 파일, 구조화 데이터를 함께 포함할 수 있다. 결과를 단순 문자열로 제한하지 않는다는 점이 중요하다.
불투명한 에이전트: 내부를 몰라도 함께 일하기
A2A의 중요한 설계 원칙 중 하나는 불투명한 에이전트(opaque agent)를 전제로 한다는 점이다. 불투명하다는 말은 수상하다는 뜻이 아니다. 내부가 외부에 그대로 보이지 않는다는 뜻이다.
사람과 일할 때도 우리는 상대의 머릿속을 직접 들여다보지 않는다. 변호사에게 계약서 검토를 맡긴다고 해서 그 변호사의 모든 메모, 사고 과정, 사용하는 검색 도구, 사내 지식베이스를 요구하지 않는다. 대신 우리는 전문 분야, 요청 방식, 진행 상태, 최종 의견을 확인한다.
A2A의 에이전트도 비슷하다. 클라이언트 에이전트는 원격 에이전트에게 다음을 기대한다.
어떤 일을 할 수 있는지 알려 줄 것
표준 방식으로 요청을 받을 것
진행 상태를 표현할 것
필요한 정보가 있으면 물어볼 것
결과를 산출물로 돌려줄 것
하지만 다음을 반드시 요구하지는 않는다.
내부 프롬프트 전체
장기 메모리의 내용
사용한 모든 도구의 구현
세부 추론 과정
벤더 고유의 오케스트레이션 로직
공식 스펙은 A2A가 에이전트들이 서로의 내부 상태, 메모리, 도구에 접근하지 않고도 정보를 교환해 사용자 목표를 달성하게 하는 데 목적이 있다고 설명한다.1 이것이 보안과 상호운용성 양쪽에서 중요하다.
내부를 모두 공개해야만 협업할 수 있다면 기업 환경에서는 도입이 어렵다. 각 조직은 데이터 접근 정책, 보안 경계, 독자적인 모델 운영 방식, 도구 체인을 가지고 있다. A2A는 이 내부 차이를 없애려 하지 않는다. 대신 외부 협업 경계를 표준화한다.
기본 흐름 한 번에 보기
지금까지의 개념을 하나의 흐름으로 묶어 보자.
클라이언트 에이전트가 원격 에이전트의 능력을 확인한다.
이때 Agent Card 같은 메타데이터가 사용될 수 있다. Agent Card는 에이전트의 명함에 가깝다. 자세한 구조는 다음 장에서 다룬다.클라이언트 에이전트가 메시지를 보낸다.
메시지에는 요청 내용과 필요한 입력이 담긴다. 텍스트만이 아니라 파일이나 구조화 데이터가 포함될 수 있다.원격 에이전트가 요청을 처리한다.
간단한 요청이면 직접 메시지로 답할 수 있고, 시간이 걸리거나 상태 추적이 필요한 요청이면 태스크를 만들어 관리한다.태스크가 만들어졌다면 진행 중 메시지가 더 오갈 수 있다.
원격 에이전트가 추가 정보를 요청하거나, 클라이언트 에이전트가 지시를 수정할 수 있다.산출물이 만들어진다.
최종 보고서, 분석표, 이미지, 데이터 파일 같은 결과가 태스크에 연결된다.태스크가 종료 상태에 도달한다.
완료될 수도 있고, 실패하거나 취소되거나 거절될 수도 있다. 중요한 것은 상태가 명시적으로 관리된다는 점이다.
이 흐름을 머릿속에 넣고 스펙을 읽으면 각 필드의 의미가 훨씬 분명해진다. 태스크의 id는 업무 티켓 번호다. contextId는 관련 업무를 묶는 폴더 이름에 가깝다. role은 메시지의 발화 방향을 나타낸다. artifact는 재사용 가능한 결과물이다.
A2A의 기본 모델은 복잡한 기술을 감추기 위한 포장지가 아니다. 서로 다른 에이전트가 안전하게 함께 일하기 위해 필요한 최소한의 업무 언어다. 이 언어를 익히면 다음 장에서 Agent Card를 통해 "어떤 에이전트에게 일을 맡길 수 있는가"를 더 구체적으로 살펴볼 수 있다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.