에이전트 검색은 실행 환경의 문제예요

5월 14일 공개된 arXiv 논문은 LongMemEval 질문 116개를 대상으로 Chronos, Claude Code, Codex, Gemini CLI에서 grep과 벡터 검색을 테스트했어요. 논문의 첫 번째 실험에서는 모든 실행 틀과 모델 조합에서 인라인 grep이 인라인 벡터 검색을 앞섰습니다. 하지만 더 큰 발견은 조금 더 낯설었어요. 검색 방식만큼이나 실행 환경이 결과를 크게 바꿨다는 점입니다.¹

에이전트 검색 품질은 “grep이냐 벡터냐”만으로 결정되지 않아요. 프롬프트, 도구 표면, 셸 사용성, 결과 형식, 맥락 압박, 전달 경로, 재시도 방식, 모델이 도구 사용 반복 과정을 끝까지 마무리하는 능력까지 포함한 전체 실행 환경에 달려 있습니다.

요약

Sen, Kasturi, Lumer, Gulati, Subbiah는 Chronos라는 맞춤 실행 틀과 3개의 제공자 기본 CLI 실행 틀인 Claude Code, Codex, Gemini CLI에서 어휘 검색과 벡터 검색을 비교했어요.¹ 이 연구는 LongMemEval-S 질문 116개 하위 집합을 사용했고, 도구 결과를 대화 안에 바로 넣는 방식과 파일로 전달하는 방식을 모두 테스트했습니다.¹ 실험 1에서는 모든 실행 틀과 모델 조합에서 인라인 grep이 인라인 벡터 검색보다 좋은 성능을 냈어요. Codex CLI와 GPT-5.4 조합에서도 인라인 grep은 93.1%, 인라인 벡터 검색은 75.9%였습니다.¹ 이 논문이 grep이 일반적으로 벡터 검색보다 낫다고 증명하는 것은 아니에요. 저자들은 답이 문자 그대로의 구간에 의존하는 경우가 많은 장기 기억 대화형 질의응답 설정으로 결론을 명시적으로 제한합니다.¹ 에이전트 구축자에게 더 유용한 결론은 이보다 선명해요. 검색 방식, 에이전트 실행 환경, 결과 전달 방식은 하나의 시스템을 이룹니다. 함께 벤치마크해야 해요.

핵심 요점

• 에이전트 구축자에게: grep을 진지한 기준선으로 유지하세요. 이 논문의 결과는 긴 대화 기록을 대상으로 하는 장기 기억 질의응답에서 “기본은 벡터”라는 태도가 느슨해 보이게 만듭니다. 특히 이름, 날짜, 사용자 사실처럼 문자 그대로의 단서가 중요할 때 그렇습니다.¹
• Codex와 Claude Code 사용자에게: 제공자 CLI를 검색 기본 기능을 감싸는 중립적인 껍데기로 보지 마세요. 논문은 같은 대화 데이터를 두고도 실행 틀 수준에서 큰 차이가 나타난다고 보고합니다.¹
• RAG 팀에게: 검색기만 보고하지 말고 전달 경로도 보고하세요. 인라인 결과와 파일 기반 결과는 서로 다른 행동을 만들었습니다. 파일 전달은 또 하나의 도구 사용 과제를 추가하기 때문이에요.¹
• 마이그레이션 작업에: 검색을 믿을 수 있게 만드는 실행 환경의 행동을 보존하세요. Claude Code에서 Codex로 옮길 때는 동등성을 선언하기 전에 검색, 대화 기록 형태, 검증 반복 과정을 테스트해야 합니다.
• 인용이 많은 시스템에: 최종 인용만으로 증거의 전체 이야기를 설명할 수는 없습니다. 별도의 Agentic GraphRAG 논문은 출처 추적이 인용된 노드뿐 아니라 방문했지만 인용하지 않은 그래프 맥락에도 의존할 수 있다고 주장합니다.⁴

Grep 논문은 실제로 무엇을 테스트했나요?

이 논문은 실용적인 질문을 던져요. LLM 에이전트가 긴 대화 기록을 바탕으로 질문에 답해야 할 때, 검색 성능은 검색 방식에 얼마나 좌우되고, 그 검색을 감싼 에이전트 시스템에는 얼마나 좌우될까요?¹

저자들은 두 가지 검색 계열을 비교했습니다.

이 검색기들은 두 종류의 실행 환경에서 테스트됐어요.

또한 결과가 모델에 도달하는 방식도 바꿨습니다. 인라인 전달은 검색 결과를 대화에 바로 삽입합니다. 프로그램 방식 전달은 결과를 파일에 쓴 뒤, 모델이 그 파일을 찾아 열고 통합해야 합니다.¹ 구현 세부사항처럼 들릴 수 있어요. 하지만 데이터는 이것도 과제의 일부라고 말합니다.

왜 여기서는 Grep이 이겼나요?

측정된 과제는 문자 그대로의 복구에 유리합니다. LongMemEval은 여러 작업 회차에 걸친 긴 대화를 바탕으로 질문합니다. 많은 답은 이름, 시간 표현, 개인적 사실, 정확한 과거 발화에 달려 있어요. 이런 설정에서는 답이 특징적인 문자열 뒤에 숨어 있는 경우가 많기 때문에 고정밀 어휘 도구가 의미 검색기를 이길 수 있습니다.¹

논문의 Table 1은 이 패턴을 분명히 보여줘요.

이 표가 “벡터 데이터베이스를 지우세요”라고 말하는 것은 아니에요. 논문 자체도 그렇게 읽지 말라고 경고합니다. 저자들은 결론이 장기 기억 대화형 질의응답에 묶여 있으며, 과학적 종합, 시각 문서, 코드 의미론 같은 영역에서는 밀집 검색이나 하이브리드 검색이 다르게 작동할 수 있다고 말합니다.¹

더 나은 해석은 이렇습니다. 정확 검색은 진지한 에이전트 실행 환경에서 일급 도구로 다뤄져야 해요. 에이전트가 파일 시스템을 검색하고, 로그를 읽고, 이전 대화 기록을 살피고, 문자 그대로의 사용자 사실을 복구할 수 있다면, 어휘 검색은 도구 상자에서 가장 저렴하면서 신호가 강한 도구일 수 있습니다.

실행 환경이 결과를 바꿨습니다

논문에서 가장 유용한 문장은 “grep이 이겼다”가 아니에요. 실행 틀을 바꾸면 검색기를 바꿀 때와 비슷한 규모로 상한선이 흔들릴 수 있다는 점입니다.¹

예를 들어 Claude Opus 4.6은 인라인 grep을 썼을 때 Chronos에서는 93.1%, Claude Code에서는 76.7%를 기록했어요.¹ 같은 모델 계열, 같은 벤치마크 하위 집합, 다른 실행 환경입니다. 또 다른 예로, Codex CLI와 GPT-5.4 조합은 인라인 grep에서 93.1%를 기록했지만, grep 결과가 프로그램 방식의 파일 전달 경로를 거치자 55.2%로 떨어졌습니다. 프로그램 방식 벡터 검색은 67.2%였습니다.¹

이것은 검색 결과만이 아닙니다. 실행 환경의 결과예요.

모델은 증거를 찾는 것 이상을 해야 했습니다. 도구 계약을 이해하고, 검색어를 고르고, stdout을 해석하고, 언제 재시도할지 결정하고, 결과가 인라인이 아닐 때 파일을 읽고, 증거를 답변에 통합해야 했어요. 이 모든 단계는 에이전트 실행 환경에 속합니다. 어느 한 단계라도 취약해지면 강한 검색기가 있어도 약한 답변이 나올 수 있습니다.

파일 기반 전달은 왜 도구 사용 테스트인가요?

파일 기반 전달에는 분명한 장점이 있습니다. 큰 검색 결과를 모델이 읽어 달라고 요청하기 전까지 즉시 대화 기록 밖에 둘 수 있어서 맥락 압박을 줄일 수 있어요. 인라인 벡터 검색 결과 덤프가 창을 밀어낼 때는 도움이 될 수 있습니다.

논문은 그 맞교환을 보여줍니다. 여러 행에서 프로그램 방식 벡터 검색이 프로그램 방식 grep보다 나았고, 이는 맥락 압박 논리를 뒷받침합니다.¹ 하지만 Codex/GPT-5.4 행은 반대쪽도 보여줘요. 파일 전달은 저렴한 검색을 여러 단계의 작업 흐름으로 바꿀 수 있습니다. 에이전트는 산출물을 찾고, 열고, 유용한 구간을 추출하고, 첫 읽기가 충분하지 않을 때 다시 시도해야 합니다.¹

즉 프로그램 방식 전달은 맥락 대역폭을 도구 사용 반복 수행 능력과 맞바꿉니다. 이 교환은 실행 환경이 반복 과정을 안정적으로 끝까지 마무리할 때만 이득이 됩니다.

실무에서는 이 점이 중요합니다. 로컬 에이전트가 검색에 실패하는 이유는 색인이 틀렸기 때문만이 아니에요. stdout이 잘못 잘렸거나, 결과 파일 경로를 놓치기 쉬웠거나, 명령이 너무 많은 노이즈를 반환했거나, 프롬프트가 과제를 잘못 잡았거나, 모델이 한 번만 더 읽었어야 할 지점에서 멈췄기 때문일 수 있습니다.

Codex 마이그레이션에 주는 의미

제가 진행한 Claude Code에서 Codex로의 마이그레이션은 파일 트리를 복사하는 것보다 운영 계약을 옮기는 데 초점을 맞춰 왔어요. 이 논문은 그 선택을 더 강하게 뒷받침합니다.

검색 품질이 실행 환경에 달려 있다면, 마이그레이션 품질도 “Codex에 검색 도구가 있나요?” 이상에 달려 있습니다. 마이그레이션은 검색을 유용하게 만드는 행동을 보존해야 해요.

• 에이전트가 의미 검색 전에 정확 검색을 언제 써야 하는지 알아야 합니다.
• 명령 출력은 읽을 수 있을 만큼 작게 유지되어야 합니다.
• 증거 경로가 최종 답변까지 살아남아야 합니다.
• 파일 기반 산출물은 찾고 살피기 쉬워야 합니다.
• 실패한 검색은 성급한 답변이 아니라 더 나은 질의로 이어져야 합니다.
• 공개 글쓰기는 그럴듯한 검색이 아니라 출처 검증을 사용해야 합니다.

이 목록은 의도적으로 공개 가능하고 일반적인 내용만 담았습니다. 비공개 자동화 연결부, 비공개 프롬프트, 로컬 작업 흐름 내부를 드러내지 않아요. 핵심은 운영 계약입니다. 에이전트가 수행한 검색에 대해 자신감 있게 말하는 데 그치지 않고, 무엇을 찾았는지 증명하게 만들어야 합니다.

이 논문은 모든 명백한 기능이 있어도 마이그레이션 결과가 더 나쁘게 느껴질 수 있는 이유도 설명합니다. Claude Code와 Codex는 둘 다 셸 도구를 제공할 수 있습니다. 둘 다 파일을 읽을 수 있고, 둘 다 검색할 수 있어요. 하지만 대화 기록 형식, 파일 결과 처리, 중단 방식, 재시도 패턴이 다르면 같은 검색 기본 기능도 다른 결과물을 만들 수 있습니다.

다른 세 신호도 같은 방향을 가리킵니다

같은 조사에서 발견된 5월 14일의 다른 논문 3편도 더 넓은 같은 패턴을 가리킵니다. 에이전트 품질은 고립된 모델 호출에서 실행 환경 구조로 옮겨가고 있어요.

APWA는 대규모 병렬 에이전트 작업을 분산 실행 문제로 다룹니다. 저자들은 작업 흐름을 서로 간섭하지 않는 하위 문제로 분해해, 독립적인 자원이 상호 통신 없이 처리할 수 있게 한 뒤, 기존 시스템이 실패하는 더 큰 과제에서 확장성을 평가합니다.² 이것은 프롬프트 기교가 아니라 실행 환경에 대한 주장입니다.

MeMo는 기억을 별도의 모델 구성 요소로 다룹니다. 실행을 맡는 LLM은 고정해 두고, 새로운 지식을 전용 기억 모델에 인코딩하며, 검색 노이즈에 대한 저항성과 오픈 소스 및 폐쇄형 LLM과의 플러그 앤 플레이 호환성을 보고합니다.³ 이것은 더 긴 맥락에 대한 주장이 아니라 기억 구조에 대한 주장입니다.

Agentic GraphRAG 출처 추적 논문은 최종 인용이 필요할 수는 있지만 충분하지 않을 수 있다고 주장합니다. 정확한 답변은 인용되지 않은 탐색 맥락, 그래프 구조, 방문했지만 인용하지 않은 엔터티에 의존할 수 있습니다.⁴ 이것은 인용 형식에 대한 주장이 아니라 출처 추적에 대한 주장입니다.

이 논문들을 grep 논문 옆에 놓으면 하나의 형태가 드러납니다.

공통 주제는 이렇습니다. 감싸는 구조가 곧 제품입니다. 모델의 능력이 유용한 작업으로 바뀌는지는 실행 환경이 결정합니다.

제가 에이전트 스택에서 바꾸고 싶은 것

지루한 기준선부터 시작하세요. 에이전트가 중요한 파일, 로그, 대화 기록, 노트를 대상으로 정확 검색을 할 수 있게 하세요. 의미 검색을 추가하기 전에 이것부터 측정하세요.

그다음 2개가 아니라 4개 조합을 테스트하세요.

각 실행의 도구 사용 기록을 기록하세요. 최종 답변만으로는 부족합니다. 에이전트가 올바른 용어를 검색했는지, 올바른 파일을 열었는지, 올바른 구간을 알아봤는지, 놓친 뒤 재시도했는지, 실제로 답변을 뒷받침한 증거를 인용했는지 알아야 합니다.

도메인에 다른 말로 표현된 내용의 복구, 개념적 종합, 문자 그대로가 아닌 증거가 필요할 때 벡터 검색을 추가하세요. 도메인에 이름, ID, 파일명, 날짜, 로그 줄, 명령 출력, 사용자 선호, 이전 지시가 포함되어 있다면 정확 검색을 유지하세요. 두 성격이 섞인 과제에는 하이브리드 라우팅을 사용하세요.

공개 글쓰기에서는 검색 경로를 더 엄격하게 만들어야 합니다. 인용이 있는 글에는 출처 URL, 주장과 출처의 정합성, 아직 검증되지 않은 항목의 기록이 함께 있어야 해요. 시스템이 그래프, 기억 계층, 중간 검색 경로를 사용했다면 최종 인용만이 유일한 흔적이어서는 안 됩니다. 출처 추적 논문은 Agentic GraphRAG를 두고 이 점을 말하지만, 제품 관점의 교훈은 더 넓게 적용됩니다. 증거는 목적지만이 아니라 경로도 설명해야 합니다.⁴

더 나은 벤치마크 질문

약한 벤치마크 질문은 이렇습니다.

어떤 검색기가 더 나은가요?

더 강한 질문은 이렇습니다.

이 실행 환경, 이 모델, 이 말뭉치, 이 전달 경로, 이 재시도 정책 아래에서 어떤 검색 행동이 검증된 답변을 만들어내나요?

이 질문은 답하기가 더 느립니다. 하지만 실제로 쓸 수 있는 것을 알려줍니다.

에이전트 작업은 사람들을 계속 구성 요소 중심 주장으로 유혹합니다. 더 나은 모델, 더 나은 검색기, 더 나은 프롬프트, 더 나은 기억, 더 나은 병렬성 같은 주장입니다. 하지만 운영 현실은 계속 반대 방향으로 밀어붙입니다. 구성 요소는 실행 환경이 그것을 과제에서 증거로, 증거에서 행동으로 이어지는 믿을 만한 경로로 바꾼 뒤에야 의미가 있습니다.

마이그레이션할 가치가 있는 부분은 바로 그 부분입니다.

FAQ

이 논문은 grep이 벡터 검색보다 낫다는 것을 증명하나요?

아니요. 저자들은 결과를 연구 대상인 장기 기억 대화형 질의응답 설정으로 명시적으로 제한합니다. 또한 과학적 종합, 시각 자료가 많은 문서, 코드 의미론처럼 증거가 문자 그대로 드러나는 경우가 드문 도메인에서는 밀집 검색과 하이브리드 라우팅이 다르게 작동할 수 있다고 말합니다.¹

실험에서 grep은 왜 이렇게 잘 작동했나요?

LongMemEval 질문은 과거 대화의 문자 그대로의 구간에 의존하는 경우가 많습니다. 이름, 날짜, 개인적 사실, 정확한 발화가 대표적이에요. 에이전트가 특징적인 용어를 추측할 수 있을 때 grep은 고정밀 패턴에 보상을 줍니다.¹

실행 틀은 왜 중요했나요?

실행 환경은 프롬프트 형태, 도구 설명, 대화 기록 형식, 셸 동작, 맥락 구성, 결과 전달, 중단 기준을 제어합니다. 논문은 기본 대화 데이터가 같아도 Chronos, Claude Code, Codex CLI, Gemini CLI 사이에서 큰 정확도 차이가 나타난다고 보고합니다.¹

Codex 사용자는 이것을 어떻게 받아들여야 하나요?

정확 검색을 기준선으로 유지하고, 도구 사용 기록을 살피고, 어떤 검색 방식이 더 낫다고 가정하기 전에 인라인 전달과 파일 기반 전달을 테스트하세요. 논문의 Codex 행은 유용하지만, 여전히 하나의 벤치마크 설정, 하나의 말뭉치 유형, 확장 행에 대해서는 불완전한 제공자 전체 그림일 뿐입니다.¹

이것은 RAG 인용과 어떤 관련이 있나요?

Agentic GraphRAG 출처 추적 논문은 최종 인용이 답변을 뒷받침할 수는 있어도, 답변에 영향을 준 검색 맥락을 빠뜨릴 수 있다고 주장합니다. 에이전트 시스템에서 인용 품질은 최종 인용 출처 목록만이 아니라 경로 전반의 출처 추적을 포함해야 합니다.⁴

Claude Code에서 Codex로 마이그레이션할 때 무엇을 보존해야 하나요?

운영 행동을 보존하세요. 에이전트가 언제 검색하는지, 출력을 어떻게 제한하는지, 증거를 어떻게 여는지, 어떻게 재시도하는지, 출처 경로를 어떻게 기록하는지, 근거 없는 주장을 어떻게 거부하는지가 핵심입니다. 두 환경 모두 셸과 검색 명령을 제공한다고 해서 동등하다고 가정하지 마세요.

참고 문헌