연결되는 시스템과 믿고 맡길 수 있는 시스템
A2A는 서로 다른 에이전트가 발견되고, 요청을 받고, 상태와 결과를 주고받도록 돕는 공개 표준이다.1 하지만 프로토콜 연동에 성공했다는 사실만으로 운영 가능한 시스템이 되지는 않는다. 데모에서는 한 번의 요청이 잘 끝나면 충분해 보인다. 운영 환경에서는 다르다. 누가 어떤 태스크를 만들었는지, 어느 원격 에이전트가 얼마나 오래 걸렸는지, 스트리밍이 어디서 끊겼는지, 최종 Artifact가 정말 생성되었는지를 나중에 설명할 수 있어야 한다.
관측성은 이런 설명 능력이다. 관측성은 시스템 바깥에서 남긴 로그, 지표, 추적 정보를 보고 내부에서 무슨 일이 일어났는지 이해하는 능력이다. 병원에서 체온, 혈압, 심전도를 보고 몸의 상태를 추정하듯이, A2A 시스템도 태스크 상태, 메시지 흐름, 호출 지연 시간, 오류율을 보고 협업의 건강 상태를 판단한다.
A2A 운영에서 중요한 질문은 단순하다.
요청이 어느 태스크로 이어졌는가?
어떤 원격 에이전트가 호출되었는가?
어느 메시지와 Artifact가 태스크에 연결되었는가?
실패가 네트워크 문제인지, 프로토콜 문제인지, 에이전트 품질 문제인지 구분되는가?
같은 문제가 다시 생겼을 때 빠르게 재현하고 막을 수 있는가?
이 질문에 답하지 못하면 시스템은 연결되어 있어도 운영되지는 않는다.
AI 생성 이미지
로그는 태스크의 일대기를 남겨야 한다
A2A에서 로그의 중심은 태스크다. Task는 업무 티켓이고, Message는 그 티켓 안에서 오간 대화이며, Artifact는 공식 산출물이다. 따라서 운영 로그도 이 구조를 따라야 한다.
가장 먼저 모든 로그에 공통 식별자를 넣어야 한다. 최소한 trace_id, request_id, task_id, message_id, artifact_id, client_agent, remote_agent, method를 남긴다. trace_id는 여러 시스템을 가로지르는 전체 흐름을 묶는 끈이고, task_id는 A2A 업무 단위를 묶는 끈이다. 둘은 다르다. 하나의 사용자 요청이 여러 태스크로 나뉠 수 있고, 하나의 태스크가 여러 HTTP 호출과 스트리밍 이벤트로 이어질 수 있기 때문이다.
로그에는 결과만 남기면 부족하다. 상태 전환도 남겨야 한다. 예를 들어 태스크가 submitted에서 working으로 바뀌고, 추가 정보가 필요해 input-required가 되었으며, 사용자의 답변 뒤 completed가 되었다면 각 전환 시점이 기록되어야 한다. 그래야 지연이 원격 에이전트의 처리 시간 때문인지, 사용자의 추가 입력 대기 때문인지 구분할 수 있다.
원격 에이전트 호출 로그에는 호출 대상, Agent Card 버전, 선택한 스킬, JSON-RPC 메서드, HTTP 상태, JSON-RPC 오류 코드, 재시도 횟수, 타임아웃 여부를 포함한다. A2A는 JSON-RPC over HTTP(S), Agent Card 기반 발견, SSE 스트리밍, 비동기 푸시 알림 같은 기능을 포함하므로 호출 경계가 여러 곳에 생긴다.2 각 경계에서 같은 식별자가 이어져야 장애 분석이 가능하다.
Artifact 로그도 중요하다. Artifact는 단순 응답 문장이 아니라 다음 단계의 입력, 감사 자료, 사용자에게 전달되는 공식 결과가 될 수 있다. 따라서 Artifact 생성 시점, 타입, 크기, 저장 위치, 해시 또는 버전, 생성한 에이전트, 연결된 태스크를 남긴다. 단, 민감한 본문을 그대로 로그에 쓰면 안 된다. 운영 로그는 문제를 찾기 위한 기록이지 데이터 복제 저장소가 아니다. 본문 대신 요약, 길이, MIME 타입, 참조 ID, 접근 권한 정보를 남기는 편이 안전하다.
지표는 분산된 협업의 건강 상태를 보여준다
로그가 개별 사건의 기록이라면, 지표는 전체 흐름의 체온계다. A2A 시스템에서는 에이전트가 여러 개이고 네트워크 경계도 많다. 그래서 단일 서버의 CPU나 메모리만 봐서는 부족하다. 태스크, 원격 호출, 스트리밍, 재시도, Artifact 생성을 따로 측정해야 한다.
기본 지표는 지연 시간이다. message/send, message/stream, tasks/get, tasks/cancel 같은 메서드별 응답 시간을 측정한다. 평균만 보면 위험하다. 대부분 빠르지만 일부 요청이 매우 느릴 수 있기 때문이다. p50, p95, p99처럼 백분위 지표를 함께 본다. 예를 들어 p95 태스크 완료 시간이 갑자기 증가했다면 특정 원격 에이전트나 특정 스킬에서 병목이 생겼을 가능성이 크다.
두 번째는 실패율이다. 실패는 하나로 묶지 말고 분류해야 한다.
네트워크 실패: 연결 실패, DNS 오류, TLS 오류, 타임아웃
HTTP 실패: 401, 403, 404, 429, 5xx 등
JSON-RPC 실패: 잘못된 메서드, 잘못된 파라미터, 내부 오류
A2A 업무 실패: 태스크가
failed가 됨정책 실패: 권한 부족, 데이터 반출 차단, 승인 거절
품질 실패: 응답은 왔지만 부정확하거나 기준을 만족하지 못함
이 구분이 없으면 모든 장애가 에이전트가 실패했다로 보인다. 그러나 해결책은 전혀 다르다. 401은 인증 설정 문제일 수 있고, 429는 호출량 제어 문제이며, 품질 실패는 모델·프롬프트·검증 데이터의 문제일 수 있다.
세 번째는 재시도와 중복 실행 지표다. 재시도 횟수, 재시도 후 성공률, 멱등성 충돌, 중복 Artifact 생성 횟수를 본다. 재시도는 안정성을 높이지만 잘못 설계하면 같은 주문을 두 번 처리하듯 위험한 중복 실행을 만든다. 태스크 생성과 외부 시스템 변경 작업에는 특히 멱등성 키와 중복 방지 로그가 필요하다.
네 번째는 스트리밍 지표다. SSE 연결 수, 평균 연결 시간, 중간 끊김 횟수, tasks/resubscribe 성공률, 마지막 이벤트 이후 무응답 시간, 최종 상태 확인 성공률을 측정한다. 스트리밍은 사용자 경험을 좋게 하지만 네트워크에 민감하다. 연결이 끊긴 것과 태스크가 실패한 것은 다르므로 지표도 분리해야 한다.
OpenTelemetry는 AI 에이전트 시스템에서도 로그, 지표, 트레이스를 표준화된 신호로 다루는 방향을 제시한다.3 A2A 시스템도 이 원칙을 따를 수 있다. 클라이언트 오케스트레이터에서 시작한 trace가 원격 에이전트 호출, 내부 도구 호출, Artifact 저장까지 이어지면 장애 분석 시간이 크게 줄어든다.
테스트는 세 겹으로 나누어야 한다
A2A 테스트는 한 번의 엔드투엔드 성공으로 끝내면 안 된다. 단위 테스트, 계약 테스트, 통합 테스트를 나누어야 한다.
단위 테스트는 작은 부품을 검증한다. Agent Card 파서가 필수 필드를 확인하는지, 라우터가 스킬과 보안 조건을 보고 올바른 에이전트를 선택하는지, JSON-RPC 요청과 응답을 정확히 만드는지 확인한다. 태스크 상태 전이도 단위 테스트 대상이다. completed가 된 태스크가 다시 working으로 돌아가지 않도록 막는 규칙, input-required 상태에서 추가 메시지를 받았을 때 다시 작업을 시작하는 규칙을 검증한다.
계약 테스트는 클라이언트와 서버 사이의 약속을 검증한다. 서버가 Agent Card에 적은 기능을 실제로 지원하는지, message/send의 입력과 출력 스키마가 문서와 맞는지, 오류 응답이 JSON-RPC 형식을 지키는지 확인한다. 클라이언트도 테스트해야 한다. 원격 에이전트가 input-required를 반환하거나, 인증 오류를 반환하거나, 예상보다 큰 Artifact를 보낼 때 클라이언트가 깨지지 않아야 한다.
계약 테스트의 장점은 서로 다른 팀이 독립적으로 배포할 때 드러난다. 원격 에이전트 팀이 응답 필드 하나를 바꾸었는데 클라이언트가 이를 전제로 동작한다면 운영 장애가 된다. 계약 테스트는 이런 변경을 배포 전에 잡아내는 안전망이다.
통합 테스트는 실제 흐름을 검증한다. 오케스트레이터가 Agent Card를 읽고, 원격 에이전트를 선택하고, 태스크를 만들고, 스트리밍 이벤트를 받고, Artifact를 저장한 뒤 최종 결과를 사용자에게 돌려주는 전체 경로를 확인한다. 여기에는 장애 주입도 포함해야 한다. 네트워크 지연, 중간 연결 끊김, 429 응답, 잘못된 JSON-RPC 오류, 원격 에이전트의 느린 응답, 웹훅 재전송을 일부러 발생시켜 본다.
운영에 가까운 통합 테스트일수록 정상 흐름보다 비정상 흐름이 중요하다. 실제 장애는 대개 프로토콜을 잘못 이해한 부분, 시간 제한을 정하지 않은 부분, 재시도와 취소가 충돌하는 부분에서 생긴다.
응답 품질과 프로토콜 안정성은 다른 문제다
A2A 시스템을 평가할 때 자주 섞이는 두 가지가 있다. 하나는 에이전트의 응답 품질이고, 다른 하나는 프로토콜 수준의 안정성이다.
응답 품질은 결과가 유용한지, 사실에 맞는지, 사용자의 의도에 맞는지, 형식 요구사항을 지켰는지에 관한 문제다. 예를 들어 시장 조사 에이전트가 보고서를 완성했지만 근거가 약하거나 최신 정보가 빠졌다면 품질 실패다.
프로토콜 안정성은 태스크가 올바르게 생성되었는지, 상태가 일관되게 바뀌었는지, 스트리밍이 끊겨도 재구독할 수 있는지, 오류가 표준 형식으로 돌아오는지, Artifact가 누락되지 않았는지에 관한 문제다. 보고서 내용이 훌륭해도 클라이언트가 최종 Artifact를 받지 못했다면 운영 관점에서는 실패다. 반대로 프로토콜은 완벽히 동작했지만 답변이 부정확하다면 품질 관점에서 실패다.
따라서 대시보드와 평가 체계도 분리해야 한다. 운영 대시보드는 지연 시간, 실패율, 재시도, 스트리밍 끊김, 태스크 완료율을 본다. 품질 평가 대시보드는 정답률, 근거 충실도, 사용자 만족도, 정책 위반, 사람이 수정한 비율을 본다. 두 지표를 함께 보되 하나로 합치지는 않는다.
이 분리는 책임을 명확히 한다. 플랫폼 팀은 프로토콜 안정성, 인증, 라우팅, 관측성, 재시도 정책을 책임진다. 에이전트 팀은 모델 선택, 프롬프트, 도구 사용, 도메인 지식, 응답 검증을 책임진다. 오케스트레이터 팀은 어느 에이전트에게 어떤 업무를 맡길지, 실패 시 어떻게 대체할지, 최종 결과를 어떻게 검수할지 책임진다.
운영 안정성은 작은 규칙의 합이다
A2A 운영 안정성은 거창한 기능 하나로 만들어지지 않는다. 작은 규칙이 모여 만들어진다.
모든 외부 호출에는 타임아웃을 둔다. 재시도는 지수 백오프와 최대 횟수를 둔다. 같은 장애가 반복되면 회로 차단기처럼 잠시 호출을 멈추고 대체 경로를 사용한다. 장기 실행 태스크는 큐와 영속 저장소에 상태를 남긴다. 취소 요청은 가능한 빨리 반영하되, 이미 외부 시스템에 반영된 작업은 보상 절차를 따로 둔다.
배포도 관측성과 연결해야 한다. Agent Card 버전, 스킬 버전, 서버 빌드 버전을 로그와 지표에 남기면 새 배포 이후 실패율이 증가했는지 확인할 수 있다. 일부 트래픽만 새 버전으로 보내는 카나리 배포도 유용하다. 새 원격 에이전트를 바로 전체 워크플로에 넣기보다 낮은 위험의 태스크부터 연결해 본다.
마지막으로 런북이 필요하다. 런북은 장애가 났을 때 사람이 따라야 할 짧은 절차서다. 원격 에이전트 5xx 증가, 스트리밍 끊김 증가, Artifact 저장 실패, 인증 오류 급증, 태스크 완료율 저하 같은 상황별로 확인할 로그, 대시보드, 임시 차단 방법, 담당 팀을 적어 둔다.
A2A는 에이전트 사이의 협업 경계를 표준화한다. 그러나 표준은 운영을 대신해 주지 않는다. 운영 가능한 A2A 시스템은 태스크의 일대기를 기록하고, 분산 호출의 건강 상태를 측정하며, 계약을 테스트하고, 품질과 안정성을 분리해 평가하는 시스템이다. 이 차이를 이해할 때, A2A는 데모용 연결을 넘어 실제 업무를 맡길 수 있는 협업 기반이 된다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.