코드 에디터 Zed를 만드는 팀이 DeltaDB라는 이름의 데이터베이스를 공개했어요. 에디터 회사가 갑자기 웬 데이터베이스냐 싶으실 텐데요, 이 팀이 걸어온 길을 보면 오히려 자연스러운 행보거든요. 오늘은 이게 어떤 물건이고 왜 의미가 있는지 차근차근 풀어볼게요.
Zed가 어떤 팀인지부터 볼게요
Zed는 GitHub의 Atom 에디터를 만들었던 개발자들이 나와서 Rust로 처음부터 다시 만든 코드 에디터예요. Atom이 Electron 기반이라 느리다는 비판을 받았던 걸 뼈저리게 경험한 팀이라, 이번에는 GPU 렌더링 엔진(GPUI)까지 직접 만들어가며 네이티브급 속도에 집착했죠. 그리고 또 하나의 축이 실시간 협업이에요. Zed는 처음 설계할 때부터 여러 명이 같은 코드를 동시에 편집하는 걸 핵심 기능으로 넣었거든요.
이 협업 기능의 기반이 CRDT라는 기술이에요. 이게 뭐냐면, Conflict-free Replicated Data Type의 약자인데, 여러 사람이 같은 문서를 동시에 고쳐도 충돌 없이 자동으로 합쳐지도록 설계된 자료구조예요. 구글 독스에서 두 사람이 동시에 타이핑해도 문서가 깨지지 않는 것과 같은 원리라고 생각하시면 돼요. Zed 안에서는 여러분이 누르는 키 입력 하나하나가 “어느 위치에 어떤 글자를 넣었다”는 작은 연산(operation)으로 표현되고, 이 연산들이 네트워크로 전파되면서 협업이 이뤄져요.
DeltaDB는 뭐가 다른 걸까요
이름에 답이 있어요. 델타(delta)는 “변경분”이라는 뜻이거든요. 기존 버전 관리의 대표주자인 Git은 스냅샷 방식이에요. 커밋을 하는 순간의 전체 상태를 사진 찍듯 저장하죠. 그런데 이 방식엔 빈틈이 있어요. 커밋과 커밋 사이에 일어난 일, 그러니까 코드를 썼다 지웠다 고민한 과정은 전부 사라져요. 하루 종일 작업하고 커밋 한 번 하면, 그날의 편집 과정은 어디에도 남지 않는 거죠.
DeltaDB는 발상이 반대예요. 편집 연산 자체를 저장의 기본 단위로 삼는 거예요. Zed 에디터가 이미 모든 편집을 CRDT 연산으로 다루고 있으니, 이 연산 스트림을 그대로 영구 저장하면 코드의 역사가 “사진첩”이 아니라 “동영상”으로 남는 셈이거든요. 이렇게 되면 커밋이라는 인위적인 구분 없이도 전체 히스토리가 존재하고, 특정 시점으로 되감기를 하거나, 어떤 코드 한 줄이 언제 누구에 의해 어떤 맥락에서 생겨났는지를 편집 단위로 추적할 수 있게 돼요.
왜 하필 지금일까요
AI 에이전트 때문이에요. 요즘은 사람이 아니라 에이전트가 코드를 대량으로 고치는 시대잖아요. 그런데 에이전트가 30개 파일을 수정한 결과를 커밋 하나로 받아보면, 리뷰하는 사람 입장에선 “이걸 왜 이렇게 고쳤지?”를 알기가 정말 어렵거든요. 편집 과정이 통째로 기록돼 있다면 이야기가 달라져요. 에이전트가 어떤 순서로 뭘 시도했고 어디서 되돌렸는지가 다 남으니까, 검토도 부분 롤백도 훨씬 정밀해지죠. 사람과 AI가 같은 코드베이스에서 뒤섞여 일하는 환경에서는 스냅샷보다 연산 로그가 훨씬 풍부한 정보원이 되는 거예요.
업계 흐름에서 보면
이런 시도가 Zed 혼자만의 아이디어는 아니에요. Figma가 멀티플레이어 편집을 위해 자체 동기화 엔진을 만들었고, Linear도 클라이언트와 서버 사이의 sync engine을 직접 구축한 걸로 유명하죠. 오픈소스 쪽에는 Automerge나 Yjs 같은 CRDT 라이브러리가 이미 활발하게 쓰이고 있고, 로컬 퍼스트(local-first) 소프트웨어라는 흐름도 몇 년째 힘을 얻고 있어요. 로컬에서 먼저 동작하고 네트워크는 동기화에만 쓰자는 철학인데, CRDT가 그 핵심 부품이거든요. DeltaDB는 이 흐름을 “코드”라는 도메인에, 그것도 에디터와 저장소를 수직 통합하는 방식으로 밀어붙인 사례라고 볼 수 있어요. 렌더링 엔진이 마음에 안 든다고 GPUI를 직접 만든 팀답게, 이번엔 저장 계층까지 직접 만든 거죠.
물론 Git을 당장 대체한다고 보긴 어려워요. Git은 사실상 업계 표준이고 GitHub이라는 거대한 생태계가 붙어 있으니까요. 현실적으로는 Git과 공존하면서, 커밋 사이의 빈 공간을 채우는 보완재로 시작할 가능성이 높아 보여요.
우리에게 주는 시사점
당장 프로덕션에 도입할 물건이라기보다는, 방향을 보여주는 신호로 읽는 게 맞을 것 같아요. 다만 협업 기능이 들어가는 서비스를 만들고 계시다면 CRDT는 지금 배워둘 가치가 충분해요. 문서 편집기, 화이트보드, 협업 툴 어디에나 등장하는 기술이고, Yjs 정도는 주말 프로젝트로 충분히 맛볼 수 있거든요. 그리고 “내 도구가 만드는 데이터의 저장 단위가 과연 최선인가”라는 질문 자체가 좋은 훈련이 돼요. Git의 커밋이 너무 당연해서 의심해본 적이 없다면, 이번 발표가 좋은 계기가 될 거예요.
정리하면, DeltaDB는 “코드의 역사를 스냅샷이 아니라 편집의 흐름으로 저장하자”는 제안이에요. 여러분은 어떠세요? 모든 키 입력이 기록에 남는다면 개발 워크플로우에서 뭐가 가장 크게 달라질까요? 편하다는 생각과 감시받는 느낌, 어느 쪽이 먼저 드시나요?
🔗 출처: Hacker News