AI 코딩 도구 커서(Cursor)가 자체 코드 호스팅 서비스 'Origin'을 유료 플랜 사용자를 대상으로 초기 베타로 순차 출시한다. 지금까지 커서는 에디터와 에이전트에 집중해 왔고 코드의 원본 저장소는 대부분 깃허브에 두는 구조였다. Origin은 그 저장소 자체를 커서 안으로 끌어들이려는 시도다. 초기 버전은 repo 관리, 풀 리퀘스트, 코드 탐색, 그리고 깃허브 동기화라는 네 가지 축으로 출발하며, 커서는 이를 "에이전트 규모에 맞춰 설계했다"고 설명한다. 관리자가 옵트아웃한 기업 조직을 제외하면 오늘부터 유료 사용자 전반이 사용할 수 있다.
새 저장소를 만드는 방식
사용자는 커서에 새로 생긴 Codebase 탭에서 Origin 저장소를 다룬다. +New를 눌러 이름을 지정하면 CLI 설치 방법과 clone·push 명령이 담긴 안내 페이지가 나타나고, 로컬 프로젝트를 push하는 순간 코드가 Origin에 호스팅된다. 첫 저장소를 만들 때 지정하는 codebase 이름은 이후 모든 저장소 URL의 일부가 된다. 예컨대 cursor.com/codebase/acme-corp 형태로 조직 단위 주소가 구성되는 식이다. 구조만 보면 깃허브의 조직-저장소 계층과 크게 다르지 않아, 기존 개발자에게 학습 부담이 큰 방식은 아니다.
주목할 부분은 기존 깃허브 저장소와의 병행 사용이다. 깃허브 계정을 커서에 연결하고 조직을 선택하면 동기화 가능한 저장소 목록이 뜨고, 원하는 것을 고르면 커서가 이를 가져온다. 동기화 항목은 선택할 수 있고 연결은 언제든 해제할 수 있다. 다만 접근 권한 모델은 그대로 상속된다. 동기화된 저장소에 읽기 또는 쓰기 권한을 가진 사람은 커서에서도 같은 저장소를 볼 수 있으므로, 팀 입장에서는 어떤 저장소를 끌어올지 권한 범위를 함께 따져봐야 한다.
소스 오브 트루스는 여전히 깃허브
동기화된 저장소는 실시간으로 갱신되며 Origin에 놓인 복사본에서 탐색·검색·pull이 가능하다. 그러나 push는 계속 깃허브로 향하고, 깃허브에서 시작된 작업의 소스 오브 트루스는 깃허브에 남는다. 즉 Origin의 동기화 모드는 깃허브를 대체하는 것이 아니라 읽기 중심의 미러에 가깝다. 저장소 이름 옆 아이콘으로 커서가 직접 호스팅하는 저장소인지 깃허브에서 가져온 저장소인지 구분되는 점도, 두 모델이 당분간 공존한다는 것을 보여준다. 실무자 입장에서는 완전 이전이 아니라 점진적 병행 도입이 현실적인 경로가 된다.
풀 리퀘스트는 모든 저장소에 제공된다. PR을 열면 타임라인, 커밋, 검사 결과, 변경 파일을 확인하고 diff를 검토한 뒤 댓글을 달고 병합할 수 있다. 동기화된 저장소의 경우 이 흐름이 양방향으로 이어진다. 커서에서 남긴 댓글은 깃허브에 게시되고, 깃허브에서 단 답글이나 반응은 몇 초 안에 커서에 반영된다. 깃허브에서 나에게 배정된 리뷰를 커서 쪽에서 처리하고 병합하는 것도 가능하다. 코드 리뷰의 창구를 어느 한쪽으로 강제하지 않으면서, 에이전트에게 질문하고 그 자리에서 변경을 적용해 PR을 갱신하거나 브랜치를 푸시하는 통합 워크플로를 노린 설계다.
통합 생태계와 남은 물음
커서는 배포·CI 도구를 저장소의 앱 탭에 붙일 수 있게 했다. Vercel을 연결하면 모든 PR에 미리보기 배포가 생기고 병합 시 프로덕션으로 나간다. CI는 Depot이나 Buildkite를 연결하는데, 둘 다 기존 깃허브 액션 워크플로를 실행하고 Buildkite는 자체 파이프라인도 돌린다. 기존 액션 자산을 버리지 않고 재사용할 수 있다는 점은 이전 비용을 낮추는 요소다. 저장소마다 설정 화면에서 동기화 상태, 접근 사용자, 연결된 앱을 관리한다.
Origin의 실질적 의미는 코드, PR, 에이전트를 한 화면에 모아 커서를 개발 워크플로의 중심 허브로 만들려는 데 있다. 다만 초기 베타라는 점, 에이전트 네이티브 기능과 다수의 통합이 아직 "곧 제공"으로 예고된 상태라는 점은 분명한 한계다. 깃허브 이슈나 액션스 마켓 같은 성숙한 주변 생태계와의 격차, 그리고 코드 호스팅을 특정 AI 도구 사업자에게 맡기는 데 따르는 종속성도 조직이 도입 전에 저울질할 대목이다. 당장은 깃허브를 유지한 채 동기화 모드로 가볍게 시험해 보고, PR 양방향 동기화와 CI 연동이 팀의 실제 리듬에 맞는지 확인하는 편이 합리적이다.