Git은 계속 쓰이겠지만, 대규모 코드 저장소를 운영하는 기업들은 자체 버전 관리 시스템을 만들거나 Git과 다른 방식으로 코드를 관리한다. Google의 Piper와 Meta의 Sapling은 규모와 접근 제어 문제를 다루며, Jujutsu(JJ)는 Git과 호환되면서 작업 흐름을 바꾸려 한다. Anthropic은 에이전트가 코드를 작성하는 환경을 겨냥한 Scion을 개발했다.
Git과 호환되는 JJ
Jujutsu(JJ)는 Git의 설계를 다시 살펴 병합 충돌을 더 잘 전달하고 개발자의 부담을 줄이려는 버전 관리 시스템이다. 작업 중인 변경 사항을 자동으로 커밋해 스테이징 영역을 없애고, 브랜치 대신 커밋과 그 계층 구조를 중심으로 작업한다. Git과 호환되며, 브랜치와 원격 브랜치 추적에는 북마크를 활용한다. 따라서 JJ를 쓰면서도 GitHub를 비롯한 Git 기반 서비스를 이용할 수 있다.
Google의 Piper와 Meta의 Sapling
Google의 Piper는 거대한 모노레포를 위한 중앙 집중식 버전 관리 시스템이다. 여러 머신에 분산하고 중복성을 높여 세계 각지의 직원이 코드에 효율적으로 접근하도록 한다. 파일 단위 접근 제어와 감사 로그도 제공해 민감한 알고리즘에 대한 접근을 제한하고, 누가 어떤 파일을 읽었는지 확인할 수 있게 한다.
Piper에서는 코드 리뷰를 거친 뒤에야 새 코드를 반영하므로 일반적인 브랜치 개념이 없다. 직원은 클라우드의 클라이언트를 통해 작업하며, 전체 저장소를 복제하는 대신 가상 파일 시스템을 이용한다. 각 개발자가 차지하는 메모리를 줄이기 위해 클라이언트에는 수정된 파일만 저장한다는 설명이다.
Meta의 Sapling은 이와 유사한 기능을 갖춘 오픈소스 시스템이다. Git과 비교하면 이름이 붙은 로컬 브랜치를 요구하거나 권장하지 않고, 스테이징 영역도 없다. 다만 JJ에는 없는 Git의 커밋·수정(amend) 방식이 있으며, Piper처럼 파일과 데이터를 필요할 때 가져올 수 있다. Sapling 저장소는 GitHub에서 확인할 수 있다.
버전 관리 서버의 기능은 클라이언트 기능과 구분된다. 실제 데이터를 보관하는 서버는 접근 제어와 중복 저장을 담당할 수 있으며, Meta는 Mononoke라는 오픈소스 서버 구현도 제공한다. Mononoke 문서에서 자세한 내용을 볼 수 있다.
에이전트를 위한 Anthropic의 Scion
Anthropic은 에이전트가 코드 대부분을 작성하고 항상 온라인이라는 전제를 바탕으로 Scion을 만들었다. 오프라인 작업을 염두에 둔 Git 복제 방식이 에이전트에게는 필요하지 않다는 설명이다. Anthropic은 관련 글에서 Piper와 Sapling과 같은 접근을 택했다고 밝혔으며, 데이터 모델을 Bonsai라고 이름 붙였다.
Scion은 대용량 저장소에서 개발자 쪽에 필요한 데이터 양을 줄이도록 차이점과 이력 계산을 서버로 옮긴다. 커밋도 서버에서 처리해 개발자 쪽에는 최소한의 정보만 두는 방식이다. 대신 서버에 계속 접속할 수 있어야 한다. 사용자나 에이전트는 저장소 일부를 가져오거나 서버에 두 파일의 차이를 직접 요청할 수 있다.
Git은 계속 쓰이겠지만, 이 사례들은 코드 규모가 커질수록 기업이 내부 코드의 버전 관리 방식을 새로 만드는 경향을 보여준다. JJ는 이런 규모 중심의 흐름과 달리 개발자의 작업 경험을 개선하려는 사례다. AI 코딩 시대에도 개발자 경험이 얼마나 중요할지는 아직 알 수 없지만, 20년 된 버전 관리 시스템에 새로운 접근이 등장하고 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요