커서가 대규모에서 Git의 한계를 우회한 방법

Cursor, AI 코드 에디터는 매우 큰 코드베이스에서 제대로 작동하기 위해 Git의 진정한 확장성 문제를 해결해야 했습니다. 그들이 한 일과 그 이유가 모든 시니어 개발자에게 흥미로운 이유입니다.

구체적인 사례

수백만 줄에 달하는 코드베이스(대형 테크 그룹, 성숙한 오픈소스 프로젝트, 빠르게 성장한 스타트업의 모노레포 등)를 상상해 보세요. Git이 버거워지기 시작합니다. git status가 몇 초나 걸리고, 일반적인 작업조차도 답답해집니다. 여기에 Cursor와 같은 AI 도구가 실시간으로 리포지토리의 상태를 이해하고 제안을 제공해야 한다면 문제는 더욱 심각해집니다.

바로 Cursor가 직면한 문제였으며, The Register는 Git의 확장성 한계를 어떻게 극복했는지 자세히 다룹니다.

근본적인 문제: Git은 AI용으로 설계되지 않았음

Git은 2005년 리누스 토르발스가 리눅스 커널을 관리하기 위해 설계했습니다. 대규모이지만 인간의 사용 패턴(개발자가 커밋, 브랜치, 머지하는 방식)에 맞춰져 있었죠. AI 도구가 매분 수십 또는 수백 번씩 리포지토리 상태를 읽어 실시간 제안을 제공해야 하는 상황은 고려되지 않았습니다.

주요 병목 현상은 다음과 같습니다:

• Git 인덱스: .git/index 파일은 단 하나의 파일만 수정되었더라도 매번 status 작업 시 전체를 다시 읽습니다.
• 오브젝트 저장소: 해시로 객체를 조회하는 방식은 대규모かつ반복적인 읽기 작업에 최적화되지 않았습니다.
• 파일 시스템 훅: Windows와 macOS에서는 파일 시스템 감시기가 지연을 추가합니다.

Cursor의 해결책: S3를 진실의 원천으로, NVMe 로컬을 지연 최적화에 활용

The Register에 공개된 Cursor의 접근 방식은 두 단계 아키텍처에 기반합니다. S3(클라우드 객체 저장소)를 리포지토리의 진실의 원천으로 사용하고, NVMe(고성능 SSD)에 로컬 리포지토리를 캐시하는 방식입니다.

구체적으로, AI가 Git의 확장성 한계로 직접 로컬 리포지토리에서 작업하는 대신, Cursor는 S3에 canonical(정식) 복사본을 유지하고, 지연이 민감한 작업에는 NVMe 로컬 캐시를 사용합니다. 두 저장소 간의 동기화는 Git 인덱스를 전체적으로 읽는 작업을 최소화하도록 최적화됩니다.

이는 시니어 개발자라면 누구나 잘 아는 문제입니다. 표준 추상화는 어느 순간까지는 통하지만, 그 한계를 넘어서면 하위 레벨로 내려가야 합니다. 여기서는 Git 호출을 미세 조정하는 것보다 저장 모델 자체를 재고하는 것이 필요했습니다.

왜 모두가 주목해야 하는가

Cursor의 해결책은 그들의 도구에만 국한되지 않습니다:

• 모노레포: 규모가 큰 모노레포에서 작업하는 모든 팀이 이 문제를 겪습니다. S3 + NVMe 로컬 아키텍처는 전이 가능합니다.
• Git LFS: 큰 바이너리 파일의 문제는 해결하지만, 인덱스 확장성은 해결하지 못합니다. 이는 아직 열린 문제로, Cursor는 다른 방식으로 우회했습니다.
• 코드베이스용 AI 도구: 정적 분석, 코드 리뷰 지원, 코드 생성 도구 등 모든 AI 도구가 성장하면서 이 문제를 마주하게 될 것입니다.