AI 에이전트(AI Agent)로 코드베이스를 다루다 보면 은근히 신경 쓰이는 것이 바로 "검색 횟수"입니다.

rg나 grep 자체는 우수하지만, Claude Code나 Codex, OpenCode처럼 동일한 리포지토리(Repository)에 대해 반복해서 검색을 수행하는 방식에서는 매번 프로세스를 실행하고, 매번 .gitignore를 읽고, 매번 파일 트리(File Tree)를 훑는 비용이 쌓이게 됩니다.

한 번의 검색이라면 오차 범위일지 몰라도, 한 세션에서 수십 번, 수백 번 반복하다 보면 무시하기 어려워집니다.

그럴 때 발견한 것이 FFF입니다.

FFF는 Neovim의 파일 피커(File Picker)로 시작된 프로젝트이지만, 지금은 그뿐만 아니라 Rust로 제작된 검색 코어를 C / Node / Bun / MCP Server로 사용할 수 있는 "검색 기반(Search Infrastructure)"이 되었습니다.

README에 따르면, FFF는 opencode의 파일 검색(File Search)을 지원하고 있으며, MCP Server 또한 OpenCode를 포함한 여러 AI 코딩 환경에 대응하고 있습니다.

즉, 단순한 Neovim 플러그인(Plugin)이 아니라, AI 에이전트 시대의 검색 기반으로서 외부로 확장되기 시작했다고 볼 수 있습니다.

이 기사에서는 FFF가 무엇을 해주는지, ripgrep과는 어떻게 다른지, 그리고 AI 에이전트용 MCP Server로서 어떻게 도입하는지를 소개합니다.

1.1 목적

이 기사의 목적은 다음 세 가지입니다.

• FFF가 무엇인지 대략적으로 이해하기
• rg / grep과 비교하여 무엇이 다른지 정리하기
• Claude Code / Codex 등에서 사용하기 위한 도입 이미지 잡기

1.2 대상 독자

• Claude Code / Codex / OpenCode / Cursor 등을 일상적으로 사용하는 분
• 동일한 리포지토리에 대해 반복해서 검색하는 분
• AI 에이전트의 탐색 비용을 조금이라도 낮추고 싶은 분
• ripgrep의 대체라기보다, "AI를 위한 검색 기반"에 관심이 있는 분

2. FFF란 무엇인가

FFF는 고속의 파일/콘텐츠 검색(File / Content Search)을 제공하는 Rust 기반의 검색 라이브러리입니다.

수행하는 작업을 대략적으로 말하자면 다음과 같습니다.

• 리포지토리를 한 번 스캔하여 파일 목록을 인덱싱(Indexing)한다
• 검색에 필요한 메타데이터와 캐시(Cache)를 상주 프로세스(Resident Process) 측에 유지한다
• 이후의 검색은 그 Warm한 상태를 재사용하여 빠르게 반환한다
• 그 결과를 Neovim / Node / Bun / C / MCP Server에서 공통 코어로 사용한다

즉, ripgrep과 같은 "그 자리에서 한 번 검색하고 끝나는 CLI"가 아니라, 오래 지속되는 프로세스 안에서 반복해서 검색하는 것을 전제로 한 설계입니다.

README에도 나와 있듯이, FFF는 CLI가 아니라 라이브러리(Library)로 만들어져 있습니다.

이 점이 AI 에이전트와 궁합이 매우 좋습니다.

3. 무엇이 다른가

OS의 grep이나 ripgrep과 비교하면 차이점은 다음과 같습니다.

중요한 점은 FFF가 검색 알고리즘만 빠른 것이 아니라, "매번 발생하는 준비 비용을 지불하지 않아도 되기 때문에" 빠르다는 점입니다.

AI 에이전트는 인간이 셸(Shell)에서 rg를 한 번 입력하는 것과는 달리, 동일한 리포지토리에 대해 반복해서 탐색을 수행합니다.

그렇기 때문에 FFF와 같은 상주형 설계가 효과를 발휘합니다.

4. 왜 빠른가

README나 구현 내용을 보면 속도의 이유는 매우 명확합니다.

• 매번 프로세스를 실행할 필요가 없다
• .gitignore 분석이나 파일 트리(File Tree) 구축을 재사용할 수 있다
• 백그라운드 워처(Background Watcher)로 차분 업데이트가 가능하다
• 콘텐츠 캐시(Content Cache)와 mmap warmup을 가질 수 있다
• 결과를 구조화하여 반환하므로 호출 측에서의 재파싱(Re-parsing)이 필요 없다

검색 모드 자체도 여러 가지가 있습니다.

• plain text: SIMD 기반의 고속 literal search
• regex: Rust의 regex engine
• fuzzy: 오타(typo)에 강한 fuzzy search
• multi pattern OR: Aho-Corasick을 이용한 여러 패턴 일괄 검색

이 정도 단계에 오면, 느낌상 "rg의 대체제"라기보다는 "AI와 editor를 위해 최적화된 검색 엔진"에 가깝습니다.

5. MCP Server로 사용하는 것이 매우 좋다

개인적으로 가장 좋다고 생각한 점은 FFF가 MCP Server를 제공한다는 점입니다.

이를 도입하면 AI 에이전트가 내장된(built-in) 검색 기능이 아니라, FFF의 grep / find_files / multi_grep을 사용할 수 있게 됩니다.

할 수 있는 일은 간단합니다.

• grep: 내용 검색
• find_files: 파일명·경로 탐색
• multi_grep: 여러 패턴의 OR 검색

여기서 말하는 grep은 OS의 grep이 아니라, FFF 고유의 content search tool입니다. Rust의 검색 코어를 프로세스 내에서 직접 호출하여 MCP tool로서 공개하고 있습니다.

즉, 에이전트 입장에서는 "검색 도구"이지만, 내부적으로는 매번 shell command를 실행하고 있는 것이 아닙니다.

6. 무엇이 좋은가

AI 에이전트와 조합하면 다음과 같은 이점이 있습니다.

• 동일한 repo에 대한 반복적인 검색이 가벼워짐
• 오타(typo)에 어느 정도 강함
• git status나 frecency를 고려한 결과가 반환됨
• 경로 탐색(path search)과 내용 검색(content search)을 동일한 철학으로 다룰 수 있음
• 도구(tool)로서 노출(expose)되므로, 에이전트 측의 이용 방침을 작성하기 쉬움

특히, AGENTS.md나 CLAUDE.md에

Use the fff MCP tools for all file search operations instead of default tools.

와 같이 적어두면, 내장 검색(built-in search)과 FFF의 사용 구분(使い分け)이 흔들리지 않게 됩니다.

7. 도입 방법

도입 자체는 매우 간단합니다.

7.1 설치

Linux / macOS:

curl -L https://dmtrkovalenko.dev/install-fff-mcp.sh | bash

Homebrew로도 설치할 수 있습니다.

brew install dmtrKovalenko/fff/fff-mcp

7.2 Codex에 등록

codex mcp add fff -- fff-mcp

영구 저장용 DB도 추가한다면 다음과 같습니다.

codex mcp add fff -- fff-mcp \
--frecency-db /home/you/.cache/fff/frecency.db \
--history-db /home/you/.local/share/fff/history.db

7.3 Claude Code에 등록

claude mcp add -s user fff -- fff-mcp \
--frecency-db /home/you/.cache/fff/frecency.db \
--history-db /home/you/.local/share/fff/history.db

7.4 동작 확인

fff-mcp --healthcheck

repo 안에서 실행하면 base path나 git repository를 제대로 인식하고 있는지 확인할 수 있습니다.

rg는 이제 필요 없는 것인가

8. 물론, 그런 뜻은 아닙니다.

단발성으로 shell에서 한 번만 찾는다면, 지금도 rg는 매우 좋습니다.

다만, AI 에이전트나 editor integration처럼,

• 동일한 repo에 여러 번 질의함
• 파일 탐색(file search)과 grep을 여러 번 왕복함
• 가능하다면 랭킹(ranking)이나 컨텍스트(context)와 함께 결과를 받고 싶음

이라는 상황에서는, FFF

FFF가 훨씬 더 합리적인 선택입니다.

rg가 단거리 달리기라면, FFF는 장거리 경주용입니다.

9. 마치며

AI 주도 개발 (AI-driven development) 문맥에서는 자칫 model이나 prompt에만 눈길이 가기 쉽지만, 실제로는 「탐색 비용 (exploration cost)을 어떻게 낮출 것인가」도 상당히 중요합니다.

FFF는 그중에서도 상당히 실무적인 접근 방식이라고 생각했습니다.

화려한 기능이라기보다, 매번 수행하는 검색을 조금씩 가볍게 만들어 세션 전체의 스트레스를 낮추는 타입의 개선입니다.

Claude Code나 Codex를 일상적으로 사용하면서 「검색이 은근히 느리다」 혹은 「같은 것을 몇 번이고 다시 찾고 있다」고 느끼는 분들이라면, 한 번 시도해 볼 가치가 있다고 생각합니다.

참고 링크

• FFF.nvim / FFF
• 과거 기사

Appendix. CodeGraph / Graphify와의 차이점

여기까지 읽으셨다면,

FFF

CodeGraph

Graphify

는 전부 「AI의 탐색을 돕는 것」으로 보일지도 모릅니다.

실제로 방향성은 비슷하지만, 특화된 작업은 상당히 다릅니다.

A.1 대략적인 차이

대략적으로 말하자면,

• FFF는 「찾기」 위한 도구
• CodeGraph는 「코드 구조를 이해하기」 위한 도구
• Graphify는 「프로젝트 지식 전체를 조망하기」 위한 도구

입니다.

A.2 CodeGraph와의 차이

CodeGraph는 tree-sitter 등을 사용하여 코드를 구조로서 인덱싱(indexing)하며,

• 어디에 정의되어 있는가
• 누가 그 함수를 호출(call)하고 있는가
• 해당 변경이 무엇에 영향을 줄 것인가

와 같은 「문자열 검색만으로는 알기 어려운 질문」에 답하는 데 특화되어 있습니다.

반면, FFF는 훨씬 앞 단계의 레이어에 있습니다.

• ActorAuth라는 식별자를 먼저 찾고 싶다
• upload 주변의 파일들을 훑어보고 싶다
• TODO나 log 문구를 찾고 싶다

와 같이 「우선 정답 후보를 찾아내는 (hit the mark)」 작업에 적합합니다.

따라서 실무에서는 경쟁 관계라기보다 분업 관계입니다.

• 우선 FFF로 식별자나 파일을 찾는다
• 정답 후보를 찾으면 CodeGraph로 caller / callee / impact를 추적한다

라는 흐름이 매우 자연스럽습니다.

A.3 Graphify와의 차이

Graphify는 코드뿐만 아니라,

• 설계 문서
• API 명세서
• 이미지
• 영상

과 같은 소재도 함께 지식 그래프 (knowledge graph)화하여, 프로젝트 전체의 관계성을 조망하는 방향의 도구입니다.

그렇기 때문에 커버리지는 FFF보다 훨씬 넓습니다.

다만, 넓은 만큼 역할도 다릅니다.

FFF는 「지금 이 repo 안에서 필요한 file이나 text를 빠르게 찾는 것」에 집중합니다.

대조적으로 Graphify는,

• 이 설계 문서와 코드의 관계는 무엇인가
• 프로젝트 전체에서 중요한 개념은 무엇인가
• 이미지나 자료를 포함하면 어떤 지식의 덩어리가 있는가

와 같은, 더 높은 관점의 질문에 적합합니다.

A.4 어떻게 구분해서 사용할 것인가

개인적으로는 다음과 같이 생각하면 이해하기 쉽습니다.

즉,

• 먼저 찾으려면 FFF
• 구조를 이해하려면 CodeGraph
• 지식 전체를 조망하려면 Graphify

입니다.

어느 하나만 있으면 모든 것이 해결된다기보다, 역할을 분담시키면 상당히 쾌적해집니다.

이런 의미에서 FFF는 화려한 「이해 계열」 도구라기보다, AI 에이전트의 탐색 루프 (exploration loop)를 뒷받침하는 기초 인프라에 가까운 도구라고 생각합니다.

Discussion