Rip'n Fast. 더 적은 토큰, 더 나은 코드.

AI 컨텍스트를 위한 ripgrep. 에이전트가 리포지토리를 읽기 전에 지도를 제공하고, 에이전트가 무엇을 작성하는지 확인합니다.

순위가 매겨지고 결정론적인 호출 그래프(call graph): 무엇을 수정해야 하는지, 무엇이 깨지는지, 어떤 테스트를 실행해야 하는지를 알려줍니다. 편집 시에는 영향 범위(blast radius), 해당 지점에 도달하는 테스트, 악화된 것만 보고하는 12가지 품질 유형, 잊힌 공동 변경 사항(co-changes), 읽히고 쓰여진 필드(fields read and written), 여러 방식으로 해결되는 이름 등을 제공합니다.

단순히 사용하고 싶다면? 아래 한 줄로 설치한 다음, 각 코딩 세션 시작 시 에이전트에게 이를 사용하도록 지시하면 됩니다. 예를 들어: "Use ripwire on this repo." 대부분의 사람들이 필요한 것은 이것뿐입니다. 이 설치 과정은 또한 에이전트가 어떤 명령어를 언제 사용할지 가르쳐 줍니다.

모든 세부 정보가 필요한가요? 하단 근처의 참조 가이드에는 설치, 명령어, 출력 형식(output format), 종료 코드(exit codes), 제한 사항 등이 포함되어 있습니다. 시작하는 데는 필요하지 않습니다.

<a href="https://trendshift.io/repositories/217924?utm_source=trendshift-badge&utm_medium=badge&utm_campaign=badge-trendshift-217924"><img src="https://trendshift.io/api/badge/trendshift/repositories/217924/weekly?language=C%2B%2B" alt="Trendshift: redhat-et/ripwire의 주간 C++ 리포지토리 배지" width="250" height="55"></a> <details> <summary>필드 보고서: 대규모 다중 에이전트 코딩 작업에 ripwire가 기여한 내용</summary> — Claude Fable 5.0이 작성했으며, 이 모델은 약 2일 동안 ~1,500개 파일의 C++/Metal 코드베이스에서 ~20개의 코딩 에이전트를 오케스트레이션했습니다. 전체 보고서를 보려면 클릭하세요.</details>

단일 개발자에게 이 도구는 좋은 조회 가속기(lookup accelerator)입니다. 하지만 *오케스트레이션된 플릿(orchestrated fleet)*에게는 핵심적인 역할을 합니다: 리서치 비용을 절반으로 줄였고, 낭비되는 작업 전에 작업을 두 번이나 재지정했으며, 최소한 하나의 사일런트-다이버전스(silent-divergence) 배포 버그를 방지했고, 코드 품질 관리(code-quality hygiene)를 희망 사항에서 태스크별 기계적 게이트로 전환했습니다. 전체 워크플로우는 ~2배; 조회당은 10–25배; 그리고 한 번의 호출이 세션의 나머지 도구들이 합친 것보다 더 가치 있었던 두 순간을 만들었습니다.

— 보고서의 결론(the report's bottom line)

필드 리포트: ripwire가 대규모 다중 에이전트 코딩 참여에 기여한 바

배경 설명(Context): 두 일에 걸쳐 ~1,500개 파일의 C++/Metal 코드베이스를 지휘하는 약 20개의 순차적/병렬 코딩 에이전트를 관리한 하나의 오케스트레이션 세션 — 심층 아키텍처 감사 후, 14가지 태스크 기능 웨이브(새 서브시스템, 측정 인프라, 검색-아카이브 마이그레이션)를 거쳐 검증된 전면 배포 전환으로 마무리되었습니다. 모든 에이전트는 오리엔테이션을 위해 ripwire로 시작하고 품질 게이트로 끝내도록 지시받았습니다.

주요 수치(The headline numbers)

감사/연구 단계 전체 토큰 지출의 약 절반을 절감했습니다. 이는 운영자의 전 단계 추정치이며, 연구 에이전트가 수행한 모든 작업(일반 파일 읽기 포함)을 포함하므로 임의로 선택된 것이 아니라 보수적인 수치입니다. 아래에 명시된 호출당 계수는 훨씬 가파릅니다: 단일 문서 검색(doc-recall) 호출만으로 164KB 규모의 기획 문서를 약 6K 토큰(~25배)으로 처리했으며, 도구를 활용하여 작업을 시작한 에이전트는 유사한 질문에 대해 단순 읽기 전개(raw read fan-outs)를 수행한 에이전트보다 도구 호출 수 측면에서 약 30–40% 더 효율적이었습니다.
단일 호출로 두 가지 작업의 방향이 변경되었습니다. 한 작업은 팀이 프로덕션 환경에 있다고 믿었던 조향(steering) 동작을 활성화하도록 지정되었으나, --callers 질의는 생산 환경 호출자가 0개임을 반환하여 해당 작업을 실제 격차(해당 동작에 필요한 데이터 제공자가 어디에도 연결되지 않았음)로 재지정했습니다. 또 다른 작업은 광범위하게 공유되는 계산을 리팩토링했는데, --edit-check는 6개의 호출 사이트 중 5개를 호환되지 않는 것으로 표시했습니다. 이 사이트들은 일반적인 텍스트 검색이 놓쳤던 부분으로, 해당 기능이 활성화된 날에 달리 경로에서 조용히 벗어나 있다가 몇 달 후 설명할 수 없는 시각적 버그로 나타날 뻔했던 결함들이었습니다.
약 15개의 구현 에이전트에 걸쳐 수십 개의 실제 코드 품질 결함이 수정되었고, 면제되지는 않았습니다. 이 모든 것은 각 에이전트가 '완료되었다고 생각할 때' --quality-delta를 통해 포착되었습니다. 여기에는 480토큰의 중복 루틴, 공유 RNG 유틸리티의 네 번째 사적 복사본, 수동으로 복제된 비용 함수, 부호가 반전된 거의 동일한 두 개의 함수(한 경계에서는 정확하지만 다른 쪽에서는 조용히 잘못됨), 형제 스위트 전반에 걸친 테스트 피처 중복, 그리고 두 번째 작업을 은밀하게 흡수한 함수 등이 포함됩니다. 이 결함들 중 어느 것도 테스트를 통과하지 못했을 것이 아닙니다. 이 모든 것은 고속의 다중 에이전트 개발 과정에서 코드베이스를 부식시키는 침전물입니다. 이 게이트(gate) 덕분에 제거하는 것이 영웅적인 일이 아니라 일상적인 일이 되었습니다.

가치가 집중된 곳

방향성 및 검색(Orientation and recall) (토큰의 승리). 순위 기반 시그니처 작업 방향 설정과 섹션 단위 문서 검색을 통해 에이전트가 파일 덤프가 아닌 답변에서 시작하도록 했습니다. 계획 문서를 대상으로 한 검색은 오케스트레이터가 가장 많이 사용한 동사였으며, 감사(audit)의 전체 틀은 두 번의 호출에서 나왔습니다.
계약 검사기(The contract checker) (배포 버그 예방책). 위에서 언급된 6개 중 5가지 케이스를 넘어, --edit-check는 웨이브 전반에 걸친 모든 공개 심볼 변경에 대해 거의 무료로 계약 증명(proof-of-contract)을 제공했습니다. 이는 그렇지 않으면 에이전트 속도에서는 단순히 발생하지 않는 검증입니다.
프로토콜로서의 품질 게이트(The quality gate as a protocol). 측정 가능한 효과는 단 하나의 포착 사례가 아니었습니다. 맥락을 공유하지 않은 15개의 서로 다른 에이전트들이 모두 동일한 "수정하거나 서면 이유를 제시"하는 규율로 수렴했으며, 이 감사 기록(acknowledgments ledger)은 작업 전반에 걸쳐 유지되었습니다. 비감독 오케스트레이션은 보통 품질 누수를 일으키지만, 여기서는 그 누수 확인이 기계화되었습니다.
영구 노트(Persistent notes). 에이전트들은 웨이브 중간에 심볼에 "주의 사항" 노트를 고정했습니다(호출자 연결법칙, 무장 규칙 불변성). 이는 나중에 작동하는 에이전트들의 조회에서 자동으로 표면화되었으며, 결코 만난 적 없는 맥락 사이의 저렴한 제도적 기억을 제공합니다.

진정한 경계(The honest boundary)

이번 참여(engagement)에서 나온 가장 깊은 발견들은 도구 자체에서 온 것이 아니었습니다. 구조적 용량 한계(structural capacity ceiling), 잘못 유도된 상수(mis-derived constant), 1 ulp의 부동소수점 재연관 드리프트(floating-point re-association drift), 그리고 시드 키잉 버그(seed-keying bug)는 모두 *에이전트들이 자체 구축한 측정(measurement)*을 통해 발견되었습니다. — 전체 데이터 필드를 사용한 기준 작업 트리 차이 분석, 다중 팔 할당 스윕(multi-arm attribution sweeps), 퍼널(funnels) 등이었습니다. 이 도구는 정직성과 방향성을 위한 '바닥(floor)'일 뿐이며, 측정 설계(measurement design)를 대체할 수는 없습니다.
알려진 거짓 양성 모드(false-positive mode)로, 자체 문서에서 처리됨: 계약 검사기(contract checker)의 arity 휴리스틱은 기본값으로 설정된 후행 매개변수(defaulted trailing parameters)에 대해 과도하게 카운트합니다 (한 작업에서는 'incompatible=18'이 나왔으나 모두 정상적이었습니다). 도구 자체의 신뢰 보정 노트(trust-calibration notes)는 이 경우 정확히 컴파일하여 확인하라고 안내하며, 이를 따른 에이전트는 아무것도 잃지 않았습니다.
광범위하고 일반적인 개념적 질의(conceptual queries)의 경우, 단순한 grep 및 읽기 방식이 여전히 가끔 우위를 점했습니다. 이는 도구 자체가 특정 기술적 질문에 강점을 가진다는 자체 안내와 일치합니다.

결론적으로(Bottom line)

단일 개발자에게 이 도구는 좋은 조회 가속기입니다. 하지만 *오케스트레이션된 군집(orchestrated fleet)*에게는 핵심적인 역할을 합니다: 연구 비용을 절반으로 줄였고, 낭비되는 작업을 두 번이나 방향 전환시켰으며, 최소한 하나의 조용한 발산 버그(silent-divergence shipped bug)가 배포되는 것을 막았고, 코드 품질 위생(code-quality hygiene)을 희망이 아닌 작업별 기계적 게이트로 바꾸어 놓았습니다. 전체 워크플로우는 약 2배; 조회당은 10~25배; 그리고 한 번의 호출이 세션 동안 사용된 모든 도구 조합보다 더 가치 있었던 순간도 있었습니다.

</details>

모델 자체 보고서 중 하나의 참여(engagement)에 대한 내용이며, 버전 0.5 이전의 것입니다. 통제된 측정은 docs/EVALS.md에서 확인할 수 있습니다.

</details> <details> <summary>50년간의 소프트웨어 공학 결과와 지난달 연구 내용. 49개의 저장소(repositories)와 71편의 논문이 정리되었습니다 — McCabe (1976)부터 지난 두 달 동안 발표된 일곱 편까지입니다. [docs/LINEAGE.md](docs/LINEAGE.md)의 각 행은 얻은 교훈과 해당 파일 위치를 명시합니다.</summary>

그 옆에는 아무런 기여를 하지 않은 237개의 도구에 대한 레이블이 지정된 설문조사 결과가 있습니다. 두 세트는 구조적으로 분리되어 있어 중첩되기보다는 추가됩니다. 즉, 하나의 교훈을 준 도구는 절대 두 번 계산되지 않습니다.

두 부분 모두 핵심적이며(load-bearing), 서로 다른 역할을 수행합니다. 확립된 결과들이 이 품질 렌즈를 신뢰할 수 있게 만듭니다: 복잡도에 대한 McCabe (1976), 볼륨에 대한 Halstead (1977), 용어 특이성에 대한 Spärck Jones (1972), churn(변동성)에 대한 Nagappan & Ball. 50년간의 반복 검증은 이것들이 의견이 아님을 의미하며, 사용자의 코드를 측정하는 도구는 살아남은 것들을 기반으로 구축되어야 합니다.

최근 연구가 이 자료를 최신으로 만듭니다: 접힌 논문 중 17개는 2026년 출판되었고, 7개는 지난 두 달에, 3개는 지난 30일 동안 발표되었습니다 (날짜 기준은 2026-09-08이며, 모든 행에는 arXiv ID가 포함되어 있어 주장이 분위기에 의존하는 것이 아니라 검증 가능합니다). 코딩 에이전트를 위한 검색(Retrieval for coding agents), 컨텍스트 압축 비용(context-compression cost), 위약 대조 국소화(placebo-controlled localization)와 관련된 문헌은 수십 년 전의 것이 아니라 몇 달 전의 것이며, 여러 행들은 논문 발표 후 몇 주 만에 접혔습니다.

어느 한쪽만으로는 충분하지 않습니다. 클래식한 것들만을 기반으로 구축된 도구는 에이전트가 무엇을 필요로 하는지 알지 못할 것이며, 지난달의 프리프린트(preprints)만을 기반으로 구축된 도구는 그 밑바탕에 아무것도 없을 것입니다. 그리고 가장 새로운 행은 이곳에서 테스트했을 때 실패한 결과이며—이것이 기록하는 목적입니다. 세 가지 수치 모두 매 실행마다 test/readmedriftcheck.sh를 통해 해당 문서 자체의 표에서 재파생됩니다. 이 페이지와 그 표가 불일치하면 실패하기 때문에, 주장이 조용히 변동(drift)할 수 없습니다. 행별 원장 기록은 docs/LINEAGE.md입니다.

언어: Rust · C++ · Objective-C/C++ · C · Metal · CUDA · Python · Go · Swift · TypeScript · JavaScript · Java · Ruby · PHP · Lua · Elixir · Dart · Kotlin · GDScript · Clojure · Bash · C# · JSON · TOML · YAML · Markdown — 언어 지원 및 제한 참조.

최신 버전: 0.6.8 — 더 완전한 첫 답변과 적은 잘못된 간선(false edges). 릴리스 노트 ·
발표 자료 · 변경 로그 — 여기에 언급된 기여자들에게 감사드리며, 이번 릴리스는 그들의 공헌이 주를 이룹니다.

<img src="https://raw.githubusercontent.com/redhat-et/ripwire/HEAD/docs/assets/no-deps.svg" alt="No API key. No embeddings. No index server. No daemon." width="470"> <details> <summary>단일 프로세스, 서버 불필요 — 측정된 그래프 데이터베이스 MCP 서버 대비 **6.6 MB**를 사용하여 이 저장소를 **0.25초** 만에 인덱싱하며, 해당 서버는 **46.8초**와 **391 MB**가 소요됩니다. 또한, 따뜻한(warm) 쿼리는 **197ms**로 응답하는 반면, 해당 서버는 **1,082ms**가 소요됩니다.</summary>

Django, Webpack 및 이 저장소 전반에 걸쳐 매칭된 48개 질문을 기준으로 측정되었습니다. 세 가지 모두에서 Ripwire는 해당 서버 대비 0.25–0.45초 및 6.6–16.5 MB로 인덱싱하며, 이는 해당 서버의 23–52초 및 391–623 MB와 비교됩니다. 전체 방법론, 개별 승리 사례 및 포함된 손실 사례는 선도적인 그래프 데이터베이스 코드 컨텍스트 MCP 서버 대비와 docs/EVALS.md에 있습니다.

</details> <details> <summary>단일 바이너리, 오프라인 — 그리고 동일한 코드가 발견하는 모든 에이전트(agent)에게 스킬을 활성화합니다: Claude Code · Codex · Cursor · Windsurf · Gemini · opencode · aider</summary>

Rip'n Fast. 더 적은 토큰으로, 더 나은 코드.

요약

핵심 포인트

Rip'n Fast. 더 적은 토큰, 더 나은 코드.

댓글

Rip'n Fast. 더 적은 토큰, 더 나은 코드.