이런 상황을 상상해 보세요.
에이전트에게 다섯 개의 도구와 하나의 지시를 내립니다.
환불 프로세스가 완벽하게 실행될 수도 있습니다.
그런데 확인 이메일 전송이 실패합니다.
에이전트는 시퀀스를 처음부터 다시 시작하며, 이미 성공한 액션을 반복합니다.
그 결과는? 이중 환불입니다.
프로토타입은 완벽하게 작동했습니다. 하지만 프로덕션 시스템은 그렇지 않았습니다.
문제는 프롬프트가 아닙니다.
문제는 모델에게 애초에 실행해서는 안 되는 프로세스를 실행하도록 요청하는 데 있습니다!
LLM은 끊임없이 라우팅, 스케줄링, 오류 관리 작업을 강요받고 있습니다.
이런 작업은 표준 소프트웨어가 이미 완벽하게 예측 가능한 방식으로 처리하고 있는 일들입니다.
그런데도 우리는 AI에게 서로 충돌하는 두 가지 일을 시키고 있습니다:
- 세상 읽기: 예측할 수 없고 비정형화된 데이터를 이해하는 일
- 프로세스 실행하기: 고정되고 사전 정의된 이벤트 시퀀스를 조율하는 일
전자는 AI가 가장 빛을 발하는 영역입니다. 후자는 전통적인 코드가 담당할 영역입니다.
다음 단계가 이미 정해져 있다면, 모델이 그것을 추측할 필요가 없습니다.
다섯 개의 도구와 하나의 큰 지시를 받은 단일 자율 에이전트를 상상해 보세요:
→ 구매 내역 조회
→ 환불 정책 확인
→ 자격이 되면 환불 처리
→ 이메일 발송
→ 티켓 종료
이를 해내려면 에이전트는 시퀀스를 기억하고, 모든 도구 결과를 살펴보고, 다음 단계를 추론해야 합니다.
돈이 송금된 후 확인 이메일이 실패하면, 모델은 안전한 실행 상태에서 재개하는 대신 컨텍스트 윈도우에서 워크플로우를 재구성하려고 시도합니다.
그 결과는 앞서 언급한 이중 환불로 이어집니다.
ADK 2.0이 혼란 속에 질서를 가져오는 방법
Google의 ADK 2.0은 전혀 새로운 접근 방식으로 이 문제를 해결합니다.
예측 가능한 액션을 구체적인 워크플로우 단계로 다시 전환하고, 실제로 해석이 필요한 지점에만 AI를 투입합니다:
[환불 워크플로우 그래프 - 출처: "우리가 ADK 2.0을 만든 이유"]
위 예시에서 구매 내역 조회, 환불 처리, 티켓 종료는 일반적인 소프트웨어 액션입니다.
불만 사항 분석과 개인화된 확인 메시지 작성은 AI에게 맡겨집니다.
그 결과는 고정된 실행과 집중된 추론이 결합된 훌륭한 하이브리드입니다.
하지만 이런 생각이 들 수도 있습니다. 이건 단순히 경직된 자동화로의 회귀 아닌가요?
에이전트가 대체해야 했던 바로 그 워크플로우를 우리가 하드코딩하고 있는 건 아닐까요?
글쎄요, 꼭 그렇지는 않습니다.
워크플로우는 이미 알려진 경계를 정의합니다.
에이전트는 여전히 해석, 언어, 판단이 필요한 부분을 처리합니다.
목표는 유연성을 제거하는 것이 아니라, 모델이 실행할 때마다 동일한 실행 경로를 다시 찾아내도록 강요하는 것을 중단하는 것입니다.
불필요한 모델 결정을 제거함으로써, 이 아키텍처는 계산 결과를 완전히 바꿔 놓습니다.
동일한 환불 워크플로우, 동일한 모델.
하지만 ADK 2.0을 사용하면 토큰은 5,152개에서 2,265개로 줄어들고, 지연 시간은 7.2초에서 5.7초로 단축됩니다 🔥
[출처: "우리가 ADK 2.0을 만든 이유"]
이 구조는 토큰 사용량을 절반으로 줄여 주는 자연스러운 필터 역할을 합니다.
전체 히스토리를 전달하는 대신, 에이전트는 필요한 정보만 볼 수 있습니다 (예: 정책 에이전트는 불만 사항만 확인합니다).
그 효과는 즉각적입니다:
- 프롬프트 노이즈 감소 및 프라이버시 강화
- 엄격하게 제한된 실행
- 안전장치: 모델이 잘못된 판단을 내릴 수는 있지만, 자체적으로 경로를 임의로 만들 수는 없습니다
프론트엔드에도 경계가 필요합니다: A2UI가 UI를 제어하는 방법
좋습니다. 이제 환불 워크플로우는 제어되고 있습니다.
ADK 2.0이 경로를 정의하고 에이전트가 자체적인 시퀀스를 만들지 못하도록 막았습니다.
하지만 사용자는 에이전트가 생성한 결과물을 안전하게 확인하고 조치를 취할 방법이 여전히 필요합니다.
즉, 프론트엔드에도 경계가 필요합니다!
이제 승인된 모든 환불에 관리자의 승인이 필요하다고 상상해 보세요.
에이전트는 단순히 "이 환불은 승인되었습니다." 라는 텍스트를 생성해서는 안 됩니다.
다음 내용을 포함하는 구조화된 카드를 표시해야 합니다:
- 금액
- 거래 내역
- 정책 사유
- 명확한 '승인/거부' 버튼
바로 이 지점에서 Google의 A2UI가 등장합니다!
A2UI를 사용하면 에이전트는 실행 가능한 프론트엔드 코드 대신 선언형 JSON 페이로드를 반환합니다.
호스트는 해당 페이로드를 검증하고, 자체 카탈로그에서 지원하는 컴포넌트만 렌더링합니다.
에이전트는 어떤 정보를 표시할지 결정하고, 앱은 이를 어떻게 렌더링할지를 제어합니다.
👇 아래는 A2UI로 렌더링된 카드의 예시로, A2UI가 구현할 수 있는 다양한 UI 구성을 보여줍니다:
Google의 A2UI-over-MCP Recipe Studio 데모는 이 아키텍처의 실제 작동 모습을 보여줍니다:
출처: Google Developers Blog.
👆 정적 선택 폼은 MCP Resource를 통해 전달되고, 동적으로 생성된 레시피 카드는 MCP Tool을 통해 반환되는 것을 확인할 수 있습니다.
A2UI는 두 가지 모두 호스트 애플리케이션 내부에서 네이티브로 렌더링합니다.
대칭 구조가 보이시나요?
- ADK 2.0은 백엔드에서 에이전트가 할 수 있는 일을 제한합니다
- A2UI는 프론트엔드에서 에이전트가 생성할 수 있는 것을 제한합니다
두 경우 모두 모델은 추론할 여지를 가지지만, 오직 애플리케이션이 정의한 경계 안에서만 가능합니다.
앞서 논의한 환불 예시로 돌아가 보면, 표준 환불에는 단순한 승인 카드만 필요할 수 있습니다.
하지만 예외 사항, 첨부 파일, 부분 상환이 포함된 분쟁 케이스는 더 풍부한 경험이 필요할 수 있습니다.
바로 이 지점에서 MCP App이 개입하여 복잡한 상호작용을 위한 격리된 작업 공간을 제공할 수 있습니다:
→ ADK는 무엇이 가능한지를 제어합니다
→ A2UI는 결과를 시각화하고 조치 가능하게 만듭니다
→ MCP App은 복잡한 작업 공간을 처리합니다
더 자세히 알고 싶으신가요?
ADK 2.0, A2UI, 그리고 Google Cloud의 광범위한 에이전트 플랫폼을 살펴보는 데 필요한 모든 자료를 정리했습니다:
- ADK 2.0: https://fandf.co/4yJhcyh
- A2UI: https://fandf.co/3S1O9pe
- A2UI over MCP: https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform: https://fandf.co/4x59VY7
이 프로젝트에서 @googlecloud와 함께하게 되어 영광이었습니다! 🤝
LLM, AI 에이전트, 워크플로우의 최신 소식을 놓치지 않으려면 @datachaz를 팔로우해서 매일 새로운 인사이트를 받아보세요.
