커서 오리진은 어떻게 깃허브의 대항마가 되려 하나

커서가 코드 호스팅 플랫폼 **오리진(Origin)**을 선보인 시점은 공교롭게도 깃허브의 신뢰성 문제가 다시 부각된 때였습니다. 오리진 출시 직후 깃허브에서는 전 세계적인 서비스 저하가 발생했고, 장애는 6시간 42분 동안 이어졌습니다. 풀 리퀘스트, 이슈, API의 오류율은 약 20%에 달했으며, 아카이브와 원시 파일 다운로드에서는 오류율이 약 50%까지 치솟은 것으로 집계됐습니다. 6

커서의 전략은 단순히 “깃허브를 떠나라”고 요구하는 방식과는 다릅니다. 기존 저장소와 개발 습관을 유지한 채, 커서가 강점을 가진 AI 중심 개발 환경을 시험해 보도록 하는 데 초점이 맞춰져 있습니다. 23

오리진이 제공하는 깃허브식 핵심 기능

오리진은 개발자들이 코드 호스팅 플랫폼에서 주로 사용하는 기본 업무를 지원하도록 설계됐습니다.

• 코드 저장소에 코드 보관
• 하나의 코드베이스를 여러 개발자가 함께 작업
• 코드 탐색과 편집
• 메인 코드베이스에 반영할 변경 사항을 제안하는 풀 리퀘스트 관리 23

이 기능 구성은 개발자에게 익숙한 출발점을 제공합니다. 팀은 저장소를 구성하고 변경 사항을 검토하는 방식 자체를 처음부터 다시 배울 필요 없이, 커서가 제안하는 AI 기반 워크플로를 평가할 수 있습니다.

커서는 오리진에 향후 ‘에이전트 네이티브(agent-native)’ 기능을 추가하겠다고 밝혔습니다. 다만 현재 공개된 보도만으로는 이 기능이 구체적으로 무엇을 수행하는지, 기존 AI 코딩 지원과 어떻게 다른지는 충분히 알려지지 않았습니다. 커서는 오리진을 중심으로 더 폭넓은 애플리케이션 생태계도 구축하겠다고 설명했습니다. 장기적으로는 저장소와 풀 리퀘스트를 넘어 더 다양한 개발 업무를 지원할 가능성을 열어둔 셈입니다. 28

핵심은 ‘깃허브와 함께 쓰기’다

오리진의 가장 현실적인 도입 전략은 **상호운용성(interoperability)**입니다. 개발자는 깃허브 조직을 연결한 뒤, 커서와 동기화할 저장소를 선택할 수 있습니다. 그러면 깃허브에 있는 저장소와 오리진에서 만든 저장소를 한 화면에서 나란히 확인할 수 있습니다. 36

이 방식은 새로운 서비스를 시험하는 데 드는 비용을 낮춥니다. 팀이 기존의 대표 저장소를 즉시 옮기거나, 권한 설정과 자동화 도구, 업무 프로세스를 한꺼번에 바꾸지 않고도 오리진의 코드 리뷰와 AI 중심 작업 방식을 경험할 수 있기 때문입니다. 관련 보도에 따르면 초기 설정에서는 깃허브가 기준 데이터의 원천으로 계속 기능하고, 저장소 활동과 풀 리퀘스트 논의가 두 서비스 사이에서 동기화됩니다. 616

이는 깃허브의 거대한 기존 사용자 기반을 오리진의 잠재적인 유통 경로로 바꾸는 전략이기도 합니다. 대규모 이전을 감수할 팀만을 상대로 경쟁하는 대신, 깃허브 생태계에 의존하면서도 새로운 개발 방식을 원하는 개발자에게 먼저 접근할 수 있습니다.

깃허브의 장애가 경쟁의 틈을 만들었다

오리진 출시 시점은 경쟁 구도를 더욱 선명하게 만들었습니다. 깃허브의 글로벌 서비스 저하 당시 풀 리퀘스트, 이슈, API의 오류율은 약 20%에 이르렀고, 아카이브 및 원시 파일 다운로드 오류율은 약 50%로 보고됐습니다. 이는 깃허브의 장애 기록을 바탕으로 한 보도 내용입니다. 610

또 다른 보도는 LeadDev의 분석을 인용해, 깃허브가 지난 1년 동안 257건의 장애를 기록했으며 이 가운데 48건은 주요 장애로 분류됐다고 전했습니다. 1013

코드 호스팅과 코드 리뷰, 개발 도구를 핵심 인프라로 여기는 팀이라면 반복되는 서비스 중단은 대안을 검토하게 만드는 요인이 될 수 있습니다. 오리진은 바로 이 불만을 AI 기반 개발 경험으로 연결하려는 것입니다.

다만 유명 깃허브 사용자의 대규모 **‘엑소더스’**가 이미 진행 중이라는 주장은 신중하게 볼 필요가 있습니다. 현재 공개된 보도에서 이 표현은 논평이나 주장으로 제시됐을 뿐, 실제 이전 규모를 수치로 입증한 독립적인 자료로 확인되지는 않습니다. 현재 근거가 보여주는 것은 경쟁 서비스가 파고들 수 있는 신뢰성 문제이지, 깃허브를 떠난 개발자나 조직의 정확한 수가 아닙니다. 9

그래도 깃허브를 대체하기 어려운 이유

장애와 성능 불만만으로 깃허브의 우위를 단숨에 무너뜨리기는 어렵습니다. 깃허브는 오랫동안 소프트웨어 개발의 기본 플랫폼으로 자리 잡았고, 저장소와 오픈소스 프로젝트, 각종 연동 도구, 기업용 업무 체계, 개발자들의 사용 경험이 촘촘하게 연결돼 있습니다. 3

마이크로소프트가 깃허브를 소유하고 있다는 점도 강점입니다. 기업용 도구와 AI 제품을 비롯한 인접 서비스와 연결할 수 있는 자원과 기반이 있기 때문입니다. 보도에 따르면 깃허브의 개발자 기반은 약 1억 8,000만 명에 달합니다. 316

따라서 완전한 이전은 저장소 파일을 복사하는 것만으로 끝나지 않습니다. 권한 체계, 자동화와 CI/CD 연동, 보안·컴플라이언스 절차, 외부 서비스 통합, 협업 방식까지 다시 설계해야 할 수 있습니다. 오리진의 인터페이스나 향후 에이전트 기능이 매력적이더라도, 팀 전체가 플랫폼을 바꾸기에는 여전히 높은 전환 비용이 남아 있습니다.

당장의 승부처는 플랫폼 교체보다 개발 워크플로

이런 점을 종합하면 오리진의 출시는 깃허브에서 하룻밤 사이 대규모 이탈을 일으키겠다는 승부수라기보다, 소프트웨어 개발의 다음 단계를 선점하려는 시도에 가깝습니다. 커서는 깃허브의 신뢰성 논란으로 주목을 끌고, 동기화 기능으로 기존 플랫폼과의 연결을 유지하면서 AI 보조 코딩과 코드 리뷰, 에이전트 기반 작업을 새로운 선택지로 제시합니다.

남은 과제는 낮은 진입 장벽을 실제 플랫폼 정착으로 전환하는 일입니다. 오리진은 이미 개발자들이 깃허브에서 기대하는 기본 워크플로를 재현하고 있지만, 장기적인 차별화는 아직 구체적인 내용이 공개되지 않은 에이전트 네이티브 기능과 애플리케이션 생태계가 얼마나 실용적인지에 달려 있습니다. 28

현재 커서의 메시지는 분명합니다. 당장 옮길 필요는 없게 만들고, 쉽게 시험하게 하며, AI 네이티브 개발을 두 번째 코드 호스팅 플랫폼을 써야 할 이유로 제시하는 것입니다. 오리진이 깃허브를 완전히 대체할지는 아직 알 수 없지만, 개발자가 플랫폼을 선택하는 기준을 저장소 보관에서 AI 중심 워크플로로 넓히는 데는 이미 성공한 셈입니다.