Cursor 자체 코드호스팅 출시, GitHub는 6시간 장애

8월 17일 월요일 아침, Cursor는 Origin이라는 새 기능을 모든 유료 사용자에게 배포하기 시작했다. 코드 호스팅 서비스로, 아직 초기 베타 단계이며 엔터프라이즈 플랜은 옵트아웃할 수 있다. 약 세 시간 반 뒤, GitHub에서 전 세계적인 서비스 저하가 발생해 6시간 42분간 지속됐고, 일부 기능의 오류율은 20%에 가까웠다.

두 사건 사이에 인과관계는 없다. 하지만 같은 날 아침에 겹쳤다는 사실 자체가 어떤 발표회보다 설득력이 있었다.

실제로 무엇을 제공하나

화면에는 새로 Codebase 탭이 생겨, 그 안에서 저장소를 만들고 관리할 수 있다. 로컬 프로젝트는 CLI를 통해 클론하거나 푸시할 수 있으며, 저장소 주소는 cursor.com/codebase/<name> 형태다. Pull Request 기능은 통째로 옮겨왔다. 타임라인, 커밋 기록, 체크 상태, 파일 변경 사항, diff 리뷰, 댓글, 머지까지 모두 갖췄고, GitHub에서 자신에게 배정된 PR도 Cursor 안에서 바로 리뷰할 수 있다.

GitHub와의 관계는 양방향 동기화다. GitHub 조직을 연결하면 기존 저장소가 Origin으로 동기화되고, Cursor에서 작성한 댓글은 GitHub로 전달되며, GitHub의 댓글도 다시 돌아온다. 공식 설명에 따르면 GitHub는 계속 source of truth로 남고, 푸시는 여전히 GitHub로 직접 들어가며, 사용자는 언제든 연결을 끊을 수 있다.

이미 연동된 서드파티로는 Vercel, Depot, Buildkite가 있으며, 프리뷰 배포와 CI 파이프라인을 커버한다.

리뷰 기능은 처음부터 새로 만든 게 아니다. 2025년 12월 Cursor는 코드 리뷰 스타트업 Graphite를 인수했다. 그 팀과 기술이 지금 Origin의 리뷰 워크플로를 떠받치고 있다. 당시 이 인수는 에디터에 기능 하나를 더하는 것처럼 보였지만, 돌이켜보면 호스팅 계층을 위한 사전 준비였던 셈이다.

왜 지금인가

지난 몇 년간 Cursor의 위치는 'GitHub 위에 얹힌 한 겹의 레이어'였다. Agent가 코드 수정을 마치면 PR을 올려야 하고, PR은 GitHub를 거쳐야 하며, 리뷰 코멘트도 GitHub에서 읽어야 하고, 도구는 그 결과를 다시 에디터로 동기화해야 한다. 이 흐름에서 시스템 간 왕복이 한 번 늘어날 때마다 Agent가 쓸 수 있는 컨텍스트는 줄고 지연 시간은 늘어난다.

호스팅 계층을 자체적으로 끌어안아서 얻는 건 네트워크 요청을 아끼는 것이라기보다 제품 정의권 그 자체다. 코드를 쓰는 주체가 사람에서 Agent로 옮겨가면, 저장소라는 개념의 형태도 함께 바뀌어야 한다. 누가 언제 어떤 파일을 볼 수 있는지, 하나의 변경을 어떻게 나눌지, 리뷰를 누구에게 보여줄지 — 이런 규칙은 지금까지 모두 인간의 협업 습관에 맞춰 정해져 있었다. Origin 공식 문구의 'Agent 규모에 맞춰 설계'라는 표현이 가리키는 게 바로 이 층위다.

GitHub 쪽 틈은 분명히 열려 있다. Microsoft는 2018년 75억 달러 상당의 주식으로 GitHub를 인수했다. 8년이 지난 지금, AI 코딩 시대에 GitHub의 역할은 꽤 애매하다. 모두의 코드를 호스팅하면서도 자사의 Copilot을 팔아야 하고, 수많은 경쟁 Agent에게 API도 열어줘야 한다. 8월에 6시간 넘게 이어진 이번 장애는 '호스팅이 곧 인프라'라는 암묵적 전제를 건드렸다.

이 판의 승산

현실적으로 보면 Origin 때문에 단기간에 저장소를 GitHub에서 옮기는 곳은 없을 것이다. 오픈소스 프로젝트의 이슈, 스타, 포크, CI 설정, 외부 기여자의 습관은 모두 GitHub 위에 뿌리내려 있다. 이전 비용은 사회적 측면에 걸려 있고, 기술적인 부분은 오히려 가장 풀기 쉬운 문제다. Cursor도 이를 알고 있어서, 첫 버전은 대체가 아니라 동기화를 택했다.

승산이 있는 쪽은 기업 내부 저장소다. 프라이빗 코드는 커뮤니티도, 외부 PR도 필요 없다. 기업이 신경 쓰는 건 오직 Agent가 빠르게 도는지, 리뷰 흐름이 매끄러운지, 구독료를 하나 줄일 수 있는지뿐이다. Cursor의 유료 사용자는 원래 이 영역에 집중돼 있고, Origin은 그들의 기존 워크플로 안에 바로 자리 잡는다. 시도해보는 데 드는 장벽은 거의 제로에 가깝다.

대략적인 계산도 같은 방향을 가리킨다. 200명 규모 기업이라면 GitHub Enterprise는 인원수 기준으로 연간 다섯 자릿수 달러가 든다. Cursor 구독료는 별도 항목이고, 두 제품이 겹치는 영역은 리뷰, CI 트리거, 코드 브라우징까지 빠르게 넓어지고 있으며 Origin은 그걸 다 커버한다. 갱신 시점에 기업이 물어야 할 질문은 하나뿐이다 — 이 두 비용을 다 낼 필요가 정말 있는가. 답은 Origin의 안정성이 버텨주느냐에 달려 있지, 기능 목록이 누가 더 기냐에 달려 있지 않다.

그 배경에는 자본 요인도 있다. Cursor는 이미 SpaceX 산하에 들어가 있고, 모회사의 현금흐름은 단기적으로 수익이 나지 않는 호스팅 서비스를 몇 년간 버틸 만큼 여유가 있다. 이는 투자 라운드의 눈치를 봐야 하는 스타트업이 같은 일을 하는 것과는 완전히 다른 게임이다.

지켜봐야 할 지표는 릴리스 노트에 없다. 반년 뒤 몇 개 기업이 Origin을 동기화 사본이 아니라 주 저장소로 설정했는지다. 동기화는 과도기이고, 주 저장소가 결론이다.

참고 출처: Cursor 공식 업데이트 로그, SiliconANGLE, CocoLoop, Slashdot; 베타 공개 범위, GitHub 장애 지속 시간 6시간 42분과 오류율 기준, Graphite 인수 시점을 확인함.