
Google Developers Blog에 따르면 Google은 1일(현지시간) 에이전트 개발 프레임워크 ADK 2.0을 설명하며, AI 에이전트 실행 흐름에 구조화된 워크플로 런타임과 협업형 에이전트 모델을 도입했다고 밝혔다. ADK는 Python, TypeScript, Go, Java, Kotlin을 지원하는 오픈소스 에이전트 개발 프레임워크다.
Google은 실제 기업 환경에서 에이전트가 무한 루프에 빠지거나, 환각으로 핵심 비즈니스 로직을 건너뛰거나, 명확한 예외 없이 실패할 수 있다고 설명했다. 기존 방식처럼 거대언어모델에 라우팅, 스케줄링, 오류 처리까지 맡기면 유연성은 얻을 수 있지만 실행 비용과 지연 시간이 커지고 결과의 변동성도 커진다는 문제의식이다.
ADK 2.0의 핵심은 언어모델이 모든 실행 순서를 추론하도록 두지 않고, 정해진 업무 절차는 그래프 기반 워크플로로 분리하는 데 있다. Google은 구매 이력 조회, 정책 판단, 환불 처리, 이메일 작성, 티켓 종료 같은 절차를 예로 들며, 도구 호출과 조건 분기, 사람 검토 단계를 명시적인 실행 경로로 구성할 수 있다고 설명했다.
이 접근은 자율 에이전트와 전통적 워크플로 사이의 중간 지대를 겨냥한다. 문서 이해, 예외 판단, 답변 작성처럼 언어모델의 추론이 필요한 노드는 에이전트가 맡고, 반드시 순서가 지켜져야 하는 결제·환불·승인·상태 변경 같은 단계는 코드와 그래프 런타임이 통제하는 방식이다.
Google은 이 구조가 토큰 사용량과 지연 시간을 줄일 수 있다고 설명했다. 블로그는 예시 워크플로에서 일반 LLM 에이전트 방식과 ADK 2.0 워크플로 방식을 비교하며, 오케스트레이션 단계 일부를 프로그램 실행으로 옮기면 모델이 매번 긴 컨텍스트를 다시 처리하지 않아도 된다고 밝혔다. 다만 제시된 수치는 모의 API 응답과 특정 모델을 사용한 예시 결과로, 일반적인 성능 보장으로 해석하기는 어렵다.
보안 측면에서도 의미가 있다. Google은 순수 자율 에이전트가 입력 프롬프트에 따라 실행 경로를 판단할 경우 프롬프트 인젝션에 취약할 수 있다고 지적했다. 반면 ADK 2.0 워크플로는 실행 가능한 경로를 그래프와 코드로 제한하기 때문에, 언어모델 노드가 조작된 입력을 받아도 정의되지 않은 도구 호출이나 승인되지 않은 절차로 이동하기 어렵다는 설명이다.
공식 ADK 문서도 ADK 2.0에서 그래프 워크플로와 협업형 에이전트를 전면에 내세우고 있다. 문서는 ADK를 엔터프라이즈 규모의 신뢰성 있는 AI 에이전트를 구축, 디버그, 배포하기 위한 프레임워크로 소개하며, 명시적 실행 경로와 예측 가능한 결과를 갖춘 그래프 기반 아키텍처를 새 기능으로 설명한다.
이번 업데이트는 AI 에이전트 개발이 단순한 프롬프트 설계에서 실행 구조 설계로 이동하고 있음을 보여준다. 기업이 에이전트를 고객지원, 운영 자동화, 내부 업무 처리에 투입하려면 모델의 자율성뿐 아니라 절차 준수, 실패 처리, 감사 가능성이 필요하다. ADK 2.0은 그 요구를 개발 프레임워크 차원에서 다루려는 Google의 방향을 보여주는 사례다.
출처: Google Developers Blog https://developers.googleblog.com/why-we-built-adk-20/ · ADK Documentation https://adk.dev/









