<div id="readability-page-1" class="page"><div data-pagefind-body="">    <p><a href="https://news.hada.io/topic?id=33183" rel="nofollow noopener noreferrer" target="_blank">GeekNews에서 zg(zvec-grep)</a>를 봤습니다. Alibaba Qwen 팀이 공개한 로컬 우선 검색 레이어로, ripgrep + BM25 + 벡터 검색을 하나로 묶고 MCP로 코딩 에이전트에 붙습니다. 제 환경에는 한국어 마크다운 수백 개짜리 개인 monorepo가 있고 에이전트가 이 문서를 검색하는 일이 잦아서, “정확한 키워드를 모르는 질문”에서 grep이 헛도는 문제를 풀어줄 후보로 보였습니다.</p><p>반나절 실측한 결론은 <strong>미채택</strong>입니다. 같은 30문제에서 zg의 최고 성적은 19/30이었고, <strong>에이전트가 원래 하던 검색(grep을 쓰는 LLM)은 30/30</strong>이었습니다. 이 글은 그 격차가 어디서 오는지와, 소규모 파일럿의 만점이 어떻게 사람을 속이는지에 대한 기록입니다.</p>
<section><h2 id="zgzvec-grep는-무엇인가">zg(zvec-grep)는 무엇인가<a href="#zgzvec-grep는-무엇인가"><span data-pagefind-ignore="">#</span></a></h2><p><a href="https://github.com/zvec-ai/zvec-grep" rel="nofollow noopener noreferrer" target="_blank">zg</a>는 “의미로 넓게 찾고 → 관련도로 좁히고 → 정확히 검증”하는 흐름을 도구 하나가 맡는 로컬 검색 레이어입니다. <code>zg index</code>로 인덱싱하면 마크다운은 헤딩 구조를 보존한 조각으로, 코드는 심볼 단위로 임베딩되고, 검색 시 BM25 어휘 랭킹과 벡터 유사도를 <a href="https://github.com/zvec-ai/zvec-grep/blob/main/docs/05-architecture.md" rel="nofollow noopener noreferrer" target="_blank">RRF로 융합</a>합니다. 에이전트에는 <code>zvec_grep_search</code>라는 MCP 툴 하나로 노출되고, 파일·인덱스·모델이 전부 로컬에 남습니다.</p><p>공식 벤치마크(SWE-QA-Bench)에서는 툴 호출과 입력 토큰을 절반으로 줄이면서 judge 점수가 올랐다고 합니다. 다만 <strong>그 수치는 전부 원격 임베딩(자사 클라우드 API) 기준</strong>이고, 제 문서는 개인 데이터라 로컬 모델만 쓸 수 있습니다. 로컬 소형 모델의 한국어 검색 품질은 어디에도 실측이 없어서 직접 재야 했습니다.</p></section>
<section><h2 id="임베딩-모델을-한-단계씩-올려가며-본-91파일-파일럿">임베딩 모델을 한 단계씩 올려가며 본 91파일 파일럿<a href="#임베딩-모델을-한-단계씩-올려가며-본-91파일-파일럿"><span data-pagefind-ignore="">#</span></a></h2><p>임베딩 모델 선택 가이드(<a href="https://github.com/zvec-ai/zvec-grep/blob/main/docs/07-embedding.md" rel="nofollow noopener noreferrer" target="_blank">docs/07</a>)는 “필요한 언어를 커버하는 가장 작은 모델로 시작해 한 단계씩 올리라”고 권합니다. 그대로 모델 세 개를 작은 것부터 평가했습니다. 시작 전에 인덱싱 범위부터 좁혔는데, zg는 텍스트/마크다운을 기본 256MiB까지 통째로 받아들여서 자막 덤프 같은 대용량 텍스트는 glob으로 제외하지 않으면 인덱싱 시간이 몇 배로 뜁니다.</p><p>파일럿은 문서 모듈 2개(91파일)만 인덱싱하고, “질문의 표현과 문서의 표현이 다른” 시맨틱 갭 쿼리 6개로 zg 하이브리드 검색과 단순 키워드 grep을 비교했습니다. 예를 들어 “후보 중 주말에 예약이 안 되는 식당”의 답은 문서에 “전화 전용”이라고 적혀 있어서 질문 어휘로 grep하면 닿지 않습니다. 정답 문서를 미리 정해두고 상위 5개 안에 들면 적중으로 채점했습니다.</p>




























<table><thead><tr><th>모델</th><th>방식</th><th>인덱싱(91파일)</th><th>hit@5</th></tr></thead><tbody><tr><td><code>potion-multilingual-128m</code></td><td>정적 룩업 (Model2Vec)</td><td>CPU 21초</td><td>3/6</td></tr><tr><td><code>multilingual-e5-small</code></td><td>ONNX 소형 transformer</td><td>2.5분, CPU 부하 중간</td><td>5/6</td></tr><tr><td><code>embeddinggemma-300m</code></td><td>GGUF, Metal GPU</td><td>4.5분, CPU 10%</td><td><strong>6/6</strong></td></tr></tbody></table><p>정적 모델은 grep이 0건인 문제를 뚫어주긴 했지만 한국어 의미 이해가 얕아서, 대출 비교 질문에 무관한 문서를 1위로 올리는 오답을 냈습니다. 소형 transformer로 올리자 어휘가 거의 안 겹치는 문제가 1위로 잡혔고, <code>embeddinggemma-300m</code>은 여섯 문제를 전부 맞혔습니다. Metal GPU로 도는 덕에 발열도 없었습니다. 여기까지만 보면 도입 결정은 끝난 것처럼 보였습니다.</p></section>
<section><h2 id="862파일로-넓히자-66이-1930으로-떨어졌다">862파일로 넓히자 6/6이 19/30으로 떨어졌다<a href="#862파일로-넓히자-66이-1930으로-떨어졌다"><span data-pagefind-ignore="">#</span></a></h2><p>도입을 결정하려던 참에 “6문제로는 표본이 너무 적지 않나”는 지적을 받았습니다. 인덱스를 monorepo 전체(자막 덤프 제외 862파일, 인덱스 조각 1만 개)로 넓히고, 쿼리를 6가지 유형에 5개씩 30개로 늘렸습니다. 표현 불일치, 비교/관계, 크로스 모듈 종합, 한국어 질문→코드 찾기, 날짜/일정, 그리고 <strong>grep이 이겨야 정상인 정확 키워드 대조군</strong>입니다. 정답 문서는 전부 사전에 정해두고 hit@5와 MRR로 기계 채점했습니다.</p><p>91파일에서 6/6이던 <code>embeddinggemma-300m</code>이 <strong>862파일에서는 19/30</strong>으로 떨어졌습니다. 문서가 적을수록 정답이 상위에 오기 쉽다는 사실이 그대로 드러난 것이고, 파일럿 만점을 믿고 도입했다면 틀린 결정이었습니다. 유형별로 문서 질문은 25문제 중 19개로 버텼지만, 한국어 질문으로 코드 파일을 찾는 유형은 5문제 전멸이었고, 본문에 분명히 존재하는 고유명사 키워드를 던진 대조군 문제 하나도 놓쳤습니다. 한국어 FTS 토크나이징이 의심되는 지점입니다.</p></section><section><h2 id="진짜-베이스라인은-grep이-아니라-grep을-쓰는-llm">진짜 베이스라인은 grep이 아니라 “grep을 쓰는 LLM”<a href="#진짜-베이스라인은-grep이-아니라-grep을-쓰는-llm"><span data-pagefind-ignore="">#</span></a></h2><p>확장 평가를 돌리던 중에 본질적인 질문이 나왔습니다. <strong>“zg 없이 에이전트가 원래 하던 검색으로는 몇 개나 맞추나?”</strong> 처음의 비교군인 “키워드 하나 뽑아 grep 한 번”(5/30)은 최저선일 뿐, 실제 에이전트는 키워드를 여러 개 시도하고 파일명과 README를 읽으며 방향을 수정합니다.</p><p>그래서 대화 컨텍스트가 없는 서브에이전트 30개를 문제당 하나씩 띄우고, zg 사용을 금지한 채 grep/glob/read만으로 검색하게 했습니다. 정답 목록 디렉터리는 접근을 차단했고, 각자 후보 파일 5개와 도구 호출 수를 보고하게 했습니다.</p>














































<table><thead><tr><th>검색 방식</th><th>hit@5</th><th>MRR</th><th>쿼리당 비용</th><th>인덱싱</th></tr></thead><tbody><tr><td><strong>에이전트 네이티브 (LLM + grep 루프)</strong></td><td><strong>30/30</strong></td><td><strong>0.88</strong></td><td>평균 5.2회 호출, 약 26k 토큰</td><td>불필요</td></tr><tr><td>zg <code>embeddinggemma-300m</code></td><td>19/30</td><td>0.35</td><td>1회 호출</td><td>4분 40초</td></tr><tr><td>zg <code>multilingual-e5-small</code></td><td>15/30</td><td>0.29</td><td>1회 호출</td><td>8분 41초</td></tr><tr><td>zg <code>potion-multilingual-128m</code></td><td>9/30</td><td>0.21</td><td>1회 호출</td><td><strong>47초</strong></td></tr><tr><td>단순 키워드 grep 1회</td><td>5/30</td><td>–</td><td>1회 호출</td><td>불필요</td></tr></tbody></table><p>네이티브 검색은 30문제 중 24개에서 정답을 1순위로 냈고, 시맨틱 갭 문제도 한국어→코드 문제도 전부 통과했습니다. 이번 비교는 “임베딩 vs 키워드”가 아니라 “<strong>3억 파라미터 임베딩 모델의 원샷 vs 프론티어급 LLM의 반복 탐색</strong>”이었습니다. “노후 대비 계좌”라는 질문을 연금·세액공제라는 문서 어휘로 옮기는 일을 네이티브 쪽에서는 검색하는 LLM 자신이 수행합니다. 체급이 다르니 결과도 그렇게 나옵니다.</p><p>제 monorepo의 특성도 컸습니다. 번호 붙인 문서 체계, 목차 역할을 하는 README, 비교 대상 둘이 파일명에 들어가는 이름 규칙이 <strong>사람이 미리 만들어둔 시맨틱 인덱스</strong>로 작동해서, 에이전트가 벡터 인덱스 없이도 의미로 길을 찾았습니다. 대신 쿼리당 5.2회 호출에 2만 6천 토큰이 듭니다. zg의 제안은 그 비싼 LLM 탐색을 싼 모델로 대체하자는 것인데, 30문제 중 11개를 놓치는 수준이면 빗나간 문제마다 네이티브 검색으로 다시 찾아야 해서 아낀 비용이 도로 나갑니다.</p></section>
<section><h2 id="그럼에도-zg가-유리한-환경은-따로-있다">그럼에도 zg가 유리한 환경은 따로 있다<a href="#그럼에도-zg가-유리한-환경은-따로-있다"><span data-pagefind-ignore="">#</span></a></h2><p>공식 벤치마크가 돌아간 곳은 matplotlib·django 같은 수십만 줄 코드베이스와 10만 문서 웹 코퍼스입니다. README를 따라 길을 찾을 수 없고 반복 grep의 시행착오 비용이 폭발하는 곳이고, 거기서 zg의 주장은 품질 향상이 아니라 “<strong>같은 품질을 토큰·호출 40~50% 절감으로</strong>”입니다. 하루 수천 쿼리 규모라면 그 절감은 실제 돈입니다.</p><p>정리되지 않은 텍스트 더미, 영어/코드 중심 코퍼스라는 조건도 zg의 임베딩·FTS가 튜닝된 방향과 일치합니다. 제 환경은 전부 반대였습니다. 862파일로 작고, 문서 체계가 잘 잡혀 있고, 한국어이고, 검색하는 에이전트가 프론티어급이죠.</p><p>zg 공식 문서도 <a href="https://github.com/zvec-ai/zvec-grep" rel="nofollow noopener noreferrer" target="_blank">“정확한 키워드 검색으로 충분한 작업에는 이득이 제한적”</a>이라고 명시합니다. 재평가 조건은 자막·수집 원문처럼 정리되지 않은 대량 텍스트를 검색 대상에 넣고 싶어질 때, 또는 zg의 한국어 처리가 성숙했을 때입니다. 쿼리 30개와 채점 스크립트를 한 세트로 남겨뒀으니 그대로 재실행하면 됩니다.</p></section>  </div></div>

Monologg Blog

GeekNews에서 zg(zvec-grep)를 봤습니다. Alibaba Qwen 팀이 공개한 로컬 우선 검색 레이어로, ripgrep + BM25 + 벡터 검색을 하나로 묶고 MCP로 코딩 에이전트에 붙습니다. 제 환경에는 한국어 마크다운 수백 개짜리 개인 monorepo가 있고 에이전트가 이 문서를 검색하는 일이 잦아서, "정확한 키워드를 모르는 질문"에서 grep이 헛도는 문제를 풀어줄 후보로 보였습니다.
반나절 실측한 결론은 미채택입니다. 같은 30문제에서 zg의 최고 성적은 19/30이었고, 에이전트가 원래 하던 검색(grep을 쓰는 LLM)은 30/30이었습니다. 이 글은 그 격차가 어디서 오는지와, 소규모 파일럿의 만점이 어떻게 사람을 속이는지에 대한 기록입니다.
zg(zvec-grep)는 무엇인가
zg는 "의미로 넓게 찾고 → 관련도로 좁히고 → 정확히 검증"하는 흐름을 도구 하나가 맡는 로컬 검색 레이어입니다. zg index로 인덱싱하면 마크다운은 헤딩 구조를 보존한 조각으로, 코드는 심볼 단위로 임베딩되고, 검색 시 BM25 어휘 랭킹과 벡터 유사도를 RRF로 융합합니다. 에이전트에는 zvec_grep_search라는 MCP 툴 하나로 노출되고, 파일·인덱스·모델이 전부 로컬에 남습니다.
공식 벤치마크(SWE-QA-Bench)에서는 툴 호출과 입력 토큰을 절반으로 줄이면서 judge 점수가 올랐다고 합니다. 다만 그 수치는 전부 원격 임베딩(자사 클라우드 API) 기준이고, 제 문서는 개인 데이터라 로컬 모델만 쓸 수 있습니다. 로컬 소형 모델의 한국어 검색 품질은 어디에도 실측이 없어서 직접 재야 했습니다.
임베딩 모델을 한 단계씩 올려가며 본 91파일 파일럿
임베딩 모델 선택 가이드(docs/07)는 "필요한 언어를 커버하는 가장 작은 모델로 시작해 한 단계씩 올리라"고 권합니다. 그대로 모델 세 개를 작은 것부터 평가했습니다. 시작 전에 인덱싱 범위부터 좁혔는데, zg는 텍스트/마크다운을 기본 256MiB까지 통째로 받아들여서 자막 덤프 같은 대용량 텍스트는 glob으로 제외하지 않으면 인덱싱 시간이 몇 배로 뜁니다.
파일럿은 문서 모듈 2개(91파일)만 인덱싱하고, "질문의 표현과 문서의 표현이 다른" 시맨틱 갭 쿼리 6개로 zg 하이브리드 검색과 단순 키워드 grep을 비교했습니다. 예를 들어 "후보 중 주말에 예약이 안 되는 식당"의 답은 문서에 "전화 전용"이라고 적혀 있어서 질문 어휘로 grep하면 닿지 않습니다. 정답 문서를 미리 정해두고 상위 5개 안에 들면 적중으로 채점했습니다.
모델
방식
인덱싱(91파일)
hit@5
potion-multilingual-128m
정적 룩업 (Model2Vec)
CPU 21초
3/6
multilingual-e5-small
ONNX 소형 transformer
2.5분, CPU 부하 중간
5/6
embeddinggemma-300m
GGUF, Metal GPU
4.5분, CPU 10%
6/6
정적 모델은 grep이 0건인 문제를 뚫어주긴 했지만 한국어 의미 이해가 얕아서, 대출 비교 질문에 무관한 문서를 1위로 올리는 오답을 냈습니다. 소형 transformer로 올리자 어휘가 거의 안 겹치는 문제가 1위로 잡혔고, embeddinggemma-300m은 여섯 문제를 전부 맞혔습니다. Metal GPU로 도는 덕에 발열도 없었습니다. 여기까지만 보면 도입 결정은 끝난 것처럼 보였습니다.
862파일로 넓히자 6/6이 19/30으로 떨어졌다
도입을 결정하려던 참에 "6문제로는 표본이 너무 적지 않나"는 지적을 받았습니다. 인덱스를 monorepo 전체(자막 덤프 제외 862파일, 인덱스 조각 1만 개)로 넓히고, 쿼리를 6가지 유형에 5개씩 30개로 늘렸습니다. 표현 불일치, 비교/관계, 크로스 모듈 종합, 한국어 질문→코드 찾기, 날짜/일정, 그리고 grep이 이겨야 정상인 정확 키워드 대조군입니다. 정답 문서는 전부 사전에 정해두고 hit@5와 MRR로 기계 채점했습니다.
91파일에서 6/6이던 embeddinggemma-300m이 862파일에서는 19/30으로 떨어졌습니다. 문서가 적을수록 정답이 상위에 오기 쉽다는 사실이 그대로 드러난 것이고, 파일럿 만점을 믿고 도입했다면 틀린 결정이었습니다. 유형별로 문서 질문은 25문제 중 19개로 버텼지만, 한국어 질문으로 코드 파일을 찾는 유형은 5문제 전멸이었고, 본문에 분명히 존재하는 고유명사 키워드를 던진 대조군 문제 하나도 놓쳤습니다. 한국어 FTS 토크나이징이 의심되는 지점입니다.
진짜 베이스라인은 grep이 아니라 "grep을 쓰는 LLM"
확장 평가를 돌리던 중에 본질적인 질문이 나왔습니다. "zg 없이 에이전트가 원래 하던 검색으로는 몇 개나 맞추나?" 처음의 비교군인 "키워드 하나 뽑아 grep 한 번"(5/30)은 최저선일 뿐, 실제 에이전트는 키워드를 여러 개 시도하고 파일명과 README를 읽으며 방향을 수정합니다.
그래서 대화 컨텍스트가 없는 서브에이전트 30개를 문제당 하나씩 띄우고, zg 사용을 금지한 채 grep/glob/read만으로 검색하게 했습니다. 정답 목록 디렉터리는 접근을 차단했고, 각자 후보 파일 5개와 도구 호출 수를 보고하게 했습니다.
검색 방식
hit@5
MRR
쿼리당 비용
인덱싱
에이전트 네이티브 (LLM + grep 루프)
30/30
0.88
평균 5.2회 호출, 약 26k 토큰
불필요
zg embeddinggemma-300m
19/30
0.35
1회 호출
4분 40초
zg multilingual-e5-small
15/30
0.29
1회 호출
8분 41초
zg potion-multilingual-128m
9/30
0.21
1회 호출
47초
단순 키워드 grep 1회
5/30
–
1회 호출
불필요
네이티브 검색은 30문제 중 24개에서 정답을 1순위로 냈고, 시맨틱 갭 문제도 한국어→코드 문제도 전부 통과했습니다. 이번 비교는 "임베딩 vs 키워드"가 아니라 "3억 파라미터 임베딩 모델의 원샷 vs 프론티어급 LLM의 반복 탐색"이었습니다. "노후 대비 계좌"라는 질문을 연금·세액공제라는 문서 어휘로 옮기는 일을 네이티브 쪽에서는 검색하는 LLM 자신이 수행합니다. 체급이 다르니 결과도 그렇게 나옵니다.
제 monorepo의 특성도 컸습니다. 번호 붙인 문서 체계, 목차 역할을 하는 README, 비교 대상 둘이 파일명에 들어가는 이름 규칙이 사람이 미리 만들어둔 시맨틱 인덱스로 작동해서, 에이전트가 벡터 인덱스 없이도 의미로 길을 찾았습니다. 대신 쿼리당 5.2회 호출에 2만 6천 토큰이 듭니다. zg의 제안은 그 비싼 LLM 탐색을 싼 모델로 대체하자는 것인데, 30문제 중 11개를 놓치는 수준이면 빗나간 문제마다 네이티브 검색으로 다시 찾아야 해서 아낀 비용이 도로 나갑니다.
그럼에도 zg가 유리한 환경은 따로 있다
공식 벤치마크가 돌아간 곳은 matplotlib·django 같은 수십만 줄 코드베이스와 10만 문서 웹 코퍼스입니다. README를 따라 길을 찾을 수 없고 반복 grep의 시행착오 비용이 폭발하는 곳이고, 거기서 zg의 주장은 품질 향상이 아니라 "같은 품질을 토큰·호출 40~50% 절감으로"입니다. 하루 수천 쿼리 규모라면 그 절감은 실제 돈입니다.
정리되지 않은 텍스트 더미, 영어/코드 중심 코퍼스라는 조건도 zg의 임베딩·FTS가 튜닝된 방향과 일치합니다. 제 환경은 전부 반대였습니다. 862파일로 작고, 문서 체계가 잘 잡혀 있고, 한국어이고, 검색하는 에이전트가 프론티어급이죠.
zg 공식 문서도 "정확한 키워드 검색으로 충분한 작업에는 이득이 제한적"이라고 명시합니다. 재평가 조건은 자막·수집 원문처럼 정리되지 않은 대량 텍스트를 검색 대상에 넣고 싶어질 때, 또는 zg의 한국어 처리가 성숙했을 때입니다. 쿼리 30개와 채점 스크립트를 한 세트로 남겨뒀으니 그대로 재실행하면 됩니다.

zvec-grep 실측기: 시맨틱 검색은 에이전트의 grep을 이기지 못했다

댓글