무엇인가: 2026년 5월 25일 Google DeepMind가 발표한 Gemini 3.5 Flash는 **에이전트 우선 모델 (agent-first model)**로 포지셔닝됩니다. 이는 채팅보다는 Antigravity 다단계 하네스 (multi-step harness)를 제품의 핵심 스토리로 삼는 Flash급 LLM입니다.

이유: 모든 프로덕션 에이전트는 루프(도구 호출, 관찰, 결정, 실패 가능성, 재시도) 내부에서 작동합니다. 채팅 데이터로만 학습된 모델은 이 루프를 생소한 영역으로 취급하는 반면, 에이전트 우선 모델은 이를 본래의 서식지(native habitat)로 취급합니다.

이전 모델과의 차이: 이전의 기본 방식은 도구 사용 하네스(파서, 재시도 래퍼, 검증기)로 감싸진 채팅 튜닝된 베이스 모델이었습니다. 에이전트 우선 모델은 이러한 하네스의 동작을 학습 과정에 내장하여 하네스가 수행해야 할 작업을 줄여줍니다.

다음과 같이 생각해보세요

원어민과 회화 책을 가진 관광객의 차이입니다.

                      도구 사용 루프 (THE TOOL-USE LOOP)
                             │
               ┌─────────────┴─────────────┐
...

• 에이전트 우선 모델 (agent-first model) = 어린 시절부터 도구 호출 (tool-calling) 언어를 배운 원어민
• 도구가 덧붙여진 채팅 모델 (chat model with tools bolted on) = 회화 책을 통해 한 문장씩 해결해 나가는 관광객
• 도구 호출 (tool call) = 모델이 정확하게 말해야 하는 단일 문장
• 환각된 도구 호출 (hallucinated tool call) = 해당 언어에 존재하지 않는 오역된 문장
• 오류 복구 (error recovery) = 듣는 사람이 "이해하지 못했습니다"라고 말하는 순간

빠른 용어 정리

에이전트 루프 (Agent loop) — 모든 에이전트의 기본적인 제어 흐름입니다. 모델이 액션 (action) (일반적으로 도구 호출)을 내보내면, 하네스가 이를 실행하고, 모델이 관찰 (observation) 내용을 읽으며, 모델이 **최종 답변 (final answer)**을 내보낼 때까지 이 사이클이 반복됩니다. AI Agents → The Agent Loop를 참조하세요.

도구 사용 하네스 (Tool-use harness) — 모델의 출력을 **실제 부수 효과 (real side effects)**로 변환하는 LLM 주변의 런타임 래퍼 (runtime wrapper)입니다. 함수 호출을 추출하는 파서 (parser), 이를 실행하는 디스패처 (dispatcher), 재시도 / 타임아웃 로직, 그리고 프롬프트로 다시 전달되는 오류 포맷팅 등이 포함됩니다. harness anatomy를 참조하세요.

함수 호출 (Function calling) — LLM이 자유 형식의 텍스트 (free-text) 대신 **구조화된 함수 이름 + JSON 인자 (JSON arguments)**를 출력하는 프로토콜입니다. 모델은 프롬프트 내에서 도구 스키마 (tool schema)를 제공받으며, 하네스 (harness)가 이를 검증하고 실행합니다. 스키마 설계는 대부분의 실패가 발생하는 지점입니다.

환각된 도구 호출 (Hallucinated tool call) — 모델이 도구 스키마에 존재하지 않는 함수 이름을 호출하거나, 잘못된 인자 형태 (argument shape)로 호출하는 경우입니다. 하네스는 이를 포착하여 오류를 다시 피드백해야 합니다. 도구 호출 추적 (tool-call traces)이 사후 학습 (post-training)의 일부로 포함될 때 이 빈도는 급격히 감소합니다.

복합 오류율 (Compounding error rate) — 턴당 정확도는 루프를 거치며 곱연산 (multiplicatively) 방식으로 누적됩니다. 예를 들어, 턴당 정확도가 95%인 모델은 10턴짜리 작업을 단 하나의 오류 없이 수행할 확률이 약 60%에 불과합니다. 에이전트 우선 학습 (Agent-first training)은 이 복합 오류 문제를 직접적으로 겨냥합니다. Evals → Compounding 섹션을 참조하세요.

Antigravity harness — Gemini 3.5 Flash의 기반이 되는 Google의 에이전트 런타임 (agent runtime)으로, 협업 서브 에이전트 (collaborative subagents) 및 다단계 워크플로우 실행을 지원합니다. 모델 출시와 함께 공개적으로 설명되었습니다. 이 하네스는 모델의 기능이 아닌 하나의 제품입니다.

MCP Atlas — LLM이 실제 MCP 서버 스택(멀티 도구, 멀티 턴, 현실적인 스키마 포함) 위에서 얼마나 잘 작동하는지를 측정하는 벤치마크입니다. Google은 Gemini 3.5 Flash를 다른 프론티어급 (frontier-class) 모델들과 비교하여 포지셔닝하는 데 이를 사용합니다.

뉴스. 2026년 5월 25일, Google DeepMind는 Gemini 3.5 시리즈의 첫 번째 모델인 Gemini 3.5 Flash를 발표했습니다. 이 모델의 프레임워크는 명시적으로 에이전트 우선 (agent-first)을 지향합니다. 블로그 포스트는 이 모델을 협업 서브 에이전트를 위한 Antigravity harness, 그리고 해석 가능성 기반의 안전 점검을 위한 Frontier Safety Framework와 결합하여 설명합니다. 주요 헤드라인 점수로는 Terminal-Bench 2.1 76.2%, MCP Atlas 83.6%, GDPval-AA 1656 Elo를 기록했으며, 경쟁 프론티어 모델 대비 약 **4배 더 많은 초당 출력 토큰 (output tokens / second)**을 생성한다고 주장합니다. 아키텍처 세부 사항(파라미터 수, 컨텍스트 윈도우, 학습 레시피 등)은 공개되지 않았습니다.

잠시 이 비유를 생각해 보십시오. 회화 책을 가진 관광객은 커피를 주문할 수 있습니다. 그들은 적절한 페이지를 펼치고, 문구를 천천히 읽으며, 음절을 대략적으로 맞춥니다. 바리스타가 무언가 대답하면, 그들은 다시 책을 찾아봅니다. 예상치 못한 응답 — "사이즈는 어떻게 해드릴까요?" — 이 돌아오면 그들은 당황합니다. 목적지에 도달하기는 하겠지만, 모든 상호작용은 개별적인 조회(look-up)이며, 실패의 비용은 다시 찾아보는 수고로 이어집니다. 반면 원어민은 번역하지 않습니다. 그들은 질문을 듣고 같은 박자에 맞춰 응답하며, 예상치 못한 상황이 발생해도 흐름을 놓치지 않고 대처합니다. 이것이 도구 사용(tool-use) 하네스를 갖춘 채팅 모델과 에이전트 우선 모델 (agent-first model) 사이의 격차입니다. 채팅 모델은 래퍼(wrapper)를 통해 한 번에 한 문구씩 도구 호출(tool call)의 언어를 구사하지만, 에이전트 우선 모델은 해당 환경에서 학습했기 때문에 그 언어를 네이티브하게 구사합니다.

대중적인 프레임워크가 암시하는 이야기의 버전에서 보자면, 학습 과정에서 변하는 것은 최소한 기질(substrate)입니다. 채팅에 최적화된 베이스 모델(base model)은 수십억 개의 인간 대화 단어는 보았지만, 도구 호출 흔적(tool-call traces)은 거의 보지 못했습니다. 함수 호출(function-calling)은 일반적으로 미세 조정(fine-tuning) 단계에서 구조화된 출력(structured-output) 규율로서 학습됩니다. 이와 대조적으로, 에이전트 우선 모델은 대규모 사후 학습(post-training) 단계(경우에 따라서는 그 이전 단계)에서 호출(call), 관찰(observation), 다음 호출(next call), 오류(error), 복구(recovery), 성공(success)과 같은 도구 호출 흔적이 나타나는 것이 특징입니다. 500 응답 이후에 "다음에 무슨 일이 일어날 것인가"에 대한 모델의 사전 지식(prior)은 더 이상 "도움이 되는 챗봇이 되어라"가 아니라, "지수 백오프(backoff)와 함께 재시도하거나 다른 도구를 선택하라"가 됩니다. Google은 Gemini 3.5 Flash의 학습 레시피를 공개하지 않았으므로, 여기서의 손실 형성(loss-shaping) 논거는 인용된 아키텍처상의 주장이 아니라, 에이전트 우선 제품 포지셔닝(Antigravity, MCP Atlas 벤치마크, Frontier Safety Framework 프레임워크)에 대한 하나의 _해석_입니다.

과소평가된 부분은 반대편에 있는 하네스(harness) 아키텍처입니다. 도구 사용 채팅(chat-with-tools) 배포에는 공격적인 하네스가 필요합니다. 즉, 환각(hallucination)된 함수 이름을 거부하는 JSON 스키마 검증기(JSON-schema validators), 도구 오류를 포착하여 사용자 메시지로 재구성하는 재시도 래퍼(retry wrappers), 정체된 루프(stuck loops)에서 다시 프롬프트를 입력하는 플래너 모듈(planner module) 등이 필요합니다. 이러한 각 계층이 존재하는 이유는 모델 자체가 자신이 루프 _내부_에 있다는 것을 기본적으로 알지 못하기 때문이며, 하네스가 계속해서 이를 알려주어야 하기 때문입니다. 모델이 에이전트 우선(agent-first) 방식으로 이동함에 따라, 하네스의 질량은 모델 쪽으로 다시 이동하는 경향이 있습니다. 각 턴(turn)이 더 짧아지고 턴당 복합 오류율(compounding error rate)이 낮아지기 때문에 파서(parsers)가 줄어들고, 재시도 래퍼가 줄어들며, 관측 가능성 스팬(observability spans)이 단순해집니다. 하네스는 얇아지며, 행동을 통제하는 것이 아니라 입력과 출력을 전달하는 역할만 수행하게 됩니다.

"에이전트 우선"이 실제로 변화시키는 것 — 한 줄씩 살펴보기

턴당 절감 효과가 실제로 발생하는 지점

간단한 계산을 통한 검토 (예시 수치임; 실제 계획을 세울 때는 본인의 작업을 대입해 보세요). 어떤 작업이 완료되기 위해 4개의 별도 도구 호출(tool calls)이 필요하다고 가정해 봅시다 — 사용자 가져오기, 권한 정책 읽기, 감사 로그 쓰기, 응답 반환. 복잡한 스키마에서 턴당 도구 호출 정확도가 약 85%인 도구 사용 채팅 모델은, 복합적으로 계산했을 때 4단계 궤적을 첫 시도에 약 52%의 확률로 성공합니다 (0.85⁴ ≈ 0.52). 모든 실패는 하네스 수준의 재시도를 트리거하며, 이는 궤도에 다시 오르기 위해 24회의 추가 턴을 소모하게 합니다. 결과적으로 기대 턴 수는 대략 811회로 급증합니다.

이제 에이전트 우선 (agent-first) 버전입니다. 만약 도구 호출 (tool-call) 트레이스에 대한 사후 학습 (post-training)을 통해 턴당 정확도가 ~95%로 향상된다면, 4단계 성공률은 ~81%로 상승합니다 (0.95⁴ ≈ 0.81). 기대 턴 수는 대략 ~5회로 감소하며, 이는 작업당 턴 수가 약 2배 줄어드는 것을 의미합니다. 여기에 Google이 서빙 레이어 (serving layer)에서 보고한 초당 출력 토큰 수의 ~4배 향상을 결합하면, 엔드 투 엔드 (end-to-end) 실제 소요 시간 (wall-clock) 개선은 승수 효과를 일으킵니다. 즉, 개별적인 개선 사항은 완만할지라도 더 적은 턴 수와 더 빠른 턴 수라는 두 가지 이점이 동시에 발생합니다. 이것이 바로 Antigravity 프레임링 (framing)이 지향하는 에이전트 처리량 (agentic-throughput)의 핵심이며, 단순한 싱글샷 (single-shot) 벤치마크 승리가 아닙니다.

함정, 그리고 에이전트 우선 방식이 공짜 점심이 아닌 이유는 10회 이상의 도구 호출을 포함하는 학습 궤적 (training trajectories)을 생성하는 비용이 비싸기 때문입니다. 이러한 트레이스는 폐쇄 루프 샌드박스 (closed-loop sandbox)에서 합성되거나 배포된 하네스 (harness)로부터 수집되어야 하며, 두 경로 모두 순수 채팅 사후 학습 (chat post-training)에는 필요하지 않았던 인프라를 추가합니다. 서빙 비용 측면의 이야기 또한 취약합니다. 초당 ~4배 토큰 수라는 주장은 Google 블로그의 공개된 벤치마크 방법론과 결합되어 있지 않으며, 이를 구현하는 아키텍처 (architecture) 또한 공개되지 않았습니다. Jetson Thor의 "7.5배 연산량" 프레임링이 edge Blackwell 설명서에서 정밀도와 충돌했던 것과 마찬가지로, 이 처리량 수치는 보장된 계약이라기보다는 방향성을 제시하는 헤드라인으로 취급해야 합니다.

더 자세히 알아보기: AI 에이전트 (AI Agents) → 에이전트 루프 및 상태 (The Agent Loop & State) → 하네스 해부 (Harness anatomy)

관련 설명서

• Tool-router contextual bandit — 에이전트 우선 모델(agent-first model)을 위해 하네스(harness)가 여전히 할 수 있는 일: 모델의 계획 예산(planning budget)을 낭비하는 대신, 턴(turn)마다 실행 가능한 가장 저렴한 도구를 선택함
• Pantheon-bench — HITL vs autonomous coding — 에이전트 우선 방식의 평가(eval) 측면: 단일 턴 점수(single-turn scores)보다 궤적(trajectories)이 더 중요함
• MCP SEP-2663 — async task handles — 반대편의 모델이 실제로 루프(loop) 안에 있을 것을 기대할 때 전송(transport) 레이어가 어떤 모습인지에 대하여

FAQ

에이전트 우선(agent-first)이란 실제로 무엇을 의미하나요? (한 단락 요약)

에이전트 우선이란 사후 학습(post-training) 혼합(mixture)에 호출(call), 관찰(observation), 오류(error), 복구(recovery), 성공(success)과 같은 다중 턴 도구 호출 궤적(multi-turn tool-call trajectories)이 큰 비중을 차지하며, 손실 함수(loss)가 단일 턴 채팅이 아닌 루프(loop)에 맞춰 형성된 모델을 의미합니다. 이 모델은 단순히

프로덕션 에이전트의 지연 시간(latency), 비용, 그리고 신뢰성은 모두 턴 수(turn count)와 턴당 오류율(per-turn error rate)에 의해 결정됩니다. 도구(tools)를 단순히 덧붙인 채팅 모델은 함수 이름을 환각(hallucinate)하거나, 구조화된 출력(structured outputs)을 실수하며, 도구 오류를 재프롬프트(re-prompt)가 필요한 대화적 놀람으로 취급합니다. 이러한 각각의 실패는 턴 수를 증가시킵니다. 도구 호출 추적(tool-call traces) 데이터로 학습된 에이전트 우선(agent-first) 모델은 턴당 오류율을 낮추고, 시스템 프레임워크(harness)가 재시도(retry) 및 검증(validation) 레이어를 덜어낼 수 있게 합니다. 이 효과는 복리로 작용합니다. 궤적(trajectories)은 곱셈적으로 구성되기 때문에, 아주 미미한 턴당 정확도 향상이라도 엔드 투 엔드(end-to-end) 측면에서는 큰 승리로 이어집니다. 프레임워크는 더 단순해지고, 관측 가능성(observability)은 더 조용해지며, SLO(Service Level Objective) 예산은 더 저렴해집니다.

도구 사용을 위해 채팅 모델을 단순히 미세 조정(fine-tuning)하는 것과는 어떻게 다른가요?

도구 사용을 위해 채팅 모델을 미세 조정하는 것은 모델이 구조화된 출력을 생성하고 함수를 호출하도록 가르치지만, 기본 사전 확률(base prior)을 바꾸지는 못합니다. 미세 조정 후에도 모델은 500 응답이나 익숙하지 않은 도구 오류를 루프 내에서 재시도하거나 도구를 전환해야 하는 신호로 받아들이기보다, 채팅 어시스턴트가 사과하거나 대화하듯 반응해야 할 무언가로 여전히 취급합니다. 에이전트 우선 모델은 사전 학습 인접 혼합 데이터(pretraining-adjacent mixture) 또는 집중적인 사후 학습(post-training) 단계에 도구 호출 추적을 포함하므로, 사전 확률(prior) 자체가 루프 형태를 띠게 됩니다. 함수 이름 환각이 줄어들고, 다단계 계획 지평(multi-step planning horizons)이 확장되며, 복구 동작(recovery behaviour)이 사과하는 모습이 아닌 제어 흐름(control flow)의 모습을 갖추게 됩니다. Gemini 3.5 Flash의 아키텍처 세부 사항은 공개되지 않았습니다.

원문은 Learn AI Visually에 게시되었습니다.