Gemini 4가 드디어 공개됐습니다.

하지만 첫 모델인 Gemini 4 Argon을 단순히 "Gemini 3보다 더 똑똑한 모델"이라고 보면 핵심을 놓치기 쉽습니다.

Google이 2026년 9월 30일 발표에서 반복해서 강조한 단어는 long-horizon workflow입니다.

즉 짧은 질문 하나에 답하는 모델보다,

목표 이해
→ 자료 확인
→ 코드 수정
→ 실행
→ 실패 분석
→ 다시 수정
→ 검증
→ 다음 단계

처럼 오래 이어지는 작업을 끝까지 끌고 가는 모델에 더 가깝습니다.

그리고 이 방향을 상징하는 숫자가 1M output tokens입니다.

먼저 짚을 점: 1M Context와 1M Output은 다릅니다

긴 컨텍스트 이야기를 들을 때 보통 이런 구조를 떠올립니다.

많이 읽는다
───────────
1M Context Window

하지만 Google의 Argon 발표에서 특히 강조한 변화는 출력 토큰 상한을 기존 64K에서 1M으로 늘렸다는 점입니다.

개념적으로는 다음 차이입니다.

Context
"얼마나 많은 자료를 한 번에 읽을 수 있는가?"

Output
"한 번의 작업 궤적에서 얼마나 오래 생각하고 만들어낼 수 있는가?"

물론 출력 상한이 크다고 매번 100만 토큰을 생성해야 한다는 뜻은 아닙니다.

중요한 것은 장기 작업에서 모델이 중간에 궤적을 끊지 않고 더 많은 reasoning과 tool-use 단계를 이어갈 headroom이 생긴다는 점입니다.

Argon이 겨냥하는 작업은 일반 채팅보다 훨씬 깁니다

Google이 공개한 내부 사례를 보면 방향이 분명합니다.

대표적으로 Argon agents는 Google 내부에서 다음과 같은 작업에 사용됐습니다.

  • 데이터센터 메모리 사용량 분석과 최적화
  • C/C++ 코드베이스의 Rust 마이그레이션
  • libgav1의 Rust SIMD 코드 재작성과 성능 최적화
  • 양자 알고리즘의 리소스 최적화

특히 코드 마이그레이션은 수만 줄 규모를 넘어 Fuchsia Zircon kernel의 80만 줄 이상 범위까지 언급됩니다.

여기서 중요한 것은 "AI가 80만 줄을 한 번에 다시 썼다"는 식으로 받아들이는 것이 아닙니다.

Google도 실제 적용에는 자동화된 검증뿐 아니라 emulation test와 사람의 review가 함께 들어간다고 설명합니다.

즉 구조는 오히려 이렇게 이해하는 편이 정확합니다.

                ┌─ 분석 ──────────┐
                ├─ 코드 수정 ─────┤
큰 목표 ────────┼─ 테스트 ─────────┼→ 반복
                ├─ 성능 측정 ─────┤
                └─ 사람 검토 ─────┘

긴 trajectory + 반복 검증이 핵심입니다.

공개 벤치마크도 장기 작업 쪽에 무게가 실려 있습니다

Google이 발표한 수치는 상당히 강합니다.

DeepSWE v1.1        77.9%
AutomationBench     51.3%
LVBench             91.7%
CWE-bench v1        68%

DeepSWE는 실제 소프트웨어 엔지니어링에 가까운 장기 작업을, AutomationBench는 여러 업무 단계가 연결된 end-to-end 실행을 봅니다.

LVBench는 긴 영상 이해를 평가하고, CWE-bench는 소프트웨어 취약점 수정 능력을 측정합니다.

다만 이 숫자를 볼 때는 출처를 구분해야 합니다.

위 수치는 Google이 Argon 발표에서 공개한 vendor benchmark 결과입니다.

실제 서비스에 적용하기 전에는 내 작업과 같은 입력·tool·reasoning 설정에서 다시 확인하는 것이 좋습니다.

Artificial Analysis의 초기 독립 측정에서도 Argon High는 Intelligence Index 53을 기록했지만, 이것 역시 모델과 평가 환경이 계속 업데이트되는 시점의 측정값입니다.

그런데 지금 바로 API에서 쓸 수 있나요?

2026년 10월 1일 기준으로는 일반 개발자가 바로 선택할 수 있는 보편적인 Gemini API 모델로 풀린 상태는 아닙니다.

Google은 우선 Fairwind Program을 통해 신뢰할 수 있는 cyber defenders에게 단계적으로 제공하고 있습니다.

개발자·기업·일반 사용자에게는 guardrail과 초기 피드백을 확인하면서 접근 범위를 넓힐 예정이라고 밝혔습니다.

발표된 introductory pricing은 다음과 같습니다.

Input        $2 / 1M tokens
Output       $10 / 1M tokens
Cached input 입력 가격 대비 95% 할인

즉 "발표됨"과 "누구나 지금 API에서 사용 가능"은 구분해야 합니다.

왜 출력 토큰이 그렇게 많이 필요할까요?

짧은 챗봇에서는 필요 없습니다.

예를 들어:

"이 함수 설명해줘"
"이 이메일 다듬어줘"
"이 JSON에서 값 찾아줘"

같은 작업은 긴 output trajectory가 오히려 낭비입니다.

반대로 이런 작업은 다릅니다.

대규모 코드 마이그레이션

1. 저장소 구조 조사
2. 의존 관계 파악
3. 변경 계획 수립
4. 작은 단위로 코드 수정
5. 빌드
6. 테스트
7. 실패 원인 분석
8. 수정
9. 성능 측정
10. 다음 모듈로 이동

이때 모델이 오래 일할 수 있다는 것은 답변 길이가 길어진다는 의미가 아니라 더 긴 실행 루프를 유지할 수 있다는 의미에 가깝습니다.

도식으로 보면 Chatbot과 Long-Horizon Agent의 차이가 보입니다

일반 Chatbot

질문
 ↓
추론
 ↓
답변
 └──────── 끝


Long-Horizon Agent

목표
 ↓
계획
 ↓
도구 ─────→ 관찰
 ↑           ↓
 └── 수정 ← 검증
      ↓
   다음 작업
      ↓
   최종 결과

Argon을 이해할 때는 두 번째 그림이 더 중요합니다.

CodeBridge Mini Lab: "긴 답변"이 아니라 "긴 작업"을 측정해 보세요

Argon이 일반 공개된 뒤 비교 실험을 한다면 단순한 QA benchmark보다 이런 작은 repository task가 더 적합합니다.

예를 들어 10개 파일 정도의 샘플 프로젝트에서:

목표:
기존 sync API를 async API로 마이그레이션한다.

완료 조건:
- public API 호환 유지
- unit test 추가
- 기존 테스트 전부 통과
- 변경 이유 문서화

를 주고 다음을 기록합니다.

모델: __________
완료 여부: Y / N
총 tool calls: __
빌드 실패: __회
테스트 실패 후 복구: __회
사람 개입: __회
예상하지 않은 파일 변경: __개
총 비용: $__
총 시간: __분

한 번 길게 말하는 능력보다 실패 후 다시 정상 궤도로 돌아오는 능력이 훨씬 중요하게 보일 겁니다.

Long-Horizon Agent에서 더 중요해지는 것은 Harness입니다

trajectory가 길어질수록 작은 오류도 누적됩니다.

초기 오해
  ↓
잘못된 계획
  ↓
잘못된 코드
  ↓
잘못된 테스트 해석
  ↓
큰 수정 비용

그래서 모델이 강해질수록 역설적으로 다음 구조가 더 중요해집니다.

Context
Rules
Tools
Permissions
Tests
Checkpoints
Review

모델이 오래 일한다고 해서 무제한 자율성을 주는 것이 아니라, 오래 일해도 크게 벗어나지 않게 만드는 실행 환경이 필요합니다.

Google의 내부 사례에서도 대규모 변경에 자동·수동 검증이 함께 등장하는 이유입니다.

결론: 1M Output의 의미는 "긴 글"보다 "긴 작업"에 있습니다

Gemini 4 Argon에서 눈에 띄는 숫자는 1M output tokens입니다.

하지만 숫자 자체보다 중요한 변화는 다음입니다.

AI 모델이 한 번 답하고 끝나는 도구에서, 여러 단계의 복잡한 작업을 오래 수행하는 실행 주체로 이동하고 있다.

Argon이 일반 개발자에게 널리 풀렸을 때 가장 먼저 볼 것은 "벤치마크 1등인가?"보다 내 작업에서 얼마나 오래 안정적으로 루프를 유지하고, 실패를 복구하고, 검증까지 끝내는가입니다.

그때부터 모델 비교는 점수표가 아니라 workflow 비교가 됩니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

Long-Horizon Agent가 오래 일할수록 모델 자체보다 컨텍스트·하네스·루프·그래프·검증 구조가 중요해집니다. 프롬프트 다음 단계의 AI 에이전트 시스템을 직접 설계해보고 싶다면 아래 강의가 가장 가까운 주제입니다.