Claude Code 의 리소스 블랙홀: 11.3MB 단일 파일 패키징에서 1.2TB 디스크 소모까지

Claude Code 의 클라이언트는 리소스 수명 관리가 전혀 없는 Node.js 단일 파일 애플리케이션이다: 시작 시 11.3MB 패키지 파일을 파싱하고, 실행 중 디스크에 무제한으로 기록하며, 터미널을 닫아도 프로세스가 살아남아 메모리를 지속적으로 소모해 시스템이 붕괴될 때까지 지속된다. GitHub Issues 에서 실제 사용자 보고와 커뮤니티 역분석을 기반으로, 본문에서는 메모리, CPU, 디스크 세 차원에서의 리소스 관리 결함을 체계적으로 정리하고, 패키징 아키텍처, 저장 설계 및 프로세스 수명 관리의 구조적 문제를 밝힌다. 이는 주변 사례가 아니라 2025년 8월부터 2026년 4월까지 커뮤니티가 지속적으로 보고했으며, stale 로봇에 의해 대량 폐쇄된 시스템적 아키텍처 결함이다.

패키징 아키텍처: 11.3MB 단일 파일의 대가

Claude Code 의 핵심은 cli.js 라는 이름의 단일 파일 패키지 산물이며, 크기는 약 11.3MB이다. 커뮤니티 사용자 paultendo 가 Issue #29481 에서 상세한 정적 분석을 수행해 여러 심각한 아키텍처 문제를 밝혀냈다.

V8 시작 시간: 32% 가 파싱에 사용

CPU 프로파일링 결과 compileSourceTextModule 이 시작 단계 샘플 시간의 31.7% 를 차지한다. V8 엔진은 이 11.3MB 단일 파일을 파싱하는 데 약 300ms 가 필요하지만, 일반 Node.js 스크립트는 23ms 만에 파싱한다. 추가로 7.3% 가 spawnSync 호출에, 3.5% 가 가비지 컬렉션에 소비된다. 이는 사용자가 명령을 입력하기 전에 이미 40% 이상의 시작 시간이 순수 파싱 비용에 낭비된다는 의미다.

전체 로드: 단 20개의 동적 import

전체 패키지 파일이 시작 시 완전히 파싱·실행되며, 오직 20개의 import() 표현식만 존재한다. 모든 기능에 대해 비용을 지불하게 되며, 사용 여부와 관계없이 로드된다. 아래는 필요에 따라 로드되어야 할 것이 전체 패키징된 구성 요소이다:

pie title 패키지 파일 구성 (약 13.5MB)
    "애플리케이션 핵심 로직" : 7540
    "AWS Bedrock SDK" : 1100
    "highlight.js (182 언어)" : 1000
    "OpenTelemetry" : 900
    "Google Vertex + gRPC + Protobuf" : 800
    "RxJS" : 300
    "기타 (Ink, Zod, Ajv, Axios 등)" : 1807

코딩 도우미는 Brainfuck, MIPS assembly, Flix, Zephir, Inform7, Lasso 등 182개의 언어를 하이라이트해야 하며, 이는 패키징 전략이 얼마나 거친지를 보여준다. 약 40개의 일반적인 언어만 남겨두어도 약 786KB 의 파싱 비용을 절감할 수 있다.

의존성 중복: 네 개의 HTTP 클라이언트, 세 개의 검증 라이브러리

각 SDK 가 독립적인 의존성을 도입해 패키지 파일에 네 개의 HTTP 클라이언트(Axios, Undici, Got, 네이티브 fetch)와 세 개의 검증 라이브러리(Zod, Ajv, JSON Schema)가 동시에 존재한다. Node 18+ 환경에서는 네이티브 fetch 가 완전히 사용 가능하므로 추가 HTTP 클라이언트가 전혀 필요하지 않다.

413개의 동기 파일 시스템 호출

패키지 파일에는 existsSync 196개, statSync 109개, readFileSync 108개, mkdirSync 58개 등 총 413개의 동기 파일 시스템 호출이 포함되어 있다. 각각은 이벤트 루프를 차단한다. 많은 호출이 existsSync(path) && readFileSync(path) 형태로 이루어져 있어, 하나의 try { await readFile(path) } catch {} 로 대체될 수 있다.

1087개의 CJS/ESM 상호 운용 래퍼

ESM 으로 패키징된 각 CommonJS 모듈은 __toESM/__commonJS/__require 호환성 패치를 생성하며, 총 1087개가 존재한다. 이 패치는 파싱 무게를 늘리고 각 모듈마다 미세한 런타임 오버헤드를 초래한다.

불필요한 Node 20 폴리필

패키지 파일에는 62개의 Promise 폴리필(Node 0.12 부터 네이티브 지원), 57개의 Symbol 폴리필(Node 4 부터 네이티브 지원), 57개의 async 변환 헬퍼(Node 8 부터 네이티브 지원), 그리고 3개의 AbortController 폴리필(Node 15 부터 네이티브 지원)이 포함되어 있다. 이는 구버전 Node 혹은 브라우저 환경을 위해 컴파일된 전이 의존성으로, 대상 런타임에서는 완전히 불필요하다.

ripgrep 전체 6개 플랫폼 바이너리 패키징: 61MB

ripgrep 의 6개 플랫폼 바이너리가 모두 패키징되어 총 61MB 를 차지한다. 반면 sharp 은 optional dependencies 를 올바르게 사용해 현재 플랫폼의 바이너리만 설치한다. 이는 각 설치마다 약 51MB 의 디스크 공간이 낭비된다는 의미다.

Ink 렌더링 성능이 대화 길이에 따라 악화

터미널 UI 는 Ink (React for Terminal)를 사용한다. 분석 결과 컴포넌트 트리에는 createElement 호출이 6457개, useState 훅이 578개 존재하지만, React.memo() 로 감싼 컴포넌트는 11개에 불과해 비율이 1.9% 에 불과하다. Ink 에서는 상태 업데이트마다 전체 가상 DOM 조정이 발생한다. 스트리밍 응답 중에 도착하는 각 토큰이 상태 업데이트를 트리거해 memo 되지 않은 컴포넌트가 불필요하게 다시 렌더링된다. 대화가 길어질수록 렌더링 출력이 증가하고, 매 재렌더링마다 더 많은 터미널 내용이 diff 된다. 이는 Issue #22265 에서 보고된 “세션 진행 중 점점 느려짐” 현상과 일치한다.

디스크 소모: GB 에서 TB 로의 무제한 성장

디스크 문제는 Claude Code 의 가장 심각한 리소스 관리 결함이며, 영향 범위가 가장 넓고 결과가 가장 치명적이다.

Windows .node 네이티브 모듈 누수: 주당 20GB

Issue #23095 에서는 수개월 동안 해결되지 않은 문제가 기록되어 있다: Claude Code 의 Windows 네이티브 바이너리(claude.exe) 가 각 세션마다 시스템 임시 디렉터리에 네이티브 Node.js 플러그인 파일을 추출하지만 절대 정리하지 않는다. 각 파일은 약 6.6MB이며, 사용자 SlothKing16 은 4일 동안 2813개의 파일을 누적해 18GB 를 차지했다. 사용자 kolkov 의 통계는 더 충격적이다: 주당 약 20GB, 고빈도 사용자는 주당 100GB 까지 소모한다. 이 문제는 2025년 초부터 보고돼 왔으며, 로봇에 의해 여러 차례 중복으로 표시돼 폐쇄되었다.

~/.claude 디렉터리: 3GB+ 관리 부재

사용자 kolkov 은 Issue #5024 에서 8개월 동안 일상적으로 사용한 머신을 감사했다:

pie title ~/.claude 디렉터리 사용량 (약 3.1GB)
    "projects/ (세션 기록)" : 2500
    "debug/ (디버그 로그)" : 303
    "file-history/ (파일 스냅샷)" : 232
    "history.jsonl (전체 히스토리)" : 10
    "기타" : 55

핵심 수치: 최대 단일 세션 JSONL 파일 203MB, 최대 서브 에이전트 JSONL 파일 72MB, history.jsonl 은 37000+ 항목을 포함한다. 모든 데이터는 순환되지도, 압축되지도, 정리 메커니즘도 없다. file-history/ 의 파일 스냅샷은 중복 제거되지 않으며, 동일 파일을 10번 편집하면 10개의 완전 복사본이 저장된다. debug/ 디렉터리의 디버그 로그는 절대 정리되지 않는다.

백그라운드 작업 출력 파일: 1.2TB 자기 참조 무한 루프

Issue #32282 은 믿기 어려운 설계 결함을 드러낸다. Claude Code 가 여러 백그라운드 에이전트를 시작하고 자동으로 진행 상황을 확인하는 bash 명령을 실행하면, 해당 명령의 출력 파일이 glob 으로 매칭되는 동일 디렉터리에 쓰여 자기 자신을 무한히 피드백하는 루프가 형성된다:

flowchart LR
    A["bash: for f in tasks/*.output; tail -5 $f"] --> B["출력 쓰기 tasks/task-A.output"]
    B --> C["glob 이 task-A.output 자체를 매칭"]
    C --> D["tail -5 로 자체 출력 읽기"]
    D --> E["자체에 추가 쓰기"]
    E --> C

여러 사용자가 동일 문제를 보고했으며, 1.2TB, 460GB, 303GB, 235GB, 480GB, 36GB 가 보고되었다. 해당 이슈의 댓글자는 관련된 70개의 오픈 이슈를 15그룹으로 나누었으며, 앞 두 그룹만 해도 약 9.5TB 의 디스크 소비를 보고했다. 쓰기 속도는 초당 425MB 에 달하며, 18분 동안 지속돼 디스크가 고갈될 때까지 진행된다.

연쇄 실패: 디스크가 가득 찬 후 복구 불가 붕괴

Issue #24207 은 디스크가 가득 찼을 때 발생하는 재앙적인 연쇄 반응을 설명한다:

flowchart TD
    A["디스크 공간 = 0"] --> B[".claude.json 쓰기 실패"]
    B --> C["0바이트 파일 생성"]
    C --> D["잘못된 JSON 으로 읽힘"]
    D --> E["모든 프로젝트 설정 덮어쓰기"]
    E --> F["OAuth/API 토큰 손상"]
    F --> G["재인증 필요"]
    G --> H["모든 실행 중인 에이전트/세션 중단"]
    H --> I["디스크 공간을 해제해도 복구 불가"]

경고도, 우아한 다운그레이드도, 복구 경로도 없다. 사용자는 모든 프로세스를 수동으로 종료하고, 디스크 공간을 해제하고, 설정을 복구하고, 재인증하고, 모든 설정을 다시 구성해야 한다.

동시 쓰기: 락도, 트랜잭션도, 조정도 없음

~/.claude/ 디렉터리에서 유일한 락 파일은 .update.lock (5바이트) 뿐이다. 다른 모든 파일 쓰기에는 보호가 없다. 여러 Claude Code 프로세스가 동시에 실행될 때(에이전트 + 서브 에이전트는 정상 사용 시나리오) 공유 파일에 대한 쓰기 조정이 전혀 이루어지지 않는다:

Windows 환경에서는 원자적 쓰기 우회(먼저 .tmp 로 쓰고 rename()) 가 실패한다. 대상 파일이 다른 프로세스에 의해 점유되면 rename() 이 EPERM 을 반환해 원자성이 완전히 깨진다.

메모리와 CPU: 13GB RSS 에서 커널 패닉까지

Windows 극단적 메모리 소비

Issue #24840 은 Windows 에서의 극단적인 사례를 기록한다: RSS 13.21GB, 가상 메모리 커밋 47.17GB, 전체 시스템 메모리는 42.56GB 뿐이다. 페이지 오류 375만 회가 발생했으며, 이는 지속적인 디스크 I/O 를 의미한다. 347초 실행 중 사용자 모드 CPU 시간은 35초에 불과해, 약 90% 가 I/O 와 스와핑 대기 시간에 소비된다. 이로 인해 다른 애플리케이션(예: Opera 브라우저)은 완전히 응답하지 않는다.

macOS 커널 패닉

Issue #39253 은 더 심각한 결과를 보고한다: MacBook Pro M3 Pro(18GB RAM) 에서 여러 Claude Code 인스턴스를 실행하면 macOS 커널 패닉이 발생한다. 두 종류의 패닉이 관찰되었다: Jetsam OOM kill(메모리 압박으로 macOS 가 핵심 watchdogd 프로세스를 종료)과 watchdog timeout(시스템 리소스 부족으로 watchdogd 가 90+초 동안 신호를 받지 못함). 시스템은 경고 없이 바로 재부팅되며, 오류 대화 상자나 작업 저장 기회가 전혀 제공되지 않는다.

프로세스 고아화: 터미널 닫아도 살아남음

Issue #44507 (2026년 4월, 몇 일 전) 은 기본적인 수명 관리 결함을 보고한다: 터미널 창을 닫아도 Claude Code 프로세스가 살아남는다. 고립된 프로세스는 21일 동안 35.4GB RSS 와 95.5% CPU 를 소비했다. 근본 원인은 메인 CLI 진입점에 process.stdin.on("end") 핸들러가 없고, 55개 이상의 setInterval 타이머(폴링, 텔레메트리, 상태바 업데이트 등)가 Node.js 이벤트 루프를 무한히 유지하기 때문이다. V8 힙은 제한 없이 성장하고, 유휴 GC 압력이 없으며, --max-old-space-size 제한도, 자체 종료 워치독도 없다.

100% CPU 정지

Issue #27415 은 TaskStop 트리거 시 100% CPU 정지를 보고했으며, 원인은 Bun 런타임의 posix_spawn 에서 발생한 제어 불가능한 루프다. Issue #26224 은 Claude Code 가 대량 프롬프트를 처리할 때 5~20분 동안 멈추는 문제를 보고했다.

평면 파일 아키텍처의 시스템적 실패

할당은 하지만 정리하지 않음: 모든 이슈에 공통된 아키텍처 패턴

커뮤니티 멤버 kolkov 은 여러 이슈에서 반복적으로 지적했다: 모든 문제의 근본 원인은 동일하다:

이 .node 누수는 고립된 버그가 아니라, Claude Code 가 자원을 할당하고 정리하지 않는 반복적인 아키텍처 패턴의 증상이다.

2025년부터 2026년까지, 문제는 .claude.json 단일 파일 팽창에서 JSONL 파일 분산 팽창으로 진화했지만, 근본 아키텍처는 변하지 않았다: 평면 파일, 락 없음, 트랜잭션 없음, 정리 없음, 압축 없음.

SQLite 와 로컬 데몬: 커뮤니티 대안

커뮤니티는 평면 파일 저장을 대체하기 위해 SQLite 사용을 여러 차례 제안했다. SQLite 데이터베이스는 모든 문제를 동시에 해결할 수 있다: WAL 모드는 동시 읽기 + 단일 쓰기의 원자성을 제공하고, 트랜잭션은 세션 쓰기를 전부 또는 전무로 보장하며, 내장 압축, TTL 정리, 내용 중복 제거, 크로스 플랫폼 일관성을 제공한다.

또 다른 제안은 로컬 데몬(예: LSP 서버, Docker 아키텍처)을 도입해 모든 Claude Code 프로세스가 IPC 로 통신하도록 하여 저장 백엔드를 변경하지 않고도 조정을 제공하는 것이다.

커뮤니티 역분석과 stale 로봇 비교

커뮤니티 멤버 gebeer 의 댓글은 현 상황을 정확히 요약한다:

당신의 상세한 분석에 감사한다. 이것은 유지 관리자가 오래 전에 해결했어야 할 일이다.

kolkov 은 추가로 지적한다:

아이러니하게도, 커뮤니티가 대신 디버깅을 하고 있다—역분석으로 코드를 혼란스럽게 만들고, 오류 경로를 추적하고, 코드 조각이 포함된 수정안을 제시하지만, 답변은 60일 후 모든 내용을 닫는 stale-issue 로봇이다.

유사 도구와 리소스 관리 비교

GitHub Copilot 은 VS Code 확장으로 실행되며, 확장 호스트의 메모리 제한과 수명 관리 제약을 받는다; Cursor 는 VS Code 기반 포크로 동일한 리소스 관리 프레임워크를 상속한다. 두 도구 모두 저장에 SQLite 혹은 유사 데이터베이스를 사용해 동시성 및 트랜잭션을 자연스럽게 지원한다. Claude Code 는 독립 프로세스 + 평면 파일 방식을 선택했지만, 독립 프로세스가 가져야 할 리소스 관리 책임(메모리 상한, 디스크 할당량, 프로세스 워치독, 우아한 종료)을 구현하지 않는다—프로토타입 시연에 가깝고, 프로덕션 환경용 도구라 보기 어렵다.

모델 능력과 엔지니어링 품질의 역설

11.3MB 단일 파일 패키징, 413개의 동기 파일 시스템 호출, 1087개의 CJS/ESM 상호 운용 래퍼, 리소스 정리 부재, 동시 제어 부재, 디스크 공간 모니터링 부재—이러한 문제들은 가장자리 케이스가 아니라 시스템적인 아키텍처 결함이다. 2025년 8월의 Issue #5024 부터 2026년 4월의 Issue #44507 까지, 커뮤니티는 동일한 범주의 문제를 지속적으로 보고하고 상세한 분석과 수정 제안을 제공했지만, 많은 이슈가 “not planned” 로 표시되거나 stale 로봇에 의해 자동 폐쇄되었다. AI 코딩 도구 자체의 코드 품질을 커뮤니티가 감사하고 수정해야 한다는 역설은 깊이 생각해볼 가치가 있다.

Claude Code 를 사용하고 있다면, 정기적으로 ~/.claude 디렉터리 크기를 확인하고, 임시 디렉터리의 .node 파일을 정리하며, 터미널을 닫기 전에 Ctrl+C 로 정상 종료하는 것을 권장한다. 디스크 공간이 갑자기 사라진다면, 이제 원인을 찾을 위치를 알게 된 것이다.

• ←이전
• 다음→