AI & LLM

[개인 Agentic 비서 만들기 1부] 14,183건의 메일, LLM + Dify 로 활용 가능할까요?

Oli-LAB 2026. 7. 12. 23:44

개인사업을 하거나 바쁜 직장 생활을 하다 보면 누구나 한 번쯤 겪는 고통이 있습니다. "그때 그 메일, 도대체 어디 있지?" 급할 땐 보이지 않고, 나중에야 발견되는 데이터의 미스터리. Outlook의 검색 기능만으로는 해결되지 않는 이슈를 해결하기 위해, Synology Mailplus, Ollama, Anything LLM을 거쳐 최종적으로 Dify에 정착하기까지의 생존기를 기록합니다. 이번 1부에서는 하드웨어 한계를 극복하고 맵 리듀스(Map-Reduce) 아키텍처로 최적화한 데이터 분석 워크플로우 구축 과정을 작성해 보고자 합니다. 

 

① 7주일간의 퇴근 후 시간을 DIfy가 가져갔습니다. 

 

처음에는 큰 생각 없이 접근하였습니다. AnythingLLM 에서 인덱싱에 이슈가 발생한 이후, 검색을 하다가 Dify를 발견하고 “한번 사용해 보자” 가 시작이었습니다. 근데 설치부터 에러가 발생하고, 7주일간 퇴근하고 계속 시간을 투입하여 이제야 간신히 완료를 하였습니다. 

 

나중에 작성할 계획이긴 하나, Markdown 파일의 수가 늘어날 수록 AnythingLLM 을 사용한 활용은 쉽지가 않은것으로 보여집니다. (단순하게 A  메일을 찾아줘! 는 가능하나, “A 라는 원인으로 발생한 문제에 대해 찾아서 정리해줘” 는 어려운거 같았습니다)

 

설치 환경은 아래와 같습니다. 

. I5 8500 / 32G 시스템 메모리 / RTX 5060 Ti 16G  / WIndows 11 + Docker Desktop 

 

설치시 아래와 같이 이슈가 발생하였습니다.

. 아무생각없이 System32 폴더에서 Pull 명령 실행하여 삭제 후 재 설치 이슈

. 명령프롬프트(CMD)로 Docker에 Dify 설치시 설치 중단 Error 발생

. 설치 후, Dify의 기본 Port가 80으로 외부 도메인 접속시 문제 발생

. 설치후, Ollama 의 Gemma4:26b 와 연동 관련 문제 발생

명령 프롬프트(CLI)에서 'docker compose up -d' 명령어를 실행한 화면. redis, nginx, api, db_postgres 등 Dify 구동에 필요한 도커(Docker) 이미지들의 다운로드(Pulled)가 완료되었으며, 각 컨테이너 네트워크가 생성(Created)되고 컨테이너가 실행(Started) 및 대기(Waiting) 중인 상태를 보여주는 터미널 출력 결과

 

설치후 Workflow 를 설계시에도 아래와 같이 문제가 발생하였습니다.

. Workflow 가 실행되다가 아무 Error 없이 실행 중단

. Workflow 가 실행되던 중 PC 다운 (아마도 OOM, Out of Memory 였던듯 합니다)

. 청크 관련 설정 문제로 5번이나 파일 인덱싱 재 실행

. 분명 markdown 파일에는 내용이 있으나, 검색시 “찾을 수 업음” 으로 휴 소리 나오게 하는 문제

. Gemma4:26b 만 사용할 경우 발생했던 H/W 부족 이슈

 

제가 가진 H/W 성능으로는 고민을 해 가면서 설정을 해야 했었습니다.

 

② 하드웨어 한계를 극복한 3단계 워크플로우 설계

 

단순히 모델을 연동하는 것만으로는 부족했습니다. i5-8500, 32GB RAM, 16GB VRAM이라는 제 하드웨어 환경에서,  14,183건의 마크다운 파일을 검색하고 추론하는 과정은 그야말로 '자원과의 싸움'이었습니다. 워크플로우 실행 중 이유 없는 중단, PC의 강제 종료(OOM 에러), 그리고 인덱싱 재실행만 5번을 반복하며 제가 도달한 결론은 '모델의 역할 분담을 통한 맵리듀스(Map-Reduce) 아키텍처'였습니다.

 

무거운 모델 하나에 의존하기보다, 각 노드의 목적에 맞는 최적의 모델을 배치하여 VRAM 부하를 최소화했습니다.

 

- 전처리: 토큰 다이어트
검색 노드(Knowledge Retrieval)가 찾아온 수만 토큰의 원문을 LLM에 바로 넣는 것은 안될 행위였습니다. 파이썬 코드 노드를 통해 과거 회신 이력(--Original Message--)과 서명 등 불필요한 노이즈를 쳐냈습니다. 또한, 역추적을 위해 본문 앞에 [출처: 파일명] 태그를 강제로 삽입해, 결과의 신뢰성을 확보하는 메타데이터 이식 작업을 거쳤습니다.

 

- 단서 추출: 맵(Map) 단계 (Iteration 내부의 LLM 노드)
반복(ITERATION) 노드 내부에서는 무거운 모델 대신 deepseek-r1:14b를 활용했습니다. 이 모델은 전체를 요약하는 대신, "질의와 관련된 일시, 부품명, 불량 현상만 1줄로 추출하고 없으면 PASS"라는 단순 필터링 역할에만 집중하게 했습니다. 또한 DeepSeek 특유의 <think> 추론 태그까지 제거하여 컨텍스트 창을 최적화했습니다. 덕분에 반복 실행 중에도 메모리 점유율을 안정적으로 유지할 수 있었습니다.

 

- 최종 리포트: 리듀스(Reduce) 단계 (LLM 2 노드)
루프를 돌며 추출된 유의미한 'Fact' 조각들만 노드를 통해 하나의 텍스트로 결합한 후. 전체 데이터를 1,000자 이내로 압축하여 Gemma:4:26b 를 사용하여 추론을 진행하였습니다. 이렇게 하니 이슈없이 결과를 볼 수가 있었습니다. 

Dify 기반의 맵리듀스(Map-Reduce) 워크플로우 전체 설계 화면. 'USER INPUT' 노드를 시작으로 'KNOWLEDGE RETRIEVAL' 노드와 전처리용 'CODE 4' 노드를 거침. 이후 'deepseek-r1:14b' 모델과 'CODE 2' 노드가 포함된 'ITERATION(반복)' 노드로 연결됨. 추출된 데이터는 'CODE 3' 노드를 거쳐 'gemma4:26b' 모델이 지정된 'LLM 2' 노드에서 최종 처리된 후 'OUTPUT'으로 도출되는 노드 간 연결 흐름도

 

[워크플로우 요약]

. 시작(User Input) → 지식 검색(Retrieval) → 전처리(Code Node)

. 추출(Iteration 내 DeepSeek 14b) → 취합(Code Node)

. 최종 작성(LLM2 - Gemma4:26b) → 완성(Output)

 

이 구조를 완성하기까지 7일이라는 시간이 녹아있습니다. 설치 중 겪었던 System32 폴더에서의 삽질, 80번 포트 충돌 문제, 그리고 5번의 인덱싱 재실행까지... 비록 휴ㅠㅠ 과정이었지만,결과적으로 하드웨어 업그레이드 없이 데이터 분석이 가능한 부분을 확인하였습니다.  이제 그 다음으로 청크 에러 해결에 대해 작성해보겠습니다.

 

2장. LLM + Dify, 청크 에러 이것도 이해가 쉽지 않았습니다.