읽는 시간 약 10분 · AI 에이전트 운영 판단 가이드
독자의 질문: 다른 팀·벤더·실행 환경의 AI 에이전트에게 조사를 맡길 때, 단일 도구 호출로 처리해도 될 일과 상태·산출물·취소·사람 승인이 필요한 작업 위임은 어떻게 구분해야 할까요?
짧은 답: 한 시스템 안에서 즉시 결과를 받고 실행 책임도 한 곳에 있다면 도구 호출로 시작해도 됩니다. 반대로 외부 에이전트가 독립적으로 결과를 만들고, 기다리는 동안 상태·산출물·취소·재시도·승인 책임이 생긴다면 작업 위임 계약으로 다루는 편이 안전합니다. A2A는 이런 에이전트 간 통신을 위한 계층이며, 운영 책임 자체를 대신해 주지는 않습니다.

핵심 요약
- A2A는 서로 다른 에이전트가 발견되고 협업하도록 돕는 통신 표준입니다. 개별 에이전트가 도구·데이터에 연결되는 경로와는 역할이 다릅니다.
- 외부 에이전트가 일을 끝내는 구조라면 Agent Card 확인, task ID, 상태, artifact, 취소, 재시도, 승인 담당자를 먼저 합의해야 합니다.
- 부분 결과를 완료로 오인하거나, 취소와 재시도가 경쟁하거나, 승인 대기가 끝나지 않는 상황은 정상 시연만으로 발견하기 어렵습니다.
- 비용은 호출 횟수만이 아닙니다. 잘못된 결과를 되돌리는 인력, 권한 오남용의 범위, 장애를 재현하기 위한 기록 비용까지 포함해 판단해야 합니다.
A2A는 도구 호출을 대체하는 것이 아닙니다
A2A Protocol 공식 문서는 A2A를 독립적인 에이전트가 서로 발견하고 작업을 위임하며 결과를 교환하는 통신 표준으로 설명합니다. 반면 MCP는 하나의 에이전트가 도구, API, 리소스에 연결되는 방식을 표준화합니다. 즉, MCP로 장착한 도구를 가진 에이전트가 A2A를 통해 다른 에이전트와 협업할 수는 있지만, 두 방식은 같은 문제를 해결하지 않습니다.
Google의 A2A 발표도 client agent가 요청을 만들고 remote agent가 작업을 수행하며, Agent Card를 통한 capability discovery, task lifecycle, artifact를 핵심 요소로 제시합니다. 여기서 중요한 점은 프로토콜이 팀의 승인 정책이나 보존 기간, 외부 부작용의 되돌림을 자동으로 정해 주지는 않는다는 것입니다. 그 부분은 요청자와 수행자 사이의 운영 계약으로 남겨야 합니다.
도구 호출과 작업 위임을 가르는 7문항
아래 질문 중 여러 항목이 ‘예’라면, 단순 호출 결과가 아니라 상태를 가진 위임 작업으로 설계할 신호입니다. 모든 항목이 ‘아니오’라고 해서 A2A를 쓸 수 없다는 뜻은 아닙니다. 다만 처음부터 무거운 계약을 붙이는 비용이 실제 위험보다 큰지 확인하는 데 도움이 됩니다.

| 판단 질문 | 예라면 | 권장 설계 |
|---|---|---|
| 결과가 즉시 오지 않고 기다리는 시간이 있나요? | 장기 실행·대기 상태가 생깁니다. | task ID와 상태 조회·알림 방식을 정합니다. |
| 수행자가 요청 시스템 밖의 독립 에이전트인가요? | 능력·인증·제한 사항이 다를 수 있습니다. | Agent Card와 인증 범위를 확인합니다. |
| 결과물이 파일·표·보고서처럼 별도 산출물인가요? | 완료 메시지만으로 품질을 판단하기 어렵습니다. | artifact의 형식, 소유자, 보존 기준을 정합니다. |
| 사용자나 운영자가 중간에 취소해야 하나요? | 취소 이후 외부 부작용이 남을 수 있습니다. | 취소 권한과 최종 상태 규칙을 계약에 적습니다. |
| 네트워크 오류 뒤 재시도가 필요한가요? | 같은 작업이 두 번 수행될 위험이 있습니다. | 재시도 한도와 중복 실행 판별 기준을 둡니다. |
| 비용·외부 발송·민감 데이터 접근이 있나요? | 기술 성공만으로 실행을 허용하기 어렵습니다. | 승인 담당자와 대기 시간 초과 후 행동을 정합니다. |
| 결과가 틀렸을 때 요청자가 재현·감사해야 하나요? | 누가 무엇을 결정했는지 남겨야 합니다. | 상관 ID, 상태 이력, artifact 버전을 기록합니다. |
구체 예시: 외부 시장조사 에이전트가 공급사 비교표를 만들어 구매 담당자에게 돌려주는 일은 단순 검색 호출보다 작업 위임에 가깝습니다. 조사 범위가 바뀔 수 있고, 표가 부분적으로만 도착할 수 있으며, 구매 후보를 외부에 발송하기 전에 담당자의 확인이 필요할 수 있기 때문입니다. 반대로 내부 데이터베이스에서 공개 가격표 한 줄을 조회해 즉시 반환하는 일은 보통 도구 호출에 더 가깝습니다.
Agent Card에서 먼저 확인할 항목
Agent Card는 원격 에이전트가 무엇을 할 수 있는지 알리는 발견 정보입니다. 카드가 존재한다는 사실만으로 요청을 보낼 수 있다고 결론 내리기보다, 현재 업무에 필요한 capability와 인증·입출력 조건을 함께 대조해야 합니다. 제품별 구현과 확장 범위는 다를 수 있으므로 실제 연결 전 해당 구현의 문서도 확인해 주세요.
| 확인 항목 | 확인할 질문 | 놓치면 생기는 문제 |
|---|---|---|
| Capability | 필요한 조사·분석·실행 범위가 명시되어 있나요? | 지원하지 않는 일을 요청해 실패를 늦게 알 수 있습니다. |
| 인증·권한 | 어떤 인증 방식이며, 어떤 데이터와 동작까지 허용되나요? | 필요 이상 권한을 주거나 요청이 거절될 수 있습니다. |
| 입력·출력 | 허용 입력 형식과 예상 artifact 형식은 무엇인가요? | 형식이 맞아도 품질 검수가 불가능할 수 있습니다. |
| 작업·스트리밍 | 비동기 상태 갱신과 중간 결과를 지원하나요? | 긴 작업을 멈춘 것으로 오해할 수 있습니다. |
| 제한 사항 | 시간, 지역, 데이터 보존, 호출 한도는 어떤가요? | 비용·규정·납기 판단이 흔들릴 수 있습니다. |
한 장으로 시작하는 위임 계약 카드
위임 계약은 복잡한 법무 문서가 아니라, 작업이 멈췄을 때 누구도 추측하지 않게 만드는 운영 메모입니다. 아래 항목을 한 작업 단위로 채우면 개발·운영·현업 담당자가 같은 상태를 볼 수 있습니다.

- task ID와 요청자·수행자: 중복 요청을 식별할 값과 각 역할의 책임자를 적습니다.
- 허용 입력과 권한: 전달 가능한 데이터 범위, 금지 데이터, 외부 동작 가능 범위를 적습니다.
- artifact와 품질 기준: 결과 형식, 필수 열·근거 링크, 부분 결과 표시 규칙을 정합니다.
- 상태와 알림: 시작·진행·승인 대기·완료·실패·취소를 누가 어디에서 확인하는지 정합니다.
- retry와 cancel: 재시도 횟수, 멱등성 판별 키, 취소 후 확인할 외부 부작용을 정합니다.
- approval owner와 timeout: 승인 담당자, 대기 상한, 응답이 없을 때 중단·에스컬레이션 중 무엇을 할지 정합니다.
- 감사 기록: 요청 시각, 결정 이유, artifact 버전, 상태 전이 기록의 보관 위치를 정합니다.
예를 들어 시장조사 작업이라면 “승인된 공개 URL만 입력으로 사용, 비교표에는 출처 링크 필수, 30분 내 진행 상태를 한 번 남김, 구매 후보 외부 발송은 담당자 승인 후에만 가능, 응답이 없으면 실행 없이 종료”처럼 적을 수 있습니다. 이 정도만 있어도 결과가 늦을 때 재촉할 대상과, 부분 표를 받아들여도 되는 조건이 분명해집니다.
정상 시연 전에 실패를 네 번 리허설하세요
승인 대기와 장기 작업을 다루는 Temporal의 예시는 위험한 행동을 사람의 결정까지 대기시키고, 승인·거절·시간 초과를 서로 다른 결과로 다룹니다. 이 패턴은 A2A 구현 자체의 기능을 주장하는 근거가 아니라, 위임 계약에서 timeout과 감사 기록을 별도 운영 책임으로 두어야 하는 이유를 보여 줍니다.
| 실패 주입 | 안전한 리허설 | 기대 상태 | 즉시 중단 조건 |
|---|---|---|---|
| 부분 결과 | artifact 일부만 반환하는 시험 작업 | 완료가 아닌 진행 또는 부분 결과로 표기 | 필수 근거 없이 완료로 처리될 때 |
| 취소 경쟁 | 취소 요청과 완료 직전 응답을 가깝게 발생 | 최종 상태와 외부 부작용 확인자가 한 명으로 수렴 | 취소 뒤 발송·쓰기 결과를 확인할 수 없을 때 |
| 승인 timeout | 승인 신호를 보내지 않는 읽기 전용 작업 | 정한 상한 뒤 중단 또는 에스컬레이션 | 무한 대기하거나 설명 없이 실행될 때 |
| 중복 retry | 첫 응답을 유실한 것처럼 재시도 | 동일 작업을 식별하고 한 번의 artifact로 정리 | 외부 행동이 두 번 일어나거나 원인을 추적할 수 없을 때 |
신뢰성 기준: 리허설 결과는 ‘통과’ 한 줄보다 task ID, 예상 상태, 실제 상태, artifact 버전, 확인 담당자, 남은 외부 부작용을 함께 남겨야 합니다. 그래야 구현을 바꾸거나 벤더를 교체한 뒤에도 같은 판단을 재현할 수 있습니다.
30분 파일럿으로 확대 여부를 결정하는 법
- 읽기 전용 업무 하나를 고릅니다. 공개 공급사 정보 정리처럼 되돌림 비용이 낮은 일을 선택합니다.
- Agent Card와 계약 카드를 함께 채웁니다. capability, 입력 범위, artifact, 담당자, timeout을 빈칸 없이 적습니다.
- 실패 하나를 일부러 넣습니다. 부분 결과 또는 승인 timeout 가운데 하나를 선택해 기대 상태를 확인합니다.
- 품질과 비용을 함께 봅니다. 결과가 출처를 포함하는지, 담당자가 상태를 이해하는지, 재작업 시간이 줄었는지 검토합니다.
- 확대 기준을 명시합니다. 중단 조건이 한 번이라도 나오면 쓰기 권한·외부 발송으로 범위를 넓히지 않습니다.
여러 에이전트를 늘릴 경제성이 있는지 먼저 따져 보고 싶다면 병렬화 손익을 계산하는 결정표를, 도구 연결과 에이전트 연결의 역할 차이를 더 살펴보려면 MCP 전환 점검 글을 함께 참고해 보세요. 계약이 안정된 뒤에는 웹훅으로 작업 상태를 추적하는 방법, 그리고 위임 작업 성과를 측정하는 방법으로 이어갈 수 있습니다.
자주 묻는 질문
A2A를 쓰면 모든 에이전트가 바로 함께 일할 수 있나요?
그렇게 단정하기는 어렵습니다. A2A는 상호 운용을 위한 공통 통신 계층이지만, 실제로 사용할 capability, 인증 방식, 입력·출력 형식, 확장 지원 범위는 각 Agent Card와 구현 문서에서 확인해야 합니다.
A2A가 MCP를 대체하나요?
아닙니다. A2A 공식 문서는 MCP를 에이전트와 도구·데이터의 연결, A2A를 에이전트와 에이전트의 연결로 구분합니다. 하나의 에이전트가 MCP로 도구를 사용하면서 A2A로 다른 에이전트에 일을 맡기는 구조도 가능합니다.
작은 조사 업무에도 위임 계약이 필요한가요?
즉시 끝나고 결과가 단순하며 책임자가 한 곳이라면 간단한 도구 호출로 시작해도 됩니다. 다만 외부 에이전트, 장기 실행, 별도 artifact, 취소·재시도, 승인 중 하나가 추가되면 최소한의 계약 카드부터 작성해 두는 편이 좋습니다.
승인 대기 시간이 끝나면 자동 실행해야 하나요?
업무 영향에 따라 다릅니다. 비용 지출, 외부 발송, 민감 데이터 접근처럼 되돌리기 어려운 행동은 자동 실행보다 중단 또는 지정 담당자에게 에스컬레이션하는 쪽이 보수적입니다. 읽기 전용 작업도 timeout 뒤 상태를 명확히 남겨야 합니다.
참고 자료
- Google Developers Blog — Announcing the Agent2Agent Protocol — A2A의 client·remote agent 역할, Agent Card 기반 capability discovery, task lifecycle과 artifact 개념을 확인할 수 있습니다.
- A2A Protocol 공식 문서 — A2A의 목적과 A2A·MCP가 맡는 서로 다른 통신 경계를 확인할 수 있습니다.
- Temporal — Human-in-the-loop AI agent — 승인 신호, timeout, 취소, 감사 기록을 장기 작업 상태로 다루는 운영 패턴을 참고할 수 있습니다.
이 글이 마음에 드세요?
FLOWIT on YouTube
영상으로도 FLOWIT을 이어서 보세요
AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.
AI 코딩 에이전트, 벤치마크 1위면 도입해도 될까? 우리 저장소에서 먼저 돌릴 10개 업무 실험 카드
AI 에이전트 승인창이 많을수록 안전할까? 장기 작업의 승인 피로를 막는 5칸 개입 예산
AI 에이전트가 503 때 싼 모델로 바뀌어도 될까? fallback 품질을 같게 만드는 5개 테스트