버전 관리 시스템은 오랫동안 커밋이라는 결과물만 기록해 왔습니다. 하지만 AI 에이전트와 함께 코드를 작성하는 방식이 보편화되면서, 정작 중요한 맥락은 커밋 메시지가 아니라 그 코드를 만들어 낸 대화 속에 남게 됐습니다. Zed가 얼리 액세스로 공개한 DeltaDB는 바로 이 빈틈을 겨냥합니다.
DeltaDB는 커밋과 커밋 사이에서 벌어진 작업 과정 전체를 기록하고, 각각의 변경을 그것을 만들어 낸 대화와 연결하는 버전 관리 시스템입니다. 이 글에서는 DeltaDB가 제안하는 개념이 무엇인지, 기존 Git 워크플로와 어떻게 다른지, 그리고 개발자 입장에서 지금 무엇을 준비하면 좋을지 정리합니다.
1. 커밋 사이의 공백을 기록한다
Git에서 하나의 커밋은 스냅샷입니다. 그 사이에 있었던 수십 번의 시행착오, 되돌린 접근, 버려진 실험은 기록되지 않습니다. 사람이 직접 타이핑하던 시절에는 이 손실이 크지 않았습니다. 개발자의 머릿속에 맥락이 남아 있었기 때문입니다.
에이전트가 코드를 대량으로 생성하는 환경에서는 이야기가 달라집니다. DeltaDB의 접근은 다음과 같습니다.
- 모든 편집에 안정적인 식별자 부여 — 코드가 변화해 온 특정 순간을 정확히 가리킬 수 있습니다.
- 어느 시점으로든 복귀 — 커밋 경계와 무관하게 임의의 편집 시점으로 되돌아갈 수 있습니다.
- 변경과 대화의 연결 — 모든 변경은 그것을 만든 에이전트 대화와 묶여서 저장됩니다.
2. 코드와 대화의 양방향 추적
DeltaDB의 핵심 차별점은 양방향 탐색입니다. 코드 한 줄에서 출발해 그 줄을 만들어 낸 대화를 찾아갈 수 있고, 반대로 대화 메시지에서 출발해 그 메시지가 실제로 건드린 코드로 이동할 수 있습니다.
실무에서 이 기능이 의미 있는 순간은 대체로 이렇습니다. 몇 주 전 에이전트가 넣은 예외 처리 한 줄을 발견했을 때, git blame은 커밋 해시와 작성자만 알려줍니다. 정작 알고 싶은 것은 왜 이 분기가 필요했는가인데, 그 근거는 커밋 메시지가 아니라 당시 대화에 있습니다.
# 개념적으로 DeltaDB가 지향하는 조회 방식
# (실제 CLI가 아니라 아이디어를 표현한 의사코드입니다)
# 1) 코드 -> 대화: 특정 라인의 근거를 찾는다
edit = deltadb.locate(file="payment/refund.py", line=142)
conversation = edit.origin_conversation
print(conversation.summary)
# 2) 대화 -> 코드: 어떤 결정이 어디에 반영됐는지 본다
for change in conversation.resulting_changes:
print(change.path, change.range, change.stable_id)
# 3) 커밋 경계와 무관한 시점 복귀
snapshot = deltadb.checkout(stable_id=edit.stable_id)
3. 가상화된 작업 트리와 저비용 브랜치
DeltaDB는 작업 트리를 가상화해, 기록상의 어느 시점에서든 사실상 비용 없이 새 에이전트 브랜치를 만들 수 있게 합니다. 심지어 에이전트가 실행 중인 도중의 상태에서도 분기가 가능합니다.
에이전트를 병렬로 굴려 본 경험이 있다면 이 지점이 왜 중요한지 바로 이해될 것입니다. 지금은 같은 문제에 세 가지 접근을 시도하려면 워크트리를 따로 만들거나 저장소를 복제해야 합니다. 분기 비용이 0에 가까워지면 여러 시도를 병렬로 돌려 놓고 결과를 비교해 고르는 방식이 기본값이 됩니다.
4. 커밋 이전 단계의 협업
또 하나 눈여겨볼 부분은 리뷰 시점을 앞당긴다는 점입니다. 동료는 커밋과 푸시를 기다리지 않고 진행 중인 작업에 참여할 수 있고, 작업을 수행한 에이전트와 직접 대화하거나 진행 과정에 주석을 남길 수 있습니다.
PR 리뷰가 늦게 도착해 방향 자체가 잘못됐다는 사실을 뒤늦게 발견하는 일은 흔합니다. 리뷰 지점이 작업 도중으로 이동하면 이런 낭비를 줄일 수 있습니다.
5. 회의적인 시선도 함께 본다
공개 직후 토론에서는 지지만큼이나 의문도 제기됐습니다. 균형 있게 짚어 둘 만한 지적들입니다.
- 왜 새 시스템인가 — Git이나 jj 같은 기존 도구 위에 얹지 않고 별도 버전 관리 시스템을 만드는 선택에 대한 의문이 있었습니다.
- 에디터 본체 우선순위 — 성능 회귀나 미해결 이슈가 남은 상황에서 새 프로젝트에 자원을 쓰는 것에 대한 아쉬움이 나왔습니다.
- 이미 있던 아이디어 — 모든 변경의 이유와 근거를 방대한 이력 데이터베이스로 남기는 방식은 1996년 항공우주 소프트웨어 개발 사례에서도 논의된 개념이라는 지적이 있었습니다.
동시에 코딩 과정에서 만들어지는 핵심 산출물은 결국 대화라는 관점에 공감하며, 이 방향의 실험 자체를 반긴다는 의견도 있었습니다.
6. 지금 준비할 수 있는 것
DeltaDB는 아직 얼리 액세스 단계이고 Zed 생태계에 묶여 있습니다. 당장 도입을 결정할 단계는 아니지만, 방향성 자체는 특정 에디터와 무관하게 참고할 만합니다.
- 대화 로그를 산출물로 취급하기 — 에이전트와의 중요한 설계 대화는 요약해 PR 설명이나 ADR에 남겨 두세요. 도구가 자동화해 주기 전까지의 현실적인 대안입니다.
- 커밋 단위를 의미 단위로 — 변경 이력을 세밀하게 추적하는 도구가 등장할수록, 의미 단위로 쪼갠 커밋의 가치는 더 커집니다.
- 병렬 시도를 전제로 한 워크플로 — 워크트리나 브랜치 자동화를 미리 정비해 두면 분기 비용이 낮아지는 흐름에 자연스럽게 올라탈 수 있습니다.
요약
- DeltaDB는 커밋 사이의 작업 과정까지 기록하고 각 변경을 그것을 만든 대화와 연결하는 버전 관리 시스템입니다.
- 모든 편집에 안정적인 식별자를 부여해 임의 시점으로 되돌아갈 수 있습니다.
- 코드와 대화를 양방향으로 오갈 수 있어 변경의 근거를 추적하기 쉽습니다.
- 작업 트리 가상화로 실행 도중을 포함한 어느 시점에서든 저비용 브랜치를 만들 수 있습니다.
- 커밋과 푸시 이전에 동료가 작업에 참여해 에이전트와 대화하거나 주석을 남길 수 있습니다.
- 새 버전 관리 시스템의 필요성과 에디터 본체 우선순위에 대한 회의적 시선도 함께 존재합니다.
📰 원본 출처 · https://news.hada.io/topic?id=32195 (#N=32195)
이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.