GitHub is breaking. 2026년 6월, 이 문장은 더 이상 과장이 아니다.
Cursor가 샌프란시스코 자체 컨퍼런스에서 'Origin'을 발표했다. Git 호환 코드 호스팅 플랫폼인데, AI 에이전트가 코드의 주체가 되는 세계를 전제로 밑바닥부터 다시 설계했다. 같은 주에 GitLab은 'Project Switch' 비공개 베타를 열었고, Zed의 Nathan Sobo는 DeltaDB의 세부 사항을 공개했다. 세 곳 모두 같은 진단에서 출발한다. GitHub이 에이전트 시대의 무게를 버티지 못하고 있다.
에이전트가 만들어내는 1,700만 개의 풀 리퀘스트
GitHub은 지난 12개월간 수백 건의 인시던트를 기록했다. 현재 월 14억 커밋을 처리하고 있고, 에이전트만 매월 1,700만 개의 풀 리퀘스트를 만들어낸다. 2021년 Copilot으로 AI 코딩 시대를 열어젖힌 GitHub이 정작 그 시대의 트래픽을 감당하지 못하고 있다.
Brian Douglas, GitHub의 전 개발자 옹호 디렉터는 말한다. "에이전트가 오픈소스를 할 의지를 빠르게 죽이고 있다." 그는 자신도 이제 GitHub에서 코드 리뷰와 PR 작업을 Claude와 Codex에서 직접 한다고 말한다. GitHub 파워 유저가 GitHub을 덜 쓴다는 진술.
문제의 핵심은 단순한 서버 용량이 아니다. PR 모델이 전제하는 세계, 인간이 한 줄 한 줄 코드를 쓰고 다른 인간이 그걸 리뷰하는 세계가 끝나고 있다. 에이전트가 몇 초 만에 수천 줄을 만들어내는 시대에, PR은 품질 게이트가 아니라 형식적인 체크박스가 된다. Pull Request는 2008년 GitHub이 도입한 이후 18년간 개발 협업의 기본 단위였다. 그 단위가 균열이 가기 시작했다.
검증의 단위가 줄에서 의미로 바뀌고 있다
내가 에이전트로 코드를 작성하면서 가장 먼저 부딪힌 건 "검증"이었다. 코드를 100% 에이전트에 맡기게 되니, 내가 말한 알고리즘이나 계산식이 맞게 들어갔는지 확인하고 싶었다. 줄 단위 diff를 읽는 것으로는 그걸 알 수 없었다. 그래서 따로 마크다운 파일로 로직을 정리해달라고 한 적이 있다. 에이전트가 어떤 알고리즘을 적용했는지, 계산식이 정확한지, 문서로 뽑아서 검증해야 했다.
기존 GitHub 워크플로우에서 diff는 줄 단위로 무엇이 바뀌었는지 보여준다. 하지만 에이전트가 코드를 쓸 때 내가 확인하고 싶은 건 "무엇이 바뀌었는가"가 아니라 "의도한 로직이 맞게 들어갔는가"다. 이건 근본적으로 다른 질문이다. 줄 단위 diff는 이 질문에 답하지 못한다. 의도 단위 검증이 필요한데, 그걸 지원하는 도구가 없으니 결국 수작업으로 마크다운을 뽑아서 읽는다. swyx가 Origin을 설명하면서 "의미 단위 diff"를 언급한 것도 같은 맥락이다. 검증의 단위가 줄에서 의미로, 커밋에서 세션으로 바뀌고 있다. 이건 도구의 문제가 아니라 일하는 방식 자체의 전환이다.
세 가지 접근 — Origin, Project Switch, DeltaDB
Cursor의 Origin은 Git 호환성을 유지하면서 에이전트 워크로드에 최적화된 아키텍처를 약속한다. 올가을 출시 예정이며, MCP 지원과 빌트인 머지 컨플릭트 해결, CI 실패 시 에이전트 자동 해결을 포함한다. Cursor가 지난 12월 Graphite를 인수하면서 속도가 붙었다. Graphite는 Shopify, Snowflake, Notion, Figma가 쓰는 코드 리뷰 도구였다. Graphite가 이미 GitHub이 따라잡지 못한 워크플로우를 만들고 있었고, 그 뒤에 SpaceX의 자본이 붙었다.
GitLab의 Project Switch는 더 보수적이다. Git 프로토콜은 그대로 두되 백엔드를 전면 재설계했다. 에이전트가 리포지토리 전체를 클론하지 않고 서버 사이드에서 쿼리할 수 있게 했다. 태스크 실행이 최대 50배 빠르고, 토큰 소비는 1/3. Anthropic이 디자인 파트너로 참여 중이다.
Zed의 DeltaDB가 가장 급진적이다. Git의 커밋 모델 자체를 버린다. 대신 에이밍할 때 에이전트가 수행하는 모든 연산을 미세 단위 delta의 연속 스트림으로 저장하고, 각 delta를 그것을 만들어낸 대화와 직접 연결한다. 코드 변경의 맥락이 보존된다. 베타는 몇 주 안에 나온다고 한다.
세 접근의 스펙트럼은 명확하다. Git 호환 + 에이전트 최적화(Origin), Git 유지 + 백엔드 혁신(Project Switch), Git 교체(DeltaDB). 공통점은 현재의 GitHub으로는 안 된다는 합의다.
네트워크 효과와 거대 자본의 벽
기술적 우위만으로 GitHub을 대체할 수 있을까. 대안은 될 수 있다. Origin이 에이전트에게 더 빠르고, Project Switch가 더 효율적이라 해도, GitHub의 진짜 해자는 기술이 아니다. 수억 개의 리포지토리, 1억 명 이상의 개발자, 그 위에 쌓인 소셜 그래프. Stack Overflow가 GitHub 로그인에 의존하고, 모든 오픈소스 프로젝트가 GitHub URL을 정준으로 삼는다.
다만 GitHub의 데이터베이스와 Microsoft라는 거대 기업의 자본 앞에서, 새로운 플랫폼이 과연 네트워크 효과를 뚫을 수 있을지는 미지수다. Cursor에 600억 달러를 쓴 SpaceX의 힘도 무시할 수 없고, GitLab은 엔터프라이즈 시장에서 자리잡았다. 하지만 GitHub이 쌓아온 데이터베이스 — 전 세계 코드와 커밋 히스토리의 축적 — 를 옮기는 건 새 도구를 만드는 것보다 훨씬 어렵다.
더 큰 문제가 하나 있다. Cursor 자체의 입지도 흔들리고 있다. Cursor 사용자들이 이미 Claude CLI와 Codex CLI로 대거 이탈하고 있기 때문이다. Cursor가 에이전트 시대의 인프라를 지향하며 Origin을 내놓았지만, 정작 Cursor를 쓰던 개발자들이 더 범용적인 CLI 도구로 옮겨가고 있다. IDE 기반 에이전트가 아니라 터미널에서 직접 동작하는 에이전트가 주류가 되면, Origin이 아무리 잘 만들어져도 그 위에서 도는 코드의 주체가 Cursor일 필요가 없다. 전환점은 Origin이 만드는 게 아니라 이미 CLI 에이전트로 이동한 사용자들이 만들고 있다.
HashiCorp 공동 창립자 Mitchell Hashimoto가 작년에 쓴 것이 있다. "AI 기업들이 GitHub보다 더 빨리 GitHub이 되어가고 있다." 그는 Origin 발표 때 자신의 글을 리트윗하며 한 줄을 덧붙였다. "Cursor가 Origin을 발표했다. 더 올 것이다."
에이전트 시대의 코드 리뷰
Cursor가 자체 코딩 모델 Composer 2.5를 출시한 건 우연이 아니다. OpenAI API 키 하나 넣어서 성장하는 시대는 끝났다. Douglas가 "모델을 소유해야 이긴다"고 말한 것처럼, 모델을 가진 자가 인프라를 가지고 인프라를 가진 자가 협업의 표준을 정한다. Composer 2.5는 Claude Opus와 동급 성능에 출력 토큰 비용이 1/10이다. 자체 모델이 있어야 스택 전체를 컨트롤할 수 있다.
에이전트로 코드를 작성하면서 로직을 마크다운으로 분리해 검증했던 건, 앞으로 더 많은 개발자가 겪을 일의 축소판이다. 에이전트가 만든 코드를 인간이 어떻게 신뢰할 것인가. 줄 단위 리뷰로는 답이 안 나온다. 의미 단위 검증, 세션 단위 추적, 토큰 단위 비용 측정. 새로운 도구가 새로운 단위를 만들고, 새로운 단위가 새로운 워크플로우를 요구한다.
Douglas는 "토큰이 커밋보다 나은 지표"라고 말한다. 커밋과 PR이 GitHub 세계에서 통용되는 화폐라면, 토큰과 에이전트 세션은 새로운 경제의 단위다. 두 경제가 공존하는 교차점에서, 누가 살아남을까. GitHub이 스스로 적응할까, 아니면 2008년의 PR처럼 2026년의 Origin이 새로운 표준이 될까. 코드를 읽는 단위가 바뀔 때, 코드를 호스팅하는 곳도 바뀐다. 그 전환점이 지금 벌어지고 있다.