MCP 활용설계 - 100-hours-a-week/3-team-ssammu-wiki GitHub Wiki
1. 현재 아키텍처에서 외부 연계 요구를 처리하는 방식
| 기능 |
외부 연계 방식 |
처리 주체 |
방식 |
| 기업 정보 요약 |
기업 API (ex. 잡플래닛 등) 또는 크롤러 |
백엔드 또는 FastAPI 서버 |
REST API 직접 호출, BeautifulSoup 등 |
| 이력서 PDF 처리 |
AWS S3 |
FastAPI 서버 |
file_url 받아서 PyPDFLoader 등으로 파싱 |
| 사용자 응답 기반 피드백 |
LLM (vLLM + 오픈소스 모델) |
FastAPI 서버 |
프롬프트 구성 후 LLM 호출 |
| 초안 생성 |
자체 정보 기반 / 추출 정보 활용 |
FastAPI |
내부 구조화된 JSON 전달로 context 주입 |
2. MCP 없이도 충분한 이유
- 현재 서비스는 단일 LLM 흐름 기반의 요청-응답 구조임
- 리소스 간의 관계를 URI로 추적하거나 context로 연결해야 할 이유 없음
- 외부 도구 연계는 FastAPI 내부에서 모듈화된 방식으로 해결 가능
- 리소스 간 context 공유나 멀티 스텝 연결이 아닌, 단일 요청 단위의 처리로 구성됨
| 항목 |
분석 |
| 리소스 URI 기반 context 공유 필요 없음 |
LLM 호출마다 context 직접 구성 (PromptTemplate + JSON 데이터) |
| 외부 연계는 모두 기능 단위로 분리되어 있음 |
기업 정보 요약, 이력서 처리 등 각 기능별 endpoint/모듈로 설계되어 있음 |
| 서비스 흐름이 직선형(선형)임 |
LangGraph 등에서 필요한 복잡한 상태 분기/재활용 구조가 없음 |
| context 재사용, 저장, 흐름 추적 필요성 낮음 |
현재는 prompt → 응답 방식으로 충분하며, context를 따로 라우팅할 필요가 없음 |
| LLM 추론 흐름이 비교적 단순 |
정보 추출 → 요약 → 생성 흐름이 직렬 구성이라 그래프 구조나 context 라우팅이 과함 |
3. 결론
해당 서비스는 RESTful API 기반의 선형 구조와 모듈화된 기능 설계를 하고 있으며,
리소스 참조, 멀티 컨텍스트 공유, 상태 기반 워크플로우가 필요하지 않기 때문에
MCP 없이도 기능적으로 완전하고 효율적으로 동작함.