Antigravity에서 Gemini 3.8 Flash의 답변이 늦어졌다면, 우선 첫 응답을 기다리는 중인지, 도구 작업이 진행 중인지, 같은 명령을 반복하는지, 화면 자체가 느린지부터 구분하세요. 짧은 질문에도 아무 반응이 없고 503과 MODEL_CAPACITY_EXHAUSTED가 보인다면 서버 처리 용량 문제를 의심할 근거가 있습니다. 반면 파일 읽기나 테스트가 계속 진행된다면 작업 전체에 시간이 걸리는 상황일 수 있습니다. 같은 명령만 반복한다면 더 기다리기보다 실행을 멈추고 변경 내용을 확인하는 편이 낫습니다.
2026년 9월 21일 기준으로 확인한 자료에는 9월 15일의 응답 지연 신고, 당일의 해결 안내, 9월 16~18일의 추가 신고가 함께 있습니다. 따라서 과거의 해결 답변 하나만으로 현재 내 계정도 정상이라고 판단할 수는 없습니다. 이 글은 해당 자료를 바탕으로 확인 순서를 제안하며, 별도의 속도 측정 결과나 복구 시간 보장은 제공하지 않습니다.
지금 느린 부분을 먼저 구분하세요
아래 표에서 현재 화면과 가장 가까운 상황을 찾으면 불필요한 재시도를 줄일 수 있습니다. 상태 표시가 바뀌는지뿐 아니라 실제로 새 결과가 쌓이는지도 함께 보세요.
| 보이는 현상 | 먼저 확인할 것 | 다음 행동 |
|---|---|---|
| 짧은 질문도 첫 답변이 나오지 않음 | 오류 메시지, 요청 시각, 다른 모델에서도 같은지 | 새 대화에서 짧은 요청 하나로 비교하고, 용량 오류가 반복되면 전체 작업 재전송 중단 |
| 답변은 시작됐지만 완료까지 오래 걸림 | 파일 탐색·추론·도구 호출이 실제로 진행되는지 | 작업 범위를 줄이거나 낮은 사고 수준으로 작은 작업 비교 |
| 특정 명령 실행 후 진도가 멈춤 | 권한 승인, 터미널 입력, 테스트나 외부 서비스 응답 대기 | 기다리는 도구 하나를 확인하고 필요한 입력이나 승인 처리 |
| 같은 명령·수정·검색을 계속 반복함 | 같은 대상과 같은 오류가 반복되는지, 파일이 계속 바뀌는지 | 에이전트 중단 후 변경 내용과 사용량 확인 |
| 대화 전환이나 클릭 자체가 버벅임 | 사용 중인 제품과 버전, 다른 대화에서도 화면이 느린지 | 작업 저장 후 해당 제품의 업데이트 확인 |
이 구분은 원인을 확정하는 검사가 아닙니다. 다만 서버가 답을 주지 못하는 상황에 프로젝트 설정을 지우거나, 화면 전환 문제에 모델만 계속 바꾸는 식의 엇나간 조치를 피하는 데 도움이 됩니다.
503 용량 오류와 개인 사용 한도는 다릅니다
9월 15일 Google AI 개발자 포럼 글에는 새 대화에서 간단한 인사만 해도 첫 응답이 오래 걸렸다는 신고와 함께 503 UNAVAILABLE, MODEL_CAPACITY_EXHAUSTED 오류가 올라왔습니다. 해당 오류 메시지는 서버에 처리 가능한 모델 용량이 없다는 내용입니다. 이 오류만으로 개인 사용 한도를 모두 소진했다고 판단해서는 안 됩니다.
서버 처리 용량은 요청을 받아 처리할 여력이 있는지에 관한 문제이고, 개인 사용 한도는 내 계정에 허용된 사용량에 관한 문제입니다. 둘은 따로 확인해야 합니다. 오류 문구는 그대로 보관하고, 계정의 모델별 사용량 표시도 확인하세요. Antigravity 2.0의 공식 변경 내역에는 설정의 Models 화면에서 사용한 양과 남은 양을 구분하는 표시가 안내되어 있습니다. 다른 클라이언트는 메뉴 이름이 다를 수 있으므로 같은 경로가 있다고 가정하지 마세요.
용량 오류가 계속된다면 동일한 큰 작업을 연달아 제출하지 않는 것이 좋습니다. 사용 가능한 다른 모델로 작은 요청을 비교하거나, 작업을 저장한 뒤 시간을 두고 다시 확인할 수 있습니다. 유료 요금제 이용 여부만으로 서버 처리 용량이 보장되는 것은 아니며, 여기서 요금제 변경을 해결책으로 권할 근거도 없습니다.
오류 기록에 나타난 gemini-3.8-flash-medium 같은 문자열 역시 주의해서 읽어야 합니다. 이는 해당 신고의 진단 정보이며, 그 자체로 공개 Gemini API에서 사용할 수 있는 모델 ID가 확인된 것은 아닙니다.
새 대화와 모델 변경은 이렇게 비교하세요
새 대화를 만들거나 Gemini 3.7로 바꾸는 행동은 문제를 좁히기 위한 비교 방법입니다. 언제나 지연을 해결하는 방법은 아닙니다. 앞서 언급한 포럼에서도 3.7은 빠르다는 사용자와 3.7도 느리다는 사용자가 함께 있었습니다.
아래 순서로 한 번씩 비교하면 결과를 해석하기가 쉽습니다.
- 현재 작업을 보존합니다. 변경 파일과 실행 중인 명령을 확인하고, 이어서 할 일을 짧게 적어 둡니다. 반복 실행이 일어나고 있다면 먼저 중단합니다.
- 같은 모델로 새 대화를 엽니다. 파일 검색이나 도구 실행 없이 한 줄로 답할 수 있는 짧은 질문을 보냅니다. 요청 시각과 첫 응답이 보인 시각을 기록합니다.
- 모델 선택기에 다른 모델이 있다면 같은 요청을 보냅니다. 클라이언트·네트워크·계정은 유지하고, 모델과 사고 수준을 기록합니다. 3.7이 보이지 않으면 선택할 수 있다고 가정하지 않습니다.
- 차이가 있으면 원래 작업의 작은 부분만 다시 시도합니다. 짧은 답변이 빠르다는 이유만으로 원래의 긴 작업도 정상적으로 끝날 것이라고 결론 내리지 않습니다.
새 대화의 짧은 요청은 빠르고 기존 작업만 느리다면 대화에 쌓인 내용, 작업 크기, 특정 도구 대기를 우선 살펴볼 수 있습니다. 여러 모델의 짧은 요청이 모두 느리다면 모델 하나에만 원인이 있다고 보기 어렵습니다. 네트워크와 클라이언트 상태, 서비스 상황을 함께 확인할 이유가 생깁니다. 어느 경우든 이 비교만으로 정확한 원인이 증명되지는 않습니다.
정상과 비정상을 가르는 공식 첫 응답 시간 기준을 임의로 정할 필요는 없습니다. 평소 같은 환경에서 걸리던 시간과 비교하되, 마감 때문에 더 기다릴 수 없는 시점을 미리 정해 두세요. 그 시점을 넘기면 같은 요청을 계속 쌓기보다 대체 작업으로 옮기는 것이 실용적입니다.
사고 수준을 낮추면 도움이 되는 경우
Gemini 3.8 Flash는 Antigravity에서 사고 수준을 조정할 수 있습니다. 공식 Antigravity 출시 안내는 추론 깊이와 지연 시간 사이의 절충을 설명하고, 연산 효율이 중요한 작업을 위해 3.7도 유지한다고 안내합니다. Google의 모델 출시 설명에 따르면 복잡한 작업에서는 추론 단계와 반복적인 도구 호출이 늘어날 수 있으며, 특히 높은 사고 수준에서 더 많은 토큰을 사용할 수 있습니다.
따라서 답변이나 도구 결과가 계속 나오지만 간단한 수정에도 작업이 지나치게 길어진다면, 낮은 사고 수준으로 범위를 좁힌 작업을 비교해 볼 수 있습니다. 예를 들어 여러 파일을 한꺼번에 고치도록 요청했다면 먼저 오류가 나는 함수 하나를 확인하게 하는 식입니다. 결과가 맞는지 검토한 뒤 다음 작업을 맡기면 됩니다.
반대로 짧은 질문의 첫 응답부터 멈추거나 명확한 서버 용량 오류가 보인다면, 사고 수준을 낮추는 것만으로 해결될 것이라고 기대하기 어렵습니다. 9월 18일의 별도 사용자 신고에는 여러 사고 수준과 새 대화에서도 지연이 있었다는 내용이 있습니다. 이는 한 사용자의 경험이므로 모든 계정에서 같은 결과가 나온다는 뜻은 아니지만, 설정 변경이 만능 해결책이라는 주장과는 맞지 않습니다.
같은 명령을 반복한다면 기다리지 마세요
추론 시간이 길어지는 것과 이미 실패한 행동을 되풀이하는 것은 구분해야 합니다. 파일을 읽은 뒤 새 정보를 바탕으로 다음 단계로 넘어가면 진행 중이라고 볼 수 있습니다. 같은 파일에 같은 수정을 적용했다가 되돌리거나, 동일한 명령을 실행해 같은 오류만 받는다면 반복 여부를 확인할 필요가 있습니다.
이때는 에이전트를 멈추고 마지막으로 정상 완료된 단계부터 살펴보세요. 실행한 명령, 남아 있는 프로세스, 파일 변경 내용을 확인한 다음, 필요한 작업을 좁혀 다시 시작합니다. 권한 승인 창이나 터미널 입력을 기다리고 있다면 그 대기를 해결해야 하며, 요청 문구를 바꾸는 것만으로는 다음 단계로 넘어가지 않을 수 있습니다.
9월 18일 신고에는 반복 명령과 사용 한도 소모에 대한 불만도 포함되어 있습니다. 하지만 이 글만으로 실패한 요청의 과금 정책이나 환불 대상 여부를 확정할 수는 없습니다. 특히 같은 글에 포함된 외부 Gemini API 과금 문제와 Antigravity 구독의 사용 한도는 동일한 항목으로 다루면 안 됩니다.
실제 사용량에 의문이 생겼다면 작업 전후의 표시, 요청 시각, 오류, 반복된 명령을 함께 남기세요. 청구 문제라면 해당 청구 내역도 별도로 확인해야 합니다. 화면에서 요청이 실패했다는 사실만으로 사용량이 차감되지 않았거나 환급된다고 가정하지 마세요.
화면 자체가 느리다면 버전을 확인하세요
대화 목록을 전환할 때 멈추거나 클릭 반응이 느린 증상은 모델의 첫 응답 지연과 따로 볼 필요가 있습니다. 2026년 9월 18일 Antigravity 2.0의 2.15.0 변경 내역에는 대화 사이드바 전환 성능 개선과, 중복 권한 항목이 대화 파일을 크게 만들어 앱을 느리게 하던 문제의 수정이 명시되어 있습니다.
따라서 Antigravity 2.0을 사용하면서 화면 조작이 버벅이는 경우에는 현재 버전과 업데이트 제공 여부를 확인할 가치가 있습니다. 업데이트는 며칠에 걸쳐 순차적으로 제공될 수 있습니다. 변경 내용을 저장하고 실행 중인 작업을 정리한 다음, 사용 중인 제품에 맞는 업데이트를 적용하세요.
이 수정은 모든 Antigravity IDE나 CLI에 자동으로 해당하는 설명이 아닙니다. 또한 앱의 화면 전환 성능 개선이 서버의 MODEL_CAPACITY_EXHAUSTED까지 해결한다는 뜻도 아닙니다. 업데이트 뒤에는 처음 느렸던 동작을 다시 확인해야 합니다. 프로젝트나 대화 기록을 통째로 삭제하는 조치부터 시작할 이유는 없습니다.
해결됐다는 답변과 이후 신고를 함께 읽어야 합니다
9월 15일 포럼에는 성능 저하를 조사 중이라는 지원 답변이 있었고, 같은 날 해결됐다는 후속 답변도 게시됐습니다. 그러나 이후 댓글에는 9월 16~18일의 지연 신고가 이어졌습니다. 각 답변은 게시 시점의 안내나 사용자 경험으로 읽어야 합니다. 이를 하나로 뭉쳐 “지금 전 세계에서 장애가 발생했다”거나 “현재 완전히 복구됐다”고 말할 수는 없습니다.
간단한 비교와 해당 제품의 업데이트 확인 뒤에도 작업을 진행할 수 없다면, 지원 문의에 다음 정보를 모아 보내세요.
- 제품명과 버전, 운영체제, 선택한 모델과 사고 수준
- 발생 시각과 시간대, 첫 응답이 늦은지 전체 작업이 긴지
- 새 대화의 짧은 요청과 다른 모델에서 확인한 결과
- 오류 원문과 반복된 명령, 사용량 문제라면 관련 표시
API 키, 인증 정보, 프로젝트의 비공개 내용은 제외하세요. 지원팀이 재현할 수 있을 만큼 작은 요청과 증상 구분이 있으면 “전체적으로 느리다”는 설명보다 확인 범위를 좁히기 쉽습니다.
지금 할 일은 기다릴 시간을 무작정 늘리는 것이 아닙니다. 응답 대기인지, 도구 대기인지, 반복 실행인지, 화면 문제인지 먼저 구분하고 그에 맞는 작은 확인을 하는 것입니다. 새 결과가 계속 나오는 작업은 진행 상황을 보고 판단하되, 반복 실행이나 용량 오류가 이어지면 중단하고 기록을 남긴 뒤 다음 선택으로 넘어가세요.
