ADK Go 2.0 멀티 에이전트 설계법: 그래프, HITL, 재시작 복구까지

ADK Go 2.0의 핵심은 “에이전트를 Go로 만들 수 있다”가 아니라 “멀티 에이전트 워크플로우를 그래프로 표현할 수 있다”는 점이다. 실제 에이전트 서비스는 단일 프롬프트로 끝나지 않는다. 분류하고, 분기하고, 여러 전문 에이전트에 나눠 맡기고, 사람이 승인하고, 실패하면 재시도하고, 중간 상태를 저장했다가 다시 시작해야 한다.

이 과정을 일반 코드의 if문과 goroutine으로만 엮으면 금방 깨진다. 처음에는 빠르게 보이지만, 승인 대기, 장애 복구, 중복 실행 방지, 상태 저장이 들어오는 순간 운영 난이도가 올라간다. ADK Go 2.0의 graph-based workflow engine은 이 문제를 정면으로 다룬다.

핵심 키워드는 ADK Go 2.0, 멀티 에이전트, 에이전트 워크플로우, human in the loop다. 이 글은 발표 요약이 아니라 Go 백엔드 팀이 실제로 에이전트 워크플로우를 설계할 때 필요한 구조와 체크리스트를 다룬다.

왜 그래프가 필요한가

실무 에이전트는 선형 절차가 아니다. 고객 문의를 처리하는 에이전트를 예로 들어보자. 먼저 문의 유형을 분류한다. 결제 문제면 결제 로그를 조회하고, 기술 문제면 배포 이력을 본다. 보상이나 환불이 필요하면 사람이 승인해야 한다. 문서 답변으로 해결 가능하면 자동 응답을 만든다. 실패하면 다른 경로로 재시도한다.

이 흐름은 자연스럽게 그래프가 된다. 노드는 분류, 조회, 판단, 승인, 응답 생성 같은 작업 단위다. 엣지는 어떤 조건에서 다음 노드로 갈지 정한다. 그래프 구조의 장점은 전체 흐름이 눈에 보이고, 각 노드의 책임이 작아지며, 재시작 지점을 관리하기 쉽다는 것이다.

ADK Go 2.0은 그래프도 하나의 agent.Agent처럼 실행할 수 있게 만든다. 즉 기존 runner, launcher, console과 같은 실행 모델 안에서 단일 에이전트와 그래프 워크플로우를 같은 방식으로 다룰 수 있다. 운영팀 입장에서는 별도 서버나 완전히 다른 실행기를 붙이지 않아도 되는 점이 중요하다.

노드 설계: 함수, 도구, 에이전트, 조인

ADK Go 2.0은 여러 종류의 노드를 제공한다. Function node는 일반 Go 함수를 감싸는 형태다. 입력과 출력 타입이 명확한 작업에 적합하다. 예를 들어 티켓 분류, 정책 룰 검사, JSON 정규화 같은 작업은 function node로 충분하다.

Agent node는 LLM 기반 에이전트를 그래프 안에 넣을 때 쓴다. 문서 검색 결과를 바탕으로 답변을 작성하거나, 코드 변경 계획을 세우는 작업처럼 자연어 판단이 필요한 부분에 적합하다. Tool node는 외부 도구 호출을 그래프 단계로 만든다. 예를 들어 GitHub 이슈 생성, 로그 검색, CRM 조회, 슬랙 알림 같은 작업이다.

Join node는 fan-out 후 결과를 다시 모을 때 필요하다. 예를 들어 장애 분석에서 로그 에이전트, 배포 이력 에이전트, 알림 이력 에이전트를 병렬로 실행한 뒤 종합 판단을 해야 한다면 join node가 fan-in 장벽 역할을 한다. 이 구조가 없으면 병렬 작업의 완료 조건과 결과 병합을 매번 직접 구현해야 한다.

HITL은 예외가 아니라 기본 설계로 둬야 한다

Human-in-the-loop, 즉 사람이 중간에 개입하는 흐름은 에이전트 시스템에서 예외가 아니다. 결제 취소, 고객 보상, 프로덕션 배포, 개인정보 접근, 대량 메시지 발송처럼 자동화가 위험한 작업은 반드시 승인 단계를 가져야 한다.

좋은 HITL 설계는 단순히 “승인 버튼 하나”가 아니다. 승인자가 무엇을 보고 판단해야 하는지, 어떤 근거가 필요한지, 승인 후 어떤 작업이 실행되는지, 거절하면 어떤 경로로 돌아가는지가 명확해야 한다. 에이전트는 승인 요청 전에 위험 요약, 변경 범위, 대안, 롤백 방법을 제시해야 한다.

ADK Go 2.0이 HITL을 built-in primitive로 제공한다는 점은 이 흐름을 워크플로우 내부에 공식 단계로 넣을 수 있다는 의미다. 사람이 응답할 때까지 중단하고, 상태를 저장하고, 이후 같은 흐름에서 재개하는 구조가 가능해진다. 운영 환경에서는 이 차이가 크다. 프로세스 재시작이나 배포가 있어도 승인 대기 중인 작업이 사라지면 안 되기 때문이다.

재시작 복구와 상태 저장을 처음부터 넣어야 한다

멀티 에이전트 워크플로우는 실행 시간이 길다. 몇 초 만에 끝나는 작업도 있지만, 승인 대기나 외부 API 지연이 있으면 몇 분, 몇 시간으로 늘어난다. 이때 프로세스가 재시작되거나 네트워크가 끊기면 처음부터 다시 실행하는 방식은 위험하다. 중복 결제, 중복 알림, 중복 PR 생성이 생길 수 있다.

그래서 각 노드는 idempotency를 고려해야 한다. 같은 입력으로 두 번 실행되어도 외부 부작용이 한 번만 일어나야 한다. 예를 들어 GitHub 이슈를 생성하는 노드는 기존 이슈 키를 먼저 확인해야 하고, 결제 취소 노드는 외부 트랜잭션 ID 기준으로 중복 실행을 막아야 한다.

ADK Go 2.0의 그래프 실행 모델은 상태 persist, pause, resume 같은 흐름을 더 자연스럽게 설계할 수 있게 한다. 하지만 프레임워크가 모든 도메인 위험을 해결해주지는 않는다. 팀은 각 노드의 입력, 출력, 부작용, 재시도 정책, 타임아웃, 보상 트랜잭션을 문서화해야 한다.

추천 아키텍처: 작은 그래프부터 시작하기

처음부터 모든 업무를 거대한 멀티 에이전트 그래프로 만들 필요는 없다. 오히려 실패한다. 첫 적용은 입력과 출력이 명확하고, 사람이 검토할 수 있으며, 외부 부작용이 제한적인 흐름이 좋다.

예를 들어 “고객 문의를 개발 티켓으로 분해하는 워크플로우”는 좋은 시작점이다. 입력은 문의 내용이다. 첫 노드는 문의 유형 분류, 두 번째 노드는 관련 문서 검색, 세 번째 노드는 재현 정보 추출, 네 번째 노드는 티켓 초안 생성, 마지막 노드는 사람이 승인 후 이슈 생성이다. 이 정도면 그래프의 장점을 경험하면서도 위험을 통제할 수 있다.

이후 장애 분석, 코드 리뷰, 보안 점검, 운영 요청 처리로 확장한다. 각 그래프는 하나의 제품 기능처럼 버전 관리해야 한다. 프롬프트, 도구 권한, 라우팅 조건, 승인 규칙이 바뀌면 배포 이력과 롤백 경로가 필요하다.

실행 체크리스트

• 워크플로우를 먼저 노드와 엣지로 그린 뒤 구현한다.
• LLM이 필요한 노드와 일반 함수로 충분한 노드를 분리한다.
• 외부 부작용이 있는 노드는 idempotency key를 둔다.
• 승인 단계에는 위험 요약, 실행 결과, 롤백 방법을 포함한다.
• 장기 실행 작업은 pause, persist, resume을 전제로 설계한다.
• 첫 적용은 고객 문의 분류나 티켓 생성처럼 저위험 흐름으로 시작한다.
• 그래프 버전, 프롬프트 버전, 도구 권한 변경 이력을 남긴다.

참고한 공개 자료

• Google Developers Blog, “Build reliable multi-agent applications with ADK Go 2.0” https://developers.googleblog.com/announcing-adk-go-20/