8월 17일, 전 세계 개발자들이 깃허브에 접속하지 못했다. 장애는 7시간 47분 동안 이어졌다. github.com과 로그인, 액션, API, 풀 리퀘스트, 이슈, 코파일럿이 한꺼번에 흔들렸다. 웹과 API 요청은 다섯 건 중 한 건꼴로 실패했고, 저장소 압축 파일을 내려받는 요청은 절반 가까이 실패했다.
같은 날 커서(Cursor)는 코드 호스팅 서비스 오리진(Origin)을 열었다. 저장소를 보관하고 풀 리퀘스트를 주고받는, 그러니까 깃허브가 하던 일을 그대로 하는 서비스다. 커서 엔지니어 맷 파머는 벤처비트에 "원래 더 일찍 내놓으려 했는데 깃허브가 죽어 있었다"고 말했다. 노린 날짜가 아니라 오히려 장애 때문에 밀린 일정이었다는 뜻이다.
그런데 두 사건이 하루에 겹친 것은 우연이어도, 두 사건이 같은 주에 벌어질 확률은 애초에 높았다. 뿌리가 같기 때문이다. 코드를 찍어내는 손이 사람 손만이 아니게 되면서 저장소가 감당해야 하는 일의 양과 성격이 함께 바뀌었고, 한쪽은 그 무게에 눌려 멈췄으며 다른 쪽은 그 틈을 노려 문을 열었다.
오리진은 정확히 무엇인가
먼저 용어를 정리하자. 깃(Git)은 코드의 변경 이력을 관리하는 프로그램이고, 내 노트북 안에서도 잘 돌아간다. 깃허브는 그 깃 저장소를 인터넷에 올려두고 여러 사람이 같이 쓰게 해주는 서비스다. 저장 공간만 파는 게 아니라 풀 리퀘스트, 코드 리뷰, 이슈 추적, 자동 테스트 실행 같은 협업 절차를 통째로 얹어서 판다. 2025년 10월 기준 개발자 1억 8천만 명이 여기에 모여 있는 이유는 저장 공간이 아니라 그 절차 때문이다.
오리진은 그 자리를 노린다. 커서 데스크톱 앱에 코드베이스 탭이 하나 생기고, 거기서 저장소를 만들고, 코드를 훑어보고, 풀 리퀘스트를 열고 리뷰하고 병합한다. 버셀(Vercel)로 미리보기 배포를 걸고, 디팟(Depot)과 빌드카이트(Buildkite)로 테스트를 돌린다. 기존에 쓰던 깃허브 액션 워크플로 파일은 손대지 않고 그대로 돌아간다.
눈여겨볼 대목은 커서가 깃허브를 걷어내라고 말하지 않는다는 점이다. 오리진은 깃허브 저장소를 끌어와 거울처럼 비춰두고, 그 저장소의 진짜 주인 자리는 깃허브에 남겨둔다. 푸시는 여전히 깃허브로 가고, 권한 설정은 양쪽이 맞춰지며, 풀 리퀘스트에 남긴 댓글은 몇 초 안에 반대편에도 나타난다. 커서에서 단 코멘트가 깃허브에 뜨고, 깃허브에서 단 답글이 커서에 뜬다.
이건 전략이다. 깃허브를 떠나는 결정은 무겁다. 몇 년치 이슈와 리뷰 기록, CI 설정, 외부 서비스 연동이 전부 얽혀 있어서 옮기려면 팀 전체가 며칠을 쓴다. 오리진은 그 결정을 아예 요구하지 않는다. 일단 그대로 두고 여기서도 한번 써보라는 제안이다. 그러다 커서 쪽 화면이 손에 익으면 새 저장소부터 이쪽에 만들게 되고, 무게중심은 그렇게 조용히 넘어간다.
물론 아직 없는 것도 많다. 커서는 오리진의 요금을 공개하지 않았고, 오리진에 직접 만든 저장소를 나중에 다른 곳으로 옮기는 절차도 내놓지 않았다. 보안 구조에 대한 설명도 아직이다. 지금 나온 것은 얼리 베타 딱지가 붙은 기능 한 벌이고, 그걸 회사 코드에 붙일지 판단할 재료는 그다음 문제다. 이 공백이 나중에 어떤 모양의 문제로 돌아오는지는 글 뒤쪽에서 다시 다루겠다.
넉 달 만에 커밋이 두 배가 됐다
깃허브가 왜 멈췄는지는 회사가 직접 밝혔다. CTO 블라드 페도로프가 서명한 사후 보고서의 설명은 담백하다. 트래픽이 새로운 최고치를 찍었고, 미국 중부 데이터센터의 핵심 인프라 하나가 그 속도를 따라 확장되지 못했다. 그 압력이 인증 시스템으로 번지면서 여러 서비스가 연쇄로 무너졌다. 잘못 배포한 코드도, 설정 실수도 아니었다. 용량이 모자랐다.
같은 보고서에 실린 숫자가 진짜 이야기다. 깃허브의 월간 커밋 수는 올해 4월 14억 건에서 8월 29억 건이 됐다. 넉 달 만에 두 배가 넘었다. 월간 병합된 풀 리퀘스트는 약 1억 3천만 건, 새로 만들어지는 저장소는 월 2400만 개다.
"원래 그 정도로 크는 서비스 아닌가" 싶다면 1년 전 숫자와 견줘보면 된다. 깃허브가 지난해 옥토버스 보고서에서 밝힌 월간 병합 풀 리퀘스트는 4320만 건이었고, 그때도 전년 대비 23퍼센트 늘었다며 성장세를 자랑하던 수치다. 그게 지금 1억 3천만 건이다. 1년 사이 세 배가 됐다. 세상의 개발자 수가 1년 만에 세 배가 됐을 리는 없으니, 늘어난 건 사람이 아니라 사람 한 명이 만들어내는 변경의 개수다.
에이전트에게 일을 맡겨본 사람은 이 숫자가 왜 이렇게 튀는지 안다. 사람은 기능 하나를 붙들고 반나절 고민한 뒤 커밋 서너 개를 남긴다. 에이전트는 같은 반나절 동안 파일을 고치고 테스트를 돌리고 실패하면 되돌리기를 수십 번 반복하며, 그 과정을 전부 커밋으로 남긴다. 여러 작업을 병렬로 굴리면 그 수는 다시 몇 배가 된다. 사람 한 명 뒤에 일꾼 다섯이 붙으면 저장소가 받는 요청은 다섯 배에서 그치지 않는다.
페도로프는 앞서 리드데브와의 인터뷰에서 깃허브가 "지금 요구받는 규모를 감당하도록 설계된 플랫폼이 아니었다"고 인정했고, 앞으로는 현재의 30배 부하를 상정해 다시 설계해야 한다고 말했다. 겸손한 표현이 아니라 상황 판단이다. 넉 달마다 두 배씩 늘어나는 곡선을 그대로 연장하면 30배까지는 두 해가 걸리지 않는다.
문제는 이번 한 번이 아니었다는 데 있다. 리드데브 집계로 깃허브는 2025년 5월부터 2026년 4월까지 열두 달 동안 장애를 257건 겪었고, 그중 48건이 주요 장애로 분류됐다. 일주일에 한 번꼴로 크게 흔들린 셈이다. 가장 많이 무너진 건 자동 테스트와 배포를 담당하는 액션으로, 1년에 57번 멈췄다. 오리진이 나온 8월 17일 장애는 보름 사이 일곱 번째 사고였다.
떠난 프로젝트도 있다. 프로그래밍 언어 지그(Zig)는 액션이 계속 실패한다는 이유로 2025년 11월 코드버그로 옮겼고, 터미널 프로그램 고스티(Ghostty)를 만든 미첼 하시모토는 지난 4월 거의 매일 반복되는 장애 때문에 리뷰와 테스트가 몇 시간씩 막힌다며 깃허브를 떠나겠다고 밝혔다. 눈에 띄는 이탈이 쌓이면 남아 있는 사람들의 마음도 흔들린다.
대기줄이 대화에서 스케줄링으로 바뀔 때
여기까지는 안정성 이야기다. 안정성만 문제였다면 커서가 만들 물건은 덜 죽는 깃허브면 충분했다. 오리진이 내세우는 근거는 다른 데 있다.
벤처비트가 전한 숫자 하나가 그 근거를 압축한다. 커서 안에서 병합된 풀 리퀘스트의 35퍼센트를 클라우드 가상머신에서 자율로 돌아가는 에이전트가 열었다. 사람이 열어달라고 부탁한 게 아니라, 에이전트가 스스로 작업을 마치고 올린 것이다. 다만 이 값은 커서가 자사 플랫폼 안에서 잰 내부 수치이고, 외부 감사를 거친 통계가 아니다. 커서를 쓰는 팀이 다른 도구를 쓰는 팀보다 에이전트에 적극적일 테니 업계 평균보다 높게 나올 가능성도 있다. 그래도 방향을 읽는 데는 모자람이 없다. 어느 회사든 이 비율이 0에서 출발해 한쪽으로만 움직이고 있다는 사실은 같기 때문이다.
이 비율이 왜 중요한지는 풀 리퀘스트라는 물건의 성격을 보면 드러난다. 풀 리퀘스트는 원래 대화 장치다. 이렇게 고쳐봤는데 어떠냐고 묻고, 동료가 읽고, 여기 이 줄은 왜 이렇게 했느냐고 되묻고, 답하고, 합의가 되면 병합한다. 이 절차는 사람의 하루 리듬에 맞춰 설계됐다. 하루에 열 개쯤 올라오고, 각각 몇 시간에서 며칠에 걸쳐 익어간다.
병합되는 변경의 3분의 1을 소프트웨어가 만들면 이 리듬이 깨진다. 대기줄이 대화가 아니라 스케줄링 문제로 바뀐다. 밤사이 스무 개가 쌓여 있고, 서로 겹치는 파일을 건드리고, 어느 것을 먼저 병합하느냐에 따라 나머지가 충돌한다. 사람은 이 줄을 읽는 속도로만 소화할 수 있는데 줄은 기계 속도로 늘어난다. 코드를 쓰는 일이 병목이던 시절은 끝나고, 이제는 코드를 승인하는 일이 병목이다.
커서가 이 지점을 겨냥한 흔적은 인수 이력에 남아 있다. 커서는 2025년 12월 코드 리뷰 스타트업 그래파이트(Graphite)를 사들였다. 그래파이트가 잘하던 건 스택드 풀 리퀘스트, 그러니까 서로 의존하는 변경 여러 개를 한 줄로 세워놓고 순서대로 검토하고 병합하는 방식이다. 큰 변경 하나를 통째로 던지는 대신 작은 조각으로 쪼개 쌓아 올리면, 앞 조각이 병합되기를 기다리지 않고 뒤 조각을 계속 만들 수 있다. 사람에게도 유용한 기법이지만, 조각을 쉴 새 없이 찍어내는 에이전트와는 훨씬 잘 맞는다. 6월 커서의 첫 자체 컨퍼런스 무대에서 오리진을 처음 보여준 사람도, 지금 개발을 이끄는 사람도 그래파이트 공동창업자 토마스 라이머스다.
오리진의 클라우드 에이전트가 하는 일을 보면 설계 의도가 더 분명해진다. 이 에이전트는 자기가 연 풀 리퀘스트를 자동으로 구독한다. 테스트가 돌아가는 걸 지켜보다가 실패하면 고치고, 리뷰 코멘트가 달리면 반영하고, 풀 리퀘스트에 변화가 생기면 깨어나서 다시 일한다. 사람이 다시 불러주기를 기다리지 않고 목표가 실제로 달성될 때까지 붙어 있는다. 코드를 만드는 곳과 코드를 보관하는 곳이 갈라져 있으면 이런 동작을 붙이기가 까다롭다. 커서가 저장소까지 직접 들고 있으려는 이유가 여기 있다.
깃허브는 이미 한 발 물러서 있었다
물러섰다는 건 손을 놨다는 뜻이 아니라 싸울 자리를 골랐다는 뜻이다. 2025년 10월 깃허브는 에이전트 HQ를 발표하면서 앤트로픽, 오픈AI, 구글, 코그니션, xAI의 에이전트를 깃허브 안에서 골라 쓰게 하겠다고 밝혔다. 자기 에이전트만 밀지 않고 경쟁사 것을 나란히 얹겠다는 결정이다. 코파일럿 유료 구독에 별도 요금 없이 포함되고, 여러 에이전트에게 일을 배정하고 진행을 지켜보는 관제탑과 접근 권한, 감사 로그, 샌드박스 실행 같은 통제 장치가 함께 붙는다.
전략은 명확하다. 가장 똑똑한 에이전트를 우리가 만들겠다는 싸움에서는 빠지고, 어느 회사 에이전트를 쓰든 그 밑에 깔린 땅은 우리 것이라는 위치를 지키겠다는 것이다. 개발자 대부분이 이미 올라와 있는 땅이니 나쁘지 않은 계산이다.
커서는 정확히 그 계산을 겨눈다. 에이전트를 조율하는 층을 내주더라도 저장소를 쥐고 있으면 안전하다는 게 깃허브의 전제인데, 오리진은 그 저장소 자체를 가져가겠다고 나선 첫 번째 진지한 시도다. 그것도 이미 코드를 쓰고 있는 편집기 안에서, 사용자가 새로 뭔가를 설치하거나 옮길 필요 없이. 하필 그 시도가 시작된 날 깃허브가 여덟 시간 가까이 멈춰 있었다는 사실은 커서가 돈으로 살 수 없는 종류의 홍보였다.
약관이 없는 서비스에 코드가 들어간다
여기서 잠깐 흥분을 가라앉힐 필요가 있다.
커서는 오리진을 유료 플랜 사용자 전원에게 얼리 베타로 열었다. 프로, 팀즈, 엔터프라이즈가 모두 대상이고, 조건은 엔터프라이즈 조직의 관리자가 빼달라고 하지 않는 한이다. 기본값이 켜짐이고 원하지 않으면 꺼야 한다. 회사 코드를 새로운 호스트에 비춰 둘지 말지를 아직 논의해본 적 없는 조직이라면, 논의하지 않은 채로 결정이 내려진 셈이다.
그런데 정작 그 결정에 필요한 문서가 나와 있지 않다. 오리진에 직접 올린 저장소를 두고 데이터를 얼마나 보관하는지, 어느 나라 서버에 두는지, 모델 학습에 쓰는지 안 쓰는지, 어떤 외부 업체를 거치는지가 공개되지 않았다. 코드를 맡길지 판단하는 데 필요한 항목이 통째로 비어 있는 상태에서 기능만 먼저 켜졌다.
배경도 가볍지 않다. 스페이스X는 6월 16일 커서의 모회사 앤이스피어를 600억 달러 전액 주식으로 인수하기로 합의했고, 오리진이 나오기 며칠 전 거래를 마무리했다. 스타트업 인수 금액으로는 역대 최대다. 이제 유료 사용자의 코드가 기본값으로 비춰지는 곳은 스페이스X 자회사의 서버다.
여기에 하나 더 얹어둘 이야기가 있다. 오리진과는 별개 사안이지만 같이 봐둘 만하다. 지난 7월 보안업체 마인드가드는 윈도우 프로젝트 폴더에 악의적인 git.exe를 심어두면 커서 편집기가 별도 확인 없이 그걸 실행한다는 취약점을 공개했다. 커서는 이를 수정하지 않겠다고 답했고 CVE 번호도 붙지 않았다. 오리진의 보안 문제가 아니라 편집기의 문제이니 둘을 섞어 읽으면 안 된다. 다만 코드 보관까지 맡아달라고 하는 회사가 자기 제품의 보안 지적을 어떻게 처리하는지 보여주는 사례로는 읽어둘 값이 있다.
도구를 고르는 일과 코드를 두는 일이 하나가 됐다
이번 일이 국내 조직에 남기는 건 깃허브에서 옮겨야 하느냐는 질문이 아니다. 오리진은 얼리 베타고, 요금표도 약관도 없고, 회사 코드를 실어 나를 만큼 무르익지 않았다.
달라진 건 코딩 도구를 고르는 일과 코드를 어디에 둘지 정하는 일이 하나로 붙어버렸다는 사실이다. 지난주까지 이 둘은 별개였다. 편집기는 취향이고 저장소는 인프라였으며, 편집기를 바꿔도 코드가 놓인 자리는 그대로였다. 오리진은 그 구분을 지운다. 편집기 하나를 유료로 쓰기 시작하면 저장소가 딸려 오고, 그것도 기본값으로 켜진 채 온다.
그래서 지금 확인할 것은 하나다. 조직에서 커서 유료 플랜을 쓰고 있다면 오리진이 켜져 있는지, 어떤 저장소가 비춰지고 있는지 들여다보는 일이다. 엔터프라이즈 조직은 관리자가 뺄 수 있지만, 프로나 팀즈 요금제를 개인이나 소규모 팀이 각자 결제해 쓰는 형태라면 그 스위치를 관리할 사람이 아예 없다. 국내에서 커서를 쓰는 팀 상당수가 이 형태다.
2주 전 메타가 코드를 학습 데이터로 내주면 값을 깎아주겠다고 했을 때는 저울이 눈에 보였다. 값과 데이터가 양쪽에 놓였고 고르는 건 사람이었다. 이번에는 저울 자체가 없다. 무엇을 내주는지 적힌 문서가 나오지 않은 채로 스위치가 켜졌기 때문이다. 그러니 오리진을 평가할 첫 잣대는 기능 목록이 아니다. 커서가 요금과 데이터 조건과 이전 절차를 언제, 얼마나 구체적으로 내놓느냐다. 저장소를 맡아달라는 회사가 그 세 가지를 미룬 채 스위치부터 켰다는 사실은, 그 자체로 이미 하나의 답이다.