커서(Cursor) 공식 계정 @cursor_ai가 2026년 8월 19일 오전 1시 57분(KST), 자체 Git 호스팅 서비스 오리진(Origin)의 저장 구조를 공개했다. 원문은 "Git 호스팅을 더 안정적이고, 빠르고, 확장 가능하게 만들고 있다"며 "이 글은 20년치 Git 인프라 역사를 되짚어, 그 역사가 어떻게 우리를 오리진을 데이터베이스처럼 설계·운영하는 결정으로 이끌었는지 설명한다"고 밝혔다. 전체 설명은 커서 공식 블로그 "Git at any scale"에 실렸다.
Git 저장소를 왜 데이터베이스로 지었나
커서 공식 설명에 따르면 오리진의 핵심은 쓰기 로그(Write-Ahead Log, WAL)다. 모든 푸시(push)는 먼저 S3 호환 오브젝트 스토리지에 WAL 항목으로 기록되고, 완전히 저장된 뒤에만 완료로 인정된다. 서버의 빠른 NVMe 디스크에도 저장소 사본이 남지만, 이는 실제 Git 연산을 위한 재현 가능한 캐시일 뿐 근거 데이터가 아니다. 특정 서버에서 저장소가 사라지면 WAL 기록을 바탕으로 다른 서버에서 즉시 다시 만들어낸다. 어느 서버가 어느 저장소를 담당할지는 별도 데이터베이스 대신 렌데부 해싱(rendezvous hashing)으로 정하고, 라우팅이 순간적으로 틀려도 시스템은 실패 대신 다른 서버에서 저장소를 다시 만들어내는 방식으로 대응한다.
초당 22.6커밋, 무엇을 뜻하나
커서는 이 구조로 한 저장소 기준 초당 22.6커밋 처리량을 시연했다고 밝혔다. 사람이 직접 커밋하던 시절의 Git 호스팅은 애초에 이런 처리량을 염두에 두고 설계되지 않았다는 것이 커서의 주장이다. 오리진은 Git 프로토콜과 호환되며, API와 MCP(Model Context Protocol)로 확장할 수 있다. 다만 이 수치는 커서가 자체 공개한 시연 환경 기준이며, 독립 기관의 벤치마크로 검증된 값은 아니다. 오리진은 현재 Pro·Teams·Enterprise 유료 플랜에 얼리 베타로 순차 공개되는 단계이고, 정식 출시 일정은 별도로 공지되지 않았다.
발표 시점, 반응은 아직 엇갈린다
이번 발표는 GitHub이 대규모 장애를 겪은 시점과 맞물려 주목받았다. 크립토노미스트 보도에 따르면 오리진의 공개 시점은 GitHub 오류율이 치솟은 시기와 겹쳤다. 공식 게시물 답글에는 실무자의 실제 반응도 남았다. "GitHub과 뭐가 다른지", "2인 팀에 필요한지" 같은 질문이 이어졌고, 한 이용자는 "긴 글을 끝까지 읽는 사람이 몇이나 되겠냐"고 지적했다. 이런 반응은 익명 이용자 개인 의견으로 통계적 대표성은 없지만, 오리진이 아직 베타 단계이고 실무 도입 판단은 GitHub과의 실사용 비교 이후로 미루는 편이 안전하다는 점을 보여준다.



