Pull Request를 대체하는 Delta — Zed의 멀티플레이어 에이전트 코딩 환경 공개 베타

본문

Zed를 만드는 Zed Industries가 코딩 에이전트 시대의 협업 도구로 설계한 Delta의 공개 베타를 출시했습니다. 핵심 주장은 명확합니다. 에이전트가 소프트웨어 작성 방식을 근본적으로 바꿨지만 협업 도구는 따라가지 못하고 있으며, GitHub가 15년 전 도입한 pull request가 그 징후라는 것입니다. 에이전트가 생성하는 코드가 폭증하면서 리뷰를 요청하는 diff의 크기도 함께 커졌고, diff를 여러 브랜치로 쪼개도 '왜 이렇게 만들었는가'라는 의사결정 맥락은 전달되지 않는다는 문제의식이 출발점입니다.

PR 없이 일하기 — 스레드 기반 협업

Delta의 가장 큰 차이점은 협업이 코드의 커밋과 푸시에 의존하지 않는다는 점입니다. 팀원을 에이전트와의 대화 스레드에 직접 초대하면, 참여자는 같은 worktree를 보고 자신의 머신에서 함께 작업할 수 있습니다. 팀원은 같은 에이전트에게 '왜 RwLock 대신 Mutex를 선택했는가' 같은 질문을 던질 수 있고, 원작성자가 로그오프해도 에이전트와의 작업을 이어받아 계속 진행할 수 있습니다. 리뷰를 위해서는 전용 리뷰 서브스레드를 만들 수 있으며, 리뷰는 원래 에이전트의 컨텍스트에 접근한 상태로 브랜치의 변경 사항을 안내합니다. 각 리뷰는 부모 스레드 worktree의 격리된 복사본을 받으므로, 리뷰어가 에이전트와 함께 코드를 탐색하고 수정을 시도해도 원래 작업을 방해하지 않습니다. 리뷰 중 발견한 문제는 수정 요청을 하거나 리뷰어가 직접 에이전트와 고칠 수 있고, 이 수정은 변경을 랜딩하기 전에 부모 스레드에 병합됩니다.

DeltaDB — Git 위의 델타 버전 관리

Delta는 Git의 콘텐츠 기반 버전 관리를 델타 기반 증분 버전으로 확장한 DeltaDB 위에 구축되어 있습니다. DeltaDB는 커밋 사이의 편집 내역을 사람과 에이전트의 메시지와 함께 기록해, 스레드 전체에 걸쳐 코드가 어떻게 진화했는지를 보존합니다. 커밋은 여전히 푸시·풀·빌드의 체크포인트로 남고, DeltaDB는 그 체크포인트 사이의 작업을 보관하는 구조입니다. 팀 전체가 Delta로 옮길 필요도 없습니다. 예를 들어 zed-industries/zed 저장소는 커뮤니티가 이슈와 변경을 제출하는 곳이므로 당분간 GitHub에 유지되며, 기여자는 pull request와 함께 Delta 스레드를 공유하는 방식이 권장됩니다. Delta를 열지 않는 팀원에게는 평범한 Git 저장소로만 보입니다.

'Continuous Engineering'과 로드맵

Zed 팀은 스레드가 소프트웨어 개발의 새로운 기본 단위가 될 것이며, 그 상태를 모델링하는 최선의 방법은 델타라고 주장합니다. 업계가 통합(integration)과 배포(delivery)를 연속화하는 동안 나머지 엔지니어링은 여전히 배치 방식이었다며, Delta 스레드에서는 아이디어·구현·리뷰·랜딩이 모두 한곳에서 일어나는 'continuous engineering'을 제안합니다. pull request는 GitHub 워크플로우에서 떠나보내는 첫 번째 요소이며, DeltaDB의 Git 스토리지를 시작으로 다른 워크플로우도 대체해 나갈 계획입니다. 장기적으로는 콘텐츠 기반 빌드로 CI 스타일 검증을 스레드 안으로 가져오는 것을 목표로 하며, 현재는 에이전트가 기존 CI 제공자에 실행을 트리거하고 결과를 확인한 뒤 랜딩하는 방식입니다.

도입 현황과 가격

실사용 지표도 공개했습니다. 지난주 Delta 자체 저장소에서 pull request를 비활성화한 뒤, 33명의 팀원이 570개의 변경을 main에 랜딩했습니다. 공개 베타 기간 동안 Delta는 무료이며, 개인·팀용 유료 플랜이 곧 도입되지만 무료 버전은 항상 유지됩니다. macOS, Linux, Windows 클라이언트 외에 웹과 모바일 브라우저에서도 스레드를 따라갈 수 있습니다.

Lobsters 반응

• @typesanitizer — 본문의 '큰 diff를 브랜치 스택으로 나누면 탐색은 쉬워지지만 코드 뒤의 의사결정은 여전히 리뷰가 필요하고, 작은 diff는 그 맥락을 제공하지 않는다'는 대목을 인용하며 반례를 제시했습니다. 크고 복잡한 계획은 먼저 문서를 작성해 PR로 리뷰받을 수 있고, 커밋 메시지와 PR 설명으로 상위 수준 의사결정을 전달할 수 있으며(GHC식 named notes도 활용 가능), 명백하지 않은 하위 수준 결정은 코드 주석으로 남길 수 있다는 기존 워크플로우 기반 대안을 들었습니다.

원문: Zed Blog / 번역·요약: Trawling