# Evan의 Jujutsu 튜토리얼

> Clean Markdown view of GeekNews topic #31399. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31399](https://news.hada.io/topic?id=31399)
- GeekNews Markdown: [https://news.hada.io/topic/31399.md](https://news.hada.io/topic/31399.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-13T23:05:43+09:00
- Updated: 2026-07-13T23:05:43+09:00
- Original source: [evmar.github.io](https://evmar.github.io/jjtut/)
- Points: 1
- Comments: 1

## Topic Body

- Git 사용 경험자가 단순하면서도 강력한 버전 관리 시스템 **Jujutsu(jj)** 를 간결하게 익힐 수 있도록 구성한 튜토리얼임
- 학습에 앞서 Jujutsu를 사용할 이유가 궁금한 독자를 위해 별도의 **Jujutsu 소개 글**을 제공함
- 대화체 입문서, 세부적인 공식 문서, 버전 관리 초심자용 자료 등 **독자 수준에 맞는 대안**도 안내함
- 주제의 선택과 생략, 배치 순서를 신중하게 결정하기 위해 **Evan Martin이 직접 집필**함
- 본문 작성에는 AI를 사용하지 않았으며, 대부분을 완성한 뒤 **오류 점검에만 AI를 활용**함

---

### 대상 독자와 학습 경로
- [Jujutsu](https://www.jj-vcs.dev/)는 단순하면서도 강력한 버전 관리 시스템이며, 튜토리얼에서는 이후 **jj**로 표기함
- **Git에 익숙한 독자**를 대상으로 핵심에 집중한 간결한 학습 흐름을 제공함
- 바로 학습하려면 [튜토리얼 시작하기](https://evmar.github.io/jjtut/basics/)로 이동할 수 있으며, 도입 이유부터 살펴보려면 [Jujutsu 소개 글](https://evmar.github.io/jjtut/pitch)을 참고할 수 있음

### 독자별 대안 자료
- 이 튜토리얼의 방식이 맞지 않는다면 경험 수준과 선호에 따라 다음 자료를 선택할 수 있음
  - [Steve's Jujutsu tutorial](https://steveklabnik.github.io/jujutsu-tutorial/): 가장 추천하는 입문 자료로, 대화체로 구성됨
  - [Jujutsu documentation](https://www.jj-vcs.dev/latest/): 처음부터 세부 내용을 더 많이 다루는 공식 튜토리얼을 제공함
  - [Jujutsu for Everyone](https://jj-for-everyone.github.io/): 이전 **버전 관리 경험이 없는 독자**를 대상으로 함

### 직접 집필과 AI 사용 범위
- 전체 텍스트는 [Evan Martin](https://neugierig.org/)이 직접 작성했으며, 무엇을 포함하거나 생략할지와 어떤 순서로 배치할지를 사람이 신중하게 결정함
- 본문을 만드는 데는 **AI를 사용하지 않았고**, 대부분을 작성한 뒤 오류를 확인하는 용도로만 활용함

## Comments



### Comment 61737

- Author: neo
- Created: 2026-07-13T23:05:44+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/beqyuc/evan_s_jujutsu_tutorial) 
- 솔직히 평판을 걸고 말하자면, `jj`를 일주일가량 써 봤지만 결국 Git을 직접 다루는 고통을 줄이려고 LLM에 도움을 청하게 됐고, 기존 작업 흐름을 충분히 대체한다는 느낌도 받지 못했음  
  평소에는 `git checkout`, `git add`, `git commit`, `git push` 정도만 쓰며, 홍보 글에서 말하는 인덱스·스태시·여러 종류의 리셋·진행 중인 리베이스·일관성 없는 실행 취소 문제도 거의 겪지 않았고 모노레포도 잘 쓰지 않음  
  **Jujutsu의 주 대상**은 누구인지, 또 `jj`를 능숙하게 쓰기까지 얼마나 걸렸는지 궁금하며 다음에는 최소한 그 정도 기간은 투자해 보고 싶음
  - LLM에는 구체적으로 어떤 작업을 도와달라고 하는지 궁금함  
    나도 Git에서는 기본 작업 외에는 피하는 편이라, 스태시 후 브랜치를 바꾸는 대신 저장소를 다른 위치에 다시 복제했고 관련 변경만 골라 커밋하는 대신 `git add --all`로 전부 커밋하거나 편집기에서 변경을 되돌린 뒤 커밋하고 다시 적용했음  
    직장에서 Mercurial을 7년 사용해 `jj`에 적응하기 쉬운 배경이 있었지만, 이제는 **커밋 재배치와 여러 변경 관리**가 간단해져 예전이라면 본능적으로 우회했을 복잡한 작업도 적극적으로 하게 됨
  - 무엇을 위해 버전 관리 시스템(VCS)을 쓰느냐에 따라 관점이 달라짐  
    선형으로 개발한 코드를 가끔 스냅샷으로 남기는 정도라면 그 명령들로 충분하고, 완전한 VCS가 과해서 Dropbox만으로도 될 수 있음  
    내게 VCS는 코드와 그 계층을 어떻게 사고했는지 보여 주는 **서사 구축 도구**이며, 주 독자는 동료이고 부 독자는 10년 뒤의 나임. `jj`는 이를 훨씬 마찰 없이 다룰 수 있게 해줌
  - LLM에 도움을 청해도 괜찮으며, 나도 필요한 기본 명령을 익힐 때까지 그렇게 했음  
    용어와 기능의 기초를 잡으려고 안내서 몇 개를 처음부터 끝까지 읽고 개인 프로젝트에서 며칠간 꾸준히 사용하니 기본 작업은 꽤 능숙해졌고, VCS를 바라보는 방식도 달라졌음  
    리팩터링이나 큰 기능을 개발할 때는 먼저 최종 목표까지 구현한 다음, 검토하기 쉽고 각각의 근거가 명확하도록 “모든 eslint 경고 수정”, “함수 노출을 위한 리팩터링”, “호출부 A를 새 함수로 전환”, “새 기능 추가” 같은 작은 변경으로 나눔. **`jj split`** 은 이 작업에 완벽하며, 이 기능 하나만으로도 `jj`를 쓸 이유가 충분함  
    반면 `git stash`는 여러 스태시를 다루기 어렵고 충돌 시 저장한 코드를 잃을 수도 있는 위험한 사용성 함정이 많음. 낮은 커밋에 PR 피드백을 반영한 뒤 위의 커밋이나 PR을 리베이스하는 일도, 특히 스택형 PR에서는 진행 표시가 없고 중간에 멈추거나 다시 쌓기 어려워 악몽에 가까움. 그래서 스택형 PR 관리는 여전히 Graphite를 사용함
  - `jj`에서 가장 크게 얻은 이점은 **리베이스 처리 방식**임  
    유기화학 전공 대학원생이 논문 작업용 브랜치를 4년간 병합이나 리베이스 없이 개발해 `main`보다 수천 커밋 뒤처진 상태에서 학위 심사를 앞두고 병합해야 했음. 거의 모든 커밋에서 충돌이 나므로 Git으로는 1~2주가 걸리고, 사흘째 긴급 버그가 들어오면 리베이스를 중단해 버그를 고친 뒤 처음부터 다시 시작해야 했으며, 3주 뒤 끝냈을 때는 최신 `main`에 맞추려고 또 리베이스해야 했음  
    `jj`에서는 **병합 충돌이 일급 객체**라 여유 있을 때 해결할 수 있고, 도중에 새 커밋으로 이동해 긴급 버그를 고쳐도 진행 상황을 잃지 않음. Git에서 일주일 걸릴 리베이스를 하루 만에 끝낼 수 있었고, 한 번은 합쳐도 아무 변화가 없는 연속된 200개 커밋을 찾아내 수만 줄의 충돌을 이틀간 처리하던 작업을 1분도 안 돼 통째로 버렸음. 리베이스 중에도 `main`을 갱신하고 작업 중인 브랜치를 최신 `main` 위로 옮길 수 있음

- Git에 너무 익숙해 가끔 명령을 찾아보는 정도인 내게도 [이 글](https://evmar.github.io/jjtut/pitch/)은 처음으로 흥미롭게 느껴진 **Jujutsu 소개 글**임  
  이전 글들은 주로 “끔찍한 Git 명령줄 인터페이스에서 벗어날 수 있다”로 시작했는데, Git의 특이한 점과 다른 이들의 어려움은 이해해도 그런 표현 때문에 Jujutsu를 로맨스 소설이나 비프 빈달루처럼 나와 무관한 것으로 여겼음
  - `jj`의 즐거움을 설명하기 어려운 이유는 모든 VCS에 당연히 있다고 여겼던 암묵적 특성들이 실제로는 그렇지 않았고, **원자적 동작**이 훨씬 단순하기 때문임  
    좋은 홍보 문구를 만들기 어려우니 결국 “Git이 아니다”라는 말이 설명을 전부 차지하게 되며, 나 역시 이를 제대로 설명하지 못하는 편임
  - Git에서는 **Sublime Merge** GUI와 몇 가지 사용자 정의 명령을 이용하면 여기서 말하는 문제를 거의 해결할 수 있음  
    다른 Git GUI와 달리 실제 Git 명령을 최대한 그대로 따르면서 난해한 문법만 메뉴와 버튼으로 바꾸고, 각 동작에 해당하는 명령도 숨기지 않고 상태 표시줄에 기록해 줌. Sublime JJ가 나온다면 즉시 갈아탈 생각임
  - 내가 `jj`를 써 보고 싶게 만든 표현은 **항상 대화형 리베이스 상태인 Git**이었음