커서가 깃허브 대항 저장소를 열었습니다 — 오리진 출시와 여덟 시간 장애가 겹친 날

SVIL - Singularity Visual Intelligence Lab 2026. 08. 19 17 min read

개발자가 코드를 맡겨 두는 곳은 오랫동안 한 곳이었습니다. 깃허브였지요. 그런데 2026년 8월 18일, 그 깃허브가 여덟 시간 가까이 멈춰 선 바로 그날, 커서가 같은 일을 하는 새 서비스를 열었습니다. 이름은 오리진(Origin)입니다.

어둠 속에 홀로 선 청록빛 문 — 새 코드 저장소가 열린 순간을 표현한 개념 이미지

깃허브가 멈춘 날, 경쟁자가 문을 열었습니다

우연이라기엔 시점이 너무 정확했습니다. 깃허브는 8월 17일 오후 1시 40분(UTC)부터 장애를 겪었고, 복구를 알린 것은 같은 날 오후 9시 15분이었습니다. 여덟 시간 남짓입니다. 그 사이 웹과 API의 오류율은 20퍼센트 안팎, 저장소 내려받기는 절반 가까이 실패했습니다.

커서는 그 시간대에 오리진의 초기 베타를 유료 사용자에게 열었습니다. 개발자들이 "깃허브가 안 되는데"라고 말하던 순간에, "여기 다른 곳이 있습니다"라고 답한 셈입니다.

오리진이 대체 무엇인가요

한 줄로 줄이면 코드 저장소 서비스입니다. 여러 사람이 같은 코드를 함께 고치고, 바뀐 부분을 검토해 합치고, 그 기록을 보관하는 일 — 지금까지 깃허브가 해 오던 그 일을 그대로 합니다.

다만 커서가 강조하는 지점이 조금 다릅니다. 사람이 손으로 코드를 쓰던 시절의 도구가 아니라, AI 에이전트가 코드를 쓰는 시대의 저장소를 표방합니다. 커서는 원래 AI 코드 편집기를 만드는 회사이니, 자기 편집기가 만들어 내는 코드를 담을 그릇까지 직접 만들겠다는 이야기입니다.

굵은 빛의 다리로 이어진 두 개의 청록빛 구체 — 두 저장소를 잇는 양방향 연결을 표현한 개념 이미지

8월 18일, 유료 사용자부터 순차 공개

오리진은 초기 베타로 나왔습니다. 커서의 프로·팀·엔터프라이즈 요금제 사용자에게 8월 18일 월요일부터 순차적으로 열렸습니다. 완성품이 아니라 "지금부터 써 보시라"는 단계입니다.

베타라는 말을 가볍게 보면 안 됩니다. 코드 저장소는 회사의 자산이 통째로 들어가는 곳이라, 보통은 안정성이 확인된 뒤에야 옮깁니다. 커서가 굳이 미완성 상태에서 문을 연 것은, 깃허브 장애가 만든 창이 오래 열려 있지 않을 것을 알았기 때문으로 보입니다.

스페이스X 인수 나흘 뒤에 나온 제품

배경을 하나 더 놓아야 그림이 보입니다. 커서를 만드는 애니스피어는 8월 14일 스페이스X에 인수 절차가 마무리됐습니다. 전액 주식 교환 방식이었고, 규모는 600억 달러로 알려졌습니다.

즉 오리진은 인수가 끝나고 나흘 만에 나온 첫 제품입니다. 개발이야 그전부터 하고 있었겠지만, 발표 시점이 새 주인 아래에서의 첫 행보가 됐다는 점은 기억해 둘 만합니다.

어둠 한가운데서 잘게 부서져 흩어지는 청록빛 띠 — 서비스 장애로 흩어진 작업 흐름을 표현한 개념 이미지

깃허브를 버리라는 제품이 아닙니다

많은 분이 오해하시는 지점입니다. 오리진은 "깃허브 계정을 지우고 넘어오라"는 제품이 아닙니다. 커서 스스로도 그렇게 말하지 않습니다.

오리진은 깃허브와 나란히 쓰도록 설계돼 있습니다. 기존 저장소를 그대로 두고, 코드를 양쪽으로 오가게 하는 구조입니다. 갈아타기가 아니라 겹쳐 쓰기입니다.

양방향 동기화가 핵심인 이유

이 구조가 왜 중요한가 하면, 옮기는 비용이 사실상 0에 가까워지기 때문입니다. 저장소를 통째로 이전하려면 협업자 계정, 자동화 설정, 배포 연결까지 전부 다시 손봐야 합니다. 회사일수록 엄두가 안 나지요.

그런데 양방향 동기화가 되면 "일단 오리진에서도 열어 두고 써 보다가, 좋으면 무게중심을 옮긴다"가 가능해집니다. 결정을 미룰 수 있게 만드는 것 — 그것이 후발주자가 쓸 수 있는 가장 강한 수입니다.

중심의 어두운 덩어리로 빨려 들어가는 가느다란 청록빛 궤적 — 인수로 흡수되는 회사를 표현한 개념 이미지

풀 리퀘스트를 그대로 주고받습니다

협업의 실무는 결국 풀 리퀘스트(변경 요청)에서 일어납니다. 누가 무엇을 고쳤고, 누가 검토했고, 어떤 논의를 거쳐 합쳐졌는지가 여기에 남습니다.

오리진은 풀 리퀘스트를 온전히 지원하고, 깃허브 쪽 풀 리퀘스트와도 양방향으로 이어집니다. 팀의 절반은 깃허브를, 절반은 오리진을 써도 같은 흐름 안에 있을 수 있다는 뜻입니다.

코드 검색과 브라우징

저장소 서비스의 절반은 "읽기"입니다. 남이 쓴 코드를 훑고, 함수 하나가 어디서 쓰이는지 찾아 들어가는 일 말이지요. 오리진도 코드 열람과 검색을 기본으로 제공합니다.

이 부분은 사실 차별점이라기보다 입장권에 가깝습니다. 여기가 부실하면 나머지 기능이 아무리 좋아도 쓰기가 어렵습니다.

같은 높이로 나란히 놓인 두 개의 청록빛 정육면체 — 두 서비스를 함께 쓰는 상태를 표현한 개념 이미지

Ask Cursor — 리뷰를 AI가 거듭니다

여기서부터 커서다운 기능이 나옵니다. Ask Cursor는 코드 검토 과정에 AI를 붙인 기능입니다. 바뀐 코드를 두고 질문을 던지면 그 자리에서 설명과 지적을 받는 방식입니다.

혼자 일하는 분에게는 이 기능의 의미가 특히 큽니다. 리뷰해 줄 동료가 없어서 검토 없이 그냥 합쳐 온 코드가, 최소한 한 번은 다른 눈을 거치게 되니까요.

그래파이트 인수가 여기서 쓰였습니다

오리진에는 스택드 풀 리퀘스트가 들어갑니다. 큰 변경을 한 덩어리로 올리지 않고, 작은 변경 여러 개를 층층이 쌓아 순서대로 검토받는 방식입니다.

이 기능은 커서가 인수한 그래파이트에서 왔습니다. 인수해 온 기술이 새 제품에 그대로 얹힌 셈이라, 오리진이 급조된 물건만은 아니라는 근거가 됩니다.

어둠을 가로지르는 두 줄기 평행한 청록빛 광선 — 양쪽으로 오가는 코드 동기화를 표현한 개념 이미지

자동 병합 충돌 해결

두 사람이 같은 줄을 서로 다르게 고치면 충돌이 납니다. 기계는 어느 쪽이 맞는지 모르니 사람에게 물어보지요. 협업에서 가장 성가신 순간입니다.

오리진은 이 충돌을 자동으로 풀어 주는 기능을 넣었습니다. 다만 이런 자동화는 "대개 맞지만 가끔 틀리는" 종류라, 결과를 확인하는 습관은 그대로 가져가시는 편이 안전합니다.

에이전트가 쓴 코드에 꼬리표를 붙입니다

개인적으로 가장 눈여겨본 기능입니다. 오리진은 AI 에이전트가 작성한 코드에 표시를 남깁니다. 어느 변경이 사람 손에서 나왔고 어느 변경이 에이전트에서 나왔는지가 기록으로 남는다는 뜻이지요.

지금은 사소해 보이지만, 코드의 절반 이상이 기계에서 나오는 시점이 되면 이 꼬리표가 사고 원인을 찾는 첫 단서가 됩니다. 책임 소재를 따지기 위해서가 아니라, 어디를 먼저 의심할지 정하기 위해서입니다.

하나로 꼬여 합쳐지는 두 가닥의 청록빛 흐름 — 변경 사항이 병합되는 과정을 표현한 개념 이미지

시간당 29만 6천 클론이라는 숫자

커서가 내놓은 성능 수치가 있습니다. 시간당 29만 6천 회 복제, 저장소 하나당 초당 22커밋입니다.

이 숫자는 사용자를 위한 것이라기보다 에이전트를 위한 것입니다. 사람은 하루에 저장소를 몇 번 복제하지 않지만, 에이전트를 수십 개 돌리면 이야기가 달라집니다. 커서가 어떤 사용 방식을 상정하고 있는지가 이 숫자에 드러납니다.

첫날 통합 3종 — 버셀·디팟·빌드카이트

저장소 혼자서는 아무것도 못 합니다. 코드가 올라가면 자동으로 검사가 돌고 배포가 되어야 쓸모가 있지요. 오리진은 출시 첫날부터 버셀·디팟·빌드카이트 세 곳과 연결됩니다.

버셀은 풀 리퀘스트마다 미리보기 배포를 자동으로 만들어 줍니다. 고친 결과를 합치기 전에 눈으로 확인할 수 있다는 뜻입니다.

아래로 좁아지며 입자를 훑어 내리는 청록빛 원뿔 — 코드 검색을 표현한 개념 이미지

깃허브 액션을 그대로 돌릴 수 있습니다

디팟과 빌드카이트는 기존 깃허브 액션 워크플로를 그대로 실행할 수 있습니다. 자동화 설정을 새로 짜지 않아도 된다는 이야기입니다.

앞서 말한 "옮기는 비용을 0으로 만드는 전략"이 여기서도 반복됩니다. 저장소도, 풀 리퀘스트도, 자동화도 다시 만들 필요가 없게 해 두는 것이지요.

에이전트 네이티브는 아직 오지 않았습니다

여기서 냉정해질 필요가 있습니다. 커서가 가장 크게 내세운 '에이전트 네이티브' 기능은 이번 출시에 들어 있지 않습니다. 문서에도 "곧 제공"이라고만 적혀 있습니다.

그러니까 지금 나온 오리진은, 기대작의 예고편에 가깝습니다. 깃허브와 다른 무언가가 아니라 깃허브와 비슷한 것이 먼저 나왔고, 진짜 차별점은 다음 차례로 미뤄져 있습니다.

커다란 청록빛 구체 표면에 맺힌 작은 밝은 점 — AI가 거드는 코드 검토를 표현한 개념 이미지

같은 날 깃허브는 여덟 시간 멈춰 있었습니다

다시 장애 이야기로 돌아가 보겠습니다. 이번 깃허브 장애는 일부 기능만 느려진 수준이 아니었습니다. API, 액션, 풀 리퀘스트, 이슈, 페이지, 웹훅, 그리고 코파일럿까지 함께 흔들렸습니다.

기업 사용자에게는 더 아팠습니다. SAML·OIDC 인증과 SCIM, 팀 동기화가 영향을 받아, 로그인 자체가 막힌 곳이 있었습니다. 개발 환경에 아예 못 들어가는 상황이 벌어진 겁니다.

오류율 20퍼센트, 다운로드는 50퍼센트

숫자로 보면 이렇습니다. 웹과 API 요청의 약 20퍼센트가 실패했고, 저장소 콘텐츠·압축 파일 내려받기는 약 50퍼센트가 실패했습니다.

50퍼센트라는 숫자가 특히 고약합니다. 완전히 죽으면 사람들은 기다리지만, 절반만 실패하면 계속 다시 시도하게 되고 그 재시도가 부하를 더 키웁니다. 겉으로는 "가끔 되는" 상태라 판단도 늦어집니다.

나선으로 층층이 쌓인 반투명 청록빛 고리들 — 층층이 쌓아 올린 변경 요청을 표현한 개념 이미지

1년에 257번, 장애가 일상이 된 이유

더 무거운 숫자는 따로 있습니다. 깃허브는 최근 1년 동안 257건의 장애를 기록했습니다. 7월 한 달만 놓고 봐도 성능 저하가 여러 차례 있었고, 8월 6일에도 한 번 있었습니다.

이쯤 되면 "운이 나빴다"로 설명이 안 됩니다. 구조적으로 감당이 안 되고 있다고 보는 편이 맞습니다.

AI 코딩이 트래픽을 몇 배로 늘렸습니다

원인으로 가장 자주 지목되는 것이 AI 코딩 도구가 만들어 내는 트래픽입니다. 사람이 하루에 몇 번 하던 일을, 에이전트는 분 단위로 합니다. 저장소를 읽고, 브랜치를 만들고, 검사를 돌리는 일이 몇 배로 늘었습니다.

얄궂은 대목은 여기입니다. 깃허브를 흔들고 있는 그 트래픽의 상당 부분이 커서 같은 도구에서 나온다는 점입니다. 부하를 만든 쪽이 그 부하를 못 견딘 자리에 들어서는 모양새가 됐습니다.

톱니처럼 맞물려 하나의 매끄러운 선이 되는 청록빛 곡선 — 충돌이 자동으로 풀리는 과정을 표현한 개념 이미지

데이터 약관이 비어 있다는 지적

칭찬만 하고 넘어갈 수는 없습니다. 출시 직후 데이터 관련 약관이 명확하지 않다는 지적이 나왔습니다. 올린 코드가 어떻게 취급되는지, 학습에 쓰이는지, 보관 기간은 어떻게 되는지 같은 항목 말이지요.

저장소 서비스에서 이 부분은 부가 조건이 아니라 본질입니다. 회사 코드를 맡기는 결정은 기능 비교가 아니라 약관에서 갈립니다.

스페이스X가 남의 코드를 보관한다는 뜻

여기에 인수 건이 겹칩니다. 오리진에 코드를 올린다는 것은, 실질적으로 스페이스X 소유 회사가 그 코드를 보관한다는 뜻이 됩니다.

회사에 따라 이건 그냥 넘어갈 사안이 아닙니다. 경쟁 관계에 있거나, 정부·방위 산업과 얽힌 조직이라면 더욱 그렇지요. 기술적 판단 이전에 거버넌스 판단이 필요한 대목입니다.

중심의 검은 구멍으로 빨려 드는 무수한 청록빛 입자 — 폭증한 트래픽을 표현한 개념 이미지

무료 요금제에는 없습니다

실무적인 확인 사항도 하나 있습니다. 오리진은 무료 요금제에서는 쓸 수 없습니다. 프로·팀·엔터프라이즈 사용자만 대상입니다.

깃허브가 무료 사용자에게도 사설 저장소를 열어 준 것과 대비됩니다. 개인 개발자 층을 넓게 가져가겠다는 전략은 아직 아닌 것으로 보입니다.

실제 사례 — 1인 개발자에게 무엇이 달라지나

저희처럼 혼자 여러 프로젝트를 돌리는 경우를 생각해 보겠습니다. 저장소가 열 개 남짓 있고, 코드의 상당 부분을 AI에게 맡기고, 자동 배포를 걸어 둔 환경 말이지요.

지금 당장 옮길 이유는 크지 않습니다. 에이전트 네이티브 기능이 아직 없으니, 오리진을 써도 얻는 것은 "장애가 덜하기를 바라는 마음" 정도입니다. 다만 깃허브 장애 때 작업이 통째로 멈추는 경험을 해 보셨다면, 중요한 저장소 한두 개만 양쪽에 동기화해 두는 것은 지금도 합리적인 선택입니다. 백업의 성격으로 말이지요.

반대로 회사 코드를 다루신다면, 기능을 보기 전에 약관과 데이터 취급 조항부터 확인하시길 권합니다. 순서를 바꾸면 되돌리기 어렵습니다.

어둠 속에서 가장자리만 청록빛으로 빛나는 닫힌 상자 — 남의 서버에 보관된 코드를 표현한 개념 이미지

핵심 정리

이번 소식을 다섯 줄로 줄이면 이렇습니다.

첫째, 커서가 8월 18일 코드 저장소 서비스 오리진을 유료 사용자 대상 초기 베타로 열었습니다. 둘째, 같은 날 깃허브는 약 여덟 시간 장애를 겪었고 오류율은 20퍼센트, 다운로드 실패는 50퍼센트에 달했습니다. 셋째, 오리진은 깃허브를 대체하는 대신 양방향 동기화로 나란히 쓰도록 설계됐습니다. 넷째, 가장 큰 무기인 '에이전트 네이티브' 기능은 아직 나오지 않았습니다. 다섯째, 데이터 약관이 불명확하고 모회사가 스페이스X라는 점은 도입 전에 따로 판단할 사안입니다.

참고하실 만한 것

SVIL 연구소는 AI 뉴스를 저시력 사용자도 편하게 읽을 수 있는 형태로 정리해 매일 올리고 있습니다. 큰 글자와 높은 대비, 그리고 짧은 문단이 기준입니다.

같은 내용을 영상으로도 만들고 있으니, 글로 읽기 힘드신 날에는 유튜브 채널에서 들으셔도 됩니다.

출처

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/