6. MCP (모델 컨텍스트 프로토콜) 활용 설계 - 100-hours-a-week/20-real-wiki GitHub Wiki

📌 MCP 미적용 아키텍처 및 대응 전략

🔧 현행 아키텍처 구성

구성 요소	설명
📁 공지사항 저장	.md 파일로 저장 (Obsidian 등으로 관리 가능)
📤 벡터화 처리	.md 문서 → 임베딩 → FAISS에 저장
🔍 검색 및 응답	사용자 질문 → 문서 검색 (RAG) → LLM이 답변 생성
📦 외부 연계	없음 — 모든 데이터는 로컬 문서 기반으로 처리됨

🔄 외부 연계 요구 발생 시 대응 (MCP 미적용 상태)

요구 상황	현행 대응 방식	한계
공지사항 업데이트	수동 스크립트로 .md 파일 갱신	LLM이 직접 작성하거나 수정할 수 없음
최신 공지 자동 반영	수동으로 갱신	실시간 자동화 수준은 낮음
조직 정보, 일정 등 요청	현재는 비지원 (구조상 불필요)	향후 도구 필요 시 구조 전환 필요

➡️ 현재 요구사항은 모두 정적 문서 처리로 해결 가능하며, 외부 시스템 호출 시나리오는 없음

✅ 기존 방식(RAG 기반)만으로 충분한 이유

1. 문서 기반 질의응답이라는 문제 정의에 부합

   • 질문은 대부분 공지나 문서 내 정의된 내용을 기반으로 함
   • 복잡한 작업 흐름이나 시스템 상태 변경은 필요 없음

2. 구현 단순성 + 유지보수 용이

   • LLM → RAG 구조만으로 작동
   • FastAPI, MCP 서버 등 추가 컴포넌트 불필요

3. 보안 및 인프라 복잡도 감소

   • 외부 API 연동 없음 → 인증/권한 관리 불필요
   • 모델과 문서만 관리하는 간단한 구조

📈 미래 요구 증가 시 대응 계획

발생 가능 요구	대응 방안
🧠 공지사항 자동 등록	update_notice 기능을 MCP 툴로 도입 가능
📅 일정/DB 질의 추가	필요 시 MCP 서버 기반 API 구조 채택 가능
🧩 복잡한 멀티툴 에이전트	기존 RAG 파이프라인에 MCP 연동 추가하여 확장 가능

✅ 현재는 RAG 중심의 단순 아키텍처

🔜 미래에는 필요에 따라 MCP로 점진적 확장하는 전략이 현실적이고 유연함

🧠 결론: 왜 MCP는 지금 필요하지 않은가?

• 현재 팀 요구사항: 공지사항을 문서 기반으로 QA
• 외부 API 호출이나 툴 실행은 없음
• 따라서 MCP 도입은 불필요

MCP는 유연한 툴 호출에 강력한 프로토콜이나, 현재 구조는 문서 → 벡터화 → RAG 검색 → 답변이라는 안정적인 구성으로 충분합니다.

🔹 단, 향후 도구 통합 수요 발생 시 자연스럽게 MCP 도입 가능

➡️ RAG 구성과 문서 저장소는 모듈화하여 확장에 대비하는 것이 바람직합니다.