jcode: 공유 데몬으로 병렬 코딩 에이전트 20개를 91 MB에 담다
jcode는 Rust로 작성된 터미널 코딩 에이전트 하네스로 MIT 라이선스이며 Linux, macOS, Windows를 지원합니다. 세션마다 프로세스를 띄우지 않고 하나의 데몬을 공유합니다. 작성자의 헤드리스 측정에서 동시 세션 20개가 90.6 MB로, Claude Code의 3376.8 MB와 비교되고 첫 프레임은 14.0 ms입니다. 벡터 기억 그래프와 swarm도 갖췄습니다. 수치는 작성자 자체 측정입니다.
개요: 메모리 사용량을 핵심 지표로 삼은 코딩 에이전트 하네스
jcode(1jehuang/jcode)는 Rust로 작성된 터미널용 코딩 에이전트 하네스이며 MIT 라이선스로 Linux, macOS, Windows를 지원합니다. 프로젝트는 스스로를 두 줄로 소개합니다. 가장 RAM 효율이 높고, 가장 똑똑한 하네스. Claude Code, Codex CLI, OpenCode, GitHub Copilot CLI, Cursor Agent, pi, Antigravity CLI와 같은 분야에 있지만 접근이 다릅니다. 대부분의 도구는 프롬프트와 도구 연동에 힘을 쏟습니다. jcode는 먼저 실행 기반 자체를 극단적으로 가볍게 만든 뒤, 그 위에 기억 그래프, 멀티 에이전트 협업(swarm), 빠른 터미널 렌더링을 얹었습니다.
설치는 한 줄입니다. macOS와 Linux에서는 `curl -fsSL https://jcode.sh/install | bash`, Windows 11의 PowerShell에서는 `irm https://jcode.sh/install.ps1 | iex`를 실행합니다. TUI에서 `/update`, 또는 셸에서 `jcode update`를 실행하면 최신 안정 버전을 백그라운드로 내려받고 세션을 유지한 채 다시 불러옵니다. README에는 다운그레이드 방지 정책도 있습니다. 오래되었거나 같은 버전은 건너뛰고, 개발 빌드는 로컬 바이너리의 Git 커밋을 릴리스 태그와 비교하며, 계보를 확인할 수 없으면 업데이트를 멈춥니다. 기본 채널은 `features.update_channel = "stable"`이고 `"main"`을 명시해야만 소스 브랜치를 따라갑니다.
핵심 구조: 공유 데몬 하나와 가벼운 클라이언트
가장 중요한 설계는 여러 세션이 하나의 데몬을 공유한다는 점입니다. README의 헤드리스 측정 설명은 분명합니다. jcode 세션은 하나의 데몬을 공유하고, Claude Code는 세션마다 `claude -p --input-format stream-json` 프로세스를 띄웁니다. 프로세스 모델의 차이가 메모리 곡선의 기울기를 정합니다.
작성자의 헤드리스 벤치마크는 다음과 같습니다. 각 세션이 파일 목록, 파일 읽기, 저장소 검색, 요약, 응답의 다섯 번의 실제 모델 호출을 수행한 뒤 모든 프로세스의 PSS 합계를 측정했습니다. 두 도구 모두 claude-sonnet-4-6을 썼습니다. 세션 1개에서 jcode는 32.6 MB, Claude Code는 261.0 MB(8.0배)입니다. 5개에서 51.0 MB 대 908.6 MB(17.8배), 10개에서 66.7 MB 대 1749.7 MB(26.2배), 20개에서 90.6 MB 대 3376.8 MB(37.3배)입니다. 세션을 하나 더할 때마다 jcode는 약 3.1 MB, Claude Code는 약 164 MB가 늘어 약 54배 차이입니다. 측정일은 2026-09-29이고 jcode v0.89.19-dev(기본 빌드, 로컬 임베딩 미포함)와 Claude Code 2.1.267을 썼으며 `python3 scripts/bench_headless_memory.py`로 재현할 수 있습니다.
절댓값보다 기울기가 중요합니다. 에이전트를 대량으로 띄우는 작업자로 쓰면, 예컨대 20개 병렬 작업에서 Claude Code 방식은 약 3.4 GB, jcode 방식은 약 91 MB가 필요합니다. 병렬성의 한계는 메모리에서 모델 사용 한도와 API 비용으로 옮겨갑니다.
대화형 성능: 첫 프레임까지 14밀리초
README는 시작 지연도 쟀습니다. 대화형 PTY 실행 10회 결과입니다. 첫 프레임까지의 시간은 jcode 14.0 ms(10.1~19.3 ms), Antigravity CLI 383.5 ms, pi 590.7 ms, Codex CLI 882.8 ms, OpenCode 1035.9 ms, GitHub Copilot CLI 1518.6 ms, Cursor Agent 1949.7 ms, Claude Code 3436.9 ms로, Claude Code는 약 245.5배 느립니다. 첫 입력까지는 jcode 48.7 ms, Claude Code 3512.8 ms로 약 72.2배입니다.
대화형 메모리 표는 더 복잡하고 더 솔직합니다. 세션 1개에서 로컬 임베딩을 끈 jcode는 27.8 MB, 켠 jcode는 167.1 MB이며, pi는 144.4 MB, Codex CLI는 140.0 MB, Claude Code는 386.6 MB입니다. 즉 로컬 의미 임베딩을 켜면 단일 세션에서 jcode가 pi나 Codex보다 작지 않습니다. 장점은 확장할 때 나타납니다. 세션 10개에서 jcode는 260.8 MB(임베딩 끔 117.0 MB), Codex CLI는 334.8 MB, pi는 833.0 MB, Claude Code는 2300.6 MB, OpenCode는 3237.2 MB입니다. 세션 추가당 PSS는 jcode 약 10.4 MB, Codex CLI 약 21.6 MB, pi 약 76.5 MB, Claude Code 약 212.7 MB, OpenCode 약 318.4 MB입니다.
기억 시스템: 임베딩과 기억 그래프
jcode가 똑똑하다는 주장의 중심은 에이전트 기억입니다. README에 따르면 매 턴의 입력과 응답은 의미 벡터로 임베딩되고, 매 턴 기억 그래프를 코사인 유사도로 조회해 관련 항목을 찾습니다. 결과는 대화에 주입되거나, 기억 보조 에이전트가 관련성을 먼저 검증한 뒤 전달됩니다.
기록도 비동기입니다. 의미 이동이 생기거나, 마지막 추출 이후 K턴이 지나거나, 세션이 끝날 때 보조 에이전트가 기억을 추출해 그래프에 저장합니다. 명시적 기억 도구로 에이전트가 직접 검색하고 저장할 수 있으며, 세션 검색은 과거 세션에 대한 일반적인 RAG입니다. 마지막으로 앰비언트 모드가 주기적으로 기억을 정리하며 재구성, 낡음 확인, 충돌 점검을 합니다.
Swarm과 생태계
같은 저장소에서 에이전트를 둘 이상 띄우면 서버가 자동으로 관리해 협업합니다. 핵심은 충돌 감지입니다. 에이전트 A가 B가 읽은 파일을 수정하면 서버가 B에게 알리고, B는 무시하거나 다시 읽을 수 있습니다. 에이전트는 swarm 도구로 팀원을 직접 만들 수도 있으며, 이때 주 에이전트는 조정자, 생성된 에이전트는 작업자가 됩니다. `~/.jcode/config.toml`의 `[agents]`에서 `swarm_root_effort`와 `swarm_deep_root_effort`(기본값 둘 다 `max`)로 루트의 추론 강도를 작업자와 따로 정할 수 있습니다.
제공자 쪽에서는 구독형 OAuth 로그인(Claude, OpenAI/ChatGPT/Codex, Google Gemini, GitHub Copilot 등)과 모든 OpenAI 호환 엔드포인트를 지원합니다. `jcode provider add`는 프로필을 한 번에 기록하고, `--api-key-stdin`으로 키를 셸 기록에 남기지 않습니다. `extra_body`와 `JCODE_OPENAI_EXTRA_BODY`로 비표준 필드를 넣을 수 있고, NVIDIA NIM의 DeepSeek-V4가 사고를 켜려면 `chat_template_kwargs`가 필요하다는 예가 README에 있습니다. MCP는 `~/.jcode/mcp.json`과 Claude Code 설정 파일을 읽지만 현재 stdio 서버만 지원하며 HTTP와 SSE는 인식 후 건너뜁니다.
한계와 관찰
모든 벤치마크는 작성자가 자신의 Linux 장비에서 측정했고 독립적인 재현은 언급되지 않습니다. 표마다 버전도 다릅니다(헤드리스는 v0.89.19-dev와 Claude Code 2.1.267, 대화형 메모리는 v0.9.1888-dev와 Claude Code 2.1.86). PSS는 메모리를 재는 것이지 결과 품질이 아니므로 「가장 똑똑하다」는 자기 소개이며 이 수치로 입증되지 않습니다. 로컬 임베딩을 켜면 단일 세션 메모리는 최소가 아니고, 장점은 공유 데몬과 임베딩을 끈 구성에 기대고 있습니다. 공유 데몬은 장애 범위를 한곳에 모으는데 README는 이 점을 다루지 않습니다. 대규모 병렬 에이전트를 운영한다면 `scripts/bench_headless_memory.py`를 직접 실행해 수치를 확인하십시오.