소프트웨어는 커밋 사이에서 만들어진다 — Zed가 공개한 DeltaDB, 깃이 버리는 과정을 기록해요

우리가 매일 쓰는 깃(Git)은 사실 '결과물'만 기억해요. 커밋이라는 스냅샷과 스냅샷 사이에서 벌어진 일들, 그러니까 함수를 세 번 갈아엎은 시행착오, 잠깐 시도했다가 지워버린 접근법, AI 에이전트가 쏟아냈다가 되돌린 코드 같은 건 커밋하는 순간 전부 증발하죠. 러스트로 만든 고성능 에디터로 유명한 Zed 팀이 바로 이 지점을 파고들었어요. '소프트웨어는 커밋 사이에서 만들어진다'는 제목의 글과 함께 DeltaDB라는 새 프로젝트를 공개했거든요.

DeltaDB가 뭐냐면

간단히 말해 에디터에서 일어나는 모든 편집 작업을 잘게 쪼개진 연산(operation) 단위로 기록하고 보관하는 데이터베이스예요. 깃이 완성된 사진만 모아둔 앨범이라면, DeltaDB는 촬영 과정 전체를 담은 영상에 가까워요. 비유하자면 구글 독스의 버전 기록 같은 거예요. 문서의 모든 변경 과정이 남아 있어서 언제든 되감아 볼 수 있잖아요. 그걸 코드 편집에, 그것도 조회하고 동기화할 수 있는 정식 데이터로 만든 거죠.

이게 가능한 배경에는 Zed의 태생적인 구조가 있어요. Zed는 처음부터 실시간 협업을 염두에 두고 CRDT라는 기술 위에 지어졌거든요. CRDT가 뭐냐면, 여러 사람이 같은 문서를 동시에 고쳐도 충돌 없이 자동으로 합쳐지도록 설계된 자료구조예요. 구글 독스에서 두 사람이 동시에 타이핑해도 문서가 안 깨지는 것과 같은 원리라고 보시면 돼요. 이 구조에서는 모든 타이핑이 어차피 '연산'이라는 작은 단위로 다뤄지기 때문에, 그 연산들을 버리지 않고 차곡차곡 저장하면 자연스럽게 편집의 전체 역사가 데이터베이스가 되는 거예요. DeltaDB는 그 역사를 영속화해서 재생하고, 검색하고, 팀과 공유할 수 있게 만든 결과물이고요.

왜 하필 지금일까요: AI 에이전트 시대의 코드 리뷰

타이밍이 절묘해요. 요즘은 AI 코딩 에이전트가 사람보다 많은 코드를 쏟아내는 시대잖아요. 그런데 에이전트가 만든 거대한 diff를 받아 들면, 최종 결과만 봐서는 이 코드를 얼마나 신뢰해야 할지 판단하기 어려워요. 어떤 부분을 사람이 직접 고쳤고, 어떤 부분을 에이전트가 어떤 시도와 번복을 거쳐 만들었는지, 그 '과정'이 리뷰와 신뢰의 근거가 되거든요. 편집 과정 전체가 기록되어 있다면 리뷰어는 결과만이 아니라 코드가 만들어진 경로를 재생해 볼 수 있고, 나중에 '이 코드가 왜 이렇게 됐지?' 싶을 때 커밋 메시지보다 훨씬 정밀한 답을 얻을 수 있어요.

업계 맥락에서 보면

버전 관리의 역사에서 보면 흥미로운 위치예요. 깃은 스냅샷 모델로 천하를 통일했지만, Pijul이나 Darcs처럼 '변경 자체'를 일급 데이터로 다루려는 시도는 꾸준히 있었어요. JetBrains IDE의 로컬 히스토리나 VS Code의 타임라인도 비슷한 욕구를 채워주지만, 어디까지나 내 컴퓨터에만 남는 휘발성 기능이었죠. DeltaDB는 이걸 로컬 편의 기능이 아니라 팀 단위로 공유되는 인프라로 끌어올리려는 시도예요. 에디터 회사들이 단순 편집기를 넘어 협업과 AI 컨텍스트 인프라로 영역을 넓히는 큰 흐름과도 맞닿아 있고요. 다만 깃을 대체하는 건 아니에요. 커밋은 여전히 '공식 발표'의 단위로 남고, DeltaDB는 그 사이의 빈칸을 채우는 보완재에 가까워요.

한국 개발자에게 주는 시사점

당장 실무에 도입할 단계는 아니지만, 방향은 분명히 봐둘 가치가 있어요. AI 에이전트의 작업을 검증하고 감사(audit)하는 문제는 앞으로 모든 팀이 마주칠 숙제고, '편집 과정의 기록'은 그 유력한 답 중 하나거든요. 물론 불편한 질문도 따라와요. 내 모든 백스페이스와 오타, 헤매던 흔적까지 기록된다면 그건 협업 도구일까요, 감시 도구일까요?

한 줄로 정리하면, 깃이 버려온 '커밋 사이의 시간'을 데이터로 만들겠다는 선언이에요. 여러분은 자신의 편집 과정 전체가 재생될 수 있다면, 더 나은 협업이라고 느끼실 것 같나요, 부담이라고 느끼실 것 같나요?