Gemini 4 Argon 출시: 100만 토큰 컨텍스트가 에이전트 설계를 바꾸는 방식

모델이 커질수록 모든 문제가 해결된다는 기대는 오래가지 못합니다. 실제 서비스에서는 모델의 최대 점수보다 긴 입력을 어떻게 분할하고, 사고 토큰과 출력 토큰을 어떻게 예산화하며, 실패한 도구 호출을 어떻게 검증하는가가 더 중요합니다.

Google은 2026년 10월 13일 Gemini 4 Argon을 개발자와 기업에 공개했습니다. Google Cloud 발표는 Argon을 코딩, 금융·법률 지식 작업, 사이버보안처럼 여러 단계의 추론이 필요한 업무용 프런티어 모델로 소개했고, Reuters도 같은 날 전 세계 개발자와 기업 대상 출시와 API 가격을 확인했습니다. 기존 글에서 다룬 데이터 에이전트나 GKE 격리 런타임과 달리 이번 변화의 중심은 모델 자체의 긴 작업 메모리와 실행 제어입니다.

이 글은 Google Cloud 발표, Gemini API 기술 문서, Google DeepMind 모델 카드·안전 보고, Vals AI의 독립 벤치마크, Reuters 보도를 교차 확인해 작성했습니다. 모델 ID, 가격, 지원 기능과 안전 평가는 빠르게 바뀔 수 있으므로 실제 배포 전 원문을 다시 확인해야 합니다.

1. 10월 13일 공개가 의미하는 것

Argon은 단순히 Gemini의 새 이름이 아닙니다. 개발자는 gemini-4-argon이라는 모델 ID로 Gemini API와 Google AI Studio에서 호출할 수 있고, Google Cloud의 Gemini 플랫폼과 관리형 에이전트에서도 사용할 수 있습니다. Google AI Ultra 구독자는 Antigravity에서 사용할 수 있지만, API 사용은 유료 계층을 전제로 합니다.

이번 공개에서 눈여겨볼 변화는 세 가지입니다.

변화	기술적으로 달라지는 점	운영자가 먼저 물어볼 질문
100만 토큰 통합 컨텍스트	입력·사고·출력이 하나의 1,048,576 토큰 창을 공유	전체 저장소나 문서를 넣어도 실제로 필요한 정보만 남아 있는가?
장시간 디코드	백그라운드 실행에서 64K 단위 continuation을 이어 최대 100만 토큰까지 생성	긴 답변을 한 번에 받지 않고 중간 결과와 취소를 관리할 수 있는가?
사고 수준 조절	low, medium, high로 품질·지연·토큰 사용량을 조정	모든 요청을 high로 보낼 이유가 있는가?

즉 “더 큰 모델을 호출한다”보다 작업 큐, 상태 저장, 토큰 예산, 평가 파이프라인을 모델의 실행 특성에 맞게 다시 짠다는 변화입니다.

2. 100만 토큰은 무료 메모리가 아니다

Gemini API 문서가 말하는 1M 컨텍스트는 입력만 100만 토큰이라는 뜻이 아닙니다. 입력, 모델의 thinking 토큰, 최종 출력이 합쳐져 1,048,576 토큰을 사용합니다. 입력 문서가 700K 토큰이면 사고와 출력에 남는 여유는 그만큼 줄어듭니다.

또한 긴 출력은 일반 동기 요청으로 무한히 기다리는 방식이 아닙니다. 문서는 65,536 토큰을 넘는 max_output_tokens를 요청할 때 background: true로 백그라운드 실행을 사용하도록 안내합니다. 서버가 최대 64K 단위의 continuation을 반복하고, 애플리케이션은 각 model_output 단계를 이어 붙여 최종 결과를 구성합니다.

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-4-argon",
    input="대규모 Java 저장소의 모듈 의존성을 분석하고 단계별 마이그레이션 계획을 작성하라.",
    background=True,
    generation_config={
        "thinking_level": "medium",
        "max_output_tokens": 131072,
    },
)

# 실제 서비스에서는 상태 조회, 재시도, 취소, 예산 초과 처리를 함께 구현한다.
while interaction.status in ("queued", "in_progress"):
    interaction = client.interactions.get(id=interaction.id)

result = "".join(
    content.text
    for step in interaction.steps
    if step.type == "model_output"
    for content in step.content
    if content.type == "text"
)
print(result)

이 구조에는 새로운 실패 지점이 생깁니다.

백그라운드 작업이 오래 걸리는 동안 사용자가 취소할 수 있는가?
continuation 중 네트워크가 끊겼을 때 같은 단계를 중복 청구하지 않는가?
최종 텍스트만 저장하지 않고 단계별 도구 호출과 근거를 감사 로그에 남기는가?
모델이 스스로 만든 계획을 다음 단계의 입력으로 다시 사용할 때 권한을 재검사하는가?

1M 창을 “한 번에 모든 데이터를 넣는 공간”으로 사용하면 비용과 지연이 먼저 커집니다. 검색·요약·계층형 메모리를 먼저 적용하고, 정말 긴 계약서나 저장소 그래프처럼 경계를 넘나드는 작업에만 긴 컨텍스트를 쓰는 편이 안전합니다.

3. 사고 수준과 가격을 함께 설계하기

Argon의 기본 사고 수준은 medium입니다. low는 토큰과 지연을 줄이고, high는 어려운 코드·수학·과학 문제의 품질을 높이는 대신 첫 토큰까지 더 오래 걸리고 출력 비용이 커질 수 있습니다. Google 문서도 세 수준을 모두 평가한 뒤 품질 기준을 만족하는 가장 낮은 수준을 선택하라고 권합니다.

API 문서의 공개 가격은 2026년 11월 30일까지 입력 1M 토큰당 2달러, 출력과 thinking 토큰 1M당 10달러입니다. 12월 1일부터는 각각 4달러와 20달러로 바뀝니다. 4,096토큰 이상 프롬프트에는 암묵적 캐시가 적용될 수 있고, 캐시 적중 입력은 프로모션 기간 1M 토큰당 0.10달러로 할인됩니다. 캐시 적중은 보장되는 기능이 아니므로 예산 계산에서는 보수적으로 잡아야 합니다.

예를 들어 입력 100K, 출력과 thinking 합계 20K인 한 요청은 프로모션 가격에서 대략 다음과 같습니다.

항목	계산	비용
입력	0.1M × 2달러	0.20달러
출력·thinking	0.02M × 10달러	0.20달러
합계	캐시 미적중 기준	0.40달러

같은 호출을 하루 5,000회 보내면 월 30일 기준 약 6만 달러가 됩니다. 실제 비용은 캐시 적중률, 재시도, 도구 호출, 긴 출력의 continuation에 따라 더 커질 수 있습니다. 따라서 모델 선택은 “요청당 가격”이 아니라 작업 하나를 끝내는 데 필요한 총 토큰과 재시도 횟수로 비교해야 합니다.

운영 정책은 다음처럼 나누는 것이 현실적입니다.

간단한 분류·추출은 낮은 사고 수준 또는 경량 모델로 라우팅합니다.
계획 수립은 medium으로 실행하되, 승인 후에만 실제 도구를 호출합니다.
긴 코드 변환·과학 분석처럼 실패 비용이 큰 작업만 high와 백그라운드 실행을 허용합니다.
조직·프로젝트·사용자별 토큰 예산과 중단 기준을 둡니다.
캐시 적중률, 평균 continuation 수, 성공한 작업당 비용을 대시보드로 분리합니다.

4. 기존 Gemini 앱을 옮길 때 생기는 호환성 문제

모델 ID만 바꾸면 끝난다는 식의 마이그레이션은 위험합니다. Gemini API의 Argon 안내에는 다음 변경점이 명시돼 있습니다.

gemini-4-argon으로 모델 문자열을 변경합니다.
명시적으로 max_output_tokens를 설정했다면 최소 32,768 이상을 검토합니다. Argon은 이전 모델보다 thinking에 더 많은 토큰을 쓸 수 있습니다.
low, medium, high 세 사고 수준을 실제 업무 평가로 비교합니다.
cachedContents와 caches.create를 사용하는 명시적 컨텍스트 캐시는 지원되지 않습니다. 대신 4,096토큰 이상 프롬프트의 암묵적 캐시 동작을 측정합니다.
temperature, top_p, top_k는 무시될 수 있으므로 이 값에 의존한 품질 조정 코드를 제거합니다.
64K를 넘는 출력은 백그라운드 실행과 긴 HTTP 클라이언트 타임아웃을 사용합니다.
다중 턴과 함수 호출은 previous_interaction_id로 서버 상태를 연결하고, 상태 ID를 개인정보처럼 보호합니다.

특히 샘플링 파라미터가 무시된다는 점은 회귀 테스트에서 놓치기 쉽습니다. 이전 모델에서 temperature=0에 기대어 안정적인 출력을 얻었다면, Argon에서는 사고 수준·프롬프트·후처리 검증을 다시 설계해야 합니다.

5. 벤치마크는 “용도별 승자”를 보여준다

Google DeepMind 모델 카드는 Argon의 강점을 여러 영역에 걸쳐 보고합니다. 예를 들어 256K~1M 범위의 GraphWalks 장문맥 평가는 84.2%, DeepSWE v1.1은 77.9%, Vibe Code Bench는 91.9%로 제시됐습니다. 그러나 같은 표에서 FrontierSWE v2는 55.0%로 GPT-6 Astra 65.5%보다 낮고, Terminal-Bench 4.0도 57.4%로 Claude Opus 5.5 66.4%보다 낮습니다.

독립 벤치마크 기관 Vals AI의 10월 13일 지표도 비슷한 그림을 보여줍니다. Vals Index에서 Argon은 68.90%로 1위였지만, Vibe Code Bench는 Claude Sonnet 5.5가 1위였고, Terminal-Bench 4.0은 Claude Opus 5.5가 1위였습니다. Argon의 Vals Index 테스트 비용은 15.68달러였고, 장시간 CUA·코드 마이그레이션 작업에서는 테스트당 비용이 30~193달러까지 올라갔습니다.

이 결과에서 읽어야 할 것은 “Argon이 모든 모델을 이겼다”가 아닙니다.

Vals Index는 금융·코딩·법률·세무 업무를 미국 GDP 비중으로 가중한 하나의 지표입니다.
모델 카드 수치는 Google이 선정한 평가와 설정을 사용한 공급자 보고입니다.
실제 서비스는 데이터 품질, 도구 오류, 승인 지연, 재시도 정책까지 포함한 시스템 평가입니다.
같은 모델도 low, medium, high에 따라 비용과 정확도가 달라집니다.

따라서 도입 전에는 조직의 대표 작업 50~100개를 고정하고, 정확성·근거 충실도·도구 성공률·지연·작업당 비용을 함께 비교해야 합니다. 단일 리더보드 순위를 제품 선택의 근거로 사용하면 안 됩니다.

6. 안전성 주장은 방어 심층화의 출발점이다

Google은 Argon의 안전 글에서 Gray Swan의 Indirect Prompt Injection 벤치마크를 언급하며 15번의 적응형 공격에서 공격 성공률을 0.7%로 낮췄다고 설명합니다. 이는 브라우저나 코드 저장소에 숨은 지시가 에이전트를 속이는 문제를 겨냥한 공급자 보고입니다.

그러나 0.7%는 0%가 아니며, 특정 테스트 설정의 결과입니다. DeepMind 모델 카드도 사이버보안 CCL 도달 가능성을 배제할 수 없어 별도의 안전 사례와 완화책을 적용했다고 적습니다. 즉 “모델이 프롬프트 인젝션을 해결했다”가 아니라 모델 수준 방어가 추가됐지만 시스템 통제가 여전히 필요하다는 뜻입니다.

실제 에이전트 배포에서는 다음 방어를 겹쳐야 합니다.

웹 문서·이메일·저장소 내용은 지시가 아닌 데이터로 취급합니다.
도구 호출마다 허용된 대상·동사·범위를 정책으로 검사합니다.
파일 삭제, 결제, 배포, 권한 변경은 사람 승인 없이는 실행하지 않습니다.
검색 결과와 모델 출력의 출처를 별도로 저장하고, 중요한 답변은 원문 링크로 검증합니다.
브라우저 세션, 서비스 계정, API 키를 작업별로 분리하고 만료시킵니다.
모델이 작성한 코드와 모델이 실행한 코드를 같은 신뢰 영역에 두지 않습니다.
공격 성공률뿐 아니라 거짓 거부, 데이터 유출, 승인 우회, 로그 누락을 회귀 테스트합니다.

7. 어떤 작업에 Argon을 쓰고, 어떤 작업에는 쓰지 않을까

잘 맞는 작업

여러 모듈을 가로지르는 코드 마이그레이션과 테스트 계획 수립
긴 계약서·규정·설계 문서의 근거 기반 비교
여러 표와 파일을 연결하는 금융·운영 분석
장시간 실행되는 연구 조사와 문헌 정리
도구 호출을 포함한 에이전트 평가와 복잡한 디버깅

다른 모델이나 고정 파이프라인이 나은 작업

정해진 형식의 대량 분류·추출
수 밀리초 지연이 중요한 자동완성
짧은 고객 문의 응답
이미지 생성이나 실시간 양방향 오디오처럼 Argon 지원표에 없는 기능
모델보다 데이터베이스 쿼리나 결정론적 규칙이 더 정확한 작업

좋은 구조는 Argon을 기본값으로 두는 것이 아니라, 작업의 시간 범위·실패 비용·근거 요구·도구 권한으로 라우팅하는 것입니다. 예를 들어 고객 문의는 경량 모델, 내부 보고서 초안은 medium, 배포 전 코드 변환은 high와 승인 게이트를 쓰는 식입니다.

8. 교육과 실무에서 재현할 수 있는 평가 실습

학생이나 개발자가 “1M 컨텍스트가 좋다”는 문구만 기억하지 않도록, 같은 자료로 모델의 경계를 측정해 볼 수 있습니다.

10K, 100K, 500K 토큰으로 구성한 동일한 문서 묶음을 준비합니다.
문서 안의 서로 다른 위치에 근거를 배치하고, 답변에 인용 위치를 요구합니다.
low, medium, high를 각각 실행해 정확도·첫 토큰 지연·총 토큰을 기록합니다.
64K를 넘는 출력 작업을 백그라운드 실행으로 보내고 continuation 누락을 검사합니다.
웹 문서 속 가짜 지시와 정상 업무 지시를 함께 넣어 prompt injection 방어를 시험합니다.
동일한 요청을 일반 모델과 Argon에 보내 작업당 비용과 사람 수정 시간을 비교합니다.
모델이 추천한 파일 변경을 실제 저장소에 자동 반영하지 않고, diff 검토 후 승인하도록 구성합니다.

이 실습의 목표는 가장 높은 점수를 찾는 것이 아닙니다. 어떤 작업에서 긴 컨텍스트와 높은 사고 수준이 비용을 정당화하는지, 언제 검색·규칙·사람 검토가 더 좋은지를 설명하는 것입니다.

9. 도입 전 체크리스트

모델 ID와 SDK 버전이 문서의 최신 값과 맞는가?
1M 컨텍스트를 쓰더라도 입력을 검색·요약하는 경로가 있는가?
사고 토큰을 포함한 총 비용과 재시도 비용을 계산했는가?
백그라운드 실행의 상태 조회·취소·타임아웃·중복 방지를 구현했는가?
temperature, 명시적 캐시 등 기존 설정이 무시되거나 지원되지 않는지 확인했는가?
모델 카드와 독립 벤치마크의 평가 조건을 구분했는가?
내부 데이터의 보존, 학습 사용, 리전, 접근 로그 정책을 확인했는가?
프롬프트 인젝션과 도구 권한을 모델 안전성만으로 해결하려 하지 않는가?
low·medium·high별 품질·지연·비용을 자체 데이터로 측정했는가?
긴 출력이 정말 필요한지, 구조화된 결과와 단계별 승인으로 줄일 수 있는지 검토했는가?

결론

Gemini 4 Argon의 핵심 변화는 “더 똑똑한 챗봇”이 아니라 긴 작업을 실행하는 모델의 운영 단위가 커졌다는 점입니다. 통합 100만 토큰 창과 장시간 디코드는 코드 마이그레이션·문서 분석·연구 에이전트의 설계를 단순화할 수 있지만, 그만큼 컨텍스트 오염·지연·비용·감사 추적의 범위도 넓힙니다.

가장 현실적인 도입 순서는 다음과 같습니다.

대표 업무를 고정하고 Argon의 low·medium·high를 같은 조건에서 평가합니다.
긴 입력을 그대로 넣기 전에 검색·요약·권한 필터를 적용합니다.
64K 초과 작업은 백그라운드 실행과 작업 큐로 감싸고, 총 토큰 예산을 강제합니다.
모델 카드·Vals AI·자체 업무 지표를 함께 보며 용도별 모델을 선택합니다.
프롬프트 인젝션, 도구 권한, 사람 승인, 감사 로그를 방어 심층화로 묶습니다.

프런티어 모델의 가치는 리더보드 1위가 아니라 우리의 데이터·도구·승인 경계 안에서 한 작업을 재현 가능하게 끝내는가로 판단해야 합니다.