jj와 Git 차이, 매일 쓰는 명령 6개로 비교해 봤습니다

매일 치는 git add가 다른 도구에서는 아예 사라진다면 어떻게 될까요? Git의 대안으로 거론되는 Jujutsu(명령어 이름은 jj)의 공식 문서에는 Git 명령과 jj 명령을 나란히 놓은 대응표가 있습니다. 이번 칼럼은 jj 소개를 되풀이하지 않고, 학생과 주니어가 매일 쓰는 여섯 가지 작업이 이 표에서 어떻게 옮겨지는지, 그리고 '1:1 번역'이 안 되는 지점이 도입 판단에 무엇을 뜻하는지 짚습니다.

왜 지금인가

Git은 오랫동안 버전 관리의 기본값이었기 때문에, 입문 과정에서 add → commit → push는 거의 의식처럼 배웁니다. 그런데 이 순서에는 스테이징(커밋에 넣을 변경을 따로 골라 담아 두는 중간 단계)이 들어 있습니다. jj는 이 중간 단계를 구조에서 없애는 쪽을 택했습니다.

교육 관점에서 이 차이는 흥미롭습니다. 공표된 조사가 있는 것은 아니고 필자의 관찰입니다만, 입문자가 Git에서 멈추는 지점은 명령어 암기보다 "변경이 지금 어느 단계에 있는가"를 머릿속에 그리는 부분인 경우가 많았습니다. 다른 도구가 같은 일을 어떻게 옮기는지 읽으면 Git의 단계 구조도 더 또렷하게 보입니다. 도구를 갈아타지 않더라도 대응표를 읽어 볼 가치가 여기에 있습니다.

공식 대응표는 "같은 동작"의 목록이 아니라 "같은 목적을 이루려면 jj에서 무엇을 치는가"의 목록으로 읽어야 합니다.

숫자로 보는 현황

이 주제에는 공표된 통계 대신 공식 문서의 대응표가 있습니다. 아래 표 1은 Jujutsu 공식 문서의 'Git command table'에서 매일 쓰는 여섯 작업을 옮긴 것입니다.

표 1. 매일 쓰는 Git 작업 6가지의 jj 대응

출처: Jujutsu 공식 문서 'Git command table' (latest, 2026년 10월 확인). 문서는 계속 갱신되므로 이 글의 대응은 그 시점의 것입니다.

※ '성격' 열은 공식 분류가 아니라 필자 해석입니다. 같은 단계에서 그대로 짝지어지면 '직접 대응', 이름만 달라지면 '이름이 바뀐 대응', 단계가 사라지거나 다른 방식으로 대체되면 '단계가 없음'·'비슷한 목적'으로 나눴습니다.

성격 열로 보면 commit과 push는 명령 이름만 익히면 되는 직접 대응이고, add와 stash는 개념 차이가 가장 큽니다. branch는 이름만 bookmark로 바뀌고, rebase는 목적이 같은 다른 명령으로 옮겨집니다. 표 1 밖의 대응 명령은 부록 표 3에 모았습니다.

명령은 바뀌는데, 바뀌는 것은 명령만이 아닙니다

add와 commit: 작업 사본도 커밋입니다

표의 항목 이름은 'Add a file to the current change'입니다. Git은 touch filename; git add filename, jj는 touch filename뿐입니다. 표에 '별도 add 명령이 없다'고 적혀 있지는 않으므로, 아래 설명은 표를 읽어 낸 것입니다. 이유는 jj의 작업 사본 커밋(working-copy commit) 구조에 있습니다. 지금 편집 중인 파일 상태 자체가 이미 하나의 커밋이어서, 파일을 만들면 그 커밋에 반영됩니다. Git이 working tree → staging → commit 세 단계라면 jj는 작업 사본 커밋 한 단계입니다.

git commit -a는 jj commit에 대응하며 항목 이름은 'Finish work on the current change and start a new change'입니다. 여기서 'finish'와 'start a new'가 함께 나오는 점이 힌트입니다. jj의 commit은 "저장"이라기보다 "지금 변경을 마무리하고 다음 변경을 시작"하는 동작입니다.

stash, rebase, branch, push: 같은 동작과 비슷한 목적

먼저 기호부터 풉니다. @는 지금 편집 중인 작업 사본 커밋이고, @-는 그 부모, 곧 바로 앞 커밋입니다. X는 공식 표가 '기존 작업 사본 커밋'을 가리키려고 붙인 이름이며, 형제 커밋은 같은 부모를 가진 커밋을 뜻합니다.

git stash는 jj new @-에 대응합니다. 공식 표의 설명에 따르면 기존 작업 사본 커밋은 형제 커밋으로 남고, jj edit X로 되돌릴 수 있습니다. 두 방식의 전후 관계를 그리면 이렇습니다.

[Git] git stash
 전:  A ── (작업 폴더에 수정 중인 변경)
 후:  A      작업 폴더는 깨끗하고, 변경은 stash 목록에 있음

[jj] jj new @-
 전:  A ── X(@)        A = @-, X = 수정 중인 작업 사본 커밋
 후:  A ─┬─ X          X는 형제 커밋으로 남음
         └─ Y(@)       Y = 새로 생긴 작업 사본 커밋
 복구: `jj edit X`를 실행하면 X가 다시 @가 됨

변경이 형제 커밋으로 보존되고 jj edit X로 복귀하므로, jj도 stash와 같은 보관 목적을 달성합니다. 달라지는 것은 보관 장소입니다. Git에서는 stash 목록이 맡던 역할을 jj에서는 커밋 그래프가 맡습니다. 그래서 "작업 폴더를 깨끗하게 만든다"는 목적은 같아도, 보관해 둔 변경을 찾는 방법은 달라집니다.

git rebase -i는 jj arrange에 대응합니다. 브랜치는 jj에서 bookmark(커밋을 가리키는 이름표)라는 용어로 바뀌어, git branch <name> <revision>이 jj bookmark create <name> -r <revision>이 됩니다. push는 git push <remote> <bookmark name>이 jj git push --bookmark <bookmark name>으로 바뀝니다.

기존 Git 원격과 colocated 저장소

호환의 핵심은 jj가 일반 Git 저장소를 백엔드로 쓸 수 있다는 점입니다. 공식 문서도 이 방식으로 Git 사용자와 협업할 수 있다고 설명합니다. Git 설정 중에서는 원격(remote) 설정과 core.excludesFile만 인식하고, .gitignore 패턴을 지원합니다.

Colocated 저장소는 .jj/와 .git이 같은 위치에 있는 구성으로, jj 명령을 칠 때마다 Git 저장소와 자동으로 가져오기·내보내기를 합니다. 그래서 Git 도구를 병행할 수 있습니다. 다만 두 도구의 명령을 섞어 쓰면 bookmark 충돌이 생길 수 있어서, 작업 단위마다 어느 도구로 처리할지 정해 두는 편이 안전합니다.

한계도 분명합니다. 대응표는 번역 사전이 아니라 "목적이 같은 명령" 목록이므로, 표에 없는 Git 기능이 jj에서 똑같이 동작한다는 보장은 없습니다. 이 글에서 확인한 범위는 표 1의 push 대응까지이며, GitHub의 PR 같은 서비스 기능과의 세부 연동은 다루지 않습니다. 호환의 빈틈은 시사점의 표 2에 정리했습니다.

현장의 변화

이 글이 확인한 사실은 공식 문서 수준이어서 특정 기업의 도입 성과는 인용하지 않습니다. 대신 공식 문서의 상태를 읽어 도입 여부를 판단하는 세 가지 경우를 필자가 가정 사례로 구성했습니다. 실제 팀의 사례가 아니라 판단 연습용입니다.

경우 1. 개인 학습용 저장소. 서브모듈이나 훅 없이 파일 몇 개를 관리하는 연습 저장소라면, 표 1의 여섯 작업이 모두 대응되고 push도 직접 대응입니다. 막히는 항목이 표 2에 없으므로 시험 도입이 자연스러운 선택입니다. 한계는 이 판단이 개인 규모의 작업 흐름에만 해당한다는 점입니다.

경우 2. 서브모듈을 쓰는 팀. 공식 문서는 서브모듈이 작업 사본에 표시되지 않지만 손실되지는 않는다고 설명합니다. 변경이 사라지지는 않으므로 위험이 큰 것은 아니지만, jj 화면에서 서브모듈 상태를 볼 수 없다는 뜻입니다. 이 팀은 서브모듈이 걸린 작업만 Git으로 처리하는 병행 구성이 맞습니다.

경우 3. 훅과 Git LFS를 쓰는 팀. 두 기능은 공식 문서상 미지원이므로, 쓰는 팀에서는 jj가 그 역할을 대신하지 못합니다. 커밋 전 검사를 훅에 맡기고 있다면 Git 쪽 흐름을 유지해야 하고, jj는 개인 실험에 한정하는 것이 현실적입니다. 판단 근거가 공식 문서의 '미지원' 한 줄이라, 문서가 바뀌면 결론도 바뀔 수 있습니다.

시사점: 우리가 갖춰야 할 것

표 2는 호환 문서가 밝힌 빈틈과 도입 판단을 한 표로 묶은 점검표입니다. 각 한계의 자세한 배경은 앞선 글 「Git 저장소에 jj를 얹기 전, 훅·LFS·속성 파일이 막힙니다」에서 다뤘으므로 여기서는 판단에 필요한 요약만 둡니다.

표 2. Git 호환 점검표: 공식 문서 상태와 도입 판단

출처: Jujutsu 공식 문서 'Git compatibility' (latest, 2026년 10월 확인). 오른쪽 열은 공식 문서 상태를 바탕으로 한 필자의 판단입니다.

판단 기준은 단순합니다. 서브모듈·훅·LFS·.gitattributes·shallow/partial clone 중 하나라도 쓰면 colocated로 병행하고, 모두 쓰지 않으면 시험 도입합니다.

• 저장소부터 점검합니다. 팀 저장소에서 표 2의 다섯 항목 중 실제로 쓰는 것이 있는지 찾아봅니다. 하나라도 있으면 그 항목의 오른쪽 열이 곧 결론입니다.
• 쓰는 것이 있으면 colocated로 병행합니다. Git 도구는 그대로 두고 jj를 얹어 봅니다. bookmark 충돌을 피하려면 작업 단위마다 도구를 하나로 정합니다.
• 모두 쓰지 않으면 시험 도입합니다. 연습용 저장소에서 표 1의 여섯 작업을 Git과 jj로 나란히 쳐 봅니다. 부록의 실습 스크립트가 파일 생성부터 push까지 그 순서를 안내합니다.
• 도입 직전에 문서를 다시 확인합니다. 표 1과 표 2는 2026년 10월 확인 기준이고 문서는 계속 갱신됩니다. 팀에 적용하기 전에 latest 문서에서 해당 항목이 바뀌었는지 먼저 봅니다.

맺음말

공식 대응표가 보여 주는 jj는 "명령 이름만 바꾼 Git"이 아닙니다. 스테이징이 없고, 작업 사본이 커밋이며, stash와 rebase는 목적이 같은 다른 방식으로 옮겨집니다. Git 원격과 협업할 수 있다는 점은 강점이지만, 표 2의 빈틈은 도입 전에 직접 확인해야 합니다. 오늘 연습용 저장소에서 부록의 실습 스크립트를 위에서 아래로 실행하고, 줄마다 적힌 기대 결과와 화면을 맞춰 보세요. Git 쪽에 있던 add 줄이 jj 쪽에는 없다는 것을 직접 확인하면 이 글의 핵심은 몸에 남습니다. 더 읽고 싶다면 참고 자료의 Klabnik 튜토리얼을 이어서 보세요.

부록. 본문에서 뺀 대응 명령과 실습 스크립트

표 3. 공식 대응표의 추가 항목

출처: Jujutsu 공식 문서 'Git command table', 'Git compatibility' (latest, 2026년 10월 확인).

실습 스크립트: 파일 생성부터 push까지

연습용 원격은 내 컴퓨터의 빈 저장소이므로 실제 서비스에는 아무것도 올라가지 않습니다. git과 jj가 설치되어 있고 두 도구 모두 사용자 이름과 이메일이 설정되어 있어야 합니다. 공식 문서 latest 기준(2026년 10월 확인)이며, 설치된 jj 버전에서 옵션 표기가 다르면 도움말로 확인합니다.

git init --bare /tmp/demo-remote.git                   # 기대: 연습용 원격(빈 bare 저장소) 생성
git init demo-git && cd demo-git                       # 기대: 빈 Git 저장소 생성 후 이동
git remote add origin /tmp/demo-remote.git             # 기대: 출력 없음, origin 등록
echo hello > a.txt && git add a.txt                    # 기대: 출력 없음, 이 줄에서 스테이징 단계가 필요
git commit -m "add a.txt"                              # 기대: 커밋 생성 메시지 출력
git branch git-demo HEAD && git push origin git-demo   # 기대: 원격에 git-demo 브랜치 생성
cd .. && jj git init --colocate demo-jj && cd demo-jj  # 기대: .jj와 .git이 같은 위치에 있는 저장소 생성
jj git remote add origin /tmp/demo-remote.git          # 기대: 출력 없음, origin 등록
echo hello > a.txt                                     # 기대: add 없이 작업 사본 커밋에 a.txt 반영
jj commit -m "add a.txt"                               # 기대: 변경 마무리, 새 빈 변경이 @가 됨
jj bookmark create jj-demo -r @-                       # 기대: jj-demo가 방금 마무리한 커밋을 가리킴
jj git push --bookmark jj-demo                         # 기대: 원격에 jj-demo 생성

참고 자료

• Jujutsu 공식 문서, 「Git command table」 (latest, 2026년 10월 확인), https://docs.jj-vcs.dev/latest/git-command-table/
• Jujutsu 공식 문서, 「Git compatibility」 (latest, 2026년 10월 확인), https://docs.jj-vcs.dev/latest/git-compatibility/
• Steve Klabnik, 「Steve's Jujutsu Tutorial」, https://steveklabnik.github.io/jujutsu-tutorial/
• 테크창 앞선 글: 「Git 없이 협업한다고? Jujutsu가 온다」
• 테크창 앞선 글: 「Git 저장소에 jj를 얹기 전, 훅·LFS·속성 파일이 막힙니다」

테크창 연구팀