Gemini 3 Tool Calling 신뢰성과 엔터프라이즈 에이전트 설계

Gemini 3의 Thought Signature, 도구 호출 오류 복구, 복잡한 지시 처리와 엔터프라이즈 에이전트 운영 방식을 비교한다.

2026-08-14 · 최초 발행 2026-05-06

도구 호출 사이에서 추론 맥락을 보존하는 방식

Google DeepMind가 2026년 초 공개한 Gemini 3는 복잡한 지시를 최소한의 프롬프트 튜닝으로 처리하면서 도구 호출의 신뢰성을 높이는 데 초점을 맞췄다. 이 모델을 기업 환경에서 운용할 때는 함수 선택 능력만 볼 수 없다. 멀티턴 호출의 상태 유지, 파라미터 해석, 오류 복구와 중복 실행 방지가 함께 맞물려야 장기 워크플로우를 맡길 수 있다.

이 구조의 중심에는 Thought Signature가 있다. 모델은 함수를 호출하기 전에 내부 추론 과정을 암호화된 서명으로 압축해 응답에 첨부한다. 클라이언트는 이 서명을 다음 요청의 대화 이력에 그대로 포함해야 한다. 그래야 모델이 여러 턴에 걸쳐 앞선 판단의 맥락을 이어갈 수 있다.

Gemini 3 이전 모델에서는 멀티턴 함수 호출 도중 컨텍스트가 끊기면서 같은 작업을 반복하거나 잘못된 파라미터를 고르는 사례가 보고되었다. Gemini 3는 함수 호출이 포함된 모든 응답에 Thought Signature를 반환하는 방식으로 이 문제를 다룬다. 사고 설정이 MINIMAL 수준이어도 서명은 포함된다.

서명의 위치는 호출 형태에 따라 다르다. 병렬 함수 호출에서는 첫 번째 함수 호출 파트에만 서명이 붙고, 여러 단계를 순서대로 수행하는 호출에서는 각 호출마다 독립된 서명이 발급된다. 클라이언트가 이를 빠뜨리면 컨텍스트 일관성이 깨질 수 있으므로 사용하는 SDK가 서명을 자동으로 처리하는지 확인해야 한다.

정확한 파라미터와 복구 가능한 오류 응답

운영 중 발생하는 문제는 올바른 함수를 고르는 데서 끝나지 않는다. 함수 스키마에 맞는 파라미터를 구성하고, 실행 실패 후 적절한 다음 행동을 정하는 과정도 호출 신뢰성을 좌우한다.

TAFC(Think-Augmented Function Calling) 연구에서는 함수 스키마 설명을 정밀하게 작성하는 것만으로 파라미터 정확도가 30% 이상 향상될 수 있다고 설명한다. Gemini 3는 이 원리를 훈련 단계에 반영해 사용자 지시가 모호해도 함수 시그니처에 맞는 파라미터를 추론하도록 설계되었다.

도구가 실패했을 때는 오류 내용과 실행 컨텍스트를 ToolMessage 형태로 모델에 돌려주는 패턴을 사용할 수 있다. 모델은 이 응답을 바탕으로 파라미터를 고쳐 재시도하거나 다른 함수를 선택하며, 자체적으로 판단할 수 없으면 사용자에게 명확화를 요청한다.

HiTEC(Hierarchical Tool Error Checklist)는 처리 방향에 따라 오류를 일시적 오류, LLM 복구 가능 오류, 사용자 개입 필요 오류, 예외 오류의 4가지로 나눈다. 일시적 오류는 재시도하고, LLM이 복구할 수 있는 오류는 ToolMessage로 반환한다. 나머지는 사람의 판단이 필요한지 또는 예외로 다뤄야 하는지를 구분하는 기준이 된다.

중복 실행을 억제하는 멀티스텝 흐름

같은 도구를 반복 호출하거나 실행 루프에서 빠져나오지 못하면 비용이 늘어날 뿐 아니라 실제 장애로 번질 수 있다. Gemini 3는 Thought Signature에 기록된 상태를 이용해 이전 단계에서 끝낸 작업을 다시 인식하는 능력을 개선했다. 멀티 에이전트 환경에서도 작업 완료 신호를 Signature 체계로 전달할 수 있어 에이전트 사이의 중복 실행을 구조적으로 완화한다.

성공오류아니오사용자 입력Gemini 3 모델 추론도구 호출 필요?Thought Signature 생성함수 호출 파트 반환클라이언트: 도구 실행실행 결과ToolMessage 반환 (결과 포함)ToolMessage 반환 (오류컨텍스트 포함)Signature 포함 다음 요청최종 응답 생성병렬 호출? 번째 파트에만 Signature부여병렬 도구 실행

이 흐름에서 클라이언트는 단순한 도구 실행기가 아니다. 함수 호출과 실행 결과, Thought Signature를 손실 없이 연결해 모델이 다음 판단에 필요한 상태를 유지하도록 하는 역할을 맡는다.

작업 난도에 맞춰 계획 깊이를 조절한다

Gemini 3에서는 사고 수준을 thinking_level로 제어할 수 있다. 설정값은 minimal, standard, high이며, high에서는 복잡한 지시 분해와 계획 수립, 버그 탐지에 더 많은 토큰을 배정한다.

정형화된 데이터 추출에는 minimal을 적용하고, 계약서 평가나 공급망 의사결정처럼 여러 조건을 장기간 추적해야 하는 작업에는 high를 선택할 수 있다. 개발자가 작업 성격에 따라 비용과 성능의 균형을 명시적으로 조정하는 방식이다.

모델은 사용자가 실행 단계를 일일이 지정하지 않아도 지시의 목표를 하위 작업으로 나누고 각 작업을 알맞은 도구에 연결한다. Shopify CTO가 언급한 최소 프롬프트 튜닝은 개발자가 가능한 모든 분기를 프롬프트에 작성하지 않아도 모델이 계획을 세워 실행하는 능력을 가리킨다.

일부 단계가 실패해도 실행 상태를 이어간다

장기 실행 워크플로우에서는 어느 한 단계가 실패할 가능성을 전제로 설계해야 한다. Gemini 3는 실패한 하위 작업의 오류 컨텍스트를 다음 추론 단계로 넘겨 대안 경로를 찾는다. 일시적 오류라면 파라미터를 조정해 재시도하고, 모델만으로 해결할 수 없는 상황에서는 사람의 개입이 필요하다는 신호와 함께 현재 실행 상태를 보존한다.

이 실행 기록은 Gemini Enterprise Agent Platform의 Agent Gateway 및 Audit Log와 결합된다. 운영자는 에이전트가 단계마다 내린 결정과 실패한 도구 호출을 플랫폼에서 추적할 수 있다.

기업용 에이전트를 한곳에서 통제하는 플랫폼

Google Cloud는 2026년 4월 22일 Vertex AI를 계승하는 Gemini Enterprise Agent Platform을 공식 발표했다. 에이전트 빌드와 배포뿐 아니라 거버넌스와 모니터링까지 단일 환경에서 관리하는 플랫폼이다.

Agent Registry는 에이전트 버전과 메타데이터를 관리하고, Agent Gateway는 요청을 라우팅하면서 시맨틱 정책을 적용한다. Audit Log에는 에이전트의 행동 이력이 남으며, Operational Telemetry는 모델 엔드포인트의 성능 지표를 제공한다. Model Garden을 통하면 200개 이상의 외부 모델을 같은 거버넌스 체계에서 사용할 수 있고, Gemma 4 같은 오픈 모델도 플랫폼 안에서 운용할 수 있다.

여러 에이전트를 동시에 배포하는 조직에서는 접근 통제가 핵심 운영 과제가 된다. 시맨틱 정책 구조체를 사용하면 각 에이전트가 어떤 도구에 접근할 수 있는지를 중앙에서 관리할 수 있다. A2A(Agent-to-Agent) 프로토콜도 지원하므로 전문화된 에이전트가 협력하는 구조를 표준 방식으로 구현할 수 있다.

공개 벤치마크에서 드러난 모델별 차이

2026년 5월 공개된 자료를 보면 Gemini 3.1 Pro, GPT-5.5, Claude Opus 4.7은 평가 대상에 따라 순위가 달라진다.

llm-stats.com의 Tool Calling 리더보드에서는 Gemini 3.1 Pro, Claude Opus 4.6, LongCat-Flash-Thinking 등이 99.3점대로 상위권을 형성한다. 이 평가는 함수 선택 정확도와 파라미터 추출, 멀티스텝 도구 체인의 오케스트레이션을 함께 측정한다.

도구 오케스트레이션을 다루는 MCP-Atlas에서는 Claude Opus 4.7이 77.379.1%로 앞섰고, GPT-5.5는 75.3%, Gemini 3.1 Pro는 73.9%를 기록했다. 명령행 계획과 반복 실행을 측정하는 Terminal-Bench 2.0에서는 GPT-5.5가 82.7%였으며, Opus 4.7은 6972%, Gemini 3.1 Pro는 68% 수준이었다.

웹 리서치 정확도를 평가하는 BrowseComp에서는 GPT-5.5가 90.1%, Gemini 3.1 Pro가 85.9%, Opus 4.7이 79.3% 순으로 나타났다.

Gemini 3.1 Pro가 유리한 운영 조건

Gemini 3.1 Pro의 뚜렷한 차별점은 1M 토큰 컨텍스트 창이다. 대형 코드베이스 전체를 컨텍스트에 넣거나 수백 페이지의 계약서와 규제 문서를 함께 분석하고, 긴 대화 이력을 유지해야 하는 작업에서 강점을 보인다. GPT-5.5나 Opus 4.7과 유사한 성능을 더 낮은 비용으로 달성할 수 있는 태스크 범위가 넓다는 점도 비용 효율성 측면의 장점이다.

플랫폼 결합 수준도 선택에 영향을 준다. 다른 모델 역시 Model Garden을 통해 Gemini Enterprise Agent Platform에서 운용할 수 있지만, Gemini 3 계열은 Thought Signature와 Agent Gateway, Audit Log의 연계가 더 깊다.

워크로드 유형 권장 모델 근거
복잡한 도구 오케스트레이션, 엣지 케이스 처리 Claude Opus 4.7 MCP-Atlas 선두, 불확실성 처리 정교함
자율 에이전트, 최소 도구 호출로 목표 달성 GPT-5.5 Terminal-Bench 압도적, BrowseComp 선두
대용량 컨텍스트 처리, 비용 효율 에이전트 Gemini 3.1 Pro 1M 토큰 창, 플랫폼 네이티브 통합, 경쟁력 있는 단가
멀티 에이전트 거버넌스, 기업 감사 추적 필요 Gemini 3 계열 Enterprise Agent Platform 네이티브 지원

모든 워크로드를 지배하는 단일 모델은 없다. 도구 오케스트레이션의 정밀도가 우선이면 Claude Opus 4.7, 속도와 자율성이 중요하면 GPT-5.5를 고려할 수 있다. Google Cloud 인프라를 이미 사용하면서 대용량 문서 처리와 멀티 에이전트 거버넌스가 필요하다면 Gemini 3.1 Pro와 Enterprise Agent Platform의 조합이 빠른 도입 경로가 된다.

모델의 벤치마크 점수만 비교해서는 운영 적합성을 판단하기 어렵다. 실제 선택 기준은 워크로드가 요구하는 컨텍스트 규모, 에이전트 거버넌스 수준, 기존 클라우드 기반과 도구 호출의 성격이다.

Sources

Gemini 3Tool CallingAI 에이전트Vertex AI멀티 에이전트