기업 문서 검색, Grep와 임베딩 중 무엇을 선택할까?

URL: https://www.youtube.com/watch?v=X4w2Pkz5tDY 날짜: 2026-10-07 채널: aiDotEngineer 발표자: George He, LlamaIndex 엔지니어링 총괄 원문 제목: Grep or Embeddings? Agentic Search Over Company Documents — George He, LlamaIndex

📌 핵심 질문 / 이 논의가 다루는 핵심 논점

==에이전트가 언제 로컬 파일 탐색만으로 충분하며, 언제 임베딩·사전 인덱싱·하이브리드 검색이 필요한가?== 핵심 판단 기준은 검색 기술 자체의 우열이 아니라 데이터의 규모, 구조, 최신성, 멀티모달성, 권한 모델, 그리고 검색 비용이다. 작은 규모의 구조화된 코드 저장소에서는 grep·cat·파일 계층 탐색이 빠르고 정확하지만, 수천~수백만 개의 비정형 기업 문서에서는 임베딩 검색이 방향을 제시하고 로컬 파일 도구가 근거를 파고드는 하네스가 가장 현실적인 조합이다.

• 모델은 로컬 파일 시스템, 스킬, MCP를 활용해 과거보다 훨씬 잘 탐색하지만, 대규모 말뭉치와 복잡한 문서를 매번 컨텍스트에 넣는 비용은 여전히 크다.
• Claude Code의 로컬 grep 중심 접근은 코드가 작고 반구조화되어 있으며 디스크에 이미 존재한다는 특성에 잘 맞는다.
• 기업 데이터는 이미지·PDF·PowerPoint·도식·제조 다이어그램이 섞이고 보안·권한·신선도·규모 문제가 있어 같은 전략을 그대로 적용하기 어렵다.
• 의미 검색과 키워드 검색을 결합하고, 파일 목록·메타데이터·grep·읽기·스크린샷을 에이전트 도구로 제공하면 검색 결과를 실제 파일 근거로 검증할 수 있다.

발표의 결론은 검색이 정보가 있을 법한 곳을 찾는 나침반 역할을 하고, 하네스가 파일 탐색·재검색·문맥 확인을 조율해 신뢰할 수 있는 답변을 만든다는 것이다.

1. 문제의 출발점: 로컬 파일 탐색과 벡터 컨텍스트

모델의 오케스트레이션 능력이 좋아졌어도 “무엇을 컨텍스트에 넣을 것인가”는 여전히 시스템 설계 문제로 남는다.

1.1. 에이전트가 컨텍스트를 얻는 두 가지 경로

1. 로컬 파일 검색과 파일 실행

   1. 모델이 파일 시스템을 직접 순회하고 파일 이름, 디렉터리, 파일 내용에 접근한다.
   2. grep으로 패턴을 찾고 cat으로 내용을 읽으며, glob과 같은 파일 관리 방식으로 범위를 좁힌다.
   3. 인덱스를 별도로 동기화할 필요가 없고, 데이터가 이미 로컬에 있다면 지연 시간이 짧다.

2. 임베딩·사전 인덱싱·사전 검색

   1. 문서를 미리 파싱하고 청크화한 뒤 벡터 또는 키워드 인덱스를 만든다.
   2. 질의와 관련 있을 가능성이 높은 문서 집합을 먼저 찾으므로 수천~수백만 개 문서를 매번 모두 읽지 않아도 된다.
   3. 최신 데이터와 권한 메타데이터를 인덱스에 반영하는 동기화 비용을 감수해야 한다.

3. 하이브리드 선택

   1. 두 접근 방식 중 하나를 시스템 운영자가 매번 수동으로 고르는 것이 아니라, 에이전트 하네스가 상황에 따라 선택하도록 만든다.
   2. 의미 검색은 검색 방향과 후보 범위를 정하고, 로컬 도구는 구체적인 문장과 근거를 확인한다.

1.2. Claude Code가 보여준 grep 중심 설계

1. 코드 저장소에 잘 맞는 이유

   1. Anthropic의 Claude Code는 로컬 파일 시스템을 사용하고 grep·glob으로 코드를 탐색하는 방향을 취했다.
   2. 코드는 이미 텍스트이며, 대체로 문법적으로 일관되고, import·테스트·참조라는 흔적을 남긴다.
   3. 디렉터리와 파일 사이에 에이전트가 이동할 수 있는 자연스러운 계층 구조가 있다.
   4. 보통 저장소의 코드 규모는 기업 전체 문서 말뭉치보다 작고, 파일이 에이전트가 실행되는 디스크에 이미 있다.

2. 벡터 데이터베이스를 채택하지 않은 배경

   1. Claude Code가 벡터 데이터베이스를 실험했지만 결국 선택하지 않았다는 Boris의 설명이 소개된다.
   2. 이유는 검색 성능만이 아니라 실용적인 확장성과 유지보수였다.
   3. 코드가 계속 업데이트되면 사전 인덱싱된 벡터 인덱스를 최신 상태로 유지하기 어렵다.
   4. 따라서 코드 저장소에서는 사전 인덱싱·RAG·벡터 검색 없이도 직접 탐색하는 편이 효과적일 수 있다.

1.3. 기업 데이터로 넘어갈 때 문제가 달라지는 이유

1. 구조와 형식의 차이

   1. 기업 데이터에는 이미지, PDF, PowerPoint, 스캔 문서, 도식, 제조 다이어그램이 한데 섞인다.
   2. 코드처럼 잘 정리된 폴더나 일관된 문법이 없으므로 회사 데이터 세트 전체를 grep으로 훑기 어렵다.
   3. PDF와 도식은 사람이 읽는 시각적 구조에 의존하고, 기계가 바로 소비하도록 만들어지지 않은 경우가 많다.

2. 규모와 보안의 차이

   1. 데이터베이스·데이터 레이크는 코드 저장소와 규모가 완전히 다르며 로컬 실행이 불가능할 수 있다.
   2. 누가 어떤 정보를 볼 수 있는지, 테넌트별 권한을 어떻게 보존할지까지 검색 결과에 반영해야 한다.
   3. 문서를 사전 인덱싱하더라도 원본 변경과 권한 변경을 계속 따라가야 한다.

3. 운영 선택지

   1. MCP 서버, Anthropic의 Claude MD, 에이전트 파일, 지시 파일 등으로 데이터 탐색 경로와 계층 구조를 알려줄 수 있다.
   2. 그러나 도구나 지시 파일을 추가하는 것만으로 문제가 해결되지는 않는다.
   3. 핵심은 데이터 규모에 맞는 검색·데이터 관리 시스템을 얼마나 큐레이션하고 유지할지 결정하는 것이다.

2. 데이터 규모와 모델 컨텍스트 비용

검색 방식을 결정할 때 모델의 컨텍스트 길이가 커졌다는 사실만 보고 모든 데이터를 넣어서는 안 된다. 길어진 컨텍스트는 가능성을 늘리지만 처리 비용과 지연도 함께 늘린다.

2.1. 파일 수에 따른 경계

1. 약 100~1,000개 파일

   1. 에이전트가 파일 이름을 순회하고 필요한 내용을 컨텍스트에서 관리할 수 있는 범위다.
   2. 이 정도 규모에서는 로컬 파일 검색이 적절할 수 있으며 별도의 사전 검색 시스템이 과할 수 있다.
   3. 파일을 순회하며 이름을 관리하는 비용이 토큰을 과도하게 소모하지 않는다.

2. 수천~수백만 개 파일

   1. 파일을 매번 모두 읽거나 모델에 전부 보내는 방식은 불가능하다.
   2. 에이전트는 건초 더미에서 바늘이 있는 정확한 위치까지는 아니더라도, 어느 방향으로 갈지 알려주는 나침반이 필요하다.
   3. 의미 검색·키워드 검색·하이브리드 검색으로 후보를 줄인 다음 파일 탐색으로 세부 내용을 검증해야 한다.

2.2. 긴 컨텍스트와 하위 에이전트의 대가

1. 컨텍스트 길이의 증가

   1. 발표 시점의 모델은 최대 100만 토큰 컨텍스트를 제공했고, 이전에는 200k, 그 전에는 100k 수준이었다.
   2. 컨텍스트가 커져도 모든 토큰을 모델의 수집 파이프라인에 밀어 넣는 비용은 사라지지 않는다.
   3. 이진 데이터를 모델에 보내 자체 렌더링과 추출을 맡기는 것도 검색 요청마다 큰 비용을 만든다.

2. 하위 에이전트의 한계

   1. 큰 에이전트가 하위 에이전트에 명령하고, 작은 모델이 메모리 팽창을 처리한 뒤 결과만 반환하는 방법이 있다.
   2. 하지만 각 하위 에이전트가 전체 문맥을 필요로 하면 원본 비용이 여러 세션에서 반복된다.
   3. Claude Code처럼 메인 세션이 더 약한 모델의 하위 세션에 일을 맡기는 환경은 토큰과 지연 시간에 부담이 된다.
   4. 문서를 매번 다시 처리하는 대신 미리 인덱싱하면 처리 속도를 높이고 반복 토큰 사용을 줄일 수 있다.

2.3. 하네스가 맡아야 할 역할

1. 수동 분기 제거

   1. 시스템이 “이번에는 하이브리드 RAG를 쓸까, 개별 파일을 읽을까”를 사람이 매번 결정하게 만들지 않는다.
   2. 에이전트에 의미 필터링 도구와 전통적인 파일 도구를 함께 제공한다.

2. 두 세계의 결합

   1. 의미 검색으로 대략 어떤 파일이 관련됐는지 파악한다.
   2. 파일명 필터링, 메타데이터 필터링, grep, cat으로 후보 파일의 실제 내용을 확인한다.
   3. 에이전트의 파일 탐색 능력으로 세부 근거를 파고들어 환각 대신 원문에 기반한 답을 만든다.

3. 기업용 에이전틱 검색을 구성하는 다섯 가지 도구

발표자는 보험·금융·의료처럼 분류되지 않았거나 부분적으로만 라벨링된 문서가 많은 분야를 예로 들며, 검색을 “어디를 볼지 정하는 과정”과 “실제 내용을 읽는 과정”으로 나눈다.

3.1. 도구 1: 검색 결과를 만드는 나침반

1. 검색 방식의 선택

   1. 가능한 접근에는 Graph RAG, 전통적인 RAG, 키워드 기반 BM25가 있다.
   2. 엔터프라이즈 사례에는 키워드와 의미 검색을 함께 쓰는 하이브리드 검색이 권장된다.

2. 키워드 검색의 역할

   1. 개발자는 특정 문자열이나 사전 인덱싱된 단어를 찾아야 하는 경우가 많다.
   2. AI 에이전트도 코퍼스 안의 정확한 명칭, 필드명, 제품명, 코드명처럼 의미 유사성만으로 놓칠 수 있는 단어를 찾아야 한다.

3. 의미 검색의 역할

   1. 표현이 달라도 같은 의미를 가진 문서와 청크를 찾는다.
   2. 질의가 문서의 실제 표현과 다를 때 후보 범위를 넓혀 준다.

4. 퓨전과 재순위화

   1. 키워드와 벡터 검색을 결합하고 가중치를 주면 한 가지 검색 방식의 편향에 덜 갇힌다.
   2. 키워드만 또는 벡터만 사용하면 기본선 수준에 머무를 수 있지만, 두 결과를 융합하면 벤치마크에서 더 나은 결과를 기대할 수 있다.
   3. 최종 후보 상위 100개를 LLM이나 더 깊은 재순위화 프로세스로 다시 평가하면 검색 품질을 더 높일 수 있다.
   4. 다만 검색은 전체 파이프라인의 한 부분이며, 최종 목표는 검색 점수가 아니라 신뢰할 수 있는 결과다.

3.2. 도구 2: 파일 목록과 계층 탐색

1. 초기 검색의 확장

   1. 에이전트는 처음부터 모든 메타데이터와 추출 콘텐츠를 알지 못할 수 있다.
   2. 초기 검색 결과에 없던 유사 파일을 파일 계층 안에서 다시 찾아 검색 범위를 확장한다.

2. 분산 파일 시스템의 기본 프리미티브

   1. 파일을 나열하고, 특정 디렉터리나 파일을 선택하고, 파일을 읽는 기능을 제공한다.
   2. 모든 원본을 에이전트 컨텍스트로 내려받지 않고 필요한 부분만 요청하는 것이 핵심이다.

3.3. 도구 3: 메타데이터 필터링

1. 후보 압축

   1. 연도, 기업명, 출처, 문서 위치 같은 메타데이터를 기준으로 검색 결과를 좁힌다.
   2. 대규모 코퍼스에서는 내용 검색만으로는 후보가 너무 많으므로 메타데이터가 검색 방향을 보완한다.

2. 권한과 메타데이터의 결합

   1. 메타데이터는 단순한 검색 편의 정보가 아니라 사용자가 볼 수 있는 문서를 결정하는 권한 정보와도 연결된다.
   2. 인덱싱할 때 문서에 메타데이터 태그를 붙여 벡터 저장 계층에서 필터링할 수 있어야 한다.

3.4. 도구 4: 특정 파일의 grep·읽기

1. 정확한 패턴 확인

   1. 검색으로 후보 파일을 찾은 뒤 특정 파일에서 여러 키워드가 함께 나타나는지 grep으로 확인한다.
   2. 여러 단서가 한 파일에 모여 있는지 확인하면 그 문서의 답변 가치와 우선순위를 높일 수 있다.

2. 문맥 추출

   1. grep 결과에서 해당 패턴의 오프셋과 원하는 최대 길이를 확인한다.
   2. 파일 전체를 내려받지 않고 필요한 위치 주변의 텍스트만 읽어 답변 근거로 사용한다.

3.5. 도구 5: 멀티모달 문서의 내용·렌더링

1. 일반 청킹이 깨지는 문서

   1. 차트, 스캔, 도식, 긴 제조 설계도는 사람이 읽는 텍스트 줄의 연속이 아니다.
   2. 기존 문서 인덱싱·청킹은 표의 구조, 공간적 관계, 페이지 배치를 잃어버릴 수 있다.

2. 사전 파싱과 구조화

   1. 에이전트가 매번 이진 데이터를 읽고 렌더링하지 않도록 사전 파싱 흐름을 구축한다.
   2. LlamaIndex의 Llama Parse와 오픈소스 Light Parse가 구조적 콘텐츠 추출 사례로 소개된다.
   3. 표·차트·분할 정보는 Markdown 또는 에이전트가 공간적 추론을 할 수 있는 표현으로 인코딩한다.

3. 페이지 렌더링과 스크린샷

   1. 사전 파싱 과정에서 페이지를 렌더링할 때 스크린샷을 생성하고 저장한다.
   2. 텍스트와 메타데이터만으로는 무엇이 페이지의 어느 위치에 있었는지 모호할 수 있으므로, 구조화된 텍스트와 화면 이미지를 함께 보존한다.
   3. 사람이 하던 시각적 판독을 에이전트가 수행할 때 사전 구축된 스크린샷 인덱스가 RAG의 중요한 근거가 된다.

4. 사전 파싱 파이프라인의 품질과 운영 조건

4.1. OCR이 놓치면 의미 검색이 무너진다

1. 레이아웃 충실도

   1. Textract 같은 전통적인 OCR 파이프라인이나 Tesseract 같은 OCR 엔진이 표와 표의 표현을 실제로 보존하는지 확인해야 한다.
   2. 텍스트만 추출되고 행·열·위치 관계가 사라지면 이후 LLM의 의미적 읽기가 잘못된 구조를 기반으로 수행된다.

2. 공간적 추론의 연쇄 효과

   1. 초기에 결과가 괜찮아 보여도 모델이 표·차트·도식의 위치와 공간 관계를 이해하지 못하면 어느 순간 답변 품질이 무너진다.
   2. 따라서 파싱 품질은 단순한 OCR 정확도가 아니라 실제 콘텐츠 레이아웃에 대한 충실도로 평가해야 한다.

4.2. 운영 환경의 두 가지 난제

1. 다중 테넌시와 권한

   1. 한 사용자가 다른 사용자의 문서를 보지 못하도록 테넌트 경계를 유지해야 한다.
   2. Google Drive나 SharePoint에서 권한 메타데이터를 가져오되, 시스템 전체를 멈추거나 매번 전체 파이프라인을 재인덱싱·재파싱하지 않아야 한다.

2. 신선도

   1. 복잡한 데이터와 변경되는 권한 메타데이터를 항상 최신 상태로 유지하는 일은 어렵다.
   2. Anthropic을 비롯한 기업들이 모든 데이터를 사전 인덱싱하려는 시도를 포기한 이유 중 하나도 이 데이터 신선도 문제다.
   3. 검색 품질이 높아도 최신 문서나 최신 권한을 반영하지 못하면 실제 운영에서는 신뢰할 수 없다.

4.3. 동기화의 세 단계

1. 수집(Ingestion)

   1. 모든 문서를 동기화된 시스템으로 가져온다.
   2. 원본의 위치, 테넌트, 권한, 연도, 회사 등의 메타데이터도 함께 가져와야 한다.

2. 파싱(Parsing)

   1. 문서를 표준화된 형식으로 변환한다.
   2. 이날의 사용 사례에서는 문서를 Markdown 또는 텍스트로 바꾸지만, 멀티모달 표현만 필요하다면 다른 표현 형식을 선택할 수 있다.

3. 재구성·사전 인덱싱

   1. 파싱된 데이터를 다시 정리하고, 앞서 말한 검색·파일·메타데이터·렌더링 도구가 사용할 수 있는 사전 인덱스 상태로 내보낸다.
   2. 이 단계에서 청크, 검색용 필드, 권한 태그, 페이지 스크린샷을 연결한다.

4.4. 계층화된 저장소와 메모리 계층

1. 저장 위치의 트레이드오프

   1. 많은 벡터 저장 서비스는 모든 데이터를 메모리에 두지만, 대규모 시스템에서는 메모리 비용과 영속성이 문제가 된다.
   2. 데이터를 디스크에 둘지, 빠른 메모리 저장소에 모두 둘지 선택해야 한다.

2. LlamaIndex의 권장 방향

   1. LlamaIndex 팀은 수백만~수천만 개 문서 규모의 멀티 테넌트 문제를 다뤄 왔다고 설명한다.
   2. 데이터는 디스크에 영구 저장하고, 필요할 때 빠르게 가져올 수 있는 보호된 메모리 계층을 두는 방식을 권장한다.
   3. 데모에서는 Turbopuffer를 사용하며, 벡터 저장소 계층에서 권한 관리와 메타데이터 필터링을 함께 처리한다.
   4. 문서가 수없이 많아지면 메타데이터 필터가 필수이므로, 수집 단계에서 벡터 저장소에 태그가 정확히 붙었는지 확인해야 한다.

5. 데모: Alphabet 재무 보고서에서 검색과 파일 탐색 결합하기

데모의 목적은 에이전트가 검색·스크린샷·문맥·파일 읽기라는 하위 구성 요소를 조합해 여러 문서에서 근거 있는 답을 만드는 과정을 보여주는 것이다.

5.1. 데이터 세트와 검색 설정

1. 사전 인덱싱된 데이터

   1. 미리 정의된 데이터 소스에서 가져온 Alphabet 재무 보고서 기반 파일 135개를 사용한다.
   2. HTML 파일과 원본 PDF 파일이 섞여 있으며, 각 정보가 어디에서 발견되는지에 대한 파일 메타데이터도 함께 수집되어 있다.
   3. 문서에 연도나 특정 기업명 태그를 붙이면 에이전트가 메타데이터로 후보를 필터링할 수 있다.

2. 하이브리드 검색

   1. 검색 흐름에서 키워드 중심과 의미 중심의 비중을 조절할 수 있다.
   2. 데모에서는 두 방식을 균형 있게 설정하고 현금 흐름표(cash flow statements)를 검색한다.
   3. 검색 결과에는 질의에 매칭된 청크와 그 청크가 원래 있던 페이지의 스크린샷이 함께 표시된다.

5.2. 청크와 페이지 스크린샷의 결합

1. 청크의 한계 보완

   1. 텍스트 청크만 있으면 해당 문장이 문서의 어느 위치와 시각적 구조에 속했는지 알기 어렵다.
   2. 청크와 원래 페이지 스크린샷을 함께 제공하면 에이전트가 특정 청크를 고르고 주변 문맥을 요청할 수 있다.

2. 에이전트의 판단

   1. 에이전트는 검색 결과를 그대로 답변에 복사하지 않고 스크린샷과 문맥을 검토한다.
   2. 무엇이 실제 질의와 관련 있는지 판단한 뒤 파일을 읽고 검색 범위를 다시 조정한다.

5.3. 원격 파일에 대한 grep과 부분 읽기

1. 정확한 텍스트 찾기

   1. 특정 파일에서 “cash flow”처럼 정규식 또는 문자열 패턴을 찾을 때 grep을 사용한다.
   2. grep 결과에서 해당 텍스트의 오프셋과 최대 읽기 길이를 확인한다.

2. 데모 수치

   1. 한 예에서 오프셋 500자부터 시작해 다음 1,000자를 읽으면 필요한 문맥을 얻을 수 있다.
   2. 파일 전체를 로컬로 내려받는 대신 필요한 부분만 가져오므로 토큰과 스트리밍 비용을 줄인다.

3. 원격 저장소 상호작용

   1. 파일 목록·검색·부분 읽기 도구를 조합하면 에이전트는 모든 파일을 로컬 파일 상태로 보유하지 않아도 된다.
   2. 에이전트는 사실상 원격 파일 저장소와 상호작용하면서, 전체 데이터를 시스템으로 스트리밍하지 않고도 더 풍부한 탐색을 수행한다.

5.4. 표 형태 질의와 에이전트의 탐색 흐름

1. 사용자 질의

   1. 데모 채팅에는 2021년부터 2025년까지의 현금 흐름과 수입을 표로 보여 달라는 요청이 입력된다.
   2. 실행에 몇 초가 걸리는 동안 에이전트의 채팅 플로우 타임라인을 통해 검색 과정을 확인한다.

2. 검색과 재범위화

   1. 에이전트는 코퍼스에 검색 명령을 발행한다.
   2. 각 검색 단계에서 페이지 스크린샷과 문맥을 검토하고 어떤 결과가 실제로 관련 있는지 판단한다.
   3. 특정 파일을 읽고, 다시 파일을 검색하고, 필요하면 질의를 재조정한다.
   4. 한 번의 검색 결과에 고정되지 않고 여러 문서를 오가며 범위를 좁히기 때문에 더 깔끔한 결과가 나온다.

3. 답변의 근거

   1. 현금 흐름 요약은 여러 파일에서 가져온 정보로 구성된다.
   2. 탐색 흐름을 따라가면 최종 답변을 특정 파일의 구체적인 청크와 연결해 근거를 확인할 수 있다.
   3. 어떤 구성 요소와 문서를 찾았는지 확인할 수 있어 에이전트가 올바른 정보를 선택했다는 확신이 커진다.

주요 발언 모음

“에이전트는 언제, 왜 벡터 컨텍스트를 필요로 하는가? 아니면 컨텍스트 자체를 필요로 하는가?”

“데이터가 100개에서 1,000개 파일 정도라면 로컬 파일 검색으로 유지할 수 있다. 하지만 수천 개나 수백만 개로 커지면 대략 어디를 찾아야 할지 알려주는 나침반이 필요하다.”

“의미 검색으로 파일 범위를 좁힌 다음 에이전트의 내장 파일 탐색으로 세부를 파고들어 환각 대신 실제 근거에 답을 grounded할 수 있다.”

“멀티모달 문서를 다룰 때는 공간적 추론이 중요하다.”

“검색은 정보를 찾도록 돕고, 하네스는 신뢰할 수 있는 결과를 준다.”

핵심 데이터·수치·사례

• 발표자: George He, LlamaIndex 엔지니어링 총괄.
• 회사 단계: LlamaIndex는 시리즈 A 스타트업으로 소개된다.
• 문서 규모의 경계: 100~1,000개 파일은 로컬 탐색이 가능한 사례, 수천~수백만 개는 사전 검색·인덱싱이 필요한 사례다.
• 컨텍스트 길이 변화: 현재 약 100만 토큰, 과거 200k와 100k 수준이 언급된다.
• 재순위화: 검색 상위 100개 결과를 LLM 또는 더 깊은 프로세스로 재순위화하는 방안이 소개된다.
• 사전 파싱 도구: Llama Parse와 오픈소스 Light Parse.
• OCR 비교 대상: Amazon Textract와 Tesseract.
• 동기화 단계: 수집, 파싱, 재구성·사전 인덱싱의 3단계.
• 대규모 운영 경험: 수백만~수천만 개 문서의 멀티 테넌트 환경.
• 저장소: 디스크 영속 계층과 보호된 메모리 계층의 조합, 데모 벡터 저장소는 Turbopuffer.
• 데모 데이터: Alphabet 재무 보고서에서 파생한 135개 파일, HTML과 원본 PDF 혼합.
• 데모 검색: 현금 흐름표, 2021~2025년 현금 흐름·수입 표 요청.
• 부분 읽기 예시: 오프셋 500자에서 다음 1,000자 추출.

결론 및 시사점

1. 검색 방식은 데이터의 구조와 규모로 결정한다: 코드처럼 작고 반구조화되며 로컬에 있는 데이터에는 grep·파일 탐색이 강력하다.
2. 기업 문서는 검색과 탐색을 분리한다: 임베딩·키워드·메타데이터 검색은 나침반이고, 실제 파일 읽기와 grep은 근거 확인 장치다.
3. 하이브리드 검색을 기본값으로 둔다: 키워드의 정확성과 벡터 검색의 의미 유사성을 결합하고 필요하면 상위 100개를 재순위화한다.
4. 멀티모달 문서를 텍스트로 납작하게 만들지 않는다: 표·차트·도식의 레이아웃을 구조화된 텍스트와 페이지 스크린샷으로 함께 보존한다.
5. 사전 파싱의 품질을 측정한다: OCR이 표의 표현과 실제 레이아웃을 얼마나 충실히 보존하는지 평가하지 않으면 이후 LLM의 공간적 추론이 무너진다.
6. 신선도와 권한을 기능의 일부로 설계한다: Google Drive·SharePoint 같은 소스의 권한 메타데이터와 최신 변경을 전체 재인덱싱 없이 반영할 방법이 필요하다.
7. 저장소를 계층화한다: 대규모 문서는 디스크에 영속화하고, 빠른 메모리 계층과 메타데이터 필터를 결합한다.
8. 원격 파일 도구로 토큰을 절약한다: 전체 문서를 다운로드하지 않고 필요한 청크·오프셋·주변 문맥만 요청한다.
9. 정답의 신뢰성을 탐색 과정으로 검증한다: 여러 파일에서 답을 모은 뒤 특정 파일과 청크로 다시 연결할 수 있어야 한다.
10. 최종 설계 원칙: 검색은 관련 정보를 찾게 하고, 에이전트 하네스는 검색·스크린샷·파일 탐색·재질의를 조율해 신뢰 가능한 결과를 만든다.

핵심 요약 (20줄)

기업 문서 검색의 핵심 질문은 에이전트가 언제 로컬 컨텍스트만으로 충분하고 언제 벡터 컨텍스트가 필요한가이다. Claude Code의 grep 중심 방식은 작고 반구조화된 코드가 로컬 디스크에 있다는 조건에서 특히 효과적이다. 코드는 import·테스트·참조 흔적과 자연스러운 디렉터리 계층을 제공해 파일 탐색의 방향을 잡기 쉽다. 기업 데이터는 이미지·PDF·PowerPoint·도식이 섞여 있어 코드처럼 전체 폴더를 grep하기 어렵다. 기업 문서는 데이터 규모·형식·권한·최신성까지 검색 설계에 포함해야 한다. 100~1,000개 파일은 로컬 파일 순회만으로 관리할 수 있지만 수천~수백만 개는 나침반이 필요하다. 100만 토큰 컨텍스트가 가능해져도 전체 데이터를 반복 처리하는 비용과 지연은 사라지지 않는다. 하위 에이전트는 문맥을 여러 번 소비할 수 있으므로 사전 인덱싱으로 반복 처리를 줄여야 한다. 에이전트 하네스는 하이브리드 RAG와 개별 파일 검색의 선택을 자동화한다. 키워드 검색은 정확한 명칭을 찾고 의미 검색은 표현이 다른 관련 문서를 찾는다. 키워드와 벡터 결과를 융합하고 상위 100개를 재순위화하면 검색 품질을 높일 수 있다. 파일 목록·메타데이터·grep·읽기 도구는 초기 검색 결과 밖의 문서를 탐색하게 한다. 차트·스캔·도식은 텍스트 청킹만으로 공간적 관계를 보존하기 어렵다. Llama Parse와 Light Parse는 표·차트·구조 정보를 에이전트가 읽을 형식으로 파싱하는 사례다. 페이지 스크린샷을 사전 생성하면 에이전트가 청크와 시각적 문맥을 함께 검토할 수 있다. Textract와 Tesseract의 결과는 표 표현과 실제 레이아웃의 충실도로 평가해야 한다. 운영 시스템은 다중 테넌시·권한 메타데이터·데이터 신선도를 처리해야 한다. 동기화는 수집·파싱·재구성 및 사전 인덱싱의 세 단계로 나눌 수 있다. Alphabet 재무 보고서 135개 파일 데모는 현금 흐름 검색과 원격 grep을 결합했다. 검색이 방향을 찾고 하네스가 파일 근거와 탐색 과정을 연결할 때 에이전트 답변을 신뢰할 수 있다.