# Antigravity의 Gemini 3.8 Flash 느림, 원인별 대처

> Antigravity에서 Gemini 3.8 Flash가 느리면 화면부터 보세요. 재시도 카운트다운·용량 오류는 서버 쪽 대기, 같은 명령 반복은 멈출 신호, 명령 승인 요청은 내 차례입니다.

- URL: https://blog.laozhang.ai/ko/posts/gemini-3-8-flash-antigravity-slow
- Published: 2026-09-21
- Updated: 2026-09-25
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: 문제 해결
- Tags: Antigravity, Gemini 3.8 Flash, 응답 지연, 문제 해결

---
Antigravity에서 Gemini 3.8 Flash가 느릴 때 원인은 하나가 아닙니다. 서버 쪽 처리 용량이 부족해 앱이 백그라운드에서 재시도하는 중일 수도 있고, 모델이 원래 길게 생각하는 중일 수도 있고, 에이전트가 같은 명령을 되풀이하거나 내 승인을 기다리고 있을 수도 있습니다. 대처가 서로 반대이기 때문에 재시작이나 재전송보다 **지금 무엇을 기다리고 있는지**를 먼저 나누는 편이 빠릅니다.

가장 오래 조용한 경우는 서버 쪽 재시도입니다. Antigravity 2.0 데스크톱 앱은 2.14.0(2026년 9월 15일)부터 일시적인 서비스 오류가 나면 세션을 끝내지 않고 약 12분 동안 간격을 늘려 가며 다시 시도합니다. 2.16.0(9월 22일)부터는 이 재시도가 로딩 표시에 카운트다운과 시도 횟수로 나타납니다. 그 표시가 보이면 문제는 내 프롬프트나 프로젝트가 아니라 모델 요청 쪽에 있습니다.

## 화면에 보이는 것으로 대기 종류 나누기

아래 표는 Antigravity 2.0 데스크톱 앱 기준입니다. 버전 번호(2.x)는 데스크톱 앱에만 해당하며, 새 버전은 며칠에 걸쳐 순차 배포되므로 같은 날에도 사람마다 보이는 표시가 다를 수 있습니다.

| 화면에 보이는 것 | 뜻하는 것 | 먼저 할 일 | 기다리기를 그만둘 때 |
| --- | --- | --- | --- |
| 로딩 표시에 카운트다운과 시도 횟수, 또는 high traffic·`MODEL_CAPACITY_EXHAUSTED` 오류 | 서버 쪽 모델 처리 용량 부족, 앱이 자동 재시도 중 | 급하지 않으면 그대로 두고, 급하면 Gemini 3.7 Flash로 바꿔 이어 가기 | 시도 횟수만 늘고 진전이 없거나, 12분 가까이 같은 상태일 때 |
| 새 대화에서 짧은 문장에도 첫 응답이 오지 않고 도구 표시도 오류도 없음 | 모델 쪽 대기(긴 사고 시간 또는 서버 지연). 2.16.0 이전 빌드라면 재시도도 이렇게 보임 | 같은 짧은 문장을 3.7 Flash로 보내 비교 | 3.7은 바로 답하는데 3.8만 조용할 때 |
| 명령 실행 승인 요청이 떠 있음 | 에이전트가 내 확인을 기다리는 중 | 명령 내용을 읽고 승인하거나 거절 | 내가 응답하기 전까지 진행되지 않음 |
| 도구 초기화 진행, 파일 읽기·수정·테스트 결과가 계속 새로 쌓임 | 정상 작업. 3.8 Flash는 도구를 여러 번 호출하도록 설계됨 | 기다리기. 다음 작업부터 사고 수준을 한 단계 낮춰 보기 | 새 결과가 끊기고 같은 단계가 되풀이되기 시작할 때 |
| 같은 명령이나 같은 수정이 새 결과 없이 반복됨 | 에이전트가 반복에 빠짐. 사용량만 줄어듦 | 즉시 중단하고 변경 내용(diff) 확인 | 같은 동작이 결과 없이 두세 번 보이면 바로 |
| 입력·스크롤·대화 전환 자체가 버벅이고 큰 파일이나 diff에서 앱이 멈춤 | 모델이 아니라 클라이언트 쪽 문제 | 앱 업데이트 | 업데이트 뒤에도 같으면 피드백 보내기 |

표의 각 줄이 왜 그런 판단으로 이어지는지는 아래에서 차례로 설명합니다. 어느 줄에도 들어맞지 않으면 마지막 두 절의 비교 방법과 피드백 항목으로 넘어가면 됩니다.

## 3.8 Flash는 정상일 때도 먼저 조용히 생각한다

Google은 Gemini 3.8 Flash를 소개하면서 복잡한 작업에서 추론 단계를 더 거치고 도구를 반복해서 호출하며, 특히 높은 사고 수준에서는 성능을 위해 토큰을 더 쓸 수 있다고 밝혔습니다. 효율이 우선인 작업에는 낮은 사고 수준을 쓰거나 계속 지원되는 Gemini 3.7 Flash를 쓰라고 안내합니다([Google 블로그](https://blog.google/innovation-and-ai/models-and-research/gemini-models/3-8-flash-and-3-8-flash-cyber/), [Antigravity 블로그](https://antigravity.google/blog/gemini-3-8-flash-in-google-antigravity)).

출시 소개에서 흔히 보이는 "빠른 응답 속도"와 실제 체감이 어긋나는 이유도 여기에 있습니다. Artificial Analysis의 측정에서 Gemini 3.8 Flash(high)의 출력 속도는 초당 292토큰으로 빠른 편이지만, 첫 토큰까지 걸리는 시간(TTFT)은 14.71초로 비슷한 가격대 추론 모델의 중앙값 3.78초보다 깁니다. 이 값은 Gemini API에서 high 수준으로 잰 것이라 Antigravity의 기준값은 아닙니다. 다만 서버가 정상이어도 첫 글자가 나오기 전에 몇 초에서 십여 초는 조용할 수 있다는 점은 보여 줍니다. 초당 토큰 수는 생성이 시작된 뒤의 속도일 뿐, 첫 응답까지의 대기나 재시도, 에이전트가 도구를 몇 번 돌리는지는 포함하지 않습니다.

그래서 도구 결과가 계속 쌓이는 긴 작업이라면 느린 것이 아니라 일을 많이 하는 중일 가능성이 큽니다. 속도를 원하면 사고 수준을 조절합니다.

- 데스크톱 앱: 대화 입력창 아래 모델 선택 드롭다운에서 모델별 사고 수준(Low / Medium / High)을 고릅니다. 공식 문서의 예시 화면에는 Fast도 보이지만, 기본값이 무엇인지는 문서에 나와 있지 않습니다.
- Antigravity CLI: `/effort`로 추론 수준을 보거나 바꾸고, 실행할 때 `--effort` 플래그로 지정할 수 있습니다.

반대로 새 대화에서 "hi" 한 줄에도 한참 답이 없다면 사고 시간으로는 설명되지 않습니다. 9월 15일 포럼에 올라온 첫 신고도 바로 이 모습이었습니다. 이때는 다음 절의 서버 쪽 대기를 의심합니다.

## 백그라운드 재시도: 12분 가까이 조용할 수 있는 이유

2.14.0 변경 내역에는 "일시적인 서비스 오류 하나로 세션이 끝나던 문제를 고쳤고, 이제 일시적 오류는 약 12분 동안 백오프하며 재시도한다"고 적혀 있습니다([Antigravity changelog](https://antigravity.google/changelog)). 예전에는 곧바로 실패하던 요청이, 이제는 실패 대신 조용한 대기로 보이게 된 셈입니다. 서버 용량이 부족한 시간대에 "Working…"이 끝나지 않는 것처럼 보이는 가장 직접적인 공식 설명입니다.

이 대기를 눈으로 확인할 수 있게 된 것은 2.16.0부터입니다. 로딩 표시가 응답을 준비하는 동안 에이전트가 하는 일을 보여 주며, 도구 초기화 진행 상황과 함께 모델 요청을 재시도할 때는 실시간 카운트다운과 시도 횟수를 띄웁니다. 그러니 로딩 표시를 먼저 봅니다.

- **카운트다운과 시도 횟수가 보임**: 모델 요청이 서버에서 거절돼 다시 시도하는 중입니다. 프롬프트를 고치거나 다시 보내도 같은 서버 상태를 만날 가능성이 큽니다.
- **도구 초기화나 작업 내용이 보임**: 모델은 응답하고 있고 에이전트가 일을 하는 중입니다. 표의 네 번째·다섯 번째 줄로 판단합니다.
- **아무 표시 없이 비어 있음**: 2.16.0 이전 빌드라면 재시도 중이어도 이렇게 보입니다. 앱을 업데이트하면 다음부터는 구분할 수 있습니다.

언제 기다리기를 그만둘지는 작업의 급한 정도로 정합니다. 재시도 시간이 약 12분이므로, 그보다 오래 같은 화면이 이어진다면 재시도만으로는 설명되지 않습니다. 급한 작업이라면 12분을 다 기다릴 이유가 없습니다. 중단하고 Gemini 3.7 Flash로 바꿔 이어 가는 것이 9월 15일 포럼 staff 답변에서 많은 사용자가 효과를 봤다고 안내한 임시 방법입니다. 다만 같은 스레드에는 3.7도 느렸다는 보고가 있어, 전환이 늘 해결책이 되지는 않습니다.

CLI나 IDE 버전은 이 2.x 번호와 따로 관리되므로, 위 재시도 표시가 그대로 있다고 가정하지 않는 편이 안전합니다.

## 503 MODEL_CAPACITY_EXHAUSTED는 내 한도가 끝났다는 뜻이 아니다

포럼에 올라온 오류 중 하나는 다음과 같은 모양이었습니다. 상태 503 `UNAVAILABLE`, 이유 `MODEL_CAPACITY_EXHAUSTED`, 메시지 "No capacity available for model gemini-3.8-flash-medium on the server". 다른 사용자는 "Our servers are experiencing high traffic right now"라는 알림이 반복됐다고 적었습니다. 둘 다 **서버 쪽 모델 처리 용량이 모자라다**는 뜻이지 내 계정 사용량이 바닥났다는 뜻이 아닙니다. Antigravity는 출시 직후 업데이트에서 개인 사용 한도에 걸린 경우와 전체 용량 한계에 걸린 경우를 구분해 알리도록 바뀌었습니다.

오류 속의 `gemini-3.8-flash-medium`은 사고 수준에 따라 붙는 내부 문자열입니다. 공개 모델 ID는 `gemini-3.8-flash`이며, 오류에 보이는 이름을 어딘가에 설정할 필요는 없습니다.

![왼쪽은 요청이 줄지어 대기하는 Antigravity 서버와 503 MODEL_CAPACITY_EXHAUSTED 경고로 나타낸 서버 처리 용량, 오른쪽은 내 계정 카드로 나타낸 개인 사용 한도, 아래에 오류 메시지와 사용량 표시를 따로 확인하라는 안내가 있는 비교 그림](https://blog.laozhang.ai/posts/ko/gemini-3-8-flash-antigravity-slow/img/server-capacity-account-quota.webp)

내 사용 한도는 오류 문구가 아니라 사용량 표시에서 따로 확인합니다. Antigravity 요금제 문서의 내용은 다음과 같습니다([Plans 문서](https://antigravity.google/docs/plans)).

| 요금제 | 기본 한도 회복 주기 |
| --- | --- |
| Google AI Ultra | 5시간마다 회복, 가장 높은 주간 한도 |
| Google AI Pro | 주간 한도에 닿기 전까지 5시간마다 회복 |
| 그 외 개인 요금제 | 주 단위로 회복 |

구체적인 수치는 공개되어 있지 않습니다. 문서는 한도가 에이전트가 한 작업량에 비례하며, 시스템 용량에 따라 조정될 수 있다고 설명합니다. 데스크톱 앱에서는 설정 화면에서 모델별 사용량을 볼 수 있고, 문서 예시 화면에는 Gemini 모델의 주간 남은 한도와 5시간 남은 한도가 표시됩니다. CLI에서는 `/usage`(별칭 `/quota`)가 서버에서 한도 정보를 새로 받아 Model Quotas 패널을 엽니다. Pro와 Ultra는 AI Credit Overages 설정을 Never로 두면 기본 한도 회복을 기다리고, Always로 두면 기본 한도가 떨어졌을 때 구입한 AI 크레딧을 씁니다.

용량 부족으로 실패한 턴이 사용량에서 차감되는지, 나중에 돌려받는지는 공개 문서에 나와 있지 않습니다. 9월 중순 X에 Antigravity 쪽이 부하로 요청 오류가 나고 있으며 rate를 초기화하겠다는 취지의 짧은 문구가 돌았지만, 본문 전체와 적용 날짜·범위는 알려져 있지 않습니다. 한도 초기화를 전제로 작업 계획을 세우지 않는 편이 좋습니다.

Antigravity가 아니라 Gemini API를 직접 호출하다 503·429를 만났다면 경로가 다릅니다. [Gemini high demand 오류는 먼저 사용 경로와 상태 코드로 나눈다](https://blog.laozhang.ai/ko/posts/gemini-high-demand-error)와 [Gemini API 사용량 한도 2026: 프로젝트·등급·처리 경로별 429 진단](https://blog.laozhang.ai/ko/posts/gemini-api-rate-limits-guide)에서 이어서 볼 수 있습니다. Plans 문서의 "rate limits"는 5시간·주 단위로 회복되는 Antigravity 사용 한도로, API의 429와는 다른 개념입니다.

## 같은 명령을 반복하면 기다리지 말고 멈춘다

느린 것처럼 보여도 실제로는 에이전트가 제자리를 도는 경우가 있습니다. 9월 18일 포럼에는 High·Medium·Low 모두 지연이 있었고, 새 대화도 도움이 되지 않았으며, 7개 세션에서 사소한 셸 명령을 반복했고 Ultra 요금제 사용량이 빠르게 줄었다는 보고가 올라왔습니다. 한 사용자의 기록이고 Google의 답변은 없지만, 요금제 문서대로 한도가 에이전트 작업량에 비례한다면 반복은 결과 없이 사용량만 쓰는 상태입니다.

![위쪽은 파일 확인, 수정, 결과 확인으로 매 단계 새 결과가 쌓이는 작업이고, 아래쪽은 같은 명령을 되풀이하다 중단하고 변경 내용을 확인해야 하는 작업이며, 하단에 진행 기록을 보고 판단하라는 안내가 있는 그림](https://blog.laozhang.ai/posts/ko/gemini-3-8-flash-antigravity-slow/img/progress-versus-command-loop.webp)

진행 기록을 보고 두 경우를 가릅니다. 파일을 읽고, 고치고, 테스트 결과가 달라지는 식으로 매 단계 새 결과가 생기면 오래 걸려도 작업은 앞으로 가고 있습니다. 같은 명령이 같은 출력으로 두세 번 되풀이되거나, 같은 파일을 다시 읽고 같은 수정을 다시 시도한다면 기다려도 나아지지 않습니다. 이럴 때의 순서는 다음과 같습니다.

1. 작업을 중단합니다. 2.16.0부터 하위 에이전트는 실행 중·대기 중·완료 상태가 보이는 카드로 나타나며, 카드에 마우스를 올려 실행 중인 하위 에이전트를 멈출 수 있습니다.
2. 지금까지의 변경 내용(diff)을 Review Changes에서 확인합니다. 의도하지 않은 파일이 생기거나 지워지지 않았는지, 지시한 제약을 어기지 않았는지 봅니다.
3. 필요한 변경은 남기고, 막힌 지점을 구체적으로 적어 다시 지시합니다. 같은 문장을 재전송하면 같은 반복으로 돌아가기 쉽습니다.

이전 대화를 다시 열거나 되감기(rewind)로 돌아가려 한다면 앱 버전부터 확인합니다. 2.16.0에서는 오래된 대화를 다시 열 때 그 대화의 예전 수정이 프로젝트에 다시 적용돼 새 작업을 덮어쓰던 문제가, 2.17.0에서는 되감기가 오래된 파일 상태를 복원하던 문제가 고쳐졌습니다. 그 전 버전에서 되감기를 쓰면 느림보다 큰 손실이 생길 수 있습니다.

## 승인 대기와 앱 자체의 버벅임

권한 프리셋이 Request Review이면 에이전트는 허용 목록에 넣은 명령을 빼고는 터미널 명령을 실행하기 전에 반드시 확인을 요청합니다([에이전트 설정 문서](https://antigravity.google/docs/agent-settings)). 다른 창을 보고 있다가 이 요청을 놓치면 에이전트가 멈춘 것처럼 보입니다. 이 경우는 내가 응답하면 바로 진행됩니다. 속도를 위해 Turbo나 Always Proceed로 권한을 풀면 명령을 검토하는 단계 자체가 사라지므로, 느림 대책으로 쓸 일은 아닙니다. 설정은 Settings → General → Permission Settings에 있고 프로젝트마다 따로 둘 수 있습니다.

모델 응답과 상관없이 앱 화면 자체가 버벅인다면 클라이언트 쪽 문제입니다. 9월에 나온 데스크톱 앱 업데이트에는 이런 증상과 맞는 수정이 여러 개 있습니다.

| 증상 | 수정된 버전 |
| --- | --- |
| 아주 긴 대화가 느리게 열리고 메모리를 많이 씀, 메시지마다 설정 파일을 다시 훑어 반응이 늦음 | 2.14.0 (9월 15일) |
| 한동안 쉬었다가 다시 연결한 뒤 몇 초씩 멈춤 | 2.14.0 |
| 권한 항목이 중복으로 쌓여 대화 파일이 커지고 앱이 느려짐, 사이드바 대화 전환이 느림 | 2.15.0 (9월 18일) |
| 큰 프로젝트나 네트워크 폴더에서 시작 시 스킬 검색에 1분 넘게 걸림 | 2.16.0 (9월 22일) |
| 큰 파일이나 큰 diff를 열면 앱이 멈춤 | 2.17.0 (9월 22일) |

증상이 표와 맞는데 아직 해당 버전이 아니라면 업데이트가 가장 확실한 대처입니다. 순차 배포라 업데이트가 도착하는 데 며칠 걸릴 수 있습니다. 캐시 폴더나 프로젝트를 지우는 방법은 모델 쪽 대기에는 효과가 없고 작업을 잃을 위험만 있으므로 권하지 않습니다. 이 수정들은 모두 화면 반응에 관한 것이라, 서버 용량 부족으로 생기는 대기는 줄여 주지 않습니다.

## 3.7 Flash로 바꿀지, 새 대화로 옮길지 짧게 비교하기

원인이 분명하지 않을 때는 작은 비교 하나로 방향을 정할 수 있습니다. 공식 절차가 아니라 위험이 적은 점검 방법이며, 결과가 곧 해결을 보장하지는 않습니다.

1. **새 대화에서 도구를 쓰지 않는 짧은 문장**을 3.8 Flash에 보냅니다. 원래 작업보다 훨씬 빨리 답한다면, 원래 작업이 느린 이유는 대화 길이나 작업량 쪽에 있습니다. 긴 작업은 사고 수준을 낮추거나 단계를 나눠 봅니다.
2. 짧은 문장에도 한참 답이 없으면 **같은 문장을 3.7 Flash로** 보냅니다. 3.7은 바로 답한다면 3.8 쪽 대기이므로 급한 작업은 3.7로 옮깁니다. 둘 다 늦다면 모델 하나의 문제가 아니므로 모델을 계속 바꿔 보는 것보다 기다리거나 피드백을 보내는 편이 낫습니다.
3. 비교할 때는 요금제, 모델과 사고 수준, 앱 버전, 시각(UTC)을 적어 둡니다. 같은 조건에서 시간을 두고 다시 해 보면 일시적인 현상인지 알 수 있습니다.

새 대화나 낮은 사고 수준이 도움이 되는지는 보고마다 엇갈립니다. 한 사용자는 새 대화도 소용없었다고 했고, 다른 사용자는 3.7로 되돌렸을 때만 나아졌다고 적었습니다. 그래서 1번과 2번을 모두 해 보고 판단하는 편이 안전합니다. Gemini API에서 모델을 직접 쓰면서 3.7에서 3.8로 옮기는 경우라면 [Gemini 3.8 Flash 출시 가이드: 가격, 모델 ID, 3.7 마이그레이션](https://blog.laozhang.ai/ko/posts/gemini-3-comparison)을 참고하세요.

## 2026년 9월 15일 이후 보고된 경과

Antigravity 전용 공식 상태 페이지는 공개된 곳이 없어, 사용자 입장에서는 포럼 스레드가 가장 가까운 경과 기록입니다. 아래 시각은 모두 UTC입니다([포럼 스레드](https://discuss.ai.google.dev/t/gemini-3-8-in-antigravity-is-too-slow/183057)).

| 날짜 | 보고 내용 |
| --- | --- |
| 9월 15일 09:17 | 평소 빠르던 Antigravity 2.0에서 전날부터 첫 응답이 극도로 느려짐, 빈 새 대화에서 "hi"에도 멈춤, 오류 코드 없음 |
| 9월 15일 | 모든 Gemini 모델이 느림과 high traffic 알림 반복, 503 `MODEL_CAPACITY_EXHAUSTED`, 백그라운드 재시도가 많다는 보고가 이어짐 |
| 9월 15일 19:25 | 포럼 staff 답변: 엔지니어링 팀이 Gemini 3.8 Flash의 성능 저하를 조사 중, 임시로 3.7 Flash 전환 안내 |
| 9월 15일 22:31 | 같은 staff: 문제가 해결됐다고 답변 |
| 9월 16~18일 | 느려짐 → 정상 → 다시 느려짐 → 다시 해결 보고가 번갈아 올라옴, 같은 지점에서 6시간 멈췄다는 보고 |
| 9월 24일 | "이번 주 내내 느리다", "3.8만의 문제가 아니며 Working…이 끝나지 않는다"는 보고 |

9월 15일의 "해결" 답변 이후에도 신고가 계속됐으므로, 그 답변을 현재 상태로 읽으면 안 됩니다. 지금 느린 것이 나만의 문제인지는 이 기록보다 앞 절의 비교와 로딩 표시로 판단하는 편이 정확합니다.

## 피드백을 보낼 때 함께 적을 정보

Google 도움말의 같은 증상 스레드에서도 제품 안에서 피드백을 보내라는 답변이 가장 위에 있습니다. 다음 정보를 함께 적으면 재현하기 쉬워집니다.

- 앱 종류와 버전(Antigravity 2.0 데스크톱 2.x, CLI, IDE 중 무엇인지)
- 모델과 사고 수준(예: Gemini 3.8 Flash, Medium)
- 증상이 시작된 시각(UTC)과 지속 시간
- 오류 문구 원문(예: `MODEL_CAPACITY_EXHAUSTED`, high traffic 알림)
- 로딩 표시에 재시도 카운트다운과 시도 횟수가 나왔는지
- 같은 짧은 문장을 3.7 Flash로 보냈을 때의 결과
- 반복이 있었다면 반복된 명령과 그 사이 사용량 변화

2.15.0 이전에는 큰 진단 로그를 첨부하면 피드백 전송이 실패하는 문제가 있었으므로, 로그를 붙일 때도 최신 버전에서 보내는 편이 좋습니다.

## 참고 자료

이 글이 링크한 외부 페이지를 본문에 나온 순서대로 정리했습니다. 마지막 업데이트: 2026-09-25.

- [Google 블로그](https://blog.google/innovation-and-ai/models-and-research/gemini-models/3-8-flash-and-3-8-flash-cyber/) (blog.google)
- [Antigravity 블로그](https://antigravity.google/blog/gemini-3-8-flash-in-google-antigravity) (antigravity.google)
- [Antigravity changelog](https://antigravity.google/changelog) (antigravity.google)
- [Plans 문서](https://antigravity.google/docs/plans) (antigravity.google)
- [에이전트 설정 문서](https://antigravity.google/docs/agent-settings) (antigravity.google)
- [포럼 스레드](https://discuss.ai.google.dev/t/gemini-3-8-in-antigravity-is-too-slow/183057) (discuss.ai.google.dev)