에이전트가 만든 코드가 늘면서 검토 단위도 바뀌고 있다. 사람이 직접 쓴 몇 줄의 변경만 읽어서는 부족하다. 그 코드가 어떤 대화와 결정에서 나왔는지도 따라가야 한다. Zed는 2026년 8월 12일 이 문제를 겨냥한 별도 애플리케이션 Delta의 비공개 베타를 시작했다. Delta는 에이전트와 함께 코딩하고 결과를 검토하는 멀티플레이어 환경이다. 대화와 작업 트리를 함께 동기화하는 DeltaDB를 바탕으로 한다.
DeltaDB는 Git을 교체하지 않는다. 기존 Git 저장소와 함께 작동하며, 편집과 대화는 커밋 사이에 기록된다. 개발자는 평소처럼 커밋하고 푸시할 수 있다. Delta를 열지 않는 동료에게는 일반 Git 저장소로 보인다. Delta는 코드 변경에 대화의 시간축을 연결한다.
왜 코드 차이만으로는 검토가 부족해졌나
기존 코드 리뷰는 특정 커밋의 스냅샷에 의견을 붙인다. 후속 변경이 생기면 그 의견은 현재 코드와 멀어질 수 있다. 에이전트가 여러 파일을 연달아 고치고 계획, 명령 실행, 수정 제안을 대화에 쌓으면 이 간격은 더 커진다. 변경 이유를 찾으려면 diff, 채팅 기록, 터미널 세션을 오가며 의도를 다시 조립해야 한다.
Delta는 작업 트리의 임의 코드 줄과 대화의 임의 지점에 주석을 붙이도록 설계했다. 주석은 코드가 바뀌어도 변화와 함께 남는다. 같은 스레드에서 에이전트에게 설명이나 수정을 요청할 수도 있다. 리뷰어가 보는 대상은 최종 diff 하나가 아니라, 현재 코드에 이르기까지의 결정 과정이다.
대화와 작업 트리를 어떻게 함께 다루나
DeltaDB는 한 스레드의 대화와 작업 트리를 참여자에게 실시간으로 복제한다. 초대받은 사람만 스레드와 코드를 볼 수 있고, 각 참여자는 로컬 머신에 자기 작업 사본을 둔 채 동기화한다. 누군가 진행 중인 작업을 이어받을 때 최신 코드가 커밋됐는지, 푸시됐는지를 먼저 확인하느라 흐름이 끊기지 않게 하려는 구조다.
Zed에 따르면 클라우드 러너로 작업을 옮긴 뒤 노트북을 닫아도 에이전트의 실행, 대화, 코드는 스레드에 동기화된다. 브라우저에서는 Rust 애플리케이션을 WebAssembly로 컴파일하고 WebGL로 렌더링해 스레드를 열 수 있게 했다. 초기에는 Claude Code와 연결해 이미 쓰는 터미널 세션을 Delta 스레드로 실시간 동기화한다.
리뷰어의 질문이 작업 지시로 이어진다
에이전트 도구는 긴 응답과 큰 변경을 빠르게 만든다. 많은 도구는 이 양을 다루기 위해 diff를 접거나 대화를 자르고 요약을 앞세운다. Delta는 diff와 대화 기록을 가능한 한 그대로 열어 둔다. 사용자는 스레드 안의 정확한 문장, 계획 단계, 코드 줄에 커서를 두고 의견을 남긴다.
리뷰어의 “이 코드를 왜 바꿨나”라는 질문은 별도 회의나 새 프롬프트로 옮겨가지 않는다. 리뷰어는 문제가 보인 위치에 질문을 남기고, 에이전트는 처음의 대화와 결정 맥락을 가진 채 답하거나 고친다. 사람 동료도 같은 자리에서 코드를 읽고 다음 작업을 이어받는다.
개발팀이 가져갈 기준은 도구 수가 아니라 맥락의 위치다
Delta는 새 편집기 기능을 덧붙인 제품이 아니라, 대화가 소프트웨어 작업의 중심이 된 환경을 전제로 만든 첫 클라이언트다. Zed는 장기적으로 DeltaDB를 Zed에도 넣겠다고 했다. 기존 사용자의 작업 흐름을 흔들지 않으면서 복제 기반 구조를 다듬기 위해 별도 애플리케이션으로 출발했다.
에이전트 코딩을 팀에 넣을 때는 모델이 한 번에 몇 파일을 고치는지보다 변경 요청, 실행 결과, 코드 줄, 검토 의견이 어디에 붙어 있는지를 먼저 살펴야 한다. 이 연결이 끊기면 리뷰는 결과물을 확인하는 절차가 된다. 연결돼 있으면 검토는 다음 수정과 인수인계의 입력이 된다. Delta의 비공개 베타는 이 연결을 제품의 기본 단위로 삼겠다는 제안이다.