실전 프로젝트와 다음 단계

하나의 프로젝트로 묶어 보기

지금까지 우리는 A2A를 구성하는 조각을 따로 살펴보았다. Agent Card는 에이전트의 명함이었다. Task는 업무 티켓이었다. Message는 업무 중 오가는 대화였고, Artifact는 저장하고 재사용할 수 있는 공식 결과물이었다. JSON-RPC와 HTTP는 이 조각들이 네트워크를 건너가는 길이었고, 스트리밍과 알림은 긴 작업의 진행 상황을 알려 주는 신호등이었다.

마지막 장에서는 이 조각을 하나의 작동 가능한 시스템으로 연결한다. 예제로 만들 시스템은 시장 조사 보고서 생성 애플리케이션이다. 사용자가 "국내 전기차 충전 인프라 시장을 분석하고, 3년 진입 전략 보고서를 작성해 줘"라고 요청하면, 클라이언트 에이전트가 여러 전문 에이전트에게 일을 나누어 맡기고 최종 보고서를 만든다.

여기서 클라이언트 에이전트는 프로젝트 매니저에 가깝다. 사용자의 목표를 이해하고, 필요한 일을 나누고, 적절한 원격 에이전트를 선택한다. 원격 에이전트는 각 분야의 전문가다. 내부에서 어떤 모델과 도구를 쓰는지는 숨겨도 된다. 대신 A2A 인터페이스를 통해 자신이 무엇을 할 수 있고, 어떤 입력을 받고, 어떤 결과를 돌려주는지 분명히 알려야 한다.

A2A 공식 문서는 A2A를 서로 다른 에이전트가 공통 언어로 협업하게 하는 공개 표준으로 설명하며, 사용자, 클라이언트 에이전트, 원격 에이전트의 협업 구조를 중심에 둔다.¹ 이 프로젝트는 그 구조를 실제 애플리케이션 설계로 옮긴 것이다.

AI 생성 이미지

프로젝트 아키텍처

전체 구조는 네 층으로 나누어 생각하면 쉽다.

첫째, 사용자 인터페이스가 있다. 웹 화면, 채팅 UI, 사내 포털, CLI 중 무엇이든 가능하다. 사용자는 여기서 목표, 제약 조건, 원하는 출력 형식을 입력한다.

둘째, 오케스트레이터가 있다. 오케스트레이터는 A2A 클라이언트 역할을 한다. Agent Card를 읽어 에이전트 목록을 만들고, 사용자 요청을 하위 작업으로 나누고, 각 원격 에이전트에 Task를 보낸다.

셋째, 전문 에이전트 서버들이 있다. 이들은 모두 A2A 호환 서버로 노출된다.

넷째, 공통 운영 계층이 있다. Task 저장소, Artifact 저장소, 에이전트 카탈로그, 정책 엔진, 감사 로그, 비용 추적 대시보드가 여기에 속한다. 작은 실습에서는 메모리 저장소로 시작할 수 있다. 하지만 운영 환경에서는 재시작 후에도 Task 상태를 복구할 수 있어야 하므로 영속 저장소가 필요하다.

각 전문 에이전트는 내부적으로 MCP 서버를 사용할 수 있다. 예를 들어 조사 에이전트는 검색 도구를, 데이터 분석 에이전트는 데이터베이스 조회 도구를, 문서 작성 에이전트는 문서 저장소를 MCP로 사용할 수 있다. 외부 협업은 A2A로 하고, 내부 도구 접근은 MCP로 분리하면 책임 경계가 선명해진다.

예제 흐름: 요청에서 최종 보고서까지

사용자 요청은 다음과 같이 들어온다고 하자.

"국내 전기차 충전 인프라 시장을 조사하고, 중견 제조사가 진입할 수 있는 3년 전략 보고서를 작성해 줘. 투자 리스크와 파트너십 후보도 포함해 줘."

오케스트레이터는 이 요청을 바로 문서 작성 에이전트에게 넘기지 않는다. 먼저 업무를 나눈다.

1. 시장 현황과 정책 환경 조사

2. 수요·경쟁·가격 데이터 분석

3. 전략 보고서 초안 작성

4. 사실성·논리·보안 검토

5. 수정 반영 후 최종 보고서 생성

그다음 Agent Card 카탈로그에서 적합한 에이전트를 찾는다. 조사 에이전트가 market-research 스킬을 제공하고, 데이터 분석 에이전트가 tabular-analysis와 forecasting 스킬을 제공하며, 문서 작성 에이전트가 business-report-writing 스킬을 제공한다고 하자. 검토 에이전트는 fact-check와 policy-review 스킬을 제공한다.

실행 흐름은 다음과 같다.

User
  → Orchestrator
    → Research Agent: 시장·정책·경쟁 조사 Task
    → Data Analysis Agent: 수요·가격·성장률 분석 Task
    → Writing Agent: 조사/분석 Artifact 기반 보고서 초안 Task
    → Review Agent: 초안 검토 Task
    → Writing Agent: 검토 의견 반영 Task
  → User: 최종 보고서 Artifact

조사와 데이터 분석은 병렬로 실행할 수 있다. 두 작업은 서로의 결과를 기다리지 않아도 되기 때문이다. 반면 문서 작성은 조사 Artifact와 분석 Artifact가 있어야 시작할 수 있다. 검토는 초안이 나온 뒤에 수행된다. 이처럼 A2A 워크플로는 단순히 에이전트를 많이 호출하는 일이 아니다. 어떤 Task가 어떤 Artifact에 의존하는지 설계하는 일이다.

Task와 Artifact 설계

실전 프로젝트에서는 Task 이름보다 Task의 경계가 중요하다. 너무 큰 Task는 실패했을 때 원인을 찾기 어렵다. 너무 작은 Task는 호출 비용과 조율 비용이 커진다.

이 예제에서는 다음 정도의 단위가 적절하다.

Task R1: 시장 현황 조사
Task R2: 정책·규제 조사
Task D1: 수요 데이터 분석
Task D2: 경쟁사 비교 분석
Task W1: 보고서 초안 작성
Task V1: 사실성·정책 검토
Task W2: 최종본 작성

각 Task는 상태를 가진다. 처음에는 submitted, 실행 중에는 working, 추가 정보가 필요하면 input-required, 끝나면 completed가 된다. 실패하면 failed, 사용자가 중단하면 canceled가 된다.

Artifact는 다음 단계가 이해할 수 있도록 구조화하는 편이 좋다. 조사 에이전트가 단순한 긴 문단만 반환하면 데이터 분석이나 검토 에이전트가 재사용하기 어렵다. 대신 다음처럼 나누어 반환하게 한다.

research_summary.md
sources.json
key_findings.json
open_questions.json

데이터 분석 에이전트도 마찬가지다.

market_metrics.json
charts.zip
analysis_notes.md
assumptions.json

문서 작성 에이전트는 이 Artifact들을 입력으로 받아 draft_report.md를 만든다. 검토 에이전트는 초안을 직접 고치는 대신 review_findings.json과 revision_requests.md를 반환한다. 이렇게 하면 누가 어떤 판단을 했는지 추적하기 쉽다.

스트리밍과 사용자 개입 지점

보고서 생성은 시간이 걸리는 작업이다. 사용자가 아무런 피드백 없이 몇 분을 기다리게 하면 시스템을 신뢰하기 어렵다. 오케스트레이터는 message/stream이나 구독 흐름을 이용해 진행 상황을 보여 줄 수 있다.

예를 들어 화면에는 다음과 같은 상태가 표시된다.

조사 에이전트: 정책 자료 수집 중
데이터 분석 에이전트: 시장 규모 데이터 정리 중
문서 작성 에이전트: 대기 중
검토 에이전트: 대기 중

중간에 조사 에이전트가 "분석 범위를 공공 급속 충전소로 제한할까요, 민간 완속 충전까지 포함할까요?"라고 물으면 Task는 input-required가 된다. 이 상태는 실패가 아니다. 업무를 더 정확히 하기 위해 필요한 멈춤이다. 사용자가 답하면 같은 Task가 다시 진행된다.

스트리밍 이벤트는 사용자 경험을 좋게 만들지만, 최종 진실의 원천으로 삼으면 안 된다. 연결은 끊길 수 있고, 이벤트는 중복될 수 있다. 중요한 화면 전환이나 최종 보고서 다운로드 전에는 tasks/get으로 확정 상태와 최종 Artifact를 다시 확인하는 습관이 필요하다.

보안과 운영 기준을 처음부터 넣기

실전 프로젝트를 만들 때 가장 흔한 실수는 먼저 연결부터 하고, 보안과 운영은 나중에 붙이려는 것이다. A2A 애플리케이션에서는 초기에 다음 기준을 정해야 한다.

• 어떤 에이전트가 어떤 데이터에 접근할 수 있는가

• 사용자 요청과 내부 Artifact 중 무엇을 로그에 남길 것인가

• 민감 정보는 어느 단계에서 마스킹할 것인가

• 외부 에이전트에 보낼 수 없는 데이터는 무엇인가

• 실패한 Task를 자동 재시도할 것인가, 사람에게 넘길 것인가

• 최종 보고서에 포함된 근거를 어떻게 추적할 것인가

특히 보고서 생성 시스템에서는 출처와 가정이 중요하다. 최종 보고서만 저장하지 말고, 근거 Artifact와 검토 결과를 함께 보존해야 한다. 나중에 "왜 이런 결론이 나왔는가?"라는 질문에 답할 수 있어야 한다.

로그에는 본문 전체보다 식별자와 메타데이터를 남긴다. trace_id, task_id, 에이전트 이름, 스킬 ID, 상태 전환, 오류 코드, Artifact 해시, 저장 위치가 핵심이다. 민감한 고객 데이터나 내부 전략 문서를 그대로 로그에 남기면 관측성이 아니라 위험이 된다.

구현 순서

처음부터 완전한 멀티 에이전트 플랫폼을 만들 필요는 없다. 다음 순서로 확장하면 된다.

1단계: 단일 원격 에이전트
문서 요약 에이전트 하나를 A2A 서버로 만든다. Agent Card를 제공하고, message/send로 요청을 받아 짧은 Message 또는 Artifact를 반환한다.

2단계: 오케스트레이터 추가
클라이언트 에이전트가 Agent Card를 읽고, 사용자 요청을 적절한 에이전트로 라우팅하게 한다. 이 단계에서는 라우팅 규칙을 단순한 키워드 기반으로 시작해도 된다.

3단계: 두 개 이상의 전문 에이전트 연결
조사 에이전트와 문서 작성 에이전트를 순차로 연결한다. 조사 결과 Artifact가 문서 작성 Task의 입력이 되도록 만든다.

4단계: 병렬 작업과 검토 단계 추가
조사와 데이터 분석을 병렬로 실행하고, 두 결과를 문서 작성 에이전트에 전달한다. 이후 검토 에이전트를 붙여 최종 품질을 높인다.

5단계: 운영 기능 강화
영속 Task 저장소, Artifact 저장소, 인증, 권한 부여, 감사 로그, 스트리밍, 푸시 알림, 비용 추적을 추가한다.

이 순서를 따르면 학습과 운영의 부담을 나눌 수 있다. A2A는 한 번에 모든 것을 바꾸는 방식보다, 기존 에이전트를 표준 인터페이스로 감싸고 점진적으로 연결하는 방식에 잘 맞는다.

계속 학습하는 경로

다음 단계에서는 공식 자료와 샘플을 직접 실행해 보는 것이 좋다. A2A GitHub 저장소는 사양, 문서, 샘플, SDK, 토론과 이슈 추적을 찾는 출발점이다.² SDK는 Python, JavaScript, Go, Java, .NET, Rust 등 여러 언어 생태계로 확장되고 있으므로 자신이 쓰는 언어에서 시작하면 된다.³

학습 순서는 다음을 추천한다.

1. 공식 문서에서 Agent Card, Task, Message, Artifact 모델을 다시 읽는다.

2. GitHub 샘플을 실행해 A2A 서버와 클라이언트의 기본 흐름을 확인한다.

3. Python SDK나 JavaScript SDK 중 하나로 작은 에이전트를 만든다.

4. ADK, LangGraph, LangChain, Semantic Kernel 등 기존 에이전트 프레임워크로 만든 에이전트를 A2A 서버로 감싸 본다.

5. MCP 서버를 하나 붙여 내부 도구 접근과 외부 에이전트 협업을 분리해 본다.

6. 스트리밍, 인증, 감사 로그를 추가해 운영형 구조로 확장한다.

실습형 자료가 필요하다면 A2A Walkthrough 저장소가 도움이 된다. 이 자료는 독립 실행되는 에이전트 서버, A2A 클라이언트, 순차·계층형 오케스트레이션, MCP 연동 패턴을 단계적으로 보여 준다.⁴ DeepLearning.AI의 A2A 과정도 여러 프레임워크로 만든 전문 에이전트를 A2A 서버로 노출하고, 클라이언트와 오케스트레이터로 연결하는 흐름을 다룬다.⁵

앞으로의 발전 방향

A2A 생태계는 아직 빠르게 발전하는 중이다. 따라서 지금 만든 설계는 특정 버전의 세부 구현에 너무 강하게 묶이지 않는 편이 좋다. 특히 다음 방향을 주목할 만하다.

첫째, 에이전트 발견 방식의 확장이다. 현재 Agent Card는 에이전트의 능력과 호출 조건을 알려 주는 기본 단위다. 앞으로는 권한 체계, 선택적 자격 증명, 레지스트리 기반 검색, 동적으로 스킬을 질의하는 방식이 더 중요해질 수 있다. 정적인 명함에서 더 똑똑한 카탈로그로 발전하는 흐름이다.

둘째, 동적 UX 협상이다. 동적 UX 협상은 작업 도중 상호작용 방식이 바뀌는 상황을 뜻한다. 처음에는 텍스트로 시작했지만, 중간에 표 업로드가 필요하거나, 차트 확인 UI가 필요하거나, 음성·영상 입력이 필요한 경우가 있다. A2A가 이런 변화를 더 잘 표현하게 되면 에이전트 협업은 단순 채팅을 넘어 업무 화면과 결합될 수 있다.

셋째, 스트리밍과 푸시 알림의 신뢰성 개선이다. 긴 작업에서는 연결 끊김, 중복 이벤트, 늦게 도착한 이벤트, 알림 실패가 자주 문제가 된다. 앞으로의 발전은 이런 상황에서도 Task 상태와 Artifact를 안정적으로 동기화하는 방향으로 이어질 가능성이 높다.

넷째, 클라이언트 주도 협업 방식의 확장이다. 지금은 Task 생성, 조회, 취소, 스트리밍 같은 흐름이 중심이지만, 복잡한 협업에서는 클라이언트가 더 다양한 방식으로 원격 에이전트와 협상해야 할 수 있다. 예를 들어 "이 스킬을 이 조건으로 수행할 수 있는가?", "이 Artifact 형식으로 반환할 수 있는가?", "이 비용 한도 안에서 가능한가?" 같은 사전 조율이 중요해진다.

A2A GitHub 저장소의 로드맵성 논의에서도 에이전트 발견, 동적 스킬 확인, Task 중 UX 협상, 스트리밍 신뢰성, 푸시 알림 개선 같은 주제가 언급된다.² 실전 설계자는 이 변화를 예상하고, 내부 코드를 느슨하게 결합해야 한다. 프로토콜 세부사항이 바뀌어도 오케스트레이터, 정책 엔진, Artifact 저장소, 개별 에이전트 로직이 한꺼번에 흔들리지 않게 만드는 것이 중요하다.

마지막 정리

A2A의 핵심은 에이전트를 하나의 거대한 시스템으로 합치는 것이 아니다. 서로 다른 팀, 다른 프레임워크, 다른 보안 경계 안에 있는 에이전트들이 업무를 맡기고, 상태를 공유하고, 결과를 검증할 수 있는 공통 접점을 만드는 것이다.

실전 프로젝트를 시작할 때는 작은 범위로 충분하다. Agent Card 하나, message/send 하나, Task 저장소 하나로 시작해도 된다. 중요한 것은 처음부터 다음 질문을 놓치지 않는 것이다.

• 이 에이전트는 어떤 책임을 지는가?

• 입력과 출력은 어떤 형식으로 계약할 것인가?

• 중간 상태와 실패는 어떻게 표현할 것인가?

• Artifact는 다음 단계에서 재사용 가능한가?

• 보안 경계와 감사 기록은 충분한가?

• 사용자는 진행 상황과 최종 근거를 이해할 수 있는가?

이 질문에 답할 수 있다면 A2A는 단순한 연결 기술을 넘어, 운영 가능한 멀티 에이전트 시스템의 기반이 된다. 이제 남은 일은 하나의 작은 에이전트를 만들고, 그것을 A2A로 노출한 뒤, 다른 에이전트와 연결해 보는 것이다. 그 작은 연결이 곧 더 큰 에이전트 생태계의 출발점이다.

참고

¹A2A Protocol

²Agent2Agent (A2A) GitHub Repository

³A2A SDK

⁵DeepLearning.AI A2A Course