Google ADK Go 2.0 출시: 멀티 에이전트 워크플로우를 그래프로 운영하는 법

Google Developers Blog에 ADK Go 2.0이 공개됐습니다. 핵심은 “에이전트를 더 쉽게 만든다”가 아니라 “멀티 에이전트 실행 흐름을 그래프 기반으로 명확하게 구성한다”입니다. Agent Development Kit for Go 2.0은 graph-based workflow engine, human-in-the-loop, dynamic orchestration, exponential backoff retry, telemetry와 state persistence 단순화를 주요 변화로 내세웁니다.

AI 에이전트를 실제 서비스에 붙여 본 개발자라면 공감할 겁니다. 문제는 LLM 호출 한 번이 아닙니다. 여러 에이전트가 순서대로 실행되고, 중간에 사용자의 승인이 필요하고, 실패한 노드를 재시도하고, 최종 결과를 추적하는 운영 구조가 어렵습니다.

왜 그래프 기반 워크플로우가 필요한가

단순 챗봇은 요청 하나에 응답 하나면 충분합니다. 하지만 실무형 에이전트는 다릅니다.

예를 들어 “경쟁사 가격 정책을 조사하고 우리 제품 랜딩 문구를 수정해줘”라는 작업은 최소한 다음 단계로 나뉩니다.

1. 검색 에이전트가 자료를 모읍니다.
2. 분석 에이전트가 가격, 기능, 포지셔닝을 구조화합니다.
3. 작성 에이전트가 문구 초안을 만듭니다.
4. 리뷰 에이전트가 과장 표현과 근거 부족을 잡습니다.
5. 사람 승인을 받은 뒤 CMS 또는 Git에 반영합니다.

이 흐름을 단순 함수 호출 체인으로 만들면 조건 분기와 재시도 로직이 금방 지저분해집니다. 그래프 기반 구조는 각 단계를 노드로 나누고, 성공·실패·승인·재시도 경로를 명시할 수 있게 합니다.

ADK Go 2.0에서 눈여겨볼 변화

이번 발표에서 개발자가 볼 만한 지점은 네 가지입니다.

1. Graph-based workflow engine

복잡한 에이전트 플로우를 그래프로 정의할 수 있습니다. 순차 실행뿐 아니라 병렬 실행, 조건부 분기, 결과 병합 같은 패턴에 적합합니다. 특히 “조사 → 요약 → 검증 → 실행”처럼 반복되는 업무 자동화에 잘 맞습니다.

2. Built-in human-in-the-loop

AI가 바로 실행하면 위험한 작업이 있습니다. 결제, 발송, 고객 데이터 수정, 프로덕션 배포가 대표적입니다. human-in-the-loop은 이런 지점에서 사람의 승인이나 입력을 워크플로우 안에 넣는 구조입니다.

중요한 건 승인 단계를 나중에 UI에서 억지로 붙이는 게 아니라, 실행 그래프의 일부로 설계한다는 점입니다. 그러면 감사 로그와 재시작 처리가 쉬워집니다.

3. Plain Go code 기반 dynamic orchestration

선언형 설정만으로 모든 흐름을 표현하면 복잡한 비즈니스 로직에서 막힙니다. ADK Go 2.0은 Go 코드로 동적 실행을 구성할 수 있다는 점을 강조합니다. 백엔드 팀이 이미 Go로 서비스 운영을 하고 있다면, 에이전트 런타임을 별도 언어로 분리하지 않아도 되는 장점이 있습니다.

4. Exponential backoff retries

LLM API, 검색 API, 사내 API는 모두 일시적으로 실패할 수 있습니다. 재시도 로직이 없으면 에이전트는 불안정해지고, 재시도가 과하면 비용과 부하가 늘어납니다. 지수 백오프는 에이전트 운영에서 기본값이 되어야 합니다.

어떤 팀이 먼저 검토하면 좋나

ADK Go 2.0은 “AI 기능 하나 붙이고 싶다” 수준의 팀보다는, 이미 백엔드 워크플로우를 운영하는 팀에 더 잘 맞습니다.

특히 다음 조건이면 검토 가치가 큽니다.

• Go 기반 백엔드와 워커 시스템이 있다.
• 고객 요청 처리 과정에 여러 단계의 AI 판단이 들어간다.
• 사람 승인 단계가 필요한 작업이 있다.
• 실행 로그, 재시도, 상태 저장이 중요하다.
• 단일 에이전트보다 여러 역할의 에이전트를 조합해야 한다.

반대로 프론트엔드 중심의 간단한 AI 기능, 개인용 자동화, 일회성 내부 도구라면 ADK Go 2.0은 과할 수 있습니다. 그 경우에는 Genkit, LangGraph, 자체 큐 기반 워커가 더 빠를 수 있습니다.

설계할 때 피해야 할 실수

멀티 에이전트 워크플로우에서 흔한 실수는 “에이전트 이름”을 먼저 정하는 겁니다. 검색 에이전트, 분석 에이전트, 작성 에이전트 같은 이름은 보기 좋지만, 실제 운영에서는 입출력 계약이 더 중요합니다.

각 노드마다 아래를 먼저 정의해야 합니다.

• 입력 데이터 구조
• 출력 데이터 구조
• 실패했을 때 재시도 여부
• 사람이 확인해야 하는 조건
• 다음 노드로 넘길 최소 정보
• 로그에 남길 민감하지 않은 요약

이 계약이 없으면 그래프는 시각적으로만 멋지고 디버깅은 어려운 구조가 됩니다.

예시: 기술 블로그 자동 발행 플로우

ADK Go 2.0 같은 그래프 엔진을 적용한다면 기술 블로그 자동화는 이렇게 나눌 수 있습니다.

1. TopicResearch 노드: 최신 릴리스와 검색 키워드를 수집
2. DuplicateCheck 노드: 기존 발행글과 주제 중복 확인
3. Outline 노드: 검색 의도와 독자 문제를 기준으로 목차 생성
4. Draft 노드: 초안 작성
5. FactCheck 노드: 공식 문서 링크와 수치 확인
6. HumanReview 노드: 제목, 근거, 민감 표현 승인
7. Publish 노드: CMS 업로드
8. Verify 노드: URL, 상태 코드, 본문 렌더링 확인

여기서 HumanReview는 선택이 아니라 안전장치입니다. 특히 회사 이름, 가격, 법률·보안 관련 내용은 자동 업로드보다 승인 단계를 두는 편이 낫습니다.

바로 적용할 체크리스트

• 워크플로우를 “에이전트 목록”이 아니라 “노드와 데이터 계약”으로 정의
• 사람 승인이 필요한 노드를 먼저 표시
• 모든 외부 API 호출에 timeout과 exponential backoff 적용
• 각 노드의 입력·출력·실패 로그 스키마 작성
• 병렬 실행이 가능한 조사 작업과 순차 실행이 필요한 승인 작업 분리
• 상태 저장소에 원문 전체가 아니라 재실행 가능한 최소 상태 저장
• 운영 대시보드에서 노드별 성공률, 평균 지연 시간, 재시도 횟수 추적

ADK Go 2.0의 의미는 “에이전트가 더 똑똑해졌다”가 아닙니다. 에이전트를 서비스처럼 운영할 수 있는 구조가 더 중요해졌다는 신호입니다. Go 백엔드 팀이라면 이번 업데이트를 단순 뉴스로 넘기지 말고, 현재 자동화 플로우 중 그래프화할 만한 업무부터 골라보는 게 좋습니다.