# Antigravity Gemini 4 Argon Retrying (1/9) 오류: 60초 끊김과 대처

> Gemini 4 Argon이 큰 파일을 고치다 Retrying (1/9)에 걸리면 60초 무통신 끊김일 가능성이 큽니다. 9번 기다리지 말고 같은 대화에서 줄 범위로 나눠 고치게 하세요.

- URL: https://blog.laozhang.ai/ko/posts/antigravity-model-unavailable-retrying
- Published: 2026-10-27
- Updated: 2026-10-27
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: 문제 해결
- Tags: Antigravity, Gemini 4 Argon, Model unavailable, Retrying (1/9), 문제 해결

---
Antigravity(안티그래비티)에서 Gemini 4 Argon이 `Model unavailable, retrying in 4s (attempt 1/9)`를 띄우고, Windows 클라이언트라면 짧게 `Retrying (1/9)...`가 보인 뒤 숫자가 올라가다 9번째에 "Agent execution terminated due to error"로 끝났다면, 모델이 내려간 것이 아닐 가능성이 큽니다. 같은 재시도 표시 뒤에는 서로 다른 실패가 여러 개 있습니다. Argon 사용자에게 가장 많이 보고된 경우는 에이전트가 파일을 새로 쓰거나 고치는 단계(`write_to_file`, `replace_file_content` 같은 도구 호출)에서 큰 수정을 만드는 동안 60초 넘게 데이터가 한 바이트도 오지 않아 연결이 끊기는 것입니다. 이때 재시도는 똑같은 요청을 다시 보낼 뿐이라 9번 모두 같은 자리에서 끊깁니다.

그래서 큰 파일을 고치던 중이라면 첫 표시에서 멈추고, 새 대화를 열지 말고 같은 대화에서 "방금 수정을 줄 범위로 나눠 한 번에 100줄 이하로 적용해 줘"라고 지시하세요. 반대로 한 줄짜리 짧은 질문까지 실패하거나 제미나이 모델이 전부 실패하고 Claude만 정상이라면 구글 쪽 처리 용량 문제이므로 잠시 Gemini 3.8 Flash나 Claude Sonnet 5.5로 바꾸면 됩니다. Settings 화면에서 사용량이 0%로 표시된다면 원인은 할당량이고, 기다리거나 AI Credit Overages 설정을 바꿔야 합니다.

2026년 10월 27일에 실제로 실행한 것은 두 가지입니다. RCA(원인 분석) 보고서 작성자가 공개한 Antigravity 로그에 그 작성자의 스크립트를 다시 돌려 결과를 대조했고, 서드파티 게이트웨이를 거쳐 Gemini 4 Argon의 스트리밍을 직접 측정했습니다. Antigravity 안에서 이 재시도 표시를 재현하지는 않았으므로, Antigravity 동작에 관한 내용은 구글 공식 문서와 Google AI 개발자 포럼의 사용자 보고에서 가져왔습니다.

## attempt 1/9 표시의 뜻: 모델이 멈춘 게 아닙니다

`attempt k/9`는 Antigravity App이 모델 요청을 자동으로 다시 보내는 중이라는 카운트다운입니다. [Antigravity 변경 기록](https://antigravity.google/docs/changelog)에 따르면 App 2.14.0(2026년 9월 15일)부터 일시적인 서비스 오류가 나도 세션을 끝내지 않고 "약 12분" 동안 간격을 늘려 가며 재시도하고, 2.16.0(9월 22일)부터 그 재시도가 시도 횟수와 함께 화면에 표시됩니다. 앞에 붙은 "Model unavailable"은 모델이 중단됐다는 뜻이 아닙니다. 구글 쪽 처리 용량이 모자랄 때도, 연결이 중간에 끊겼을 때도 같은 문구가 붙기 때문에 이 문구만으로는 원인을 알 수 없습니다.

9번째 시도까지 실패하면 대화가 멈추고 로그에는 `agent executor error: generating and executing: stream reading error: unexpected EOF`가 남습니다. Windows 데스크톱 클라이언트에서 도중에 취소를 누르면 "task cancelled by user"가 표시되는데, 이는 사용자가 취소했다는 기록일 뿐 원인과는 관계가 없습니다. 이 화면 문구들은 구글 문서에 정리돼 있지 않고, [포럼의 2.23.0 재시도 루프 분석 글](https://discuss.ai.google.dev/t/189559)과 [Windows 사용자의 Retrying (1/9) 보고](https://discuss.ai.google.dev/t/189747)에서 확인되는 형태이므로 버전에 따라 조금씩 다를 수 있습니다.

## 내 경우는 어느 쪽인가: 증상 5가지와 원인별 대처

어느 경우인지는 실패한 순간에 에이전트가 무엇을 하고 있었는지와, 같은 계정에서 다른 요청이 되는지로 가릅니다. 아래 표는 포럼 보고와 구글 문서를 바탕으로 정리한 것이고, 첫 번째 줄의 판단은 실험 결과에서 끌어낸 추론입니다.

| 보이는 것 | 가능성이 큰 원인 | 먼저 할 일 |
| --- | --- | --- |
| 큰 파일을 쓰거나 고치다가 1분 남짓 지나 표시가 뜸. 사용량은 남아 있고 짧은 질문은 정상 | 도구 호출 인자가 다 만들어질 때까지 아무 데이터도 오지 않아 60초 무렵 연결이 끊김 | 첫 표시에서 멈추고 같은 대화에서 줄 범위로 나눠 수정하게 하기 |
| 한 줄짜리 질문도 실패하거나, 제미나이 모델이 전부 실패하고 Claude는 정상 | 구글 쪽 일시적 처리 용량 부족 | 잠시 Gemini 3.8 Flash(Medium/Low)나 Claude Sonnet 5.5·Opus 5.5로 전환하거나 몇 분 기다리기. 이 경우엔 새 대화도 괜찮음 |
| Settings 화면의 5시간 또는 주간 사용량이 0% | 할당량 소진 | 갱신을 기다리거나 AI Credit Overages를 Always로 바꾸기 |
| 파일 수정 없이 긴 추론을 하다가 몇 분 뒤 끊김 | 추론 요약 사이에 60초 공백이 생겼거나, 네트워크가 유휴 연결을 끊음 | 사고 수준을 한 단계 낮추고 작업을 나누기 |
| VPN·프록시·회사망에서만 반복되거나, 계정 관리용 서드파티 도구를 쓰는 계정에서 반복 | 중간 네트워크 장비 또는 서드파티 도구 | VPN·프록시를 끄고 다른 망에서 같은 요청을 보내기. 서드파티 도구는 사용 중지 |

용량 부족 사례로는 2026년 10월 1일 Gemini 3.7 Flash High에서 같은 `attempt 2/9` 표시가 모든 프롬프트에 뜨다가 모델을 바꾸자 바로 풀린 보고가 있고, 스레드의 첫 답변은 "그 순간 모델이 응답하지 못한 것이며 계정 문제가 아니다"라는 설명이었습니다([포럼 186207](https://discuss.ai.google.dev/t/186207)). 10월 26일에는 주간 98%·5시간 100%가 남은 Pro 계정에서 제미나이 모델만 전부 실패하고 Claude는 정상이었는데, 이 포럼에서 자주 답변하는 같은 사용자가 일시적인 서버 쪽 용량 문제로 보고 3.8 Flash나 Claude로 잠시 옮기라고 답했습니다. 둘 다 구글의 공식 입장이 아니라 사용자의 답변입니다([포럼 195034](https://discuss.ai.google.dev/t/195034)). 큰 수정 사례의 로그에는 서버 오류가 한 줄도 없었던 것과 달리, 이 사례에서는 "Our servers are experiencing high traffic right now"처럼 서버 쪽 메시지가 화면에 직접 떴습니다. 3.8 Flash로 잠시 옮길 때 무엇이 달라지는지는 [Gemini 4 Argon vs 3.8 Flash 차이: 같은 프롬프트 실측 비용과 갈아탈 작업](https://blog.laozhang.ai/ko/posts/gemini-4-argon-vs-gemini-3-8-flash)에 정리돼 있습니다.

긴 추론 중 끊김은 RCA 작성자의 2.25.0 재시험에서 4분 22초짜리 추론이 추론 요약 사이의 공백이 60초에 이른 순간 262초에 끊긴 사례가 있습니다. 그보다 앞선 App 2.18.1의 Gemini 3.1 Pro High에서도 약 120초마다 끊기는 보고가 있었고, 스레드의 답변은 "일부 네트워크는 약 2분간 유휴로 보이는 연결을 끊는다"며 VPN·프록시·회사 방화벽 없이 시도하고 사고 수준을 낮추라고 권했습니다([포럼 186367](https://discuss.ai.google.dev/t/186367)). 서드파티 도구는 2026년 3~5월 중국어권 커뮤니티에서 계정 관리 도구를 쓰던 계정이 계속 재시도에 걸렸다는 보고가 있었고, 무엇보다 [Antigravity FAQ](https://antigravity.google/docs/faq)는 서드파티 소프트웨어로 Antigravity에 접근하면 약관 위반이며 계정 정지나 해지로 이어질 수 있다고 밝힙니다. 자동 계정 전환도 개인 요금제에서 지원되지 않으므로 해결책으로 쓰면 안 됩니다.

어느 쪽인지 한 번의 시도로 가리고 싶다면, 같은 에이전트에게 100줄 이하의 작은 수정을 하나 시켜 보세요. 그 수정이 들어가면 요청 크기가 원인이었다는 뜻이고, 작은 수정이나 "한 줄로 답해 줘" 같은 질문까지 실패하면 용량이나 할당량 쪽을 봐야 합니다. 이 판별법은 포럼의 실험 결과에서 끌어낸 추론이며, Antigravity 안에서 직접 검증한 것은 아닙니다. 재시도 표시 없이 그냥 느린 것이 문제라면 [Antigravity의 Gemini 3.8 Flash 느림, 원인별 대처](https://blog.laozhang.ai/ko/posts/gemini-3-8-flash-antigravity-slow)를, 로그인이나 라이선스 오류라면 [Antigravity 3501 오류 해결: 재설정으로 풀리는 경우와 안 되는 경우](https://blog.laozhang.ai/ko/posts/antigravity-error-3501)를 보세요.

![attempt 1/9가 떴을 때 100줄 이하 작은 수정이 들어가는지, Settings 사용량이 0%인지 차례로 확인해 요청 크기·할당량·용량 부족을 가리는 판단 흐름](https://blog.laozhang.ai/posts/ko/antigravity-model-unavailable-retrying/img/retry-cause-check.webp)

## 큰 파일 수정은 줄 범위로 나눠 같은 대화에서 다시 시킵니다

큰 수정이 원인일 때 가장 효과가 있었다고 보고된 방법은 도구 호출 한 번에 담기는 수정량을 줄이는 것입니다. Windows 사용자 dllhell이 [포럼 189559 스레드](https://discuss.ai.google.dev/t/189559)에서 "도구 호출당 최대 60~80줄"을 제안했고, macOS의 App 2.24.0·Argon (High) 사용자가 "이 방법이 실제로 통했다"고 확인했습니다. 순서는 다음과 같습니다.

1. 큰 파일을 쓰거나 고치는 단계에서 `attempt 1/9`가 뜨면 9번을 기다리지 말고 그 자리에서 취소해 멈춥니다.
2. 새 대화를 열지 않고 같은 대화에 아래처럼 지시합니다. 포럼에서 쓰인 영어 원문은 "Split that file edit into two smaller replace_file_content calls by line range."입니다.

   ```text
   방금 하던 파일 수정을 줄 범위로 나눠서 진행해 줘.
   replace_file_content(새 파일이면 write_to_file) 한 번에 100줄 이하만 쓰고,
   각 호출 전에 몇 번째 줄부터 몇 번째 줄까지인지 먼저 알려 줘.
   ```

3. 새 파일을 만들 때도 처음부터 "약 N줄짜리 파일"이 아니라 줄 범위나 구역 단위로 나눠 쓰라고 지시합니다. 아래 측정에서 "약 400줄"을 요청하자 실제로는 551~773줄이 나왔기 때문에, 대략적인 크기만 말하면 상한이 지켜지지 않습니다.
4. 같은 대화의 다음 작업에도 같은 제한을 처음부터 붙여 둡니다.
5. 100줄 이하로 나눴는데도 같은 자리에서 끊기면 크기가 원인이 아닐 수 있으므로, 위 표의 다른 줄로 돌아갑니다.

나누면 끊김은 줄지만 사라지지는 않습니다. RCA 작성자의 통제 실험에서 1,200줄 파일을 한 번에 쓰면 3번 모두 60.25~60.36초에 끊겼고, 100줄씩 12번에 나눠 쓰면 3번 중 1번만 끝까지 성공했습니다. 실패한 두 번 중 한 번은 9번째 호출이 60.2초 동안 데이터 없이 있다가 끊긴 경우였고(같은 요청의 재시도는 성공했지만 실험은 첫 실패에서 멈췄습니다), 다른 한 번은 5번째 호출이 약 46초 동안 데이터 없이 있다가 `proto: unexpected EOF`라는 다른 오류로 실패한 경우로 재시도하지 않았습니다([antigravity-stream-cutoff-rca 저장소](https://github.com/Xiphiros/antigravity-stream-cutoff-rca)). 또 도구를 호출하기 전에 "지금 수정합니다" 같은 한 문장을 먼저 말하게 해서 연결을 살려 두려는 방법은 효과가 없었다고 보고됐습니다. dllhell의 로그에서는 그 문장을 3초에 내보낸 실행이 63초에 끊겼고, 끊김은 매번 마지막으로 스트리밍된 추론이나 문장 뒤 정확히 60.0초에 일어났습니다([포럼 189747의 Argon 60초 끊김 분석](https://discuss.ai.google.dev/t/189747)).

## 9/9까지 기다릴까, 취소하고 새 대화를 열까

큰 수정 때문에 끊긴 경우라면 9번째까지 기다리는 것은 손해입니다. 시도마다 약 60초 동안 응답을 기다리다 끊기고, 실패한 뒤 다음 시도까지의 대기는 1번째 실패 뒤 4초에서 시작해 거의 두 배씩 늘고, 가장 긴 대기는 7번째와 8번째 시도가 실패한 뒤, 즉 화면에 7/9·8/9가 떠 있는 동안의 약 2분 반~4분입니다. 구글 변경 기록은 재시도 시간을 "약 12분"이라고 적고 있지만, RCA 작성자의 로그에서 9번을 다 쓴 12번의 실행은 첫 실패부터 종료까지 16.7~20.2분이 걸렸습니다. 그 시간 동안 매번 같은 요청이 나가므로 결과도 같습니다.

취소한 뒤 새 대화를 여는 것도 큰 수정에서는 좋은 선택이 아닙니다. 끊길 때마다 대화 기록에 "Error: The stream was interrupted. Please continue the task you were working on."이 남는데, dllhell의 보고에서는 Argon이 이 기록을 보고 6번째 시도에서 스스로 수정 범위를 나눠 성공했습니다. 새 대화는 이 기록과 쌓아 둔 맥락을 버리고 같은 큰 수정을 처음부터 다시 시도하게 만듭니다. 반면 용량 부족처럼 작은 요청까지 실패하는 경우에는 새 대화를 열고 모델을 바꾸는 것이 합리적입니다. 실패한 턴을 계속 재시도하지 않게 되기 때문입니다.

## 파일 수정만 끊기는 이유: Argon 도구 호출 스트리밍 실측

Argon이 추론하거나 일반 문장을 쓸 때는 글자가 몇 초 간격으로 계속 흘러오지만, 파일 수정 도구를 호출할 때는 인자(파일 내용 전체)가 다 만들어진 뒤 한 번에 도착합니다. Vertex AI 함수 호출 문서도 프리뷰 옵션 `streamFunctionCallArguments`를 켜지 않으면 함수 호출 인자는 모두 생성된 뒤에 돌아온다고 설명합니다. 그래서 큰 수정을 만드는 동안에는 연결이 완전히 조용해지고, Antigravity에서는 그 무통신이 60초 무렵에 끊깁니다. RCA 작성자가 App 2.23.0에서 남긴 로그에는 503이나 `RESOURCE_EXHAUSTED` 같은 서버 오류가 한 줄도 없었고, 실패는 모두 상대 쪽이 닫은 연결(EOF)이었습니다. 다만 누가 60초에 끊는지는 밝혀지지 않았습니다. 작성자는 구글 프런트엔드 쪽을 의심하지만 패킷 캡처로 확인하지는 않았습니다.

2026년 10월 27일, 이 차이를 직접 측정했습니다. 경로는 laozhang.ai의 제미나이 네이티브 엔드포인트 `streamGenerateContent?alt=sse`였고, 모델은 Gemini 4 Argon, 사고 수준은 low, 함수는 `write_to_file(path, content)` 하나였습니다. Python 모듈 하나를 함수 호출 한 번으로 쓰게 한 경우와 같은 내용을 일반 텍스트로 쓰게 한 경우를 비교했고, 다섯 번 호출에 정가 기준 $0.28이 들었습니다.

*안내: [laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다](https://blog.laozhang.ai/ko/about#laozhang). 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.*

| 요청 방식 | 요청한 길이 | 실제 줄 수 | 출력 토큰 | 첫 데이터까지 | 받은 이벤트 수 |
| --- | --- | ---: | ---: | ---: | ---: |
| 함수 호출 1번 | 약 100줄 | 135 | 2,029 | 20.8초 | 2 |
| 함수 호출 1번 | 약 400줄 | 616 | 5,965 | 54.9초 | 2 |
| 함수 호출 1번 + `streamFunctionCallArguments: true` | 약 400줄 | 665 | 6,635 | 59.8초 | 2 |
| 함수 호출 1번 (반복) | 약 400줄 | 773 | 7,250 | 62.0초 | 2 |
| 일반 텍스트 | 약 400줄 | 551 | 6,276 | 6.2초 | 241 |

![Gemini 4 Argon 실측에서 함수 호출은 20.8~62.0초 동안 데이터 없이 있다가 인자 전체가 한 번에 오고, 일반 텍스트는 6.2초부터 241개 조각으로 오는 타임라인](https://blog.laozhang.ai/posts/ko/antigravity-model-unavailable-retrying/img/argon-stream-timeline.webp)

함수 호출은 매번 첫 데이터가 올 때까지 아무것도 오지 않았고, 6.9~30.3KB의 인자 전체가 이벤트 하나로 한꺼번에 도착했습니다. 같은 분량의 텍스트는 6.2초부터 241개 조각으로 나뉘어 왔고 가장 긴 공백도 그 첫 6.2초였습니다. 생성 속도는 초당 약 95~116 출력 토큰이었으므로, 60초 동안 조용히 만들 수 있는 양은 60 × 95~116 ≈ 5,700~7,000 토큰이고 이 측정의 Python 파일로는 약 600~700줄입니다. 135줄짜리 호출은 20.8초로 60초의 약 3분의 1이었고, 같은 비율이면 100줄은 20.8 × 100 ÷ 135 ≈ 15초로 60초 한도의 약 4분의 1입니다. 다만 줄 밀도는 언어와 파일마다 다르고, RCA 실험에서 100줄씩 나눈 쓰기가 3번 중 2번 실패한 이유는 밝혀지지 않았습니다. RCA 작성자는 느린 백엔드 응답을 가능성 중 하나로 들었을 뿐이므로, 100줄 이하로 나누는 것은 실패를 줄이는 방법이지 보장은 아닙니다.

이 측정에는 한계가 있습니다. Antigravity의 엔드포인트가 아니라 서드파티 게이트웨이를 거쳤고, 이 게이트웨이는 62초짜리 요청도 끊지 않았으므로 60초 타이머가 어디에 있는지는 보여 주지 못합니다. Antigravity는 Argon을 High로 돌리고 도구 호출 전에 추론을 스트리밍하므로, 무통신 구간은 요청 시작이 아니라 추론이 끝난 뒤부터 시작됩니다. 포럼에는 같은 Antigravity에서 Claude 모델은 괜찮고 제미나이만 이 오류가 난다는 보고도 있는데, 문서로 확인되는 것은 제미나이가 함수 호출 인자를 한 번에 돌려준다는 쪽뿐이고 Claude 쪽 동작은 측정하지 않았습니다.

## 사용량이 0%인가: Settings 화면과 AI Credit Overages

Reddit r/google_antigravity의 "Gemini 4 Argon 출시 이후 Model unavailable, retrying이 뜨는 사람" 글에는 "5시간 사용량이 0%로 바닥났을 때만 이게 뜬다, 사용량이 남아 있는 게 확실하냐"는 답이 위에 올라와 있습니다. 할당량 소진도 원인일 수 있으니 먼저 확인해 볼 만하지만, 사용량이 남아 있는데 큰 수정에서만 끊긴다면 할당량은 원인이 아닙니다. App이 할당량을 다 썼을 때 재시도 표시를 띄우는지는 구글 문서에 나와 있지 않습니다. 참고로 CLI는 1.3.3(2026년 10월 10일)부터 개인 할당량 도달을 재시도 없이 바로 알리도록 바뀌었습니다.

[Antigravity 요금제 문서](https://antigravity.google/docs/plans)에 따르면 Google AI Pro는 5시간마다 갱신되는 할당량이 주간 한도까지 주어지고, Ultra도 5시간마다 갱신되며, 그 밖의 요금제는 주 단위로 갱신됩니다. 구체적인 숫자는 공개되지 않았고, 한도는 에이전트가 한 작업량에 비례합니다. 모델별 사용량은 **Settings** 페이지에서 볼 수 있고(IDE 사용자의 포럼 보고에서는 Models & Usage 화면), 기본 할당량을 다 쓴 뒤의 동작은 **AI Credit Overages** 설정이 정합니다. Never는 갱신까지 기다리고, Always는 구매한 AI 크레딧을 씁니다.

요금제 자체로 Argon을 못 쓰는 경우도 있습니다. 2026년 10월 27일 기준 [Antigravity 모델 문서](https://antigravity.google/docs/models)에서 Gemini 4 Argon은 Free와 Google AI Plus에서는 쓸 수 없고, Google AI Pro는 유료 구독이거나 해당 프리미엄 기기의 체험일 때만 쓸 수 있습니다. 또 Argon은 Antigravity IDE에는 없고 Antigravity App, Antigravity CLI, IDE 확장에서만 제공됩니다. Pro에서 Claude Sonnet 5.5·Opus 5.5도 체험이 아닌 구독에서만 쓸 수 있으니, 체험 계정이라면 용량 부족 때 옮겨 갈 모델이 Gemini 3.8 Flash로 좁혀집니다.

## Argon은 Antigravity CLI로 쓰는 게 나을까

CLI가 60초 끊김을 피한다는 근거는 아직 없습니다. 포럼의 실험은 모두 App에서 이뤄졌고, CLI 변경 기록에서 확인되는 것은 재시도 방식이 다르다는 점뿐입니다. CLI 1.3.4(2026년 10월 13일)는 자동 재시도 사이 대기를 최대 4분에서 30초로 줄였고, 1.3.6(10월 15일)은 5분 동안 데이터가 오지 않으면 요청을 취소하고 다시 보냅니다. 기다리는 시간은 짧아질 수 있지만, 같은 큰 요청이 같은 이유로 끊긴다면 결과는 달라지지 않습니다.

Argon을 다른 에이전트 도구에 물려 쓰는 방법을 생각한다면 경계가 분명합니다. Antigravity FAQ는 `agy`를 서드파티 에이전트로 감싸거나 계정 전환을 자동화하는 것을 개인 요금제에서 지원하지 않으며, 서드파티 코딩 에이전트에서 제미나이를 쓰려면 Gemini Enterprise나 Google AI Studio API 키를 권한다고 밝힙니다.

## 구글은 고쳤나: 2026년 10월 27일 기준 App 2.26.0까지

2026년 10월 27일 기준으로 구글이 이 60초 끊김을 고쳤다는 기록은 없습니다. App 2.23.1(10월 13일), 2.24.0(10월 15일), 2.25.0(10월 20일), 2.26.0(10월 22일)의 변경 기록에는 도구 호출 인자 스트리밍, 연결 유지 신호, 60초 제한에 관한 항목이 없습니다. 2.26.0에 들어간 "절전 해제나 Wi-Fi 변경 뒤 소켓 끊김에 자동 재시도" 수정은 다른 문제입니다.

RCA 스레드의 첫 답변은 2.23.1로 올려 보라는 것이었지만, RCA 작성자의 재시험에서는 2.23.1(10월 15일)에서 1,200줄과 1,400줄 한 번 쓰기가 60.18~60.37초에, 2.25.0(10월 22일)에서 1,200줄 쓰기 3번이 60.21~60.38초에 끊겨 파일이 하나도 써지지 않았습니다. 2.26.0에서 다시 시험한 결과는 2026년 10월 27일 기준 포럼 스레드에 아직 없습니다. 새 버전은 며칠에 걸쳐 순차 배포되므로 업데이트는 해 두되, 업데이트만으로 큰 수정이 통과할 것이라고 기대하지는 않는 편이 안전합니다.

## 제미나이 API로 직접 만든 에이전트: streamFunctionCallArguments

Antigravity가 아니라 제미나이 API로 직접 에이전트를 만들고 있다면, RCA 작성자가 구글에 요청한 기능을 직접 켜 볼 수 있습니다. [Vertex AI 함수 호출 문서](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/function-calling)에 따르면 `streamGenerateContent`에서 `toolConfig.functionCallingConfig` 안의 `streamFunctionCallArguments`를 `true`로 두면 인자가 생성되는 대로 `partialArgs`와 `willContinue`가 담긴 중간 응답으로 흘러옵니다. 프리뷰 기능이고 Gemini 3 이후 모델이 대상입니다(Gemini 3.1 Flash-Lite 제외). Antigravity 사용자는 이 옵션을 켤 수 없습니다.

위의 2026년 10월 27일 측정에서는 이 값을 넣어도 오류 없이 200이 돌아왔지만 59.8초에 한 번에 도착해 차이가 없었습니다. 게이트웨이가 이 필드를 전달하는지는 알 수 없으므로, 효과를 보려면 Vertex AI에서 직접 확인해야 합니다. 직접 짠 코드에서 같은 요청을 다시 보낼지 다른 모델로 넘길지는 [LLM API 재시도 vs 폴백: 모델을 바꾸기 전 5가지 기준](https://blog.laozhang.ai/ko/posts/llm-api-retry-vs-fallback-model)에서 다룹니다.

## 내 로그 확인과 구글 신고 체크리스트

내 실패가 60초 끊김인지는 RCA 작성자가 공개한 `reconstruct_attempts.py`로 `language_server.log`를 읽어 보면 알 수 있습니다. 2026년 10월 27일 macOS 26.1·Python 3.12.1에서 작성자의 공개 로그에 이 스크립트를 다시 돌려 보니 21번의 실행에서 136번의 실패가 나왔고, 그중 응답 헤더 없이 끊긴 실패는 104번, 시간이 기록된 79번의 중앙값은 60.352초(최소 60.270초, 최대 61.075초)였습니다. 출력은 작성자가 공개한 CSV와 완전히 같았습니다. 다만 README의 `--utc-offset -04:00`처럼 음수 오프셋을 띄어 쓰면 "expected one argument" 오류가 나고, `=`로 붙여 써야 동작합니다.

```bash
python3 scripts/reconstruct_attempts.py ~/.config/Antigravity/logs/language_server.log \
  --utc-offset=+09:00 --year 2026 > failed-attempts.csv
```

`--utc-offset`은 로그에 찍힌 현지 시각의 오프셋이므로 한국 시간대라면 `+09:00`입니다. 위 경로는 Linux 기준이고, macOS와 Windows에서의 로그 위치는 직접 확인하지 못했습니다. 결과 요약에서 `no response headers` 실패가 60초 바로 위에 몰려 있으면 같은 끊김입니다.

구글에 알릴 때는 Google AI 개발자 포럼의 Google Antigravity 카테고리에 올리고 아래 항목을 붙입니다. 앞의 다섯 가지는 RCA 작성자가 서버 쪽에서 찾아볼 수 있도록 붙인 항목입니다. 마지막 항목은 RCA 작성자의 목록에 없는 추가 제안으로, 크기가 원인인지 가리는 데 도움이 됩니다.

- [ ] 실패마다의 발생 시각(UTC)
- [ ] 로그에 있는 ResponseID와 Trace ID (응답이 시작되지 않은 실패에는 없음)
- [ ] Antigravity 클라이언트 버전과 OS
- [ ] 모델과 사고 수준 (예: Gemini 4 Argon, High)
- [ ] 작업 내용 (예: "1,200줄 파일을 `write_to_file` 한 번으로 생성")
- [ ] 줄 범위로 나눴을 때의 결과

## 참고 자료

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

- [Antigravity 변경 기록](https://antigravity.google/docs/changelog) (antigravity.google)
- [포럼의 2.23.0 재시도 루프 분석 글](https://discuss.ai.google.dev/t/189559) (discuss.ai.google.dev)
- [Windows 사용자의 Retrying (1/9) 보고](https://discuss.ai.google.dev/t/189747) (discuss.ai.google.dev)
- [포럼 186207](https://discuss.ai.google.dev/t/186207) (discuss.ai.google.dev)
- [포럼 195034](https://discuss.ai.google.dev/t/195034) (discuss.ai.google.dev)
- [포럼 186367](https://discuss.ai.google.dev/t/186367) (discuss.ai.google.dev)
- [Antigravity FAQ](https://antigravity.google/docs/faq) (antigravity.google)
- [antigravity-stream-cutoff-rca 저장소](https://github.com/Xiphiros/antigravity-stream-cutoff-rca) (github.com)
- [Antigravity 요금제 문서](https://antigravity.google/docs/plans) (antigravity.google)
- [Antigravity 모델 문서](https://antigravity.google/docs/models) (antigravity.google)
- [Vertex AI 함수 호출 문서](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/multimodal/function-calling) (docs.cloud.google.com)