🤖 6단계 : MCP 적용 가능성 점검 - 100-hours-a-week/7-team-ddb-wiki GitHub Wiki

본 프로젝트는 추천 서비스인 만큼 다양한 외부 시스템(데이터베이스, 벡터 검색, 실시간 API 등)과의 연동이 필요하지만, 현재 구조에서 충분히 대응 가능한 수준이며 복잡성을 증가시키지 않도록 하기 위해 MCP를 미적용할 것으로 결정

---

• MCP 도입은 명확한 인터페이스와 통신 계층을 제공하나, 별도의 MCP 서버, 프로토콜 정의, 툴 서버 구성 등 초기 구축 리소스가 큼
• 현재 팀의 리소스와 개발 범위를 고려할 때, MCP는 과도한 설계임

• FastAPI 기반의 라우터 및 서비스 레이어에서 외부 시스템(PostgreSQL, Vector DB, 파일 시스템 등)에 직접 연동 가능
• 기능이 많지 않고, 도구 연동 수가 제한적이므로, 별도 중계 계층 없이도 충분히 관리 가능

• 서비스 특성상 툴 추가나 외부 시스템 변경이 자주 발생하지 않으며, 모든 기능이 내부 데이터 및 고정된 도구로 처리 가능
• 정형화된 연동 방식이 요구되는 복잡한 MLOps나 멀티툴 파이프라인 환경이 아님

---

구성 요소	처리 방식
DB 접근	FastAPI 서비스 계층에서 직접 SQLAlchemy 등으로 처리
벡터 검색	Python 코드에서 embedding 후 FAISS 또는 Chroma 직접 호출
외부 API	필요시 requests 등으로 직접 호출, 라우터 별도 정의 가능

이 방식은 구현이 간단하고 직관적이며, 개발 속도와 운영 효율 면에서 유리합니다.

---

• 향후 기능 확장이나 복잡한 워크플로우가 추가될 경우에는 MCP와 유사한 구조 또는 메시지 중계 방식 도입을 재검토할 수 있음
• 하지만 현 시점에서는 MCP 도입보다 간단하고 명확한 구조 유지가 우선적으로 판단됨

---

MCP는 외부 툴 연동을 구조화하고 확장 가능성을 높이는 유용한 방식이나, 현재 프로젝트의 범위, 리소스, 필요성 기준으로는 도입하지 않음이 타당

• 현 구조는 간결하고 유지보수가 용이
• MCP 없이도 모든 외부 연계 및 기능 구현이 무리 없이 가능함

따라서, 본 프로젝트는 MCP를 사용하지 않으며, 기존의 FastAPI 기반 구조로 외부 연동을 직접 처리하는 방식을 유지