Git 이후의 버전 관리를 향한 ERSC의 도전

What Comes After Git

Git 이후의 버전 관리를 향한 ERSC의 도전

Steve Klabnik이 이끄는 East River Source Control(ERSC)이 Git 프로토콜을 그대로 사용하면서도 저장소 엔진을 자체 개발해 확장성과 안정성을 높이는 새로운 버전 관리 시스템을 구상 중이다. 에이전트 기반 개발이 몰고 온 대규모 코드와 모노레포 문제를 해결하기 위해, Git 클라이언트와 호환되면서도 Jujutsu(jj) 같은 차세대 도구를 수용할 수 있는 유연한 저장 계층을 목표로 한다.

우리는 Git이 소스 관리의 미래라고 믿지 않는다. Git은 수년간 개발자들에게 잘 봉사해 왔지만, 2005년의 제약을 기준으로 설계된 것이지 2025년, 심지어 2035년을 염두에 둔 것이 아니다.
  1. nrr

    여기 다른 댓글들에 동의합니다: 이 글은 ERSC가 미래를 위해 Git을 어떻게 개조하려는지(마이그레이션 경로로서의 Jujutsu를 넘어서) 또는 미래[0]에 Git(우리가 아는)이 설 자리가 없는 이유에 대해 세부 사항이 정말 빈약합니다.

    저는 우연히 이 문제[1]에 대한 기술적 맥락을 가지고 있는데, 이 발표를 보고 상당히 실망했습니다. 적어도 pack-protocol 와이어 포맷이 얼마나 빌어먹을 정도로 고통스러운지 언급이라도 해주지! Git의 속사정에 깊이 빠져 있는 기술적인 우리들에게 함께 욕할 거리를 좀 주라고요!

    그래도 Fossil이 언급되긴 했네요! \o/

    --

    0: 네, 그들은 에이전틱 개발 패턴과 모노레포 지향 패턴이 부딪히는 제약을 언급하지만, 세부 사항은 손을 흔들어 넘겨버립니다. 특히 어떤 에이전틱 개발 패턴이 Git을 압박하는 걸까요? 에이전트를 쓰지 않거나 접해본 적이 제한적인 우리에게는 별로 명확하지 않지만, 그 사용 패턴은 거의 확실히 작은 규모의 회사들이 겪을 다른 Git 사용 방식에도 반영되어 있을 겁니다.

    1: 저는 심지어 Git의 오브젝트 스토어를 append-only 로그에 더 가깝게 재작업해서, 예를 들어 과중한 GitOps 워크플로가 때때로 일으킬 수 있는 문제들, 하물며 에이전틱 개발에 대한 열풍까지 완화할 수 있을지 오랫동안 깊이 고민해 봤습니다. 말하자면 이 분야는 누군가 들어와서 더 잘 만들어 줄 준비가 되어 있지만, 버전 관리는 기술적인 사람들을 위한 기술적인 도구입니다.

  2. rbsmith

    이건 여기 많은 댓글들에 대한 반응이라기보다는, 그들이 어떤 가치를 가져올 수 있는지에 대한 관점을 제공하는 글입니다.

    저는 버전 관리/SCM 분야에서 35년 이상을 보냈고, 그 절반은 BitKeeper 팀의 일원으로서 보냈습니다. 거기서 제 일은 세트, 그래프, 위브를 팀 맥락에서 고민하는 것이었고, 상용 고객들의 삶을 개선하면서 오픈 소스 세계에도 이익이 되도록 하는 것이었습니다.

    Git이 당신에게 충분히 좋다면, 그것이 모든 사람에게 그렇지는 않다는 걸 아세요. 그 모든 사람 중 일부에게는 그 고통을 없애기 위해 돈을 지불할 가치가 있습니다. 그리고 그 고통을 없애는 것의 일부는 현재 세계와 연결을 유지하고, 현재 세계의 충분한 상위 집합이 되어, 호환되지 않는 방식으로 더 나아지지 않는 것입니다. 그게 제가 Steve와 팀이 그리는 그림에서 보는 것입니다: 고통을 없애기 위해 기꺼이 돈을 지불하려는 일부에게 더 나은 방식으로 Git과 상호작용하는 세계.

    Non-Git Storage Engine에 대해서는 별로 언급이 없다는 데 동의합니다. 제 인생의 절반을 그 세계에서 보냈기 때문에 이해합니다: 비밀 소스죠. 한동안은 별로 언급되지 않을 거라고 예상합니다.

  3. EddieRingle

    다른 댓글들처럼, 저도 이게 Git 경쟁자를 홍보하고 또 하나의 지나치게 특정한 "컨퍼런스"를 홍보하는 것 외에 무엇을 하려는 건지 매우 혼란스럽습니다. 이 글은 논증을 해야 하는 섹션에서조차 실제로 어떤 논증도 하지 않습니다. 그리고 왠지 모르게 GraphQL을 이 mix에 추가하고 있네요, 어떻게든?

  4. asmnzxklopqw

    그들이 해결하려는 문제가 뭔가요? 이 부분은 아직도 저에게 명확하지 않습니다.

  5. fergie

    저에게 Git이 훌륭하지 않은 실제 부분은 데이터(베이스) 버전 관리인데, 이 글은 그걸 다루지 않는 것 같습니다. 사실 저는 이 글에서 제안하는 문제/해결책을 파싱하는 데 애를 먹고 있습니다.

이 날의 다른 글

2026-09-11