ripgrep보다 100배 빠르다고? 정규식을 넘어선 코드 검색의 미래, fff

코드 검색, 우리가 당연하게 쓰던 방식에 한계가 있었다면?

개발하다 보면 코드 검색은 하루에도 수십 번씩 하게 되잖아요. VS Code에서 Ctrl+Shift+F 누르거나, 터미널에서 grep이나 ripgrep(rg)을 돌리거나요. 특히 ripgrep은 속도가 워낙 빨라서 "이것보다 더 빠를 수 있어?"라고 생각하기 쉬운데요. 최근 공개된 fff라는 도구가 정확히 그 질문에 도전장을 내밀었어요. ripgrep보다 100배 빠르다는 꽤 과감한 주장과 함께요.

fff의 핵심 아이디어는 간단해요. "코드 검색에 정규식(regex)이 꼭 필요한가?"라는 질문에서 출발하거든요. 우리가 코드를 검색할 때 대부분의 경우는 사실 정규식의 복잡한 패턴 매칭이 필요 없어요. 함수 이름을 찾거나, 특정 문자열이 어디서 쓰이는지 확인하거나, 변수명을 추적하는 정도죠. 그런데 기존 도구들은 항상 정규식 엔진을 거쳐야 하니까, 단순한 검색에서도 불필요한 오버헤드가 생기는 거예요.

어떻게 100배나 빠를 수 있을까

fff가 속도를 끌어올리는 핵심 전략은 정규식 엔진을 아예 쓰지 않는다는 점이에요. 이게 뭐냐면, ripgrep 같은 도구는 아무리 간단한 문자열을 검색해도 내부적으로 정규식 파서와 매칭 엔진을 통과시켜요. 정규식은 워낙 강력한 패턴 매칭을 지원하다 보니 그 범용성 자체가 비용이 되는 셈이죠. 마치 동네 편의점에 가는데 대형 트럭을 모는 것과 비슷해요. 갈 수는 있지만, 자전거가 훨씬 빠르고 효율적이잖아요.

fff는 이 점에 착안해서, 코드 검색에 최적화된 전용 알고리즘을 사용해요. 리터럴 문자열 매칭(literal string matching)이라고 하는데, 정규식의 복잡한 문법 해석 없이 바이트 단위로 직접 비교하는 방식이에요. 여기에 SIMD(Single Instruction, Multiple Data)같은 CPU 레벨의 병렬 처리 기법을 적극 활용해서, 한 번의 CPU 명령어로 여러 바이트를 동시에 비교할 수 있거든요. 쉽게 말해, 책에서 특정 단어를 찾을 때 한 글자씩 읽는 게 아니라 한 페이지를 사진 찍듯 한눈에 스캔하는 느낌이에요.

또한 fff는 파일 시스템 접근 자체도 최적화했어요. 대규모 코드베이스를 검색할 때 병목이 되는 건 사실 문자열 매칭보다 디스크에서 파일을 읽어오는 I/O인 경우가 많거든요. fff는 메모리 맵 파일(memory-mapped file)과 병렬 디렉토리 탐색을 조합해서 이 부분의 지연도 최소화했다고 해요.

ripgrep은 느린 도구였나? 그건 또 아니에요

오해하면 안 되는 게, ripgrep이 느리다는 이야기가 아니에요. ripgrep은 코드 검색 도구 중에서 이미 최상위권의 속도를 자랑하는 도구예요. 기존의 grep이나 ack, ag(The Silver Searcher) 같은 도구들을 이미 크게 앞지른 상태고요. 특히 ripgrep은 .gitignore를 자동으로 인식하고, 유니코드를 올바르게 처리하고, 정규식도 Rust의 regex 크레이트를 써서 상당히 빠르게 돌아가요.

그런데 fff의 접근은 아예 판을 다르게 깔아요. "범용 정규식 검색"이라는 카테고리에서 경쟁하는 게 아니라, "코드에서 특정 문자열을 찾는다"는 가장 흔한 유스케이스에 올인한 거죠. 그래서 정규식이 꼭 필요한 복잡한 패턴 매칭에서는 ripgrep이 여전히 더 적합할 수 있어요. fff는 트레이드오프를 명확히 한 도구인 셈이에요.

이런 접근은 소프트웨어 설계에서 꽤 중요한 교훈을 주기도 해요. 모든 상황을 커버하는 범용 솔루션보다, 가장 빈번한 케이스에 최적화된 전용 솔루션이 극적인 성능 차이를 만들어낼 수 있다는 거죠. 데이터베이스에서 범용 B-Tree 인덱스 대신 특정 쿼리 패턴에 맞는 전용 인덱스를 만드는 것과 비슷한 원리예요.

한국 개발자에게 주는 시사점

실무에서 대규모 모노레포를 다루는 분들이라면 한번 관심을 가져볼 만해요. 수만 개의 파일이 있는 프로젝트에서 검색 속도가 100배 차이나면, 체감이 꽤 클 수 있거든요. 특히 CI/CD 파이프라인에서 코드 패턴을 검사하거나, 대규모 로그 파일에서 특정 문자열을 찾는 스크립트에 적용하면 실질적인 시간 절약이 될 수 있어요.

다만 아직 초기 프로젝트인 만큼, ripgrep처럼 검증된 도구를 완전히 대체하기보다는 보조 도구로 먼저 시도해 보는 게 좋겠어요. 정규식이 필요 없는 단순 문자열 검색 위주라면 fff를, 복잡한 패턴 매칭이 필요하면 ripgrep을 쓰는 식으로 상황에 맞게 골라 쓰는 게 현실적이에요.

정리

"가장 흔한 작업을 가장 빠르게"라는 단순한 철학이 100배의 성능 차이를 만들어냈어요. 범용성을 포기하고 핵심 유스케이스에 집중하는 이 접근법, 여러분의 프로젝트에도 적용할 수 있는 부분이 있지 않을까요? 혹시 코드 검색 속도 때문에 병목을 겪어본 경험이 있으신가요?