코드 작성 대화가 곧 소프트웨어: DeltaDB의 등장

DeltaDB는 Git의 스냅샷 기반 커밋과 달리, 모든 연산(Operation)을 세분화된 델타(Delta) 스트림으로 기록한다고 설명합니다. 각 델타는 고유한 식별자를 가지며, 코드의 진화 과정 중 어떤 순간의 상태든 참조 가능하게 합니다. 이는 코드와 이를 생성한 대화(Conversation)를 나란히 기록하여, 코드와 의도의 불일치(Drift)를 방지하는 데 중점을 둡니다. 커뮤니티에서는 이러한 방식이 과도한 노이즈(Noise)를 발생시킬 수 있다는 우려와 함께, 작고 원자적인 커밋(Small, Atomic Commits)의 중요성을 강조하는 의견도 있습니다.

본문의 핵심 주장은 소프트웨어의 진정한 소스(Source of Truth)는 코드를 생성하는 대화라는 것입니다. DeltaDB는 메시지와 해당 메시지가 생성한 편집 내용을 나란히 기록하여, 코드와 대화 간의 연관성(Cross-referencing)을 유지합니다. 이를 통해 개발자는 특정 코드 라인에서 생성된 대화로 점프하거나, 해당 코드를 생성한 대화 및 이후의 모든 대화를 추적할 수 있습니다. 이는 AI 에이전트와의 협업 시에도 동일하게 적용되어, 에이전트가 코드의 맥락을 이해하고 이전 에이전트와 소통하는 것을 가능하게 합니다. 일부 사용자는 이러한 방식이 개인적인 생각 과정(Thinking Process)을 노출하는 것에 대한 거부감을 표현했습니다.

DeltaDB는 Git의 커밋 중심 협업 방식이 코드 리뷰(Code Review) 시점의 지연과 대화의 단절을 야기한다고 지적합니다. 반면, DeltaDB는 실시간 협업 환경을 제공하여, 개발자가 커밋 및 푸시를 기다리지 않고도 동료나 AI 에이전트와 직접 소통하며 작업할 수 있다고 주장합니다. 그러나 커뮤니티에서는 Git의 `git rebase`를 통한 히스토리 재작성(History Rewriting)이나 `git merge --no-ff`와 같은 기능을 활용하면 유사한 효과를 얻을 수 있다는 반론이 제기되었습니다. 또한, 모든 변경 사항을 기록하는 것이 불필요한 정보(Junk)를 축적할 수 있다는 비판도 존재합니다.

새로운 버전 관리 시스템에 대한 논의에서 개발자 감시(Developer Surveillance)에 대한 우려가 제기되었습니다. 모든 변경 사항과 대화 기록이 실시간으로 저장되고 관리될 수 있다는 점에서, 일부 사용자는 개인 정보 보호(Privacy) 및 데이터 통제권(Data Control)에 대한 불안감을 표출했습니다. 특히, 이러한 시스템이 기업에 의한 데이터 수집 및 분석에 활용될 가능성에 대한 우려가 언급되었습니다. 또한, API 키(API Keys)와 같은 민감 정보가 시스템 내에 저장될 가능성에 대한 지적도 있었습니다.

본문은 AI 에이전트와의 협업이 코드 생성 과정의 대화를 더욱 중요하게 만든다고 강조합니다. 에이전트는 코드의 맥락을 파악하기 위해 이전 대화 기록을 참조하며, 이는 LLM(Large Language Model)을 위한 문서화(Documentation for LLMs)의 필요성을 증대시킵니다. 일부 사용자는 이러한 변화가 개발자들이 문서화에 대한 동기 부여를 얻게 하는 긍정적 측면이 있다고 보지만, 동시에 LLM을 만족시키기 위한 과도한 노력으로 이어질 수 있다는 비판적 시각도 존재합니다. 또한, Claude Code와 같은 도구에서 메시지 기록 되돌리기 및 수정 기능의 부재가 지적되기도 했습니다.