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

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

---

배경과 문제의식

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

DeltaDB와 다음 단계

• 모든 커밋이 아니라 모든 연산

  • DeltaDB는 작업을 세밀한 델타 스트림으로 나누며, Git이 커밋마다 스냅샷을 저장하는 것과 달리 커밋 사이의 모든 연산을 기록함
  • 각 델타는 안정적인 식별자를 가지므로, 코드가 계속 바뀌는 중에도 진화 과정의 특정 순간을 가리킬 수 있음
  • 워크트리는 변화하는 과정 자체가 버전 관리되며, 그 변화를 이끄는 대화와 함께 다뤄짐
  • 메시지와 그 메시지가 만들어낸 편집은 나란히 기록되어 서로 분리되지 않음
  • DeltaDB는 충돌 없는 복제 워크트리를 내장해 여러 사람과 에이전트가 서로 다른 머신에서 같은 파일을 동시에 편집할 수 있음
  • 파일은 실제 파일이며, 에이전트는 터미널을 통해 파일에서 작업하고 사용자는 필요할 때 전체 워크트리를 디스크에 마운트해 자신의 도구를 사용할 수 있음

• 소스 코드는 이제 소스 대화

  • 참조가 줄 번호가 아니라 델타에 고정되기 때문에, 코드가 아래에서 이동해도 참조가 유지됨
  • 과거 대화의 어떤 줄에서도 현재 상태의 코드나 에이전트가 작성했던 당시의 코드로 이동할 수 있음
  • 어떤 코드 줄에서도 그 코드를 만든 대화와 이후 그 코드를 건드린 모든 대화를 찾을 수 있음
  • 에이전트도 이 정보를 활용해 자신이 건드리는 코드의 배경 맥락을 가져올 수 있음
  • 에이전트는 이전에 해당 코드에서 작업한 에이전트를 불러와 왜 그런 방식으로 작성됐는지 물을 수 있음

• 협업을 위해 커밋할 필요가 없어야 함

  • 에이전트와의 대화가 협업에 필요한 유일한 대화가 되는 것이 목표임
  • 팀원은 작업이 아직 진행 중일 때 참여해, 작업을 수행한 에이전트와 대화하고 진행 중에 주석을 달 수 있음
  • 팀원이 참여하기 위해 먼저 커밋과 푸시를 기다릴 필요가 없음
  • 풀 리퀘스트, 리뷰 스레드, 인라인 댓글은 코드와 논의가 서로 다른 장소에 있었기 때문에 나중에 토론을 코드에 다시 붙이기 위한 절차였음
  • 코드와 논의가 같은 장소에 있으면 그런 절차는 사라짐
  • Git과 CI는 검사를 실행하고 외부 세계와 연결하는 역할에 머물며, 협업이 강제로 일어나는 장소가 되지 않음

• 다음 단계

  • 소프트웨어는 이제 커밋이 아니라 대화 속에서 형태를 갖춰감
  • DeltaDB는 이를 위한 버전 관리 시스템이며, 몇 주 안에 초기 사용자에게 제공될 예정임
  • 먼저 사용해보고 싶다면 대기자 명단에 등록할 수 있음

[GN⁺]

Hacker News 의견들

• 커밋 사이의 작업물은 지저분한 수프라서 들여다봐도 누구에게도 유용하지 않음. git rebase로 기록을 다시 써서 각 커밋을 작고 원자적으로 만들고, 커밋으로 만든 이야기가 왜 지금 모습이 되었는지 설명해 줌
  실제로 어떤 시간순으로 진행됐는지는 중요하지 않음. 풀 리퀘스트 리뷰가 너무 늦다는 데는 동의하지만, 문제는 풀 리퀘스트가 브랜치 전체 결과를 한 번에 리뷰하도록 설계돼 개별 커밋 리뷰가 어렵다는 것임. 해법은 모든 잡음을 공유하는 게 아니라, 기능이나 수정이 끝나기 전에 초기 작업을 리뷰할 수 있도록 작고 원자적인 커밋을 장려하는 쪽이어야 함

  • 여기 댓글과 내 직업 네트워크를 보면 사람들은 대체로 두 진영으로 갈림. 하나는 Git을 거친 자동 저장처럼 쓰고 병합 때 합치는 쪽, 다른 하나는 깔끔하게 정리된 완전 동작 원자 커밋을 선호하는 쪽임
    내 경험상 1번이 더 흔한데, GitHub가 자연스럽게 그 방식을 더 잘 지원하고 누적 커밋이 2번의 일부 문제를 해결할 수 있기 때문일 수도 있음. 선택하라면 1번이 훨씬 더 말이 된다고 봄
  • 그건 Phabricator나 Gerrit 같은 도구 문제가 아니라 그냥 GitHub 문제 아닌가?
  • 지저분한 수프든 아니든 디스크나 비용이 문제가 아니라면, 누군가—아마 에이전트—가 내가 뭘 했는지 보는 것 자체는 괜찮음
    확신이 강하진 않지만, 에이전트는 일부에게는 잡음일지라도 추가 정보를 선호한다고 봄
  • 이런 반응이 나올 줄 알았음. 글을 읽으며 버전 관리 얘기 때마다 같은 감정을 보고 실망했던 기억이 남
    너무 많은 사람이 기록을 “깔끔하게” 보이게 하려고 너무 쉽게 버림. 말이 안 되지만, 의외로 흔한 특정 프로그래머식 논리에는 맞아 보임
    내 방식은 하루에도 수십 번씩 자주 커밋하는 것임. 커밋은 일어난 일의 기록이고, 그 기록이 가능한 한 많이 남아 있길 원함. git bisect가 아무 문제 없어 보이는 한 줄짜리 작은 커밋을 가리켜서, 훨씬 나중에야 발견된 미묘한 버그를 찾아준 적이 여러 번 있음
    내 생각에 소스 관리는 그런 걸 찾으라고 있는 것임. 큰 커밋의 모든 줄을 뒤져야 했다면 이런 문제들은 훨씬 고통스러웠을 것임
    그래서 사람들이 PR 전체 분량의 커밋을 일부러 뭉쳐서 합치고, 버전 관리가 유용한 유일한 부분이라고 보는 것을 버리는 모습을 보면 정말 이해가 안 됨. 부모 댓글 같은 진영도 많으니, 작성자의 더 세밀한 기록 계획은 쉽지 않은 싸움이 될 듯함
  • 당신이 커밋을 쓰는 방식은 내가 회사에서 스택형 PR을 쓰는 방식과 비슷하게 들림
    좋은 커밋 위생은 팀 차원에서 강제하기 어렵지만, 이상하게도 PR 수준에서는 사람들이 좋은 설명을 쓰고 변경 묶음을 깔끔하게 유지하는 데 꽤 협조적임

• 이건 Git에 대한 신뢰가 덜한 잦은 자동 커밋처럼 들림. Git은 잦은 자동 커밋을 충분히 잘 처리할 수 있음
  잦은 자동 커밋을 더 “깨끗한” 상위 커밋으로 말아 올리면서도 시점별 자동 커밋의 “대화”를 보존하고 싶다면, 가끔 git merge --no-ff를 쓰고 --first-parent 같은 도구로 “대화” 커밋보다 상위 커밋에 집중하면 됨
  Git 백엔드는 이미 Git pack과 다른 도구에 델타 DB 최적화가 많이 들어가 있고, 사실 조금 손봐야 할 곳은 Git 프런트엔드—주로 --first-parent—와 수많은 “지하철 노선도 우선/전용” Git UI임. 많은 사람이 그 노선도를 못생기고 헷갈리고 불쾌하게 느끼니, --first-parent에 대응하는 드릴다운 UI가 더 많아야 함

  • 나도 그렇게 함. 브랜치의 커밋은 평소에 보지 않지만 필요하면 남아 있음. git blame도 --first-parent를 쓰도록 설정할 수 있음

• “소프트웨어는 커밋 사이에서 만들어진다”에는 동의하지만, “DeltaDB가 각 커밋 사이의 모든 작업을 캡처한다”에는 동의하지 않음
  우선 침해적으로 느껴짐. 일하는 동안 24시간 돌아가는 화면 녹화기도 원하지 않음. 내 실수가 드러나는 게 잘못은 아니겠지만, 일을 제대로 하고 있다면 내가 만든 가치는 커밋에 담기고, 그 방식이 훨씬 덜 침해적으로 느껴짐
  둘째, 나는 여러 도구를 쓰고 있고, 그 모든 걸 이상한 DB에 통합하고 싶지 않음. 어떤 시점에는 “외부 프로세스가 뭔가 했다”로 끝난다면 모든 걸 캡처하는 의미가 뭔가? Zed가 많은 것을 통합할 수 있다는 점은 좋지만, Zed에 통합된 모든 걸 쓰겠다는 뜻은 아님. 마지막으로 확인했을 때 Zed에서 ACP로 Claude Code를 쓰면 예전 메시지를 되감아 수정할 수도 없었음
  마지막으로 개인적으로는 우리가 이미 커밋의 본질을 놓쳤다고 봄. 대부분은 임의의 무한정한 변경 묶음을 만든 뒤 git commit을 실행하고, 그 변경 묶음은 거대한 덩어리로 리뷰된 다음 커밋들이 합쳐짐. 세상이 끝나는 일은 아니지만, 손으로 잘 빚은 커밋은 정말 훌륭함. 이런 방식을 강제하는 프로젝트에서 git blame을 실행해 보면 무슨 말인지 바로 알 것임
  DeltaDB 같은 건 커밋을 대충 뭉치는 관행을 더 강화하고 굳힐 뿐임. 무슨 일이 벌어진 건지 궁금하면 이제 사용자가 LLM과 나눈 대화를 관음적으로 재생해 보면 되는 셈임
  마지막 지점은 흥미롭지만 짜증나기도 함. 팀원에게 도움이 되는 좋은 공학 관행이라는 이유만으로는 변경 내용과 동기를 문서화하게 설득할 수 없었지만, 모두가 LLM에게는 기꺼이 설명함. LLM이 일을 해주려면 필요하기 때문인 면이 크지만, 예전에는 하지 않았을 일을 LLM을 만족시키려고 얼마나 많이 하는지 흥미로움. 갑자기 이상하게 문서화되지 않았던 것들이 CLAUDE.md에 문서화됨

• 커밋 사이에 쓰는 코드는 내 사고 과정임. 코드를 써보고, 지우고, 다시 쓰면서 생각함
  커밋으로 실려 나가는 코드는 다른 사람이 이해하도록 작성한 것이고, 생각을 위해 쓰는 과정의 결과물임. 내 생각이 직렬화되고 버전 관리되고 공개적으로 접근 가능해지는 건 원하지 않음
  https://www.nature.com/articles/s44222-025-00323-4

  • JJ에 대해서도 같은 문제가 있었음. 커밋 사이의 모든 것이 버전 관리되길 원하지 않음
    커밋 사이의 모든 중간 상태가 관련 있거나 유용한지도 확신이 없음. 다만 내가 소수파인 느낌임
  • 그래서 PR 전에 rebase를 쓰고, squash는 싫어함. 2년 뒤에는 왜 그 코드를 그렇게 썼는지 기억하지 못할 것이고, 버그를 이해하고 체스터턴의 울타리 상황을 식별하려면 델타와 커밋 기록밖에 없음
    squash를 해버리면 당신이 “한 번에” 쓴 400줄짜리 코드와 그 코드가 배정된 기능 요청만 맥락으로 남음. 아무 도움도 안 됨
    최악의 사람은 새 모듈을 작성하면서 어느 정도 동작할 때까지 아무것도 체크인하지 않았음. 자기 코드의 버그를 먼저 말하지 않고 몰래 고치던 취약한 자존심과도 이어졌던 것 같음. 그는 Kernighan의 법칙이 드러나는 난해한 코드를 썼고, 그런 짓을 하기엔 경력이 10년은 더 많았음. 자기 코드가 “강력하다”고 자랑했는데, 그건 칭찬이 아니라 전조임. 초기 커밋 코드에서 버그를 여러 번 찾았음. 제발 뭐라도 남겨 달라는 심정임
    문제를 찾을 때까지 아무거나 시도했다고 해서 그걸 고백할 필요는 없음. B 지점에 도달 가능하다는 걸 알게 된 뒤, A에서 B로 가는 원하는 이야기를 만들면 됨. 처음부터 정확히 해야 할 일을 알았다면 썼을 방식으로 커밋을 재배열하면 됨. 썼다가 바로 지운 코드의 90%나 그 서사를 뒷받침하지 않는 것은 버리면 됨
    법 집행에는 병행 구성이라는 게 있음. 법정에서 허용되지 않는 사실을 통해 용의자가 유죄임을 알 수 있지만, 같은 사실을 절차대로 다시 발견해야 함. 쓰레기 수거일에 쓰레기를 확보하고, 이웃을 인터뷰하고, 수색영장을 받을 만큼의 정황증거를 모은 뒤 그 증거를 다시 찾는 식임
  • 주로 AI 에이전트를 염두에 둔 것 같음. 전에 본 적 있는 흥미로운 아이디어이고, 모두가 AI를 위해 뭔가를 재발명하려는 분위기는 재미있음
    하지만 그냥 텍스트 파일을 만들고 커밋 참조를 넣으면 되지 않나 싶어 회의적임. Fossil을 쓰면 안 되는 이유도 모르겠음. SQLite 데이터베이스라서 이미 원하는 걸 묶어 넣을 수 있고, 커밋을 참조할 수 있는 온갖 기능이 내장돼 있음
  • 협업 부분은 회의적이지만, 기업 고객을 위한 기능처럼 들려서 의도는 이해됨
  • 완전히 동의함. 감시 느낌이 매우 불쾌함. 특히 “DeltaDB는 작업을 세밀한 델타 스트림으로 쪼갠다. Git이 각 커밋의 스냅샷을 캡처하는 반면, DeltaDB는 그 사이의 모든 작업을 캡처하고 각각에 안정적인 식별자를 부여한다”는 부분이 그렇음
    Zed에 emacs 키맵이 생겼다길래 한번 써볼까 했는데, 이제는 아님. 이건 너무 끔찍하게 침해적인 기능이고, 리뷰를 위해 공개한 커밋에 이르기까지의 모든 중간 편집을 동료가 키 입력 단위로 검토하는 걸 전혀 원하지 않음
    PR을 올리기 전에는 magit에서 커밋 기록을 조금 다듬어 더 선형적이고 소화하기 쉽게 만들 때가 있음. 설명을 고치거나 인접한 커밋을 합치는 식임. 그런데 이 기능은 그런 업무의 한 측면을 통째로 던져버리고, “동료여, 이 델타의 소방 호스를 빨아들이고 즐겨라”라고 말하는 셈임
    “우리가 정말 원하는 것은 단순하다. 에이전트와의 대화가 당신에게 필요한 유일한 대화가 되는 것이다”라는 문장은 대체 무슨 뜻인가. 아니, 틀렸음

• Anthropic이나 OpenAI가 Zed를 인수하는 건 피할 수 없다는 느낌이 들어 속이 불편함. 아이디어가 너무 좋고 소프트웨어도 너무 좋음

  • Zed의 코딩 하네스는 Claude Code보다 훨씬 좋지만, Claude API를 직접 쓰기 때문에 훨씬 비쌈. 같은 제품군 안으로 들어가면 제품 범주를 정의하는 수준이 될 수 있음
  • 왜 Zed에서 멈추나? AI 회사들이 모은 1조 달러 투자금은 명목상 데이터센터용이었지만, 비용이 오르고 완공 일정이 일반적인 사업 계획 범위를 넘어가면 그 돈을 다른 곳에 쓰는 편이 더 효율적임. 1조 달러면 원하는 건 뭐든 살 수 있음
  • Anthropic이나 OpenAI가 가려는 곳에는 더 이상 편집기가 없어 보임. 개인적으로는 더 나은 읽기 전용 코드 도구, 아니면 UML의 귀환을 원함

• 지금 이 분야에서 경쟁하는 초기 스타트업이 정말 많음. 최근 몇 주 동안 면접을 보면서 최소 두 곳과 이야기해 봄
  이런 도구들이 대규모로 성공할 만큼 자리를 잡으려면 경쟁이 아주 치열할 것임. 다만 이 모든 게 내가 매우 불편하게 느끼는 수준의 개발자 감시를 가능하게 하는 것 같다는 생각을 지울 수 없음

  • 관리자가 자기 밑의 모든 개발자 키 입력을 전부 관찰하는 데 시간을 다 쓴다면, 진짜 할 일이나 신경 써야 할 사업 문제가 너무 없는 것임

• 커밋은 먼저 정리했기 때문에 유용함. 그 사이의 시행착오는 뭔가를 시도하고 막다른 길을 지우는 곳이며, 대부분은 버려져야 함
  모든 변경과 에이전트 메시지를 저장하면 그 쓰레기가 계속 남을 뿐임

• Google은 citc로 아마 10년쯤 전부터 이걸 해왔음. Gemini가 실제로 언제 이걸 활용할지는 모르지만, Google은 최소 10년 동안 거의 모든 개발자의 기록을 Ctrl-S 단위로 사실상 완전히 갖고 있음
  지금 Gemini가 멍청해 보인다면, 그건 계산 자원 할당을 아끼고 있기 때문일 뿐임
  0 - https://en.wikipedia.org/wiki/Piper_(source_control_system)

• 여기서 가치 제안이 뭔지 모르겠음. 여러 회사가 대략 이런 기능을 제안하는 걸 봤지만, 이 기술이 존재해야 할 설득력 있는 이유를 제시한 곳은 하나도 없었음

  • 당신의 경험과 작업 흐름이 내 것과 이렇게 다르다는 게 흥미로움. 이건 내가 매일 겪는 실제 문제를 해결한다고 주장하는 기능임
    우리 회사는 완전 원격이고, 동료들은 대부분 내 근처에 살지 않음. 하루에 몇 번 화상 채팅으로 보지만, 주로 Slack으로 소통함
    우리는 좋은 코드를 작성하도록 LLM 에이전트를 도입하는 곡선에서도 꽤 앞쪽에 있음. 좋은 모델과 특정 코딩 하네스의 매우 좋은 안전장치 덕분에 요즘은 LLM이 우리 코드의 대부분을 작성함
    보통 하루는 티켓 하나를 집어 LLM에게 가리키고 함께 문제를 풀기 시작함. 아키텍처 결정을 하고 계획을 만들고 실행함. 가장 최근에 배포한 기능은 토큰 비용이 19달러였고, 한창일 때 LLM이 내 입력 없이 30분 정도 계속 작업했음
    어떤 방향이 나은지 확신이 없을 때만 팀 채팅에 질문을 올려 동료 의견을 구할 수도 있음. 하지만 많은 티켓은 완전히 자율적으로 끝남
    그런 다음 PR을 열고 Slack에 PR 링크를 올려 리뷰를 요청하면, 동료들은 그때 구현을 처음 보게 됨. 동료들이 질문할 때가 있음. 빠른 실시간 대화에는 GitHub 댓글이 잘 맞지 않아서, PR 댓글보다 Slack 스레드에 질문을 올리는 경우가 많음
    그 질문들의 답은 내 노트북에 있는 LLM과의 채팅 로그에 있지만, 동료에게 쉽게 보여줄 방법이 없음. 그래서 동료 질문을 Slack에서 LLM 채팅으로 복사하고, 답을 다시 붙여넣는 전화 놀이를 하게 됨
    동료와 LLM과 내가 모두 같은 대화에 더 쉽게 참여할 수 있다는 아이디어는 매우 매력적임
    이것이 Zed 팀이 올바른 방향이라는 뜻은 아니고, 우리 팀이 다른 방식으로 일하면 더 나을 수도 있음. 하지만 현재 접근 방식이 너무 “성공적”이라 조직적으로 바꿀 압력이 별로 없음

• 소프트웨어 팀의 일은 어떤 도메인에서 효과적으로 작동하는 모델을 협력해 학습하는 것임. 그 모델과 배움을 코드, 테스트, 관련 문서로 표현함
  그래서 한편으로는 풀 리퀘스트와 코드 리뷰가 이 과정을 치명적으로 훼손한다는 데 전적으로 동의하지만, 곧바로 또 다른 부차적 절차와 산출물을 만들어 우리를 산만하게 한다는 생각에 움찔함. 이런 건 전부 코드베이스에서 드러나야 함
  별개의 무언가가 아님. 커밋 메시지나 ADR 묶음도 아님. 코드베이스가 인간과 AI 모두에게 무엇과 왜를 완전히 스스로 설명하지 못한다면 실패한 것이고, 그 실패를 관리하려고 평생 더 많은 절차를 만들게 될 것임

  • 기능과 실험을 위한 저렴한 브랜칭, 특정 커밋을 빠르게 되돌릴 수 있는 능력, 한 줄의 코드가 마지막으로 바뀐 때의 커밋 메시지를 읽는 일은 모두 엄청나게 중요하고 분산 버전 관리 시스템이 가능하게 해준 것임
    현재 코드 상태만으로는 현대 소프트웨어 개발에 충분하지 않음