멀티 에이전트 워크플로 패턴

워크플로는 호출 순서가 아니라 책임 배치다

A2A를 안다는 것은 message/send를 호출할 수 있다는 뜻만은 아니다. 실제 시스템에서는 "어떤 에이전트에게 어떤 책임을 맡기고, 결과를 어디서 검증하며, 사람이 언제 개입할 것인가"를 정해야 한다. 이것이 멀티 에이전트 워크플로다.

워크플로는 공장의 컨베이어벨트와 비슷하다. 원재료가 들어오면 한 작업자가 자르고, 다음 작업자가 조립하고, 마지막 작업자가 검수한다. 단, AI 에이전트 워크플로에서는 각 작업자가 서로 다른 회사, 다른 프레임워크, 다른 보안 경계 안에 있을 수 있다. A2A는 이들이 같은 내부 구조를 갖지 않아도 업무를 주고받을 수 있게 하는 공통 협업 규칙이다. 공식 설명에서도 A2A는 서로 다른 에이전트가 통신하고 협업하기 위한 공개 표준으로 설명된다.¹

이 장에서는 대표적인 네 가지 패턴을 본다.

• 순차형 워크플로

• 계층형 워크플로

• 전문가 위원회형 워크플로

• human-in-the-loop 워크플로

각 패턴은 서로 배타적이지 않다. 실전 시스템에서는 순차형 흐름 안에 계층형 위임이 들어가고, 마지막 검토 단계에서 전문가 위원회와 사람 승인이 함께 쓰이기도 한다.

AI 생성 이미지

순차형: 조사, 분석, 작성이 차례로 이어지는 흐름

순차형 워크플로는 앞 단계의 결과가 다음 단계의 입력이 되는 구조다. 가장 이해하기 쉬운 패턴이다. 예를 들어 "신규 시장 진출 보고서를 만들어 달라"는 요청을 다음처럼 나눌 수 있다.

1. 조사 에이전트가 시장 자료를 수집한다.

2. 분석 에이전트가 자료를 비교하고 의미를 뽑아낸다.

3. 작성 에이전트가 최종 보고서로 정리한다.

여기서 조사 에이전트, 분석 에이전트, 작성 에이전트는 모두 원격 에이전트가 될 수 있다. 원격 에이전트는 네트워크 너머에 있는 협업 상대라는 뜻이다. 반드시 멀리 있는 서버라는 의미보다, 클라이언트가 내부 구현을 직접 통제하지 않는 상대라고 이해하면 쉽다.

A2A 관점에서 순차형 흐름은 Task와 Artifact의 연결이다. Task는 업무 티켓이고, Artifact는 그 업무가 만든 공식 산출물이다. 조사 에이전트의 Artifact가 분석 에이전트의 Message 입력이 되고, 분석 에이전트의 Artifact가 작성 에이전트의 입력이 된다.

사용자 요청
  ↓
[Task A] 조사 에이전트 → Artifact: 자료 묶음
  ↓
[Task B] 분석 에이전트 → Artifact: 인사이트 목록
  ↓
[Task C] 작성 에이전트 → Artifact: 최종 보고서

이 패턴의 장점은 추적이 쉽다는 점이다. 어느 단계에서 실패했는지 분명하다. 조사 결과가 부족하면 분석 에이전트를 탓하기 전에 조사 Task를 다시 실행하거나 보강하면 된다. 또한 각 단계의 Artifact를 저장해 두면 나중에 결과를 감사하거나 재사용하기 쉽다.

하지만 순차형은 느려질 수 있다. 세 단계가 반드시 차례대로 끝나야 하므로 전체 시간은 각 단계의 합이 된다. 따라서 순차형을 설계할 때는 "정말 앞 단계 전체가 끝나야 다음 단계가 가능한가"를 따져야 한다. 예를 들어 시장 규모 조사와 경쟁사 조사는 병렬로 실행한 뒤, 분석 단계에서 합쳐도 된다.

순차형에서 중요한 설계 원칙은 Artifact의 계약을 명확히 하는 것이다. 조사 에이전트가 자유 형식의 긴 텍스트만 반환하면 분석 에이전트가 매번 해석 부담을 떠안는다. 반대로 조사 Artifact에 출처, 날짜, 지역, 신뢰도, 핵심 수치 같은 구조화된 필드를 포함하면 다음 단계의 품질이 안정된다.

계층형: 매니저 에이전트가 일을 나누고 통합한다

계층형 워크플로는 한 명의 매니저가 여러 전문가에게 일을 나눠 맡기는 구조다. 여기서 매니저 에이전트는 클라이언트 에이전트 역할을 한다. 클라이언트 에이전트는 단순 호출자가 아니라, 사용자의 목표를 해석하고 적절한 원격 에이전트를 선택해 결과를 통합하는 조율자다.

예를 들어 기업 내부의 "분기별 리스크 점검" 에이전트를 생각해 보자.

• 법무 에이전트: 계약과 규제 리스크를 검토한다.

• 보안 에이전트: 시스템 취약점과 접근 권한 문제를 검토한다.

• 재무 에이전트: 비용, 매출, 예산 초과 가능성을 검토한다.

• 매니저 에이전트: 각 결과를 받아 우선순위와 실행 계획으로 통합한다.

이때 매니저 에이전트는 먼저 Agent Card를 통해 각 에이전트의 능력과 입력 형식, 인증 조건을 확인한다. 그런 다음 하위 Task를 만든다. 각 Task는 독립적인 상태를 가진다. 어떤 Task는 completed가 되고, 어떤 Task는 input-required가 될 수 있으며, 어떤 Task는 failed가 될 수 있다.

계층형 패턴의 핵심은 "위임하되 방치하지 않는 것"이다. 매니저 에이전트는 하위 에이전트에게 일을 맡기지만, 전체 목표와 품질 책임은 계속 갖고 있어야 한다. 원격 에이전트가 반환한 Artifact를 그대로 붙여 최종 답으로 내보내면 통합이 아니라 단순 취합에 가깝다.

좋은 매니저 에이전트는 다음 일을 한다.

• 사용자 목표를 하위 작업으로 나눈다.

• 각 하위 작업에 적합한 에이전트를 고른다.

• Task ID와 상태를 추적한다.

• 각 Artifact의 범위와 한계를 확인한다.

• 충돌하는 결과를 조정한다.

• 최종 사용자에게 하나의 일관된 결과를 제공한다.

Google이 A2A를 소개할 때 강조한 문제의식도 이와 맞닿아 있다. 여러 벤더와 프레임워크의 에이전트가 기업 환경에서 정보를 교환하고 행동을 조율해야 하며, 긴 작업에 대해서는 상태 업데이트와 알림이 필요하다는 것이다.² 계층형 워크플로는 이런 요구를 가장 직접적으로 드러내는 패턴이다.

다만 매니저 에이전트가 너무 많은 판단을 혼자 맡으면 병목이 된다. 모든 세부 결정을 중앙에서 처리하면 하위 전문 에이전트의 장점이 줄어든다. 따라서 매니저는 목표, 제약, 평가 기준을 분명히 주고, 세부 수행 방식은 전문 에이전트에게 맡기는 편이 좋다.

전문가 위원회형: 여러 의견을 비교하고 검증한다

전문가 위원회형 워크플로는 여러 에이전트에게 같은 문제 또는 서로 다른 관점의 문제를 맡긴 뒤, 결과를 비교해 더 신뢰할 수 있는 결론을 만드는 구조다. 회의실에 여러 전문가를 불러 의견을 듣는 모습과 비슷하다.

예를 들어 "새 제품 출시 전략이 타당한가"라는 질문이 있다면 다음처럼 구성할 수 있다.

• 시장 전문가 에이전트: 고객 수요와 경쟁 구도를 평가한다.

• 기술 전문가 에이전트: 구현 가능성과 기술 부채를 평가한다.

• 재무 전문가 에이전트: 비용, 가격, 손익분기점을 평가한다.

• 리스크 검토 에이전트: 법무, 보안, 평판 리스크를 평가한다.

• 조정 에이전트: 의견을 비교하고 최종 권고안을 만든다.

이 패턴은 단일 에이전트의 편향이나 누락을 줄이는 데 유용하다. 하나의 모델이나 하나의 도구 체인에 의존하지 않고, 서로 다른 전문성의 결과를 나란히 놓고 볼 수 있기 때문이다. A2A는 각 전문가를 독립적인 원격 에이전트로 다룰 수 있게 하므로, 내부 프롬프트나 도구 구성을 공유하지 않아도 의견 수렴이 가능하다. A2A 기반 협업 설계에서는 에이전트의 내부를 비공개로 유지하면서 표준화된 메시지와 Artifact로 협업하는 접근이 권장된다.³

위원회형에서 조심할 점은 "다수결이 항상 정답은 아니다"라는 점이다. 세 에이전트가 같은 잘못된 자료를 보고 같은 결론을 낼 수도 있다. 따라서 조정 에이전트는 단순 투표보다 근거의 품질을 평가해야 한다.

좋은 조정 기준은 다음과 같다.

• 어떤 출처나 데이터에 근거했는가?

• 가정이 명시되어 있는가?

• 반대 근거를 검토했는가?

• 결론의 확신도와 불확실성이 구분되어 있는가?

• 다른 에이전트의 결과와 충돌하는 지점은 어디인가?

A2A로 구현할 때는 각 전문가 의견을 별도 Task와 Artifact로 남기는 편이 좋다. 그래야 나중에 최종 결론이 왜 나왔는지 추적할 수 있다. 최종 Artifact에는 "합의된 결론"뿐 아니라 "의견 차이가 남은 쟁점"도 포함해야 한다. 특히 엔터프라이즈 환경에서는 반대 의견이 사라진 깔끔한 보고서보다, 판단의 근거와 남은 위험이 보이는 보고서가 더 유용하다.

Human-in-the-loop: 사람을 예외가 아니라 참여자로 설계한다

모든 결정을 에이전트에게 맡길 수는 없다. 결제 승인, 계약 발송, 고객 보상, 개인정보 접근, 대외 공지처럼 책임이 큰 작업에는 사람의 승인이나 추가 입력이 필요하다. human-in-the-loop는 사람이 중간에 개입하는 설계다.

A2A에서는 이를 태스크 흐름 안에 자연스럽게 배치할 수 있다. 원격 에이전트가 작업을 진행하다가 정보가 부족하거나 승인이 필요하면 Task 상태를 input-required로 둘 수 있다. input-required는 실패가 아니다. "계속하려면 입력이 필요하다"는 정상적인 대기 상태다.

예를 들어 구매 요청 워크플로를 보자.

사용자: 노트북 30대를 구매해 줘.
  ↓
구매 매니저 에이전트: 예산 확인 Task 생성
  ↓
공급사 비교 에이전트: 견적 Artifact 반환
  ↓
구매 매니저 에이전트: 승인 필요 → input-required
  ↓
사람 승인자: A안을 승인
  ↓
구매 매니저 에이전트: 발주 Task 진행

이 구조에서 사람은 시스템 밖의 방해물이 아니다. 워크플로의 한 참여자다. 에이전트는 사람에게 필요한 판단 자료를 Message로 제공하고, 사람의 응답을 받아 Task를 이어 간다. 긴 작업이라면 스트리밍 업데이트나 푸시 알림을 통해 "승인 대기", "검토 완료", "발주 진행 중" 같은 상태를 알려 줄 수 있다. IBM의 A2A 설명에서도 원격 에이전트가 추가 정보가 필요할 때 클라이언트 에이전트에 요청하고, 긴 작업에서는 SSE나 웹훅 기반 업데이트를 사용할 수 있다고 설명한다.⁴

human-in-the-loop를 설계할 때 중요한 것은 승인 지점을 미리 정하는 것이다. 모든 단계마다 사람에게 묻는 시스템은 느리고 피곤하다. 반대로 아무 단계에서도 묻지 않는 시스템은 위험하다. 다음 기준을 사용할 수 있다.

• 비용이 일정 금액을 넘는가?

• 외부 고객이나 파트너에게 영향을 주는가?

• 민감한 데이터 접근이 필요한가?

• 법적 책임이나 계약상 의무가 생기는가?

• 에이전트의 확신도가 낮거나 결과가 충돌하는가?

사람에게 요청하는 Message도 잘 설계해야 한다. "승인하시겠습니까?"만 보내면 부족하다. 승인자가 빠르게 판단할 수 있도록 선택지, 근거, 위험, 되돌릴 수 있는지 여부를 함께 제공해야 한다. 또한 승인 결과는 Artifact나 감사 로그와 연결되어야 한다. 나중에 누가, 언제, 어떤 근거로 승인했는지 확인할 수 있어야 한다.

패턴 선택 기준

워크플로 패턴은 업무 성격에 맞춰 고른다.

처음부터 복잡한 구조를 만들 필요는 없다. 작은 순차형 워크플로로 시작해도 충분하다. 이후 병렬화가 필요한 지점, 전문 검토가 필요한 지점, 사람 승인이 필요한 지점을 발견하면서 계층형과 위원회형을 추가하면 된다.

중요한 것은 A2A가 워크플로 자체를 대신 설계해 주지는 않는다는 점이다. A2A는 에이전트 발견, Task 전달, 상태 추적, Message 교환, Artifact 반환을 위한 공통 언어를 제공한다. 하지만 어떤 책임을 누구에게 맡길지, 어떤 결과를 신뢰할지, 언제 사람에게 멈춰 물어볼지는 설계자의 몫이다.

멀티 에이전트 시스템의 품질은 에이전트 수가 아니라 경계의 선명함에서 나온다. 각 에이전트가 무엇을 잘하고, 어떤 입력을 받고, 어떤 Artifact를 돌려주며, 실패하면 누가 복구할지를 분명히 해야 한다. 그 경계가 명확할수록 A2A 워크플로는 더 예측 가능하고 운영하기 쉬워진다.

참고

¹A2A Protocol

²Announcing the Agent2Agent Protocol (A2A)

³Designing Collaborative Multi-Agent Systems with the A2A Protocol

⁴What is A2A protocol (Agent2Agent)?