Gemini 4 Argon 심층 분석: 장기 코딩·이용 경로·비용의 실제 조건

공개 확대에서 먼저 달라진 것

Gemini 4 Argon의 발표와 공개 확대는 두 단계로 나뉜다. 9월 30일 발표는 Fairwind 프로그램의 제한된 제공을 알렸다. 10월 13일 발표는 개발자·기업·일반 구독자로 접근을 넓혔다. Google Cloud의 현재 모델 문서에도 공개 모델 gemini-4-argon이 GA, 출시일 10월 13일로 표시된다.

독자의 선택을 바꾸는 지점은 복잡한 작업에 특화된 모델을 자기 자료와 저장소에 적용해 볼 경로가 열렸다는 것이다. 다만 모델 접근권, 코드를 실행하는 도구, 구독에 포함된 사용량은 같은 항목이 아니다. 2026년 10월 15일 공식 문서를 기준으로 나누면 다음과 같다.

필요한 일	먼저 볼 경로	확인한 제공 조건
문서를 읽고 대화하며 결과물을 다듬기	Gemini 앱	10월 13일부터 Google AI Pro·Ultra에 전 세계 순차 제공
저장소를 읽고 수정·실행·검사를 이어 가기	Antigravity 데스크톱·CLI	개인은 Google AI Ultra, 기업은 해당되는 Gemini Enterprise 구독
사내 서비스의 요청·도구·예산을 직접 제어하기	Gemini API·AI Studio / Cloud 경로	공개 모델 ID 확인. API 과금·접근 조건을 별도로 확인

출처: 앱 릴리스 노트, Antigravity 발표, Developer API 가격표. 앱의 Pro 제공을 Antigravity의 Argon 제공이나 API 무료 사용으로 옮겨 읽으면 안 된다. Developer API 가격표에는 Argon의 무료 티어가 없다.

여기서 ‘전 세계 순차 제공’은 각 한국 계정에서 직접 접속을 확인했다는 뜻이 아니다. 국가·계정·조직 설정과 사용 한도는 실제 이용 화면에서 확인해야 한다. 방어용 별도 모델 gemini-4-argon-cyber-permissive도 일반 Argon과 구분해야 한다. 모델 문서는 이 버전을 별도 허용 목록으로 제한한다.

이 글에서는 공식 문서와 공개 코드만 분석했다. 유료 모델 호출, Antigravity 조작, 응답 품질·생산성 비교는 수행하지 않았다. 아래의 성능 수치는 Google의 보고이며, 계산 예시는 실제 사용 청구서가 아니다.

장기 코딩 능력은 어떤 구조에서 결과가 되는가

파일 하나를 고치는 일과 프레임워크 전체의 병목을 줄이는 일은 다르다. 후자는 느린 지점을 찾은 뒤 그 함수를 부르는 곳, 다른 모듈의 전제, 테스트에서 바꿔 끼우는 대상을 함께 따라가야 한다. 작은 변경이 다른 호출자의 동작을 바꾸면 빨라진 코드도 채택할 수 없다.

이때 역할을 세 층으로 나누면 Argon의 기여를 이해하기 쉽다. 모델은 다음 가설과 변경을 만들고, 실행 도구는 파일·명령·검사 결과를 연결하며, 저장소의 규칙은 무엇을 유지해야 하는지 정한다. 이는 제품의 내부 신경망 구조에 대한 설명이 아니라 공개 사례를 읽기 위한 분석 틀이다.

Google의 ADK 작업 기록은 그 차이를 보여준다. 처음에는 별도 저장소 지침 없이 병목을 찾았지만 호환성과 검토 관행을 놓쳤다. 다음 실행에서는 .agents/skills에 유지보수 지침을 제공하고 Antigravity의 /goal로 목표를 이어 가게 했다. 11시간 작업에서 나온 최적화 제안 여섯 가지 중 두 가지가 채택됐다. 두 실행은 지침과 실행 방식이 함께 바뀌었으므로 성과를 어느 한 설정의 효과로 분리할 수는 없다.

이 사례를 내 프로젝트로 옮길 때 중요한 질문은 “얼마나 오래 혼자 두나”보다 “다음 행동을 고를 때 어떤 결과와 금지 조건을 계속 보게 하나”다. 테스트가 초록색이어도 공개 API, 직렬화 형식, 호출 순서가 달라지면 실패일 수 있다. 아래 커밋에서 실제로 달라진 비용부터 살펴보자.

ADK 공개 커밋에서 확인되는 두 가지 변화

분석 대상은 google/adk-python의 1754b3e 커밋이다. 최신 브랜치의 동작을 추정하지 않고 이 시점의 변경을 읽었다.

필요한 이벤트를 고른 뒤 복사한다

세션에는 대화와 도구 실행 이벤트가 쌓인다. 호출자가 최근 이벤트 일부만 원해도 전체 세션부터 깊은 복사하면 버릴 데이터까지 복사 비용을 낸다. 변경된 _get_session_impl은 최근 개수·시각 조건으로 이벤트를 고른 다음 복사한다. 세션 목록 조회에서는 이벤트가 없는 형태를 복사한다.

여기서 줄이는 것은 반환하지 않을 데이터의 복사다. 모델에 필요한 과거를 임의로 지워 빠르게 만드는 정책과는 다르다. 예를 들어 10,000개의 저장 이벤트 중 100개만 요청한 상황이라면 두 방식 모두 같은 100개를 돌려주면서 복사할 이벤트의 수를 줄일 수 있다. 이는 구조를 설명하기 위한 가상 개수이며 100배 속도 향상이라는 뜻이 아니다. 상태 병합·이벤트 크기·필터 비용도 남는다. 전체 이벤트를 요청한다면 이 선택 단계에서 절약할 부분은 줄어든다.

또한 _model_copy.py는 이미 복사한 객체를 기록하는 memo를 사용한다. 복사본 안에서 공유하던 객체의 관계와 순환 참조를 다루기 위해서다. 단순히 깊은 복사를 얕은 복사로 바꿔도 된다는 사례가 아니다. 소스의 처리 경로를 확인했으며 이 복사기를 설치해 재시험하지는 않았다.

모듈을 읽는 비용의 시점을 옮긴다

telemetry/__init__.py에는 속성 접근 때 하위 모듈을 가져오는 __getattr__ 경로가 있다. 당장 쓰지 않는 모듈을 패키지 import 단계에서 모두 읽지 않게 하는 방식이다.

이 방식은 명령 도움말이나 테스트 수집처럼 패키지를 불러오기만 하는 작업에 유리할 수 있다. 반면 바로 그 기능을 실행하는 요청은 뒤로 미룬 로딩 비용을 다시 낸다. 따라서 import만 재면 사용자 첫 작업도 빨라졌다고 착각하기 쉽다. 커밋의 측정값이 이 차이를 보여준다.

Google이 보고한 측정 구간	변경 전 → 후	이 값으로 말할 수 있는 범위
내부 150턴 뒤 첫 모델 요청 준비	200ms → 122ms	긴 세션의 특정 준비 구간 감소
158턴 전체 실행	65.6초 → 56.1초	해당 가짜 모델·도구 환경의 프레임워크 전체 비용 감소
새 프로세스의 ADK import	1.22초 → 0.97초	패키지 로딩 자체 감소
새 프로세스에서 첫 모델 요청까지	3.07초 → 3.09초	이 측정에서는 개선되지 않음

커밋의 벤치마크 설명은 즉시 반환하는 모델·도구로 ADK 비용만 측정했고, 6~12회 실행의 중앙값이라고 밝힌다. 첫 행의 준비 구간은 가비지 컬렉션을 끈 조건이다. 158턴 전체 감소율은 (65.6−56.1)/65.6 ≈ 14.5%다. 이를 “AI 업무가 40% 빨라졌다”로 바꿀 수 없다.

여기서 턴은 사람이 메시지를 보낸 횟수와도 다르다. 공식 해설의 턴은 도구 호출 같은 내부 단계다. 같은 글은 외부 DB·SQLite·Firestore·Redis 등의 세션 저장소에는 이 메모리 복사 개선이 적용되지 않는다고 설명한다. 내 서비스가 느린 이유가 DB 조회나 모델 응답이라면 먼저 요청 지연을 구간별로 나누는 방법으로 병목부터 확인할 수 있다.

채택하지 않은 네 가지에서 배울 도입 조건

공식 ADK 기록에서 기각된 변경은 오래된 데이터를 돌려줄 수 있는 캐시, 외부 라이브러리의 비공개 속성 의존, 실제 전체 지연을 줄이지 못한 경로 재작성, 합성 시험에서만 이득이 있는 추가 상태 관리였다. 또 공개 테스트가 통과한 import 변경이 Google 내부 테스트의 속성 패치를 깨뜨린 사례도 있었다. 공식 검토 기록

이 사실은 에이전트가 찾아낸 변경의 수를 성과로 세기 어렵다는 뜻이다. 탐색에서는 여러 가설을 넓게 시도할 수 있지만, 최종 코드에는 유지 비용을 감수할 이득만 남겨야 한다. 가령 보고서 생성 배치의 시작 시간을 줄이는 팀이라면 다음처럼 판단을 바꿀 수 있다. 아래는 이 글에서 설계한 가상 업무 사례다.

제안된 변경	함께 볼 증거	채택 판단
import를 뒤로 미뤄 시작 표시를 앞당김	첫 보고서가 완성될 때까지의 시간	표시만 빨라지고 완성 시간은 같다면 요구사항에 따라 보류
최근 처리 결과를 캐시함	원본 수정 후 다음 실행의 결과·캐시 무효화 조건	오래된 보고서가 나올 수 있으면 성능과 별개로 기각
쓰지 않을 레코드를 먼저 제외함	제외 전후 동일한 최종 결과·경계 날짜 사례	필요한 결과가 같고 대표 작업도 빨라졌을 때 채택 후보

첫 실험을 “전체 프로젝트를 최적화해 줘”로 시작할 필요는 없다. 가장 시간을 많이 쓰는 실제 작업 하나를 고르고, 변경하지 않을 동작과 남겨야 할 증거를 먼저 적을 수 있다.

과제: 월별 보고서 배치에서 첫 결과와 전체 완료 시간을 줄인다.
유지할 것: 입력 형식, 공개 함수, 계산 결과와 정렬, 오류 처리.
비교할 입력: 짧은 작업 / 긴 이력 / 데이터 수정 직후의 재실행.
먼저 남길 것: 기준 커밋, 환경, 변경 전 구간별 시간과 결과.
허용할 산출물: 작은 변경 묶음, 같은 입력의 전후 결과, 실패 사례.
멈출 조건: 결과 차이의 원인을 설명하지 못하거나 예산을 소진함.
인계: 채택·기각 후보와 이유를 구분한 미병합 PR. 자동 병합 금지.

이것은 Argon에서 실행한 프롬프트가 아니라 독자가 자기 프로젝트에 맞춰 수정할 과제 양식이다. “결과가 같음”도 파일 해시 하나로 끝나지 않을 수 있다. 생성 시각처럼 달라도 되는 필드와 금액·정렬처럼 같아야 하는 필드를 먼저 나누면 불필요한 재시도와 잘못된 통과를 함께 줄일 수 있다.

100만 토큰을 읽고 100만 토큰을 따로 쓰는가

개발 문서에서 특히 주의할 부분은 토큰 예산이다. Enterprise 개발 가이드는 1,048,576토큰을 입력과 출력의 통합 한도로 정의한다. 출력에는 생각하는 토큰, 함수 호출, 최종 응답이 포함된다. 모델 표의 문맥과 최대 출력 숫자를 각각 독립된 통장처럼 합치면 안 된다.

가령 총 입력이 900,000토큰이라면 남은 출력 공간의 이론상 상한은 148,576토큰이다. 입력을 400,000으로 줄이면 648,576이 남는다. 이 값은 단순 뺄셈이며 실제 생성 길이나 품질의 예측이 아니다. 출력 설정과 요청별 제한도 적용된다. 필요한 근거를 빠뜨리면서 입력만 줄이면 판단은 오히려 나빠질 수 있다.

같은 가이드는 한 요청의 기본 출력 한도를 스트리밍 65,536, 비스트리밍 직접 HTTP 요청 32,768토큰으로 구분한다. 더 긴 한 응답은 long decode의 이어받기 경로가 필요하다. 현재 이 경로는 GenerateContent의 v1beta1 조건 등이 있으므로 기존 클라이언트에서 모델 ID만 바꿔 쓸 수 있다고 가정해서는 안 된다. 짧은 도구 호출을 여러 번 이어 가는 장기 에이전트와 한 응답을 길게 생성하는 long decode는 다른 축이다.

옮기기 전에는 thinking_budget·MINIMAL이 오류를 내고, temperature·top_p·top_k의 사용자 지정값은 무시된다는 점도 점검해야 한다. 이 내용은 문서 확인이며 실제 오류 응답을 재현한 결과가 아니다. 통합 과정에서는 개발 가이드의 최신 조건을 다시 확인하자. 긴 입력에 무엇을 남길지 정하는 문제는 긴 문맥과 RAG의 역할로 이어진다.

소개 가격으로 장기 작업 예산을 계산할 때

2026년 10월 15일 확인한 Developer API의 Standard 가격표는 다음과 같다. 단위는 미화 달러/100만 토큰이다. 앱이나 Antigravity 구독 가격을 계산하는 표가 아니다.

항목	2026-11-30까지	2026-12-01부터 공지된 가격
일반 입력	$2.00	$4.00
캐시 입력	$0.10	$0.20
출력·생각하는 토큰	$10.00	$20.00

가상의 작업 묶음에서 캐시를 쓰지 않은 청구 입력 합계 1,000,000토큰, 출력·추론 합계 200,000토큰을 사용했다고 가정하자. 여러 호출의 합계이며 단일 문맥 한도와 비교하는 값이 아니다. Standard 소개 가격으로는 1×2 + 0.2×10 = $4, 공지된 이후 단가로는 $8이다. 입력 중 800,000토큰이 실제 캐시 과금으로 잡혔다면 소개 가격은 0.2×2 + 0.8×0.1 + 0.2×10 = $2.48이 된다.

캐시 적중은 이 계산의 가정이다. 같은 문서를 다시 보냈다는 이유만으로 할인받았다고 쓰면 안 된다. 이어받기 요청에서 앞선 출력이 입력으로 다시 처리될 수 있으므로 문서 길이와 최종 답변 길이만으로 청구량을 추정하는 것도 부족하다. 실제 사용 메타데이터에 맞춰 계산해야 한다.

Cloud 이용자는 별도 가격표도 봐야 한다. 표에는 non-global 단가가 따로 있고, 소개 혜택을 일정 기간 순지출의 50% 크레딧 환급으로 제공한다는 각주가 있다. 그래서 위의 Developer API 가상 금액을 기업 Cloud 청구서의 결제 금액으로 옮기지 않았다. 도구·검색·실행 인프라·사람 검토 비용도 계산에서 제외했다.

장기 작업에서 실패한 시도도 비용을 쓴다. 반복 실행 예산과 채택 조건을 같이 정하고, 최종 완료에 드는 사람 시간까지 비교하려면 에이전트 완료 비용 평가를 함께 볼 수 있다.

어떤 업무부터 선택할까

공개 근거를 바탕으로 한 판단은 다음과 같다. 기존 코드와 테스트가 있고, 여러 파일을 따라가야 하며, 몇 차례 가설을 버리는 비용보다 탐색을 줄이는 가치가 큰 과제가 Argon 도입을 검토할 좋은 출발점이다. ADK 사례에서 가져올 것은 보고된 개선율보다 기준 작업·호환성 조건·작은 변경·기각 이유를 함께 남기는 방식이다.

대화로 자료를 정리하는 것이 목적이면 앱 경로부터, 로컬 저장소의 수정·검사까지 맡겨야 하면 Antigravity부터 검토할 수 있다. 자체 제품에 붙일 경우에는 API의 토큰·설정·청구 조건을 먼저 확인한다. 짧은 요청의 지연이 중요한 서비스나 모델 밖의 병목이 지배하는 작업이라면 별도 대조 없이 Argon으로 전환할 이유는 약하다.

첫 작업을 마친 뒤에는 “오래 실행됐다”보다 채택된 변경, 그대로 유지된 결과, 버린 제안과 실제 비용을 한 묶음으로 보자. 이 글을 저장해 과제 양식과 가격 적용일을 다시 확인하거나, AI 시스템 주제 모음에서 문맥·검증의 후속 글을 읽을 수 있다. 새 분석을 이어서 보려면 RSS를 이용할 수 있다.