메타 설명
Gemini 3.5 Flash의 주요 변화, 사용처, 가격, Antigravity 코딩 활용 경험, 세계적인 반응을 정리했습니다. 빠른 속도와 에이전트형 코딩 작업에서 어떤 장점이 있는지 실제 사용 관점에서 살펴봅니다.

1. Gemini 3.5 Flash란?

Google이 2026년 5월 19일 공개한 Gemini 3.5 Flash는 Gemini 3.5 모델군의 첫 번째 모델입니다. Google은 이 모델을 “복잡한 에이전트형 작업을 실행하기 위한 모델”로 소개하고 있으며, 특히 코딩, 장기 작업, 에이전트 워크플로우에서 성능 향상을 강조하고 있습니다. (blog.google)

기존 Flash 계열이 “빠르고 저렴한 모델”이라는 이미지가 강했다면, Gemini 3.5 Flash는 단순히 빠른 모델을 넘어서 실제로 일을 끝까지 수행하는 모델에 가까워졌다는 점이 핵심입니다. Google 공식 모델 설명에서도 Gemini 3.5 Flash를 “속도에 최적화되면서도 검색과 그라운딩 능력을 갖춘 지능형 모델”로 설명하고 있습니다. (Google AI for Developers)

이번 모델은 Gemini 앱, Google Search의 AI Mode, Google AI Studio, Android Studio, Gemini API, Google Antigravity, Gemini Enterprise 등으로 제공됩니다. 즉, 일반 사용자뿐 아니라 개발자와 기업 사용자까지 모두 겨냥한 모델이라고 볼 수 있습니다. (blog.google)

2. 이전 모델과 달라진 점

Gemini 3.5 Flash의 가장 큰 변화는 속도와 코딩 성능의 균형입니다. Google은 3.5 Flash가 에이전트와 코딩 작업에서 프론티어급 성능을 제공한다고 설명합니다. 특히 Google Antigravity 안에서 AlphaZero 논문을 분석해 게임을 만들거나, 오래된 코드베이스를 Next.js로 전환하는 예시를 공개했습니다. (blog.google)

개발자 입장에서 눈여겨볼 변화도 있습니다. Gemini API 문서에 따르면 기존 gemini-3-flash-preview에서 gemini-3.5-flash로 모델명이 바뀌었고, thinking_budget 대신 thinking_level을 사용하도록 변경되었습니다. 또한 기본 추론 수준이 high에서 medium으로 바뀌었기 때문에, 품질·속도·비용을 함께 테스트하라고 안내하고 있습니다. (Google AI for Developers)

정리하면 변화점은 다음과 같습니다.

3. Antigravity에서 직접 써본 느낌

제가 Antigravity에서 Gemini 3.5 Flash를 사용해보며 가장 크게 느낀 점은 코딩 실력이 유의미하게 괜찮아졌다는 점입니다.

예전 Flash 계열은 빠르기는 했지만, 복잡한 코드 구조를 다루거나 여러 파일을 함께 수정하는 작업에서는 아쉬움이 있었습니다. 그런데 Gemini 3.5 Flash는 단순 코드 생성보다 프로젝트 맥락을 읽고 수정 방향을 잡는 능력이 더 좋아졌다는 느낌을 받았습니다.

특히 좋았던 부분은 다음과 같습니다.

첫째, 응답 속도가 빠릅니다.
코딩 중간에 기다리는 시간이 길면 흐름이 끊기는데, Gemini 3.5 Flash는 Antigravity 안에서 비교적 쾌적하게 사용할 수 있었습니다.

둘째, 토큰 사용량이 체감상 부담스럽지 않았습니다.
같은 작업을 여러 번 반복하거나 수정 요청을 이어갈 때도 과하게 무거운 모델을 쓰는 느낌이 덜했습니다. 물론 초반이다보니 사용량을 넉넉하게 주는 것일 수 있지만 AR기반의 앱을 하나 개발하는데 토큰을 60%정도만 소모하였습니다. 실제 API 비용은 사용 방식과 설정에 따라 달라질 수 있으므로, 개발자가 API로 사용할 때는 공식 가격표를 반드시 확인해야 합니다. (Google AI for Developers)

셋째, 5시간 단위 리프레시 구조가 작업 흐름에 도움이 됐습니다.
Google은 Antigravity에서 Google AI Pro·Ultra 구독자에게 더 높은 사용 한도와 5시간마다 갱신되는 할당량을 제공한다고 안내한 바 있습니다. 다만 사용량은 단순 메시지 수가 아니라 에이전트가 수행한 “작업량”과 관련이 있다고 설명합니다. (blog.google)
실제 사용에서는 이 구조 덕분에 하루에 여러 차례 나누어 작업하기 좋았습니다. 복잡한 프로젝트를 한 번에 몰아치기보다, 단계별로 구현하고 검증하는 방식과 잘 맞았습니다.

넷째, 코딩 품질이 뛰어납니다.

기존 구글의 제미나이 기반 3.1프로 등의 모델을 코딩에 있어 문제가 많았습니다. 자율성이 높아서인지 임의로 작업을 하다 앱 자체를 말아먹는 일이나 오류를 제대로 못 잡아내고 의도와 다르게 생성하는 경우가 많았습니다. 3.5 플래시는 그런 경우가 없었고 의도한데로 앱을 잘 만들어 주는 느낌이었습니다.

4. 어떤 사용처에 적합할까?

Gemini 3.5 Flash는 다음과 같은 사용처에 잘 맞습니다.

1) 바이브 코딩과 앱 개발

Antigravity, Google AI Studio, Android Studio에서 코딩 보조 모델로 활용하기 좋습니다. 간단한 코드 생성뿐 아니라 기존 코드 수정, 구조 리팩터링, 오류 추적, UI 개선 작업에 활용할 수 있습니다.

특히 “처음부터 완성형 앱을 만들어줘”보다는 다음과 같이 쓰는 것이 좋습니다.

• 현재 코드 구조 분석

• 오류 원인 추정

• 특정 컴포넌트 개선

• 파일 단위 리팩터링

• 기능별 단계 구현

• 수정 후 테스트 체크리스트 생성

이 방식은 Google이 말하는 에이전트형 작업 흐름과도 잘 맞습니다.

2) 빠른 문서 작성과 요약

Gemini 3.5 Flash는 빠른 응답이 강점이기 때문에 회의록 초안, 블로그 초안, 기획서 구조화, FAQ 작성, 문장 다듬기에도 적합합니다. 다만 Google Search 가이드에서도 강조하듯이 AI가 만든 글을 그대로 게시하기보다, 실제 경험과 관점을 더해야 검색에도 유리하고 독자에게도 도움이 됩니다.

3) 검색 기반 정보 정리

Google Search의 AI Mode에도 Gemini 3.5 Flash가 기본 모델로 적용되었습니다. Gemini 3.5 Flash는 단순 챗봇 모델이 아니라 검색, 요약, 실행, 에이전트 작업을 연결하는 모델로 자리 잡고 있다고 볼 수 있습니다.

4) 반복 작업 자동화

데이터 정리, 간단한 업무 자동화, 보고서 초안 생성, 코드 수정 제안처럼 반복적이지만 맥락 이해가 필요한 작업에 활용하기 좋습니다. 속도가 빠르기 때문에 실무자가 여러 번 시도하면서 결과를 개선하기에 적합합니다.

5. 가격은 어느 정도일까?

Gemini 3.5 Flash API 가격은 Gemini Developer API 기준으로 다음과 같습니다. 표준 사용 기준으로 입력은 100만 토큰당 1.50달러, 출력은 100만 토큰당 9.00달러입니다. Batch와 Flex 사용 시 입력 0.75달러, 출력 4.50달러로 낮아집니다. Priority 사용은 입력 2.70달러, 출력 16.20달러입니다. (Google AI for Developers)

여기서 중요한 점은 Gemini 3.5 Flash가 “Flash”라는 이름을 갖고 있지만, 이전 Flash Preview보다 무조건 저렴한 모델은 아니라는 점입니다. Google 문서에서도 Gemini 3.5 Flash가 Gemini 3 Flash Preview보다 비싸졌으니 가격을 검토하라고 안내하고 있습니다. (Google AI for Developers)

따라서 API로 대량 사용하려는 개발자는 다음 기준으로 접근하는 것이 좋습니다.

• 단순 대량 처리: Flash-Lite 계열 검토

• 코딩·에이전트 작업: Gemini 3.5 Flash 검토

• 고난도 추론: Pro 계열 검토

• 비용 절감: Batch 또는 Flex 활용

• 장기 프로젝트: 토큰 사용량과 thinking level 관리

6. 세계적인 반응은 어떨까?

Gemini 3.5 Flash에 대한 반응은 크게 두 가지로 나뉩니다.

첫 번째는 Google 생태계의 AI 전환이 본격화됐다는 반응입니다. Guardian은 Google이 검색창을 더 길고 구체적인 질문을 처리할 수 있는 방식으로 바꾸고, Gemini 3.5를 기반으로 AI 검색 경험을 강화한다고 보도했습니다. 또한 Gemini 앱 월간 사용자가 9억 명에 도달했다는 점도 함께 언급했습니다. (가디언)

두 번째는 개발자 커뮤니티의 비용·쿼터 우려입니다. Google AI Developers Forum에서는 Gemini 3.5 Flash가 이전 모델보다 비싸진 것 아니냐는 논의가 올라왔습니다. 특히 Flash라는 이름 때문에 저렴한 모델을 기대한 개발자들이 가격 변화에 민감하게 반응하는 분위기도 있습니다. (Google AI Developers Forum)

즉, 세계적인 반응은 “성능과 생태계 확장에 대한 기대”와 “실제 개발 비용에 대한 우려”가 함께 존재한다고 보는 것이 정확합니다.

7. 모델별 체감 비교

Gemini 3.5 Flash를 평가할 때는 “가장 똑똑한 모델인가?”보다 “실제 작업에서 얼마나 빠르고 쾌적한가?”를 함께 봐야 합니다.

현재 사람들의 평가를 종합하면 Claude와 ChatGPT의 최상위 모델은 여전히 복잡한 추론, 긴 코드베이스 분석, 장기 에이전트 작업에서 강점을 보입니다. 특히 여러 파일을 오가며 오랫동안 맥락을 유지해야 하는 작업에서는 Claude Opus 계열이나 ChatGPT 상위 모델이 더 안정적이라는 평가가 많습니다.

반면 Gemini 3.5 Flash는 속도와 비용 효율이 강점입니다. Antigravity에서 직접 사용해보면 코드 초안 생성, 간단한 리팩터링, UI 수정, 오류 원인 추정 같은 작업을 빠르게 반복하기 좋았습니다. 특히 응답이 빠르고, 토큰 사용량이 비교적 부담스럽지 않으며, 5시간 단위 리프레시 구조 덕분에 하루 작업을 여러 번 나눠 진행하기 좋았습니다.

따라서 Gemini 3.5 Flash는 Claude나 ChatGPT의 최상위 모델을 완전히 대체한다기보다, 실무에서 “빠르게 만들고, 빠르게 고치고, 빠르게 확인하는 모델”로 보는 것이 적절합니다. 고난도 설계나 복잡한 장기 작업은 Claude·ChatGPT 상위 모델을 함께 활용하고, 반복적인 코딩과 빠른 수정은 Gemini 3.5 Flash를 활용하는 식의 조합이 가장 현실적입니다.

8. 결론: Gemini 3.5 Flash는 “빠른 코딩 보조 모델”을 넘어섰다

Gemini 3.5 Flash는 단순히 빠른 모델이 아닙니다.
Google이 강조하는 방향은 명확합니다. 이제 AI 모델은 질문에 답하는 수준을 넘어, 사용자의 목표를 이해하고 실제 작업을 수행하는 에이전트형 도구로 이동하고 있습니다.

제가 Antigravity에서 사용해본 느낌도 비슷했습니다. 코딩 실력이 유의미하게 좋아졌고, 속도가 빠르며, 토큰 사용 부담도 비교적 덜하게 느껴졌습니다. 특히 5시간 단위로 다시 작업을 이어갈 수 있는 리프레시 구조는 바이브 코딩을 하는 사람에게 꽤 실용적이었습니다.

물론 가격은 반드시 확인해야 합니다. Gemini 3.5 Flash는 이름만 보면 저렴한 Flash 모델처럼 보이지만, API 기준으로는 이전 Flash Preview보다 비싸졌습니다. 그래서 단순 대량 작업보다는 코딩, 에이전트 작업, 빠른 반복 개발, 실무 자동화처럼 속도와 품질을 함께 요구하는 작업에 적합합니다.

한마디로 정리하면, Gemini 3.5 Flash는 “가볍게 쓰는 빠른 모델”이라기보다 빠르게 움직이는 실무형 AI 모델에 가깝습니다. Antigravity와 함께 사용할 때 그 장점이 특히 잘 드러납니다.

FAQ

Q1. Gemini 3.5 Flash는 코딩에 좋은가요?

Google은 Gemini 3.5 Flash를 에이전트와 코딩 작업에 강한 모델로 소개하고 있습니다. 실제 Antigravity 사용에서도 코드 수정, 리팩터링, 오류 분석에서 이전 Flash 계열보다 더 안정적인 느낌을 받을 수 있었습니다. (blog.google)

Q2. Gemini 3.5 Flash와 Gemini 3.1 Pro 중 무엇을 써야 하나요?

무조건 Gemini 3.5 Flash 입니다 3.1프로는 쓰는거 아닙니다

Q3. Antigravity에서 5시간마다 무조건 초기화되나요?

Google은 AI Pro·Ultra 사용자의 Antigravity 할당량이 5시간마다 리프레시된다고 안내했습니다. 다만 사용량은 단순 메시지 수가 아니라 에이전트가 수행한 작업량과 관련이 있으므로, 복잡한 작업을 많이 수행하면 체감 한도는 달라질 수 있습니다.