소프트웨어는 커밋 사이에서 만들어진다

1 hour ago 1

DeltaDB는 에이전트와 나눈 대화, 에이전트가 편집한 워크트리를 함께 버전 관리하는 새로운 형태의 버전 관리 시스템임
Git은 개별 커밋 중심으로 구성되어 코드가 계속 바뀌는 동안 이어지는 대화와 코드 변경을 함께 다루도록 설계되지 않았음
DeltaDB는 커밋뿐 아니라 작업 중 발생하는 모든 연산을 세밀한 델타 스트림으로 기록하고, 각 델타에 안정적인 식별자를 부여함
메시지와 그 메시지가 만든 편집이 나란히 기록되며, 여러 사람과 에이전트가 서로 다른 머신에서 같은 파일을 동시에 편집할 수 있음
협업은 커밋과 푸시 이후의 리뷰 절차보다, 코드가 만들어지는 중의 대화와 워크트리 안에서 더 직접적으로 이뤄질 수 있음

배경과 문제의식

Zed 팀은 풀 리퀘스트 방식에 익숙하지 않았고, 같은 워크트리에서 함께 작업하며 코드를 작성하는 중에 토론하는 방식으로 신뢰와 공유 이해를 쌓아왔음
GitHub는 커밋하고 푸시한 뒤에야 코드에 대해 이야기할 수 있게 하지만, Zed 팀의 중요한 대화는 보통 그 시점 전에 이미 끝났음
Zed는 2021년에 커밋의 제약을 넘어서기 위해 시작됐고, 먼저 세계 최고 개발자에게 걸맞은 에디터를 만든 뒤 그 안에서 더 나은 협업 방식을 제공하려 했음
인간끼리의 협업 맥락에서 오래 고민해온 문제는 에이전트와 협업할 때 더 중요해졌음
코드를 생성하는 대화가 점점 소프트웨어의 실제 원천이 되고 있으며, 그 대화는 지속적으로 전개되고 변화하는 코드와 상호 참조되어야 함
Git은 개별 커밋을 중심으로 구성되어 있어 이런 지속적 대화와 코드 변화의 연결을 지원하도록 설계되지 않았음

DeltaDB와 다음 단계

모든 커밋이 아니라 모든 연산
- DeltaDB는 작업을 세밀한 델타 스트림으로 나누며, Git이 커밋마다 스냅샷을 저장하는 것과 달리 커밋 사이의 모든 연산을 기록함
- 각 델타는 안정적인 식별자를 가지므로, 코드가 계속 바뀌는 중에도 진화 과정의 특정 순간을 가리킬 수 있음
- 워크트리는 변화하는 과정 자체가 버전 관리되며, 그 변화를 이끄는 대화와 함께 다뤄짐
- 메시지와 그 메시지가 만들어낸 편집은 나란히 기록되어 서로 분리되지 않음
- DeltaDB는 충돌 없는 복제 워크트리를 내장해 여러 사람과 에이전트가 서로 다른 머신에서 같은 파일을 동시에 편집할 수 있음
- 파일은 실제 파일이며, 에이전트는 터미널을 통해 파일에서 작업하고 사용자는 필요할 때 전체 워크트리를 디스크에 마운트해 자신의 도구를 사용할 수 있음
소스 코드는 이제 소스 대화
- 참조가 줄 번호가 아니라 델타에 고정되기 때문에, 코드가 아래에서 이동해도 참조가 유지됨
- 과거 대화의 어떤 줄에서도 현재 상태의 코드나 에이전트가 작성했던 당시의 코드로 이동할 수 있음
- 어떤 코드 줄에서도 그 코드를 만든 대화와 이후 그 코드를 건드린 모든 대화를 찾을 수 있음
- 에이전트도 이 정보를 활용해 자신이 건드리는 코드의 배경 맥락을 가져올 수 있음
- 에이전트는 이전에 해당 코드에서 작업한 에이전트를 불러와 왜 그런 방식으로 작성됐는지 물을 수 있음
협업을 위해 커밋할 필요가 없어야 함
- 에이전트와의 대화가 협업에 필요한 유일한 대화가 되는 것이 목표임
- 팀원은 작업이 아직 진행 중일 때 참여해, 작업을 수행한 에이전트와 대화하고 진행 중에 주석을 달 수 있음
- 팀원이 참여하기 위해 먼저 커밋과 푸시를 기다릴 필요가 없음
- 풀 리퀘스트, 리뷰 스레드, 인라인 댓글은 코드와 논의가 서로 다른 장소에 있었기 때문에 나중에 토론을 코드에 다시 붙이기 위한 절차였음
- 코드와 논의가 같은 장소에 있으면 그런 절차는 사라짐
- Git과 CI는 검사를 실행하고 외부 세계와 연결하는 역할에 머물며, 협업이 강제로 일어나는 장소가 되지 않음
다음 단계
- 소프트웨어는 이제 커밋이 아니라 대화 속에서 형태를 갖춰감
- DeltaDB는 이를 위한 버전 관리 시스템이며, 몇 주 안에 초기 사용자에게 제공될 예정임
- 먼저 사용해보고 싶다면 대기자 명단에 등록할 수 있음