jcode는 Rust로 만든 오픈소스 AI 코딩 에이전트 하네스(harness)입니다. 하네스는 모델 자체가 아니라 모델을 실행하고 관리하는 껍데기를 뜻해요. jcode는 그 껍데기를 처음부터 다시 짜서 메모리와 부팅 시간을 극단적으로 줄인 프로젝트입니다.
숫자가 눈에 띕니다. 세션 하나에 27.8MB를 쓰는데, 같은 조건에서 클로드 코드는 386.6MB예요. 약 14분의 1입니다. 부팅은 더 벌어집니다. 첫 화면이 뜨기까지 jcode는 14ms, 클로드 코드는 3,437ms로 245배 차이가 나요.
다만 이 글에서 한 가지는 먼저 못 박고 가겠습니다. 저 수치는 전부 하네스 자체의 오버헤드를 잰 것이지, 코드를 얼마나 잘 짜는지를 잰 게 아닙니다. 이 구분이 흐려지면 도구를 잘못 고르게 돼요.
jcode 깃허브 저장소 화면 — 별 15.4k, MIT 라이선스
jcode 저장소. 소개문부터가 "가장 RAM 효율적인 하네스"입니다. (2026년 8월 3일 기준 별 15.4k)
핵심 기능 4가지
1. 극단적인 경량화 아래 표는 PSS(프로세스가 실제 점유하는 물리 메모리) 기준입니다. 다만 읽기 전에 하나 알고 봐야 해요. 경쟁 도구 수치까지 전부 jcode 개발자가 직접 잰 것입니다. 제3자 검증이 아니라 자기 도구가 1등인 표라는 뜻이라, 순위보다 자릿수 차이를 보는 편이 안전합니다.
세션당 메모리 사용량 (PSS 기준)
────────────────────────────────────────────
도구 1세션 10세션
────────────────────────────────────────────
jcode (임베딩 끔) 27.8 MB 117.0 MB
jcode (임베딩 켬) 167.1 MB 260.8 MB
Codex CLI 140.0 MB 334.8 MB
Cursor Agent 214.9 MB 1,632.4 MB
Claude Code 386.6 MB 2,300.6 MB
OpenCode 371.5 MB 3,237.2 MB
────────────────────────────────────────────
1세션만 보면 "요즘 컴퓨터에서 140MB든 390MB든 무슨 차이야" 싶습니다. 10세션에서 이야기가 달라져요. OpenCode는 3.2GB, 클로드 코드는 2.3GB인데 jcode는 117MB입니다. 세션 하나 늘 때마다 약 9.9MB만 더 쓰기 때문입니다.
2. 시맨틱 메모리 대화를 한 번 주고받을 때마다 그 내용을 벡터로 바꿔 메모리 그래프에 넣습니다. 새 대화가 들어오면 코사인 유사도로 관련 기억을 찾아 자동으로 끼워 넣어요. 메모리 도구를 직접 부르지 않아도 과거 맥락이 따라옵니다.
3. Swarm — 여러 에이전트가 한 저장소에서 같은 저장소에 세션을 두 개 이상 열면 서버가 알아서 조율합니다. A가 파일을 고치면 그 파일을 읽었던 B에게 알림이 가고, B는 무관하면 무시하고 겹치면 변경 내역을 확인해요. 메인 에이전트가 워커를 만들어 코디네이터로 전환하는 것도 됩니다.
4. 세션 이어받기 클로드 코드, Codex, OpenCode, pi에서 하던 세션을 jcode에서 그대로 이어갈 수 있습니다. MCP 설정도 기존 클로드 코드·Codex 것을 자동으로 가져와요.
이렇게 써보세요
활용 1: 갈아타지 말고 이어받기부터
가장 위험이 적은 시작점은 세션 이어받기입니다. 쓰던 도구를 버리지 않고, 멈췄을 때 맥락을 살리는 용도로만 붙여보는 거예요. 설치는 이 한 줄입니다.
curl -fsSL https://raw.githubusercontent.com/1jehuang/jcode/master/scripts/install.sh | bash
활용 2: 에이전트를 여럿 띄워야 할 때
파일 5개를 동시에 손봐야 하는 리팩토링처럼, 원래는 노트북이 못 버텨서 포기하던 작업이 대상입니다. 10세션에 117MB면 물리적으로 가능해지는 범위가 달라집니다.
활용 3: 로컬 모델을 붙일 때
Ollama나 LM Studio 같은 로컬 추론, vLLM 자체 호스팅도 설정 파일 하나로 연결됩니다. 프로바이더를 10개 넘게 지원해서 한 회사에 묶이지 않아요.
어두운 화면에 코드가 떠 있는 맥북
Photo by Caspar Camille Rubin on Unsplash
자주 묻는 질문
jcode는 무료인가요?
네, MIT 라이선스 오픈소스입니다. 다만 jcode는 하네스일 뿐이라 실제 모델은 따로 붙여야 하고, 클로드나 OpenAI 같은 상용 모델을 쓰면 그쪽 요금은 그대로 나갑니다.
jcode와 클로드 코드 중 뭘 써야 하나요?
메모리와 부팅 속도만 보면 jcode가 압도적입니다. 다만 코드를 얼마나 잘 짜는지는 측정된 적이 없어요. 에이전트를 여러 개 동시에 돌리는 게 목적이면 jcode, 한 개를 안정적으로 쓰는 게 목적이면 굳이 옮길 이유가 약합니다.
jcode 설치하려면 뭐가 필요하나요?
macOS·리눅스는 설치 스크립트 한 줄이면 되고, Homebrew나 소스 빌드도 지원합니다. 설치 후 프로바이더 로그인만 하면 바로 씁니다.
벤치마크 수치는 믿을 만한가요?
경쟁 도구 것까지 전부 개발자 본인이 측정한 수치라 제3자 검증은 아직 없습니다. 다만 임베딩을 켜면 27.8MB가 167.1MB로 6배 뛴다는 불리한 숫자까지 같은 표에 넣어뒀고, 측정 조건도 공개돼 있습니다. 도입을 검토한다면 본인 환경에서 한 번 재보는 게 확실합니다.
인사이트
이 프로젝트가 진짜로 던지는 건 속도 자랑이 아니라 전제의 교체입니다.
지금까지 코딩 에이전트는 "한 사람이 한 에이전트와 대화한다"를 기준으로 만들어졌어요. 그러니 세션당 300MB를 써도 아무도 문제 삼지 않았습니다. jcode는 그 전제를 "여러 개를 동시에 쓰는 게 기본"으로 바꾸고, 거기에 맞춰 하네스를 다시 짰습니다. 원문의 표현을 빌리면 Git 자체가 멀티 에이전트를 고려하지 않고 설계됐고, Swarm은 그 빈틈을 메우려는 시도예요.
그래서 판단 기준도 바뀝니다. "클로드 코드보다 나은가"가 아니라 에이전트를 동시에 몇 개 굴려야 하는가를 먼저 물어야 해요. 한 개로 충분한 사람에게 27.8MB는 아무 의미가 없습니다. 반대로 10개를 띄워야 하는데 2.3GB짜리를 쓰고 있었다면 이건 취향 문제가 아니라 가능·불가능의 문제고요.
아직 검증 안 된 구석도 분명합니다. 자동으로 주입되는 기억은 편한 만큼 틀린 기억이 현재 맥락을 오염시킬 위험을 같이 안고 있고, Swarm은 여전히 0.x대(2026년 8월 3일 기준 최신 v0.65.0)라 큰 리팩토링에서 조율이 버티는지 확인되지 않았습니다. 에이전트가 자기 소스를 고치는 self-dev 모드는 프로젝트 측이 "프론티어 모델을 쓰라"고 권고하는 것 자체가 위험도를 말해줘요. 이런 걸 먼저 밝히는 프로젝트는 대체로 믿을 만하지만, 믿을 만하다는 것과 지금 프로덕션에 넣어도 된다는 건 다른 얘기입니다.
원문: jcode: 코딩 에이전트 하네스의 성능 한계를 다시 쓰다 — 박재홍의 실리콘밸리 · 저장소: github.com/1jehuang/jcode