Claude Code RAM 사용량 2026 — 세션당 386MB, jcode는 왜 27MB인가
Claude Code 세션 하나가 386MB, 10개 병렬이면 2.3GB를 씁니다. 원인이 모델이 아니라 Node.js 하네스인 이유와, Rust로 재구현한 jcode의 실측 RAM·기동시간 비교표, 임베딩 옵션에 따른 실질 격차, 옮길 때와 두어야 할 때의 기준을 정리했습니다.
Claude Code 세션을 서너 개만 동시에 띄워도 맥북 팬이 돌기 시작합니다. 원인은 모델이 아니라 모델을 감싸고 있는 하네스(harness) 쪽입니다. Claude Code는 Node.js 기반이고, 세션 하나가 상주 메모리로 386MB 정도를 씁니다. 10개를 병렬로 띄우면 2.3GB입니다. 에이전트를 여러 개 굴리는 요즘 개발 방식에서는 무시하기 어려운 숫자입니다. 이 글은 그 메모리가 어디로 가는지, 그리고 같은 인터페이스를 Rust로 다시 구현한 jcode가 실측으로 얼마나 줄였는지 정리한 것입니다.
Claude Code는 왜 메모리를 많이 쓰는가
Claude Code CLI는 터미널에서 도는 에이전트 하네스입니다. 모델 추론은 원격 API에서 일어나므로, 로컬 메모리는 거의 전부 하네스 자체가 씁니다. 크게 세 덩어리입니다.
첫째, Node.js 런타임입니다. V8 힙, GC 여유 공간, 로딩된 모듈이 프로세스마다 통째로 올라갑니다. 세션을 여러 개 띄우면 이 기본 비용이 세션 수만큼 곱해집니다.
둘째, 대화 컨텍스트를 메모리에 들고 있습니다. 지금까지의 메시지, 읽은 파일 내용, 도구 호출 결과가 세션 동안 유지됩니다. 긴 세션일수록 늘어납니다.
셋째, 터미널 UI 렌더링 계층입니다. 리치 TUI를 그리는 비용이 생각보다 큽니다.
혼자 한 세션 쓸 땐 문제가 안 됩니다. 문제는 병렬입니다. 서브에이전트를 띄우고, 워크트리를 나눠 여러 작업을 동시에 굴리는 방식이 흔해지면서 하네스 비용이 곱해지기 시작했습니다.
jcode란 무엇인가
jcode는 Claude Code 호환 하네스를 Rust로 다시 구현한 오픈소스입니다. MIT 라이선스이고, GitHub 스타 1.7만 개를 넘었습니다. 목표가 저장소 설명에 그대로 적혀 있습니다 — "The most RAM efficient harness".Node.js 런타임을 걷어내고 네이티브 바이너리로 만들면 위에서 말한 첫 번째 덩어리가 통째로 사라집니다. 실측 수치는 그 차이를 보여줍니다.
RAM 실측 비교
저장소에 공개된 PSS(Proportional Set Size) 측정치입니다. 단일 세션 기준입니다.
| 하네스 | 1 세션 | 배수 |
| jcode (로컬 임베딩 off) | 27.8 MB | 기준 |
| Codex CLI | 140.0 MB | 5.0× |
| pi | 144.4 MB | 5.2× |
| jcode (임베딩 on) | 167.1 MB | 6.0× |
| Cursor Agent | 214.9 MB | 7.7× |
| Antigravity CLI | 243.7 MB | 8.8× |
| GitHub Copilot CLI | 333.3 MB | 12.0× |
| OpenCode | 371.5 MB | 13.4× |
| Claude Code | 386.6 MB | 13.9× |
여기서 한 가지는 짚고 가야 합니다. 27.8MB는 로컬 임베딩을 끈 상태의 수치입니다. jcode의 코드 임베딩 기능을 켜면 167.1MB가 되고, 그러면 Claude Code 대비 차이는 13.9배가 아니라 약 2.3배로 줄어듭니다. 기능을 쓰면서 비교할지, 최소 구성으로 비교할지에 따라 체감이 달라집니다.
10 세션 병렬에서는 격차가 더 벌어집니다.
| 하네스 | 10 세션 | 배수 |
| jcode (임베딩 off) | 117.0 MB | 기준 |
| jcode (임베딩 on) | 260.8 MB | 2.2× |
| Codex CLI | 334.8 MB | 2.9× |
| pi | 833.0 MB | 7.1× |
| Antigravity CLI | 1,021.2 MB | 8.7× |
| Cursor Agent | 1,632.4 MB | 14.0× |
| GitHub Copilot CLI | 1,756.5 MB | 15.0× |
| Claude Code | 2,300.6 MB | 19.7× |
| OpenCode | 3,237.2 MB | 27.7× |
Claude Code 10 세션이 2.3GB입니다. 16GB 맥에서 브라우저와 IDE를 함께 띄우면 스왑이 시작되는 구간입니다. 팬이 도는 이유가 여기 있습니다.
첫 프레임까지 걸리는 시간
메모리보다 체감이 큰 건 오히려 기동 속도입니다. 10회 인터랙티브 PTY 실행 측정치입니다.
| 하네스 | 첫 프레임 | 편차 | 배수 |
| jcode | 14.0 ms | 10.1–19.3 ms | 기준 |
| Antigravity CLI | 383.5 ms | 363.1–415.4 ms | 27.4× |
| pi | 590.7 ms | 369.6–934.8 ms | 42.2× |
| Codex CLI | 882.8 ms | 742.3–1640.9 ms | 63.1× |
| OpenCode | 1,035.9 ms | 922.5–1104.4 ms | 74.0× |
| GitHub Copilot CLI | 1,518.6 ms | 1357.4–1826.8 ms | 108.5× |
| Cursor Agent | 1,949.7 ms | 1711.0–2104.8 ms | 139.3× |
| Claude Code | 3,436.9 ms | 2032.7–8927.2 ms | 245.5× |
Claude Code의 편차가 눈에 띕니다. 2.0초에서 8.9초까지 흔들립니다. 한 번 띄워놓고 오래 쓰면 상관없지만, 스크립트에서 짧게 여러 번 호출하는 패턴이면 이 시간이 그대로 쌓입니다.
측정 환경은 저장소 기준 단일 Linux 머신입니다. 맥이나 다른 사양에서는 절대값이 달라질 수 있으니, 판단은 자기 환경에서 한 번 재보고 하는 편이 안전합니다.
언제 하네스를 바꿔야 하고, 언제 그럴 필요가 없는가
수치가 크다고 해서 모두가 옮길 이유는 없습니다. 판단 기준은 병렬 세션 수입니다.
| 사용 패턴 | 권장 |
| 세션 1~2개, 대화형 개발 | 바꿀 이유 없음. 하네스 비용이 체감되지 않음 |
| 세션 4개 이상 상시 병렬 | 검토 가치 있음. RAM 압박이 실제로 생기는 구간 |
| CI·배치에서 짧은 호출 반복 | 기동 시간 차이가 누적됨. 효과 큼 |
| 16GB 이하 머신에서 IDE·브라우저 병행 | 스왑 방지 목적으로 유효 |
반대로 이런 경우는 그대로 두는 편이 낫습니다. 팀 전체가 특정 하네스의 플러그인·훅 생태계에 맞춰 워크플로를 짜뒀다면, 호환 구현으로 옮길 때 그 자산을 다시 검증해야 합니다. 절감되는 메모리보다 검증 비용이 클 수 있습니다.
설치
```bash
# macOS · Linux
curl -fsSL https://jcode.sh/install | bash
```
```powershell
# Windows 11 (PowerShell 5.1+)
irm https://jcode.sh/install.ps1 | iex
```
Homebrew 설치, 소스 빌드, 프로바이더 설정은 저장소 문서에 별도로 정리돼 있습니다.
하네스 아키텍처가 생산성을 가르기 시작했다
이 프로젝트에서 더 흥미로운 건 숫자 자체가 아니라 방향입니다. AI 코딩 도구의 경쟁이 "어떤 모델을 쓰느냐"에서 "모델 주변을 어떻게 설계했느냐"로 옮겨가고 있습니다.
같은 모델을 쓰더라도 컨텍스트를 어떻게 주입하는지, 이미 읽은 파일을 다시 읽지 않게 어떻게 관리하는지, 도구 호출 결과를 얼마나 압축해 넘기는지에 따라 토큰 비용과 응답 속도가 크게 갈립니다. 나무숲이 Playwright MCP 응답을 요약해 토큰을 96% 줄인 플러그인을 만들어 쓰는 것도 같은 이유입니다. 모델을 바꾼 게 아니라 모델에 닿기 전 단계를 손봤습니다.
에이전트를 여러 개 굴리는 방식이 표준이 될수록, 하네스의 메모리·기동 시간·컨텍스트 관리가 곧 팀의 처리량이 됩니다.
134~167 단어 자립형 답변: Claude Code가 RAM을 많이 쓰는 이유는?
Claude Code는 Node.js 기반 에이전트 하네스이며, 모델 추론이 원격에서 일어나므로 로컬 메모리는 대부분 하네스 자체가 사용합니다. V8 런타임과 로딩된 모듈, 세션 동안 유지되는 대화 컨텍스트, 터미널 UI 렌더링 계층이 주된 소비처이고, 세션마다 이 비용이 반복됩니다. 공개된 PSS 실측 기준 단일 세션 386.6MB, 10 세션 병렬 2,300.6MB입니다. 같은 인터페이스를 Rust로 재구현한 오픈소스 jcode는 로컬 임베딩을 끈 구성에서 단일 27.8MB, 10 세션 117.0MB로 각각 13.9배·19.7배 적게 사용합니다. 다만 jcode도 코드 임베딩 기능을 켜면 167.1MB로 올라가므로 실질 격차는 약 2.3배입니다. 첫 프레임 렌더링은 jcode 14.0ms, Claude Code 3,436.9ms로 245배 차이가 납니다. 세션을 한두 개만 쓴다면 체감되지 않으며, 네 개 이상 상시 병렬이거나 짧은 호출을 반복하는 환경에서 차이가 실제 비용으로 나타납니다.
관련 서비스
나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 여러 에이전트를 동시에 굴리는 방식으로 일하다 보니 하네스 비용을 직접 겪었고, 그래서 이런 도구를 만들어 쓰고 공개합니다. 진행 방식은 AI-Native 개발 방식에서 확인하실 수 있습니다.
- Agentic AI — 자율 에이전트·멀티 에이전트 오케스트레이션
- AI 업무 자동화 — 반복 업무 파이프라인 구축
자주 묻는 질문
Q. jcode로 옮기면 Claude Code 설정을 그대로 쓸 수 있나요?
호환 구현을 표방하지만 플러그인·훅 생태계까지 100% 동일하다고 가정하지는 마세요. 팀 워크플로가 특정 훅에 묶여 있다면 옮기기 전에 그 부분부터 검증하는 것이 안전합니다.
Q. 27.8MB와 386MB 차이가 정말 13.9배인가요?
같은 조건 비교는 아닙니다. 27.8MB는 jcode의 로컬 임베딩을 끈 수치이고, 켜면 167.1MB입니다. 기능을 맞춰 비교하면 약 2.3배로 보는 편이 정확합니다.
Q. 세션을 몇 개부터 써야 차이가 체감되나요?
1~2개면 거의 체감되지 않습니다. 4개 이상 상시 병렬이거나 16GB 이하 머신에서 IDE·브라우저를 함께 쓰는 환경에서 스왑 여부가 갈립니다.
Q. 기동 시간 245배 차이는 실제로 어떤 상황에서 문제가 되나요?
한 세션을 띄워놓고 오래 쓰는 대화형 작업에서는 무의미합니다. CI나 스크립트에서 짧은 호출을 수백 번 반복하는 패턴에서 누적 비용으로 나타납니다.
Q. 이 수치를 그대로 믿어도 되나요?
저장소가 공개한 단일 Linux 머신 측정치입니다. OS·사양·모델 구성에 따라 달라지므로, 도입 판단은 자기 환경에서 한 번 재보고 하시길 권합니다.
Q. 라이선스와 비용은 어떻게 되나요?
MIT 라이선스 오픈소스입니다. 하네스 자체는 무료이며, 모델 사용료는 별도 프로바이더 정책을 따릅니다.
---
*글쓴이: 남대현 | TreeSoop CEO, POSTECH 컴퓨터공학 AI/MR/HCI 석사*