▲

나는 jj에서 미래를 본다

 (steveklabnik.com)
6P by GN⁺ 16시간전 | ★ favorite | 댓글 2개
  • 새로운 버전 관리 시스템 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와 함께 새로운 장으로 이어지고 있음
▲
tujuc 8시간전  [-]

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

답변달기
▲
GN⁺ 16시간전  [-]
Hacker News 의견

  • 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)을 오래 썼는데, jj의 UX가 완전히 자연스럽진 않지만 단축키 커스터마이즈로 해결될 문제 같음
    • Git 위에 좋은 UX를 얹는 게 왜 중요한지 이해한다면 jj의 철학 95%는 이미 이해한 것임
    • jj에서도 git index를 쓸 수 있음. 단, git_head를 바꾸는 jj 명령만 안 쓰면 됨. 나는 staged 변경으로 커밋하는 alias를 만들어서 쓰고 있음 (config.toml 예시)

  • 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)

    • ‘jjhub’은 괜찮은 첫 단계라 생각함. 이미 jj를 github과 함께 쓸 수 있지만, 그 이상으로 가치 있는 무언가를 제공해야 함
    • 참고로 이런 것도 있음: 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 같은 도구로 일부 경험을 얻을 수 있음. GitHub SVP가 jj에 관심을 보였다는 트윗도 있었음. 또, 이슈를 리포 안에 넣는 시스템으로 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은 정말 멋진 이름임

답변달기