커서(Cursor)가 8월 17일부터 자체 코드 호스팅 서비스 Origin을 모든 유료 플랜에 얼리 베타로 열었다. 저장소 생성, 풀 리퀘스트, 코드 브라우징, 깃허브(GitHub) 동기화까지 지원해, 깃허브 없이도 코드를 통째로 커서 안에 둘 수 있게 됐다. 다만 무료 플랜에는 제공하지 않고, 엔터프라이즈 조직은 관리자가 옵트아웃하지 않는 한 자동으로 켜진다.
Origin은 커서 안의 새 Codebase 탭에서 시작한다. 조직 이름(코드베이스명)을 한 번 정하면 이후 모든 저장소 URL이 cursor.com/codebase/{조직명}/{저장소명} 형태로 붙는다. 저장소를 새로 만들면 CLI 설치 명령과 클론·푸시 명령이 바로 안내되고, 로컬 프로젝트를 푸시하는 순간 그 코드는 커서가 호스팅하는 저장소가 된다. CLI는 ~/.local/bin/origin에 설치되며, 로그인하면 git credential helper도 함께 설정돼 별도 인증 없이 git push·git pull이 동작한다.
깃허브 저장소를 그대로 옮기지 않고 나란히 둘 수 있다
Origin은 기존 깃허브 저장소를 옆에 두는 방식으로도 쓸 수 있다. 깃허브 조직을 연결하고 동기화할 저장소를 고르면, 그 저장소가 커서 안에서 보이기 시작한다. 접근 권한은 깃허브의 읽기·쓰기 설정을 그대로 따르고, 동기화는 실시간으로 갱신된다. 중요한 건 방향이다. 푸시는 계속 깃허브로 가고, 깃허브가 원본 소스로 남는다. 커서 쪽 사본은 브라우징·검색·풀에만 쓰인다.
풀 리퀘스트도 양방향으로 동기화된다. 커서에서 남긴 댓글은 깃허브에 그대로 올라가고, 깃허브에서 단 반응이나 답글은 몇 초 안에 커서 화면에 나타난다. 깃허브에서 리뷰가 배정된 풀 리퀘스트를 커서에서 그대로 승인하고 머지할 수도 있다. 저장소 설정 화면에서는 동기화 상태, 접근 권한, 연결된 앱을 한 곳에서 확인한다.
에이전트와 CI·배포 도구까지 같은 화면에 들어왔다
커서는 출시 첫날 Vercel, Depot, Buildkite 세 개의 연동을 붙였다. Vercel은 모든 풀 리퀘스트마다 프리뷰 배포를 만들고 머지되면 그대로 프로덕션에 반영한다(Pro·Enterprise 대상 퍼블릭 베타). Depot과 Buildkite는 기존 깃허브 액션 워크플로를 그대로 실행하는 CI이고, Buildkite는 자체 파이프라인도 함께 지원한다. 즉 빌드·배포 파이프라인을 새로 짜지 않아도 저장소만 옮기면 그대로 붙는다.
여기서 커서가 강조하는 건 에이전트가 코드와 풀 리퀘스트 옆에 함께 있다는 사실이다. 보고 있는 코드에 질문하면 답을 받고, 리뷰 코멘트를 넘기면 에이전트가 풀 리퀘스트를 바로 수정하며, 브랜치 푸시도 시킬 수 있다. RuntimeWire가 보도한 커서의 내부 수치를 보면 이 구조를 만든 이유가 짐작이 간다. 커서 안에서 머지된 풀 리퀘스트의 35%는 클라우드 가상머신에서 자율적으로 동작한 에이전트가 연 것이었다. 사람이 의도를 설명해줄 수 있다는 전제로 만든 기존 포크(forge) 구조로는, 병합 대기열의 3분의 1을 차지하는 이 작업들을 다루기 어렵다.
하필 출시 3시간 반 만에 깃허브가 멈췄다
공교롭게도 Origin이 월요일 아침 롤아웃을 시작하고 약 3시간 30분 뒤, 깃허브 상태 페이지에 장애가 떴다. VentureBeat가 깃허브 공식 인시던트 로그를 인용해 정리한 바로는 이 장애가 6시간 42분 동안 이어졌고, 풀 리퀘스트·이슈·API 오류율이 20%에 가까웠으며 아카이브·raw 파일 다운로드 오류율은 50%에 달했다. SAML·OIDC·SCIM 프로비저닝 같은 엔터프라이즈 SSO 기능과 Copilot도 함께 멈췄고, 장애는 20시 22분(UTC)에 해소됐다.
제품 출시는 보통 몇 주 전에 확정되므로 커서가 이 타이밍을 노렸다고 볼 근거는 없다. 하지만 이 우연은 Origin이 하려는 주장을 그대로 증명해 버렸다. 커서 소속 개발자 매트 파머는 자기 회사의 출시 소식에 "원래 더 일찍 내보내려고 했는데, 깃허브가 다운돼서 못 했다"는 댓글을 달았다. 버셀 CEO 기예르모 라우치도 X에 "이제 Origin에 저장소를 올리고 Origin에서 Vercel로 배포할 수 있는데, 그 Origin 자체가 Vercel에 호스팅돼 있다"며 "깃허브와 달리 온라인 상태"라고 적었다.
깃허브의 잦은 장애가 만든 빈틈
이런 반응이 나오는 배경에는 누적된 불만이 있다. 업계 매체 LeadDev 집계로는 2025년 5월부터 2026년 4월까지 깃허브에서 257건의 인시던트가 있었고 그중 48건이 주요 장애였다. 2월 한 달에만 37건이 몰려 최악의 달로 기록됐고, 깃허브 액션만 놓고 봐도 12개월간 57차례 중단됐다. 깃허브 최고기술책임자 블라드 페도로프는 "지금 규모를 감당하도록 만들어진 플랫폼이 아니다"라며 앞으로 지금의 30배 부하를 견디도록 설계해야 한다고 말한 바 있다. 깃허브 최고경영자였던 토머스 돔키는 2025년 8월 사임한 뒤 후임 없이 마이크로소프트 CoreAI 조직에 통합됐다.
Zig 언어 프로젝트가 2025년 11월 깃허브 액션 장애를 이유로 Codeberg로 옮겼고, 5만 2천 개 넘는 스타를 보유한 터미널 프로젝트 Ghostty도 같은 이유로 이탈을 발표했다. The Information은 오픈AI 역시 장애로 엔지니어들이 몇 시간씩 커밋하지 못하는 상황을 겪은 뒤 자체 깃허브 대안을 만들기 시작했다고 보도했다. Origin은 이런 불만이 쌓인 시점에 나온, 준비된 대안인 셈이다.
회사 코드를 어디에 맡길지, 확인해야 할 것들
다만 Origin을 팀 전체에 들이기 전에 짚어야 할 부분도 있다. 첫째, 기본값이 옵트아웃이다. 유료 플랜이면 관리자가 따로 끄지 않는 한 자동으로 활성화되므로, 회사 코드를 새 호스트에 미러링할지 결정을 내린 적 없는 조직도 사실상 결정이 내려진 상태가 된다. 둘째, 커서는 데이터 보관 기간·처리 지역·학습 활용 여부 같은 약관을 아직 공개하지 않았다. 셋째, Origin이 안전하게 시도할 수 있는 이유인 "깃허브가 원본으로 남는다"는 구조와 액션 호환성 자체가, 커서의 이해관계가 바뀌면 가장 먼저 흔들릴 수 있는 부분이기도 하다.
이 흐름을 더 눈여겨봐야 할 이유는 커서의 지분 구조에도 있다. Origin 출시 사흘 전, 블룸버그는 스페이스X가 600억 달러 규모의 올스톡 거래로 커서 인수를 마쳤다고 보도했다. 커서는 이제 SpaceXAI라는 사업부 안에서 운영된다. 코드 저장소를 맡아 달라고 요청하는 회사가, 자체 프런티어 모델 사업부를 둔 로켓 기업의 한 부서가 된 셈이다. Origin의 풀 리퀘스트·PR 동기화 기능 뒤에는 2025년 12월 커서가 인수한 코드 리뷰 스타트업 Graphite의 스택형 PR 기술이 있다. 인수 당시 시리즈 B 밸류에이션 2억 9천만 달러를 훌쩍 웃도는 금액이었다고 Axios는 전했다.