제품 관점2026-08-19

Cursor가 저장소까지 가져간다

Origin 얼리 베타가 8월 17일 유료 플랜 전체에 열렸다

Cursor가 자체 코드 호스팅 Origin을 열었다. 저장소, 풀리퀘스트, GitHub 실시간 양방향 동기화가 첫 묶음이다. 옮기라고 요구하지 않는 설계라서 마이그레이션 회의 없이 무게중심만 넘어간다.

8월 17일 Cursor가 Origin을 얼리 베타로 풀었다. 코드 편집기가 이제 코드 보관까지 한다. 첫 묶음은 저장소 생성, 풀리퀘스트, 코드 브라우징, GitHub 동기화다. 대상은 Pro·Teams·Enterprise 유료 플랜 전체, 엔터프라이즈 조직은 관리자가 옵트아웃하면 빠진다. 무료 플랜은 제외다.

새 기능 목록보다 눈여겨볼 자리는 따로 있다. 이 제품은 GitHub를 떠나라고 요구하지 않는다.

한 줄 정리

AI 코드 편집기가 저장소까지 품으면서 이사 결정 없이 일상 작업만 조용히 넘어가는 경로가 열렸다.

한눈에 보기

항목 현재 상태
저장소·코드 브라우징 얼리 베타 제공, 주소는 cursor.com/codebase/{이름}
풀리퀘스트 타임라인·커밋·체크·변경 파일·머지
GitHub 동기화 실시간 양방향, 푸시는 GitHub로 유지
앱 연동 Vercel 미리보기 배포, Depot·Buildkite CI
에이전트 모든 저장소에서 질문·수정·PR 갱신·브랜치 푸시

마이그레이션을 요구하지 않는 게 설계다

동기화한 저장소는 GitHub가 그대로 원본으로 남는다. 푸시도 계속 GitHub로 간다. Cursor 안에서 단 코멘트는 GitHub에 올라가고 GitHub에서 단 답글은 몇 초 안에 Cursor에 뜬다. GitHub에서 배정받은 리뷰를 Cursor에서 읽고 머지할 수도 있다. 어느 저장소가 Cursor 것이고 어느 게 GitHub에서 온 건지는 아이콘으로 구분된다.

그래서 팀이 결정할 일이 없다. 아무것도 옮기지 않았고 아무 회의도 안 열었는데 하루 대부분을 Cursor 창에서 보내게 된다. 도구 교체는 결심으로 일어나지 않는다. 습관으로 일어난다.

GitHub는 정확히 이 방식으로 커졌다. 그리고 8월 17일 무렵 GitHub 장애가 겹치면서 개발자 커뮤니티가 이 출시를 농담거리로 만들었다. 농담이 잘 먹혔다는 건 대안을 찾던 사람이 그만큼 있었다는 뜻이다.

무료 플랜을 뺀 것도 계산이 들어간 선택이다. 코드 호스팅은 서버 비용이 실제로 드는 기능이라 무료로 열면 저장소만 만들고 떠나는 계정이 몰린다. 돈을 내는 사람만 들이면 비용이 통제되고 동시에 유료 전환의 이유가 하나 늘어난다. 편집기 구독료에 저장소가 딸려 오면 팀 입장에서는 따로 결제하던 항목이 하나 줄어든 것처럼 보인다.

에이전트를 저장소 옆에 두면

코드와 풀리퀘스트와 에이전트가 한 화면에 있다. 브라우징 중인 코드를 두고 물어보면 답하고 고치고 풀리퀘스트를 갱신하고 브랜치를 민다. 파일을 열어 붙여 넣고 다시 돌아가는 왕복이 사라진다.

바깥 도구도 붙였다. Vercel을 연결하면 풀리퀘스트마다 미리보기 배포가 뜬다. CI는 Depot과 Buildkite가 받고 둘 다 기존 GitHub Actions 워크플로를 그대로 돌린다. 파이프라인을 다시 짜지 않아도 되게 만들어 뒀다는 뜻이다. 갈아타는 비용을 0에 가깝게 깎는 게 이 출시의 핵심 작업이었다.

에이전트 전용 기능은 아직 안 나왔다. Cursor는 곧 낸다고만 적었다. 지금 나온 묶음은 저장소와 풀리퀘스트라는 기본기뿐이고 그건 GitHub가 15년 넘게 다듬은 영역이다. 기능 비교로 보면 Origin은 한참 뒤에 있다. 그런데도 이 출시가 의미를 갖는 이유는 비교가 기능 대 기능으로 일어나지 않기 때문이다. 코드를 읽고 고치는 시간이 이미 편집기 안에서 흐르고 있으면 창을 하나 덜 여는 편의가 기능 열 개를 이긴다.

코드를 안 짜는 팀도 같은 걸 만난다

이 패턴은 개발 도구만의 일이 아니다. 디자인 도구가 에셋 원본을 가져가고, 문서 도구가 지식 베이스를 가져가고, 광고 도구가 크리에이티브 원본과 성과 이력을 가져간다. 순서가 똑같다. 편집기가 창고를 겸하면 일이 편해지고 그만큼 나가기 어려워진다.

지금 확인할 항목은 네 개다.

  1. 올린 자료가 학습이나 분석에 쓰이는지, 그 조건이 문서로 있는지
  2. 통째로 내보내는 경로가 있는지, 그게 클릭 몇 번인지
  3. 조직 관리자가 이 기능을 끌 수 있는지
  4. 계약이 끝나면 보관된 자료가 언제 어떻게 사라지는지

Origin은 얼리 베타 상태로 유료 플랜 전체에 열렸고 옵트아웃은 엔터프라이즈 관리자에게만 있다. 세 번째 항목이 특히 실질적인 이유다. Pro나 Teams 플랜을 쓰는 5인 팀에는 조직 단위로 끄는 스위치가 따로 없다. 팀원 한 명이 편해서 저장소를 올리면 그게 팀의 결정이 된다. 규칙은 도구가 아니라 사람 쪽에 걸어야 하는 상황이다.

같은 질문을 지금 쓰는 도구 전부에 던져 보면 대개 답이 안 나온다. 계약서를 다시 읽어야 알 수 있고 내보내기 경로는 눌러 봐야 안다. 확인에 드는 시간은 도구당 10분 안쪽이고 대부분의 팀은 그 10분을 한 번도 안 쓴다.

anyAX 관점

Origin이 영리한 자리는 GitHub를 원본으로 남겨 둔 대목이다. 떠나라고 하면 저항이 생기고 옆에 두라고 하면 아무도 회의를 안 연다. 그렇게 반년이 지나면 리뷰 기록도 배포 미리보기도 CI 알림도 전부 한 회사 계정 안에 쌓인다. 그때 GitHub는 여전히 원본이지만 팀의 기억은 아니다. 원본과 기억이 갈리는 순간이 갈아타기 비용이 실제로 발생하는 지점이다.

그러니 이번 주에 볼 건 기능 목록이 아니라 나가는 문이다. 저장소 하나를 시험 삼아 올리기 전에 내보내기 버튼이 어디 있는지 먼저 눌러 보는 순서. 5분이면 끝나고 안 하면 반년 뒤에 못 한다.

그리고 이건 코드만의 얘기도 아니다. 우리 팀이 쓰는 도구 중 원본을 들고 있는 게 몇 개인지 세 보면 대개 세다가 멈춘다. 디자인 파일, 고객 문의 이력, 광고 소재, 회의록. 편해서 하나씩 맡긴 것들.

참고