큐레이션
Google ADK 2.0: 에이전트와 워크플로를 나누는 Python 프레임워크
에이전트의 판단과 정해진 실행 순서를 그래프형 워크플로로 나누고, 도구 승인·평가·배포까지 설계하는 Google의 오픈소스 프레임워크

여러 단계의 AI 업무를 만들 때 무엇부터 나눠야 할까요?
Python으로 자료 조사·작성·검토처럼 여러 단계를 이어가는 팀이라면 Google Agent Development Kit(ADK) 2.0을 비교해 볼 만합니다. 이 프레임워크는 모델 호출만 감싸는 데 그치지 않고, 에이전트의 판단과 정해진 실행 순서를 한 코드베이스에서 나누도록 돕습니다.
이 Pick에서 확인할 수 있는 핵심은 “어떤 모델이 가장 좋은가”보다 “어느 단계에 에이전트를 쓰고, 어느 단계에 정해진 흐름과 사람 확인을 둘 것인가”입니다. Google 공식 저장소와 문서를 기준으로 기능 범위와 주의할 점을 정리했습니다.
어떤 팀이 먼저 살펴볼 만한가요?
- 한 번의 답변보다 조사·변환·검토·전달처럼 여러 단계가 필요한 팀
- 순차 실행, 병렬 실행, 조건에 따른 분기와 재시작 지점을 코드로 관리하려는 개발자
- 여러 전문 에이전트를 조합하되 도구 사용과 사람 승인을 구분하려는 팀
- 로컬 개발 화면에서 실행 이벤트와 평가 결과를 확인한 뒤 배포하려는 팀
단순한 질의응답이나 규칙이 이미 고정된 변환 작업이라면 이 프레임워크를 추가하는 것이 오히려 복잡도를 높일 수 있습니다. 먼저 일반 함수로 표현할 수 있는 단계와 모델의 판단이 필요한 단계를 나누는 편이 좋습니다.
도입 전에 무엇을 먼저 구분해야 하나요?
에이전트와 워크플로를 나눕니다
에이전트는 도구를 고르고 다음 행동을 판단하는 개방형 작업에 맞습니다. 워크플로는 여러 단계의 순서와 분기를 코드로 고정해야 할 때 맞습니다.
예를 들어 회의 자료를 정리한다면 요약 초안은 에이전트가 맡을 수 있습니다. 원문 대조, 개인정보 확인과 외부 발송은 정해진 단계와 사람 승인을 두는 편이 안전합니다.
도구 호출과 승인 지점을 표시합니다
ADK는 사용자 함수, OpenAPI 명세, MCP 도구를 연결할 수 있고 도구 실행 전에 확인을 받는 흐름도 제공합니다. 그러나 확인 화면이 있다고 해서 권한·데이터 보관·접근 기록 문제가 해결되는 것은 아닙니다.
실제 설계에서는 파일 읽기, 외부 검색, 메일 발송, 데이터 변경을 서로 다른 도구로 나누고 각각에 허용 계정과 중단 조건을 적어 두어야 합니다.
평가와 배포를 별도 단계로 둡니다
공식 README는 adk eval 명령과 개발용 웹 UI를 안내합니다. 테스트 질문과 기대 결과를 먼저 만들고, 정상 응답뿐 아니라 누락·잘못된 도구 선택·승인 거부 상황도 평가 목록에 넣는 방식이 적합합니다.
공식 README에서 확인한 기능과 시작점은 무엇인가요?
ADK 2.0은 그래프형 실행 엔진을 통해 라우팅, 병렬 분기와 합치기, 반복, 재시도, 상태 관리, 동적 노드, 사람 개입과 중첩 워크플로를 구성할 수 있다고 설명합니다. 여러 에이전트를 계층으로 조합하는 Task API도 함께 제시합니다.
도구 측면에서는 사전 제공 도구, 사용자 함수, OpenAPI, MCP를 연결할 수 있습니다. Python 외에도 TypeScript, Go, Java, Kotlin용 ADK 저장소가 공식 README에 연결되어 있지만, 이 Pick은 google/adk-python 저장소의 Python 구현을 기준으로 봅니다.
공식 README의 최소 구조는 Agent로 행동을 정의하고 Workflow로 실행 순서를 감싸는 형태입니다.
from google.adk import Agent, Workflow
draft_agent = Agent(
name="draft_agent",
model="gemini-2.5-flash",
instruction="자료를 초안으로 정리합니다.",
)
review_agent = Agent(
name="review_agent",
instruction="초안의 누락과 확인 필요 항목을 표시합니다.",
)
root_agent = Workflow(
name="document_workflow",
edges=[("START", draft_agent, review_agent)],
)
설치는 Python 3.10 이상에서 pip install google-adk로 시작할 수 있습니다. 로컬에서 adk run으로 에이전트를 실행하고, adk web으로 개발 화면을 열며, adk eval로 평가 세트를 실행하는 흐름을 공식 문서가 안내합니다.
한계와 주의사항은 무엇인가요?
- ADK 2.0은 에이전트 API, 이벤트 모델과 세션 스키마에 변경이 있습니다. 공식 README는 오래된 1.x 버전과 세션 호환이 되지 않는다고 명시합니다.
- 프레임워크는 Gemini에 최적화되어 있지만 다른 모델과 배포 환경도 지원한다고 설명합니다. 실제 모델별 도구 호출, 구조화 출력과 인증 방식은 연결하려는 공급자의 문서에서 따로 확인해야 합니다.
- Cloud Run과 Vertex AI Agent Engine 배포는 Google이 안내하는 선택지입니다. 조직의 비용, 리전, 접근 제어, 로그 보관 조건이 맞는지는 별도 검토가 필요합니다.
- 도구 승인과 평가 명령은 설계 수단이지 업무 정확도나 규정 준수를 보장하는 인증이 아닙니다. 최종 결과의 사실·수치·개인정보 검수 책임은 사람에게 남습니다.
- GitHub stars는 2026년 9월 6일 공식 저장소 화면에서 확인한 값입니다. 인기와 조직 적합성은 같은 기준이 아니므로 버전, 라이선스, 운영 인력과 지원 범위를 함께 비교해야 합니다.
지금 해볼 다음 행동은 무엇인가요?
운영 데이터 대신 비식별 자료로 입력 → 초안 → 원문 대조 → 사람 승인 네 단계를 작은 워크플로로 만들어 보세요. 각 단계의 입력·출력 형식과 실패 시 중단 조건을 적은 뒤 adk eval에 정상·누락·승인 거부 사례를 넣으면 도구 선택보다 먼저 필요한 검수 기준을 확인할 수 있습니다.
문서·회의·표처럼 반복 업무에 적용할 범위를 정해야 한다면 기업 AI 업무자동화 실무교육에서 입력·검수·승인 단계와 교육 산출물을 비교해 볼 수 있습니다. 개발 프레임워크 도입 여부와 별도로, 무엇을 자동화하고 무엇을 사람에게 남길지 정하는 과정입니다.