약 일주일 동안 저는 제 도구가 Next.js 모노레포 (monorepo)를 7~10초 만에 압축한다고 사람들에게 말해왔습니다. 실제 수치는 1.6초였습니다.

저는 벤치마크 (benchmark) 출력값의 잘못된 줄을 읽고 있었습니다. time 명령어는 사용자 시간 (user time)과 벽 시계 시간 (wall time)을 제공하는데, 저는 코어 전체에 걸쳐 합산된 CPU-초 (CPU-seconds)인 사용자 시간을 인용하고 있었습니다. 제 도구는 5개의 코어에서 실행됩니다. 그래서 저는 질문하는 모든 사람에게 자신 있게 성능을 5배나 낮게 말하고 있었던 것입니다. 이 포스트에서 한 가지만 기억하신다면 이것입니다. 벽 시계 시간 (wall clock)이 인간이 경험하는 숫자입니다. 그것을 인용하세요.

어쨌든, 이 포스트는 repo-to-prompt 도구에 관한 것입니다. 네, 2026년에 말이죠. 끝까지 읽어주세요.

먼저 어색한 타이밍 문제부터

Repo-to-prompt 도구들은 2년 전, 워크플로우가 "수동으로 컨텍스트 (context)를 조립하고, 채팅창에 붙여넣고, 기도하는" 방식이었을 때 전성기를 누렸습니다. 그 후 에이전트 (agents)들이 grep을 학습했습니다. 이제 Claude Code와 Cursor는 스스로 컨텍스트를 선택하며, 대부분의 사람들은 세션마다 패커 (packer)를 실행하는 것을 멈췄습니다.

그렇다면 왜 하나를 만드는 걸까요?

때때로 에이전트의 검색 (retrieval) 결과가 정확히 제가 원하지 않는 것이기 때문입니다. 전체 서브시스템 (subsystem)에 걸친 코드 리뷰. 마이그레이션 (migration) 계획. 아무도 나를 위해 검색을 해주지 않는 가공되지 않은 API 호출. 그런 순간에는 제가 직접 파일을 선택하고, 토큰 (tokens) 비용이 얼마나 드는지 확인하며, .env.production 파일이 따라오지 않았음을 알고 싶습니다.

세 가지 요구사항. 빠를 것. 가시적인 토큰 비용과 함께 상호작용할 것. 비밀 정보 (secret)를 스캔할 것.

세 가지를 모두 갖춘 도구는 없었습니다. 빠른 도구들 (yek, repomix-rs)은 실행 후 잊어버리는 (fire-and-forget) 방식입니다. 지정하고, 덤프하고, 끝입니다. 상호작용이 가능한 도구 (code2prompt)는 토큰 비용을 보여주지 않습니다. 그래서 저는 code2prompt를 포크 (fork)하여 gnaw를 만들었습니다.

벤치마크

벤치마크 (vendor benchmarks)는 기본적으로 쓰레기입니다. 서로 다른 기기, 선별된 플래그 (flags), 그리고 제가 가장 좋아하는 수법인 아무도 확인하지 않은 출력값과 비교하는 방식 같은 것들 말이죠. 절반의 시간 안에 절반의 파일만 내뱉는 도구는 빠른 것이 아닙니다. 불완전한 것입니다.

그래서 여러분이 다시 실행하더라도 견딜 수 있도록 구축된 설정은 다음과 같습니다:

• Docker, --cpus 8 --memory 8g. 단 한 번의 명령으로, 저와 동일한 환경을 구축합니다.
• 코퍼스 (Corpus): 70e3934 커밋의 vercel/next.js.
• hyperfine, 10회 실행, 워밍업 (warmup), 평균 ± σ (표준편차).
• 파일 수 확인: 모든 도구는 다른 도구와 약 1% 이내의 오차로 결과를 내놓아야 하며, 그렇지 않으면 비교는 무효입니다. 모든 도구가 26.6k에서 26.9k 사이의 파일 수를 기록했습니다.
• repomix-rs는 npm 패키지가 아닌 5798dc0에서 소스 빌드되었습니다. npm 빌드는 대략 2배 더 느립니다. 저는 그들의 패키징이 아닌 엔진을 벤치마킹했습니다. 이 점이 오히려 제 수치를 더 나쁘게 보이게 만든다면, 오히려 좋습니다.
• 스캔 설정 (Scan settings), 중요하기 때문에 정확히 명시합니다: 5개의 도구 중 3개(gnaw, repomix, repomix-rs)가 시크릿 스캔 (secret-scan)을 수행합니다. 실행 1 (Run 1)에서는 끌 수 있는 경우 스캔을 끕니다. repomix-rs는 기본적으로 스캔을 수행하며 이를 비활성화할 방법을 찾지 못했으므로, 실행 1의 수치에는 스캔 시간이 포함되어 있습니다. 즉, 실행 1은 순수한 gnaw 대 repomix-rs의 비교가 아니며, 저는 이를 비교 대상으로 인용하지 않을 것입니다. 실행 2 (Run 2)가 순수한 비교입니다: 스캔이 가능한 모든 기능에 대해 스캔을 수행합니다.
• 도구를 개발하는 동안 3일에 걸쳐 세 번 실행했습니다. 절대적인 시간은 호스트의 상태에 따라 약 ±6% 정도 흔들렸습니다. 하지만 비율은 거의 변하지 않았습니다. 비율을 신뢰하십시오. 절대적인 시간은 "그날, 그 하드웨어에서의 결과"로 간주하십시오.

스크립트와 Dockerfile은 리포지토리에 있습니다. 다시 실행해 보세요. 진심입니다. 제가 가장 싫어하는 답변 유형은 "제 컴퓨터에서는 다르게 작동합니다"이며, 차라리 수치를 첨부하여 GitHub 이슈로 올려주시는 편이 낫습니다.

실행 1: 추출, 가능한 경우 스캔 비활성화

실행 2: 스캔 가능 도구 3개에 대해 스캔 활성화

제가 주장할 것과 주장하지 않을 것

실제로 사람들이 설치해서 사용하는 도구들과 비교했을 때, 그 격차는 미미한 수준이 아닙니다: yek보다 5배 빠릅니다. repomix보다 20배 빠릅니다. 두 도구 모두 스캐닝을 수행한다는 점을 고려하면 말이죠. 게다가 repomix의 그 수치는 Node.js의 시작 시간과 메모리 사용량을 모두 포함하고 있으며, gnaw의 gitleaks와는 다른 규칙 세트인 Secretlint를 실행하고 있습니다. 이 세 가지 주의 사항을 한 문장에 담은 이유는, 20배라는 헤드라인을 던져놓고 세 번 스크롤을 내려야 나오는 세부 사항을 숨기는 것이 벤더(vendor) 벤치마크가 거짓말을 하는 방식이기 때문입니다. 그리고 아니요, repomix는 사람들이 여전히 인용하는 예전 yek 벤치마크의 22분짜리 공룡이 아닙니다. 그들은 상당한 병렬화(parallelization) 작업을 완료했습니다. 현재 버전 기준으로 35초가 걸립니다. 그래도 여전히 20배 차이입니다.

두 도구 모두 스캐닝을 수행하는 조건에서 repomix-rs와 비교하면: 1.01 ± 0.08. 막상막하입니다. 저는 이 결과를 억지로 승리로 몰아가지 않겠습니다. 한 번에 정리한 전체 트레이드오프(trade-off)는 다음과 같습니다: gnaw는 실제 소요 시간(wall-clock time) 측면에서 repomix-rs와 대등하지만, 피크 RSS(Resident Set Size)가 166 MB 더 높으며, repomix-rs가 커스텀 정규식(regex) 세트를 실행하는 동안 gnaw는 전체 gitleaks 규칙 세트를 실행합니다. 메모리 사용량은 더 큰 규칙 세트를 사용하는 데 따른 대가입니다. 철저함이 166 MB의 가치가 있는지는 여러분의 선택입니다. 저는 제 선택을 내렸습니다.

정직하게 하나 더 말씀드리겠습니다. yek의 사용자 시간(user time)을 보십시오: 8.0 CPU-초입니다. 이제 gnaw의 시간을 보십시오: 7.4입니다. 총 작업량은 거의 동일합니다. yek은 하나의 코어에 머물러 있는 반면, gnaw는 8개의 코어 중 약 5개에 작업을 분산합니다 — cpu× 열에 표시된 5.2가 바로 실제 소요 시간(wall-clock)의 격차를 만드는 원인입니다. 2코어 CI 러너(runner)에서는 이 격차가 훨씬 줄어들 것입니다. (왜 8이 아니라 5.2인가요? 트래버스(traversal)는 부분적으로 I/O 바운드(I/O-bound)이기 때문입니다. 다른 코어들이 어디로 갔는지 프로파일링(profiling)하는 작업도 계획 목록에 있습니다.)

이제 제가 실제로 중요하게 생각하는 수치입니다. 스캐닝을 끈 gnaw: 1.55초. 26,706개의 파일에 대해 전체 gitleaks 패스(pass)를 수행했을 때: 1.76초.

스캐닝 비용은 약 200밀리초(ms)입니다.

저는 gitleaks가 더 무겁고 느린 옵션임을 알고 선택했으며, 상당한 비용이 발생할 것에 대비했습니다. 하지만 그 비용은 눈 깜빡할 사이였습니다. "비밀 스캐닝(secret scanning)은 너무 느려서 기본적으로 켜둘 수 없다"라고 말하던 시대는 이제 끝났습니다.

포크 (The fork)

code2prompt는 핵심을 정확히 짚었습니다. 리포지토리(repo)를 패킹(packing)하는 것은 단순히 실행하는 것이 아니라, 사용자가 조절할 수 있어야 하는 작업입니다. 이 도구는 TUI(Text User Interface)를 갖추고 있으며, 추출 속도 또한 네이티브 도구들과 대등합니다. 이것이 제가 처음부터 새로 시작하는 대신 이를 포크(fork)한 이유입니다.

제가 변경한 사항은 다음과 같습니다:

실시간 토큰 수 (Live token counts). gnaw가 존재하는 이유입니다. 트리(tree)를 탐색하며 파일과 디렉토리를 넣거나 뺄 때마다 토큰 총량이 실시간으로 업데이트됩니다. test/ 디렉토리를 선택 해제하면 토큰 수가 줄어드는 것을 바로 확인할 수 있습니다. 컨텍스트 윈도우(context window)는 예산과 같습니다. 도구는 사용자가 그 예산을 어떻게 쓰고 있는지 보여주어야 합니다.

제가 계속 기대해 왔던 방식대로 작동하는 검색. 버그 리포트라기보다는 취향의 차이입니다. code2prompt의 검색도 제 역할을 수행하지만, 제 손가락은 하루에도 몇 번씩 그 방식에 동의하지 않았습니다. 그래서 gnaw의 검색은 제 손가락이 기대하는 대로 작동합니다. 구체적인 UX 차이점들은 추후 별도의 글에서 다루겠습니다. 작고 구체적이면서도, 즐겁게 논쟁할 수 있는 주제들이기 때문입니다.

기본 스캐너로 gitleaks 사용. 철저한 옵션입니다. 저는 속도를 희생하는 대신 이를 선택한다고 가정했습니다. 위에서 언급했듯이, 200ms가 걸립니다. 올해 제가 한 가장 쉬운 거래였습니다. 저는 더 가벼운 스캐너들과 비교하여 재현율(recall)과 오탐(false positives)을 제대로 측정하기 위해, 의도적으로 비밀 정보(secrets)를 심어둔 코퍼스(corpus)를 구축하고 있습니다. 이것이 발표되기 전까지는 "더 철저하다"는 것이 측정된 결론이 아닌 저의 가설적인 믿음입니다.

병렬 추출 엔진 (A parallel extraction engine). CPU 사용량 5.2배. 표(table)가 이미 이 점을 입증했습니다.

순수하게 취향이 반영된 변경 사항들은 포크(fork) 버전에 남겨둡니다. 객관적인 수정 사항으로 판명되는 모든 것은 원래 있어야 할 곳인 업스트림(upstream)으로 보냅니다.

gnaw가 아닌 것

에이전트(Agent)가 아닙니다. 만약 Claude Code가 이미 당신의 작업에 적합한 컨텍스트를 잘 골라주고 있다면, 이 탭을 닫으셔도 좋습니다. gnaw는 당신이 직접 검색(retrieval) 단계를 수행하고 싶을 때를 위한 도구입니다. 결정론적(deterministic)이고, 검사 가능하며(inspectable), 스캔이 완료되며, 2023년처럼 GitHub에서 파일을 일일이 클릭하며 복사하는 20분이 아니라 2초 이내에 끝납니다.

여기서 끝이 아닙니다. 다음 로드맵은 **MCP 서버 (MCP server)**입니다. 이를 통해 에이전트가 gnaw를 수동 전용 도구로 사용하는 대신, 토큰 예산이 할당되고 비밀 정보가 스캔된 컨텍스트 추출기 (context extractor)로서 호출할 수 있게 될 것입니다. 그것이 바로 2026년에 의미 있는 버전이며, 제가 구축하기를 가장 기대하고 있는 부분입니다.

작업 내용 확인하기

Repo: gnaw. README에서 빠른 시작 (Quickstart) 방법을 확인할 수 있으며, 그 옆에 벤치마크 스크립트 (benchmark script)와 Dockerfile이 있습니다. docker run으로 실행해 보시고, 만약 결과 수치가 제 것과 다르다면 이슈 (issue)를 생성해 주세요. 저도 예전에 제 벤치마크 결과를 5배나 잘못 읽은 적이 있습니다. 따라서 수정 사항에 대해 까다롭게 굴 자격은 없습니다.

이 도구가 유용하다면, 별 (star) 하나가 다음 사람이 이 도구를 찾는 데 큰 도움이 됩니다.