6. MCP 설계 - 100-hours-a-week/6-nemo-wiki GitHub Wiki
1. MCP를 도입하지 않은 이유
1.2 현재 서비스 구조와 복잡도
- 단일 FastAPI 서버 내에서 로컬 모델 호출 및 외부 시스템(ChromaDB, Redis) 접근을 직접 처리.
- 텍스트 생성, 관심사 추출 등 모델의 기본 작업 외에 별도 외부 도구 호출이 요구되지 않음.
- 요청과 응답 포맷이 단순하고 일관적이어서 추가적인 표준화 계층이 불필요.
1.2 개발 및 운영 효율성
- FastAPI 서버만으로 모든 외부 시스템 접근이 가능하여, MCP 서버 구축 및 운영 부담이 없음.
- 초기 개발 속도, 유지보수 편의성을 고려했을 때 복잡한 프로토콜 도입은 비효율적이라고 판단.
- 장애 대응도 FastAPI 내 표준 HTTP 에러 핸들링 체계로 충분히 대응 가능.
2. 현재 외부 연계 처리 방식
| 항목 | 현재 처리 방식 |
|---|---|
| 모델 호출 | FastAPI 서버가 로컬 모델에 직접 요청 |
| 벡터 검색 | FastAPI 서버가 ChromaDB에 직접 질의 |
| 캐시 조회/저장 | FastAPI 서버가 Redis에 직접 접근 |
| 컨텍스트 관리 | 요청별 단순 데이터 전달 및 반환 |
| 오류 처리 | FastAPI 서버 내부 에러 핸들링 및 HTTP Status 관리 |
3. MCP를 적용하려 할 경우 필요한 구조 변화
3.1 FastAPI 역할 변화
| 항목 | 현재 구조 | MCP 적용 시 구조 |
|---|---|---|
| 외부 도구 호출 방식 | FastAPI 서버가 직접 Redis/ChromaDB 접근 | FastAPI는 MCP 서버에 요청, MCP 서버가 Redis/ChromaDB 호출 |
| 로직 위치 | FastAPI 내부에 모든 외부 시스템 로직 포함 | FastAPI는 단순히 MCP 요청 생성 및 결과 수신 역할 |
| 코드 복잡도 | 다양한 도구별 직접 로직 관리 | MCP 프로토콜로 일관화된 요청/응답 처리 |
> FastAPI 서버가 외부 시스템과 직접 통신하는 구조를 버리고, MCP 서버를 통해 간접 통신하도록 재설계해야 함.
3.2 컨텍스트 포맷 표준화
| 항목 | 현재 구조 | MCP 적용 시 구조 |
|---|---|---|
| 요청 포맷 | FastAPI 내부 코드별 자유 형식 | MCP 표준 포맷(Context Object) 사용 필요 |
> 모든 외부 요청은 MCP가 요구하는 "Tool 호출 요청 포맷"으로 변환해서 보내야 합니다.
3.3 LLM 호출 방식 변화
| 항목 | 현재 구조 | MCP 적용 시 구조 |
|---|---|---|
| 모델 입력 | 사용자 입력 + FastAPI 서버 가공 결과 | 사용자 입력 + MCP 서버 검색 결과 |
| 흐름 | FastAPI → 모델 호출 | FastAPI → MCP 호출 → 결과 조립 → 모델 호출 |
> LLM에게 주는 프롬프트도, MCP를 통해 가져온 외부 툴 데이터가 포함된 형태로 변해야 합니다.
3.4 시스템 추가 구축 필요
| 항목 | 설명 |
|---|---|
| MCP 서버 구축 | 외부 도구 호출을 담당하는 별도의 MCP 서버 구축 필요 |
| 툴 목록 및 기능 등록 | Chroma 검색, Redis 조회 등을 MCP에 등록해야 함 |
| 인증 및 권한 관리 강화 | MCP 서버와 FastAPI 간 보안 고려 필요 (API Key, JWT 등) |
> FastAPI + LLM 모델 외에 별도의 MCP 서버/툴 레지스트리 구축이 필요합니다.
4. 현재 MCP 미도입이 적합한 이유
- 외부 시스템 통합 요구가 단순하며, FastAPI 내 통제로 충분히 대응 가능.
- 로컬 모델이 별도의 툴 호출 기능(tool calling)을 사용하지 않음.
- 현재 기능(모임 추천, 일정 추천 등)에 대해 복잡한 외부 상호작용 없이 안정적 운영 가능.
- 초기 단계에서는 개발 리소스를 최적화하고, 서비스 출시 속도를 우선시하는 전략이 중요.
- MCP 도입은 과설계(Overengineering)가 될 위험이 있으며, 현 서비스 수준에서는 실익이 적음.
5. 향후 MCP 도입 고려 조건
| 시나리오 | MCP 도입 필요성 |
|---|---|
| 다양한 외부 API 연동 요구 발생 | ✅ |
| LLM이 직접 툴 호출(tool calling) 기능 사용 시 | ✅ |
| 다중 모델, 다중 툴 환경으로 확장 시 | ✅ |
향후 복잡성 증가가 확인될 경우, MCP 기반 아키텍처 전환을 검토할 예정.
결론
현재 네모 서비스 구조에서는 MCP를 도입하지 않고도 안정적이고 효율적인 운영이 가능하다.
MCP 도입은 복잡성이 급격히 증가하거나, 다수 외부 시스템과의 통합이 요구될 때 공식적으로 검토할 계획이다.