3.5 Flash 가격 6배, 에이전트 모델의 새 청구서

AI 요약

• 무슨 일: Google이 gemini-3.5-flash를 I/O 2026에서 공개하고 에이전트·코딩용 Flash로 배포했습니다.
  • 공식 발표 기준 Terminal-Bench 2.1 76.2%, MCP Atlas 83.6%, GDPval-AA 1656 Elo를 내세웁니다.
• 비용 신호: 공식 표준 가격은 입력 $1.50, 출력 $9.00/100만 토큰입니다.
  • Gemini 3 Flash 대비 3배, Gemini 3.1 Flash-Lite 대비 6배라서 "Flash=저가" 공식이 흔들립니다.
• 실무 영향: 이제 모델 단가보다 에이전트 루프의 재시도, 검증, 하네스 비용을 함께 봐야 합니다.

Google이 2026년 5월 19일 I/O 2026에서 Gemini 3.5 모델 시리즈를 발표했습니다. 첫 타자는 gemini-3.5-flash입니다. 이름만 보면 익숙한 Flash 라인의 최신판처럼 보입니다. 하지만 발표문을 읽어보면 Google이 이 모델을 단순한 "빠른 응답 모델"로 팔고 있지 않다는 점이 먼저 보입니다. Google은 3.5 Flash를 "frontier intelligence with action"으로 설명하고, 복잡한 장기 에이전트 작업, 코딩, 도구 사용, 멀티스텝 워크플로를 처리하는 엔진으로 배치했습니다.

이 표현의 변화는 작지 않습니다. 지난 몇 년 동안 Flash라는 이름은 대체로 더 빠르고 더 싸며, 대량 요청에 넣기 쉬운 모델 계층을 뜻했습니다. 개발자는 Pro나 Opus류 모델을 어려운 판단에 쓰고, Flash나 mini 계열을 분류, 요약, 간단한 변환, 비용 민감한 백그라운드 작업에 넣는 식으로 모델 라우팅을 설계했습니다. 그런데 Google은 이번에 Flash를 "에이전트가 실제로 일을 끝내는 모델"로 재정의했습니다. 성능표도 일반 채팅 지표보다 Terminal-Bench, MCP Atlas, GDPval-AA 같은 에이전트·작업 지표를 전면에 세웁니다.

문제는 가격표입니다. Google의 공식 Gemini API 가격표에서 gemini-3.5-flash 표준 가격은 입력 100만 토큰당 1.50달러, 출력 100만 토큰당 9.00달러입니다. 같은 표에서 gemini-3-flash-preview는 입력 0.50달러, 출력 3.00달러입니다. gemini-3.1-flash-lite는 입력 0.25달러, 출력 1.50달러입니다. 기준을 무엇으로 잡느냐에 따라 숫자는 달라지지만, 개발자 커뮤니티가 "Flash가 비싸졌다"고 반응한 이유는 명확합니다. 3.5 Flash는 Gemini 3 Flash 대비 3배, 3.1 Flash-Lite 대비 6배의 표준 토큰 단가를 갖습니다.

이 글의 핵심은 "Google이 가격을 올렸다"가 아닙니다. 더 중요한 질문은 Google이 왜 Flash라는 이름을 유지하면서도 가격과 역할을 이렇게 바꿨느냐입니다. 답은 에이전트 비용의 단위가 토큰 하나에서 실행 루프 하나로 옮겨가고 있다는 데 있습니다.

Flash는 왜 에이전트 모델이 됐나

Google의 공식 발표는 3.5 Flash를 "가장 강한 agentic and coding model"이라고 부릅니다. 공개 수치도 그 방향을 향합니다. Terminal-Bench 2.1 76.2%, GDPval-AA 1656 Elo, MCP Atlas 83.6%, CharXiv Reasoning 84.2%입니다. Google은 출력 토큰/초 기준으로 다른 frontier 모델보다 4배 빠르다고도 말합니다. 발표문 안의 사례 역시 일반적인 챗봇 사용보다 agent run에 가깝습니다. 레거시 코드베이스를 Next.js로 옮기고, 두 에이전트가 AlphaZero 논문을 요약해 게임을 만들고, 자산을 자동 분류하며, 여러 UX 시안을 60초 안에 생성하는 식입니다.

이 수치와 사례를 그대로 받아들이기 전에 한 가지를 분리해야 합니다. 모델 자체가 더 똑똑해진 것과, 모델이 들어가는 하네스가 더 강해진 것은 다릅니다. Google은 같은 날 개발자 하이라이트에서 Antigravity 2.0, Antigravity CLI, Antigravity SDK, Gemini API Managed Agents, AI Studio Android 흐름을 한꺼번에 발표했습니다. 3.5 Flash는 그 제품군의 모델 엔진입니다. 따라서 Google의 주장은 "모델 하나가 더 나아졌다"보다는 "모델, 하네스, 샌드박스, 도구 호출, 개발 표면을 묶으면 장기 작업의 처리량이 올라간다"에 가깝습니다.

이 관점에서 보면 Flash라는 이름이 유지된 이유도 보입니다. 에이전트 작업에서는 최고 모델의 단일 응답 품질만큼이나 반복 속도가 중요합니다. 한 번에 완벽한 답을 내는 모델보다, 빠르게 계획하고 실행하고 실패를 확인하고 다시 시도하는 모델이 더 나은 총비용을 만들 수 있습니다. Google은 3.5 Flash가 "다른 frontier 모델보다 빠르다"는 메시지를 통해 바로 이 지점을 노립니다. 에이전트 실행에서 속도는 UX 문제가 아니라 검증 루프의 단가입니다.

하지만 이 주장은 곧바로 비용 질문으로 이어집니다. 빠른 에이전트 모델은 재시도를 싸게 만들어야 합니다. 그런데 토큰 단가가 올라가면 "두 번 돌리고 검증 한 번 더 붙이는" 전략이 실제로 싸지는지 다시 계산해야 합니다. 특히 코딩 에이전트는 출력 토큰이 많이 나옵니다. 계획, 파일 읽기 요약, 패치, 테스트 로그 해석, 재수정, 최종 보고까지 모두 출력과 사고 토큰으로 청구됩니다. 3.5 Flash의 출력 가격이 100만 토큰당 9.00달러라는 점은 이 모델을 단순 요약 작업에 무심코 넣기 어렵게 만듭니다.

3배와 6배, 숫자를 정확히 나누기

커뮤니티 반응에서 가장 많이 보이는 표현은 "3.5 Flash가 6배 비싸졌다"입니다. 이 말은 기준에 따라 맞기도 하고, 너무 단순하기도 합니다. Google 공식 가격표를 기준으로 보면 gemini-3.5-flash 표준 가격은 입력 1.50달러, 출력 9.00달러입니다. gemini-3-flash-preview 표준 가격은 입력 0.50달러, 출력 3.00달러입니다. 이 둘을 비교하면 정확히 3배입니다.

반면 gemini-3.1-flash-lite 표준 가격은 입력 0.25달러, 출력 1.50달러입니다. 3.5 Flash와 비교하면 입력과 출력 모두 6배입니다. Flash-Lite는 "고볼륨 agentic tasks, translation, simple data processing"에 최적화된 별도 계층이므로, 3.5 Flash와 같은 급으로 단순 비교하면 안 됩니다. 그러나 개발자 입장에서는 실제 라우팅 후보가 됩니다. 에이전트가 모든 단계에 3.5 Flash를 써야 하는지, 단순 분류와 변환은 Flash-Lite로 내리고 핵심 계획/수정만 3.5 Flash로 올릴지 결정해야 하기 때문입니다.

이 표가 보여주는 것은 가격 인상만이 아닙니다. Google의 모델 계층이 더 세분화되고 있다는 점입니다. Flash-Lite는 여전히 고볼륨 작업의 비용 바닥을 담당합니다. 3 Flash Preview는 이전 Flash 계층의 감각을 남깁니다. 3.5 Flash는 "Flash"라는 이름을 달았지만 사실상 에이전트 실행을 위한 고성능 작업 모델입니다. 이름은 같아도 예산상의 역할은 달라졌습니다.

이 변화는 모델 라우팅을 복잡하게 만듭니다. 예전에는 "어려우면 Pro, 쉬우면 Flash"라는 단순 규칙이 어느 정도 통했습니다. 이제는 "장기 작업의 어느 단계인가"를 봐야 합니다. 계획 수립, 병렬 subagent 분해, 대규모 diff 작성, 테스트 실패 해석은 3.5 Flash가 유리할 수 있습니다. 반면 파일 목록 정리, 로그 압축, 간단한 한국어/영어 변환, 중복 제거는 Flash-Lite나 더 싼 모델이 충분할 수 있습니다. 비용 최적화는 모델 하나를 고르는 문제가 아니라 agent run을 단계별로 쪼개는 문제가 됩니다.

Google의 반론은 작업당 비용입니다

Google은 공식 발표에서 3.5 Flash가 "다른 frontier 모델보다 절반 이하 비용"으로 장기 에이전트 작업을 처리할 수 있다고 주장합니다. 이 문장은 토큰 단가만 보면 이상하게 들릴 수 있습니다. 3.5 Flash가 이전 Flash보다 비싸졌는데 어떻게 더 싸다는 말이 가능할까요. 답은 비교 대상과 계산 단위에 있습니다.

Google이 말하는 비교 대상은 저가 Flash-Lite가 아니라 다른 frontier 모델입니다. 그리고 계산 단위는 토큰당 가격이 아니라 작업 하나가 끝날 때까지의 총 비용입니다. 예를 들어 어떤 모델이 한 번의 시도에서는 싸지만 실패율이 높고, 다시 프롬프트를 다듬고, 컨텍스트를 재전송하고, 테스트 실패를 사람이 읽어야 한다면 전체 비용은 올라갑니다. 반대로 3.5 Flash가 더 비싼 토큰을 쓰더라도 한 번의 루프에서 더 빨리 올바른 패치와 검증 결과를 만들면 작업당 비용은 낮아질 수 있습니다.

이 논리는 충분히 타당하지만, 자동으로 참은 아닙니다. 에이전트 비용은 세 가지에 의해 갈립니다. 첫째, 작업 성공률입니다. 벤치마크 점수가 실제 저장소, 실제 권한, 실제 CI, 실제 팀 규칙에서 유지돼야 합니다. 둘째, 토큰 형태입니다. 에이전트는 대개 입력보다 출력과 중간 reasoning, 로그 해석이 비용을 키웁니다. 셋째, 하네스의 효율입니다. 같은 모델이라도 파일 선택, 캐싱, 도구 호출 정책, 실패 복구 전략이 나쁘면 토큰을 낭비합니다.

그래서 개발자는 Google의 "절반 이하 비용" 주장을 모델 소개 문구가 아니라 실험 가설로 읽어야 합니다. 제품에 넣기 전에 기존 agent run 로그를 기준으로 비교해야 합니다. 같은 작업 30개를 뽑아 gemini-3.5-flash, 더 싼 Flash-Lite 조합, 기존 GPT/Claude 조합을 각각 돌리고, 토큰 가격뿐 아니라 성공률, 사람이 개입한 횟수, 테스트 통과 여부, 리뷰에서 되돌아온 비율까지 함께 봐야 합니다. 특히 코딩 에이전트에서는 "성공처럼 보이는 큰 diff"가 실제로는 가장 비싼 실패일 수 있습니다.

Antigravity와 Managed Agents가 가격표를 바꾼다

이번 발표가 흥미로운 이유는 3.5 Flash가 독립 모델로만 나오지 않았기 때문입니다. Google I/O 2026 개발자 하이라이트는 Antigravity 2.0 데스크톱 앱, Antigravity CLI, Antigravity SDK, Gemini API Managed Agents, AI Studio Android 지원을 한 흐름으로 묶었습니다. Google은 Antigravity 2.0을 여러 에이전트를 병렬로 조율하는 중앙 표면으로 설명하고, CLI는 터미널 중심 실행 표면, SDK는 같은 하네스를 자체 인프라에서 쓰는 방법으로 설명합니다. Managed Agents는 단일 API 호출로 reasoning, tool use, code execution을 격리 Linux 환경에서 수행하게 하는 계층입니다.

이 구조는 모델 비용을 더 불투명하게 만들 수도, 더 관리 가능하게 만들 수도 있습니다. 불투명해지는 이유는 agent run이 단일 completion이 아니기 때문입니다. 내부에서 몇 번 계획을 세웠는지, 어떤 파일을 읽었는지, subagent가 몇 개 떴는지, 테스트 로그를 얼마나 먹었는지에 따라 비용이 달라집니다. 반대로 관리 가능해지는 이유는 하네스가 같은 실행 단위를 표준화하기 때문입니다. 팀이 직접 worker, sandbox, trace, retry 정책을 조립할 때보다, 공통 agent harness가 더 일관된 로그와 예산 경계를 제공할 수 있습니다.

여기서 중요한 실무 질문은 "3.5 Flash가 좋은가"보다 "어느 계층에서 예산을 제어할 수 있는가"입니다. 모델 API만 쓸 때는 요청당 토큰과 rate limit을 직접 볼 수 있습니다. Managed Agents나 Antigravity 같은 계층에서는 실행 단위가 더 큽니다. 개발자는 UI에서 보이는 한 번의 작업이 내부적으로 몇 개의 모델 호출, 도구 호출, 검색 요청, 캐시 읽기를 만들었는지 알고 싶어집니다. Google 가격표에는 Grounding with Google Search가 일정 무료 한도 이후 1,000개 검색 쿼리당 14달러로 청구된다는 조건도 있습니다. 에이전트가 검색과 Maps grounding까지 쓰는 순간, 모델 토큰 외 비용도 설계 대상이 됩니다.

이것이 3.5 Flash 발표를 단순 모델 뉴스가 아니라 AI 인프라 뉴스로 봐야 하는 이유입니다. 에이전트 시대의 비용은 모델 단가표 한 줄로 끝나지 않습니다. 모델, 하네스, 샌드박스, 검색, 파일 컨텍스트, 캐시, 재시도, 검증 스텝이 모두 합쳐집니다. Google은 이 묶음을 자사 생태계 안에서 통합하려 합니다. OpenAI는 Agents SDK와 Codex로, Anthropic은 Claude Code와 Agent SDK/Managed Agents로 비슷한 방향을 밟고 있습니다. 경쟁은 "누가 더 똑똑한 모델을 냈나"에서 "누가 더 예측 가능한 실행 단가를 만들 수 있나"로 이동하고 있습니다.

커뮤니티가 보는 긴장감

Reddit의 초기 반응은 크게 둘로 갈립니다. 긍정적인 쪽은 3.5 Flash가 채팅 업데이트라기보다 에이전트 업데이트처럼 보인다고 말합니다. Terminal-Bench, MCP Atlas, OSWorld 같은 숫자가 전면에 나오고, 긴 작업에서 한 번 더 재시도하거나 검증 패스를 붙일 수 있을 만큼 빠르면 워크플로 자체가 달라진다는 시각입니다. 이 관점은 Google의 발표 논리와 맞닿아 있습니다. 모델이 아주 조금 더 싸거나 비싼 문제가 아니라, 에이전트 루프의 설계가 달라진다는 것입니다.

회의적인 쪽은 두 가지를 지적합니다. 첫째, Google의 발표 벤치마크가 실제 제품 품질을 곧바로 보장하지 않는다는 점입니다. 장기 에이전트 작업에서 실패는 "답이 멍청함"보다 "도구가 멈춤", "컨텍스트가 꼬임", "diff가 너무 커서 신뢰하기 어려움", "테스트는 통과했지만 유지보수성이 낮음"으로 나타납니다. 둘째, Flash라는 이름과 실제 가격 감각 사이의 괴리입니다. 어떤 개발자는 3.5 Flash가 기존 Flash의 무심한 대량 처리 용도에 맞지 않고, 사실상 에이전트 전용 작업 모델처럼 가격이 책정됐다고 봅니다.

두 반응 모두 맞는 부분이 있습니다. Google이 3.5 Flash를 통해 제시하는 미래는 분명합니다. 모델 하나가 답을 내는 시대에서, 하네스가 여러 번 행동하고 검증하고 다시 행동하는 시대로 이동합니다. 이 미래에서는 빠른 모델이 중요합니다. 하지만 빠른 모델이 비싸졌다면, 개발자는 더 엄격하게 작업을 나눠야 합니다. 에이전트가 알아서 다 하게 두는 것이 아니라, 어떤 단계는 비싼 모델, 어떤 단계는 싼 모델, 어떤 단계는 규칙 기반 코드, 어떤 단계는 사람 리뷰로 남길지 정해야 합니다.

개발팀이 지금 확인할 것

첫 번째는 기존 agent run의 토큰 분포입니다. 많은 팀은 총 토큰만 봅니다. 이제는 입력, 출력, 캐시, 검색, 도구 호출 로그를 나눠 봐야 합니다. 3.5 Flash처럼 출력 가격이 높은 모델에서는 "긴 설명을 잘하는 모델"이 비용상 불리할 수 있습니다. 에이전트가 매 단계마다 장문의 계획과 회고를 쓰게 하면 눈에는 투명해 보이지만 청구서에는 무겁게 남습니다. 반대로 짧은 structured event와 필요한 diff만 남기는 하네스는 같은 모델에서도 비용을 줄일 수 있습니다.

두 번째는 성공률을 가격표 옆에 놓는 것입니다. 토큰 단가가 6배라도 성공률이 2배 오르고 사람 검토 시간이 크게 줄면 제품에 따라 합리적일 수 있습니다. 반대로 성공률 차이가 작다면 더 싼 모델 조합이 낫습니다. 중요한 것은 "벤치마크가 높다"가 아니라 "우리 작업 큐에서 더 싼 총비용으로 끝난다"입니다. 버그 수정, 리팩터링, 문서화, 데이터 정리, 고객 리서치처럼 작업 유형별로 샘플을 나눠야 합니다.

세 번째는 모델 라우팅을 agent planner 안에 넣는 것입니다. 사용자가 선택한 모델 하나로 모든 단계가 도는 구조는 단순하지만 비쌉니다. 계획 수립과 위험한 코드 수정에는 3.5 Flash를 쓰고, 로그 압축과 파일 후보 추리기에는 Flash-Lite를 쓰며, 최종 리뷰에는 더 보수적인 모델을 붙이는 식의 조합이 필요합니다. 에이전트 제품을 만드는 팀이라면 모델 선택 UI보다 내부 정책 엔진이 더 중요해질 수 있습니다.

마지막은 하네스 종속성입니다. Google Antigravity와 Managed Agents는 분명 개발자가 직접 조립해야 했던 많은 인프라를 줄여줍니다. 격리 환경, 상태 지속, subagent, 도구 실행, AI Studio와 Android/Firebase 흐름까지 묶어주는 것은 매력적입니다. 하지만 비용, 로그, 보존 기간, 권한, 데이터 경계가 Google의 실행 모델 안으로 들어갑니다. 기업 팀이라면 "편해졌다"와 "통제 가능하다"를 같은 말로 보지 말아야 합니다.

결론: Flash의 의미가 바뀌었다

Gemini 3.5 Flash는 Google의 모델 라인업에서 이상한 이름표를 달고 있습니다. Flash인데 싸기만 한 모델은 아닙니다. 빠르지만, 저가 대량 처리 모델로 무심코 쓰기에는 가격이 높습니다. 대신 Google은 이 모델을 에이전트 실행의 기본 엔진으로 내세웁니다. Terminal-Bench, MCP Atlas, GDPval-AA 같은 지표를 앞세우고, Antigravity와 Managed Agents를 통해 하네스까지 함께 제공합니다.

그래서 이번 발표의 진짜 뉴스는 "Gemini가 또 새 모델을 냈다"가 아닙니다. Google이 Flash 계층을 에이전트 경제의 중심으로 끌어올렸다는 점입니다. 개발자에게 남는 질문은 단순합니다. 3.5 Flash가 비싼 모델인가, 아니면 실패와 재시도를 줄이는 싼 실행 루프인가. 답은 Google의 발표문이 아니라 각 팀의 작업 로그에서 나옵니다.

당분간 좋은 기본 전략은 보수적입니다. 3.5 Flash를 모든 요청의 기본값으로 올리기보다, 장기 코딩·도구 사용·멀티스텝 작업에 제한적으로 넣고, 기존 Flash-Lite나 더 저렴한 모델과 비교 실험을 해야 합니다. 그리고 비교 기준은 토큰 단가가 아니라 작업당 완결 비용이어야 합니다. 에이전트 모델의 새 청구서는 그렇게 읽어야 합니다.