커서가 깃허브를 만들겠다고 나섰습니다: 코드 호스팅 판이 흔들리는 이유

개발자들이 코드를 올려두는 곳, 깃허브. 지난 15년 동안 이 자리는 사실상 무주공산이었습니다. 그런데 요즘 분위기가 좀 이상합니다. AI 코딩 도구로 급성장한 커서(Cursor)가 자체 코드 호스팅 서비스 Origin을 발표했고, 비슷한 시기 해커뉴스에는 “깃허브 요즘 무슨 일 있나요?“라는 질문 글이 올라왔습니다. 우연처럼 보이지만 두 사건은 뿌리가 같습니다.

먼저 한 가지 밝혀둘 게 있습니다. 이번 주제는 커뮤니티 데이터가 충분히 모이지 않았습니다. 최근 30일 기준으로 확인된 레딧 스레드가 없었고, X 데이터도 인증 문제로 수집하지 못했습니다. 그래서 개별 커뮤니티 반응을 인용하는 대신 업계 구조와 흐름을 중심으로 씁니다. 수치를 단정적으로 제시하지 않는 것도 같은 이유입니다.

왜 하필 AI 코딩 회사가 깃허브를 만드나

얼핏 이상합니다. 커서는 코드 에디터 회사입니다. 에디터 잘 만들면 되지, 왜 서버 비용 많이 드는 저장소 사업까지 손을 댈까요.

답은 에이전트에 있습니다. 지금의 AI 코딩은 이미 자동완성 단계를 넘어섰습니다. AI가 이슈를 읽고 브랜치를 파고 코드를 고쳐서 PR을 올립니다. 사람이 하던 워크플로를 그대로 밟습니다. 그리고 그 워크플로의 무대는 전부 깃허브 위에 있습니다.

문제는 깃허브가 사람을 위해 설계된 도구라는 점입니다. PR 화면은 사람이 눈으로 diff를 훑어보라고 만들어졌습니다. 코드 리뷰 코멘트는 사람이 타이핑하는 속도를 전제로 합니다. API 호출량 제한도 사람 한 명이 하루에 낼 만한 요청 수에 맞춰져 있고요.

에이전트가 열 개, 백 개씩 동시에 돌기 시작하면 이 전제가 다 깨집니다. 초당 수십 번씩 저장소를 읽고 브랜치를 수십 개씩 만들고 PR을 분 단위로 올립니다. 사람용 인프라에 기계 트래픽을 밀어넣는 셈입니다. 커서 입장에서는 자기 제품의 성능 한계를 남의 서버가 정하는 상황입니다. 직접 만들겠다는 결론이 나올 만합니다.

“깃허브 요즘 왜 이래?“라는 질문이 나온 시점

같은 시기 해커뉴스에 올라온 글은 훨씬 담백합니다. 요즘 깃허브가 자주 느리고 가끔 안 되고 예전 같지 않다는 체감을 공유하는 내용이었습니다.

이런 글은 원래 주기적으로 올라옵니다. 어느 서비스든 장애는 나니까요. 그런데 이번에는 맥락이 다릅니다. 마이크로소프트가 깃허브를 인수한 지 8년이 지났고, 그 사이 깃허브는 코파일럿을 중심으로 조직을 재편했습니다. 회사의 무게중심이 저장소 서비스에서 AI 제품으로 옮겨간 겁니다.

여기서 개발자들이 걱정하는 건 서버 다운 자체가 아닙니다. 기본기에 쏟는 관심이 줄어드는 것 아니냐는 의심입니다. 코드 호스팅은 화려한 기능보다 “언제 접속해도 된다"는 신뢰가 전부인 서비스입니다. 그 신뢰가 한번 흔들리면 그것만으로도 대안을 찾아 나설 이유가 됩니다.

플랫폼의 기술 인력이 다른 곳으로 옮겨간다는 이야기도 함께 돌았습니다. 이런 소문은 검증이 어렵습니다. 다만 커뮤니티가 그 소문을 진지하게 받아들인다는 사실 자체가 신호입니다. 튼튼하다고 믿는 회사를 두고는 이런 이야기가 잘 퍼지지 않거든요.

코드 호스팅은 원래 갈아타기 어렵습니다

반론도 짚고 갑시다. 깃허브가 흔들린다고 사람들이 바로 떠날까요? 쉽지 않습니다.

깃(Git) 자체는 분산 시스템입니다. 저장소를 통째로 복사해서 다른 서버에 올리면 끝입니다. 이론상 이사는 몇 분이면 됩니다. 그런데 실제로 발목을 잡는 건 저장소 바깥에 붙어 있는 것들입니다.

이슈 히스토리, PR 토론 기록, CI 설정, 배포 파이프라인, 외부 서비스 연동, 조직 권한 구조. 오픈소스 프로젝트라면 스타 수와 컨트리뷰터 네트워크까지. 이게 다 깃허브에 묶여 있습니다. 게다가 개발자 이력서에는 깃허브 프로필 주소가 들어갑니다. 채용 담당자가 열어보는 주소도 거기고요.

깃허브의 해자는 기술보다 사회적 인프라 쪽입니다. 커서가 이 벽을 정면으로 넘기는 어렵습니다. 그래서 전략이 갈립니다.

커서의 노림수는 정면승부가 아닐 겁니다

현실적인 시나리오는 이렇습니다. 커서가 노리는 건 모두가 깃허브를 버리게 만드는 일이 아닙니다. 에이전트가 일하는 작업 공간을 자기 영역으로 가져오는 쪽이죠.

AI가 코드를 짜는 중간 과정을 떠올려보세요. 수십 개의 시안 브랜치, 실패한 시도, 되돌린 커밋. 이런 건 최종 저장소에 남길 필요가 없습니다. 사람 팀원이 볼 필요도 없고요. 지저분한 중간 단계는 커서 안에서 처리하고 정리된 결과물만 기존 깃허브로 내보내는 구조가 자연스럽습니다.

이렇게 되면 개발자는 깃허브를 버리지 않으면서도 실제 작업 시간의 대부분을 커서 위에서 보내게 됩니다. 계정을 옮기라고 요구하지 않으니 저항도 적습니다. 그러다 어느 순간 깃허브가 결과물 보관소로만 남는 그림. 이쪽이 진짜 목표에 가까울 겁니다.

물론 리스크도 큽니다. 저장소 호스팅은 돈이 많이 드는 사업입니다. 스토리지 비용과 대역폭이 들고, 무엇보다 “데이터를 절대 잃어버리지 않는다"는 운영 능력이 필요합니다. 에디터를 잘 만드는 것과 24시간 인프라를 굴리는 건 완전히 다른 근육입니다. 커서가 이걸 해낼지는 지켜봐야 합니다. 코드는 회사 자산 중에서도 가장 민감한 축에 속하니까요.

진짜 변화는 “누가 개발자의 하루를 차지하나”

한 발 물러서서 보면 이 판은 깃허브 대 커서의 싸움으로 정리되지 않습니다. 개발 도구의 무게중심이 어디로 옮겨가느냐의 문제에 가깝습니다.

지난 10년간 개발자 도구 시장의 승자는 워크플로의 중심을 차지한 쪽이었습니다. 깃허브가 강했던 것도 코드를 저장해줘서가 아니라 코드 리뷰와 협업이 그 위에서 벌어졌기 때문입니다. 그런데 협업의 상대가 사람에서 AI로 바뀌는 중입니다. 리뷰어가 AI고 커밋 작성자도 AI라면, 그 무대를 굳이 사람용 플랫폼에 둘 이유가 약해집니다.

깃허브도 이걸 모를 리 없습니다. 코파일럿에 회사를 걸다시피 한 이유가 바로 그겁니다. 다만 그 과정에서 기존 서비스의 안정성이 흔들린다는 인상을 주면, 방어하려던 자리를 스스로 내주게 됩니다. 해커뉴스 글이 하필 지금 나온 게 뼈아픈 이유입니다.

마무리

당장 내일 깃허브에서 저장소를 옮길 필요는 없습니다. 15년치 사회적 인프라는 그렇게 쉽게 무너지지 않습니다. 다만 앞으로 1~2년, 개발자가 실제로 시간을 보내는 화면이 어디인지는 눈여겨볼 만합니다.

만약 여러분의 코드를 실제로 읽고 고치는 존재가 대부분 AI라면, 그 코드는 사람이 보기 편한 곳에 있어야 할까요, AI가 다루기 편한 곳에 있어야 할까요. 커서는 후자에 베팅했습니다.