Google이 에이전트 아키텍처 플레이북을 변경하다: 하나의 프롬프트로 여러 모델 및 실제 비즈니스 액션 구현

사용자들이 애플리케이션, AI 모델, 자동화 도구 사이를 전환하는 대신 전체 비즈니스 워크플로우를 위임할 수 있다면 어떨까요? Google이 새로 발표한 Gemini 에이전트는 바로 그 미래를 가리키며, 신뢰할 수 있는 에이전트를 구축하기 위해 개발자들이 해결해야 할 과제를 보여줍니다.

2026년 10월 8일, Google Cloud는 'Gemini at Work' 이벤트에서 Gemini 에이전트를 발표했습니다. 아이디어는 간단합니다: 사용자가 원하는 결과(outcome)를 설명하면, 에이전트가 작업을 계획하고, 도구를 사용하며, 비즈니스 시스템에 연결한 다음, 완성된 결과를 반환하는 것입니다.

Google은 이 에이전트가 질문 답변 및 콘텐츠 생성부터 코딩 및 기존 애플리케이션 전반의 작업 완료까지 다양한 활동을 지원할 수 있다고 말합니다. 또한 모델 선택, 비용 통제, 보안, 엔터프라이즈 거버넌스(enterprise governance)를 강조합니다.

개발자들에게 흥미로운 발전은 단순히 또 다른 AI 어시스턴트가 아니라는 점입니다. 그것은 한 번에 하나의 프롬프트에 응답하는 대신 전체 워크플로우를 오케스트레이션(orchestrate)하는 에이전트로의 이동입니다.

1. 챗봇에서 워크플로우 실행기로
전통적인 AI 상호작용은 다음과 같습니다:
사용자 질문
↓
LLM
↓
답변

에이전트 기반 워크플로우는 다릅니다:
사용자 목표(User Goal)
↓
에이전트 계획(Agent Planning)
↓
도구 및 모델 선택(Select Tools and Models)
↓
액션 실행(Execute Actions)
↓
결과 확인(Verify Results)
↓
완성된 결과(Completed Outcome)

비즈니스 요청을 고려해 봅시다:
'이번 달 판매 데이터를 분석하고, 실적이 저조한 제품을 식별하며, 보고서를 준비하세요.'

유능한 에이전트는 판매 데이터를 검색하고, 지표를 계산하며, 관련 제품을 식별하고, 보고서를 생성해야 할 수 있습니다. 애플리케이션은 모든 것을 신뢰성 있게 수행하기 위해 하나의 모델 응답에 의존하는 대신, 이러한 작업을 조정(coordinate)해야 합니다.

2. 모델 선택이 아키텍처 결정 사항이 되다
Google 발표에서 주목할 만한 점은 각 작업에 가장 적합한 모델을 선택하는 데 중점을 둔 것입니다.
Google에 따르면 Gemini 에이전트는 자체 Gemini 모델 패밀리와 Claude 모델 전반에 걸쳐 오케스트레이션(orchestrate) 할 수 있으며, 플랫폼이 발전함에 따라 다른 모델 지원도 예상됩니다. 또한 발표에서는 스마트 라우팅과 프로젝트 수준의 지출 제어 기능도 설명합니다.

이는 유용한 설계 원칙을 반영합니다:
단순 분류 → 더 작은 모델
복잡한 추론 → 더 강력한 모델
데이터 검색 → 검색 또는 데이터베이스 도구
계산 → 결정론적 코드

모든 작업에 동일한 모델이 필요하지 않습니다.
프로덕션 애플리케이션은 정확도(accuracy), 지연 시간(latency), 비용, 그리고 작업 요구 사항을 고려하여 모델 선택을 평가해야 합니다.

3. 실제 엔지니어링 과제는 오케스트레이션이다
실용적인 에이전트 아키텍처는 다음과 같은 모습일 수 있습니다:
사용자 목표
↓
에이전트 런타임(Agent Runtime)
↓
작업 오케스트레이션(Task Orchestration)
/ |
↓ ↓ ↓
검색 데이터베이스 분석
\ | /
↓ ↓ ↓
결과 유효성 검사(Validate Results)
↓
최종 출력

도구들은 기능을 노출합니다. 런타임이 실행을 조정합니다. 결정론적 서비스(Deterministic services)는 정확한 결과가 필요한 작업을 처리합니다.
예를 들어, LLM은 어떤 판매 보고서를 검색할지 결정할 수 있지만, 실제 합계 계산은 Python이나 SQL이 수행해야 합니다.
이러한 분리는 결과를 테스트하고 검증하기 쉽게 만듭니다.

4. 보안은 아키텍처의 일부여야 한다
Google의 발표는 또한 엔터프라이즈 거버넌스(enterprise governance)를 강조합니다.
설명된 제어 기능에는 에이전트 신원(agent identity), 세분화된 권한(fine-grained permissions), 감사 추적(audit trails), 격리된 실행 환경(isolated execution environments), 그리고 조직 정책을 강제하기 위한 에이전트 게이트웨이(Agent Gateway)가 포함됩니다.

이러한 제어 기능은 근본적인 문제를 해결합니다: 에이전트는 여러 시스템에 접근할 권한을 가질 수 있지만, 사용 가능한 모든 작업을 자동으로 수행할 권한을 가져서는 안 됩니다.

더 안전한 워크플로우는 다음과 같습니다:
에이전트가 작업 제안 → 권한 확인(Permission check) ↓ 비즈니스 검증(Business validation) ↓ 필요 시 승인(Approval if required) ↓ 실행(Execution) ↓ 감사 로그(Audit log)

예를 들어, 판매 수치를 읽고 환불을 처리하는 것은 동일한 권한 정책을 공유해서는 안 됩니다.
모델이 어떤 액션을 선택할 수는 있지만, 애플리케이션 코드와 인프라가 경계를 강제해야 합니다.

5. 개발자가 실험할 수 있는 방법
이러한 패턴을 학습하기 위해 범용적인 엔터프라이즈 에이전트가 필요하지 않습니다. AI SDK와 몇 가지 제어된 도구를 사용하여 작은 워크플로우를 구축해 보세요:
사용자가 제품 추천을 요청함
↓
제품 검색
↓
제품 세부 정보 검색
↓
결정론적 필터 적용
↓
추천 생성

그런 다음 다음 항목들을 측정합니다:

• 성공적인 작업 완료율
• 도구 호출 횟수
• 지연 시간(Latency)
• 모델 및 도구 비용
• 유효하지 않은 액션 수
• 인간의 수정 횟수

다음으로, 승인이 필요한 민감한 작업을 추가합니다. 이는 에이전트 개발을 단순히 인상적인 텍스트를 생성하는 시연이 아니라 측정 가능한 결과가 있는 엔지니어링 연습으로 바꿉니다.

저자 소개 -> 저는 Ashutosh Maurya이며, 고성능 UI 개발 및 MERN 스택에서 6년 이상의 경험을 가진 시니어 풀스택 AI 엔지니어입니다. Schooliko와 같은 확장 가능한 아키텍처 및 AI 통합 플랫폼 구축을 전문으로 합니다. 저의 목표는 복잡한 백엔드 로직과 원활한 프론트엔드 경험 사이의 격차를 해소하는 것입니다.