새로운 채팅이 시작될 때마다 에이전트는 사용자의 문서를 기억하지 못한 상태로 시작합니다. 에이전트는 문서를 다시 읽을 수 있는데, 이는 시간과 컨텍스트를 소모합니다, 혹은 기억하는 무언가에 문의할 수 있습니다. GroupDocs.Search.Mcp는 디스크에 로컬로 명명된 전체 텍스트 인덱스를 유지하며, 세션 및 컨테이너 재시작 사이에도 살아남습니다. 따라서 Claude Desktop, Cursor 또는 Copilot은 각 세션을 프로젝트의 문서가 이미 검색 가능하도록 시작하고, 파일이 변경될 때 한 번의 호출로 인덱스를 새로 고칩니다:

몇몇 계약서를 수정했습니다. 계약서 인덱스를 새로 고친 다음, 이제 벌칙을 언급하는 계약서가 어떤 것인지 알려 주세요.

구성 및 문제 해결을 포함한 단계별 버전은 문서에 있습니다: 파일이 변경될 때 문서 인덱스를 최신 상태로 유지하는 방법.

에이전트에게 “메모리”란 무엇을 의미하나요?

실제로는 두 가지가 있습니다: 대화 외부에 지속되는 상태와 그 상태를 저렴하게 유지하는 방법. 채팅 기록은 두 경우 모두 실패합니다: 세션이 끝나면 사라지고, 문서가 변경될 때 이를 업데이트해 주는 것이 없습니다. 검색 인덱스가 문서에 더 적합합니다. 문서와 같은 디스크에 존재하며, 문서를 로드하지 않고도 “어떤 파일이 X라고 말하는가”에 답하고, 점진적으로 새로 고칠 수 있습니다.

session 1    add_to_index --> index "contracts" --+
                                                 |  kept on disk in
session 2    search, get_text_fragments <--------+  /data/.groupdocs-search-
             (nothing is re-read)                    index/contracts
files edit   update_index --> re-reads changed, added, deleted files only
new project  create_index {"indexName":"legal-2026"} --> a separate index

새로 고침은 어떻게 작동하나요?

update_index는 인덱스를 디스크의 파일과 비교하고 변경된 부분만 다시 읽습니다. 아래는 두 호출 사이에 한 계약서에 벌칙 조항이 추가된 후 서버가 반환한 내용입니다:

-> get_index_info {"indexName":"contracts"}
<- { "documentCount": 5, "indexedPaths": [ "contracts" ],
     "documentsWithErrors": [], "status": "Ready" }

-> update_index {"indexName":"contracts"}
<- Index 'contracts' updated: 0 added, 1 updated, 0 removed;
   5 document(s) in the index.

-> search {"query":"penalty","indexName":"contracts"}
<- documentsFound 3, including the edited initech-nda.docx

카운트는 무슨 일이 일어났는지 알려 줍니다: 파일 하나가 다시 읽혔고, 다른 것은 변경되지 않았습니다. 삭제된 파일은 같은 호출에서 사라집니다.

프로젝트당 하나의 인덱스를 사용하는 이유는?

별개의 코퍼스는 별개의 답변을 받아야 하기 때문입니다. 올해 계약서에 대한 질문이 작년 초안이 나타나서는 안 되고, 한 클라이언트의 문서가 다른 클라이언트와 섞여서는 안 됩니다. 인덱스 이름은 비용이 적게 듭니다:

-> create_index {"indexName":"legal-2026"}
<- Index 'legal-2026' created. Add documents with add_to_index
   (indexName: 'legal-2026').

각 인덱스는 /data/.groupdocs-search-index 아래 폴더이며, 이름 없이 get_index_info를 호출하면 모두 나열됩니다. add_to_index가 처음 사용 시 인덱스를 생성하기 때문에 보통 create_index를 명시적으로 사용할 필요는 없습니다. 그러나 인덱스를 의도적으로 이름 짓는 것이 “인덱스”를 “이 프로젝트의 메모리”로 바꾸는 것입니다.

제거에 관한 하나의 규칙

엔진은 추가된 경로 자체를 제거하며, 그 안의 개별 파일은 제거하지 않습니다. 시도하면 서버가 명확히 이렇게 말합니다:

-> remove_from_index {"documentPath":"contracts/hooli-supply-terms.txt",...}
<- Removal failed for 'contracts/hooli-supply-terms.txt':
   'contracts/hooli-supply-terms.txt' is inside the indexed folder
   'contracts'. GroupDocs.Search removes whole indexed paths only: ...

따라서 설계 시 이를 고려하세요: 나중에 코퍼스의 일부(예: 연도, 클라이언트, 초안)를 삭제할 예정이라면, 해당 부분을 별도 경로(contracts/2025, contracts/2026)로 인덱싱하고 각각 독립적으로 제거할 수 있게 합니다. 디스크에서 파일을 삭제하고 update_index를 실행하면 해당 파일도 제거됩니다.

요청 없이 최신 상태 유지하기

create_index (optional)
      |
      v
add_to_index ---> search ---> get_text_fragments
      ^              ^
      |              |  get_index_info: counts, paths, status
update_index  (files changed on disk)
      |
remove_from_index  (only a path that was given to add_to_index)

새로 고침을 자동화하는 실용적인 세 가지 방법:

  1. 에이전트 지침에 포함. CLAUDE.md 또는 AGENTS.md에 한 줄을 추가하여, “파일이 변경되었을 수 있는 경우 답변하기 전에 이 프로젝트의 인덱스에 대해 update_index를 호출한다”고 명시하면 세션 시작 시 에이전트가 이를 수행합니다.
  2. 스케줄에 따라. MCP를 지원하는 자동화는 매일 밤 update_index를 호출할 수 있습니다; 변경 사항이 적을 경우 호출이 빠릅니다.
  3. 대량 복사 후. 한 번의 호출로 추가된 모든 파일을 잡아냅니다.

인덱스는 업그레이드 후에도 유지됩니다: GroupDocs.Search 22.7에서 26.8까지 만든 인덱스는 첫 사용 시 변환되며, 인덱스 옆에 백업이 보관됩니다.

에이전트가 결정하는 것과 인덱스가 수행하는 것

에이전트가 결정하는 것 인덱스가 수행하는 것
질문이 속한 인덱스 각 명명된 인덱스를 자체 폴더에 보관합니다
파일이 변경되었을 가능성 변경, 추가 및 삭제된 파일만 다시 읽습니다
검색할 단어와 시도할 변형 단어, 구문, 범위를 매치하고 찾은 용어를 보고합니다
인용할 컨텍스트 양 요청된 단어 수만큼 주변을 포함한 구절을 반환합니다
전달할 내용 없음: 카운트, 경로 및 텍스트만 반환하고 결론은 제공하지 않습니다

이 구분은 의도적인 것입니다. 판단은 모델에 남아 있고, 모델이 추론하는 사실은 검토 가능한 도구의 출력에서 나옵니다.

솔직한 제한 사항

  • 평가 모드에서는 인덱스가 최대 100개의 문서를 보유하고 검색 결과는 최대 10개까지 반환합니다. 인덱스를 신뢰할 근거로 사용하기 전에 get_license_status를 호출하세요.
  • 인덱스는 /data(또는 인덱스 볼륨)가 마운트된 호스트 폴더인 경우에만 지속됩니다; 그렇지 않으면 컨테이너와 함께 사라집니다.
  • 인덱스에는 문서 텍스트가 포함되어 있으므로 문서와 마찬가지로 보호하고 폐기해야 합니다.
  • Docker 전용; Linux에서는 --user "$(id -u):$(id -g)"를 추가하여 컨테이너가 인덱스를 쓸 수 있게 합니다.

자주 묻는 질문

에이전트가 세션 간에 내 문서를 기억하나요?
지속적인 인덱스가 있으면 가능합니다: 인덱스가 디스크에 남아 있어 다음 세션에서 아무것도 다시 읽지 않고 검색합니다.

파일이 변경될 때 인덱스를 재구축해야 하나요?
아니요. update_index는 변경, 추가 및 삭제된 파일만 다시 읽습니다.

읽기 전용 문서와 인덱스를 별도로 유지할 수 있나요?
예. 문서는 읽기 전용으로 마운트하고, /index에 쓰기 가능한 폴더를 마운트한 뒤 GROUPDOCS_MCP_INDEX_PATH=/index를 설정합니다.

더 깊이 파고들기