ADK Go 2.0 멀티 에이전트 설계법: graph, HITL, retry로 운영 장애 줄이기

ADK Go 2.0 멀티 에이전트 설계의 핵심은 ‘에이전트를 많이 붙이는 것’이 아니라 실행 흐름을 graph로 명시하는 것이다. Google은 2026년 6월 ADK for Go 2.0을 공개하며 graph-based workflow engine, built-in human-in-the-loop, dynamic orchestration, retry와 concurrency control을 주요 변화로 소개했다. Go로 production agent를 만들던 팀이라면 이번 업데이트를 단순 SDK 버전업이 아니라 운영 모델 변화로 봐야 한다.

왜 멀티 에이전트가 쉽게 망가지는가

처음에는 단일 agent로 충분해 보인다. 사용자 요청을 받고, 도구를 호출하고, 답변을 만들면 된다. 하지만 기능이 늘어나면 흐름이 복잡해진다. 요청을 분류해야 하고, specialist agent를 병렬로 호출해야 하고, 결과를 합쳐야 하고, 위험한 작업은 사람 승인을 받아야 한다. 실패하면 재시도해야 하고, 중간에 프로세스가 재시작되어도 이어서 실행해야 한다.

이 과정을 ad-hoc if문과 goroutine으로 만들면 처음에는 빠르지만 곧 운영이 어려워진다. 어느 branch가 실행됐는지 추적하기 어렵고, partial failure를 처리하기 어렵고, 사람이 승인한 뒤 어디서 재개해야 하는지 모호해진다. 멀티 에이전트 장애는 모델 품질보다 orchestration 부실에서 자주 발생한다.

ADK Go 2.0의 graph-first 접근은 이 문제를 구조적으로 다룬다. 작업 단위를 node로 만들고, node 사이의 edge와 route를 정의한다. 실행은 scheduler가 맡고, state persistence, pause/resume, fan-out/fan-in, retry, concurrency limit을 workflow 안에서 관리한다.

graph로 표현하면 무엇이 좋아지나

Google의 발표에 따르면 ADK 2.0에서는 Function node, Emitting function node, Agent node, Tool node, Join node, Dynamic node, Workflow node, Parallel worker, State-bound node 같은 building block을 제공한다. 핵심은 모든 작업을 graph의 node로 표현할 수 있다는 점이다.

예를 들어 고객 문의 처리 agent를 생각해 보자.

Start
  -> classify_request
  -> route by category
    -> billing_agent
    -> technical_agent
    -> security_agent
  -> join_results
  -> risk_check
  -> human_approval if needed
  -> final_response

이 흐름을 코드 곳곳의 조건문으로 흩뿌리면 관찰과 테스트가 어렵다. 반면 graph로 만들면 어떤 route가 실행됐는지, 어디서 멈췄는지, 어떤 node가 실패했는지 로그와 telemetry에서 보기 쉬워진다. 특히 production에서는 ‘왜 이 답변이 나왔는가’를 설명해야 할 때가 많다. graph는 답변 생성 경로를 남기는 데 유리하다.

HITL은 기능이 아니라 안전장치다

human-in-the-loop, 즉 HITL은 데모에서는 승인 버튼처럼 보인다. 하지만 운영에서는 훨씬 중요하다. 환불 승인, 계정 정지, 배포 실행, 개인정보 접근, 대량 이메일 발송처럼 agent가 단독으로 실행하면 안 되는 작업을 멈추는 안전장치다.

ADK Go 2.0은 node가 중간에 pause하고 사람에게 입력을 요청한 뒤, 나중에 답을 받아 workflow를 재개할 수 있는 구조를 제공한다. 발표 글에는 NewRequestInputEvent로 승인 질문을 만들고, Handoff 또는 Re-entry 방식으로 이어갈 수 있다고 설명되어 있다. 또한 session에 run state가 남기 때문에 프로세스 재시작 후에도 workflow를 복구할 수 있다.

실무에서 HITL을 넣을 때는 질문 문구보다 schema가 중요하다. 사람이 ‘네’라고 답했는지, 어떤 금액까지 승인했는지, 어떤 리소스에 대해 승인했는지 구조화해서 남겨야 한다. 그렇지 않으면 감사 로그가 애매해지고, 같은 승인을 다른 작업에 잘못 재사용할 위험이 생긴다.

권장되는 승인 이벤트에는 최소한 다음 필드가 필요하다.

{
  `action`: `approve_refund`,
  `resource_id`: `refund_123`,
  `amount`: 200,
  `currency`: `USD`,
  `risk_level`: `medium`,
  `expires_at`: `2026-07-16T15:00:00Z`
}

승인은 모호한 대화가 아니라 만료 시간이 있는 구조화된 decision이어야 한다.

retry와 concurrency를 먼저 설계하라

멀티 에이전트 시스템은 실패가 정상이다. 외부 API가 timeout 될 수 있고, 도구 호출이 rate limit에 걸릴 수 있고, LLM 응답이 schema 검증에 실패할 수 있다. ADK Go 2.0은 node별 retry policy, exponential backoff, jitter, timeout, graph-wide concurrency cap을 제공한다고 설명한다. 이 기능은 선택 사항이 아니라 production 기본값으로 봐야 한다.

재시도 정책은 작업별로 달라야 한다. 검색 API timeout은 2~3회 재시도할 수 있다. 결제 승인 같은 쓰기 작업은 idempotency key 없이는 재시도하면 안 된다. LLM JSON 형식 오류는 같은 모델에 한 번 재요청하고, 실패하면 더 강한 모델이나 사람 검토로 넘길 수 있다.

concurrency도 마찬가지다. fan-out으로 specialist agent를 20개 동시에 실행하면 속도는 빨라질 수 있지만 비용, rate limit, 로그 복잡도가 폭발한다. graph-wide concurrency cap을 두고, branch별 timeout을 정해야 한다. 특히 사용자 요청 하나가 내부적으로 여러 agent를 호출하는 구조에서는 요청당 최대 비용을 계산해야 한다.

dynamic orchestration은 남용하면 안 된다

ADK Go 2.0은 실행 순서가 런타임에 결정되는 경우를 위해 Dynamic node를 제공한다. 일반 Go 코드 안에서 child node를 실행하고, loop와 조건을 표현할 수 있다. 이 기능은 강력하지만, 모든 것을 dynamic node로 만들면 graph의 장점이 줄어든다.

기본 흐름은 edge와 route로 명시하고, 정말 데이터에 따라 개수가 바뀌거나 반복 횟수가 정해지지 않는 부분만 dynamic node로 빼는 것이 좋다. 예를 들어 문서 100개를 평가해야 하는 작업에서 문서 수에 따라 parallel worker를 돌리는 것은 dynamic orchestration의 좋은 사례다. 반대로 결제 승인 흐름처럼 규칙이 명확한 업무를 dynamic node 안의 복잡한 if문으로 숨기는 것은 좋지 않다.

운영팀이 graph를 봤을 때 주요 경로를 이해할 수 있어야 한다. dynamic node는 탈출구이지 기본 설계 방식이 아니다.

observability는 처음부터 넣어야 한다

멀티 에이전트는 결과만 보면 디버깅이 어렵다. 최종 답변이 틀렸을 때 원인이 분류 node인지, specialist agent인지, join 로직인지, tool timeout인지 알아야 한다. ADK Go 2.0은 node와 agent 실행이 일관된 telemetry span tree로 나타나도록 개선했다고 설명한다. 이 장점을 살리려면 span 이름과 state를 대충 두면 안 된다.

로그에는 최소한 다음을 남겨야 한다.

workflow run ID
사용자 요청 ID
실행된 node 목록
route 결정값
각 node latency와 retry 횟수
tool 호출 결과 요약
HITL 승인 ID와 결정값
최종 응답을 만든 source node
실패 시 error type과 재시도 여부

이 정보가 있어야 품질 개선도 가능하다. 단순히 ‘agent가 틀렸다’가 아니라 ‘security_agent가 stale policy를 참조했다’ 또는 ‘join node가 최신 결과보다 오래된 결과를 선택했다’처럼 원인을 좁힐 수 있다.

적용 체크리스트

ADK Go 2.0으로 멀티 에이전트 워크플로우를 설계한다면 아래 순서로 시작하자.

ADK Go 2.0의 장점은 agent를 더 화려하게 만드는 데 있지 않다. 운영 가능한 agent workflow를 코드 구조로 강제한다는 데 있다. graph, HITL, retry, telemetry를 처음부터 설계하면 멀티 에이전트 시스템은 데모를 넘어 실제 서비스에 가까워진다.