A2A(Agent2Agent)는 이름 그대로 에이전트와 에이전트가 상호작용할 수 있게 만드는 구조적 접근이다.
핵심은 단순하다.
https://codelabs.developers.google.com/intro-a2a-purchasing-concierge?hl=ko#0 (이거 봐라 잘 나와있다.)
- 에이전트 하나가 모든 일을 다 하도록 만드는 대신,
- 역할이 다른 여러 에이전트가 협업하도록 설계한다.
많은 팀이 에이전트를 도입할 때 처음에는 “성능 좋은 모델 하나”에 집중한다. 하지만 운영 단계로 가면 진짜 문제는 모델 성능보다 작업 분해, 통신 계약, 실패 복구, 추적 가능성에서 발생한다. A2A 아키텍처는 바로 이 운영 문제를 풀기 위한 프레임이다.
이 글은 A2A를 유행어가 아니라 실제 설계 관점에서 설명한다.
1) 왜 A2A가 필요한가
단일 에이전트 구조는 시작이 쉽다. 프롬프트 하나로 많은 일을 처리할 수 있다.
하지만 작업이 길어지고 팀 단위 협업으로 넘어가면 한계가 빠르게 드러난다.
단일 에이전트의 대표 한계
-
컨텍스트 과부하
조사, 생성, 검증, 배포 판단까지 한 맥락에 밀어 넣으면 품질 편차가 커진다. -
책임 경계 부재
실패했을 때 어디서 잘못됐는지 추적이 어렵다. -
재사용성 낮음
특정 작업에 맞춘 프롬프트/로직이 다른 작업에 그대로 재사용되기 어렵다. -
운영 위험 증가
권한이 한 에이전트에 과도하게 몰리면 보안·안정성 리스크가 커진다.
A2A는 이 문제를 역할 분리로 해결한다.
- Planner: 작업 분해/순서 결정
- Researcher: 근거 수집
- Builder: 산출물 생성
- Critic: 검증/리뷰
- Orchestrator: 전체 흐름 제어
즉, “한 명의 만능 인턴” 대신 “역할 있는 팀”으로 바꾸는 개념이다.
2) A2A의 본질: 모델이 아니라 계약(Contract)
A2A를 제대로 구현하려면 제일 먼저 정해야 하는 건 모델이 아니라 통신 계약이다.
계약에 포함되어야 할 최소 항목
- 입력 스키마(필수/선택 필드)
- 출력 스키마(성공/실패 형태)
- 상태 코드 또는 결과 타입
- 타임아웃/재시도 정책
- 오류 시 에스컬레이션 규칙
예를 들어,
- Planner가 Worker에게 보낼 때는
task_id,goal,constraints,deadline이 필수 - Worker가 응답할 때는
status,artifact_uri,confidence,error_reason을 고정
이런 구조가 없으면 에이전트끼리 대화는 되는데 운영은 안 된다.
3) A2A 아키텍처의 기본 레이어
A2A를 시스템처럼 설계하려면 레이어를 나눠 보는 게 좋다.
3-1. Coordination Layer
- 작업 큐
- 라우팅
- 스케줄링
- 우선순위
어떤 작업을 어느 에이전트가 언제 처리할지 결정하는 층이다.
3-2. Communication Layer
- 메시지 포맷
- 요청/응답 계약
- correlation id
- retry/timeout
에이전트 간 대화의 신뢰성을 담당한다.
3-3. Capability Layer
- 각 에이전트의 역할과 도구 권한
- 모델/툴 조합
- 정책 제약
“누가 무엇을 할 수 있는가”를 정의한다.
3-4. Observability Layer
- 로그
- 트레이스
- 메트릭
- 감사(audit)
운영 단계에서 문제를 진단할 수 있게 해준다.
3-5. Governance Layer
- 권한 경계
- 민감 작업 승인
- 데이터 보존/마스킹
조직에서 실제로 굴릴 수 있게 만드는 안전장치다.
4) 실무 설계 원칙 8가지
A2A 설계를 잘하려면 아래 원칙을 지키는 것이 중요하다.
원칙 1. Contract-first
코드보다 먼저 입출력 스키마를 고정한다.
원칙 2. Idempotency
같은 요청이 두 번 들어와도 결과가 꼬이지 않게 한다.
원칙 3. Deterministic envelope
메시지 외피(메타데이터)는 항상 동일 구조로 유지한다.
원칙 4. Least privilege
각 에이전트는 자기 역할에 필요한 최소 권한만 가진다.
원칙 5. Timeout + Retry + Backoff
실패를 예외가 아니라 기본 경로로 취급한다.
원칙 6. Human gate for critical actions
배포, 삭제, 외부 발송 같은 민감 작업은 승인 게이트를 둔다.
원칙 7. Observable by default
모든 요청은 trace id를 가지고, 모든 단계는 로그가 남아야 한다.
원칙 8. Progressive rollout
처음부터 전체 자동화하지 말고 작게 시작해 확장한다.
5) 대표 패턴
A2A는 구조를 어떻게 짜느냐에 따라 품질이 크게 달라진다.
5-1. Fan-out / Fan-in
- 작업을 여러 Worker로 병렬 분산(Fan-out)
- 결과를 Aggregator가 통합(Fan-in)
리서치, 로그 분석, 코드 후보 생성에 특히 유용하다.
5-2. Critic Loop
- Builder가 초안을 만든다
- Critic이 검증한다
- 기준 미달이면 재생성한다
품질 기준을 강제할 수 있다.
5-3. Planner-Executor-Supervisor
- Planner: 계획 수립
- Executor: 실행
- Supervisor: 정책/품질 체크
운영형 자동화에서 안정적인 패턴이다.
5-4. Escalation Pattern
신뢰도 낮음/오류 반복/정책 충돌 시 사람에게 즉시 전달한다.
6) 실패 사례에서 배우는 A2A 안티패턴
안티패턴 1. “에이전트 수 늘리기 = 고도화” 착각
역할은 늘었는데 계약과 책임이 없으면 혼란만 커진다.
안티패턴 2. 공통 포맷 부재
에이전트마다 다른 응답 형식 쓰면 통합 단계가 깨진다.
안티패턴 3. 무제한 권한
편해서 모든 도구 권한을 주면 보안 리스크가 폭증한다.
안티패턴 4. 로그 없는 자동화
실패 이유를 모르면 개선이 불가능하다.
안티패턴 5. 사람 승인 없는 완전자동
민감 작업까지 자동화하면 작은 오류가 큰 사고로 이어질 수 있다.
7) A2A 품질을 측정하는 핵심 지표
A2A 운영은 감으로 하면 안 된다. 최소 지표를 정해야 한다.
- Task success rate
- 평균 처리 시간(P50/P95)
- 재시도율
- 에스컬레이션 비율
- 에이전트별 오류 분포
- 승인 대기 시간
- 롤백 발생률
특히 중요한 건 실패 사유 상위 5개를 매주 보는 것이다.
8) 보안/거버넌스: A2A에서 특히 중요한 이유
A2A는 에이전트 수가 늘어나는 구조라 공격면도 커진다. 따라서 기본 보안이 필수다.
- 메시지 서명/검증
- 역할 기반 권한 분리
- 민감데이터 마스킹
- 감사 로그 불변성
- 비밀키/토큰 보관 정책
- 외부 호출 allowlist
“작동한다”와 “운영 가능하다”는 다르다. 보안이 빠지면 A2A는 실무에서 오래 못 간다.
9) A2A를 도입할 때 가장 현실적인 질문
- 이 작업은 정말 분리가 필요한가?
- 사람 승인 없이 실행해도 안전한가?
- 실패했을 때 10분 내 원인 파악 가능한가?
- 누가 최종 책임자인가?
- 한 달 뒤 유지보수 담당이 바뀌어도 운영 가능한가?
이 질문에 답하지 못하면, 구현보다 설계를 먼저 해야 한다.
10) 결론
A2A는 “에이전트끼리 대화한다”는 아이디어가 핵심이 아니다.
진짜 핵심은:
- 역할 분리
- 계약 기반 통신
- 실패를 전제로 한 복구 설계
- 관측 가능성과 승인 체계
즉, A2A는 모델 성능 경쟁이 아니라 운영 가능한 협업 시스템 설계의 문제다.
이 원칙을 지키면 A2A는 데모 기술이 아니라, 실제 조직 생산성을 올리는 구조가 된다.
11) 요약
A2A는 “AI를 여러 개 붙이는 기술”이 아니다.
역할과 계약이 있는 협업 시스템을 만드는 기술이다.
- 한 에이전트가 모든 것을 잘하는 시대에서,
- 여러 에이전트가 각자 잘하는 일을 합쳐서,
- 검증 가능한 결과를 만드는 구조로 이동하는 것.
그게 A2A의 본질이다.
출처
- A2A 프로젝트(공식): https://github.com/a2aproject/A2A
- Google 레퍼런스 링크(리다이렉트): https://github.com/google/A2A
