AI 에이전트(AI agents)는 독립적으로 보일 때 가장 흥미롭게 느껴집니다.

• 요청을 읽습니다.
• 도구(tool)를 선택합니다.
• 다음 단계를 결정합니다.
• 응답을 작성합니다.
• 동작을 트리거(trigger)합니다.

이는 강력하게 느껴집니다.

하지만 동시에 상황이 불편해질 수 있는 지점이기도 합니다. 제품 워크플로(product workflow)는 모델이 실행되는 동안 스스로 발명해야 하는 것이 항상 아니기 때문입니다.

• 환불에는 규칙이 있습니다.
• 결제 변경에는 확인 절차가 있습니다.
• CRM 업데이트에는 올바른 계정이 필요합니다.
• 지원 티켓(support ticket)은 종료되기 전에 컨텍스트(context)가 필요합니다.
• 계정 작업은 무엇인가가 변경되기 전에 권한이 필요합니다.

이것이 바로 Google ADK 2.0 워크플로(Workflows)에 주목해야 하는 이유입니다.

이번 업데이트는 단순한 또 다른 AI 에이전트 기능이 아닙니다. 이는 프로덕션 AI(production AI)를 생각하는 더 나은 방식을 제시합니다: 제품이 경로를 제어하게 하세요. 판단이 필요한 곳에서만 AI가 돕게 하세요.

Google ADK 2.0 워크플로(Workflows)란 무엇인가

Google ADK 2.0은 더 구조화된 에이전트를 구축할 수 있도록 워크플로(workflow) 지원을 추가합니다.

모델이 모든 단계를 스스로 결정하게 하는 대신, 개발자는 경로를 더 명확하게 정의할 수 있습니다.

해당 경로는 다음과 같은 것들을 포함할 수 있습니다:

• 고정된 소프트웨어 단계,
• 도구 호출(tool calls),
• AI 추론(reasoning),
• 전문 에이전트(specialist agents),
• 인간의 검토(human review),
• 그리고 안전한 중단 지점(stopping points).

쉽게 말해, 이는 제품이 다음과 같이 말할 수 있음을 의미합니다:

이 단계는 항상 먼저 수행됩니다.

이 도구는 여기서만 허용됩니다.

이 동작은 승인이 필요합니다.

이 오류는 워크플로를 중단해야 합니다.

이 부분은 AI가 추론(reason)해야 하는 곳입니다.

이것이 에이전트 중심의 제품(agentic products)을 구축하는 훨씬 더 건강한 방식입니다.

에이전트에게 모든 것을 부여할 때 발생하는 문제

초기 에이전트 설계의 상당수는 너무 많은 자유를 주는 것에서 시작합니다.

에이전트는 목표, 프롬프트(prompt), 몇 가지 도구, 그리고 작업을 완료하라는 광범위한 지침을 받습니다.

이는 연구, 초안 작성 또는 내부 실험에는 괜찮을 수 있습니다.

하지만 고객 대상 제품 흐름(customer-facing product flows)은 다릅니다.

만약 에이전트가 돈, 액세스 권한, 기록, 메시지, 파일 또는 지원 동작을 처리하고 있다면, 제품에는 더 강력한 경계(boundaries)가 필요합니다.

문제는 모델이 쓸모없다는 것이 아닙니다. 문제는 모델에게 너무 많은 일을 한꺼번에 시키고 있다는 점입니다.

사용자를 이해해야 합니다.

다음 단계를 선택해야 합니다.

비즈니스 규칙을 기억해야 합니다.

도구 (tool)를 선택해야 합니다.

도구의 결과를 해석해야 합니다.

계속할지 여부를 결정해야 합니다.

실패를 처리해야 합니다.

그리고 작업이 완료되었을 때를 결정해야 합니다.

이 모든 것을 하나의 유연한 시스템 안에 담기에는 너무 많은 양입니다. 좋은 소프트웨어는 보통 책임을 분리합니다. AI 워크플로 (workflows)도 마찬가지여야 합니다.

단순한 제품적 교훈

워크플로의 어떤 부분은 유연해야 합니다. 어떤 부분은 그렇지 않아야 합니다.

AI는 입력값이 무질서할 때 유용합니다.

예를 들어:

• 고객의 불만 사항 이해,
• 긴 스레드 (thread) 요약,
• 문서에서 세부 정보 추출,
• 사용자 의도 (intent) 분류,
• 답장 초안 작성,
• 또는 혼란스러운 사례 설명.

하지만 제품은 일관성이 필요한 단계들을 제어해야 합니다.

예를 들어:

• 권한 확인,
• 필수 필드 유효성 검사,
• 계정 소유권 확인,
• 환불 정책 확인,
• 안전하지 않은 동작 차단,
• 사람의 검토 요청,
• 감사 기록 (audit records) 저장,
• 그리고 필수 데이터가 누락되었을 때 중단.

이곳들은 모델에게 자유가 필요한 곳이 아닙니다.

이곳들은 제품에게 제어가 필요한 곳입니다.

AI 에이전트 워크플로를 설계하는 더 나은 방법

AI 에이전트를 제품 전체가 아닌, 제품의 한 부분으로 생각하십시오.

더 강력한 워크플로는 다음과 같은 모습일 수 있습니다:

1. 고객이 무질서한 요청을 보냅니다.
2. 제품이 필요한 계정 컨텍스트 (context)를 수집합니다.
3. 제품이 권한을 확인합니다.
4. AI가 요청을 해석합니다.
5. 제품이 허용된 경로를 확인합니다.
6. AI가 응답 또는 다음 단계의 초안을 작성합니다.
7. 사람이 민감한 사례를 검토합니다.
8. 제품이 승인된 동작만을 완료합니다.
9. 시스템이 발생한 일을 기록합니다.

이것 역시 AI 기반의 워크플로입니다.

하지만 비즈니스 프로세스를 헤쳐 나가며 추측하는 느슨한 에이전트가 아닙니다.

이것은 내부에 AI를 포함한 제품 흐름 (product flow)입니다.

그 차이가 중요합니다.

예시: 환불 워크플로 (refund workflow)

고객이 환불을 요청한다고 가정해 봅시다.

느슨한 에이전트 (loose agent)라면 메시지를 읽고, 주문 내역을 확인하고, 해당 사례가 타당해 보이는지 결정한 뒤, 적절하다고 판단되면 환불을 실행할 수도 있습니다.

그것은 위험합니다.

더 나은 워크플로 (workflow)는 작업들을 분리합니다.

제품 (product)이 주문 정보를 가져옵니다.

제품이 환불 가능 기간을 확인합니다.

제품이 계정 소유권을 검증합니다.

AI가 고객의 메시지를 읽고 이유를 식별합니다.

제품이 해당 사례가 승인된 경로와 일치하는지 결정합니다.

만약 사례가 민감하다면, 사람이 이를 검토합니다.

그제서야 제품이 동작을 완료합니다.

AI는 여전히 도움을 줍니다.

하지만 전체 프로세스를 소유하지는 않습니다.

이것이 SaaS 및 AI 제품에 중요한 이유

더 많은 SaaS 제품들이 에이전트 (agents)를 추가할 것입니다.

고객 지원 에이전트 (Support agents).

영업 에이전트 (Sales agents).

CRM 에이전트 (CRM agents).

재무 에이전트 (Finance agents).

인사 에이전트 (HR agents).

운영 에이전트 (Operations agents).

내부 워크플로 에이전트 (Internal workflow agents).

어떤 것들은 첫 번째 버전에서 매우 인상적일 것입니다.

하지만 유용한 버전은 제품 워크플로 (product workflow) 내부에서 신뢰할 수 있는 버전입니다.

그것은 팀이 다음 사항들을 알고 있어야 함을 의미합니다:

• 에이전트가 무엇을 읽을 수 있는지,
• 어떤 도구 (tools)를 호출할 수 있는지,
• 어떤 단계가 고정되어 있는지,
• AI가 추론 (reasoning)할 수 있도록 허용된 영역은 어디인지,
• 사람의 검토 (human review)가 어디에서 발생하는지,
• 어떤 동작이 차단되는지,
• 무언가 실패했을 때 어떤 일이 일어나는지,
• 그리고 팀이 나중에 워크플로를 어떻게 추적 (trace)할 수 있는지.

이것이 많은 AI 기능들이 놓치고 있는 부분입니다.

그들은 에이전트가 무엇을 할 수 있는지에 집중합니다.

더 나은 질문은 제품이 에이전트에게 무엇을 하도록 허용해야 하는가입니다.

실질적인 규칙

제품 팀을 위한 간단한 규칙은 다음과 같습니다:

불명확한 입력 (unclear input)에는 AI를 사용하십시오.

명확한 규칙 (clear rules)에는 소프트웨어를 사용하십시오.

민감한 판단 (sensitive judgment)에는 사람을 사용하십시오.

이 한 줄의 규칙이 수많은 엉망인 에이전트 설계를 방지할 수 있습니다.

만약 작업에 해석 (interpretation)이 필요하다면, AI가 도움을 줄 수 있습니다.

만약 작업에 순서 (sequence), 권한 (permission), 또는 정책 (policy)이 필요하다면, 제품이 이를 제어해야 합니다.

만약 작업이 돈, 접근 권한, 신뢰, 또는 고객의 결과에 영향을 미친다면, 검토 (review)가 경로의 일부가 되어야 합니다.

창업자를 위한 시사점 (Founder takeaway)

Google ADK 2.0 Workflows는 단순한 개발자 업데이트가 아닙니다.

이는 AI 제품 아키텍처 (Product architecture)가 나아갈 방향에 대한 신호입니다.

가장 뛰어난 AI 에이전트 (AI agent)가 항상 더 높은 자율성 (Autonomy)을 가진 것은 아닙니다.

때로는 더 명확한 제품 경로 (Product path) 내에 있는 에이전트가 더 나은 에이전트일 수 있습니다.

왜냐하면 프로덕션 AI (Production AI)는 모델이 모든 것을 책임지게 만드는 것이 아니기 때문입니다.

그것은 모델에게 적절한 직무를 부여하고, 제품에 적절한 제어권 (Control)을 주며, 전체 워크플로 (Workflow)를 더 신뢰하기 쉽게 만드는 것에 관한 것입니다.

에이전트에 더 많은 도구를 추가하기 전에, 다음을 자문해 보십시오:

이 프로세스의 어떤 부분들이 AI가 스스로 제어해서는 안 되는가?

그 질문이 보통 더 나은 디자인의 시작점입니다.

Sources

• Google ADK 2.0 documentation - https://adk.dev/2.0/

• Google Developers Blog: Why we built ADK 2.0 - https://developers.googleblog.com/why-we-built-adk-20/

• Gemini Enterprise release notes - https://docs.cloud.google.com/gemini/enterprise/docs/release-notes