대규모 문서 검색을 위해 Claude Code를 더 빠르게 만드는 방법

실제 문서 코퍼스(corpus)를 대상으로 Claude Code를 실행해 보았다면, 파일 수가 늘어남에 따라 속도가 빠릿빠릿한 상태에서 느릿느릿하게 변하는 것을 아마 목격했을 것입니다. 파일 10개는 즉각적으로 느껴집니다. 하지만 수백 개의 PDF가 되면 동일한 쿼리(query)를 처리하는 데 몇 분이 걸리고, 토큰 비용(token bill)은 급증하며, 때로는 답변이 자신 있게 틀리기도 합니다.

이 포스트는 왜 그런 현상이 발생하는지, 그리고 대규모 문서 세트에서 Claude Code를 어떻게 더 빠르게 만들 수 있는지에 관한 것입니다. 요약하자면, 병목 현상(bottleneck)은 대개 모델이 아니라 검색 전략(search strategy)에서 발생합니다. 검색 패턴(retrieval pattern)을 수정하면 속도, 비용, 그리고 신뢰성 문제가 대부분 함께 해결됩니다.

문제점: 직접적인 파일 검색은 확장성이 없습니다

기본적으로 Claude Code는 파일을 직접 읽음으로써 문서 검색을 수행합니다. 질문을 던지면 에이전트(agent)가 파일을 열고, 스캔하고, 찾아낸 내용에 대해 추론(reasoning)합니다. 에이전트가 전체 내용을 컨텍스트(context)에 담을 수 있기 때문에 작은 프로젝트에서는 아주 훌륭하게 작동합니다.

문제는 인덱스(index)가 없다는 점입니다. 에이전트에게 답변이 어디에 있는지 알려주는 것이 없기 때문에, 코퍼스가 커질수록 철저함을 유지하기 위해 점점 더 많은 파일을 살펴봐야 합니다. 이때 세 가지 문제가 동시에 나타납니다. 모델이 질문에 필요한 것보다 훨씬 더 많은 텍스트를 읽기 때문에 지연 시간(latency)이 증가합니다. 스캔된 모든 문서는 관련 여부와 상관없이 지불해야 하는 입력 토큰(input tokens)이 되므로 비용도 함께 증가합니다. 그리고 답변이 실제로 존재하지 않을 때, 모든 것을 스캔하도록 지시받은 모델은 깔끔하게 "찾을 수 없음"을 반환하기보다 그럴듯한 무언가를 꾸며내는 경향이 있어 신뢰성이 떨어집니다.

핵심적인 문제는 작업량이 질문의 난이도가 아니라 라이브러리의 크기에 따라 확장된다는 것입니다. 이는 문서 비중이 높은 작업에서 잘못된 스케일링 곡선(scaling curve)입니다.

해결책: 먼저 검색하고, 나중에 추론하라

표준적인 해결책은 검색 증강 생성 (Retrieval Augmented Generation, RAG)입니다. 모델에게 단 한 번의 과정 (single pass)으로 정보를 찾고 추론하도록 요청하는 대신, 작업을 분리합니다. 전용 검색 레이어 (retrieval layer)가 미리 구축된 인덱스 (index)를 검색하여 정답을 포함할 가능성이 가장 높은 소수의 구절 (passages)을 반환합니다. 해당 출처와 함께 전달된 이 청크 (chunks)들은 Claude Code로 전달되며, Claude Code는 이 작고 집중된 데이터 세트를 바탕으로 추론하여 근거 있는 (grounded) 답변을 생성합니다. 쉽게 말해, 흐름은 사용자 질의 (user query)에서 RAG 검색 레이어, 관련 문서 청크, Claude Code의 추론을 거쳐 근거 있는 답변으로 이어집니다.

각 구성 요소는 자신이 잘하는 일을 수행합니다. 벡터 검색 (Vector search)은 대규모 코퍼스 (corpus)에서 관련 텍스트를 찾는 데 빠르고 저렴하며, Claude는 집중된 사실 세트를 바탕으로 추론하는 데 강력합니다. 직접적인 파일 검색은 모델로 하여금 두 가지를 모두 수행하게 하며, 특히 모델이 가장 느리게 처리하는 부분인 '건초더미에서 바늘 찾기'까지 강요합니다.

핵심적인 행동 변화는 검색 비용이 대략 일정하게 유지된다는 점입니다. 문서가 50개이든 5만 개이든, 검색기 (retriever)는 소수의 청크 세트를 반환하므로 Claude는 매번 거의 동일한 양의 텍스트에 대해 추론합니다. 따라서 지연 시간 (latency)과 비용은 코퍼스 규모에 따라 증가하는 대신 평탄해집니다.

MCP를 통한 프라이빗 RAG 레이어 연결

이를 Claude Code에 연결하는 깔끔한 방법은 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)입니다. MCP를 사용하면 Claude Code가 외부 도구를 호출하고 구조화된 컨텍스트 (structured context)를 돌려받을 수 있으므로, 검색 시스템을 MCP 서버로 노출하여 에이전트 루프 (agent loop) 내의 다른 도구들과 동일하게 동작하도록 만들 수 있습니다.

MCP 상의 프라이빗 RAG (Retrieval-Augmented Generation) 계층은 보통 세 가지 작업을 수행합니다. 첫째, 매 쿼리마다 다시 스캔하는 대신 문서를 미리 청킹 (chunking) 및 임베딩 (embedding) 하여 한 번 인덱싱 (indexing) 합니다. 둘째, 선택적으로 검색하여 각 질문에 대해 가장 관련성이 높은 청크와 그 출처만을 반환합니다. 셋째, 인덱스가 사용자가 제어하는 환경 내에 존재하므로 데이터를 격리된 상태로 유지합니다. 마지막 이 점이 기업 팀에게는 핵심적인 요소입니다. 검색 계층은 사용자의 소유이며, 데이터가 임시 스캔 (ad hoc scans) 과정으로 유출되지 않고, 자체적인 액세스 제어 (access controls)를 적용할 수 있기 때문입니다.

벤치마크가 보여주는 것

주장에 수치를 부여하는 것이 도움이 됩니다. CustomGPT.ai는 500개의 PDF 워크플로를 대상으로 Claude Code의 통제된 테스트를 실행하여, 문서 수가 증가함에 따라 응답 시간, 비용, 완료율을 측정했습니다. Claude Code 앞에 프라이빗 RAG 계층을 배치했을 때, 결과는 4.2배 더 빨라졌고 3.2배 더 저렴해졌으며, 평균 응답 시간은 2분 31초에서 36초로 단축되었습니다. 신뢰성 격차 또한 규모가 커짐에 따라 더 벌어졌습니다. 검색 기능이 없을 때는 검색의 상당 부분이 합리적인 시간 내에 결과를 반환하지 못했지만, 검색 기능이 있을 때는 완료율이 일정하게 유지되었습니다. 방법론과 원시 데이터는 Claude 벤치마크에서 확인할 수 있습니다.

핵심은 특정 도구가 아닙니다. 모델이 아니라 검색 패턴 (retrieval pattern)이 수치를 변화시킨다는 점입니다.

직접 파일 검색 vs. 프라이빗 RAG

트레이드오프 (trade-off)는 작업이 어디에서 수행되는지에 달려 있습니다. 직접 파일 검색 (Direct file search)은 별도의 설정이 필요 없고 항상 파일의 실시간 상태를 반영하지만, 말뭉치 (corpus) 크기가 커질수록 지연 시간 (latency)이 증가하고, 더 많은 파일을 스캔함에 따라 쿼리당 비용이 상승하며, 데이터의 양(haystack)이 늘어날수록 근거 (grounding)가 약해집니다. 반면 MCP 상의 프라이빗 RAG 계층은 사전 수집 (ingest) 및 인덱싱 단계가 필요하며 문서가 변경될 때 재인덱싱을 해야 하지만, 그 대가로 라이브러리가 커져도 지연 시간이 거의 일정하게 유지되고, 쿼리당 비용이 낮고 안정적이며, 답변이 액세스 제어된 인덱스 내의 검색된 출처에 고정된 상태를 유지합니다.

간단히 말해, 한 가지 패턴은 라이브러리 크기에 따라 확장되고, 다른 한 가지 패턴은 질문의 난이도에 따라 확장됩니다.

직접 파일 검색(Direct file search)이 충분한 경우

인덱스(Index)는 관리해야 할 요소가 하나 더 늘어나는 것이므로, 필요하지 않은 곳에 RAG를 추가하지 마세요. 문서 세트가 몇 개에서 수십 개 정도의 소규모일 때는 직접 파일 검색(Direct file search)이 올바른 선택입니다. 또한 파일이 끊임없이 변경되어 에이전트가 실시간 작업 세트(Live working set)를 바탕으로 추론하기를 원하거나, 데이터 수집(Ingest) 단계가 속도만 늦출 뿐인 빠르고 탐색적인 작업을 수행할 때도 이 방식이 더 나은 선택입니다.

프라이빗 RAG(Private RAG)가 더 나은 패턴인 경우

문제의 형태가 바뀐다면 프라이빗 RAG(Private RAG) 계층을 고려하세요. 이는 보통 코퍼스(Corpus)가 크거나 계속 늘어나는 경우, 동일한 지식 베이스(Knowledge base)에 대해 반복적으로 쿼리를 던지는 경우, 대량 처리 시 질문당 비용이 중요한 경우, 또는 정확도와 데이터 프라이버시가 타협 불가능하여 허구의 답변(Fabricated answer)이 용납되지 않는 경우를 의미합니다. 실질적인 경험칙(Rule of thumb)을 들자면, 파일이 수십 개를 넘어서고 이를 자주 쿼리하게 되면 검색(Retrieval)은 선택 사항이 아닌 필수 사항이 됩니다.

구현 체크리스트

검색 계층을 추가하기로 결정했다면, 최소한의 경로는 다음과 같습니다. 먼저 코퍼스(Corpus)를 목록화하여 문서 수, 형식, 그리고 변경 빈도를 파악하세요. 이는 RAG가 정당화될 수 있는지 알려줍니다. 임의의 고정된 크기보다는 의미론적 경계(Semantic boundaries)를 따르는 청킹(Chunking) 전략을 선택하고, 모든 청크(Chunk)에 소스 메타데이터(Source metadata)를 유지하세요. 벡터 인덱스(Vector index)는 쿼리 시간 이전에 미리 구축해 둡니다. 해당 검색 기능을 MCP 서버로 노출하여 Claude Code가 이를 도구(Tool)로 호출하고 출처와 함께 가장 잘 일치하는 상위 청크들을 받을 수 있도록 합니다. 프롬프트(Prompt)를 제한하여 Claude가 검색된 청크로부터만 답변하도록 하고, 코퍼스에 실제로 답이 없는 경우에는 "찾을 수 없음(not found)"을 반환하게 하세요. 개선 사항을 추측하는 대신 증명할 수 있도록, 적용 전후의 응답 시간, 쿼리당 비용, 완료율(Completion rate)을 측정하세요. 마지막으로, 문서가 변경됨에 따라 인덱스를 어떻게, 언제 갱신할지 계획하세요.

벤치마크를 맥락과 함께 포함한 단계별 버전을 확인하려면, 문서 검색 시 Claude Code를 더 빠르게 만드는 방법에 대한 이 가이드가 유용한 참고 자료가 될 것입니다.

개발자 핵심 요약 (Developer takeaway)

대규모 문서 세트에서 Claude Code를 더 빠르게 만드는 것은 모델의 선택 문제가 아니라 아키텍처 (Architecture)의 선택 문제입니다. 규모가 작고 변화가 빠른 작업에는 직접적인 파일 검색 (Direct file search)부터 시작하세요. 코퍼스 (Corpus)가 커짐에 따라 지연 시간 (Latency)과 비용을 모니터링하고, 해당 곡선이 불리하게 변하는 즉시 MCP를 통해 Claude Code 앞에 프라이빗 RAG (Private RAG) 레이어를 구축하세요. 한 번 인덱싱 (Indexing)하고, 선택적으로 검색하며, 모델이 중요한 구절에 대해서만 추론 (Reasoning)할 수 있도록 하세요.