Grep만 있으면 충분할까? 에이전트 검색을 위한 Grep vs 벡터 검색 (Vector Retrieval)

무엇인가 (What): "Is Grep All You Need?" 연구는 실제 grep 도구와 벡터 검색 (Vector-search) 도구를 동일한 에이전트 (Agent)에 연결하고, 116개의 LongMemEval 질문을 실행합니다. 이를 통해 프롬프트 (Prompt)에 무관한 컨텍스트 (Context)가 점진적으로 추가될 때 각 검색 방식이 어떻게 버티는지 측정합니다.

왜 하는가 (Why): 벡터 검색 (Vector retrieval)은 수년간 에이전트 검색 (Agentic search)의 기본값이었지만, 임베딩 (Embedding) 단계, 벡터 저장소 (Vector store), 그리고 ANN 인덱스 (ANN index)를 위한 비용을 지불해야 합니다. 이러한 비용은 의미론적 일치 (Semantic match)가 실제로 제 역할을 할 때만 가치가 있습니다. 만약 grep이 정확도 면에서 비슷하면서 노이즈 (Noise)에 더 견고하다면, 인프라의 한 계층 전체가 선택 사항이 될 수 있습니다.

이전 방식과의 차이 (vs prior): 이전의 RAG 벤치마크는 독립적인 검색 품질(라벨링된 골드 세트에 대한 recall@k)을 기준으로 검색 알고리즘을 비교했습니다. 반면, 이 논문은 에이전트 루프 (Agent loop) 내부에서 알고리즘을 측정하며, 여기서 도구 호출 (Tool-calling) 스타일과 하네스 (Harness) 설계가 알고리즘 자체보다 더 중요하다는 것이 밝혀졌습니다.

인용구를 찾는 상황을 생각해 보세요 — PDF에서 Ctrl-F를 사용하는 것과 사서에게 "비슷한 느낌"의 책을 찾아달라고 요청하는 것의 차이입니다.

질의 (THE QUERY) │ ┌─────────────┴─────────────┐ │ │ ┌───────▼────────┐ ┌────────▼───────┐ │ Ctrl-F │ │ Librarian │ │ (grep) │ │ (vector) │ └───────┬────────┘ └────────┬───────┘ │ │ types literal phrase embeds query, finds scans every line top-k "feels close" │ │ ▼ ▼ ✓ stable as ✗ accuracy drops as noise grows noise grows (matches are local) (distance shifts) the document store = the PDF or the library shelf grep tool = Ctrl-F — the model types a literal phrase and gets exact matches vector retrieval tool = the librarian — the model hands over a vector that "feels like" the question, gets the k nearest books irrelevant context (noise) = unrelated chapters added to the PDF, or random books shoved onto the shelf the agent harness = how the model decides which tool to call, when to stop, and what to do with the chunks

간단 용어 사전
에이전트 검색 (Agentic search) — LLM이 검색된 청크 (Chunks)를 한 번에 전달받는 대신, 검색 도구를 반복적으로 호출하는 검색 패턴입니다.

모델은 무엇을 검색할지, 언제 다시 검색할지, 그리고 언제 멈출지를 결정합니다. 벡터 검색 (Vector retrieval) — 모든 문서 청크 (Chunks)를 고정된 차원의 벡터로 임베딩 (Embed)하고, 쿼리 (Query)도 동일한 방식으로 임베딩한 뒤, 코사인 유사도 (Cosine similarity) 또는 내적 (Dot-product) 유사도를 기준으로 상위 k개의 가장 가까운 청크를 반환합니다. 2023년 이후 "RAG"의 기본 방식입니다. Grep — 고전적인 Unix 도구로, 텍스트 파일 내에서 문자열 그대로의 부분 문자열 (Substrings) 또는 정규 표현식 (Regex) 패턴을 찾아냅니다. 에이전트 하네스 (Agent harness) 내부에서는 모델이 문자열 인자 (String argument)와 함께 호출할 수 있는 도구로 노출됩니다. LongMemEval — 에이전트의 메모리 및 검색 능력을 테스트하기 위해 설계된 116개 문항의 벤치마크 (Benchmark)로, 이전 대화 내용을 참조하거나, 멀티 홉 검색 (Multi-hop search)이 필요하거나, 노이즈에 의해 쉽게 묻힐 수 있는 작은 세부 사항에 의존하는 질문들로 구성됩니다. ANN — 근사 최근접 이웃 (Approximate Nearest Neighbour) — 재현율 (Recall)과 지연 시간 (Latency) 사이의 트레이드오프 (Trade-offs)를 대가로 벡터 검색을 빠르게 만드는 인덱스 (Indexes) 제품군 (HNSW, IVF, FAISS)입니다. 도구 호출 스타일 (Tool-calling style) — 하네스가 모델에 도구를 노출하는 방식 — 단일 실행 (Single shot) 대 반복적 (Iterative), 병렬 (Parallel) 대 직렬 (Serial), 구조화된 JSON (Structured-JSON) 대 자유 형식 (Free-form)을 의미합니다. 논문은 도구 뒤에 어떤 검색 알고리즘이 있는가보다 이 방식이 더 중요하다는 것을 발견했습니다. 소식: 2026년 5월 14일, "Is Grep All You Need?" 논문 (arXiv:2605.15184)은 에이전트 검색에 대해 두 가지 실증적 실험을 수행했습니다. 첫 번째 실험은 문자열 그대로의 grep 도구와 벡터 검색 도구를 여러 플랫폼의 동일한 에이전트에 연결하고 116개의 LongMemEval 질문을 각각 실행했습니다. 테스트된 조건 전반에 걸쳐, grep은 일반적으로 벡터 검색보다 더 높은 정확도를 나타냈습니다. 두 번째 실험은 강건성 (Robustness)을 조사하기 위해 무관한 컨텍스트 (Context)를 점진적으로 주입했습니다. 저자들의 핵심 결론: 전체적인 성능은 검색 알고리즘 단독이 아니라, 에이전트 하네스 (Agent harness)와 도구 호출 스타일 (Tool-calling style)에 의해 좌우됩니다. Ctrl-F와 사서의 차이를 다시 떠올려 보십시오. 사용자가 "3분기 파리 사무소에 대해 보고서가 뭐라고 했지?"라고 물을 때, Ctrl-F 경로는 매우 문자 그대로 작동합니다. 'Paris'라는 문자열을 입력하면, 해당 문자열이 포함된 모든 줄을 가져와 주변 문장을 훑어보는 방식입니다.

사서(librarian) 방식은 의미론적 (semantic)입니다. 질문을 설명하면, 사서가 서가를 돌아다니며 "느낌이 비슷한" 세 권의 책을 건네주는 방식입니다. 서가가 깔끔하고 질문이 모호할 때(

그리고 top-k 절단(cutoff)이 예를 들어 k = 5로 고정되어 있다면, 만약 두 개의 방해 요소(distractors)가 두 개의 관련 청크(relevant chunks)보다 더 가깝게 위치하게 될 경우, 관련 청크들은 밀려나게 됩니다. 논문의 노이즈 스윕(noise sweep) 실험은 이를 구체적으로 보여줍니다. 노이즈가 증가함에 따라 애니메이션에서의 벡터 정확도(vector accuracy)는 약 71%에서 35%로 떨어지는 반면(예시), grep은 74% 근처에서 평탄하게 유지됩니다. grep은 주변 텍스트가 얼마나 존재하는지에 신경 쓰지 않습니다. 입력된 내용을 매칭하고 정확히 해당 구간(spans)을 반환할 뿐입니다. 이러한 취약성은 임베딩(embeddings)이라는 기술 자체의 결함이 아닙니다. 알고리즘은 깨끗한 서가를 가정하고 있는데, 시스템(harness)은 계속해서 무작위의 책들을 서가에 밀어 넣는 상황에서 발생하는 실패 모드(failure mode)의 문제입니다.

에이전트 내부에서 두 도구의 비교

| 특성 | Grep 도구 | 벡터 검색 (Vector retrieval) 도구 |
| :--- | :--- | : |
| 인덱스 구축 | 사전 구축 없음 (또는 trie / 역색인 (inverted index)) | 임베딩 패스 + ANN 인덱스 |
| 쿼리 비용 | O(N) 선형 스캔, 100MB 미만에서 빠름 | 임베딩 + 최근접 이웃 (nearest-neighbour) 조회 |
| 강점 | 리터럴 토큰 (literal tokens), 코드, 식별자 (identifiers), 날짜, 이름 | 의역 (paraphrase), 유의어 (synonyms), 퍼지 주제 매칭 (fuzzy topical match) |
| 실패 모드 | 유의어 / 재표현(rephrasing)을 놓침 | 노이즈 상황에서 top-k가 방해 요소에 의해 밀려남 |
| 무관한 문맥에 대한 견고함 | 예 — 매칭이 로컬(local)임 | 아니요 — 임베딩이 이동함에 따라 거리가 변함 |
| 에이전트 적합성 | 반복적으로 호출하기 저렴하며, head / tail과 체이닝하기 쉬움 | 한 번의 호출로 고정된 top-k 번들을 반환함 |

위의 표는 논문의 핵심 슬로건이 아닙니다. 핵심 슬로건은 다음과 같습니다: 일단 어느 도구든 에이전트 루프(agent loop) 안에 넣게 되면, 시스템(harness)이 그 차이를 상쇄한다는 것입니다. 모델이 정제된 쿼리로 도구를 다시 호출하고, 스니펫(snippet)을 살펴본 뒤, 계속 진행할지 결정할 수 있게 해주는 시스템은, 도구가 무엇이든 상관없이 도구를 한 번만 호출하여 top-k를 컨텍스트(context)에 쏟아붓는 시스템보다 더 뛰어난 성능을 발휘합니다.

에이전트 설계자에게 이것이 시사하는 점

실질적인 해석은 두 가지 측면이 있습니다. 프로젝트에

선형 스캔 (linear scan)이 느려질 정도로 코퍼스 (corpus)가 충분히 크거나, 쿼리 (query)가 진정으로 주제 중심적이거나 의역된 형태이거나, 혹은 에이전트가 단 한 번의 기회 (single shot)로 정보를 검색해야 하는 경우에는 여전히 벡터 검색 (vector retrieval)을 선택하십시오. 그리고 어떤 선택을 하든, 설계 예산은 하네스 (harness) — 즉, 에이전트가 도구를 호출하기로 결정하는 방식, 언제 물러설지(back off), 그리고 결과를 컨텍스트 (context)에 어떻게 다시 엮어 넣을지에 — 에 집중하십시오. 이 논문은 에이전트 설계자들에게 실제 레버리지 (leverage)가 어디에 있는지를 말해주고 있습니다. 관련 설명 자료: AsyncFC — 디코드 스트림 (decode stream) 내의 심볼릭 퓨처 (symbolic futures) — 모델이 아닌 하네스가 도구 호출에 드는 실제 시간(wall-clock)을 결정하는 또 다른 방식; MCP SEP-2663 — 장시간 실행되는 도구 호출을 위한 비동기 작업 핸들 (async task handles) — 에이전트가 어떤 검색 도구를 선택하든 그 밑단에 있는 프로토콜 계층.

자주 묻는 질문 (FAQ)

"Is Grep All You Need?"의 실제 주장은 무엇인가요?
이 논문은 두 가지 실증적 실험을 수행합니다. 첫째, 여러 플랫폼에 걸쳐 동일한 에이전트에 실제 grep 도구와 벡터 검색 (vector-retrieval) 도구를 모두 연결하고, 각각 116개의 LongMemEval 질문을 실행했습니다. 테스트된 조건 전반에서 grep은 일반적으로 벡터 검색보다 더 높은 정확도를 보였습니다. 둘째, 무관한 컨텍스트 (irrelevant context)를 점진적으로 주입했을 때, 벡터 검색은 성능이 저하되는 반면 grep은 거의 일정하게 유지됨을 보여주었습니다. 저자들의 프레임링은 단순히 "grep이 이긴다"는 것보다 더 미묘합니다. 전체적인 성능은 검색 알고리즘 자체가 아니라, 에이전트 하네스 (agent harness)와 도구 호출 스타일 (tool-calling style)에 의해 좌우됩니다.

이것이 벡터 임베딩 (vector embeddings)이 쓸모없어졌다는 뜻인가요?
아니요. 코퍼스가 커서 선형 grep 스캔이 느려지거나, 쿼리가 진정으로 의역되었거나 주제 중심적인 경우, 또는 에이전트가 반복할 수 없이 단 한 번의 검색 기회만 갖는 경우에는 여전히 벡터 검색이 승리합니다. 변하는 것은 기본 설정 (default)입니다. 에이전트 설계자는 프로젝트에 "검색"이 필요해지는 순간 바로 임베딩 인덱스 (embedding-index)와 벡터 저장소 (vector-store)를 찾아서는 안 됩니다. 반복적인 에이전트 루프 내에서 소규모~중규모 코퍼스를 대상으로 하는 리터럴 토큰 (literal-token) 중심의 쿼리에는 grep이 종종 더 나은 시작점이 됩니다.

왜 무관한 컨텍스트는 grep보다 벡터 검색에 더 해로운가요?

벡터 검색 (Vector retrieval)은 임베딩 공간 (embedding space)에서의 거리에 따라 순위를 매깁니다. 코퍼스 (corpus)나 쿼리 (query)에 무관한 텍스트가 추가되면 세 가지 현상이 동시에 발생합니다. 즉, 쿼리 임베딩 (query embedding)이 표류하고, 방해 요소가 되는 청크 (distractor chunks)들이 관련 청크 근처의 잠재 공간 (latent space)을 가득 채우며, 고정된 top-k 컷오프 (top-k cutoff)로 인해 관련 청크가 새로 근접한 방해 요소들에게 밀려 제외될 수 있습니다. Grep은 문자열 그대로의 부분 일치 (literal substrings)를 찾으므로 이러한 현상으로부터 자유롭습니다. 매칭 결과는 전체 데이터의 상대적 위치가 아니라 해당 청크 (chunk) 내에서 국소적으로 결정되기 때문입니다. 원문은 Learn AI Visually 에 게시되었습니다.