Often, no. 계약서, 보고서 또는 이메일 폴더에 대해 전체 텍스트 검색 도구를 갖춘 AI 에이전트가 올바른 파일을 찾아 일치하는 구절만 읽고 인용하며, 인덱스는 임베딩 모델이나 벡터 저장소 없이 로컬에서 실행됩니다. GroupDocs.Search.Mcp는 Claude Desktop, Claude Code, Cursor 또는 Copilot에 한 Docker 명령으로 해당 도구를 제공합니다:

계약서 폴더를 인덱싱한 다음, 계약서 중 해지 벌금이 언급된 것을 알려주고 해당 조항을 인용해 주세요.

구성 및 문제 해결이 포함된 단계별 버전은 문서에 있습니다: How to search documents with AI agents using MCP.

왜 모두가 먼저 임베딩을 선택할까?

“retrieval‑augmented generation”(RAG)이 레시피로 등장했기 때문입니다: 문서를 청크로 나누고, 각 청크를 임베딩한 뒤, 벡터에 저장하고, 질문을 임베딩한 뒤 가장 가까운 청크를 찾아 프롬프트에 붙여 넣는 방식입니다. 이것은 작동하고, 질문이 문서와 전혀 다른 방식으로 표현될 때는 올바른 도구입니다. 하지만 이것은 임베딩 모델 호출, 저장소 운영, 청크 튜닝, 그리고 문서가 바뀔 때마다 재임베딩 작업이 필요한 파이프라인입니다. “내 300개의 계약서 중 해지 벌금이 언급된 것이 어느 것인가”와 같은 경우, 그 기계는 검색 인덱스가 직접 답할 수 있는 질문을 처리합니다.

직관과 일치하는 증거가 나타났습니다. 2025년 말 arXiv에 발표된 연구(Keyword search is all you need)는 에이전트에게 폴더에 대한 키워드와 정규식 검색만을 수행하게 하고 이를 표준 RAG 파이프라인과 비교했습니다: 벡터 데이터베이스 없이도 RAG 점수의 90% 이상을 달성했으며, 자주 변경되는 컬렉션에 더 적합했습니다. 코딩 에이전트는 이미 실무에서 이 패턴을 보여주었습니다: grep으로 검색하고, 결과를 정제한 뒤 다시 검색합니다.

에이전트는 대신 무엇을 하나요?

세 가지 호출. GroupDocs.Search.Mcp는 여덟 가지 도구를 제공하며, 루프에는 그 중 세 가지가 필요합니다:

user              agent                         Search MCP server
 |  "Which contracts mention a termination penalty?"           |
 |---------------->|                                           |
 |                 |-- add_to_index ------------------------->|  reads the
 |                 |   {"documentsPath":"contracts",           |  files once,
 |                 |    "indexName":"contracts"}               |  stores text
 |                 |<- "5 document(s) added, 5 in the index" --|
 |                 |-- search ------------------------------->|
 |                 |   {"query":"termination AND penalty"}     |
 |                 |<- {"documentsFound":3, "documents":[ ... |  which files
 |                 |-- get_text_fragments ------------------->|
 |                 |   {"query":"\"termination penalty\""}     |
 |                 |<- === contracts/acme-...-agreement.pdf ===|  the passages
 |<- "Two contracts carry one: Acme (3 monthly fees, 12.3),    |
 |    Globex (50% of the remaining fees). Initech excludes it."|

add_to_index는 파일을 한 번 읽고 텍스트를 디스크에 있는 명명된 인덱스에 저장합니다. search는 일치하는 파일을 발생 횟수와 함께 JSON으로 반환합니다. get_text_fragments는 각 일치 항목을 몇 단어의 컨텍스트와 함께 반환하므로, 에이전트는 전체 계약서를 로드하지 않고 조항을 인용할 수 있습니다.

다음은 다섯 개의 합성 계약서에 대해 테스트한 서버 실제 반환값입니다:

-> search {"query":"termination AND penalty","indexName":"contracts"}
<- documentsFound 3: acme-master-services-agreement.pdf,
   globex-consulting-agreement.docx, initech-nda.docx

-> get_text_fragments {"query":"\"termination penalty\"",...}
<- === contracts/acme-master-services-agreement.pdf (1 occurrence(s)) ===
     …a termination penalty of three monthly fees applies, payable
     within 30…
   === contracts/globex-consulting-agreement.docx (1 occurrence(s)) ===
     …Early termination penalty: the Client pays 50 percent of the fees…

세 번째 계약서를 주목하세요. Initech NDA는 termination AND penalty와 일치했는데, 이는 “해지와 관련된 비용이나 벌금이 없습니다” 라고 명시했기 때문입니다. 구절 자체가 매치를 의미하게 만들며, 구절을 읽는 에이전트는 그렇게 말합니다. 이것이 grounding입니다: 답변의 모든 주장이 파일과 열어볼 수 있는 문장으로 연결됩니다.

각각의 접근 방식은 언제 강점이 있나요?

Embedding pipeline                       Agentic full-text search
-------------------------------------    -------------------------------------
split, embed, store in a vector store    add_to_index: a local full-text index
embed the question, take top-k chunks    agent searches, refines, searches again
paste the chunks into the prompt         get_text_fragments: quoted passages
re-embed when documents change           update_index re-reads what changed
needs an embedding model and a store     no model calls, no network at runtime
matches meaning; ranking is opaque       matches words; every hit is explainable

전체 텍스트 검색은 질문과 문서가 공유하는 단어가 없을 때 실패합니다: “우리에게 위험한 계약서는 무엇인가?” 라는 질문에는 키워드가 없습니다. 반면 어휘가 공유될 때는 강력합니다. 이는 대부분의 사용자가 자신의 문서에 대해 묻는 질문—조항 이름, 제품, 고객, 청구서 번호, 날짜 범위—에 해당합니다. 쿼리가 놓치면 에이전트는 renewal OR renews와 같이 시도하거나 퍼지 매치를 사용합니다. 서버는 도움이 됩니다: 인용되지 않은 두 단어 쿼리는 GroupDocs.Search에서 아무 결과도 반환하지 않으며, 빈 결과에 hint가 포함되어 에이전트에게 구문을 인용하도록 알려줍니다.

어떤 질문에 어떤 도구를 사용하나요?

사용자가 묻는 내용 에이전트가 호출하는 도구
“이 폴더를 인덱싱해 주세요” add_to_index
“어떤 파일에 X가 언급돼 있나요?” search
“X에 대해 뭐라고 적혀 있나요?” get_text_fragments
“파일이 변경됐으니 새로 고쳐 주세요” update_index
“초안 폴더를 잊어버려 주세요” remove_from_index
“인덱스에 뭐가 있나요?” get_index_info
“별도 인덱스를 만들고 싶어요” create_index
“왜 결과가 10개만 나오나요?” get_license_status

이 인덱스는 PDF, Office, OpenDocument, HTML, 그리고 이메일 아카이브(PST, OST, MSG, EML)와 그 첨부 파일을 포함해 82가지 형식을 이해합니다.

어떻게 실행하나요?

claude mcp add groupdocs-search -- docker run --rm -i \
  -v /path/to/documents:/data ghcr.io/groupdocs-search/search-net-mcp:latest

Cursor, Claude Desktop, GitHub Copilot이 포함된 VS Code 및 기타 클라이언트는 자체 설정 파일에서 동일한 컨테이너를 사용합니다: Register in AI clients. Linux에서는 --user "$(id -u):$(id -g)" 옵션을 추가해 컨테이너가 인덱스를 폴더에 쓸 수 있도록 합니다. 서버는 GroupDocs.Search 26.10 엔진을 실행하며, 새로운 인덱스 형식 덕분에 인덱스 크기가 작아지고 메모리 사용량이 약 절반으로 감소했습니다(release notes).

솔직한 제한 사항

  • 평가 모드에서는 인덱스에 최대 100개의 문서만 보관되며, 검색 결과는 최대 10개만 반환됩니다; 모든 응답에 이를 명시합니다. 먼저 get_license_status를 호출하세요.
  • 의미 기반 검색이 아니라 전체 텍스트 검색이므로 의미가 아닌 단어를 매치합니다.
  • OCR이 지원되지 않습니다: 텍스트 레이어가 없는 스캔 PDF는 파일 속성만 인덱싱됩니다.
  • Docker 이미지 형태로만 제공됩니다(패키지는 NuGet 용량 제한을 초과합니다).

FAQ

Claude가 로컬 문서를 업로드 없이 검색할 수 있나요?
네. 서버는 로컬 컨테이너에서 실행되며 마운트한 폴더를 읽습니다; 모델에 전달되는 것은 에이전트가 인용한 구절뿐입니다.

이게 RAG인가요?
검색‑증강은 되지만 에이전트 방식입니다: 모델이 언제 무엇을 검색할지 스스로 결정하고, 임베딩 대신 전체 텍스트 인덱스를 사용합니다.

문서가 변경되면 어떻게 되나요?
에이전트에게 새로 고침을 요청하면 됩니다. update_index는 변경·추가·삭제된 파일만 다시 읽습니다.

더 깊이 파고들기