ENOSPC file watchers는 디스크가 가득 찬 줄이 아니라 리눅스 inotify 감시 개수를 개발 서버가 다 쓴 줄입니다. node_modules ignored, sysctl 한도, 맥과 우분투 CI. Next.js, 웹팩, 한국 1인 개발자 기준. 2026년 9월 Next.js ENOSPC·inotify 문서.
ENOSPC: System limit for number of file watchers는 디스크가 가득 찬 줄이 아니라, 리눅스가 허용한 inotify 감시 개수를 넥스트 개발 서버가 다 써서 파일 감시를 못 붙인 줄입니다. 그래서 용량부터 비우면 같은 줄이 다시 납니다.
맥에선 되고 우분투 깃허브 액션이나 개발용 컨테이너만 감시가 멈추는 일, 한국에서 넥스트를 혼자 붙이다 보면 한 번은 만납니다. 힙 부족으로 빌드가 죽는 줄과도 칸이 다릅니다.
워처 한도를 보기 전에 node_modules를 감시 목록에서 빼는 편이 먼저입니다. 근거는 Next.js ENOSPC 문서와 inotify 매뉴얼에 있습니다.
같은 ENOSPC라도 메시지 나머지를 읽어야 합니다. no space left on device는 블록이 없는 줄이고, file watchers는 감시 슬롯이 없는 줄입니다. 넥스트 공식 메시지는 후자를 리눅스 inotify 한도로 설명합니다.
개발 서버는 소스 파일이 바뀌는지 보려고 폴더마다 감시를 붙입니다. 여러 패키지가 한 저장소에 있고 의존성 폴더까지 들어가면 기본 한도를 금방 넘습니다. 맥의 파일 알림은 그 한도가 달라 같은 저장소가 맥에선 돕니다. 리눅스만 멈추면 용량 청소보다 감시 개수를 먼저 세는 편이 맞습니다.
힙이 부족해 빌드가 죽는 줄은 heap out of memory입니다. 모듈을 못 찾는 줄은 Cannot find module입니다. 워처가 죽으면 핫리로드만 멈추고, 이미 뜬 화면은 살아 있을 수 있습니다.
메시지 뒷부분 | no space left on device면 df -h로 용량을 보고, number of file watchers면 sysctl inotify를 보세요. 같은 코드 네 글자에 칸이 둘입니다.
한도와 현재 사용, 무시 목록 세 칸이면 원인이 갈립니다.
| 칸 | 증상 | 먼저 할 일 |
|---|---|---|
| 한도 자체 | 작은 앱도 리눅스만 실패 | fs.inotify.max_user_watches 읽기 |
| node_modules 감시 | 의존성 설치 뒤부터 실패 | watchOptions ignored, webpack watch |
| 여러 개발 서버 | 두 번째 프로젝트부터 실패 | 띄운 next dev 개수, 에디터 감시 |
| 디스크 가득 | 메시지에 device | df -h, 이 글이 아님 |
| EMFILE | 열린 파일 수 한도 | ulimit -n, 워처와 다른 칸 |
VS Code와 넥스트와 스토리북을 같이 띄우면 감시를 세 벌 씁니다. 한국에서 노트북 하나로 여러 사이트를 돌리는 1인이면 한도를 올리기 전에 창 개수부터 줄이는 게 빠릅니다. 포트가 겹쳐 서버가 안 뜨는 줄은 EADDRINUSE입니다.
워처 한도와 현재 값 보기cat /proc/sys/fs/inotify/max_user_watches # 흔한 기본값: 8192 # 임시로 올리기 (재부팅 시 초기화) sudo sysctl fs.inotify.max_user_watches=524288 # 유지하려면 # echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
한도만 올리면 다음 모노레포에서 다시 찹니다. 넥스트와 웹팩은 node_modules, .git, .next를 감시하지 않게 둘 수 있습니다. 공식 ENOSPC 문서도 한도 상향과 함께 감시 범위를 줄이라고 안내합니다.
컨테이너 안 개발은 호스트 sysctl이 필요합니다. 컨테이너만 올리면 권한이 거절됩니다. 도커 데스크톱 맥은 리눅스 VM의 inotify라, 맥 본체가 아니라 VM 한도입니다. 깃허브 액션 우분투 러너는 기본 한도가 낮아, 테스트에서 워치를 켜면 같은 줄이 납니다.
스크립트 실패로만 보이면 ELIFECYCLE이 겉을 감싼 겁니다. 안쪽 첫 줄이 ENOSPC watchers인지 읽으세요. 설치 트리 충돌은 ERESOLVE입니다.
next.config.js 감시 범위 줄이기/** @type {import('next').NextConfig} */ const nextConfig = { webpack: (config, { dev }) => { if (dev) { config.watchOptions = { ignored: ['**/node_modules/**', '**/.git/**', '**/.next/**'], } } return config }, } module.exports = nextConfig
자동 검사에서 개발 서버를 띄울 일이 있으면 감시를 끄세요. 배포용 빌드는 감시가 필요 없습니다. 개발 서버를 액션에서 돌리는 화면 시험만 이 줄을 만납니다. 한도를 올리는 칸을 워크플로에 넣거나, 자동 검사에서는 주기 확인을 씁니다.
WSL2도 리눅스 한도를 따릅니다. 윈도우 쪽 디스크를 마운트해 감시하면 더 빨리 찹니다. 프로젝트는 WSL 홈 쪽에 두는 편이 낫습니다. EMFILE은 열린 파일 디스크립터 한도라 ulimit -n이고, 워처 한도와 함께 올라가는 경우가 많습니다.
카카오 콜백을 로컬에서 시험하려고 여러 넥스트를 띄운 창이 원인일 때도 있습니다. 3000, 3001을 동시에 감시하면 슬롯이 두 배입니다. 포트 충돌과 워처 한도를 한 증상으로 묶지 마세요.
| 메시지 | 부족한 것 | 도구 |
|---|---|---|
| ENOSPC watchers | inotify 슬롯 | sysctl, ignored |
| ENOSPC device | 디스크 블록 | df -h |
| EMFILE | 열린 파일 수 | ulimit -n |
| heap out of memory | 노드 힙 | NODE_OPTIONS |
CI에서 next dev를 끄기 | 빌드 잡에 개발 서버가 필요 없습니다. 워치를 켜야 하는 잡만 한도 스텝을 넣고, 그 외에는 build와 start로 나눕니다.
메시지 뒷부분을 읽고, watchers면 한도 값을 찍습니다. 개발 서버와 에디터를 하나만 남기고 재현합니다. 그래도 나면 ignored를 넣고, 마지막에 sysctl을 올립니다. 디스크 용량 청소는 device 메시지일 때만입니다.
컨테이너면 호스트에서 sysctl을 올립니다. 액션이면 워치를 끄거나 한도 스텝을 넣습니다. 맥만 쓰는 환경에서 이 줄이 나면, 실제로는 도커 VM이거나 원격 리눅스입니다.
고친 뒤에도 저장 반영이 안 되면 감시가 붙지 않은 겁니다. 한 번 저장이 화면에 나타나는지 보고, 안 되면 서버를 재시작합니다. 모듈 해석 실패와 섞이면 감시가 아니라 실행 위치입니다. 한국에서 우분투 컨테이너로만 재현되면, 맥 본체를 의심하지 말고 그 리눅스 한도를 보세요.
내부 연계: 힙 메모리, 모듈을 찾을 수 없음, 포트 점유, ELIFECYCLE, EACCES
인용한 동작은 2026년 9월 공개 문서 기준입니다.
메시지에 file watchers가 있으면 용량이 아닙니다. inotify 슬롯을 다 쓴 줄입니다. df -h가 초록이어도 워처 한도는 따로입니다.
맥은 FSEvents라 한도 계산이 다릅니다. 컨테이너는 호스트 inotify를 씁니다. 호스트에서 sysctl을 올리고, 컨테이너 안에서만 올리지 마세요.
sysctl 임시 값은 재부팅에 사라집니다. /etc/sysctl.conf 또는 sysctl.d에 남겨야 유지됩니다. ignored를 먼저 넣으면 한도에 덜 기대게 됩니다.
next build는 워처가 필요 없습니다. 액션에서 next dev를 띄운 잡인지 보세요. 빌드 잡이면 개발 서버를 빼는 쪽이 맞습니다.
열린 파일 수 한도입니다. ulimit -n을 올리고, 워처 ignored도 같이 넣습니다. 둘 다 파일을 많이 여는 증상이나 커널 칸이 다릅니다.
워처가 죽은 뒤에도 프로세스는 살아 있을 수 있습니다. 콘솔 첫 ENOSPC를 찾고, 서버를 재시작한 뒤 ignored와 한도를 적용하세요. 핫리로드만 죽은 상태입니다.
