ADK Go 2.0 GA, 사람 승인까지 품은 그래프 워크플로

AI 요약

• 무슨 일: Google이 2026년 6월 30일 ADK for Go 2.0을 GA로 공개했습니다.
  • 새 엔진은 함수, 도구, 에이전트, 사람 승인을 노드로 묶는 그래프 기반 워크플로를 Go 런타임에 넣습니다.
• 설계 이유: Google은 라우팅·스케줄링·오류 처리를 모두 LLM에 맡기면 비용과 지연, 실행 편차가 커진다고 설명합니다.
  • 공식 예시는 환불 워크플로에서 토큰 5,152개를 2,265개로, 지연 시간을 7.2초에서 5.7초로 줄인 설명용 수치를 제시합니다.
• 개발자 영향: 에이전트 앱의 단위가 프롬프트 하나에서 Workflow, 엣지, 재개 가능한 승인 이벤트로 내려옵니다.
• 주의점: v2 모듈 경로는 google.golang.org/adk/v2이며, GitHub 릴리스는 Go 1.25 이상을 요구합니다.

Google이 2026년 6월 30일 ADK for Go 2.0을 GA로 공개했습니다. 발표문의 짧은 이름은 ADK Go 2.0이지만, 실제 변경점은 Go 언어 지원 업데이트보다 큽니다. Google은 그래프 기반 워크플로 엔진, 내장 사람 개입 루프, Go 코드로 쓰는 동적 오케스트레이션, Chat·Task·SingleTurn 에이전트 모드, 단일 노드 런타임을 한꺼번에 넣었습니다. 2026년 7월 1일에는 별도 글 Why we built ADK 2.0으로 Python과 Go용 ADK 2.0의 설계 이유까지 정리했습니다.

이 뉴스는 새 모델 출시가 아닙니다. Google이 건드린 대상은 에이전트가 어떤 순서로 실행되고, 어디서 멈추며, 어떤 단계만 모델에게 맡길 것인가입니다. 최근 devlery가 다룬 Google AX 프리뷰는 장시간 실행되는 에이전트를 재개하고 감사하는 런타임 계층이었습니다. 이번 ADK Go 2.0은 그보다 애플리케이션 코드에 가깝습니다. 개발자가 환불, 리포트 작성, 데이터 조사, 고객 대응 같은 업무 순서를 그래프와 Go 코드로 박아 두고, 자연어 판단이 필요한 노드에서만 LLM을 호출하게 만듭니다.

LLM이 모든 실행 순서를 고를 필요는 없습니다

Google의 문제 제기는 꽤 직접적입니다. 운영 환경의 AI 에이전트는 무한 반복에 빠지거나, 환각 때문에 업무 규칙을 건너뛰거나, 오류를 명확한 예외로 올리지 못할 수 있습니다. 모델에게 큰 시스템 프롬프트를 주고 "1단계부터 5단계까지 반드시 따라라"라고 쓰는 방식은 빠르게 시작할 수 있지만, 실행 순서 자체를 확률적 모델 판단에 맡기는 구조입니다. Google은 라우팅, 스케줄링, 오류 처리처럼 전통적 코드가 잘하는 일을 LLM이 매번 다시 추론하게 두면 느리고 비싸며 실행 편차가 생긴다고 설명합니다.

반대편 문제도 있습니다. 모든 예외를 전통적 워크플로 엔진에 미리 적으려 하면 실제 업무의 모호성을 놓칩니다. 고객 이메일을 읽고 환불 예외에 해당하는지 판단하거나, 조사 결과를 요약하거나, 확인 메일 문구를 작성하는 일은 여전히 모델이 잘하는 영역입니다. ADK 2.0의 설계 방향은 두 선택지 중 하나를 고르는 것이 아닙니다. 순서가 확정된 부분은 그래프와 코드로 고정하고, 모호한 판단만 에이전트 노드에 남기는 방식입니다.

공식 예시는 고객 환불 처리입니다. 순수 자율 에이전트 방식에서는 구매 이력 조회, 정책 확인, 환불 실행, 이메일 발송, 티켓 종료가 모두 모델의 도구 선택 루프 안에 들어갑니다. ADK 2.0 워크플로 방식에서는 구매 이력 조회는 도구 노드, 정책 예외 판단은 LLM 에이전트 노드, 환불 실행은 Stripe 같은 API를 부르는 도구 노드, 이메일 작성은 다시 LLM 에이전트 노드, 티켓 종료는 CRM 도구 노드로 나뉩니다. 모델은 판단과 문장 생성에 쓰이고, 환불을 실제로 실행하는 경로는 그래프 엣지와 코드가 통제합니다.

출처: Google Developers Blog 공식 워크플로 이미지입니다.

Google은 이 환불 예시에서 순수 LLM 에이전트가 한 번 실행될 때 5,152개 토큰을 쓰고 7.2초가 걸렸지만, ADK 2.0 워크플로는 2,265개 토큰과 5.7초로 줄었다고 제시했습니다. 발표문은 이 수치를 gemini-3.5-flash와 모의 API 응답을 사용한 설명용 벤치마크라고 단서를 붙입니다. 따라서 이 숫자를 모든 에이전트 앱의 절감률로 읽으면 안 됩니다. 그래도 방향은 분명합니다. 모델이 다음 단계를 고르는 토큰을 줄이면 비용과 지연 시간을 동시에 줄일 수 있습니다.

Go 2.0의 새 단위는 노드와 엣지입니다

ADK for Go 2.0의 핵심 단위는 노드입니다. 공식 글은 함수 노드, 이벤트를 낼 수 있는 함수 노드, 에이전트 노드, 도구 노드, 조인 노드, 동적 노드, 하위 워크플로 노드, 병렬 작업자, 상태 바인딩 노드를 나열합니다. 함수 노드는 일반 Go 함수를 감싸고, 제네릭으로 입력과 출력 스키마를 추론합니다. 도구 노드는 기존 tool.Tool을 그래프 단계로 바꾸며, 에이전트 노드는 LlmAgent 같은 에이전트를 그래프 안에 넣습니다.

엣지는 실행 순서와 라우팅 조건을 정의합니다. 순차 체인, 조건부 라우터, 팬아웃과 팬인, 하위 그래프, 순환 구조가 모두 엣지와 라우트로 표현됩니다. 예를 들어 사용자 문장을 LLM 에이전트가 question, statement, exclamation 중 하나로 분류하면, 작은 함수가 라우팅 값을 내고 그래프가 해당 처리 노드로 보냅니다. 모델은 분류만 하고, 그래프가 신뢰 가능한 디스패처 역할을 맡는 구조입니다.

이 설계가 Go에서 의미 있는 이유는 타입과 운영 환경입니다. 많은 백엔드 팀은 이미 Go 서비스 안에서 API, 큐, 데이터베이스, 권한, 관측성을 관리합니다. 에이전트가 실험용 스크립트에 머무를 때는 Python 노트북이나 프롬프트 파일이면 충분합니다. 하지만 결제, 환불, 고객 지원, 배포 자동화처럼 기존 Go 서비스와 붙는 순간, 에이전트 실행도 같은 타입 시스템과 테스트, 배포 파이프라인 안에 들어가야 합니다. ADK Go 2.0은 이 지점에서 프롬프트 중심 에이전트와 일반 서버 코드 사이의 간격을 줄이려 합니다.

GitHub 릴리스 기준으로 v2는 모듈 경로를 google.golang.org/adk/v2로 옮겼고 Go 1.25 이상을 요구합니다. 별도 ToolContext와 CallbackContext는 하나의 agent.Context로 합쳐졌습니다. 이벤트 스트림에는 노드 필드와 메타데이터가 더 붙고, 사용자 지정 세션 저장소는 새 필드를 보존해야 합니다. runner.Run, RunLive, agenttool, llmagent 콜백의 공개 시그니처는 유지됐지만, 노드와 문맥 주변은 v2로 기계적 마이그레이션이 필요합니다.

사람 승인은 프롬프트 문구가 아니라 정지 가능한 이벤트입니다

ADK Go 2.0에서 가장 실무적인 변화는 사람 개입 루프입니다. 공식 발표는 어떤 노드든 그래프를 멈추고 사람에게 입력을 요청할 수 있다고 설명합니다. 사용자가 나중에 답하면 워크플로는 두 방식 중 하나로 재개됩니다. 첫째, 답변을 다음 노드로 넘기는 handoff입니다. 둘째, 멈췄던 노드가 사람의 답변을 ctx.ResumedInput(...)으로 읽고 다시 실행되는 re-entry입니다.

이 차이는 승인 UX에서 중요합니다. 많은 에이전트 제품은 "사람 승인 필요"를 시스템 프롬프트 문장으로 처리합니다. 모델이 위험한 일을 하려 할 때 "먼저 사용자에게 물어봐라"라고 적는 방식입니다. 그러나 실제 운영에서는 사용자가 답하기 전까지 실행 상태를 보존하고, 프로세스가 재시작돼도 같은 승인 지점으로 돌아오며, 답변 스키마가 맞지 않으면 명확한 오류를 내야 합니다. Google은 ADK Go 2.0에서 run state가 세션에 남고, session history를 스캔해 멈춘 워크플로를 재구성할 수 있다고 설명합니다.

이 구조는 민감한 업무에 바로 닿습니다. 환불 승인은 금액과 정책 근거를 보여줘야 하고, 데이터 삭제 승인은 대상 레코드와 되돌릴 수 없는 결과를 보여줘야 합니다. 코드 변경 승인이라면 어떤 파일을 바꾸고 어떤 테스트를 돌릴지 보여줘야 합니다. 사람이 "예"라고 답한 사실만으로는 부족합니다. 승인 이벤트에는 interrupt ID, 메시지, 응답 스키마, 재개 방식, 실패 시 오류가 남아야 합니다. ADK 2.0의 사람 개입 루프는 이런 승인 경계를 모델의 친절한 질문이 아니라 런타임 이벤트로 바꿉니다.

동적 워크플로는 그래프와 일반 Go 코드 사이를 잇습니다

그래프는 실행 구조를 선명하게 만들지만, 모든 업무가 정적 그래프에 맞지는 않습니다. 조사할 항목 수가 런타임에 정해지거나, 어떤 모델 출력에 따라 반복 횟수가 달라지거나, 여러 후보를 모은 뒤 일부만 다시 검증해야 하는 경우가 있습니다. ADK Go 2.0은 이런 상황을 위해 동적 노드를 제공합니다. 개발자는 일반 Go 함수 안에서 RunNode(...)를 호출하며 루프, 조건문, 누적, 동적 리스트 팬아웃을 표현할 수 있습니다.

이 기능은 LangGraph나 Temporal 같은 워크플로 도구를 쓰는 팀에게 익숙한 문제를 겨냥합니다. 정적 그래프는 관측성과 안전성에 강하지만, 복잡한 업무를 모두 라우팅 테이블로 바꾸면 유지보수가 어려워집니다. 반대로 일반 코드만 쓰면 전체 실행 형태가 문서와 대시보드에서 잘 보이지 않습니다. ADK 2.0의 동적 노드는 그래프의 관측 가능한 경계 안에서 Go 코드의 표현력을 쓰게 하는 타협안입니다.

재시도와 타임아웃도 같은 결을 갖습니다. 각 노드에는 지수 백오프와 지터를 가진 재시도 정책을 붙일 수 있고, 노드별 타임아웃과 그래프 전체 최대 동시성도 제한할 수 있습니다. 병렬 브랜치는 문맥 격리를 통해 한 브랜치의 대화 이력이 다른 LLM 프롬프트에 섞이지 않도록 설계됩니다. 에이전트 실패의 많은 부분은 모델 성능보다 도구 응답 지연, 외부 API 오류, 문맥 누수, 재시도 폭증에서 나옵니다. ADK Go 2.0은 이런 실패를 프롬프트 재작성보다 실행 제어 문제로 다룹니다.

ADK 2.0은 AX와 다른 층의 Google 에이전트 전략입니다

Google의 최근 에이전트 발표를 한 줄로 묶으면 모두 "에이전트 인프라"처럼 보입니다. 그러나 층은 다릅니다. Google AX는 에이전트 실행, 재개, 감사, 격리를 맡는 런타임 표준에 가깝습니다. AX는 특정 모델이나 특정 프레임워크를 대체하기보다 여러 하네스를 감싸는 serving layer로 소개됐습니다. 반면 ADK Go 2.0은 개발자가 앱 안에서 에이전트, 도구, 함수, 승인 단계를 어떻게 조립할지 다룹니다.

이 구분은 도입 판단에 필요합니다. ADK 2.0을 쓴다고 해서 장시간 에이전트의 배포, 스냅샷, 멀티테넌트 격리, Kubernetes 운영이 자동으로 해결되는 것은 아닙니다. 반대로 AX 같은 런타임을 검토한다고 해서 앱 내부의 업무 순서와 승인 노드가 자동으로 설계되는 것도 아닙니다. 실제 제품은 두 층을 모두 묻습니다. 어떤 그래프를 실행할 것인가와 그 그래프 실행을 어디서 어떻게 재개하고 감사할 것인가는 다른 질문입니다.

Google이 ADK 문서 첫 화면에 Python, JS, Go, Java, Kotlin을 나란히 놓은 것도 같은 맥락입니다. ADK 2.0의 그래프 워크플로와 협업형 워크플로는 언어별 SDK 안에 들어가지만, 운영 환경에서는 Vertex AI Agent Engine, Cloud Run, GKE, AX 같은 배포·런타임 선택지와 만납니다. 개발자에게 필요한 것은 "Google 에이전트 스택을 통째로 쓰라"는 결론이 아닙니다. 현재 업무가 실험용 에이전트인지, 운영 서비스 안의 승인 가능한 워크플로인지, 장시간 실행되는 작업자인지 먼저 분리해야 합니다.

커뮤니티의 질문은 v1과 v2 패턴 구분에 몰렸습니다

ADK Go 2.0은 발표된 지 며칠 되지 않아 대형 Hacker News 토론이 확인되지는 않았습니다. 대신 r/agentdevelopmentkit에는 ADK 2.0을 배우는 사용자가 v1 패턴과 v2 권장 패턴을 구분하기 어렵다는 질문을 올렸습니다. 답변들은 새 기능을 그래프 기반 워크플로, 협업형 에이전트 팀, 동적 워크플로로 요약하면서도 ADK 1.0이 완전 폐기된 것은 아니라고 설명했습니다. 이 반응은 문서 전환기의 실제 문제를 보여줍니다. 프레임워크가 기능을 추가할수록, 예전 튜토리얼과 새 권장 구조가 섞입니다.

r/googlecloud의 별도 질문은 ADK 2.0과 Vertex AI Agent Engine을 함께 쓸 때 배포 revision과 versioning이 어떻게 관리되는지 묻습니다. 이 질문은 ADK 2.0의 관심사가 코드 안의 그래프 작성에서 끝나지 않는다는 신호입니다. 그래프가 프로덕션 업무를 실행한다면, 어떤 버전의 그래프가 어떤 고객 작업을 처리했는지, 실패한 실행을 어떤 릴리스로 재현할 수 있는지, 롤백이 워크플로 상태와 충돌하지 않는지도 같이 봐야 합니다.

이 지점에서 ADK 2.0은 LangGraph, OpenAI Agents SDK, LlamaIndex Workflows, Microsoft Agent Framework 같은 도구와 경쟁합니다. 비교 기준은 "에이전트를 만들 수 있는가"가 아닙니다. 그래프와 일반 코드의 경계, 사람 승인의 상태 보존, 배포 이력, 관측성, 테스트, 권한, 모델 교체를 얼마나 자연스럽게 연결하는지가 더 중요합니다. 특히 Go 팀에는 기존 서버 코드와 같은 언어로 에이전트 워크플로를 관리할 수 있다는 점이 장점이지만, Go 1.25 이상과 v2 모듈 경로 같은 업그레이드 비용도 함께 따릅니다.

지금 가져갈 체크리스트는 세 가지입니다

첫째, 현재 에이전트가 실제로 워크플로인지 확인해야 합니다. 사용자의 질문에 답하거나 문서를 요약하는 대화형 보조라면 그래프는 과할 수 있습니다. 반대로 환불, 보안 점검, 배포 승인, 고객 티켓 처리처럼 정해진 순서와 예외 처리가 있다면 프롬프트 안의 단계 목록으로 버티기 어렵습니다. 이때 ADK 2.0의 질문은 간단합니다. 항상 A 다음 B가 와야 하는가. 그렇다면 모델이 매번 그 순서를 추론하게 둘 이유가 없습니다.

둘째, 사람 승인을 어디에 이벤트로 남길지 정해야 합니다. 승인 문구는 제품 문장이고, 승인 이벤트는 운영 데이터입니다. interrupt ID, 응답 스키마, 승인자, 승인 시점, 재개 방식, 실패 오류가 남아야 나중에 감사와 장애 복구가 가능합니다. ADK Go 2.0은 이 구조를 워크플로 노드 안에 넣었지만, 어떤 요청을 승인 대상으로 볼지는 여전히 팀이 정해야 합니다. 금액, 권한, 데이터 삭제, 외부 전송, 코드 실행 같은 기준을 그래프 설계 전에 분리해야 합니다.

셋째, LLM 노드를 줄이는 것이 항상 좋은 것은 아니라는 점을 기억해야 합니다. Google의 환불 예시는 토큰과 지연 시간을 줄였지만, 지나치게 단단한 그래프는 실제 고객 문제의 예외를 놓칠 수 있습니다. 모델 판단이 필요한 지점과 코드로 확정해야 하는 지점을 나누는 일이 설계의 본체입니다. 불명확한 입력 분류, 정책 예외 판단, 설명 작성은 LLM 노드에 남길 수 있습니다. 결제 실행, 권한 변경, 티켓 종료, 재시도 정책은 코드와 그래프가 맡는 편이 낫습니다.

ADK Go 2.0의 의미는 "Google도 에이전트 프레임워크를 냈다"가 아닙니다. 이미 에이전트 프레임워크는 많습니다. 이번 발표가 새롭게 밀어붙이는 기준은 에이전트 실행 순서를 제품 코드의 일부로 보라는 쪽입니다. 모델은 여전히 중요하지만, 운영 환경의 에이전트는 모델 하나로 완성되지 않습니다. 노드, 엣지, 재개 가능한 승인, 상태 격리, 재시도, 배포 이력이 함께 있어야 업무 시스템 안에 들어갈 수 있습니다.

그래서 ADK Go 2.0은 모델 경쟁보다 지루하지만 오래 남는 질문을 던집니다. 우리 에이전트가 실패했을 때 어느 노드에서 멈췄는가. 어떤 도구 호출은 자동으로 실행됐고, 어떤 호출은 사람이 승인했는가. 어떤 LLM 노드는 어떤 문맥만 받았는가. 같은 그래프를 Go 서비스의 테스트와 배포 안에서 재현할 수 있는가. 에이전트 앱을 만드는 팀이라면, 이번 Google 발표를 새 SDK 릴리스보다 실행 순서와 승인 경계의 제품화로 읽는 편이 더 정확합니다.