컨텍스트 엔지니어링을 위한 검색 도구

에이전트에게 가장 중요한 도구는 자체 컨텍스트를 구축하는 데 사용할 수 있는 검색 도구입니다. 최근 LlamaIndex와 LangChain의 게시물은 컨텍스트 엔지니어링을 위해 에이전트에게 셸 도구와 파일 시스템만으로 충분할까?라는 논의를 불러일으켰습니다.안타깝게도 논의는 파일 시스템 대 데이터베이스라는 잘못된 초점으로 빠르게 흘러갔습니다.

이 글에서는 에이전트가 자체 컨텍스트를 구축하는 데 필요한 적절한 검색 인터페이스는 무엇인가?라는 질문에 다시 초점을 맞춥니다. 먼저 셸 도구와 전용 데이터베이스 도구 간의 절충점을 다룹니다. 이를 통해 에이전트의 요구에 맞는 인터페이스를 찾는 데 유용한 실용적인 프레임워크를 제공합니다.

'컨텍스트 구축'이란 에이전트에게 실제로 무슨 의미일까요?

초기 검색 증강 생성(RAG) 파이프라인에서는 개발자가 고정된 검색 파이프라인을 설계했고, 대규모 언어 모델(LLM)은 컨텍스트의 수동적인 수신자였습니다. 이는 근본적인 한계였습니다. 필요한지 여부에 관계없이 모든 쿼리에서 컨텍스트가 검색되었지만 실제로 도움이 되는지 확인하지 못했습니다.

에이전트 기반 RAG로의 전환으로 이제 에이전트는 자체 컨텍스트를 구축하기 위한 일련의 검색 도구에 접근할 수 있게 되었습니다. 예를 들어, Claude Code[1]와 Cursor[2] 모두 에이전트가 다양한 검색 도구 간에 선택할 수 있도록 하고, 작업에 실제로 필요한 내용에 따라 이를 연결된 쿼리로 조합할 수도 있습니다.

컨텍스트 엔지니어링을 위한 검색 인터페이스에는 어떤 것이 있나요?

컨텍스트는 웹, 로컬 파일 시스템 또는 데이터베이스와 같은 다양한 위치에 존재할 수 있습니다. 에이전트는 다양한 도구를 통해 이러한 맥락에서 벗어난 데이터 소스 각각과 상호 작용할 수 있습니다.

셸 도구는셸 명령을 실행하고 로컬 파일 시스템에 접근할 수 있습니다. 기본 제공 셸 도구의 예로는 Claude API의 bash 도구, OpenClaw의 exec 도구, 그리고 LangChain의 shell 도구입니다.
전용 데이터베이스 도구는 MCP(모델 컨텍스트 프로토콜) 서버의 도구(예: Elastic Agent Builder MCP 서버) 또는 사용자 정의 도구(예: run_esql(query) 또는 db_list_index())로, 데이터베이스를 쿼리할 수 있습니다.
전용 파일 검색 도구는 (완전한 셸 액세스 권한 없이도) 로컬 파일(또는 업로드된 파일)을 검색하고 읽을 수 있습니다. 기본 제공 파일 검색 도구의 예로는 Gemini API의 파일 검색 도구 또는 OpenAI의 파일 검색 도구가 있습니다.
웹 검색 도구는 웹에서 정보를 검색할 수 있습니다.
메모리 도구는 (저장 방식에 관계없이) 장기 기억을 저장하고 불러올 수 있습니다.

에이전트가 로컬 파일, 독점 데이터, 웹 및 장기 메모리에 접근하기 위해 다양한 컨텍스트 검색 도구를 사용하는 방법을 보여주는 다이어그램입니다.

보시다시피, 셸 도구는 다재다능하며 다음과 같은 다양한 데이터 소스에서 컨텍스트를 검색하는 데 사용할 수 있습니다.

파일 시스템: 에이전트는 디렉터리 구조를 탐색하고(ls, find), 관련 콘텐츠를 검색하고(grep, cat), 충분한 컨텍스트를 구축할 때까지 이 과정을 반복합니다.
데이터베이스: 에이전트는 데이터베이스 명령줄 인터페이스 (CLI) 도구(예: elasticsearch-sql-cli)를 사용하거나, curl을 통해 HTTP API를 호출하거나, 스크립트를 실행할 수 있습니다. 이는 올바른 도구 사용을 안내하기 위해 에이전트 컨텍스트에 삽입된 재사용 가능하고 문서화된 예시인 에이전트 스킬과 함께 사용하면 특히 유용합니다(예: Elastic Agent Skills for Elasticsearch).
웹: 에이전트는 검색 제공업체의 API를 통해 curl 명령을 사용하여 웹 검색을 실행할 수 있습니다.

그러나 셸 도구는 직접적인 시스템 액세스를 제공하므로 격리된 샌드박스 환경에서 실행하고 모든 실행된 명령을 로깅하는 등의 안전 조치가 필요합니다.

각 검색 인터페이스의 사용 시점

적합한 검색 인터페이스는 데이터, 쿼리 패턴 및 사용 사례에 따라 달라집니다. 이 섹션은 실용적인 출발점이 됩니다.

파일 시스템이 데이터베이스를 쓸모없게 만들지는 않습니다

파일 시스템과 데이터베이스의 논쟁은 저장 공간 계층에 관한 것이 아닙니다. 예를 들어, LangChain은 자체 메모리 시스템이 실제로 실제 파일 시스템에 메모리를 저장하지 않는다고 설명합니다. 대신 데이터베이스에 메모리를 저장하고 이를 에이전트에게 파일 세트로 표현합니다[3].

파일 시스템은 코딩 에이전트와 같은 파일 기반 사용 사례에 매우 적합합니다. 또한 임시 메모장이나 작업 메모리로 사용하기에 적합하며 동시성이 문제가 되지 않는 단일 사용자 또는 단일 에이전트 시나리오에 적합합니다. 이러한 경우 물리적 파일 시스템 또는 데이터를 파일 시스템으로 표현하는 것은 목적에 맞춰진 인터페이스에 약속하기 전에 유연성을 제공합니다.

그러나 파일 시스템 저장 공간에는 실제적인 단점이 있습니다. 예를 들어 약한 동시성, 수동 스키마 적용, 원자적 트랜잭션 등이 있습니다. 이러한 단점은 애플리케이션을 확장해야 하거나 다중 에이전트 시나리오로 전환해야 할 때 더욱 분명해집니다. 이러한 단점을 무시하는 사람은 프로덕션 데이터베이스가 이미 제공하는 트랜잭션 안전이나 액세스 제어를 뒷받침하는 수십 년의 엔지니어링 없이 더 나쁜 데이터베이스를 고통스럽게 재창조해야 할 운명에 처하게 됩니다. 또한 대부분의 기업 환경에서는 이미 비즈니스에 중요한 데이터가 저장되어 있는 데이터베이스가 존재하기 때문에 데이터베이스 사용 여부를 선택할 필요가 없습니다.

셸 도구 + 파일 시스템

셸 도구는 파일 시스템 검색의 자연스러운 출발점입니다. 현재 코딩 에이전트가 해당 분야의 발전을 주도하고 있습니다. 로컬 파일의 코드를 다루기 때문에 본질적으로 파일 중심의 사용 사례입니다. 따라서 LLM은 코딩 작업을 위해 훈련 후 단계에서 미세 조정됩니다. 그렇기 때문에 많은 LLM은 코드를 작성하는 것뿐만 아니라 셸 명령을 사용하고 파일 시스템을 탐색하는 데도 능숙합니다.

ls 및 grep과 같이 기본 제공 CLI가 있는 셸 도구를 사용하면 파일을 효과적으로 찾을 수 있습니다. grep에서는 " matplotlib를 가져오는 모든 파일을 찾으세요" 같은 쿼리가 빠르고 정확하며 저렴합니다. 하지만 에이전트가 "우리 앱은 인증 실패를 어떻게 처리하나요?"와 같은 개념적인 쿼리를 처리해야 하는 경우 grep을 사용한 패턴 매칭은 금방 한계에 부딪힐 수 있습니다. 명령줄에 의미 검색 기능을 제공하는 몇 가지 대안이 이러한 격차를 메우기 위해 등장했으며, 여기에는 jina-grep이 포함됩니다.

그러나 grep과 많은 시맨틱 검색 대안들은 코퍼스 전체에서 O(n) 시간 복잡도로 실행됩니다. 코드베이스를 대상으로 하는 사용 사례에서는 이 방식이 괜찮을 수 있습니다. 그러나 데이터가 증가하면 지연이 눈에 띄게 나타납니다. 이 경우 성능을 유지하기 위해 인덱싱된 데이터 저장소가 필요합니다.

셸 도구 + 데이터베이스

데이터에 시맨틱 검색이나 하이브리드 검색과 같은 더 많은 검색 기능을 추가하는 또 다른 방법은 Cursor의 예처럼 데이터를 데이터베이스에 저장하는 것입니다. 또한 데이터에 복잡한 관계형 조인이나 집계가 필요한 경우 데이터베이스 인터페이스는 필수적입니다.

데이터가 파일 시스템이 아닌 데이터베이스에 있을 때, 셸 도구는 특정 사용 사례에서 경량 데이터베이스 인터페이스 역할을 할 수 있습니다. 쿼리가 CLI나 curl 호출로 간단하다면, 전용 데이터베이스 도구는 불필요한 복잡성을 더할 수 있습니다.

이러한 접근 방식은 초기 탐색 단계에서도 적합합니다. 아직 어떤 쿼리 패턴이 개발될지 모를 때 유용합니다. 이 경우, 에이전트 스킬은 목적에 맞춰 제작된 도구에 의존하지 않고도 에이전트에게 올바르게 쿼리할 수 있는 충분한 구조를 제공할 수 있습니다. 하지만 에이전트가 반복적인 작업을 위해 데이터베이스를 쿼리하는 올바른 방법을 파악하는 데 여러 번의 반복이 필요한 경우, 셸 도구를 인터페이스로 사용하는 데 따른 토큰 오버헤드가 추가 도구를 사용하지 않음으로써 얻는 단순성이라는 이점을 더 이상 정당화하지 못합니다.

전용 데이터베이스 도구

특히 반복되는 쿼리 패턴이 구조화되거나 분석적일 때 전용 데이터베이스 도구가 필요해집니다. Vercel과 Braintrust의 블로그 게시물은 고객 지원 티켓 및 영업 통화 기록과 같은 반정형 데이터에 대한 실제 검색 작업에서 서로 다른 검색 도구 세트를 갖춘 에이전트를 비교했습니다(예: "미해결 이슈 중 '보안'을 언급한 것은 몇 개인가요?" 또는 "누군가 버그를 보고하고 나중에 누군가 이를 수정한다고 주장하는 PR을 제출한 이슈를 찾으세요?") [4].

전용 데이터베이스 도구를 사용한 에이전트는 토큰을 더 적게 사용하고, 더 빠르며, 셸 도구와 파일 시스템만 사용한 에이전트보다 실수를 더 적게 했습니다. 이를 통해 알 수 있는 교훈은 쿼리가 반정형 데이터에 대한 분석적 추론을 필요로 할 때 직접적인 데이터베이스 도구가 올바른 선택이라는 것입니다.

검색 인터페이스 결합하기

모든 쿼리를 완벽하게 처리할 수 있는 단일 검색 인터페이스는 없습니다. 예를 들어, Cursor는 셸 도구(grep을 통한 검색용)와 시맨틱 검색 도구를 결합하여 에이전트가 사용자 프롬프트에 따라 적합한 도구를 선택할 수 있도록 합니다. 그들은 에이전트가 특정 기호나 스트링을 매칭하기 위해 grep을 선택하고, 개념적 또는 행동 질문에 대해서는 시맨틱 검색을 선택하며, 탐색적 작업에는 둘 다를 사용한다고 보고합니다.

Vercel 실험 보고서는 동일한 결과를 보여줍니다. 셸 도구와 전용 데이터베이스 도구 모두에 접근할 수 있는 하이브리드 에이전트가 먼저 전용 데이터베이스 도구를 사용한 다음 파일 시스템을 grep하여 결과를 확인함으로써 테스트된 모든 에이전트 중 최고의 성능을 달성했습니다. 하지만 이 접근 방식은 도구 선택과 검증을 위한 추론에 더 많은 토큰과 시간을 사용합니다.

두 예시의 패턴은 동일합니다. 컴포지션이 단일 인터페이스를 능가하지만 컴포지션에는 추가 비용과 지연 시간이 발생한다는 단점이 있습니다.

적합한 도구 세트를 찾기 위한 실용적인 권장 사항

적합한 검색 인터페이스는 간결하고 목적에 부합하며 에이전트의 실제 쿼리 패턴에 맞춰 특화되어 있어야 합니다. 현재 가장 좋은 방법은 수백 개의 MCP 도구를 사용하는 에이전트 대신 가능한 한 적은 수의 도구를 사용하는 에이전트를 보유하는 것입니다. 이는 가능한 모든 도구를 미리 노출할 경우 발생하는 단점이 컨텍스트 윈도우를 비대화시키고 에이전트가 실제로 사용할 도구에 대해 혼란스럽게 만든다는 것입니다. 예를 들어, Claude Code는 보고된 바에 따르면 약 20개의 도구만 가지고 있습니다.

대신, 점진적 공개의 개념은 최소한의 도구 세트로 시작하고 에이전트가 필요할 때만 추가 기능을 발견하도록 하는 것입니다. Anthropic[5] 및 Cursor[6]의 연구에 따르면 이 접근 방식은 47%–85% 사이의 토큰 절감 효과를 가져옵니다. 예를 들어, Claude Code는 이를 직접 구현하여 에이전트가 API나 데이터베이스를 쿼리하는 방법을 점진적으로 발견할 수 있도록 하며, 이러한 지식이 모든 LLM 호출에서 컨텍스트를 소비하지 않도록 합니다.

에이전트의 쿼리 패턴에 익숙해지면, 에이전트가 기본적으로 액세스할 수 있는 검색 도구 세트를 다시 검토할 수 있습니다. 이 절충점을 고려할 때 유용한 방법은 '낮은 바닥, 높은 천장' 원칙에 다라 어떤 도구를 선택할지 결정하는 것입니다. '높은 천장' 도구는 에이전트의 잠재력을 제한하지 않습니다. 예를 들어, 다목적 셸 도구를 사용하면 에이전트가 애매한 쿼리를 포함한 전체 데이터베이스 쿼리를 작성할 수 있지만, 추론 오버헤드, 더 높은 지연 시간, 더 낮은 신뢰성이라는 대가가 따릅니다.

'낮은 바닥' 도구는 그 반대입니다. 이들은 특정 쿼리를 처리하는 전문화된 도구로, 에이전트가 최소한의 추론 오버헤드로 즉시 접근할 수 있어 비용을 낮추고 신뢰성을 높입니다. 그러나 초기 엔지니어링이 필요하고, 모든 가능한 쿼리를 다룰 수 없으며, 에이전트가 올바른 도구를 선택하기 더 어렵게 만들 수 있습니다.

각 도구를 스펙트럼으로 생각해 보세요. '낮은 바닥' 도구는 에이전트가 올바르게 사용하기 쉽지만 범위가 좁습니다. '높은 천장' 도구는 다용도이지만 효과적으로 사용하기 위해서는 더 많은 추론이 필요합니다.

세 가지 에이전트 설계 접근 방식(높은 바닥/높은 천장, 낮은 바닥/낮은 천장, 낮은 바닥/높은 천장)을 비교하는 다이어그램으로, 다양한 도구 전략이 에이전트가 모호하고, 다목적이며, 예측 가능한 쿼리를 처리하는 방식에 어떤 영향을 미치는지 보여줍니다.

대부분의 에이전트는 다양한 검색 도구의 조합이 필요합니다. 하지만 각 도구마다 추가 기능이 필요합니다. 다목적 검색 도구(예: search_database() 도구 또는 셸 도구)로 시작하는 것이 좋습니다. 그런 다음 보안 목적으로 이미 보관하고 있는 명령 로그를 재사용하여 도구 호출, 재시도 및 사용자 쿼리당 호출 횟수를 포함하여 에이전트가 실제로 수행하는 작업을 추적하세요. 그리고 쿼리 패턴이 반복되거나 실패하는 것을 발견하면 이를 위한 전용 도구를 구축해야 한다는 신호입니다.