많은 비즈니스 지식이 이메일에 존재하며, 필요한 부분은 보통 첨부 파일에 있습니다: 견적서, 서명된 수정 계약, 수정된 일정표. GroupDocs.Search.Mcp는 Docker에서 로컬로 실행되며 이메일 파일 및 아카이브(PST, OST, MSG, EML)를 열어 모든 메시지와 모든 첨부 파일을 인덱싱하므로 Claude Desktop, Cursor 또는 Copilot이 아카이브를 제자리에서 검색하고 일치 항목이 어느 첨부 파일에서 왔는지 정확히 알려줄 수 있습니다:

메일 폴더를 인덱싱하십시오. 어떤 메시지가 가격 인상을 언급하고 있으며 정확히 무엇이라고 말하고 있나요?

단계별 구성 및 문제 해결 방법은 문서에 나와 있습니다: AI 에이전트와 함께 이메일 아카이브 및 첨부 파일을 로컬에서 검색하는 방법.

에이전트에게 이메일이 어려운 이유는?

아카이브는 컨테이너 안의 컨테이너이기 때문입니다. PST는 폴더를 보관하고, 폴더는 메시지를 보관하며, 메시지는 첨부 파일을 보관하고, 첨부 파일은 자체적으로 Word 파일, PDF 및 스프레드시트입니다. 파일 도구를 가진 에이전트는 하나의 큰 바이너리 파일만을 봅니다. 아카이브를 먼저 개별 파일로 내보내면 작동하지만 느리고, 민감한 데이터가 디스크에 복제되며, 아카이브가 변경될 때마다 다시 해야 합니다. 또한 모델은 PST를 전혀 읽을 수 없습니다.

검색 엔진이 중첩 구조를 스스로 처리합니다. 각 메시지와 각 첨부 파일이 검색 가능한 항목이 되며, 결과는 컨테이너가 어디에 있는지와 일치 항목이 내부 어디에서 발견됐는지를 모두 기록합니다.

첨부 파일 내부의 일치는 어떻게 보이나요?

다음은 세 개의 EML 메시지로 테스트했을 때 서버가 반환한 내용입니다. “price increase”라는 구절은 그 중 하나에 첨부된 Word 견적서 안에만 나타나며, 메시지 본문은 단지 *“please find the updated quotation attached”*라고만 적혀 있습니다.

-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.

-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
     { "filePath": "mail/2026-09-18-re-q3-pricing.eml",
       "innerPath": "quotation-Q-2026-118.docx",
       "occurrences": 1 } ] }

-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
   (1 occurrence(s)) ===
     …Due to raw material costs we announce a price increase
   of 6 percent from 2026-11-01.…

filePath는 메시지이며, innerPath는 첨부 파일입니다. 에이전트는 “Contoso의 Re: Q3 pricing 메시지, 첨부된 quotation Q‑2026‑118: 2026년 11월 1일부터 6% 인상”이라고 답변할 수 있으며, 그 문장의 모든 부분을 추적할 수 있습니다.

mail/2026-09-18-re-q3-pricing.eml          <- filePath
  |- body: "please find the updated quotation attached"
  '- attachment: quotation-Q-2026-118.docx  <- innerPath
        "...we announce a price increase of 6 percent..."

메일에서 작동하는 질문들

일반적인 쿼리 언어가 적용되며, 서신 작업에 특히 유용한 몇 가지 패턴이 있습니다. 아래 모든 예시는 동일한 테스트 메일함을 대상으로 확인되었습니다:

  • “Fabrikam에서 보낸 메시지 중 배송 지연을 언급한 것이 있나요?”: fabrikam AND delay. 발신자 주소는 메시지와 함께 인덱싱되므로 contoso도 본문에 회사를 언급하지 않은 인보이스를 찾을 수 있습니다.
  • “order 77812를 언급한 모든 이메일을 찾으세요”: 77812. 전체 숫자는 단어로 취급됩니다.
  • “10월에 마감되는 인보이스는 어떤 것이 있나요?”: invoice AND content: daterange(2026-10-01 ~~ 2026-10-31). 이는 메시지 텍스트에 쓰인 날짜와 일치하며, 여기서는 *“due on 2026-10-22”*와 매치됩니다. content: 접두사가 중요합니다: 이를 빼면 날짜 범위가 각 파일에 대해 엔진이 기록한 날짜와도 매치됩니다.

메일은 다른 어떤 것보다 로컬 환경이 더 중요한 이유

이메일은 민감한 자료가 집중된 곳입니다: 개인 데이터, 협상 내용, 인사 스레드, 법률 자문 등. 메일함을 서비스에 업로드하거나 동기화해야 하는 검색 도구는 많은 팀에게 전혀 사용할 수 없습니다. 여기서는 아카이브를 머신 내 컨테이너에 읽기 전용으로 마운트하고, 그곳에서 인덱싱 및 검색을 수행합니다. 에이전트가 답변에 인용하는 텍스트만이 외부로 나가며, 로컬에 호스팅된 모델을 사용한다면 그조차도 발생하지 않습니다.

보다 견고한 설정을 위해 아카이브를 읽기 전용으로 마운트하고 인덱스에 별도 볼륨을 할당합니다:

docker run --rm -i \
  -v /srv/mail:/data:ro \
  -v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
  ghcr.io/groupdocs-search/search-net-mcp:latest

대규모 아카이브 범위 지정

수만 개의 메시지를 포함한 아카이브도 라이선스가 있으면 문제없이 인덱싱할 수 있지만, 신중히 접근하는 것이 좋습니다. 폴더별 또는 연도별(mail/2025, mail/2026)로 별도 경로에 인덱싱하면 연도별로 삭제하거나 재구성할 수 있습니다. 엔진은 개별 파일이 아니라 전체 인덱스 경로를 제거하기 때문입니다. 메일은 계약서나 보고서와 별도의 인덱스로 유지하여 서신 관련 질문이 다른 모든 자료를 뒤섞지 않게 합니다. 아카이브가 성장하면 update_index가 기존 파일을 다시 읽지 않고 새로운 메시지만 추가합니다.

솔직한 제한 사항

  • 평가 모드에서는 인덱스에 최대 100개의 문서만 보관되며 검색 결과는 최대 10개까지 반환되고, 모든 메시지와 첨부 파일이 카운트됩니다. 따라서 실제 아카이브에는 라이선스가 필요합니다. 먼저 get_license_status를 호출하세요.
  • 큰 PST는 인덱싱에 시간이 걸립니다: 모든 메시지와 첨부 파일을 열어야 하기 때문입니다. 한 번 인덱싱한 뒤 update_index를 사용하세요.
  • 텍스트 레이어가 없는 스캔된 첨부 파일은 파일 속성만으로 인덱싱되며 OCR은 제공되지 않습니다.
  • Docker 전용이며, Linux에서는 --user "$(id -u):$(id -g)" 옵션을 추가해야 합니다(위의 읽기 전용 설정을 사용하지 않을 경우).

FAQ

Outlook 없이 AI로 PST 파일을 검색할 수 있나요?
예. 엔진은 PST, OST, MSG 및 EML을 직접 읽으며 Outlook은 전혀 관여하지 않으며, 아무것도 내보내지 않습니다.

이메일 첨부 파일 내부도 검색하나요?
예. 첨부 파일은 해당 메시지의 항목으로 인덱싱되며, 내부 일치는 innerPath를 통해 첨부 파일 이름이 반환됩니다.

내 메일함이 어디에든 업로드되나요?
아니요. 로컬 컨테이너 내부에서만 읽히며, 에이전트가 인용한 구절만 모델 제공자에게 전달됩니다.

더 깊이 파고들기