이미지: TechCrunch AI 화면 갈무리
요약
- 커서가 이번 주 코드 호스팅 플랫폼 Origin을 출시해 깃허브가 담당해온 저장소·PR·협업 기능을 그대로 옮겨왔다
- Origin 출시 당일 깃허브는 6시간 넘게 세계적 장애를 겪었고 오류율이 20%에 달했다. 최근 1년간 장애만 257건이라는 분석도 나왔다
- Origin은 깃허브 계정을 연결해 저장소를 동기화하는 방식으로 깃허브와 병행 사용이 가능하며, 에이전트 네이티브 기능과 앱 생태계 확장이 예고됐다
- Origin 출시 시점
- 2026년 8월 셋째 주(현지 발표 기준)
- Origin 핵심 기능
- 저장소 호스팅, 코드 브라우징·편집, PR 처리, 깃허브와 상호연동
- 같은 날 깃허브 장애
- 6시간 이상 지속, 세계 오류율 약 20%
- 깃허브 최근 1년 장애 건수
- 257건 (LeadDev 분석, 찰스 험블)
- 깃허브 사용자 규모
- 1억8000만명 (깃허브 자체 집계, 지난해 10월 기준)
- 깃허브 연혁
- 2007년 설립, 2012년 마이크로소프트 인수
- 커서 소속 변화
- 2026년 8월 스페이스X에 인수, xAI와 같은 소속
- 예고된 후속 기능
- 에이전트 네이티브 기능, 앱 생태계 확장
깃허브가 멈춘 날, 커서가 문을 열었다
지난 18일(현지시간) 깃허브가 세계적으로 6시간 넘게 접속 장애를 겪었다. 오류율은 한때 20%에 달했다. 공교롭게도 같은 날 커서는 깃허브를 정면으로 겨냥한 코드 호스팅 플랫폼 Origin을 출시했다. 기술매체 LeadDev의 분석에 따르면 깃허브는 최근 1년간 257차례 장애를 겪었고, 이 매체 기자 찰스 험블은 이를 두고 유명 사용자들의 이탈이 눈에 띄게 늘고 있다고 짚었다.
깃허브는 전 세계 개발자가 코드를 올리고 함께 고치는 창고 역할을 해온 곳이다. 2007년 세워져 2012년 마이크로소프트에 인수됐고, 지난해 10월 기준 1억8000만명이 이곳에서 코드를 관리한다고 스스로 밝히고 있다. 반복되는 장애에도 여전히 세계 최대 코드 호스팅 서비스라는 지위는 흔들리지 않은 셈이다.
Origin이 하는 일
Origin은 깃허브가 담당해온 핵심 기능을 그대로 옮겨왔다. 팀원끼리 코드베이스를 같이 작업하고, 코드를 열람·수정하고, 다른 사람이 올린 수정 제안(PR)을 처리하고, 저장소에 코드를 보관하는 일까지 한 화면에서 처리한다. 다만 Origin을 쓴다고 깃허브를 그만 써야 하는 건 아니다. 커서는 자사 블로그에서 "깃허브 저장소는 커서가 호스팅하는 저장소와 나란히 놓일 수 있다"고 소개했다. 깃허브 계정을 커서에 연결하면 조직 단위로 저장소를 골라 동기화할 수 있다는 설명이다. 커서는 이와 함께 '에이전트 네이티브' 기능을 곧 선보이겠다고 예고했지만 구체적인 내용은 아직 공개하지 않았고, 코딩 작업 전반을 지원할 더 넓은 앱 생태계도 구축 중이라고 밝혔다.
원래는 편집기 회사였다
커서는 원래 AI 코드 편집기다. 화면 안에서 앤스로픽의 클로드, 오픈AI의 GPT, 구글의 제미나이 같은 다른 회사 모델을 골라 쓸 수 있게 해주는 한편, 컴포저라는 자체 모델도 직접 훈련해 함께 제공해왔다. 2026년 8월 스페이스X가 커서를 인수하면서 커서는 그록을 만드는 xAI와 같은 식구가 됐다. 코드 편집기에서 출발한 회사가 저장소 호스팅까지 손을 뻗은 셈이다.
이미 포착됐던 신호
Origin이라는 이름은 이번이 처음 등장한 게 아니다. 지난 13일 커서는 'Cursor Origin(Cursor Review)'이라는 이름으로 일부 파트너를 대상으로 비공개 베타를 진행 중이었고, 사이드바에 Codebase·Review 탭을 붙여 깃허브 저장소를 동기화하는 기능을 시험하고 있었다. 하루 뒤인 14일에는 벤처캐피털 a16z가 커서 공동창업자 마이클 트루엘의 2025년 인터뷰 발언을 다시 공유했는데, 그는 당시 모델 자체 개발과 멀티프로덕트 전환, 'AI 코딩 번들' 구축을 커서의 전략 축으로 꼽은 바 있다. 비공개 베타로 다지던 기능이 일주일여 만에 정식 출시로 이어진 흐름이다.
어떻게 써보나
Origin을 쓰려면 별도 프로그램 설치 없이 깃허브 계정 연동부터 시작한다. 1) 커서 계정에서 깃허브 계정을 연결한다. 2) 연동할 조직(org)을 선택한다. 3) 동기화 가능한 저장소 목록이 뜨면 원하는 저장소를 고른다. 4) 선택하면 커서가 해당 저장소를 그대로 가져와 Origin 안에서 작업할 수 있게 한다. 요금제나 대기열 같은 이용 조건은 아직 공개되지 않았다.
활용 예를 들면, 기존 깃허브 저장소는 그대로 두고 새로 시작하는 프로젝트만 Origin에서 관리해볼 수 있다. 팀 전체를 한 번에 옮기는 대신 일부 저장소만 먼저 동기화해 PR 처리와 협업 흐름이 어떻게 다른지 시험해보는 것도 가능하다.
깃허브 vs 커서 Origin
| 항목 | 깃허브 | 커서 Origin |
|---|---|---|
| 운영 주체 | 마이크로소프트(2012년 인수) | 커서(2026년 스페이스X 인수) |
| 사용자 규모 | 1억8000만명(지난해 10월 기준) | 출시 초기, 규모 미공개 |
| 최근 안정성 | 최근 1년 장애 257건(LeadDev) | - |
| 깃허브와의 관계 | - | 계정 연동으로 저장소 동기화·병행 사용 |
에디터의 시선
이번 출시는 우연이 아니다. 커서는 이미 지난 13일부터 같은 기능을 비공개로 시험하고 있었고, 마이클 트루엘이 1년 전부터 밝혀온 멀티프로덕트 전략의 다음 조각이 저장소 호스팅이었을 뿐이다. 깃허브의 장애가 겹친 건 타이밍이 좋았던 것이지, Origin을 만든 이유는 아니다. 편집기 하나로 개발자를 붙잡아두는 시대가 저물고 있다는 판단이 먼저 있었고, 장애는 그 판단을 증명해준 사건에 가깝다.
IDE 하나로 시작한 도구가 저장소 호스팅까지 들어오는 흐름은 낯설지 않다. 코드를 짜는 도구와 코드를 저장하는 창고를 분리해 쓰던 시절에는 두 서비스 사이를 오가는 게 당연했지만, 편집기 회사가 호스팅까지 붙이기 시작하면 개발자 입장에서는 이동 비용이 줄어드는 대신 한 회사에 묶이는 위험이 커진다. 이번 Origin도 깃허브와 병행 사용을 강조한 건, 아직 완전히 갈아타라고 말할 단계가 아니라는 뜻이기도 하다.
실무팀이라면 지금 당장 전체 저장소를 옮길 이유는 없다. 다만 신규 프로젝트 한두 개를 Origin에서 시작해 PR 처리 속도나 협업 흐름이 기존 깃허브와 얼마나 다른지 비교해보는 정도는 지금도 가능하다. 규모가 큰 조직일수록 안정성 트랙레코드가 쌓이기 전까지는 핵심 저장소를 이동하는 결정을 서두를 필요가 없다.
앞으로 몇 주 안에는 예고된 '에이전트 네이티브' 기능이 구체적으로 드러날 가능성이 크다. 커서의 부모가 그록을 만드는 xAI와 스페이스X라는 점을 감안하면, Origin의 다음 단계는 그록을 활용한 자동 코드 리뷰나 PR 처리 같은 기능일 것으로 예상된다.
