AI 에이전트에 검색 도구를 붙이는 일은 알고리즘 하나를 고르는 문제처럼 보인다. 하지만 실제 답변 품질에는 에이전트가 정보를 찾아 받아들이는 과정까지 개입한다.
검색 성능은 누가 결정하는가
AI 에이전트의 검색 성능은 검색기만으로 결정되지 않는다. grep은 문자열이나 정규식과 정확히 일치하는 원문 위치를 찾아주는 검색 도구다. PwC 연구진이 LongMemEval(장기 대화 기억을 평가하는 질의응답 벤치마크) 116문항을 시험한 결과, 같은 Claude Opus 4.6과 grep을 써도 Chronos(연구진이 만든 맞춤형 에이전트 하네스)는 93.1%, Claude Code는 76.7%를 기록했다. 하네스만 바꿨는데 16.4% 차이가 났다. 하네스는 모델의 프롬프트, 도구 호출, 결과 전달을 함께 운영하는 실행 환경을 뜻한다.
한편 Gemini 3.1 Flash-Lite와 Chronos 조합에서는 grep이 86.2%, 벡터 검색이 62.9%였다. 벡터 검색은 질의와 문장을 수치 벡터로 바꿔 의미상 가까운 항목을 찾는 방식이다. 이런 격차에 대해 연구진은, 모델의 판단력이 낮을수록 질의를 다듬고 결과를 판독하는 일이 덜 일관될 수 있다는 가설을 내놓았다. 다만 평가 점수에는 검색 정확도뿐 아니라 질의 작성, 도구 호출, 결과 전달 능력도 섞여 있다. 그렇다면 벡터 DB 도입 여부보다 하네스와 결과 형식 비교가 먼저 아닐까?
파일로 건네자 순위가 뒤집혔다
결과를 메시지에 바로 넣을지, 파일 경로만 줄지에 따라서도 순위가 뒤집혔다. GPT-5.4와 Codex CLI 조합에서 grep은 인라인 방식으로 93.1%였지만 파일 방식에서는 55.2%로 떨어졌다. 파일로 전달한 벡터 검색은 67.2%였다. grep의 17.2% 우위가 12% 열세로 바뀐 것이다.
| 전달 방식 | grep | 벡터 검색 |
|---|---|---|
| 인라인 | 93.1% | — |
| 파일 | 55.2% | 67.2% |
파일 방식은 파일을 찾아 열고 필요한 내용을 추려 답에 반영하는 단계가 더 필요하다. 이 과정이 불안정하면 검색 결과가 좋아도 소용없다. 실제로 파일 전달 실험에서는 열 개 조합 중 다섯 개에서 벡터 검색이 grep을 앞섰다. 결국 이 실험에서는 검색기 자체보다 결과 활용 능력이 더 큰 병목으로 작용했다.
grep과 벡터 검색의 차이
벡터 검색은 표현이 달라도 의미가 비슷한 문장을 찾지만 주제만 비슷한 기록도 함께 가져온다. Chronos와 Opus 4.6 조합에서 벡터 검색 점수는 대화 세션이 5개일 때 94.0%, 30개일 때 84.5%였다. grep은 같은 구간에서 89.3%에서 85.3%로 비교적 적게 떨어졌다.
반면 원문에 같은 단어가 없거나 여러 표현을 함께 해석해야 할 때는 의미 검색이 유리하다. 실제로 Cursor는 작업 기록으로 학습한 임베딩 모델(텍스트나 코드를 의미를 반영한 수치 벡터로 바꾸는 모델)로 질의응답 정확도를 평균 12.5% 높였고 grep과 의미 검색을 함께 쓸 때 성과가 가장 좋았다고 밝혔다.
그런데 비용은 어떤가. 저장 방식에 크게 좌우된다. 768차원 벡터를 float32로 저장하고 인덱스, 메타데이터에 1.5배 오버헤드를 더하면, 1,000만 개 기준 약 46GB다. 오브젝트 스토리지(파일을 객체 단위로 보관하는 클라우드 저장소)에 두면 월 25달러 수준이지만 64GB RAM에 모두 올리면 수백 달러가 든다. 비용뿐 아니라 도구가 실제로 쓰이는지도 확인해야 한다. JetBrains는 IDE 검색의 비용 절감 효과를 발표했지만 도구가 제대로 호출되지 않았음을 발견했다. GPT-5.6이 낮은, 중간 추론 조건에서 도구를 실제로 호출한 재실험에서는 비용이 6~7%(중앙값) 늘어 기본 적용을 보류했다.
문자열이 보이면 grep부터 써라
구별하기 쉬운 문자열이 있고 결과를 인라인으로 전달할 수 있다면 grep이 좋은 기본값이다. 이 조건에서는 모든 모델과 하네스 조합에서 grep이 벡터 검색을 앞섰다. Claude Code도 RAG와 로컬 벡터 DB를 없애고 에이전트가 직접 검색하도록 바꿨다. 개발자 Boris Cherny는 이 방식이 보안과 개인정보, 오래된 인덱스 문제도 줄인다고 설명했다. 기본 키워드 도구만으로 전통적 RAG 성능의 90% 이상을 낸 연구도 있다.
- 질의에 정확한 문자열 단서가 있는가?
- 검색 결과를 인라인으로 넣을 여유가 있는가?
- 에이전트가 파일 열기와 재검색 같은 여러 단계를 안정적으로 처리하는가?
문자열 단서가 있고 인라인 전달이 가능하면 grep부터 시작한다. 용어가 다르거나 큰 코드베이스를 탐색한다면 벡터 검색을 보완재로 붙인다. 인라인 전달이나 다단계 처리가 불안정하면 검색기보다 하네스를 먼저 고쳐야 한다. LLM이 검색식을 만들고 가벼운 역색인(단어별로 그 단어가 든 문서 위치를 저장한 색인)이 실행하는 방식도 강한 하이브리드 검색과 비슷한 정확도를 더 낮은 비용으로 냈다.
같은 검색기가 환경에 따라 다른 결과를 낸다면, 벤치마크의 순위보다 실패가 발생한 단계를 구분하는 일이 더 많은 정보를 주지 않을까?