Git 다음에는 무엇이 올까

East River Source Control(ERSC)은 기존 Git 클라이언트와 프로토콜을 그대로 사용하면서, 서버에서는 자체 엔진에 코드를 저장하는 버전 관리 시스템을 개발 중임 AI 에이전트가 병렬로 작업하면서 저장소 크기, 활성 브랜치 수, 병합 경합이 커짐. 격리된 클라우드 환경에서 작업을 시작할 때 빠르게 클론할 필요도 커짐 Git 호환성을 유지해 기존 도구를 계속 쓸 수 있게 하고, 자체 저장 엔진의 수평 확장과 고객별 분리 배포로 저장소 부하에 대응하려 함 팀원마다 Git과 Jujutsu(jj) 중 원하는 클라이언트를 쓸 수 있음. 장기적으로는 jj가 Git 프로토콜 외의 별도 프로토콜로 같은 저장 엔진에 접근하는 방식도 구상 중 저장소부터 제공하고 코드 리뷰, CI, 이슈 추적은 기존 도구와 조합할 수 있게 할 것이며, 저장소를 먼저 제공하고, 이후 자체 제품과 외부 도구를 함께 사용할 수 있도록 할 계획 에이전트 개발이 바꾸는 버전 관리 요구 소프트웨어 개발은 본질적으로 협업 작업이며, 작은 프로젝트부터 수십억 줄 규모의 모노레포까지 소스 코드를 안전하게 보관하고 변경 이력을 관리하며 개발자에게 제공하는 일이 중요함 코드가 공유 서버에 있던 시기를 거쳐 소스 코드 관리(SCM) 와 버전 관리 시스템(VCS) 이 발전함 오픈소스에서는 CVS, SVN, Git이 널리 쓰였으며, 그 밖의 버전 관리 도구로 Perforce, ClearCase, Fossil, Mercurial, SCSS, Monotone, BitKeeper 등이 있음 에이전트 기반 개발은 이전보다 더 많은 코드를 빠르게 생산하면서 저장소 크기, 활성 브랜치 수, 새 작업을 병합할 때의 경합을 늘림 에이전트는 더 많은 맥락에 쉽게 접근할 수 있는 모노레포와 잘 맞지만, 이로 인해 규모 관련 문제가 커짐 개발 환경이 격리된 클라우드 환경으로 이동하면서 빠른 복제도 필요해짐 과거 대규모 조직에 집중됐던 문제가 작은 조직에도 나타나고 있음 ERSC는 조직의 목표와 규모가 커질수록 차세대 VCS가 필요해질 것으로 봄 소스 코드는 조직의 중요한 자산이므로 새 도구 도입에 신중할 이유가 있으며, 전환에는 보상뿐 아니라 위험도 있음 기존 환경에서 미래 환경으로 점진적으로 이동할 수 있는 연결 경로를 만들고 있음 Git 호환 인터페이스와 자체 저장 엔진 일반적인 Git 호스팅 구조에서는 클라이언트가 Git 프로토콜로 서비스에 접속하고, 서비스 계층...