Is Grep All You Need? 정말로 AI에이전트에서 RAG는 만능일까

 이번에 에이전트를 설계하면서 들었던 가장 큰 의문

잘 짜여진 데이터베이스 스키마가 RAG보다 더 효율적이지 않을까?

 

 RAG라고 하면 일반적으로 임베딩을 통해서 소스에서의 정보 검색을 통하여 데이터를 처리하는 과정을 의미한다. 하지만 임베딩이라는게 직관적으로 이해가 되지 않는 부분인만큼 그냥 잘 검색을 하는게 더 좋지않을까? 하는 생각이 떠나지를 않았다. 일단 설계하던 에이전트가 크게 복잡하지는 않아서 RAG를 따로 쓰고 있지 않고 그냥 DB로 떼우고 있던 김에 스레드에서 그럴듯한 논문을 찾았다

 

  RAG에 대한 개념은 상황에 따라서 다르게 쓰이기는 하지만 여기서는 로컬 저장소에서 데이터를 검색하는 경우를 설명한다.

Granite를 사용하여 LangChain 에이전틱 RAG를 생성하는 방법의 튜토리얼 | IBM

 

 RAG라는 개념과 그 성능을 부정하지는 않지만 우리가 만드는 대부분의 에이전트가 사용하는 저장소에서는 저장되는 데이터의 양이 크기 않다. 내가 만드는 에이전트는 금융 분야에서 뉴스와 데이터를 수집하는데 금융 증권 분야의 특성상 과거의 데이터가 크게 중요하지 않아 현재 시점에서의 판단이 요구될 경우 과거의 데이터를 의도적으로 배제하기 때문에 저장되어 있는 데이터가 크지 않고, 현재시점에서 수집해오는 데이터도 최대한 중복을 배제하여 사용하기 때문에 크게 검색 성능을 증가시킬 필요는 없다. 다만 그래도 에이전트라면 A2A라던가 RAG라던가 이런 기초적인 기술로 꺼드럭을 댈 수 있어야 하기 때문에 RAG를 사용하지 않는다면 왜 사용하지 않았냐에 대해서 설명할 수 있어야 한다. 

 

 오늘 찾은 논문은 Is Grep All You Need? How Agent Harnesses Reshape Agentic Search라는 이름으로 Pricewaterhouse 라는 나무위키에도 등재되어 있는 회계법인에서 나온 논문이다. 아무래도 회계법인이니 엄청나게 많은 데이터를 정확하게 가져와야하기 때문에 RAG에 관심이 많은 모양이다. 

 

논문에서는 2가지 실험을 한다. 첫번째 실험은 grep과 vector 검색을 LongMemEval에서 116개의 질문에 대해서 수행하는데 커스텀 에이전트 하네스와 native CLI 하네스를 사용한다. 하네스는 모델이 자신이 검색하는 파일 시스템에 대한 전반적인 정보를 가진다. 두번째 실험은 grep-only와 vector-only 검색을 사용하는데 조금 더 무가치한 대화를 섞어서 검색을 어려운 환경을 조성한다. 결과적으로 첫번째 실험에서는 grep이 더 정확하게 나왔지만 하네스의 역할이 컸다고 합니다.

 

검색 패턴에는 RAG방법으로  많이 알려진 semantic vector search 와 grep(BM25, regex) 으로 대표되는 lexical search가 있다. lexical search는 정확하고 패턴적으로 인식하는 사전적 방식이다. vector 검색에 비해서 lexical은 더 간단하고, 견고하고 임베딩 비용이 발생하지 않는다. 즉, semantic vector search가 에이전트 아키텍처와 툴 호출 패러다임의 에이전틱 워크플로우 내에서 더 효과적인가 하는 의문을 남긴다. lexical search가 주어질 경우 에이전트는 직접 어느것을, 얼마나 많은  쿼리를 사용하여, 결과가 충분한지를 판단하는 과정을 에이전트 하네스와 도구 호출 인터페이스로 조절한다. 또한 도구 호출 결과가 모델에 보여질 때, 컨텍스트 안에 주입이 되는지, 혹은 외부적으로 접근하는지에 대한 차이도 존재한다 (왜?) 

 클로드 코드, 코덱스, 재미나이CLI와 같은 경우 기본 하네스와 도구 호출 기능이 있어 모델이 직접적으로 grep같은 command line으로 작동하지만 커스텀 하네스와 같은 경우 직접 모든 과정을 정교하게 필요로 하는 아키텍처적인 차이도 고려한다. 노이즈에 대한 검색 수준의 강건성, 즉 필요한 데이터와 불필요한 데이터의 비율에 따라서 검색 전략이 달라져야 한다. 

 크게 lexical search vs semantic vector search / custom harness vs provider-native harness / inline-context delivery vs file-based result delievery 로 나누어 실험을 진행한다. 116개의 질문에 대한 LongMemEval 벤치마크 셋을 사용한다.

 

Experiment 1 - 검색 방식, 하네스, 도구 호출 간의 상관관계

 컨텍스튼에 인라인 방식에서는 grep이 vector search보다 더 높은 정확도를 보였습니다. 정확한 단어나 날짜를 찾는데 더 유리했기 때문입니다. 하지만 검색 결과를 파일로 모델이 직접 열어보는 경우는 10개의 테스트 환경 중에서 5개에서 vector search가 grep보다 더 유리했습니다. 이는 모델이 파일을 읽고 여는 과정이 늘어나기 때문이라고 생각됩니다

 

Experiment 2 - 노이즈에 대한 강건성

 노이즈가 적은 초기에서는 vector search가 더 좋은 성능을 보이기도 했습니다만 결과랑 쓸데 없는 문서가 많아지는 환경이 될 수록 vector search는 실제적인 내용보다는 제목이나 주제에 영향을 더 크게 받아  제목은 유사하지만 전혀 다른 내용이 포함된 문서를 선택하는 경우가 발생하였습니다. 반면 grep은 정확한 패턴이나 단어를 검색하기 때문에 노이즈가 많아질 수록 성능 격차가 줄어들거나 일부 역전하기도 하였습니다.

grep-only에서는 커스텀 하네스가 더 성능이 안좋은 경우도 있었구요 vector-only에서는 커스텀 하네스가 훨씬 더 성능이 좋은 모습이 보이구요

 

Limitation$

 이런 저런 조건 하에 진행된 실험이기 때문에 무조건 grep이 더 좋다는건 아니고 일반적으로 긴 대화 속에서 질의응답에서 데이터를 추출하기 때문에 모델 입장에서는 답변에서 그대로 일치하는 단어를 사용하여 lexical search (grep) 을 사용하는게 효과적일 수도 있습니다. 일치하는 근거가 글자 그대로 나타나지 않는 경우 ( 의역된 과학적 증거, 시각 자료가 많은 문서, 코드 ) 와 같은 경우 dense retrieval과의 양상이 다를 수 있습니다. 

 

Conclusion

grep은 vector search보다 일관되게 더 높은 정확도를 보이며 inline grep은 모든 하네스-모델의 inline vector의 성능을 능가합니다. 동시에 주어진 대화 컨텍스트가 동일할 때의 성능은 하네스와 도구 호출 스타일에 크게 달라집니다.결론적으로 검색 메커니즘, 하네스 오케스트레이션, 결과 전달 경로가 에이전트 설계에서 독립적인 선택이 아니라 하나의 시스템으로 다루어져야하며 보다 더 많은 환경에서는 본 논문과 달라질 수 있습니다. 

 

 논문 하나만으로 결론을 내는게 좋지 않으므로 다른 이야기를 들어봅시다. 

 

llm-wiki

llm-wiki

 원본으로 이것도 어디 똑똑한 양반이 만든 데이터인데 마크다운 방식의 위키를 구축하는 것으로 몇 달 많이 인기가 있던 주제이다. 새로운 정보가 들어올때 마다 기존 문서와 연결하고 모순점을 찾아서 업데이트하며 지식을 축적한다. 기존의 RAG는 질문마다 원본 문서를 기반으로 처음부터 다시 조립?해야하는 문제점이 있다. RAG와 직접적으로 비교하던데 데이터를 저장한다는 점에서 RAG와는 조금 다르지 않은가 생각한다. 사용자는 자료 수집과 방향을 설정하고 LLM은 유지보수를 담당한다. 

 아키텍처 적으로 보면 원본(raw sources), 위키, 스키마 (schema) 로 분류된다. 새 자료를 넣으면 LLM이 요약하고 관련 위키 문서를 찾아 내용을 업데이트하고, 질문에 답을 하며 도출된 마음에 드는 분석은 다시 위키의 내용에 추가된다. 정기적으로 문서의 모순, 연결되지 않은 문서등을 찾아내어 위키를 유지한다. 즉, 개인 데이터 관리에서 문서 정리와 문서 간의 연결 유지를 LLM에게 시키는 방식으로 사실 나도 일반 위키를 하나 운영하려고 하고 있는데 유지보수를 하는 AI 플러그인을 만들고 있다. 아무래도 사람이 하는 것보다 부정확한 부분이 있지만 마크다운을 관리하는 것은 상당히 귀찮은 과정이다.

 

 Open Knowledge Format (OKF)  by Google

How the Open Knowledge Format can improve data sharing | Google Cloud Blog

 요런 것도 있는데 LLM 위키를 표준화시킨 것으로 개방형 지식 표준 포맷이라고 번역하는게 조금 문화어스럽지만 유사하지 않나 생각. 사내 위키, 코드, 문서가 전부 흩어져있기 때문에 AI가 맥락을 파악하기가 힘들기 때문에 모든 문서에서의 공통 포맷을 적용합니다. 극단적으로 단순화시킨 아키텍처로 마크다운 파일, YAML Frontmatter, 파일 간의 링크로 문서를 연결합니다. 이렇게 보니까 llm-wiki랑은 조금 다른 점이 보입니다. 

 OKF 번들이라고 하는 것은 컨셉트에 관한 마크다운 파일들의 저장소로 표, 데이터셋, 문서, api 뭐든지 일단 때려놓고 봅니다. 각 파일은 하나의 컨셉트이고 파일의 경로는 컨셉의 정체성입니다. 

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
│   ├── index.md
     └── weekly_active_users.md

 각 컨셉트의 문서에는 작은 YAML front matter가 필드와 마크다운 본문을

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column        | Type      | Description                              |
|---------------|-----------|------------------------------------------|
| `order_id`    | STRING    | Globally unique order identifier.        |
| `customer_id` | STRING    | FK to [customers](/tables/customers.md). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

컨셉트는 다른 마크다운 파일들과 연결되면서 저장소를 하나의 그래프 관계로 만들어 기존의 파일 시스템의 수직적인 상하관계에서 탈피합니다.