Antigravity에서 채팅이 아무 응답 없이 실패할 때: Silent Fail 원인과 해결기

 

문제 해결 과정을 정리해서 ChatGPT로 다듬은 글입니다.

---

원격 서버에서 Antigravity를 사용하다가 꽤 난감한 문제를 겪었다.

채팅을 입력하면 잠깐 로딩이 돌다가 아무 응답도 없이 끝난다. 에러 메시지도 없고, 경고창도 없고, 실패했다는 표시도 없다. 그냥 빈 응답처럼 처리되고 새 입력창만 다시 나타난다.

로컬에서는 잘 되는데, 원격 서버에서만 안 된다.
프로젝트를 바꿔도 안 되고, 모델을 바꿔도 안 되고, 계정이나 구독 문제도 아니었다.

결론부터 말하면 원인은 오래 살아남은 구버전 language_server 프로세스들이 inotify watch 리소스를 점유하고 있었기 때문이었다.

해결은 의외로 간단했다.

pkill -f "1.19.4.*language_server_linux_x64"

이후 VS Code에서 Developer: Reload Window를 실행하자 Antigravity 채팅이 바로 정상 동작했다.

---

문제 상황

환경은 다음과 같았다.

항목내용

서버	Docker 컨테이너 기반 원격 GPU 서버
OS	Linux
RAM	약 503GB
접속 방식	로컬 Mac → SSH Remote → Antigravity
IDE	Antigravity, VS Code 기반
모델	Gemini 3.1 Pro High
구독	Gemini Ultra

증상은 다음과 같았다.

• Antigravity 채팅 입력 후 엔터를 치면 잠깐 로딩만 됨
• 아무 응답 없이 새 입력창으로 넘어감
• Undo도 작동하지 않음
• 빈 채팅 이력만 계속 쌓임
• 모든 워크스페이스에서 동일하게 실패
• 같은 계정으로 로컬에서는 정상 작동

즉, UI상으로는 실패했다는 단서가 전혀 없었다.

이런 유형의 문제는 흔히 Silent Fail이라고 부를 수 있다.
내부에서는 실패했지만, 사용자에게는 아무 오류도 보여주지 않는 상태다.

---

1차 점검: 디스크, 메모리, 네트워크는 정상

먼저 서버 상태부터 확인했다.

df -h /
free -h
curl -s -o /dev/null -w '%{http_code}' https://generativelanguage.googleapis.com
curl -s -o /dev/null -w '%{http_code}' https://oauth2.googleapis.com

결과는 모두 정상이었다.

• 디스크 여유 공간 충분
• 메모리 여유 공간 충분
• Google API 엔드포인트 연결 가능
• 인증 서버 연결 가능

서버 자체가 죽어 있거나, 네트워크가 막혀 있거나, 메모리가 부족한 문제는 아니었다.

---

이상한 프로세스 발견

다음으로 Antigravity의 핵심 백엔드인 language_server 프로세스를 확인했다.

ps aux | grep language_server_linux | grep -v grep

그런데 이상한 프로세스들이 남아 있었다.

PID      버전      시작일
996710   1.23.2    오늘        ← 현재 세션
1424328  1.19.4    2월 26일    ← 오래된 프로세스
1424734  1.19.4    2월 26일    ← 오래된 프로세스
1562953  1.19.4    2월 26일    ← 오래된 프로세스
1836471  1.19.4    2월 27일    ← 오래된 프로세스
1837681  1.19.4    2월 27일    ← 오래된 프로세스

현재 세션의 language server는 v1.23.2였지만, 2월 말부터 살아 있던 구버전 v1.19.4 프로세스가 5개나 남아 있었다.

이 프로세스들은 사실상 이전 IDE 세션이 제대로 종료되지 않으면서 남은 찌꺼기였다.

다만 여기서 의문이 생겼다.

이 프로세스들이 2월부터 남아 있었다면, 왜 문제는 며칠 전부터 발생했을까?

단순히 오래된 프로세스가 있다는 것만으로는 설명이 부족했다.

---

실제 로그 확인: too many open files

결정적인 단서는 Antigravity 로그에 있었다.

cat ~/.antigravity-server/data/logs/20260503T080703/exthost8/google.antigravity/Antigravity.log | tail -40

로그에는 다음과 같은 에러가 반복되고 있었다.

Unable to start git event watcher for workspace:
failed to create git event watcher: too many open files

LanguageServerService/WatchDirectory:
failed to create watcher: too many open files

핵심은 이 부분이다.

failed to create watcher: too many open files

Antigravity의 language server가 파일 watcher를 만들지 못하고 있었다.

즉, 서버와 모델 호출 자체가 문제라기보다는, IDE가 워크스페이스 파일을 감시하고 인덱싱하는 단계에서 실패하고 있었다.

---

왜 파일 watcher가 필요한가?

Antigravity 같은 AI 코딩 어시스턴트는 단순히 채팅창만 띄우는 도구가 아니다.

사용자가 다음과 같이 요청한다고 해보자.

이 함수 리팩토링해줘.
이 에러 원인 찾아줘.
이 프로젝트 구조 보고 수정 방향 알려줘.

이런 요청에 답하려면 AI 도구는 현재 프로젝트의 파일 구조, Git 상태, 관련 코드, import 관계, 최근 변경 사항 등을 알아야 한다.

이를 위해 language server는 프로젝트 디렉토리를 감시한다.

예를 들어 다음과 같은 것들을 추적한다.

목적설명

파일 변경 감지	외부 도구나 git pull로 파일이 바뀌면 즉시 반영
Git 상태 추적	branch, diff, staged 상태 등을 추적
코드 인덱싱	새 파일 생성, 삭제, 이동을 반영
컨텍스트 구성	채팅 요청 시 관련 파일을 찾아 LLM에 전달

이 파일 감시가 실패하면, Antigravity는 코드베이스 컨텍스트를 제대로 구성하지 못한다.

결과적으로 채팅 요청도 내부적으로 실패할 수 있다.

---

근본 원인: inotify watch 한도 초과

Linux에서는 파일 변경 감지를 위해 주로 inotify라는 커널 기능을 사용한다.

inotify는 특정 파일이나 디렉토리에 변화가 생겼을 때 프로세스에 이벤트를 알려주는 시스템이다.

문제는 이 리소스가 무한하지 않다는 점이다.

확인해보면 다음과 같은 제한이 있다.

cat /proc/sys/fs/inotify/max_user_instances
cat /proc/sys/fs/inotify/max_user_watches
ulimit -n

이번 환경에서는 특히 max_user_watches가 중요했다.

cat /proc/sys/fs/inotify/max_user_watches
# 65,536

즉, 한 사용자 UID가 등록할 수 있는 inotify watch 수가 65,536개로 제한되어 있었다.

 

그런데 /workspace 아래 디렉토리 수를 세어보니 다음과 같았다.

find /workspace -type d | wc -l
# 491,694

약 49만 개의 디렉토리가 있었다.

항목값

/workspace 하위 디렉토리 수	491,694개
inotify watch 제한	65,536개
부족분	약 42만 개

VS Code나 language server는 디렉토리 단위로 watcher를 등록한다.
그런데 감시해야 할 디렉토리 수가 커널 제한보다 훨씬 많았던 것이다.

여기에 오래된 language server 프로세스들이 이미 일부 watch 리소스를 점유하고 있었다.
그래서 새 세션의 language server는 watcher를 생성하지 못했고, 로그에는 too many open files가 반복적으로 남았다.

---

Docker 컨테이너라 더 곤란했던 점

일반적인 Linux 서버라면 다음처럼 inotify 제한을 늘릴 수 있다.

sudo sysctl fs.inotify.max_user_watches=524288

또는 직접 /proc/sys 값을 수정할 수도 있다.

echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches

하지만 이번 환경은 Docker 컨테이너였다.

 

컨테이너 내부에서는 /proc/sys가 read-only로 마운트되어 있어서 다음과 같이 실패했다.

tee: /proc/sys/fs/inotify/max_user_watches: Read-only file system

즉, 컨테이너 안에서는 커널 파라미터를 직접 바꿀 수 없었다.

이 값을 바꾸려면 호스트 OS에서 수정하거나, 컨테이너를 privileged 모드로 실행해야 한다.
하지만 클라우드 GPU 서버나 관리형 환경에서는 호스트 접근 권한이 없는 경우가 많다.

따라서 이 상황에서는 inotify 제한을 늘리는 방식이 현실적인 해결책이 아니었다.

---

해결: 오래된 language_server 프로세스 정리

결국 실질적인 해결책은 기존에 리소스를 점유하고 있던 구버전 language server 프로세스를 종료하는 것이었다.

pkill -f "1.19.4.*language_server_linux_x64"

이 명령으로 2월부터 살아 있던 v1.19.4 language server 프로세스 5개를 종료했다.

 

이후 VS Code에서 다음 명령을 실행했다.

Developer: Reload Window

그러자 Antigravity 채팅이 즉시 정상 동작했다.

---

Silent Fail이 발생한 흐름

이번 문제의 전체 흐름은 대략 다음과 같다.

사용자가 Antigravity 채팅 입력
        ↓
Antigravity Extension이 language server에 요청
        ↓
language server가 워크스페이스 파일 감시 시도
        ↓
inotify watch 한도 초과
        ↓
WatchDirectory 실패
        ↓
파일 컨텍스트 구성 실패
        ↓
채팅 요청 내부 실패
        ↓
UI에는 빈 응답처럼 표시

중요한 점은, 이 실패가 사용자 UI로 명확히 전달되지 않았다는 것이다.

로그에는 에러가 계속 찍히고 있었지만, 채팅창에는 아무 에러도 표시되지 않았다.
그래서 겉보기에는 모델이 응답하지 않는 것처럼 보였다.

하지만 실제 원인은 모델이나 구독 문제가 아니라, 원격 서버의 파일 감시 리소스 문제였다.

---

재발 방지를 위한 점검 명령어

원격 서버에서 Antigravity나 VS Code Remote를 오래 사용하는 경우, 주기적으로 다음을 확인해보는 것이 좋다.

1. 오래된 language server 확인

ps aux | grep language_server_linux | grep -v grep

현재 세션과 무관한 오래된 프로세스가 남아 있다면 정리 대상일 수 있다.

2. inotify watch 제한 확인

cat /proc/sys/fs/inotify/max_user_watches

3. 워크스페이스 디렉토리 수 확인

find /workspace -type d | wc -l

디렉토리 수가 max_user_watches보다 훨씬 많다면, IDE나 language server가 파일 watcher 생성에 실패할 가능성이 높다.

4. Antigravity 로그 확인

tail -f ~/.antigravity-server/data/logs/*/exthost*/google.antigravity/Antigravity.log

다음과 같은 메시지가 보이면 inotify 또는 fd 관련 문제를 의심할 수 있다.

too many open files
failed to create watcher
Unable to start git event watcher
WatchDirectory

---

정리

이번 문제는 겉으로 보기에는 Antigravity 채팅이 갑자기 먹통이 된 문제였다.

하지만 실제 원인은 다음 두 가지가 겹친 것이었다.

1. /workspace 아래 디렉토리가 약 49만 개로 너무 많았다.
2. 오래된 language server 프로세스들이 inotify watch 리소스를 계속 점유하고 있었다.

결과적으로 새 language server가 파일 watcher를 만들지 못했고, Antigravity 채팅은 내부적으로 실패했다.
하지만 UI에는 에러가 표시되지 않아 Silent Fail처럼 보였다.

최종 해결 방법은 다음과 같았다.

pkill -f "1.19.4.*language_server_linux_x64"

그리고 VS Code에서 창을 다시 로드했다.

Developer: Reload Window

---

결론

Antigravity나 VS Code Remote 계열 IDE에서 다음과 같은 증상이 나타난다면,

• 채팅이 아무 응답 없이 끝남
• 로컬에서는 정상인데 원격 서버에서만 실패함
• 프로젝트를 바꿔도 동일하게 실패함
• 로그에 too many open files 또는 failed to create watcher가 보임

모델, 계정, 네트워크보다 먼저 language server 프로세스와 inotify watch 제한을 확인해보는 것이 좋다.

특히 Docker 컨테이너 기반 원격 서버를 장기간 재시작 없이 사용한다면, IDE 관련 백그라운드 프로세스가 누적될 수 있다.

이번 경우처럼 단순히 오래된 프로세스를 정리하는 것만으로도 문제가 바로 해결될 수 있다.