# 나는 jj에서 미래를 본다

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23869](https://news.hada.io/topic?id=23869)
- GeekNews Markdown: [https://news.hada.io/topic/23869.md](https://news.hada.io/topic/23869.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-10-24T03:37:53+09:00
- Updated: 2025-10-24T03:37:53+09:00
- Original source: [steveklabnik.com](https://steveklabnik.com/writing/i-see-a-future-in-jj/)
- Points: 12
- Comments: 2

## Summary

Rust로 구현된 새로운 **버전 관리 시스템 jj**가 Git의 복잡한 내부 구조를 단순화하며 점진적 도입이 가능한 대안으로 주목받고 있습니다. Git 저장소와 완전 호환되면서도 **더 직관적인 워크플로**를 제공해, 대규모 조직과 개인 개발자 모두에게 실용적 선택지를 제시합니다. Google과 Oxide 등에서 실제 사용이 확산 중이며, **열정적인 커뮤니티와 전문 개발팀**이 형성되면서 초기 Rust 생태계를 떠올리게 하는 성장세를 보이고 있습니다.

## Topic Body

- 새로운 **버전 관리 시스템 jj**는 Rust로 작성된 프로젝트로, 기존 Git의 한계를 보완하며 점진적 도입이 가능한 구조를 지닌 도구임  
- 저자는 과거 Rust의 성장 가능성을 분석했던 경험을 바탕으로, jj 역시 **시장 적합성·전문 팀·사용자 기반** 측면에서 유사한 잠재력을 지닌다고 평가함  
- jj는 **Git 저장소와 호환**되면서도 더 단순한 워크플로를 제공해, 특히 Git 내부 구조에 익숙하지 않은 개발자에게 접근성이 높음  
- Google과 Oxide 등에서 실제 사용이 확산되고 있으며, **열정적인 커뮤니티와 헌신적인 개발팀**이 형성되고 있음  
- 저자는 jj 기반 협업 플랫폼을 개발하는 **ERSC**에 합류하며, Rust 초기 시절처럼 jj 생태계의 성장을 직접 이끌 계획임  

---
### Rust를 선택했던 이유
- 저자는 2012년 크리스마스에 Hacker News에서 **“Rust 0.5 released”** 소식을 보고 언어에 관심을 갖게 됨  
  - 당시 Ruby on Rails 개발자였지만, 대학 시절부터 **컴파일러와 시스템 프로그래밍**에 흥미가 있었음  
- Rust의 성공 가능성을 판단할 때 세 가지 요소를 고려함: **시장 적합성, 개발팀, 사용자 기반**  
  - C/C++을 대체할 신뢰할 만한 언어가 없었고, Rust는 **가비지 컬렉션 없이 메모리 안전성**을 제공하는 혁신적 접근을 제시함  
  - Mozilla가 후원하며 Firefox에 Rust를 도입하려는 계획이 있었기에, 실사용 기반 확보 가능성이 높다고 판단함  
- Rust 커뮤니티의 **친절하고 협력적인 분위기**도 매력적 요인으로 작용  
  - 이후 저자는 “Rust for Rubyists” 튜토리얼을 작성하고, 공식 문서 공동 저자로 참여하게 됨  

### jj의 등장
- **jj(Jujutsu)** 는 프로그래밍 언어가 아닌 **새로운 버전 관리 시스템(VCS)** 으로, Rust로 구현됨  
  - Git과 호환되며, 기존 저장소를 그대로 사용하면서 점진적으로 도입 가능  
- 저자는 기술적 취향이 비슷한 개발자 **Rain**의 추천을 계기로 jj를 탐색하기 시작함  
  - Rain은 Meta의 소스 관리팀 출신으로, 그녀의 추천은 신뢰할 만한 신호로 받아들여짐  
- 주말에 jj를 직접 실험하며 **튜토리얼 작성 프로젝트**를 시작함  
  - Rust 학습 때와 마찬가지로, 글을 쓰며 개념을 정리하는 방식으로 접근  
  - 결과적으로 튜토리얼이 커뮤니티에서 긍정적 반응을 얻음  

### jj의 미래 전망
- 저자는 jj에서 Rust 초기와 유사한 **성장 패턴**을 봄  
  - 시장 적합성, 팀 역량, 사용자 확산 가능성 모두 긍정적임  
- **시장 적합성** 측면에서 Git이 절대적 우위를 점하고 있지만, jj는 Git 저장소를 그대로 다룰 수 있어 **부분적 도입**이 가능함  
  - Oxide 내부에서도 Rain을 시작으로 사용이 확산되어 전용 채널이 생길 정도로 관심이 높음  
- **Google 내부에서도 jj가 사용**되고 있으며, 이는 Mozilla가 Rust를 채택했던 것과 유사한 신호로 해석됨  
  - Google의 대규모 모노레포(Piper 백엔드 기반)에서도 일부 프로젝트가 jj를 활용 중이며, 이는 **사회적 신뢰 증거(social proof)** 로 작용  
- 학습 곡선은 존재하지만, Git 내부 구조에 익숙하지 않은 사용자에게는 오히려 **더 직관적이고 간단한 사용성**을 제공  
  - Git 전문가일수록 새로운 개념에 적응이 필요하지만, 일반 개발자는 빠르게 익숙해짐  
- jj 커뮤니티는 **열정적이고 친근한 분위기**로 성장 중이며, 이는 초기 Rust 커뮤니티를 연상시킴  

### jj 팀과 커뮤니티
- 창시자 **Martin**은 jj 개발에 오랜 기간 헌신해왔으며, 최근에는 개인 계정에서 **공식 조직 계정으로 이전**하고 거버넌스를 정비함  
- 팀 구성원들은 **소스 제어 도구 개발 경험이 풍부한 전문가들**로, 기술적 방향성과 품질 관리에 강점을 보임  
- 커뮤니티는 활발한 피드백과 협업을 통해 빠르게 성장 중이며, **초기 Rust 커뮤니티의 긍정적 에너지**를 재현하고 있음  

### 새로운 도전: ERSC 합류
- 저자는 **Oxide를 떠나 jj 기반 협업 플랫폼을 개발하는 스타트업 ERSC**에 합류하기로 결정함  
  - Oxide는 훌륭한 직장이었지만, jj 생태계에 더 깊이 참여하고자 하는 열망이 결정적 요인이 됨  
- ERSC는 jj 위에 **개발자 협업 플랫폼**을 구축할 예정이며, GitHub가 Logical Awesome이라는 법인명으로 출발했던 사례를 언급하며 비슷한 초기 단계를 설명함  
- 저자는 Oxide에서의 업무를 마무리한 뒤 휴식을 취하고, 이후 jj 커뮤니티 활동과 튜토리얼 완성에 전념할 계획임  
  - Discord에서의 활동 확대, 블로그 연재, 커뮤니티 기여 등을 예고함  
- 2025년을 **새로운 전환점**으로 평가하며, 자신이 진정으로 열정을 느끼는 프로젝트에 도전할 수 있음에 감사함을 표현  

### 결론
- 저자는 jj가 **Rust의 성장 궤적을 재현할 잠재력**을 지닌다고 확신함  
  - Git과의 호환성, 점진적 도입 가능성, 헌신적인 팀, 그리고 활발한 커뮤니티가 그 근거임  
- jj는 단순한 도구를 넘어, **개발자 협업 방식의 혁신 플랫폼**으로 발전할 가능성을 보여줌  
- Rust에서 시작된 저자의 여정은 이제 jj와 함께 새로운 장으로 이어지고 있음

## Comments



### Comment 45403

- Author: tujuc
- Created: 2025-10-24T11:27:57+09:00
- Points: 1

여러번 나왔던 건데 한번 봐야겟네요.

### Comment 45382

- Author: neo
- Created: 2025-10-24T03:37:53+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45672280) 
- jj를 두 번 정도 진지하게 써봤음. **first-class conflict** 개념은 멋지지만 실제로는 충돌 해결보다 **staging/commit**을 훨씬 자주 하게 됨. magit에서 오다 보니 jj의 hunk 분할과 선택 기능은 너무 불편하게 느껴졌음. 나는 rebase를 자주 하는 편이라 magit의 rebase 단축 기능으로 이미 jj의 장점을 대부분 누리고 있었음. 나 같은 사람에게는 jj가 magit을 이기려면 hunk 선택 UX가 훨씬 개선되어야 함
  - jj에서는 staging이나 commit을 생각하지 않는 게 핵심임. 모든 것이 **변경(change)** 이고, 부모나 더 먼 조상을 북마크로 지정해 그 안에 squash하거나 다음 변경으로 북마크를 옮기는 식으로 사고해야 함
  - 나도 rebase를 자주 하는데, jj의 너무 **의견이 강한 버전 관리 철학**은 별로임. 특히 초보자에게 내부 설계를 너무 숨기는 건 학습에 도움이 안 된다고 생각함
  - magit의 hunk 선택 UX가 구체적으로 어떤지 궁금함. jj의 것과 크게 다르지 않아 보였음. 나는 GitUp([gitup.co](https://gitup.co/))을 오래 썼는데, jj의 UX가 완전히 자연스럽진 않지만 단축키 커스터마이즈로 해결될 문제 같음
  - **Git 위에 좋은 UX**를 얹는 게 왜 중요한지 이해한다면 jj의 철학 95%는 이미 이해한 것임
  - jj에서도 git index를 쓸 수 있음. 단, git_head를 바꾸는 jj 명령만 안 쓰면 됨. 나는 staged 변경으로 커밋하는 alias를 만들어서 쓰고 있음 ([config.toml 예시](https://github.com/CGamesPlay/dotfiles/blob/2484f6f7d0ab302e2afb508a83f9ede49040320d/files/.config/jj/config.toml#L110))

- Git의 대안을 볼 때마다 약간 **루다이트 감정**이 듦. 이미 언어, 프레임워크, 도구가 너무 많음. 최소한 VCS만큼은 Git이라는 거의 보편적인 해법이 있어서 다행이라 생각함. jj가 문제를 해결할 수도 있겠지만, 업계가 두 시스템을 모두 지원해야 하는 부담을 생각하면 순이익이 아닐 것 같음
  - Git의 **UI 부실함**이 너무 짜증나서 대체되길 바람. Git의 개념을 더 잘 설명해주는 새로운 도구가 나왔으면 함
  - jj는 개발자 개인이 선택할 수 있는 옵션임. jj repo는 git repo의 상위집합이라 기존 도구들이 깨지지 않음
  - 예전에 svn을 쓰던 회사에서 `git-svn`으로 Git을 먼저 썼던 경험이 있음. jj도 비슷한 접근을 하는 듯함. jj를 몰라도 기존 CI나 툴이 그대로 작동함
  - Git은 **생산성 저하 요인**이고, 특히 에이전트 기반 코딩 시대에는 더 큰 문제임. jj는 충분히 혁신적이지 않다고 봄. 차라리 **원자 단위(atomic)** 로 변경을 추적하는 새로운 VCS가 필요함. 이런 구조라면 브랜치 개념이 사라지고, 계획(plan)과 원자(atom)로 리포 상태를 구성할 수 있음. 다만 이런 시스템으로 전환하는 건 엄청난 도전이 될 것임
  - rcs, cvs, svn을 거쳐 git이 나왔듯, git도 언젠가 더 나은 것으로 대체될 것임

- jj를 써봤지만 나는 **Sublime Merge**에 익숙함. CLI로 버전 관리를 하면 반복 입력이 많고 상태를 잃기 쉬움. GUI에서는 상태가 항상 보이고 클릭 한 번으로 diff나 커밋 메시지 입력이 가능함. 키보드로 hunk를 선택하는 건 다시는 하고 싶지 않음. SM은 정말 쾌적함. jj GUI가 발전하거나 SM에 jj가 통합되면 좋겠음

- 진짜 뉴스는 사람들이 **“jjhub”** 같은 걸 만들기 시작했다는 점임 ([ersc.io](https://ersc.io/))
  - ‘jjhub’은 괜찮은 첫 단계라 생각함. 이미 jj를 github과 함께 쓸 수 있지만, 그 이상으로 **가치 있는 무언가**를 제공해야 함
  - 참고로 이런 것도 있음: [Stacking 블로그 글](https://blog.tangled.org/stacking)
  - Gerrit도 jj 개념과 잘 맞고, **Jujutsu change ID** 지원을 추가하는 RFC가 승인됨
  - jjhub라는 이름, 꽤 멋짐
  - 진심으로 성공하길 바람. **Github의 진짜 대안**이 나올 때가 됐음

- Google 내부에서 jj가 확산 중이라는데, Google은 주기적으로 내부 VCS를 바꾸는 경향이 있음. git wrapper, mercurial 확장판, 이제는 jj까지 7년 사이에 다 바뀜
  - 사실 Google 내부 도구 대부분이 수명이 짧음. 그래도 jj는 **변경의 정체성(identity)** 을 유지한다는 점에서 혁신적임. git에서는 rebase나 amend 후 완전히 다른 커밋이 되지만 jj는 동일한 변경으로 추적됨. 다만 jj도 결국 git을 **저장 백엔드**로 계속 쓸 가능성이 높음
  - jj가 계속 유지되길 바람. 회사와 집에서 같은 워크플로를 쓰고 싶음. mercurial보다 훨씬 빠름
  - 이번에는 Perforce fork도 같이 폐기하려는 의도 같음. 외부에서 보기엔 변화가 너무 많음
  - git wrapper는 원래 실험적이었고, mercurial 기반 시스템은 거의 10년 가까이 유지됨

- jj가 **대용량 바이너리 파일**을 git보다 잘 다루는지 궁금함. 게임 개발 쪽에서는 여전히 Perforce가 왕임. git은 LFS가 있어도 충분하지 않음
  - Perforce의 바이너리 지원은 사실상 **Git LFS와 동일**함. 차이는 기업용 지원 여부 정도임
  - jj는 git을 저장소로 쓰고 LFS를 지원하지 않아서, 이 부분은 git과 동일한 한계를 가짐
  - 현재로선 특별한 개선은 없지만, 이 영역은 인지하고 있고 앞으로 변화가 있을 수도 있음

- 하루 정도 **Jujutsu 튜토리얼**을 따라 해봤는데 꽤 괜찮았음. 다만 뭔가 **빠진 퍼즐 조각**이 있는 느낌이었음. 예를 들어 GitHub에 PR을 올릴 때 change id가 실제로 도움이 되는지 궁금했음. 아마 Google 내부 Piper 백엔드에서만 진가를 발휘하는 듯함. ERSC의 계획이 궁금함. 개인적으로는 **오프라인 코드 리뷰**가 내장된 분산형 워크플로우를 원함
  - 즐겁게 써봤다니 기쁨 :) 현재 GitHub에서는 change id의 이점이 거의 없음. 하지만 [jj-spr](https://github.com/LucioFranco/jj-spr) 같은 도구로 일부 경험을 얻을 수 있음. GitHub SVP가 jj에 관심을 보였다는 트윗도 있었음. 또, **이슈를 리포 안에 넣는 시스템**으로 [beads](https://github.com/steveyegge/beads)를 써봤는데 꽤 마음에 듦
  - jj로 만든 커밋에는 `change-id` 헤더가 포함되어 있어서, GitHub이 jj를 몰라도 jj 사용자끼리는 rebase 추적이 가능함. `git cat-file -p HEAD`로 확인 가능함

- 개인 프로젝트에 jj를 1~2개월 써봤는데 꽤 만족스러움. 다만 예전 리비전을 수정할 때 `.gitignore`에 새로 추가된 파일이 실수로 포함될 수 있음. 그 외에는 좋음. 그래도 아직은 **Git 지식이 훨씬 많음**, 천천히 회사에도 도입할 예정임

- 올해 **Sapling/Subversion 회사**에 합류했는데 jj는 아직 못 써봄. 그래도 Sapling은 훨씬 **직관적**이고, 커밋 스택이 브랜치보다 이해하기 쉬움. 다만 Meta의 리뷰 UI 같은 지원이 없으면 어떻게 될지 궁금함. 이런 프로젝트가 꼭 필요함
  - 맞음, **Sapling과 jj는 같은 방향의 동료 프로젝트**임

- 이름이 뭐라 해도 **East River Source Control**은 정말 멋진 이름임