AX LABS
← 블로그 에이전트 제품 설계

위임은 호출이 아니라 계약이다

Task adapter가 벤더 경계를 낮춘다

AX LABS 5분 읽기

여러 팀이 에이전트를 만들기 시작하면 같은 질문이 반복된다. “저 에이전트 결과를 우리 에이전트가 받아서 다음 일을 시킬 수 있나.” 처음에는 API 하나 붙이면 된다고 본다. 곧 상태, 중간 산출물, 재시도, 권한, 사람이 끼어드는 지점이 모두 다른 방식으로 새어 나온다.

A2A Task adapter는 이 지점에서 필요하다. 내부 에이전트를 갈아엎는 기술이 아니다. 내부 실행 방식을 외부 위임 계약으로 감싸는 경계면이다. 2026-06-29 기준 A2A GitHub release는 v1.0.1이 최신으로 표시된다: https://github.com/a2aproject/A2A/releases

내부 에이전트는 그대로 두고 경계를 바꾼다

A2A의 핵심은 상대 에이전트의 내부 메모리, 도구, 추론 절차를 공유하지 않아도 협업할 수 있게 만드는 데 있다. A2A 명세는 Task를 상태를 가진 작업 단위로 보고, Artifact를 Task 결과물로 정의한다. 최신 명세는 https://a2a-protocol.org/latest/specification/ 에서 확인된다.

Task adapter는 내부 에이전트 앞단에 얇게 붙는 번역 계층이다. 외부 요청은 Message로 받고, 내부 실행은 기존 런타임에 맡긴다. 대신 외부에는 Task 상태와 Artifact만 내보낸다. 이 구분이 없으면 내부 구현이 곧 계약이 된다. 구현이 계약이 되는 순간 벤더 교체와 다중 위임은 막힌다.

cross-vendor 위임은 “상대가 어떻게 일하는가”를 맞추는 문제가 아니라 “작업이 어떤 상태와 산출물로 드러나는가”를 맞추는 문제다.

Task adapter는 세 가지를 고정한다

첫째, 작업 식별자를 고정한다. 외부 클라이언트는 한 번 던진 일을 계속 추적해야 한다. 내부 에이전트가 여러 tool call, subagent, batch job을 돌려도 외부에는 하나의 Task로 보인다.

둘째, 상태 전이를 고정한다. working, input-required, auth-required, completed, failed, canceled, rejected 같은 상태는 운영 언어다. 현장에서는 “아직 도는 중인지”, “사람 입력이 필요한지”, “실패했는지”가 로그보다 먼저 필요하다.

셋째, 산출물 경계를 고정한다. 내부 에이전트의 긴 대화 로그가 결과가 아니다. 외부 위임의 결과는 Artifact다. 문서, JSON, 파일 참조, 검토 요청, 승인 초안이 Artifact로 나와야 다음 에이전트가 이어받는다.

구분 직접 연동 A2A Task adapter
결합 지점 내부 API와 프롬프트 Task·Artifact 계약
상태 관리 호출자별 임시 규칙 표준 state transition
산출물 응답 문자열 중심 Artifact 중심
변경 영향 내부 구현 변경이 외부로 전파 adapter에서 흡수
운영 관찰 로그 해석 필요 Task 상태로 추적

state transition이 운영을 만든다

PoC는 답변이 나오면 끝난다. 운영은 답변이 나오기 전과 나온 뒤가 더 길다. 지연, 중단, 추가 입력, 권한 요청, 부분 산출물, 재시작이 생긴다. 그래서 Task adapter는 단순 wrapper가 아니다. 상태 기계다.

설계할 때 최소 네 가지 매핑을 정한다.

  1. 내부 실행 시작을 어떤 Task 상태로 노출할지
  2. 사람이 답해야 하는 순간을 input-required로 끊을지
  3. 내부 실패를 failed와 rejected 중 어디로 보낼지
  4. 부분 결과를 Artifact update로 낼지 최종 Artifact로만 낼지

이 매핑이 없으면 cross-vendor 위임은 데모에서만 작동한다. 상대 에이전트는 우리의 로그를 읽지 않는다. 상대는 Task 상태와 Artifact만 읽는다.

먼저 하나의 업무를 adapter로 감싼다

도입 순서는 크지 않아야 한다. 내부 에이전트 하나를 골라 AgentCard, Task 생성, 상태 전이, Artifact 반환, 취소 처리까지 닫힌 루프로 만든다. 그다음 streaming이나 push notification을 붙인다. Google Cloud 문서도 A2A가 서로 다른 프레임워크·벤더·서버의 에이전트 상호운용을 목표로 한다고 설명한다: https://docs.cloud.google.com/run/docs/ai/a2a-agents

AX Ops 관점의 첫 산출물은 코드가 아니라 계약표다. 어떤 요청을 받을지, 어떤 상태를 외부에 보일지, 어떤 Artifact를 다음 에이전트가 신뢰할지 정한다. 그 표가 있어야 보안, 평가, 운영 모니터링이 붙는다.

A2A Task adapter는 에이전트를 더 똑똑하게 만드는 장치가 아니다. 에이전트를 맡길 수 있는 운영 단위로 만드는 장치다. 내부 에이전트를 위임 가능한 제품 경계로 바꾸려면 AX Ops 방법론 →

참고