품질 평가와 관측 가능성
작동 여부보다 추적 가능성이 먼저다
A2A 시스템을 처음 만들 때 개발팀은 보통 한 가지 질문에 집중한다. "요청을 보내면 원격 에이전트가 응답하는가?" 이 질문은 중요하지만 운영 환경에서는 충분하지 않다. 다중 에이전트 시스템에서는 한 번의 사용자 요청이 여러 Agent Card 조회, 인증, Message 전달, Task 생성, 상태 전이, Artifact 생성으로 이어진다. 중간에 사람이 승인해야 할 수도 있고, 외부 API나 MCP 서버가 지연될 수도 있다.
따라서 운영 전 검증의 기준은 단순히 "된다"가 아니다. "어떤 에이전트가 왜 선택되었는가", "Task가 어느 상태에서 오래 머물렀는가", "최종 Artifact가 재사용 가능한 품질인가", "장애가 발생했을 때 원인을 추적할 수 있는가"를 답할 수 있어야 한다.
이 장에서 말하는 품질은 세 층으로 나눌 수 있다.
프로토콜 품질: A2A 명세에 맞게 Agent Card, Message, Task, Artifact를 주고받는가.
결과 품질: 에이전트들이 협업해 사용자의 업무 목표를 정확히 달성하는가.
운영 품질: 지연, 실패, 재시도, 취소, 승인 대기, 장애 원인을 측정하고 개선할 수 있는가.
이 세 가지가 함께 갖춰져야 A2A 시스템을 기업 업무에 투입할 수 있다.
AI 생성 이미지
A2A Inspector로 대화를 눈에 보이게 만들기
A2A Inspector는 A2A 에이전트를 사람이 직접 연결하고 관찰하는 디버깅 도구로 이해하면 쉽다. 개발자는 에이전트의 기본 URL을 입력하고, Inspector는 보통 표준 well-known 경로인 /.well-known/agent-card.json에서 Agent Card를 가져온다. 환경에 따라 레지스트리나 직접 설정을 사용할 수도 있지만, 공개적으로 발견 가능한 에이전트라면 이 경로를 먼저 점검하는 것이 좋다.1
Agent Card가 열리면 화면에서 에이전트 이름, 설명, 서비스 엔드포인트 또는 지원 인터페이스, 버전, 지원 입출력 모드, 스킬 같은 정보를 확인한다. 이 과정에서 필수 필드 누락, URL 형식 오류, 타입 불일치, 스킬 배열 구조 오류 같은 문제를 빠르게 찾을 수 있다.
Inspector의 가치는 Agent Card 확인에서 끝나지 않는다. 메시지를 보내면 원시 JSON-RPC 요청과 응답, 응답 시간, 상관관계 ID, 검증 오류가 함께 표시된다. 응답이 task, status-update, artifact-update, message 같은 기대한 종류로 분류되는지도 확인할 수 있다.2 즉, 화면에 답변이 그럴듯하게 보이는지보다 A2A 객체가 올바르게 오갔는지를 본다.
운영 전에는 다음 흐름을 Inspector로 최소 한 번씩 점검하는 것이 좋다.
Agent Card가 표준 공개 위치나 조직이 정한 레지스트리에서 안정적으로 조회되는가.
Agent Card의 엔드포인트, 버전, 스킬, 인증 요구사항이 실제 배포 설정과 일치하는가.
간단한 Message 요청이 정상 응답을 반환하는가.
장시간 작업 요청이 Task를 만들고 상태를 갱신하는가.
input-required,auth-required,failed,canceled,rejected같은 대기, 인증 요구, 실패 흐름이 명세에 맞게 표현되는가.Artifact가 사람이 읽을 수 있을 뿐 아니라 후속 시스템이 처리할 수 있는 구조를 갖는가.
Inspector는 부하 테스트 도구가 아니다. 대신 한 건의 상호작용을 깊게 들여다보는 현미경에 가깝다. 특히 여러 에이전트가 연결된 시나리오에서 어떤 경계에서 프로토콜 위반이 생겼는지 확인하는 데 유용하다.
TCK를 자동화된 호환성 관문으로 두기
A2A 생태계에서는 Inspector와 함께 Technology Compatibility Kit, 줄여서 TCK가 검증 도구로 제공된다.3 TCK는 특정 구현이 프로토콜의 기본 기대를 만족하는지 반복적으로 확인하는 자동화된 호환성 테스트 묶음으로 운용해야 한다. Inspector가 사람이 보는 디버깅 도구라면, TCK는 빌드와 배포 파이프라인에 들어가는 자동 관문이다.
TCK를 사용할 때의 목표는 "우리 클라이언트와 우리 서버끼리만 동작한다"를 넘는 것이다. A2A는 개방형 표준이므로 다른 SDK, 다른 언어, 다른 클라우드에서 만든 에이전트와도 맞물려야 한다. 공개 TCK는 Agent Card가 선언한 전송 방식에 따라 JSON-RPC, gRPC, HTTP+JSON 같은 프로토콜 바인딩을 검증하고, 실행 결과를 기계가 읽을 수 있는 보고서와 사람이 보는 보고서로 남길 수 있다.
실무에서는 다음 항목을 테스트 범위에 넣는다.
Agent Card 스키마, 버전, 엔드포인트, 보안 요구사항 검증
메시지 보내기, Task 조회, Task 취소 같은 기본 작업 호출
Task 상태 전이의 유효성
잘못된 입력, 권한 부족, 지원하지 않는 스킬 요청에 대한 오류 표현
스트리밍, 재조회, 재구독 흐름에서 상태와 Artifact가 일관되게 보이는지
SDK 재생성 후 기존 요청과 응답이 깨지지 않는지
실무에서는 TCK를 세 시점에 실행한다. 첫째, 에이전트 서버 코드가 변경될 때다. 둘째, A2A SDK나 명세 버전을 올릴 때다. 셋째, Agent Card의 스킬, 인증 방식, 입출력 모드를 바꿀 때다. 이 세 경우는 외부 에이전트와의 계약을 바꾸는 순간이기 때문이다.
결과 품질은 최종 답변만 보지 않는다
A2A 시스템의 평가는 일반 챗봇 평가와 다르다. 최종 문장이 자연스러운지만 보면 안 된다. 어떤 에이전트가 선택되었는지, 필요한 시점에 사람에게 입력이나 승인을 요청했는지, Task가 올바른 상태로 끝났는지, Artifact가 후속 자동화에 쓸 수 있는지까지 봐야 한다.
Google Cloud는 A2A 에이전트 개발과 평가를 지원하기 위해 Vertex AI와 연결되는 개발자 도구와 평가 기능 확장을 발표했다.4 이런 평가 체계를 사용할 때는 평가 데이터셋을 단순 질의응답 모음으로 만들지 말고 업무 시나리오 단위로 구성하는 편이 좋다.
예를 들어 구매 요청 시나리오라면 평가 항목은 다음처럼 나눌 수 있다.
올바른 구매 에이전트를 발견하고 선택했는가.
예산 한도를 넘는 경우 승인 요청 상태로 전환했는가.
공급업체 비교 결과를 Artifact로 남겼는가.
최종 결과에 근거 데이터와 제약 조건이 포함되었는가.
권한이 없는 사용자의 요청을 실행하지 않고 거절했는가.
평가 지표도 여러 층으로 둔다. 목표 달성률, 에이전트 선택 정확도, 지시 준수율, 근거 충실도, 정책 위반률, Artifact 스키마 유효성, 재실행 시 일관성 등을 함께 본다. 일부는 정답 기반으로 자동 평가할 수 있고, 일부는 LLM 평가자나 사람이 판단해야 한다. 중요한 것은 매 릴리스마다 같은 시나리오를 반복 실행해 이전 버전과 비교하는 것이다. 그래야 "모델이 좋아진 것 같다"가 아니라 "승인 대기 처리 정확도가 92%에서 97%로 올랐다"처럼 말할 수 있다.
운영 지표는 Task 중심으로 정의한다
A2A 운영 지표는 HTTP 요청 수나 평균 응답 시간만으로 부족하다. 사용자에게 중요한 단위는 개별 API 호출이 아니라 Task다. 따라서 지표도 Task 생명주기를 기준으로 설계해야 한다.
가장 먼저 볼 지표는 지연 시간이다. 단, 전체 평균 하나로 뭉개면 원인을 찾기 어렵다.
Agent Card 발견 시간
인증과 인가 처리 시간
Task 생성까지 걸린 시간
실제 작업 실행 시간
input-required또는auth-required상태에서 머문 시간Artifact 생성과 전달 시간
전체 완료 시간의 p50, p95, p99
다음은 실패와 중단 지표다.
failed비율rejected비율사용자 또는 시스템에 의한 취소율
재시도 횟수와 재시도 성공률
타임아웃 비율
스트리밍 연결 끊김과 재구독 성공률
하위 MCP 도구나 외부 API 장애로 인한 실패 비율
특히 인간 승인 대기 시간은 별도 지표로 분리해야 한다. 사람이 승인하지 않아 Task가 늦어진 것과 에이전트 실행이 느린 것은 전혀 다른 문제다. 이를 구분하지 않으면 잘못된 성능 개선에 시간을 쓰게 된다.
서비스 수준 목표, 즉 SLO도 에이전트 전체가 아니라 스킬 단위로 잡는 것이 현실적이다. 보고서 요약 스킬과 계약 검토 스킬은 위험도와 처리 시간이 다르다. 같은 성공률과 지연 목표를 적용하면 운영 판단이 흐려진다.
Agent Card와 SDK 변경은 계약 변경이다
Agent Card는 설명 문서가 아니라 호출 계약이다. 이름이나 설명을 조금 고치는 것은 가벼운 변경일 수 있지만, 스킬 의미, 입력 형식, 인증 방식, 엔드포인트, 지원 출력 모드를 바꾸면 외부 클라이언트가 깨질 수 있다.
변경은 세 종류로 나누어 관리한다.
하위 호환 변경: 선택 필드 추가, 새 스킬 추가, 기존 의미를 바꾸지 않는 설명 보강
주의가 필요한 변경: 스킬 설명 변경, 기본 출력 형식 변경, 응답 Artifact 구조 확장
호환성 깨짐 변경: 기존 필드 제거, 필수 입력 추가, 인증 방식 변경, 기존 스킬 의미 변경, 엔드포인트 변경
안전한 절차는 단순하다. 먼저 새 Agent Card를 검증 환경에 공개한다. 다음으로 TCK와 회귀 평가 시나리오를 실행한다. 이후 주요 클라이언트의 계약 테스트를 통과해야 한다. SDK를 재생성했다면 생성된 모델이 기존 요청과 응답을 여전히 읽을 수 있는지도 확인한다. 호환성이 깨지는 변경은 새 버전의 Agent Card나 새 엔드포인트로 나란히 제공하고, 기존 버전의 종료 일정을 명확히 공지한다.
A2A 명세가 업그레이드될 때도 같은 원칙을 적용한다. 명세의 새 기능을 쓰는 것과 기존 클라이언트를 깨뜨리는 것은 다른 문제다. 오래된 클라이언트가 모르는 필드를 무시할 수 있는지, 필수 필드가 늘어나지 않았는지, Task 상태 해석이 바뀌지 않았는지 확인해야 한다.
트레이싱과 감사 로그를 객체 단위로 연결하기
관측 가능성은 시스템 내부를 밖에서 이해할 수 있게 만드는 능력이다. A2A에서는 이 능력을 Task, Message, Artifact 단위로 설계해야 한다. 로그가 많아도 서로 연결되지 않으면 장애 분석에 도움이 되지 않는다.
모든 요청에는 최소한 다음 식별자를 연결한다.
trace_id 또는 correlation_id
task_id
context_id
message_id
artifact_id
호출한 에이전트와 호출받은 에이전트의 ID
사용자 또는 위임된 서비스 계정
스킬 이름과 Agent Card 버전
Task 상태와 상태 변경 시각
오류 코드와 재시도 횟수
이 식별자가 있으면 하나의 사용자 요청이 여러 에이전트를 거쳐도 흐름을 복원할 수 있다. 예를 들어 최종 보고서가 늦게 생성된 경우, 원인은 보고서 에이전트가 느린 것이 아니라 앞단의 데이터 수집 Task가 input-required 상태에서 6시간 동안 승인 대기였을 수 있다. 또는 Artifact는 생성되었지만 후속 에이전트가 기대한 JSON 스키마와 달라 실패했을 수도 있다.
감사 로그는 더 엄격하게 다뤄야 한다. 누가 어떤 권한으로 어떤 에이전트에 어떤 작업을 위임했는지, 어떤 Artifact가 생성되었는지, 어떤 정책 때문에 거절되었는지는 남겨야 한다. 하지만 민감한 원문 데이터, 토큰, 개인정보를 그대로 로그에 남기면 안 된다. 필요한 경우 원문 대신 해시, 참조 ID, 마스킹된 요약을 저장한다.
Google Cloud 환경에서는 Cloud Trace, Cloud Logging, Cloud Monitoring 같은 운영 도구를 사용해 추적, 로그, 지표, 알림을 구성할 수 있다.5 다만 도구보다 중요한 것은 표준화된 식별자와 이벤트 구조다. 어떤 플랫폼을 쓰든 Task와 Message, Artifact가 연결되어야 장애 원인을 찾을 수 있다.
평가 가능한 시스템만 개선할 수 있다
A2A는 에이전트가 서로 협업하게 해 주지만, 협업의 품질을 자동으로 보장하지는 않는다. 프로토콜을 지키는지 확인해야 하고, 결과가 업무 목표에 맞는지 평가해야 하며, 운영 중 어디서 느려지고 실패하는지 관측해야 한다.
좋은 A2A 시스템은 데모에서 한 번 성공한 시스템이 아니다. 실패했을 때 이유를 설명할 수 있고, 변경했을 때 무엇이 좋아졌는지 수치로 말할 수 있으며, 다른 구현과도 안정적으로 통신할 수 있는 시스템이다. 다중 에이전트 운영의 핵심은 더 많은 에이전트를 연결하는 것이 아니라, 연결된 협업을 추적 가능하고 평가 가능하게 만드는 데 있다.
참고
1Agent Discovery - A2A Protocol
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.