AI가 코드를 많이 만들면 저장소도 바뀌어야 할까. Cursor의 코드 호스팅과 Zed의 새 협업 도구를 보면 GitHub를 떠나는 이야기부터 나오기 쉽다. 하지만 코드 저장 위치를 바꾸는 일, 변경을 검토하는 화면을 바꾸는 일, Git 자체를 대체하는 일은 서로 다르다.
이 글은 2026년 9월 8일에 확인한 공식 발표를 기준으로 내용을 갱신했다. 최초 작성일 이후 공개된 기능을 반영한 문서 검토이며, 두 제품을 운영 저장소에 도입해 비교한 후기는 아니다. 확인되지 않은 커밋 규모나 인수 금액으로 제품의 미래를 판단하지 않고, 작은 프로젝트에서도 점검할 수 있는 이전 조건을 정리한다.
Origin에서 원본이 어디에 있는지부터 구분한다
Cursor는 8월 17일 Origin 코드 호스팅을 초기 베타로 공개했다. 발표에서 특히 구분해야 할 부분은 Origin에 직접 호스팅하는 저장소와 GitHub에서 동기화하는 저장소다. 전자는 Origin이 기준 저장소이고, 후자는 GitHub가 기준이며 푸시도 GitHub로 간다. 같은 화면에 보인다고 데이터의 책임 위치까지 같아지는 것은 아니다. Cursor Origin 공개 안내
예를 들어 GitHub의 프로젝트를 Origin에 연결해 코드와 PR을 본다고 하자. 이것을 ‘GitHub에서 이전 완료’라고 부르면 장애 대응이 꼬인다. 동기화가 늦어졌을 때 어느 쪽을 확인해야 하는지, CI가 어느 저장소의 이벤트를 받는지부터 따져야 한다. 팀 문서에 기준 저장소와 연결된 서비스를 적어 두면 이런 혼동을 줄일 수 있다.
직접 호스팅을 선택하면 질문이 달라진다. 기존 브랜치와 태그뿐 아니라 검토 댓글, 이슈 링크, 릴리스 산출물, 봇 권한을 어디에서 관리할 것인가. Git 데이터가 옮겨졌다는 사실만으로 협업 기록이 모두 이전됐다고 볼 수 없다. 코드가 정상적으로 복제되는 검사와 업무 이력이 보존되는 검사를 따로 해야 한다.
Origin 발표에는 PR 검토와 일부 배포·CI 연결도 설명돼 있다. 다만 내가 쓰는 모든 GitHub 기능이나 조직 정책이 그대로 지원된다는 의미는 아니다. 도입할 계정에서 지원 여부를 확인하고, 베타 범위와 나중에 추가될 기능을 구별해야 한다. 현재 문서에서 확인하지 못한 기능을 ‘곧 될 것’이라는 전제로 필수 경로에 넣지는 않겠다.
DeltaDB는 기존 Git을 버리는 제품 설명이 아니다
Zed는 8월 12일 Delta를 비공개 베타로 소개했다. 발표에서 DeltaDB는 대화와 작업 트리를 함께 동기화하며, 기존 Git 저장소와 함께 동작한다고 설명한다. 커밋과 푸시는 계속 사용할 수 있고 Delta를 쓰지 않는 동료에게도 일반 Git 저장소로 보인다. 따라서 이를 Git 폐기 선언으로 요약하면 제품 설명과 어긋난다. Zed의 Delta 소개
내가 관심을 두는 부분은 커밋 사이의 맥락이다. 최종 diff만 보면 함수가 바뀐 사실은 알 수 있어도, 어떤 요구를 받아 무엇을 포기했는지는 모를 때가 있다. 대화와 코드가 연결되면 이 간격을 줄일 가능성이 있다. 이것은 발표를 읽고 얻은 기대이며, 실제 검토 시간이 줄었다는 측정 결과는 아니다.
대화를 더 많이 저장하는 데 따른 질문도 있다. 프롬프트에 포함된 내부 문서나 개인 정보는 누가 볼 수 있는가. 작업 중 잠시 만든 코드와 폐기한 가설은 어디까지 남는가. 계정을 끊으면 어떤 기록을 내보낼 수 있는가. 코드 저장소 접근 권한과 대화 공유 권한이 같은지 확인해야 한다.
대화 전체가 있다는 이유만으로 의사결정 기록을 생략할 수도 없다. 길게 오간 대화에서 최종 합의가 무엇인지 찾기 어렵다면 검토 부담은 남는다. 중요한 변경에는 요청, 선택한 접근, 버린 대안, 검증 결과를 짧게 묶은 기록이 필요하다. 자동 수집한 대화와 사람이 책임지는 결정 문서는 용도가 다르다.
비교표에는 기능 수 대신 현재 업무의 의존성을 적는다
두 제품을 같은 대체재로 점수 매기기 전에 내 작업의 실패 지점을 정리하는 편이 낫다. 코드 호스팅 문제인지, 에이전트의 작업을 따라가기 어려운 문제인지에 따라 시험할 제품과 기준이 달라진다.
| 확인 대상 | 기존 흐름에서 적을 내용 | 새 도구에서 확인할 질문 |
|---|---|---|
| 기준 저장소 | 배포에 쓰는 커밋이 최종 확정되는 위치 | 동기화 사본인가, 직접 호스팅인가 |
| 검토 기록 | 승인한 사람, 당시 diff, 보완 요청 | 코드 수정 뒤 이전 승인의 의미가 유지되는가 |
| 자동 검사 | 필수 검사 이름과 실행 주체 | 새 연결에서도 같은 커밋을 검사하는가 |
| 권한 | 읽기·쓰기·병합·배포 권한을 가진 계정 | 연동으로 추가 권한이 생기거나 넓어지는가 |
| 복구 | 저장소, 문서와 산출물의 백업 경로 | 계정을 끊어도 원래 흐름으로 돌아갈 수 있는가 |
이 표는 제품별 기능 보장을 뜻하지 않는다. 시험 전에 작성할 점검표다. 한 사람이 운영하는 블로그라면 복잡한 조직 권한보다 배포 커밋이 엇갈리지 않는 것이 더 급할 수 있다. 여러 팀이 공유하는 저장소라면 승인자와 감사 기록이 우선일 수 있다.
또 하나 볼 것은 외부 링크다. 예전 PR URL이 문서나 장애 보고서에 붙어 있다면 이전 뒤에도 맥락을 찾을 수 있어야 한다. URL이 깨졌는데 코드만 남았다고 이전 성공을 선언하면, 과거 결정 이유를 다시 추적하는 비용이 발생한다. 시험할 때는 최근 PR뿐 아니라 오래된 장애 수정 기록도 하나 골라 따라가 보는 것이 좋겠다.
AI가 만든 변경에도 기존 병합 조건이 살아 있어야 한다
GitHub의 브랜치 보호는 검토 승인, 상태 검사, 강제 푸시 제한 같은 조건을 설정할 수 있다. 관리자와 우회 권한의 예외도 설정에 따라 달라진다. 새 도구에서 PR을 조작할 수 있다는 사실과 기존 보호 조건을 동일하게 지킨다는 사실은 별도로 검증해야 한다. GitHub 보호된 브랜치 문서
안전한 시험은 민감 정보가 없는 연습용 저장소에서 시작할 수 있다. 보호된 브랜치에 작은 변경을 보내고, 실패하도록 만든 검사 때문에 병합이 막히는지 본다. 검토 후 변경을 추가했을 때 승인 상태가 어떻게 처리되는지도 확인한다. 이 시험을 통과했다고 운영 저장소의 모든 정책까지 검증한 것은 아니므로, 실제 규칙 목록과 대조한 기록을 남긴다.
에이전트가 갖는 토큰도 따로 확인해야 한다. 읽기 도구를 연결하려다가 쓰기나 배포 권한까지 주는 일은 피한다. 현재 연결에 필요한 범위와 서비스가 요청하는 범위를 비교하고, 필요하지 않은 권한이 필수라면 시험을 멈춰도 된다. 이 글에 특정 제품의 권한 결함이 있다는 뜻은 아니다. 새 연동을 추가할 때 적용할 공통 점검이다.
검토 화면에서 AI의 설명이 잘 읽힌다고 테스트가 대신되는 것은 아니다. ‘기존 동작을 유지했다’는 설명은 기존 동작의 검사가 통과했을 때 의미가 있다. 반대로 테스트가 통과했더라도 승인 범위 밖의 파일을 고쳤다면 검토에서 되돌려야 한다. 자연어 설명, diff, 검사 결과가 같은 변경을 가리키는지 함께 보겠다.
이전 실험은 돌아오는 경로까지 포함한다
실험의 첫 목표를 ‘새 도구에서 PR 하나를 끝내기’로 잡으면 범위가 명확해진다. 기존 흐름에서 같은 유형의 변경이 어떻게 처리되는지도 기록해 둔다. 새 화면에서 설명을 찾는 시간, 검토자가 놓친 맥락, CI 결과를 찾는 경로를 비교하되, 한 번의 결과를 생산성 향상률로 발표하지 않는다.
동기화 중단도 시험 대상이다. 연결을 잠시 중단했을 때 읽는 사본이 오래된 상태임을 알 수 있는지, 다시 연결했을 때 충돌을 어떻게 확인하는지 문서와 시험 기록을 맞춰 본다. 실제 시험에서는 작업 중인 사용자가 없는 연습 저장소를 쓰고, 운영 연결을 임의로 끊지 않는다.
복구 계획에는 코드 백업 외에 연결 해제 순서를 적는다. 어느 서비스에서 토큰을 폐기하고, 어떤 자동화의 입력 저장소를 원래 위치로 돌리고, 배포 커밋을 어떻게 확인할 것인가. 새 도구의 대화 기록이 이전 방식으로 완전히 내보내지지 않는다면 필요한 결정 사항을 별도 문서로 남기는 대안도 검토한다.
도입 판단은 ‘GitHub가 끝났다’ 같은 전망 없이도 할 수 있다. 현재 검토의 어려움을 줄이고 필요한 통제를 유지하며 되돌아올 수 있다면 제한된 범위에서 확대한다. 기존 흐름으로도 문제를 해결할 수 있고 이전 비용이 더 크다면 기다린다. Origin의 저장 방식과 Delta의 대화 기록이 각자 무엇을 바꾸는지 구분하는 것부터가 그 판단의 시작이다.
참고자료
- Cursor — Origin Code Hosting: 2026년 8월 17일 초기 베타 발표와 저장 모드 구분.
- Nathan Sobo, Zed — Introducing Delta: 2026년 8월 12일 발표, 대화·작업 트리 동기화와 Git 공존 설명.
- GitHub Docs — About protected branches: 병합 전 검사·승인과 우회 설정의 확인 기준.