Google ADK 2.0 Workflows, 에이전트 루프를 운영 코드로 묶는 법 | DAKER 커뮤니티
Google이 ADK 2.0 Workflows를 통해 에이전트 실행 흐름을 더 결정적으로 제어하는 방식을 제시했습니다. 핵심은 LLM에게 모든 라우팅을 맡기지 말고, 업무 흐름은 코드 그래프로 고정하자는 점입니다.
ADK 2.0 Workflows란, 에이전트 판단과 결정적 업무 흐름을 함께 묶는 Google의 개발 도구 방식입니다.
오늘의 한 줄 요약은 무엇인가요?
오늘의 한 줄 요약: ADK 2.0은 “더 똑똑한 에이전트”보다 “덜 흔들리는 실행 경로”를 먼저 설계하라는 개발자용 신호입니다.
Google은 장기 실행 에이전트가 무한 루프, 비즈니스 로직 우회, 애매한 실패 상태에 빠질 수 있다고 설명했습니다. ADK 2.0 Workflows는 LLM이 필요한 지점과 코드가 반드시 통제해야 하는 지점을 분리합니다. 작성 기준은 2026년 7월 4일 KST이며, 공개 본문에는 외부 링크를 남기지 않았습니다.
왜 지금 중요한가요?
많은 팀이 고객 응대, 환불, 데이터 조회, 승인 흐름에 AI 에이전트를 붙이고 있습니다. 그런데 실제 운영에서는 답변 품질보다 “환불을 실행해도 되는가”, “사람 승인 단계가 빠지지 않았는가”, “실패가 어디서 났는가”가 더 중요해집니다. ADK 2.0은 이 문제를 프롬프트가 아니라 실행 그래프와 상태 경계로 풀라고 말합니다.
이번 발표에서 Google은 Workflows가 결정적 단계와 LLM 단계를 함께 구성한다고 설명했습니다. 예시 기준으로 순수 LLM 에이전트보다 토큰 사용이 약 절반 줄고, 지연 시간도 약 20% 줄어드는 흐름을 보여줬습니다. 이 수치는 예시 벤치마크이므로 그대로 성능 보장으로 읽기보다, 불필요한 LLM 라우팅을 줄이는 설계 방향으로 보는 편이 안전합니다.
실무자가 볼 포인트는 무엇인가요?
구분 | 순수 에이전트 루프 | ADK 2.0 Workflows식 접근 |
|---|---|---|
라우팅 | LLM이 다음 행동을 계속 판단 | 코드 그래프가 다음 노드를 결정 |
상태 | 도구 출력이 대화 기록에 쌓임 | 필요한 데이터만 다음 노드에 전달 |
보안 | 프롬프트 인젝션이 실행 경로를 흔들 수 있음 | 허용된 edge와 node 밖으로 실행이 어렵게 설계 |
운영 | 실패 원인 추적이 흐려질 수 있음 | 단계별 성공·실패 상태를 명확히 남김 |
실무자는 먼저 “LLM이 생각해야 하는 일”과 “코드가 반드시 통제해야 하는 일”을 분리해야 합니다. 정책 판정, 고객 문장 해석, 답변 초안은 LLM 후보입니다. 결제 취소, 환불 실행, 권한 변경, 최종 발송은 코드 그래프와 승인 정책 후보입니다.
바로 할 일은 무엇인가요?
현재 에이전트 업무에서 반드시 순서가 지켜져야 하는 단계를 적습니다.
각 단계 옆에 “LLM 판단 필요” 또는 “코드 결정 가능”을 표시합니다.
외부 API 응답 전체를 다음 프롬프트에 넣는 구간을 찾습니다.
승인, 결제, 삭제, 권한 변경 같은 side effect 단계에는 사람 확인이나 명시적 정책 노드를 둡니다.
실패 메시지를 “모델 실패”가 아니라 “정책 판정 실패”, “도구 호출 실패”, “사용자 확인 필요”처럼 나눕니다.
주의할 점은 무엇인가요?
워크플로우 그래프가 모든 문제를 자동으로 해결하지는 않습니다. 업무 규칙 자체가 자주 바뀌거나 예외가 너무 많으면 그래프가 복잡해질 수 있습니다. 그래서 처음부터 전 업무를 옮기기보다 환불, 승인, 리포트 생성처럼 반복되고 위험도가 높은 한 흐름만 고르는 것이 좋습니다.
또한 ADK 2.0을 도입한다는 말이 LLM 활용을 줄이라는 뜻은 아닙니다. LLM은 애매한 문장 해석과 초안 작성에 강하고, 코드는 권한과 순서 제어에 강합니다. 두 역할을 섞지 않는 팀이 프롬프트만 길게 쓰는 팀보다 장애 분석을 빠르게 할 수 있습니다.
FAQ는 무엇을 확인해야 하나요?
ADK 2.0 Workflows는 누구에게 필요한가요?
반복 업무에 AI 에이전트를 붙였지만 실행 순서, 승인, 실패 처리가 불안한 개발팀에게 필요합니다.
기존 에이전트를 전부 다시 만들어야 하나요?
아니요. 가장 위험한 side effect가 있는 한 흐름부터 그래프로 분리하면 됩니다.
프롬프트 인젝션 방어에 도움이 되나요?
도움이 됩니다. 실행 경로를 LLM 판단과 분리하면, 입력 문장이 곧바로 위험한 도구 실행으로 이어질 가능성을 줄일 수 있습니다.
토큰 절감 수치는 그대로 믿어도 되나요?
공식 예시는 특정 조건의 illustrative 결과입니다. 내 서비스에서는 단계별 로그로 직접 비용과 지연을 측정해야 합니다.
오늘은 고객 응대 에이전트 하나를 떠올리고, LLM이 판단할 노드와 코드가 통제할 노드를 색깔만 나눠 보세요. 그 한 장이 운영 가능한 에이전트 설계의 출발점입니다.