Gemini 4 Argon이 2026년 10월 13일부터 정식 출시(GA)되면서, Google의 출력 한도가 기존 64K 토큰에서 약 1M 토큰으로 대폭 늘어났습니다. 이제 모델이 "단 한 번의 연속적인 궤적(single trajectory) 안에서 수십만 토큰을 생성"할 수 있게 된 것입니다. 세부 방식은 Google 개발자 가이드에 자세히 설명되어 있습니다. 기본 설정 상태의 일반적인 요청은 여전히 65,536 출력 토큰에서 멈춥니다. 하지만 Interactions API에서 background: true 옵션과 함께 max_output_tokens를 더 높게 설정하면, 서버는 입력값을 제외한 최대 1,048,576 토큰 한도에 도달할 때까지 최대 64K 토큰 단위로 생성을 이어갑니다. Google은 난도가 높은 프롬프트의 경우 완료까지 수 분이 걸릴 수 있다고 안내합니다.
하지만 이번 출시 발표글에서 가장 눈여겨보아야 할 대목은 출력 토큰 한도 자체가 아닙니다. 바로 Google이 그 엄청난 출력량을 '어디에 활용했는가'입니다. Google은 re2, libgav1 같은 핵심 라이브러리의 수만 줄에 달하는 코드부터 Fuchsia Zircon 커널의 80만 줄 이상의 코드에 이르기까지, C/C++ 코드를 Rust로 이전하는 사내 마이그레이션 작업에 Argon을 실제로 투입했다고 밝혔습니다. 그러면서 이 재작성 작업들이 "프로덕션 배포에 앞서 철저한 자동화 및 수동 감사, 에뮬레이션 테스트, 코드 리뷰를 거치고 있다"고 덧붙였습니다. 모델을 직접 개발하고 훈련한 연구소조차도 실제 제품으로 내보내기 전에 철저한 리뷰를 거칩니다. 이제 에이전트로부터 16배나 늘어난 결과물을 받아볼 수 있게 된 팀이라면, 새 모델을 도입하기 전에 리뷰 계획부터 먼저 수립해야 합니다.
TL;DR
100만 토큰에 달하는 출력 한도는 병목 현상의 위치를 '코드 생성'에서 '코드 승인'으로 옮겨놓았습니다. 단 한 번의 실행으로 이처럼 방대한 결과를 받아볼 수 있게 된 지금, 작업은 한 사람이 한 자리에서 검토할 수 있는 크기의 태스크(Task) 단위로 쪼개야 합니다. 각 태스크마다 서면으로 완료 조건(Definition of Done)과 타임아웃을 명시하고, 실행마다 확실한 검증 근거를 요구하며, 팀의 리뷰 용량을 먼저 계산해 두어야 합니다. 에이전트는 조사, 실행, 테스트, 보고를 담당하고, 사람은 방향을 잡고 권한을 부여하며 결과를 승인하는 역할을 맡아야 합니다.
단일 실행으로 이만한 결과를 낼 수 있을 때 무엇이 달라지는가
리뷰 용량(Review capacity)이란 팀이 하루 동안 읽고, 평가하고, 승인할 수 있는 에이전트 작업 완료 결과물의 수를 의미하며, 이는 모델이 아니라 오직 사람이 결정합니다. 출력 한도가 늘어났다고 해서 사람의 검토 능력이 올라가는 것은 아니며, 단지 한 번에 쏟아져 들어오는 분량이 늘어날 뿐입니다.
이전의 제한된 출력 한도는 의도치 않게 작업 범위를 제어하는 역할을 해 주었습니다. 한 번에 반환되는 응답의 길이가 제한되어 있다 보니, 작업이 자연스럽게 여러 조각으로 나뉘어 반환되었고 중간중간 점검할 여유가 있었습니다. 반면 Google이 밝힌 새로운 한도의 목적은 그 반대입니다. "까다로운 문제를 한 번에(in one go) 해결할 수 있는 여유 공간"을 제공하겠다는 것입니다. 하지만 리뷰어 입장에서 '한 번에' 나온다는 것은 단 하나의 결과, 단 한 번의 결정, 그리고 "방향이 틀렸다"고 중간에 개입해 바로잡을 체크포인트가 전혀 없음을 의미합니다.
또한 이 한도는 입출력 공유 창입니다. Argon의 1,048,576 토큰 윈도우는 입력, 생각(Thinking), 출력을 모두 합산한 수치입니다. 따라서 30만 토큰 분량의 코드를 읽어 들이는 작업이라면 사고와 작성에 쓸 수 있는 토큰은 약 74만 8천 토큰이 남습니다. 이 역시 사람이 한 자리에서 한 줄 한 줄 꼼꼼히 읽기에는 여전히 벅찬 분량입니다.
여기에 품질 문제도 따릅니다. 발표 당시 블룸버그는 익명의 Google 직원들을 인용해 Argon이 벤치마크에 비해 일부 코딩 및 프론트엔드 작업에서 기대에 미치지 못한다고 보도했고, Google은 사실무근이라 반박했습니다. 하지만 Google이 자체 공개한 표에서도 Argon은 4개의 에이전트 코딩 항목 중 2개에서 뒤처지는 것으로 나타났습니다(자사 비교 분석 글에서 자세히 다루고 있습니다). 벤치마크는 특정 테스트 세트에 대한 주장일 뿐입니다. 여러분의 코드베이스에 적용되는 diff는 여러분의 시스템에 대한 주장이며, 어떤 모델이 작성했든 명확한 근거를 바탕으로 승인되어야 합니다.
토큰 예산이 아닌 태스크(Task)의 범위를 정하라
여러분이 통제해야 하는 단위는 토큰 수가 아니라 태스크(Task)입니다. 모델의 한계치에 작업 크기를 맡겨버리면 모델이 뿜어낼 수 있는 가장 방대한 결과물을 마주하게 될 뿐입니다. 작업 단위를 직접 설정해야 사람이 검토하고 승인할 수 있는 크기의 결과가 나옵니다. Google의 공식 지침 역시 같은 맥락입니다. 일반적인 태스크에는 기본값인 65,536을 유지하고, 복잡한 추론이나 코딩 작업에도 최대치 대신 131,072나 262,144 토큰으로 백그라운드 모드를 사용하라고 권장합니다.
Google의 작업 사례만 보더라도 라이브러리와 커널 단위로 작업을 분할했습니다. 코드 이식(Porting) 작업도 동일하게 나누어야 합니다. 리뷰어가 한 번 앉은 자리에서 검토를 끝낼 수 있도록 모듈당 하나의 태스크를 할당하는 방식입니다. Sharkly에서는 이를 모듈별 하위 태스크를 둔 상위 태스크 형태로 구성하고, 선행되어야 하는 모듈에는 "선행/후행(blocks / is blocked by)" 연결 관계를 설정합니다. 목표, 범위, 인수 기준은 에이전트와 리뷰어 모두가 볼 수 있도록 태스크 설명란에 명시합니다:
SH-412 Port the tokenizer module to Rust
Parent: SH-400 Port the parser library to Rust
Blocked by: SH-411 Port the shared buffer types
Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work
이를 뒷받침하는 두 가지 에이전트 설정이 있습니다. 첫째, 태스크별 타임아웃은 모델 기준이 아니라 태스크 크기에 맞게 설정해야 합니다. 단일 모듈 처리에 필요한 정직하고 적절한 최대 소요 시간보다는 길게, 비용 낭비로 후회할 만큼 과도하게 긴 시간보다는 짧게 잡아야 합니다. 둘째, 최대 동시 실행 수(할당 태스크 수)를 제한하여 진행 중인 모듈 수를 통제해야 합니다. 40개의 하위 태스크가 동시에 실행되면 같은 리뷰어 한 명 앞에 40개의 결과물이 한꺼번에 쌓여 병목이 발생하기 때문입니다.
판단의 기준은 명확합니다. 컴파일러 검증과 전체 테스트 스위트를 거치는 기계적 이름 변경(rename)처럼, 자동화된 검사로 전체 결과를 완벽하게 검증할 수 있는 작업이라면 단일 실행에 전체 작업을 맡겨도 됩니다. 반면 사람의 정성적 판단이 조금이라도 개입되어야 한다면 작업을 쪼개야 하며, 언어 마이그레이션 작업의 대부분은 후자에 속합니다. 하루 근무 시간보다 오래 걸리는 실행 작업 역시 동일한 전제 조건이 필요합니다. 확실한 중단 조건, 대기 상태, 그리고 다음 날 아침 이를 넘겨받아 책임질 담당자가 지정되어 있어야 합니다.
태스크에 명확한 검증 근거(Evidence)를 남겨라
검증 근거가 없는 거대한 결과물은 리뷰 대상이 아닙니다. 그것은 단지 사람이 직접 느린 속도로 작업을 처음부터 다시 실행하는 것에 불과합니다.
libgav1 사례는 훌륭한 검증 근거가 무엇인지 잘 보여줍니다. Google에 따르면 Argon은 기존 Rust 포트에서 3만 2천 줄에 달하는 SIMD 코드를 대체했으며, 그 결과 "Rust 포트보다 2.7배 빠르면서도 완벽히 동일한 비디오 출력을 냈다"고 합니다. 이 문장의 후반부야말로 3만 2천 줄의 코드를 리뷰 가능하게 만든 핵심입니다. 기존 코드와 새 코드에 동일한 입력을 넣었을 때 동일한 출력이 나왔다는 점입니다. 이것이 바로 차분 테스트(Differential Testing)이며, 이를 통해 리뷰어는 단순 비교로는 잡아내기 힘든 unsafe 코드, 에러 처리 경로, 실제 운영 환경에서도 성능 향상이 유지되는지 여부와 같은 본질적인 검토에 온전히 집중할 수 있게 됩니다.
모든 실행 결과는 태스크에 다음 네 가지 항목을 반환해야 합니다:
| 태스크에 제시할 검증 근거 | 해당 근거가 답하는 리뷰어의 질문 |
|---|---|
| 변경 사항 요약 | 어디서, 무엇이, 왜 바뀌었는가? |
| 테스트, 타입 검사(typecheck), 빌드 출력 결과 | 기존에 신뢰하던 검증 과정을 여전히 통과하는가? |
| 검증된 내용 및 검증 방식 | 어떤 입력값에 대해 기존 동작이 그대로 유지되었는가? |
| 알려진 한계점 | 리뷰어가 직접 눈으로 확인해야 할 부분은 무엇인가? |
이는 Sharkly 자체 워크플로가 지향하는 구조이기도 합니다. 에이전트가 타입 검사, 테스트, 빌드를 수행한 뒤 변경 사항 요약, 검증 결과, 알려진 한계점을 태스크에 첨부하면, 사람이 이를 확인하고 승인하거나 수정을 요청하고 머지 및 릴리스 단계를 결정합니다. 에이전트의 최종 응답은 태스크에 저장되고 실행 로그는 Executions 탭에 기록되므로, 증거 자료가 개발자의 개인 터미널에 묻히지 않고 태스크 단위로 체계적으로 관리됩니다. 태스크 수준의 근거를 바탕으로 리뷰하는 방법에서 검토 순서를 안내하고 있으며, 인수인계 템플릿을 통해 일관된 보고서 형식을 갖출 수 있습니다.
검사를 통과했다고 해서 최종 승인된 것은 아니며, 머지되었다고 해서 작업이 끝난 것도 아닙니다. Sharkly에서는 연결된 풀 리퀘스트를 머지하더라도 태스크 상태가 자동으로 완료로 변경되지 않습니다. 자동화된 검사는 검증할 수 있는 영역까지만 확인해 줄 뿐이며, AI 리뷰 에이전트 글에서 그 한계점을 짚어드린 바 있습니다. 변경 사항이 태스크의 본래 요구사항을 온전히 충족했는지 판단하는 최종 결정권은 사람에게 있습니다.
실행 전에 리뷰 용량을 먼저 계산하라
리뷰는 큐(Queue) 구조와 같습니다. 결과물이 도착하면 사람이 이를 처리하고, 유입량이 처리량을 넘어서면 대기열이 쌓이게 됩니다. 출력 한도가 커지면 유입량만 급격히 증가합니다. 실제 프로젝트가 아닌 가상의 시나리오를 바탕으로 수치를 계산해 보겠습니다:
| 가상 시나리오 입력값 | 수치 |
|---|---|
| 마이그레이션 대상 모듈 수 | 40개 |
| diff만 볼 때 모듈당 소요되는 리뷰 시간 | 2시간 |
| 차분 검증 근거와 변경 요약이 있을 때 모듈당 소요되는 리뷰 시간 | 30분 |
| 리뷰어 한 명이 하루에 꼼꼼한 코드 리뷰에 집중할 수 있는 시간 | 3시간 |
diff만 보고 리뷰한다면 이 마이그레이션에는 총 80시간의 리뷰 시간, 즉 약 27영업일이 소요됩니다. 반면 모든 태스크에 검증 근거가 충실히 갖춰져 있다면 20시간, 약 7일이면 충분합니다. 작업을 한 번의 거대한 실행으로 처리하든 40개의 작은 실행으로 나누든, 리뷰어가 검토해야 할 작업의 총량은 동일합니다.
달라지는 것은 '의사결정의 방식'입니다. 40개의 태스크로 나누면 사용자가 조절할 수 있는 속도로 결과가 도착하며, 각 태스크마다 독립적인 판단을 내릴 수 있습니다. 반면 40개 모듈을 단 한 번의 실행으로 묶어버리면 단 한 번의 전체 판정만 내려야 하므로, 31번째 모듈에서 문제가 발생하면 나머지 39개 모듈까지 함께 묶여버립니다. 하위 태스크로 나누어 작업하면 문제가 된 모듈에 코멘트를 남겨 후속 실행을 돌리는 동안, 나머지 모듈들은 지체 없이 다음 단계로 진행할 수 있습니다.
비용 계산도 빼놓을 수 없습니다. 최대 한도로 생성하는 작업은 약 100만 출력 토큰을 사용합니다. 11월 30일까지 적용되는 100만 토큰당 $10 요율로는 약 $10, 12월 1일부터는 약 $20의 비용이 듭니다. Tier 1 프로젝트의 경우 Google의 지출 한도는 10분 단위 롤링 윈도우당 $10입니다. 즉, 최대치 실행 한 번으로 현재 요율 기준 10분 치 예산 한도를 통째로 소진하며, 12월 1일부터는 한도의 두 배에 달하게 됩니다. 따라서 이처럼 대규모 실행이 허용된 에이전트의 경우 최대 동시 실행 수를 반드시 낮게 유지해야 합니다.
큐가 넘쳐난 뒤에 수습하려 하지 말고, 대규모 실행을 시작하기 전에 수치를 먼저 계산하십시오. 리뷰 용량 계산법에서는 팀 단위의 구체적인 계산 방식을 다루며, 인간의 리뷰가 병목이다에서는 리뷰 큐를 시각화하는 상태 관리 및 게이트 설계법을 설명합니다.
첫 100만 토큰 실행 전에 점검해야 할 체크리스트
- [ ] 작업을 리뷰어가 한자리에서 검토할 수 있는 크기의 태스크로 나누고, 하위 태스크 및 “선행/후행(blocked by)” 연결 관계를 설정했는가?
- [ ] 각 태스크 설명에 완료 조건(Done)과 대상 외(Out of scope) 범위를 명확히 기재했는가?
- [ ] 태스크별 타임아웃을 모델의 출력 한도가 아닌 태스크 작업량(긴 백그라운드 요청은 수 분 소요)에 맞게 설정했는가?
- [ ] 최대 한도 실행 시의 비용이 현재 API 티어의 지출 한도 내에 들어오는가?
- [ ] 할당된 태스크에 대한 에이전트의 최대 동시 실행 수가 컴퓨터의 처리 능력이 아니라 리뷰어가 검토할 수 있는 용량에 맞춰져 있는가?
- [ ] 모든 실행 결과가 변경 요약, 검사 출력값, 검증된 내용, 알려진 한계점을 반환하도록 설정했는가?
- [ ] 기존 동작을 그대로 보존해야 하는 작업의 경우 이전 코드와의 차분 검증을 거치도록 했는가?
- [ ] 각 태스크마다 담당 리뷰어를 지정했으며, 승인이 머지 작업의 부수 효과가 아니라 리뷰어의 명시적인 상태 변경을 통해 이루어지도록 했는가?
이 모든 원칙은 이제 유료 Gemini API 키만 있으면 누구나 호출할 수 있는 Argon에만 국한되지 않습니다. "대규모 출력 생성 후 감사, 에뮬레이션 테스트, 코드 리뷰를 거쳐 프로덕션 배포"라는 Google의 문장은 앞으로의 표준 템플릿입니다. 향후 어느 연구소에서 또 한 번 비약적인 출력 확장을 선보이더라도, 관리 계획의 중심은 모델 자체가 아니라 태스크에 있어야 합니다. Sharkly는 특정 모델에 종속되지 않습니다. 에이전트 문서에 설명된 바와 같이, 에이전트는 해당 런타임의 기본 모델을 따르며 사용자 정의 인수나 도구 설정을 통해 얼마든지 변경할 수 있습니다. 운영 중인 런타임에 더 큰 규모의 모델이 추가되더라도 변경되는 것은 해당 모델 값뿐이며, 태스크, 검증 근거, 리뷰 게이트 체계는 그대로 유지됩니다. 요청부터 배포까지 맥락, 진행 상황, 차단 요인, 결과, 인간 리뷰가 투명하게 유지됩니다.
이미 여러 에이전트를 운영하고 계시다면, Sharkly를 통해 에이전트들의 작업과 결과를 한곳에서 체계적으로 관리해 보시기 바랍니다.
