Context Engineering for AI Agents Starts with Retrieval

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AI 에이전트의 컨텍스트 엔지니어링은 검색에서 시작하며, Deep Agents는 필요한 정보만 찾고 파일로 분리한 뒤 하위 에이전트에 분석을 위임해 제한된 컨텍스트를 관리한다.

📌 핵심 요약

• 에이전트의 검색은 비효율적인 탐색, 한꺼번에 유입되는 과도한 정보, 무관하거나 오래된 정보라는 세 가지 문제에 부딪히며, 에이전트 하네스는 작업에 필요한 컨텍스트를 적절한 시점에 제공해야 한다.
• Deep Agents의 기본 파일시스템 도구는 glob으로 파일명을 찾고 grep으로 일치하는 내용을 검색한 뒤 read_file로 필요한 부분만 읽는다. read_file의 기본 읽기 단위는 100줄이며 시작 위치와 분량을 지정할 수 있다.
• 정확한 문자열 검색으로 부족하면 벡터 저장소 기반 의미 검색이나 SQL 데이터베이스, 검색 API, MCP server를 활용할 수 있다. agentic retrieval은 작업 도중 추가 검색을 허용하고, skill의 progressive disclosure는 필요한 시점에만 상세 지침을 불러온다.
• 약 20,000토큰을 넘는 도구 결과는 /large_tool_results/ 아래 파일로 저장되고 에이전트에는 경로와 짧은 미리보기만 전달된다. 사용자 정의 검색 도구도 결과 본문 대신 파일 경로를 반환하도록 구성할 수 있다.
• ‘retrieve, offload, delegate’는 검색 결과를 파일에 저장하고 하위 에이전트가 읽어 핵심 사실과 출처를 반환하게 하는 방식이다. 무관한 정보의 유입을 줄이는 것과 별도로, 최신 검색 API나 MCP server 및 날짜 필터로 오래된 결과 문제를 다뤄야 한다.

🧩 주요 포인트

1. 검색 방식과 자료 특성을 맞추면 불필요한 재검색과 파일 읽기를 줄여 실제 분석에 쓸 컨텍스트를 확보할 수 있다.
2. agentic retrieval과 skill의 progressive disclosure는 새로 드러난 정보 수요에 대응하면서 상세 검색 지침의 상시 적재를 줄이는 설계다.
3. 파일 경로 반환과 하위 에이전트 위임은 검색·분석·종합의 컨텍스트를 나누며, 정보의 관련성과 최신성은 각각 다뤄야 할 품질 조건이다.

🧠 상세 정리

1. 검색이 컨텍스트 엔지니어링의 출발점인 이유

글은 오픈북 시험에서 모든 자료를 갖고 있어도 정답을 효율적으로 찾기는 어렵다는 비유로 에이전트의 검색 문제를 설명한다. 에이전트 역시 제한된 컨텍스트 윈도 안에서 작업하므로 필요한 정보를 검색해야 하며, 비효율적인 탐색과 과도한 정보 유입, 무관하거나 오래된 정보라는 세 가지 장애에 부딪힌다. 파일을 무작정 열거나 같은 질의를 반복하면 유용한 근거를 찾기도 전에 토큰과 시간을 소모하고, 잘못된 정보가 들어오면 이후 추론에도 그 오류가 이어질 수 있다. 에이전트 하네스의 역할은 이러한 검색 기법을 전략적으로 적용해 작업에 맞는 정보를 필요한 시점에 제공하는 것이다. 사례로 제시된 경쟁사 분석 에이전트는 매주 월요일 수백 개 경쟁사를 조사해 팀 양식의 보고서를 작성하며, Company A의 지난주 메모와 대규모 시장 자료 속 매출 수치, 뉴스 기록의 새로운 소식을 서로 다른 방식으로 찾아야 한다.

2. 파일을 읽기 전에 이름과 키워드로 범위 좁히기

경쟁사마다 필요한 자료를 찾는 데 여러 차례 실패하면 보고서를 쓰기 전부터 검색 결과가 컨텍스트를 채우므로, 글은 작업에 맞는 도구를 선택해 반복 검색을 줄여야 한다고 주장한다. 파일시스템에서는 모든 파일을 열어 내용을 확인하기보다 책의 색인을 살피듯 파일명과 키워드부터 확인하는 방식이 제시된다. glob은 파일명 패턴으로 검색하며, 예를 들어 */company-a.md는 Company A 관련 메모를 찾는 데 사용할 수 있다. grep은 파일 전체를 컨텍스트에 올리지 않고 지정한 문자열을 검색해 일치하는 파일이나 줄, 일치 횟수를 반환할 수 있다. Deep Agents에는 glob과 grep 외에도 ls, read_file, write_file, edit_file이 기본 제공되며, 이 도구들은 공통 backend를 거치므로 파일이 에이전트 상태나 로컬 디스크, 영속 저장소, 샌드박스 중 어디에 있든 같은 방식으로 작동한다.

3. 정확한 문자열 검색을 넘어서는 검색 도구

grep은 찾을 단어를 알고 있을 때 유용하지만 입력한 정확한 문자열에 의존하므로, 표현이 다른 관련 자료를 놓칠 수 있다. 글의 예시에서 ‘Company A funding’을 검색하면 ‘Company A closes $50M Series B’라는 제목의 기사를 놓칠 수 있으며, 이는 원하는 소식이 있어도 단어 선택 때문에 검색에 실패하는 경우다. 의미를 기준으로 찾으려면 벡터 저장소를 사용하는 검색 도구를 추가할 수 있고, 이 도구는 질의를 받아 데이터 원천에서 가까운 결과를 찾아 반환한다. 다만 검색 도구가 반드시 벡터 저장소에만 연결되는 것은 아니며, 구조화된 매출이나 고객 기록을 조회하는 SQL 데이터베이스에도 연결할 수 있다. 웹의 최신 정보를 가져오는 검색 API나 다른 사람이 구축한 문서 검색 등을 제공하는 MCP server도 데이터 원천이 될 수 있으므로, 검색 방식은 찾으려는 정보의 성격에 맞춰 선택해야 한다.

4. 작업 중 검색을 결정하고 필요한 지침만 불러오기

처음에 한 번 검색한 뒤 답하는 2-step RAG는 FAQ 봇에는 맞을 수 있지만, 조사 도중 새로운 정보 수요가 생기는 연구 에이전트에는 충분하지 않다고 글은 설명한다. Company C를 조사하다 처음 알게 된 제품 출시 기사를 발견하면 그 제품의 가격도 찾아야 하는데, 초기 검색만 허용하면 보고서에 필요한 정보가 빠질 수 있다. agentic retrieval에서는 에이전트가 언제 무엇을 검색하고 추가 검색이 필요한지를 결정하며, Deep Agents는 기본적으로 반복 실행 과정에서 도구를 필요한 만큼 호출할 수 있다. 검색 노하우는 사용할 색인, 질의 표현법, 인용 형식 등을 담은 skill로 묶어 제공할 수 있다. 에이전트는 처음에는 각 skill의 이름과 짧은 설명만 보고 관련 작업이 생겼을 때 전체 지침을 불러온다. 이러한 progressive disclosure는 특정 작업에 필요한 전문 지침을 제공하면서도 평소에는 그 지침이 컨텍스트를 차지하지 않도록 하는 방식이다.

5. 큰 파일과 예상보다 큰 도구 결과 처리하기

검색을 효율화해도 올바른 결과 자체가 너무 클 수 있으며, 글은 Company B의 분기 매출 한 수치를 찾기 위해 시장 자료 40,000행을 모두 읽는 상황을 예로 든다. 뉴스 검색도 검색 한 번에 기사 네 개를 반환하고 이를 다섯 회사에 반복하면 본문이 빠르게 쌓이므로, 검색 성공과 컨텍스트 사용량 관리는 별개의 문제다. read_file은 기본적으로 한 번에 100줄을 읽고 offset과 limit으로 시작 위치와 분량을 정할 수 있어, grep으로 찾은 매출 수치 주변의 몇 줄만 확인할 수 있다. 그래도 도구 결과가 약 20,000토큰을 넘으면 하네스는 전체 결과를 /large_tool_results/ 아래 파일로 저장하고 에이전트에는 경로와 처음 및 마지막 몇 줄의 짧은 미리보기를 전달한다. 이후 에이전트는 read_file의 offset과 limit으로 필요한 부분만 다시 읽을 수 있으므로, 큰 결과가 한 번에 주 컨텍스트를 차지하는 일을 줄일 수 있다.

6. 사용자 정의 검색에서도 본문 대신 파일 경로 반환하기

글은 사용자 정의 검색 도구에서도 크기 제한에 도달하기를 기다리지 말고, 검색 결과를 파일로 저장한 뒤 경로만 반환하는 방식을 적용할 수 있다고 제안한다. 이는 ‘retrieve, offload, delegate’ 패턴의 앞부분으로, 검색으로 확보한 원문과 주 에이전트에 전달할 정보를 분리하는 단계다. 예시의 search_news 도구는 StateBackend를 사용하고 vector_store.similarity_search를 k=4로 실행해 네 개의 검색 결과를 얻는다. 각 결과의 본문은 /retrieved/result_{i}.md 형식의 파일로 저장되며, backend.upload_files를 거친 뒤 도구는 저장된 경로 목록만 문자열로 반환한다. 따라서 주 에이전트는 기사 네 편의 전체 본문 대신 짧은 경로 네 개만 받게 되지만, 이 단계만으로는 어느 파일이 실제 질문에 관련되는지까지 판단한 것은 아니므로 다음 분석 단계가 필요하다.

7. 하위 에이전트에 읽기를 위임해 관련 사실만 종합하기

검색 결과가 작아도 이름이 비슷한 다른 회사의 기사나 오래된 소식이면 잘못된 근거가 될 수 있고, 주 에이전트가 파일을 직접 열어 판별하면 무관한 본문도 이미 컨텍스트에 들어오게 된다. 이를 줄이기 위해 ‘retrieve, offload, delegate’의 마지막 단계에서는 하위 에이전트가 검색 파일을 읽고 핵심 사실을 반환하도록 한다. 예시의 chunk-analyst는 호출당 /retrieved/ 아래 파일 경로 하나와 질문을 받으며, read_file로 파일을 읽고 핵심 사실과 출처 URL을 반환하라는 지침을 갖는다. 주 에이전트와 하위 에이전트는 search_news가 사용한 것과 동일한 backend 인스턴스를 공유해야 저장된 파일을 읽을 수 있다. 주 에이전트는 검색으로 받은 네 경로를 각각 하위 에이전트에 전달하고 병렬 분석을 수행할 수 있으며, 돌아온 짧은 요약과 출처를 종합한 뒤 부족한 정보가 있으면 다시 검색한다. 이 구조에서는 원문 읽기가 각 하위 에이전트의 컨텍스트에서 이뤄지고 주 에이전트는 그 결론을 받아 작업을 이어간다.

8. 관련성 필터링과 별도로 최신성 확보하기

글은 하위 에이전트의 필터링이 주제와 무관한 결과를 줄이는 데 도움이 되더라도, 검색 결과가 오래되었다는 문제까지 해결하지는 못한다고 구분한다. 매주 월요일 실행되는 경쟁사 분석 에이전트가 지난달의 색인만 사용하면 이번 주 뉴스를 찾을 수 없으므로, 분석 단계뿐 아니라 정보를 가져오는 원천도 살펴야 한다. 해결 방법으로는 몇 달 전에 색인된 자료에만 의존하는 대신 검색 API나 MCP server로 현재 정보를 가져오는 방안이 제시된다. 데이터에 날짜가 있다면 검색 도구에서 날짜 필터를 적용해 오래된 결과를 제외하는 방법도 가능하다. 따라서 파일로 분리하고 읽기를 위임하는 구조와 별개로, 검색 원천의 최신성과 날짜 조건을 함께 다뤄야 한다는 것이 제공된 본문의 마지막 논점이다. 원문은 이어지는 ‘Be careful with retriev’라는 미완성 구절에서 끊겨 있어, 그 뒤에 어떤 주의사항이나 결론이 제시되는지는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 검색 품질은 관련 자료를 찾는 능력뿐 아니라, 그 자료를 읽는 과정에서 컨텍스트를 얼마나 소모하는지에도 달려 있다.
• 파일 경로 반환은 본문의 즉시 유입을 줄이고, 하위 에이전트 위임은 본문을 판별하는 과정까지 분리하므로 두 방식은 서로 다른 단계의 부담을 다룬다.
• 관련 정보만 추리는 설계가 갖춰져도 오래된 검색 원천의 한계는 남으므로, 관련성과 최신성은 독립적으로 관리해야 한다.

✅ 액션 아이템

• 검색 대상의 특성에 맞춰 glob·grep과 벡터 저장소 기반 의미 검색, SQL 데이터베이스, 검색 API의 적용 범위 검토.
• 사용자 정의 검색 도구에 파일 경로 반환과 ‘retrieve, offload, delegate’를 적용해 주 에이전트의 컨텍스트 유입 축소.
• 오래된 결과를 줄이기 위한 최신 검색 API 또는 MCP server 활용과 날짜 필터 적용 검토.

❓ 열린 질문

• 현재 검색 대상은 glob·grep의 정확한 문자열 검색으로 충분한가, 벡터 저장소 기반 의미 검색이 필요한가?
• 파일 경로 반환과 ‘retrieve, offload, delegate’를 적용했을 때 주 에이전트에 전달할 핵심 사실과 출처의 범위는 어디까지인가?
• 최신 검색 API나 MCP server 및 날짜 필터를 통해 필요한 정보의 최신성을 확보할 수 있는가?