ripgrep, 왜 아직도 grep 쓰고 계세요?

터미널에서 코드 검색, 어떻게 하고 계세요?

개발하다 보면 하루에도 수십 번 코드를 검색하게 되잖아요. "이 함수 어디서 쓰이지?", "이 변수명 어디에 정의돼 있지?" 같은 상황이요. 대부분 IDE의 검색 기능을 쓰거나, 터미널에서 grep을 돌리게 되는데요. 그런데 이 grep이라는 도구, 사실 1970년대에 만들어진 물건이에요. 물론 오랫동안 잘 써왔지만, 현대의 거대한 코드베이스를 다루기엔 좀 느릴 수밖에 없거든요.

ripgrep(줄여서 rg)은 Rust로 작성된 코드 검색 도구인데요, 기존의 grep이나 ag(The Silver Searcher), git grep 같은 도구들보다 훨씬 빠르다는 걸 체계적인 벤치마크로 입증한 프로젝트예요. ripgrep의 제작자인 Andrew Galloway(닉네임 burntsushi)가 왜, 그리고 어떻게 더 빠른지를 상세히 분석한 글이 다시 조명받고 있어요.

ripgrep이 빠른 이유, 기술적으로 들여다보면

"그냥 Rust로 짜서 빠른 거 아니야?"라고 생각하실 수 있는데, 그게 전부가 아니에요. ripgrep이 빠른 핵심 이유는 크게 세 가지로 나눌 수 있어요.

첫째, 정규표현식 엔진의 차이예요. ripgrep은 Rust의 regex 크레이트를 사용하는데, 이 엔진은 유한 오토마타(finite automata) 기반이에요. 이게 뭐냐면, 정규표현식을 미리 상태 기계(state machine)로 컴파일해놓고 텍스트를 한 글자씩 읽으면서 상태를 전이시키는 방식이에요. 일반적인 백트래킹(backtracking) 방식과 다르게, 입력 길이에 비례하는 선형 시간 복잡도를 보장하거든요. 즉, 아무리 복잡한 패턴이라도 입력 크기만큼만 시간이 걸려요. 백트래킹 방식은 특정 패턴에서 지수적으로 느려질 수 있는 것과 대조적이죠.

둘째, 내부 리터럴 최적화(literal optimization)가 있어요. 예를 들어 foo[0-9]+bar라는 패턴을 검색한다고 해볼게요. ripgrep은 이 패턴 안에서 고정된 문자열 foo와 bar를 먼저 추출해서, 이 리터럴이 포함된 줄만 골라낸 뒤 그 줄에서만 전체 정규표현식 매칭을 수행해요. 텍스트 대부분의 줄에는 foo가 없을 테니, 정규표현식 엔진이 실제로 처리해야 하는 양이 크게 줄어드는 거죠. SIMD 명령어를 활용한 Teddy 같은 멀티 리터럴 검색 알고리즘도 내부적으로 사용하고 있어요.

셋째, 똑똑한 파일 필터링이에요. ripgrep은 기본적으로 .gitignore에 명시된 파일들을 건너뛰고, 바이너리 파일도 자동으로 제외해요. node_modules나 .git 디렉토리, 빌드 아티팩트 같은 것들을 알아서 무시하니까 불필요한 I/O가 줄어드는 거예요. 이건 단순한 편의 기능이 아니라 성능에 직접적으로 영향을 주는 부분이에요. 대형 프로젝트에서는 무시해야 할 파일이 검색 대상보다 훨씬 많을 수도 있거든요.

벤치마크로 보는 실제 성능 차이

burntsushi가 공개한 벤치마크에서 ripgrep은 리눅스 커널 소스 코드(약 6만 개 파일) 같은 대규모 코드베이스에서 일관되게 가장 빠른 결과를 보여줬어요. grep -r보다는 보통 5~10배, ag(The Silver Searcher)보다도 2~5배 정도 빠른 경우가 많았는데요. 특히 유니코드 처리가 필요한 검색에서는 차이가 더 벌어졌어요. ag는 PCRE 정규표현식 라이브러리를 사용하는데, PCRE는 유니코드 처리에서 상대적으로 비용이 크거든요.

git grep도 비교 대상인데, 재미있는 점은 git grep이 특정 상황에서는 꽤 빠르다는 거예요. Git의 인덱스를 활용해서 파일 목록을 빠르게 가져올 수 있기 때문이에요. 하지만 정규표현식 엔진 자체의 성능 차이 때문에 ripgrep에 밀리는 경우가 대부분이었어요.

개발 생태계에서 ripgrep의 위치

사실 ripgrep은 이미 개발 도구 생태계에 깊숙이 스며들어 있어요. VS Code의 내장 검색 기능이 바로 ripgrep을 사용하고 있거든요. VS Code에서 Ctrl+Shift+F(또는 Cmd+Shift+F)로 프로젝트 전체 검색을 할 때, 뒤에서 돌아가는 엔진이 ripgrep이에요. 그래서 VS Code의 검색이 다른 에디터에 비해 체감상 빠르게 느껴지는 거예요.

Neovim의 Telescope 플러그인이나, fzf와 조합해서 쓰는 경우도 많고요. 실무에서 대규모 모노레포(monorepo)를 다루는 팀이라면 ripgrep의 성능 차이가 체감될 수밖에 없어요. 수만 개의 파일에서 특정 API 호출을 찾아야 할 때, 1초 걸리던 게 0.1초로 줄어들면 작업 흐름이 달라지거든요.

비슷한 도구로는 ag(The Silver Searcher)가 있고, 더 최근에는 ugrep이나 hypergrep 같은 프로젝트도 등장했어요. 하지만 성능, 기능, 커뮤니티 지원 면에서 ripgrep이 여전히 사실상의 표준(de facto standard) 위치에 있다고 볼 수 있어요.

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

아직 ripgrep을 안 써보셨다면, 설치는 정말 간단해요. macOS라면 brew install ripgrep, Ubuntu라면 apt install ripgrep이면 돼요. 기본 사용법도 rg "검색어" 한 줄이면 충분하고요.

특히 한국어가 섞인 코드베이스에서 검색할 때 ripgrep의 유니코드 지원이 빛을 발해요. 한글 주석이나 문자열을 검색할 때도 깨지거나 느려지는 문제가 없거든요. 그리고 --type 옵션으로 특정 언어 파일만 검색하는 것도 편리해요. rg --type py "함수명" 이런 식으로요.

이 글이 다시 주목받는 이유도 생각해볼 만한데요. 2016년 글이지만 핵심 메시지는 변하지 않았어요. "좋은 알고리즘 선택과 시스템 수준의 최적화가 결합되면 엄청난 성능 차이를 만들 수 있다"는 거죠. Rust 생태계가 시스템 도구 분야에서 얼마나 강력한지 보여주는 대표적인 사례이기도 하고요.