Jujutsu 창시자 Martin von Zweigbergk, ERSC CTO로 합류하며 JJ 오픈소스 유지

게시 날짜가 2026년 7월 8일로 돼 있는데 새 소식 맞음?

내가 수정했음. Martin은 그때 합류했고, 오늘 올리는 글인데 게시 날짜를 오늘로 바꿔야 했음.

JJ를 정말 좋아하는데, 업스트림에서 파일 이름을 바꾼 뒤 그 파일을 건드린 커밋을 main에 리베이스하면 복사 추적이 Git보다 약하더라. 이건 곧 개선될 예정인지 궁금함.

JJ가 더 널리 쓰이지 않으면 이 회사도 가능성이 있나 싶음. VCS를 새로 배우는 부담은 언어보다 작아도, Git을 깊이 배우지 않은 개발자가 많고 Mercurial도 크게 퍼지진 않았음.

ERSC가 정확히 뭐 하는 곳인지 모르겠음.

내가 합류한 이유는 예전에 따로 썼는데, 짧게 말하면 엔터프라이즈용 차세대 소스 제어 시스템을 만드는 회사임.

Git도 있고 JJ는 Git과 동작하는데, ERSC가 GitHub 경쟁사라면 뭘 더 주는지 모르겠음. GitHub의 문제를 어떻게 푸는지도 아직 못 봤고 SourceHut이나 Codeberg도 비슷한 조향 장치를 붙일 수 있지 않나.

JJ의 최종 목표는 자체 백엔드라고 봤음. Git 공존은 사용자를 옮겨오기 위한 호환 단계고, ERSC가 새 채용을 계기로 JJ 포지를 만들 수도 있겠다고 생각함.

우린 SourceHut이나 Codeberg 같은 사회적 코딩 사이트를 만드는 게 아니라 엔터프라이즈 인프라를 만듦. JJ는 여러 백엔드를 쓸 수 있고, Git은 대형 모노레포용으로 설계되지 않아 에이전트를 많이 돌리는 조직에서 성능과 기능 한계가 나타남. Git 입출력도 지원하지만 Git이 못 하는 고급 기능도 있음.

'Git이 JJ가 하는 일을 다 한다'는 말은 좀 단순함. 예를 들어 Git은 충돌을 커밋 안에 저장하지 못하는데, JJ는 Git 객체 DB에 충돌 트리를 저장하면서 충돌 구조 자체는 별도 데이터로 관리함. 디스크 저장 형식은 Git을 써도 알고리즘과 UX는 상당히 다름.

JJ를 그냥 Git UI나 porcelain이라고 부르면 빠지는 부분이 많음. Git만으로도 비슷한 작업은 가능하지만 자연스럽지 않고, JJ는 다른 작업 흐름을 유도함. 명령은 하루 만에 익혔지만 그 모델을 이해하는 데는 한두 달 걸렸고 난 그만한 가치가 있었음.

JJ가 Git 위에서 동작한다고 Git이 JJ를 전부 제공한다는 뜻은 아님. TypeScript가 JS 위에서, QUIC이 UDP 위에서 동작하는 것과 비슷한 얘기임.

'할 수 있음'과 '마찰 없이 쉽게 할 수 있음'은 다름. 어셈블리로 Python이나 Rust가 하는 일을 할 수 있어도, 굳이 어셈블리로 개발하고 싶진 않잖아.