Cursor가 ripgrep을 1,300배 이긴 비결, GitHub Code Search의 로컬 부활

ripgrep으로 Chromium 코드베이스를 정규식 검색하면 16.8초가 걸립니다. Cursor의 새로운 Instant Grep은 같은 검색을 13ms에 끝냅니다. 1,300배 차이입니다. 이 기술을 만든 사람은 GitHub Code Search의 핵심 엔지니어 Vicent Marti입니다. 그가 GitHub에서 수억 개 리포지토리를 검색하던 기술을 가져와서, 이번에는 개발자의 로컬 머신에 심었습니다. AI 코딩 에이전트가 코드를 탐색하는 방식이 근본적으로 달라지려 하고 있습니다.

에이전트의 숨겨진 병목, 코드 검색

AI 코딩 에이전트는 코드를 "잘 쓰는 것"만큼이나 "잘 찾는 것"이 중요합니다. Claude Code, Cursor, Copilot 같은 에이전트가 대형 코드베이스에서 작업할 때, 관련 파일을 찾고, 함수 정의를 추적하고, 패턴을 파악하는 과정에서 grep을 반복적으로 호출합니다. Marti의 표현을 빌리면 이렇습니다.

"에이전트는 grep을 정말 사랑합니다."

(원문: "Agents just love to use grep.")

문제는 grep의 지연 시간이 코드베이스 크기에 비례한다는 점입니다. 소규모 프로젝트에서는 ripgrep이 충분히 빠릅니다. 하지만 수십만 개의 파일을 가진 모노레포에서는 한 번의 검색에 10초 이상이 걸립니다. 에이전트가 한 작업에서 grep을 10번, 20번 호출한다면? 검색만으로 수 분이 사라집니다. Cursor 팀은 이를 "에이전트 연산 중 지연 시간이 코드베이스 크기에 따라 스케일하는 몇 안 되는 작업"이라고 설명합니다.

이 병목은 단순한 속도 문제가 아닙니다. 검색이 느리면 에이전트는 탐색적 검색을 포기합니다. "혹시 관련된 코드가 있을까?" 하고 넓게 찾아보는 대신, 이미 아는 경로만 직접 참조하게 됩니다. 코드베이스에 대한 이해가 얕아지고, 결과적으로 생성하는 코드의 품질이 떨어집니다. 검색 속도가 에이전트의 지능을 제한하는 셈입니다.

Vicent Marti, GitHub에서 Cursor까지

이 문제를 해결하기 위해 Cursor가 데려온 인물이 Vicent Marti입니다. 그의 이력은 코드 검색의 역사 자체와 겹칩니다.

Marti는 GitHub에서 Blackbird라는 코드 검색 엔진을 만든 핵심 엔지니어였습니다. 2023년 정식 출시된 GitHub Code Search는 GitHub에 호스팅된 수억 개 리포지토리를 밀리초 단위로 검색할 수 있게 한 서비스입니다. 이 서비스의 핵심에 Marti의 sparse n-gram 인덱싱 기술이 있었습니다.

코드 검색 기술은 30년이 넘는 역사를 갖고 있습니다. 1993년 Glimpse의 trigram 인덱스, 2012년 Google Code Search(Zoekt), 2016년 Sourcegraph를 거쳐 2023년 GitHub Blackbird에 이르렀습니다. 이 기술들은 모두 서버사이드에서 동작했습니다. 대규모 인프라 위에서 인덱스를 구축하고 쿼리를 처리하는 방식이었습니다.

Marti는 GitHub 이후 PlanetScale을 거쳐 Cursor에 합류했습니다. 그리고 서버에서 검증된 기술을 개발자의 로컬 머신에 가져왔습니다. 이것이 기술적으로 왜 흥미로운지는, sparse n-gram의 작동 원리를 이해하면 명확해집니다.

sparse n-gram은 어떻게 1,300배를 만드는가

ripgrep이 느린 이유부터 짚어보겠습니다. ripgrep은 인덱스 없이 파일을 하나씩 열어서 읽고, 정규식 패턴과 대조합니다. Chromium 수준의 코드베이스에서는 수십만 개 파일의 수 GB 텍스트를 매번 처음부터 스캔해야 합니다. 아무리 ripgrep이 최적화되어 있어도, 물리적 I/O의 한계를 넘을 수는 없습니다.

Instant Grep은 접근이 다릅니다. 코드베이스 전체를 미리 분석해서 인덱스를 만들어 둡니다. 검색할 때는 이 인덱스만 참조하면 되니, 전체 파일을 스캔할 필요가 없습니다. 데이터베이스의 B-tree 인덱스가 테이블 풀 스캔을 피하는 것과 같은 원리입니다.

핵심은 "어떤" 인덱스를 쓰느냐입니다. 전통적인 trigram 인덱스는 텍스트를 3글자 단위로 잘라서 저장합니다. function이라는 단어는 fun, unc, nct, cti, tio, ion으로 분해됩니다. 검색 시 쿼리도 같은 방식으로 분해해서, 모든 trigram이 포함된 파일을 찾습니다.

문제는 trigram이 너무 짧아서 false positive가 많다는 것입니다. 3글자 조합은 코드베이스 전체에 너무 자주 등장합니다. 인덱스가 "이 파일에 있을 수 있다"고 알려줘도, 실제로 열어보면 없는 경우가 많습니다.

sparse n-gram은 이 문제를 해결합니다. 핵심 차이는 두 가지입니다.

첫째, 가변 길이 n-gram을 사용합니다. 3글자로 고정하는 대신, 상황에 따라 4글자, 5글자, 혹은 그 이상의 n-gram을 생성합니다. function처럼 흔한 패턴은 더 긴 n-gram으로 인덱싱하고, 드문 패턴은 짧은 n-gram으로 충분합니다. 이렇게 하면 인덱스의 선택도(selectivity)가 높아져서 false positive가 줄어듭니다.

둘째, 빈도 기반 가중치를 적용합니다. 코드에서 자주 등장하는 n-gram(예: the, int, return)은 가중치를 낮추고, 드물게 등장하는 n-gram은 가중치를 높입니다. 검색 시 가장 선택적인 n-gram부터 필터링하면, 후보 파일 수를 빠르게 좁힐 수 있습니다.

인덱스 파일 구조도 효율적입니다. 2파일 아키텍처로 설계되어 있는데, 하나는 n-gram에서 파일 목록으로의 매핑(역인덱스), 다른 하나는 실제 파일 내용의 오프셋 정보를 담습니다. 정규식 패턴이 들어오면, 이를 인덱스 쿼리로 변환해서 후보 파일을 빠르게 좁힌 뒤, 해당 파일만 실제로 스캔합니다.

인덱스 동기화도 흥미롭습니다. 개발자가 코드를 수정할 때마다 인덱스를 처음부터 다시 만들면 비효율적입니다. Instant Grep은 Git 앵커 기반 동기화를 사용합니다. Git 커밋을 기준점으로 삼아서, 변경된 파일만 인덱스를 업데이트합니다. 전체 재구축 없이 인덱스를 최신 상태로 유지하는 방식입니다.

벤치마크와 그 이면

Cursor가 공개한 벤치마크는 인상적합니다. 테스트 대상은 Chromium 코드베이스로, 약 50만 개 파일이 들어 있는 대형 모노레포입니다.

순수 로컬 검색은 13ms로 1,300배 빠릅니다. Cursor의 아키텍처에서는 인덱스가 원격 서버에 있으므로 네트워크 지연이 추가되는데, 그래도 243ms로 69배 빠릅니다. 에이전트가 체감하는 실제 성능은 69배 향상입니다.

하지만 이 벤치마크에는 보이지 않는 비용이 있습니다. 커뮤니티가 즉시 지적한 부분입니다.

인덱스 빌드 시간입니다. Chromium 수준의 코드베이스에서 인덱스를 처음 만드는 데 약 4분이 걸립니다. ripgrep은 인덱스 구축 시간이 0입니다. 프로젝트를 처음 열 때의 초기 비용을 고려하면, "16.8초 vs 13ms"라는 비교는 전체 그림의 일부만 보여줍니다.

인덱스 크기도 무시할 수 없습니다. Chromium 코드베이스의 인덱스는 약 1GB에 달합니다. 여러 대형 프로젝트를 동시에 작업하는 개발자라면 인덱스만으로 수 GB의 디스크 공간이 필요합니다.

ripgrep이 진짜 16.8초 걸리는가?라는 질문도 있습니다. 이 수치는 Chromium이라는 극단적 케이스에서의 결과입니다. 대부분의 프로젝트는 Chromium보다 훨씬 작고, ripgrep으로도 충분히 빠릅니다. 일반적인 중소 규모 프로젝트에서 ripgrep은 밀리초 단위로 동작합니다.

이런 맥락에서 Hacker News의 한 유저 boyter의 지적이 눈에 띕니다.

"요즘 데스크톱 CPU가 200MB 캐시를 탑재하면서 점점 더 유리한 접근법이 되고 있습니다."

인덱스 기반 검색이 하드웨어 발전과 시너지를 내고 있다는 분석입니다. CPU 캐시가 커지면서 인덱스를 메모리에 올려두는 비용이 줄어들고 있습니다.

AI 코딩 도구의 인프라 경쟁

Instant Grep을 단순한 기능 하나로 보면 핵심을 놓칩니다. 이것이 중요한 이유는 AI 코딩 도구의 경쟁 축이 이동하고 있기 때문입니다.

지금까지 AI 코딩 도구의 경쟁은 주로 모델 품질에 집중되어 있었습니다. 어떤 LLM을 쓰느냐, 코드 생성 정확도가 얼마나 높으냐가 핵심 차별화 포인트였습니다. 하지만 모델 품질은 점점 상향 평준화되고 있습니다. GPT-4o, Claude 3.5 Sonnet, Gemini 2.0 사이의 코드 생성 품질 차이는 1년 전보다 좁아졌습니다.

그래서 경쟁의 축이 도구 인프라로 이동하고 있습니다. 모델이 똑같이 똑똑하다면, 모델에게 얼마나 좋은 컨텍스트를 제공하느냐가 결과를 결정합니다. 코드 검색, 인덱싱, 심볼 분석, 프로젝트 구조 이해 같은 기반 기술이 에이전트 품질의 핵심이 됩니다.

Cursor가 GitHub Code Search 출신 엔지니어를 영입해서 검색 인프라에 투자한 것은 이 흐름의 구체적 사례입니다. Cursor는 이미 $29.3B 밸류에이션의 Anysphere가 운영하며, $50B 협상 중이라는 보도까지 나오고 있습니다. ARR $2B를 달성했고, 17개월 만에 $1B ARR을 찍어 역대 가장 빠른 SaaS라는 기록을 세웠습니다. 100만 명 이상의 사용자, Fortune 500 절반 이상이 사용 중입니다. 이 규모에서 검색 인프라의 개선은 수백만 에이전트 세션의 품질에 직접 영향을 미칩니다.

반면 VS Code의 GitHub Copilot, JetBrains의 AI Assistant, Windsurf 같은 경쟁자들은 아직 이 수준의 검색 인프라 투자를 공개하지 않았습니다. Copilot은 GitHub Code Search와 같은 회사 안에 있으면서도, 로컬 에디터에 이 기술을 적용했다는 발표는 없습니다. 이것이 Cursor의 기술적 차별화가 되는 이유입니다.

커뮤니티는 반으로 갈렸다

Instant Grep 발표 이후 Hacker News와 Reddit에서의 반응은 선명하게 양극화되었습니다.

회의론

회의적인 시각의 핵심은 "벤치마크의 공정성"입니다.

ripgrep이 16.8초 걸리는 상황은 Chromium처럼 극단적으로 큰 코드베이스에서의 결과입니다. 대부분의 개발자가 일상적으로 작업하는 프로젝트에서는 ripgrep이 이미 충분히 빠르다는 지적입니다. 인덱스 빌드에 4분이 걸린다는 점이 비교에서 빠져 있다는 비판도 있었습니다.

더 근본적인 반론도 있습니다. "에이전트의 검색 속도보다 검색 결과의 품질이 더 중요하다"는 주장입니다. 13ms에 결과를 가져와도, 그 결과가 에이전트가 실제로 필요한 코드가 아니라면 무의미합니다. 정규식 검색만으로는 코드의 의미적 관계를 파악할 수 없고, 시맨틱 검색이나 AST 기반 분석이 더 중요할 수 있다는 것입니다.

오픈소스 진영에서는 fff.nvim이라는 대안이 등장했습니다. Neovim 플러그인으로 구현된 이 도구는 Cursor와 유사한 인덱스 기반 검색을 제공하면서도, 인덱스 크기가 100MB(Cursor의 1/10), 빌드 시간이 8초(Cursor의 1/30)입니다. 물론 기능 범위가 다르겠지만, "이 문제를 해결하는 데 Cursor 수준의 인프라가 반드시 필요한가?"라는 질문을 던지고 있습니다.

옹호론

옹호하는 쪽은 에이전트 시대의 맥락에서 이 기술을 봅니다.

AI 에이전트는 한 세션에서 grep을 수십 번 호출합니다. 각 검색이 16초에서 13ms로 줄어들면, 에이전트 전체 작업 시간이 분 단위로 단축됩니다. 검색이 빨라지면 에이전트가 더 탐색적으로 행동할 수 있습니다. "혹시 비슷한 패턴이 다른 파일에도 있을까?" 같은 질문을 비용 없이 던질 수 있게 됩니다. 토큰 효율성도 높아집니다. 검색에 시간을 덜 쓰면, 같은 시간 안에 더 많은 추론에 토큰을 배분할 수 있습니다.

수백만 파일 규모의 모노레포에서 일하는 대기업 개발자에게는 이 기술이 체감되는 차이를 만든다는 의견도 있었습니다. Google, Meta, Microsoft 같은 곳에서는 Chromium 수준의 코드베이스가 일상적이기 때문입니다.

서버사이드에서 로컬로, 기술의 이동

한 걸음 물러서서 보면, Instant Grep은 기술 이동의 패턴을 보여줍니다.

GitHub Code Search는 데이터센터의 분산 시스템 위에서 동작합니다. 수억 개 리포지토리를 처리하기 위해 설계된 대규모 인프라입니다. 이 기술을 개발자의 노트북으로 가져온다는 것은, 서버에서 검증된 알고리즘이 하드웨어 발전 덕분에 로컬에서도 실용적이 되었다는 뜻입니다.

이 패턴은 AI 코딩 도구에서 반복되고 있습니다. 과거에는 서버에서만 가능했던 것들이 로컬로 내려오고 있습니다. 코드 분석, 심볼 인덱싱, 시맨틱 임베딩 같은 기술들이 점점 에디터 안으로 들어오고 있습니다. Cursor가 원격 인덱스 서버를 두면서도 로컬 캐싱을 병행하는 하이브리드 아키텍처를 선택한 것도 이 흐름의 일부입니다.

앞으로의 방향은 어디일까요? 정규식 검색과 시맨틱 검색의 융합이 다음 단계로 보입니다. 현재 Instant Grep은 정규식 패턴 매칭에 집중되어 있습니다. 하지만 에이전트가 진정으로 필요한 것은 "이 함수와 비슷한 역할을 하는 코드를 찾아줘"와 같은 의미 기반 검색입니다. sparse n-gram의 빠른 필터링과 벡터 임베딩의 시맨틱 이해를 결합하면, 에이전트의 코드 이해 능력이 한 단계 높아질 수 있습니다.

도구 인프라가 곧 에이전트의 지능이다

Cursor의 Instant Grep은 단순한 성능 개선 이상의 의미를 갖습니다. AI 코딩 에이전트의 경쟁이 모델 품질에서 도구 인프라로 확장되고 있음을 보여주는 사례입니다.

Marti가 GitHub에서 Cursor로 이동한 것은 상징적입니다. 서버사이드 검색 인프라의 전문가가 로컬 AI 코딩 도구로 자리를 옮겼다는 것은, 이 영역에 해결할 가치가 있는 기술적 문제가 산적해 있다는 뜻입니다. 그리고 그 문제를 해결하는 기업이 에이전트 시대의 승자가 될 가능성이 높습니다.

$29.3B 밸류에이션의 Cursor가 검색 엔진 하나에 이 정도의 엔지니어링을 투자한 이유는 명확합니다. 에이전트가 똑똑해지려면 먼저 빨라져야 합니다. 그리고 빨라지려면 인프라가 받쳐줘야 합니다. 모델은 범용화되고 있지만, 모델 위의 도구 인프라는 아직 차별화의 여지가 큽니다.

커뮤니티의 회의론도 유효합니다. 인덱스 빌드 비용, 대부분의 프로젝트에서 ripgrep이 이미 충분하다는 점, 속도보다 결과 품질이 중요하다는 지적은 모두 타당합니다. 하지만 AI 에이전트의 사용 패턴이 인간 개발자와 근본적으로 다르다는 점을 고려하면, 이 투자의 방향성은 맞습니다. 에이전트는 인간보다 훨씬 많이, 훨씬 자주 검색합니다. 그 차이가 1,300배의 속도 개선을 의미 있게 만듭니다.

다음 질문은 이것입니다. Copilot과 Windsurf는 언제 같은 수준의 검색 인프라를 갖추게 될까요? 그리고 정규식을 넘어선 시맨틱 코드 검색은 언제 에이전트의 기본 능력이 될까요? Cursor가 Instant Grep으로 던진 것은 기술적 우위의 과시가 아니라, 에이전트 인프라 경쟁의 시작 신호입니다.