코드 에디터를 만드는 Zed가 DeltaDB라는 새로운 버전 관리 시스템의 얼리 액세스 신청을 받기 시작했다. 아직 공개된 정보는 소개 페이지 수준에 머물러 있지만, 표방하는 방향만큼은 분명하다. 지금까지의 버전 관리가 '커밋'이라는 이산적인 스냅숏을 쌓아 올리는 방식이었다면, DeltaDB는 작업이 진행되는 과정 자체를 연속적으로 기록하고 그 코드가 어떤 대화에서 비롯됐는지를 함께 붙들어 두는 것을 목표로 한다. 회사는 이를 '지속적인(continuous) 소스 관리와 리뷰'라고 부른다.
커밋과 커밋 사이를 기록한다는 것
Git을 비롯한 기존 도구에서 커밋 이전의 편집 과정은 사실상 사라진다. 개발자가 수십 번 코드를 고치고 되돌려도 최종적으로 남는 것은 하나의 커밋뿐이고, 그 사이의 흐름은 로컬 작업 디렉터리 안에서만 존재하다 덮어써진다. DeltaDB는 이 지점을 겨냥한다. 커밋과 커밋 사이에 일어나는 모든 연산(operation)을 포착하고, 각각에 안정적인 식별자를 부여한다는 설명이다. 그 결과 코드가 진화하는 어느 순간이든 특정 시점을 정확히 지목하고 참조할 수 있게 된다는 것이다. 변경을 사후에 요약한 결과물이 아니라, 변경이 일어난 시간축 자체를 데이터로 다루겠다는 발상에 가깝다.
이 접근은 AI 에이전트가 코드를 작성하는 흐름을 전제로 설계됐다는 점에서 특히 눈에 띈다. DeltaDB는 모든 변경을 그것을 만들어낸 에이전트 대화와 연결한다. 코드의 어느 한 줄에서 출발해 그 줄을 만든 대화로 거슬러 올라갈 수 있고, 반대로 대화 속 어떤 메시지에서 그 메시지가 건드린 코드로 곧장 이동할 수도 있다. 지금도 많은 팀이 커밋 메시지나 PR 설명에 맥락을 남기지만, 그것은 사람이 사후에 재구성한 서술이다. 코드와 대화를 양방향 링크로 직접 묶어 두면, '이 코드는 왜 이렇게 됐나'라는 질문에 대한 추적이 훨씬 기계적으로 이뤄질 수 있다.
워크트리 가상화와 협업 방식의 변화
또 하나의 핵심은 워크트리(worktree) 가상화다. Zed는 DeltaDB가 작업 디렉터리를 가상화하기 때문에 새로운 에이전트 브랜치를 띄우는 비용이 사실상 공짜에 가깝다고 말한다. 히스토리상의 어떤 지점이든 유효한 분기점이 될 수 있으며, 심지어 에이전트가 작업을 실행하는 도중(mid-run)에도 그 시점에서 갈라져 나올 수 있다는 것이다. 여러 에이전트에게 서로 다른 접근을 병렬로 시도시키고 그중 나은 결과를 취하는 식의 작업이 늘고 있는 상황에서, 브랜치 생성 비용을 낮추는 것은 실질적인 의미가 있다.
협업의 결도 달라진다. DeltaDB에서는 동료가 작업이 아직 진행 중인 상태에서 합류해, 그 작업을 수행한 에이전트와 직접 대화하고, 진행되는 코드에 그때그때 주석을 달 수 있다고 한다. 누군가 커밋하고 푸시할 때까지 기다렸다가 리뷰를 시작하는 기존 순서를 뒤집어, '완성 후 리뷰'가 아니라 '진행 중 리뷰'를 하겠다는 그림이다. 리뷰가 작업 흐름 바깥의 별도 관문이 아니라 작업과 같은 시간 위에 얹히는 셈이다.
실무자가 짚어둘 지점과 한계
한국의 개발 조직 입장에서 흥미로운 대목은, 이것이 AI 에이전트 중심 개발이 보편화될 때 드러나는 도구의 공백을 정면으로 다룬다는 점이다. 에이전트가 짧은 시간에 대량의 변경을 만들어낼수록 '무엇이 언제 왜 바뀌었나'를 되짚는 일은 어려워지고, 사람의 커밋 습관에 의존한 추적은 한계에 부딪힌다. 코드와 대화를 원자 단위로 연결해 두는 발상은 그 흐름에 대한 하나의 답으로 읽힌다.
다만 현재로선 신중하게 볼 부분도 많다. 공개된 것은 개념 소개와 얼리 액세스 신청뿐이고, 저장 구조나 성능, 팀 규모별 확장성, 기존 Git 워크플로 및 GitHub·GitLab 같은 플랫폼과의 연동 여부에 대한 구체적 정보는 아직 확인되지 않는다. Zed 에디터에 얼마나 종속되는지도 분명치 않아, 도입 시 벤더 종속 위험을 따져볼 필요가 있다. 방향성은 분명하지만 실제 성능과 조직 적합성은 손에 잡히는 제품이 나온 뒤에야 판단할 수 있는 단계다. 지금은 실험적 시도로 기록해 두고, 에이전트 기반 개발 도구의 다음 세대가 어디로 향하는지를 가늠하는 신호 정도로 받아들이는 편이 적절하다.