A2A의 기본 등장인물과 객체 모델

A2A를 이해할 때 처음부터 메서드 이름이나 전송 방식으로 들어가면 흐름을 놓치기 쉽다. 먼저 봐야 할 것은 "누가 누구에게 무엇을 맡기고, 그 과정이 어떤 객체로 기록되는가"이다.

A2A의 대화는 단순한 문자열 교환이 아니다. 요청자, 처리자, 에이전트 소개 문서, 작업 단위, 메시지, 콘텐츠 조각, 산출물이 함께 움직인다. 이 장에서는 A2A 상호작용을 구성하는 기본 등장인물과 객체 모델을 한 번에 정리한다.

AI 생성 이미지

두 역할: 요청하는 쪽과 처리하는 쪽

A2A 상호작용의 출발점에는 A2A Client가 있다. A2A Client는 사용자나 다른 시스템을 대신해 원격 에이전트에게 작업을 요청하는 쪽이다. 여기서 Client는 반드시 사람이 보는 채팅 화면일 필요가 없다. 기업 포털, 업무 자동화 서버, 오케스트레이션 에이전트, 또는 다른 전문 에이전트가 모두 A2A Client가 될 수 있다.

Client의 역할은 크게 네 가지다.

• 어떤 원격 에이전트가 적합한지 찾는다.

• 요청을 A2A 형식의 Message로 만든다.

• 장기 실행 작업이라면 Task ID를 보관하고 상태를 추적한다.

• 추가 입력, 승인 요청, 실패, 최종 산출물을 사용자나 상위 시스템에 전달한다.

반대편에는 A2A Server 또는 Remote Agent가 있다. A2A Server는 A2A 요청을 받는 서버 측 인터페이스이고, Remote Agent는 그 뒤에서 실제 업무를 처리하는 에이전트 애플리케이션이다. 실무에서는 둘을 엄격히 구분하기보다 "A2A로 호출 가능한 원격 에이전트"라는 의미로 함께 이해해도 된다.

중요한 점은 Remote Agent가 내부 구현을 노출하지 않는다는 것이다. 어떤 모델을 쓰는지, 어떤 프롬프트를 사용하는지, MCP로 어떤 도구에 연결되는지, 내부 워크플로가 그래프인지 코드인지까지 Client가 알 필요는 없다. Remote Agent는 자신이 제공할 수 있는 능력과 호출 방식, 진행 상태, 결과를 A2A 객체로 표현하면 된다. 이것이 앞 장에서 본 불투명 실행의 실제 형태다.

Agent Card: 호출하기 전에 읽는 자기소개서

Client가 원격 에이전트에게 바로 요청을 보내려면 먼저 "그 에이전트가 무엇을 할 수 있는지" 알아야 한다. 이때 사용하는 객체가 Agent Card다.

Agent Card는 A2A Server가 공개하는 기계 판독 가능한 메타데이터 문서다. 사람을 위한 홍보 문구가 아니라, 다른 에이전트나 시스템이 읽고 판단하기 위한 소개서에 가깝다. A2A의 표준 객체 모델에는 Agent Card, Task, Message, Part, Artifact 같은 핵심 객체가 포함되며, Agent Card는 그중 발견과 선택을 담당한다¹.

Agent Card에는 보통 다음 정보가 담긴다.

예를 들어 구매 업무를 담당하는 Client Agent가 "공급업체 리스크 평가"를 수행할 에이전트를 찾는다고 하자. Agent Card를 보면 어떤 Remote Agent가 재무 건전성 분석을 지원하는지, 어떤 형식의 공급업체 정보를 받아야 하는지, 결과를 보고서로 주는지 구조화 데이터로 주는지 판단할 수 있다.

Agent Card는 계약서와도 닮았다. 단, 법적 계약서처럼 모든 실행 결과를 보장하는 문서는 아니다. "이 에이전트는 이런 방식으로 호출할 수 있고, 이런 종류의 작업을 처리하도록 설계되어 있다"는 호출 전 합의에 가깝다. 실제 요청은 권한, 입력 품질, 정책, 실행 상태에 따라 거절되거나 추가 입력을 요구할 수 있다.

Task: 상태를 가진 작업 단위

A2A에서 가장 중요한 실행 단위는 Task다. Task는 고유 ID를 가진 작업 객체이며, 한 번의 요청으로 끝나지 않는 업무를 추적하기 위해 사용된다.

간단한 질문은 즉시 Message로 답할 수 있다. 예를 들어 "이 에이전트가 PDF를 처리할 수 있나요?" 같은 요청은 별도의 장기 작업이 필요하지 않을 수 있다. 그러나 "지난 12개월의 거래 내역을 분석해 공급업체 리스크 보고서를 작성해 주세요"라는 요청은 다르다. 시간이 걸리고, 중간에 추가 자료가 필요할 수 있으며, 최종 산출물도 여러 개일 수 있다. 이런 경우 Task가 필요하다.

Task는 다음 질문에 답한다.

• 이 작업의 ID는 무엇인가?

• 지금 어떤 상태인가?

• 어떤 메시지들이 이 작업과 관련되어 있는가?

• 추가 입력이나 인증이 필요한가?

• 완료되었다면 어떤 산출물이 생성되었는가?

• 실패했다면 어떤 이유로 실패했는가?

A2A의 Task 생명주기에서는 즉시 끝나는 무상태 Message와, 시간이 걸리는 상태 기반 Task를 구분한다. Task는 진행 중에 입력 필요, 인증 필요 같은 중단 상태에 놓일 수 있고, 완료, 취소, 거절, 실패 같은 종료 상태에 도달할 수 있다².

이 구조가 중요한 이유는 기업 업무가 자주 끊기기 때문이다. 파일 권한이 부족할 수 있고, 결재자가 승인해야 할 수 있으며, 고객 정보가 누락될 수도 있다. Task가 없다면 Client는 "요청을 보냈다"는 사실만 알 뿐, 일이 어디까지 진행되었는지 안정적으로 알기 어렵다.

또 하나의 중요한 개념은 contextId다. contextId는 여러 Task와 Message를 하나의 논리적 대화 맥락으로 묶는 식별자다. 예를 들어 첫 번째 Task에서 기본 보고서를 만들고, 이어서 "이 보고서를 임원용 한 페이지 요약으로 다시 만들어 달라"고 요청할 수 있다. 이미 완료된 Task를 되살리는 것이 아니라, 같은 contextId 안에서 새 Task를 만들어 후속 작업을 수행하는 방식이 자연스럽다.

Message: 대화의 한 턴

Message는 Client와 Remote Agent 사이에서 오가는 대화의 한 턴이다. Message에는 역할이 있다. 보통 요청자 쪽의 Message는 user 역할, 원격 에이전트 쪽의 Message는 agent 역할로 표현된다. 여기서 user는 반드시 실제 사람이 아니라 Client 측 요청자를 뜻한다고 이해하면 된다.

Message는 단순한 텍스트 한 줄이 아니다. Message는 하나 이상의 Part를 포함한다. 이 덕분에 하나의 요청 안에 지시문, 구조화 데이터, 파일 참조를 함께 담을 수 있다.

예를 들어 Client가 다음과 같은 요청을 보낼 수 있다.

{
  "role": "user",
  "parts": [
    { "kind": "text", "text": "다음 공급업체의 리스크를 평가해 주세요." },
    { "kind": "data", "data": { "supplierId": "S-2041", "region": "KR" } },
    { "kind": "file", "uri": "gs://bucket/contracts/s-2041.pdf" }
  ]
}

이 예시는 개념을 보여주기 위한 단순화된 형태다. 핵심은 Message가 "말"이고, 그 말은 여러 조각으로 구성될 수 있다는 점이다. Remote Agent도 Message로 답할 수 있다. 예를 들어 "계약서 파일에는 접근할 수 있지만 최근 재무제표가 필요합니다"라고 추가 입력을 요청할 수 있다.

Message는 Task와 결합될 수도 있고, 독립적으로 오갈 수도 있다. 가벼운 질의응답은 Message만으로 끝날 수 있다. 반면 실행과 추적이 필요한 업무는 Message가 Task를 시작하거나, Task 진행 중에 추가 입력을 주고받는 수단이 된다.

Part: 내용을 쪼개 담는 최소 단위

Part는 Message나 Artifact 안에 들어가는 콘텐츠의 최소 단위다. A2A가 Part를 두는 이유는 에이전트 간 협업에서 주고받는 정보가 텍스트만이 아니기 때문이다.

Part는 다음과 같은 내용을 담을 수 있다.

• 자연어 지시문

• JSON 같은 구조화 데이터

• 파일 본문 또는 파일 참조

• 이미지, 문서, 표와 같은 다양한 형식의 데이터

• 특정 업무 화면이나 폼을 구성하는 정보

텍스트만 주고받는 시스템에서는 "프롬프트 문자열" 하나면 충분해 보일 수 있다. 그러나 실제 업무 요청은 대개 복합적이다. "이 계약서를 읽고", "첨부한 거래 내역을 기준으로", "아래 정책 JSON을 적용해", "결과는 표와 요약문으로 달라"처럼 여러 자료와 지시가 함께 온다.

Part는 이런 복합 요청을 무리하게 하나의 문자열로 합치지 않게 해준다. 텍스트는 텍스트로, 파일은 파일로, 구조화 데이터는 구조화 데이터로 분리된다. 덕분에 Remote Agent는 각 Part의 의미를 더 명확히 해석할 수 있고, Client는 어떤 자료가 요청에 포함되었는지 추적하기 쉽다.

Artifact: 작업의 산출물

Artifact는 Task 수행 과정이나 완료 결과로 생성되는 산출물이다. 보고서, 이미지, PDF 파일, 표, JSON 결과, 코드 패치, 분석 요약 등이 Artifact가 될 수 있다. Artifact도 Part들로 구성될 수 있다.

Message와 Artifact는 비슷해 보이지만 역할이 다르다.

예를 들어 Remote Agent가 공급업체 리스크 분석 Task를 완료하면 다음과 같은 Artifact를 만들 수 있다.

• 임원 보고서 PDF

• 리스크 점수와 근거가 담긴 JSON 데이터

• 원본 데이터 품질 경고 목록

• 후속 검토가 필요한 항목 리스트

이 산출물들은 단순한 채팅 답변보다 오래 보존될 필요가 있다. 다른 시스템이 다운로드하거나, 승인 프로세스에 첨부하거나, 다음 Task의 입력으로 사용할 수 있기 때문이다. 그래서 A2A는 결과를 Message 안의 텍스트 답변으로만 다루지 않고 Artifact라는 별도 객체로 표현한다.

하나의 흐름으로 보면

지금까지의 객체를 하나의 시나리오로 묶어 보자.

1. 구매 오케스트레이션 에이전트가 A2A Client 역할을 한다.

2. Client는 여러 Agent Card를 읽고, 공급업체 리스크 평가에 맞는 Remote Agent를 선택한다.

3. Client는 공급업체 ID, 계약서 파일, 평가 기준을 담은 Message를 보낸다.

4. Remote Agent는 이 요청이 장기 실행 작업이라고 판단하고 Task를 생성해 ID와 상태를 반환한다.

5. 처리 중 재무제표가 부족하면 Remote Agent는 Message로 추가 입력을 요청한다.

6. Client는 같은 Task 또는 같은 contextId를 사용해 필요한 자료를 다시 보낸다.

7. Remote Agent는 작업을 완료하고 PDF 보고서와 구조화된 리스크 점수를 Artifact로 제공한다.

8. Client는 Task 상태와 Artifact를 상위 업무 시스템에 전달한다.

이 흐름에서 Client는 Remote Agent의 내부 프롬프트나 도구 체인을 알지 못한다. 대신 Agent Card로 호출 가능성을 판단하고, Message와 Part로 입력을 전달하며, Task로 상태를 추적하고, Artifact로 결과를 받는다. 이것이 A2A 객체 모델의 핵심이다.

객체 모델을 읽는 간단한 기준

A2A의 문법을 익힐 때는 다음 기준으로 객체를 구분하면 쉽다.

• Agent Card: 이 에이전트는 누구이고 무엇을 할 수 있는가?

• Message: 이번 대화에서 무엇을 말하고 있는가?

• Part: 그 말이나 결과는 어떤 콘텐츠 조각들로 이루어져 있는가?

• Task: 이 일이 추적해야 할 작업인가, 지금 상태는 무엇인가?

• Artifact: 작업 결과로 무엇이 남았는가?

이 다섯 가지를 구분하면 A2A의 나머지 흐름도 훨씬 단순해진다. 발견은 Agent Card에서 시작하고, 실행은 Message로 촉발되며, 장기 처리는 Task로 추적되고, 복합 콘텐츠는 Part로 나뉘며, 결과는 Artifact로 남는다. 다음 장에서는 이 객체들이 실제 상호작용에서 어떤 순서로 오가며, 발견에서 실행까지 어떤 흐름을 만드는지 살펴본다.

참고

¹A2A Protocol Specification

²Life of a Task - A2A Protocol