Backoffice AI Agent 구축기: RAG+MCP 기반 플레이스AI 특화 지식 검색 시스템

플레이스AI 플랫폼(PAIP) MLOps 팀은 Backoffice 전용 RAG+MCP 의미검색 에이전트를 구축해 흩어진 기술 문서와 이슈를 빠르게 찾을 수 있는 지식 검색 환경을 만들었다. 목표는 OJT와 협업 과정에서 문서 탐색 시간을 줄이고, 팀 내 기술·서비스 간 지식 격차를 완화하는 것이었다.

데이터 계층은 OpenSearch를 원본 저장소와 로그 저장소로, Milvus를 벡터 저장소로 두는 구조로 설계했다. 수집 대상은 GitHub Issues, Confluence Wiki, Milvus·vLLM·GoFastMCP 같은 공식 문서였고, 수집-정제-청킹-임베딩-적재를 자동화한 Data Loader와 임베딩 실험을 분리한 Milvus Loader를 통해 운영했다. Crawl4AI로 본문 중심 크롤링을 적용하고, 증분 업데이트 API를 둬 최신성을 유지했다.

현재까지 5개 데이터 소스에서 11,173건의 문서를 적재했다. 이 구조는 내부 협업 문서와 외부 기술 문서를 함께 흡수해, 서비스별로 분산되던 맥락을 하나의 검색 계층으로 묶는다.

검색 계층은 단일 검색의 한계를 보완하기 위해 Dense + Sparse 하이브리드 검색으로 구성했다. BEIR-SCIFACT와 LLM-as-a-Judge 평가 체계를 먼저 만들고, 20개 실험을 통해 임베딩 모델, 인덱스, 청킹 전략을 비교했다. 최종적으로 HNSW 인덱스, 2048 토큰 Chunk, RRF(Reciprocal Rank Fusion), 그리고 LLM Reranker를 조합해 검색 결과의 문맥 품질을 끌어올렸다.

특히 청킹은 Markdown header 분할보다 TokenTextSplitter가 더 안정적이었고, 2048 토큰이 긴 회의록과 로그 문서에서 더 좋은 평가를 받았다. 재정렬 단계에서는 Medium 모델 Reranker가 Judge 점수를 평균 +0.7점 개선해, LLM이 참조할 최종 Context를 더 정밀하게 만들었다.

인터페이스는 MCP(Model Context Protocol) 기반으로 통일했다. FastMCP 위에 Search Module과 Document Module을 분리해, 벡터 검색과 원문 조회를 표준화된 Tool로 제공했고, Cursor나 Dify 같은 환경에서도 같은 방식으로 호출할 수 있게 했다. 또한 mcp_log를 OpenSearch에 쌓아 질의, 도구 호출, 응답 시간, 반환 문서를 추적했다.

로그를 분석한 결과, 검색기 성능보다 비정형 질의 자체가 품질 저하의 주요 원인이라는 점이 드러났다. 이를 해결하기 위해 Smart Search를 도입해 질의를 먼저 구조화했다. 시간 정규화, 작성자 이름 변형 생성, 검색어 재작성, 문서 타입 필터링을 수행한 뒤 Hybrid Search와 Rerank를 순차적으로 호출해, 검색부터 응답까지를 Agentic RAG 흐름으로 완성했다.

운영 결과는 분명했다. 응답 만족도는 2배, 응답 속도는 1.4배, 토큰 사용량은 66% 감소, 툴 호출 수는 49% 감소했다. 검색 품질과 운영 효율을 함께 끌어올리며, 백오피스 지식 탐색을 실제 업무에 쓸 수 있는 수준으로 끌어올렸다.