모두를 위한 Jujutsu

 (jj-for-everyone.github.io)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 이 문서는 Git 경험이 없어도 따라 할 수 있도록 Jujutsu(VCS) 를 단계별 레벨 구성으로 가르치는 초심자용 튜토리얼임
  • 터미널 사용을 전제로 하지만 터미널 기초부터 다루며, 주요 명령은 Linux/macOS 중심으로 설명하고 Windows 사용자는 WSL 권장
  • 학습 흐름은 레벨 1~3에서 기본·협업·문제 해결을 다지고, 상위 레벨에서 히스토리 리라이트·고급 워크플로우로 확장하는 구조
  • 튜토리얼 진행 중 상태가 꼬일 때를 대비해 reset 스크립트로 각 장 시작점으로 되돌리는 재현 가능 학습 환경을 제공함
  • 왜 Git 대신 Jujutsu인가에 대해 Git 호환성, 학습 난이도 완화, 고급 기능성을 근거로 제시하며, 최신 Jujutsu 0.32 기준으로 갱신 중

소개(Introduction)

  • 이 튜토리얼은 Jujutsu를 처음 쓰는 사용자를 대상으로 한 입문 자료임
  • 기존 Jujutsu 자료가 숙련 Git 사용자 전환에 집중된 한계를 보완하는 비기너 중심 콘텐츠 제공
  • 터미널 사용이 기본이며, 기초 터미널 사용법 장을 포함하고 Windows 사용자는 WSL 사용을 권장함

읽는 법(How to read this tutorial)

  • 내용은 레벨 단위로 구성되며, 각 레벨을 마친 뒤 실제로 연습 후 다음 레벨로 진행하는 학습 설계
  • 협업 목적이라면 레벨 1과 2를 연속 수강할 것을 권장함
  • 레벨 개요
    • 레벨 1: 개인 작업에 필요한 최소 시작 셋 제공, 혼자 과제 관리하는 학생 수준에 적합함
    • 레벨 2: 협업을 위한 최소 셋, 학생 팀 프로젝트와 실무 개발자에게 필요함
    • 레벨 3: 충돌 해결, 복구 등 문제 해결 기초, 평균 개발자 숙련도에 해당함
    • 레벨 4: 히스토리 리라이트로 깔끔한 이력 구축, 일부 프로젝트의 품질 기준 충족을 위해 필요함
    • 레벨 5: 생산성 부스터·고급 워크플로우·희소 CLI·이론, Jujutsu 마스터 단계
    • 레벨 6: 태그·서브모듈·워크스페이스 등 상황별 주제, 필요 시 참조 권장

단축키(Keyboard shortcuts)

  • 좌우 화살표로 장 간 이동 지원
  • S 또는 / 로 책 내 검색 지원
  • ? 로 도움말 표시, Esc 로 숨김 지원

진행 상태 초기화(Reset your progress)

  • 예제 저장소 상태가 다음 장과 연동되므로, 상태 손실 시 진행이 막힐 수 있음
  • 이를 해결하기 위해 장 시작점으로 복구하는 reset.sh 스크립트 제공
  • 각 장 서두에 정확한 reset 명령이 포함되어 있어 복사·붙여넣기로 재현 가능
  • 스크립트는 실행 전 내용 검토를 권장하며, 실질적으로 수동 명령 모음 수준의 단순 동작임
  • 스크립트 주요 특징
    • JJ_CONFIG=/dev/null로 사용자 설정 영향 차단
    • 예제 레포 생성, colocate Git 연동, 사용자 정보 세팅, 커밋/푸시/페치/리베이스 등 연속 시나리오 재구성
    • 각 챕터 키워드를 인자로 받아 해당 지점에서 성공 종료하도록 분기 설계

최신 상태 유지(Stay up to date)

  • 튜토리얼과 Jujutsu는 지속 진화 중이며, 튜토리얼 저장소의 Releases 구독을 통해 큰 변경 공지를 받을 수 있음
  • 본 튜토리얼은 Jujutsu 0.32 기준(2025년 8월) 으로 최신이라고 명시함
  • GitHub에서 Watch → Custom → Releases로 업데이트 알림 설정 안내 제공

버전 관리의 필요(What is version control and why use it?)

  • 소프트웨어뿐 아니라 Typst 등 문서 저작에도 적용 가능한 점진적 작업 축적 관리 수단임
  • 과거 상태로의 복귀 가능, 여러 사람의 동시 작업을 안전하게 지원함
  • 일반 백업이나 협업 에디터 대비 더 예리한 제어 도구가 필요할 때 Jujutsu가 적합함

왜 Jujutsu인가(Why Jujutsu instead of Git?)

  • Git 호환성: 기존 Git 저장소와 무손실 상호운용, 대부분의 Git 통합 도구를 그대로 활용 가능함
  • 학습 용이성: Git의 복잡·비직관 UI 대비 Jujutsu는 같은 기능을 낮은 복잡도로 제공함
  • 더 강력한 기능성: 쉬운 학습성과 별개로 파워 유저 기능을 다수 제공하여 워크플로우 확장성 보장
  • 단점 및 고려사항
    • 대화 시 Git 용어 중심 문화와의 개념 매핑 부담 존재, 동료 설득으로 완화 가능성 있음
    • 비교적 신생이라 Git의 일부 기능 미포함 사례가 있고, 필요 시 Git 직접 사용으로 폴백 가능함
    • CLI가 아직 안정화 과정으로 일부 명령 변화 가능, 튜토리얼 릴리스 구독으로 변화 추적 권장

학습 진행(Completed & Next)

  • 현재 레벨 1~3 중심으로 실전 과제 흐름(설치→초기화→로그/커밋→리모트/푸시·클론→브랜치/머지→리베이스→내비게이션→되돌리기/복구→충돌 해결→정리)을 체득하도록 구성
  • 상위 레벨에서 리라이트·고급 워크플로우·희소 주제를 추가 학습하는 점진적 숙련 전략 제시

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 내가 jj에 대한 칭찬 기사만 수십 개를 본 것 같음. 이번 튜토리얼도 비슷한데, 이제 좋은 점은 충분히 읽었으니, 단점과 불편한 점에 더 관심이 감. 내가 jj를 써보니 장단점이 있었음. 동료와 브랜치를 공유해서 커밋을 계속 쌓는 워크플로우를 자주 쓰는데, jj는 이름 붙인 브랜치가 없어서 git보다 사용이 번거로웠음(tug alias를 써도 마찬가지). 튜토리얼의 “Tracking remote bookmarks” 단원도 내게는 여전히 불편해 보임. 또 하나 불편했던 점은 jj가 git의 git clone --filter=blob:none처럼 light clone을 사용할 수 없어, 이게 고쳐졌는지 궁금함

    • jj에는 이름 붙인 브랜치가 있고, jj에서는 “bookmarks”라고 부름. remote bookmark를 추적하면 jj git fetch로 로컬이 remote와 동기화됨

    • 나를 어렵게 했던 부분 중 하나는 jj가 내 변경 사항을 무작위로 잃는 경우가 있다는 점임. Cursor에서 작업하고 jj로 리포를 mutating하지 않았는데(jj status, jj log 정도만 했을 뿐) 나중에 보면 내 변경이 사라져 있기도 하고, 종종 "stale workspace" 메시지가 뜨기도 함. 이게 IDE나 거대한 모노레포 때문인지 모르겠지만 정말로 고통스러웠음. 그래도 jj의 유연성은 상당히 마음에 듦

    • https://github.com/jj-vcs/jj/discussions/3549에서 tug 워크플로우를 조금 더 간단하게 만드는 논의가 있음

    • jj에 이름 브랜치가 없다는 건 잘못된 이야기임. jj branch set -r@ XYZ처럼 수동으로 지정해줘야 해서 조금 번거롭지만, push할 때만 한 번 해주면 됨. 또는 jj git push --named XYZ=@로 브랜치를 옮기는 방법도 있음

    • jj가 light clone(git clone --filter=blob:none)을 지원 못하는 건 여전히 해결되지 않음

  • “Jujutsu가 Git보다 더 강력하다”고 했는데 구체적으로 어떤 점이 강력한지 설명이 없어서, 도대체 왜 써야 하는지 궁금함. 이건 단순한 미사여구 같음

    • 튜토리얼 저자임. 초보자가 대상이라서 Git과의 자세한 비교는 적합하지 않았음. Git UI의 복잡함이 “강력함” 때문에 정당화되는 경우가 많아, 사용자들에게 Jujutsu가 배우기 쉽다는 이유로 기능을 잃는 게 아니라는 점을 알려주려고 해당 주장만 첨언함

    • 예를 들어 Main 브랜치에서 새로운 브랜치를 만들고, 나중에 PR로 보낼 계획임. 커밋을 여러 개 쌓다가 1번 커밋을 바꿔야 한다고 느끼면, 1번을 수정하고 저장만 하면 다른 모든 커밋이 알아서 최신 상태로 리베이스됨. PR 이후에도 3번 커밋을 수정하려면 그냥 해당 커밋만 편집해 푸시하면 끝임. 이런 작업을 Git으로 직접 하는 건 정말 어려움. 동료들이 여러 커밋으로 나뉜 PR을 대단히 좋아함

    • 나도 비슷하게 생각함. Git UI들이 전반적으로 부족하다고 느껴서 jj를 어느 정도는 신뢰하며 쓸 의향이 있음. 하지만 “왜 더 쉽거나 강력하거나 편리한지”에 대한 구체적인 시연이 있었으면 더 좋겠음

    • 한 가지 예로, 머지 컨플릭트(conflict)를 하나의 항목으로 등록해 두고 나중에 처리할 수 있음: https://jj-vcs.github.io/jj/latest/conflicts/

  • 최근 JJ를 다시 써 보니 많이 좋아져서 즐겁게 사용 중임. 초기에 시도했을 땐 날카로운 모서리가 많아 부담스러웠지만, JJ는 최근 등장한 뛰어난 툴링 “새로운 물결”의 일부라 생각함. 블로그에도 관련 글을 남김: https://pdx.su/blog/2025-08-13-the-quiet-software-tooling-renaissance/

    • 좋은 글임. 최근 몇 년간 개발 툴링 기준이 정말 높아졌다고 생각함. Rust도 그런 변화의 일부임

    • mise를 당신도 사용하고 좋아한다니 반가움. mise, jj(그리고 완전 멋진 jjui TUI), python용 uv 모두 혁신적임. 이런 툴이 정말 아름답다고 생각함

    • 나는 여기에 nushell도 꼭 추가하고 싶음

    • Bun도 이 툴링 혁신의 선두주자임

  • 훌륭한 작업임! 나는 거의 5개월 동안 Jujutsu만 사용해서 git을 완전히 대체했음. 실제로 그동안 Git은 52번(그 중 11번은 --help였음) 실행했으나 Jujutsu는 582번이나 사용함. 특정 워크플로우에 맞출 필요 없이, Jujutsu는 거의 모든 워크플로우를 지원할만큼 충분히 유연함. git처럼 쓰더라도, 커밋과 브랜치를 자유롭게 이동할 수 있고(stash할 필요 없음), 간단하게 리베이스할 수 있음(이건 git 고수에겐 익숙하겠지만, VSCode의 git 도구 없이 바로 되는 게 정말 고마움), VCS에서 오는 골치 아픈 부분 없이 작업에만 집중할 수 있음. 주의할 점은, 작업 내역은 기존처럼 git 리포에도 남기 때문에 다른 git 도구들과도 호환됨. 동료들이 VCS를 바꾸지 않아도 내가 다른 걸 쓸 수 있다는 셈임. 태그, 서브모듈, LFS 쪽에서 약간 아쉬운 부분이 있지만, 그래도 써볼 가치 충분함

    • git branch --set-upstream-to의 jj 대체 방안이 무엇인지 궁금함

    • jjui를 써보면 앞으로 jj 명령어 터치할 일이 거의 사라짐. 진짜 놀라움

  • Jujutsu 정말 괜찮음. 몇 달 전에 써보고 관련 글도 몇 개 썼는데 (이 글) 그 이후로 계속 쓰고 있음. 전체적으로 아주 “일관된” 경험임. 사실 나는 git도 문제없이 썼던 사람인데, jj는 모든 게 몇 가지 기본 원리로 돌아가고, 원하는 대로 조합해서 복잡한 작업 이력 변경도 쉽게 할 수 있음. 나는 원래 “stash 위주”로 일했는데, jj는 변경 자동 추적, 자유로운 변경 이동 등 덕분에 git보다 훨씬 쾌적함. 리베이스와 충돌 해결도 (특히 stash 스타일의 워크플로우에서는) 훨씬 좋음. 적극 추천이며, 갈아타는 데 드는 노력도 매우 작음

  • 개인적으로 git 위에 새로운 레이어를 추가하는 접근 방식은 별로임. git의 헤게모니를 뚫는 건 어렵다는 건 알지만, 완전히 새로운 기반 위에 짓는 게 훨씬 더 강력하고 자유로울 거라 생각함

  • 나는 한 달 정도 jj를 쓰다가, 회사 특정 프로젝트 때문에 git으로 다시 돌아왔음. jj가 정말 마음에 들긴 했지만, 그 이상은 아님. 그런데 git로 돌아간 지 몇 시간 만에 jj의 편리함이 엄청 그리워졌음: https://blog.nawaz.org/posts/2025/Aug/the-jujutsu-effect/

    • “그 이상은 아니었다”는 게 정확히 무슨 뜻인지 궁금함

    • 잃고 나서야 진가를 알 수 있다는 내용임

  • “Jutustsu for Git experts”라는 주제로 더 읽고 싶음. 예를 들어, conflict를 커밋하는 게 내 git rerere를 망치진 않을지, 혹은 git에선 git add -p로 패치의 일부분만 스테이징해서 작업하는 걸 좋아하는데, jj에서 2단계 패치 셋을 간편하게 구현할 방법이 있을지 궁금함. 타임스탬프 손상이나 무의미한 빌드 시스템 리빌드를 피해가고 싶음

    • jj에서 가장 널리 쓰는 워크플로우(“squash workflow”)로 답변함. 작업 디렉터리인 top commit에서 자유롭게 변경하다가, “스테이징”하고 싶을 때 하위 커밋(즉, 한 단계 아래)으로 squash down(모든 변경 또는 -i로 일부만 선택)하면 됨. 또 squash --into로 다른 커밋을 지정해 원하는 위치에 squash 가능함

      1. jj에서는 git rerere를 쓰지 않으니 이 질문은 약간 엇나감. 2. @이 작업 공간이고, @-가 작업 중인 커밋. jj squash -i로 원하는 diff 일부만 인터랙티브하게 @로 되돌릴 수 있음

    • “스테이지/언스테이지 구분은 불필요하다” 동의함에도, “patch 중 마음에 드는 부분만 스테이징은 정말 좋아한다”는 의견은 신기함. git worktree, git diff, vi, git apply 조합으로 스테이징 없이 비슷한 효과를 낼 수 있지만 정말 번거로움. mercurial 7.1에도 여전히 인터랙티브 추가가 없어서 worktree를 통한 편법 외엔 대안이 없음

  • 최근 들어 Jujutsu 얘기를 봤지만, 구체적인 워크플로우까지는 안 들어가 봄. Emacs Magit보다 Jujutsu가 특별히 유리한 점이 있는지 궁금함. 지금까지 써본 Git UI는 대부분 부족했으나, Magit 덕분에 git 생산성이 크게 올랐고 git의 “마법”도 체감했음. Jujutsu가 이 경험과 경쟁하려는 건가, 아니면 (정말로 부족한) 기존 git UI에 대한 대안이 목표인지 궁금함

    • Jujutsu는 단순한 git UI가 아니라, 오히려 git UI로서의 기능은 약한 편임(태그, 서브모듈 등 지원 부족). 완전히 새로운 VCS인데, 백엔드로 git을 씀. git이 SVN 대비 “cheap branch”를 제공했다면, JJ는 “cheap rebase”를 가져옴. 컨플릭트가 전체 작업을 중단시키지 않고, 리베이스, 커밋 구조 관리 등이 정말 편함. stacked diffs 사용해 봤다면 익숙하게 느껴질 것이고, stacked diff PR이 jj에서는 거의 노력을 들이지 않고도 가능함

    • 이미 Magit을 많이 쓰는 사용자라면, jj의 기본 컨셉들도 매력적일 것임. jj는 기존에 불가능하다고 생각했던 커밋 acrobatics(예: 5-way octopus merge의 2 리프를 컨플릭트 미해결 상태로 리베이스)가 가능함. 이건 “Mega Merge”라는 이름으로 내가 만든 기법이기도 함. Magit과 jj는 닮은 점이 있는데, “git의 마법”도 실은 도구의 “디자인 언어” 덕분이라 생각함. Git은 Magit과 jj 모두의 물리적 저장소 레이어일 뿐, 알고리즘·UX·개념 등에서 큰 차이를 만듦. Magit 사용자는 jj에 충격을 덜 받는 편이지만, 고급 Git 커맨드라인 유저는 jj로 아주 쉽게 넘어오고, 실제로 강력한 전도자가 됨. 커밋 그래프 조작에 강한 툴의 힘을 누구보다 잘 이해하는 사람들임. 참고로 나는 jj 메인테이너 중 한 명이고, 아주 잘 만든 도구라 생각함. 며칠만이라도 Magit 없이 한 번 써보면 좋겠음

    • 여기 관련 링크가 있음. Megamerge 워크플로우가 잘 설명된 글: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/, https://ofcr.se/jujutsu-merge-workflow, 그리고 jj cli를 감싼 최고 수준의 TUI: https://github.com/idursun/jjui

    • Jujutsu의 “중심 개념”이 뭔지 궁금함. Git이 업계 표준이라는 점에 비해 Jujutsu를 써야 할 만한 강력한 이유가 뭔지 잘 감이 안 옴. 개념은 흥미롭다고 생각하지만, 좀 더 명확한 마케팅 관점이 추가되면 활용 가능성이 커질 것 같음. Git의 가장 큰 약점은 외부인에게 너무 불친절하다는 점(전문 용어, 발견 어려움, GUI 프론트 부족 등)이라, 초보자 친화적 VCS의 잠재력이 크다고 봄

    • Magit에서 jujutsu로 갈아탔음. 변한 점은 PR 쌓기가 훨씬 쉬워졌고, 더 작은 단위로 변경을 나누는 습관이 생겨서 “보낼 만한 가치” 기준이 더 엄격해진 점임. 대체로 긍정적 경험이지만, Magit이 이미 잘 맞다면 특별한 강점은 없음. 그래도 https://github.com/bolivier/jj-mode.el 덕분에 Emacs에서 jj도 충분히 쓸 수 있음

  • 흥미롭게 봄. 온라인 활동이 잦음에도 Jujutsu를 이번에 처음 들어봤음. Git을 백엔드로 쓰면서 더 나은 VCS를 제공하는 아이디어가 마음에 듦. 그 이유 중 하나는 여전히 Github-Gitlab으로 백업·공유가 가능하기 때문임. Fossil이나 Bitkeeper도 매력 있지만, git만큼 “충분히” 더 나아서 git의 네트워크 효과를 극복하진 못했음. Jujutsu를 좀 만져봐야겠음. 계속 쓸지는 모르겠지만, 생각 이상으로 괜찮으면 좋겠음

답변달기