🚀 [Project] AI 내 직원 만들기: MCP의 환상과 현실적인 우회로

🏠 로컬(Local) vs 원격(Remote): 기술보다 '비용과 보안'

MCP 서버를 어디에 둘 것인가? 이 질문에 대해 저는 '로컬 우선' 전략을 선택했습니다. 그 이유는 명확합니다.

• 비즈니스 모델(BM)의 부재: OpenAI나 구글 같은 거대 기업도 수익화에 사활을 거는 시기에, 개인 프로젝트에서 고정적인 호스팅 비용을 지출하는 것은 큰 부담입니다.

• 보안의 관점 전환: 원격 서버는 외부 침입(Hacking)에 취약한 반면, 로컬 서버는 물리적으로 단절되어 있습니다. 물론 로컬 파일 접근에 대한 리스크는 있지만, 이는 '최소 권한 원칙'과 '샌드박스 환경'을 통해 충분히 통제 가능합니다.

• 에이전트 런타임: 굳이 서버를 24시간 열어둘 필요 없이, 필요할 때만 로컬에서 프로세스를 실행하고 stdio 통신을 통해 LLM과 연결하는 방식이 훨씬 합리적입니다.

---

 

⚠️ 기술적 정정: MCP는 'Master Control Program'이 아닙니다

글을 정리하다 보니 한 가지 짚고 넘어갈 부분이 있습니다. 대화 중 언급된 MCP는 영화 <트론>의 인공지능이나 IBM의 옛 용어가 아닌, Anthropic이 발표한 Model Context Protocol(모델 컨텍스트 프로토콜)의 약자입니다.

단순히 '지휘하는 프로그램'이라는 의미를 넘어, AI가 데이터 소스 및 도구와 통신하기 위한 "표준 규약"으로 이해하는 것이 앞으로의 개발 방향을 잡는 데 더 정확합니다.

---

 

🚧 닥공(닥치고 공격)이 안 될 땐, 전략적 후퇴

FastAPI에 mcp.mount()를 시도하며 MCP 서버 구축에 박차를 가하려 했지만, 예상치 못한 장벽에 부딪혔습니다. 관리 페이지가 뜨지 않고, 참고할 자료도 부족했죠.

하지만 이 기술적 난관은 오히려 "과연 지금 나에게 MCP가 최선인가?"라는 본질적인 질문을 던지게 했습니다. 여기서 저는 중요한 결론에 도달했습니다.

"AI의 자유도보다는 공정의 표준화가 우선이다."

---

 

⚖️ MCP vs Function Calling: 품질과 표준화의 딜레마

우리가 AI 직원에게 기대하는 것은 '창의적인 일탈'이 아니라 '균일한 업무 품질'입니다.

1. 제조 공정의 표준화: ISO9001처럼, 훌륭한 시스템은 작업자의 기분에 따라 결과가 바뀌지 않도록 매뉴얼화되어 있습니다.

2. AI의 가변성: MCP는 AI가 도구를 '스스로 선택'하게 합니다. 이는 유연하지만, 반대로 말하면 똑같은 질문에도 매번 다른 경로로 업무를 처리할 수 있다는 뜻입니다.

3. 결론: 정형화된 업무 자동화에는 AI가 도구를 선택하게 두는 MCP보다, 개발자가 프로세스를 엄격히 제어하는 Function Calling이 '품질 관리' 측면에서 훨씬 유리할 수 있습니다.

결국 기술적 오류를 해결하려다, 제 서비스에 더 적합한 방식은 Function Calling을 통한 정교한 제어라는 확신을 얻게 되었습니다. 그래서 우선은 MCP 서버에 목매기보다, DRF(Django REST Framework)를 통한 CRUD 엔드포인트를 먼저 탄탄하게 구축하기로 전술을 변경했습니다.

---

 

⏭ 다음 단계: 기반 다지기

기술 구현은 결국 '돈'과 '품질'로 귀결됩니다. 다음 기록에서는 MCP 서버에 등록될 도구들의 기반이 될 DRF CRUD 엔드포인트 구축기를 들려드리겠습니다.

 

---

💡 안내: 이 포스팅은 기존 네이버 블로그의 7, 8회차 연재분을 통합했습니다. 로컬과 원격 서버 사이의 전략적 선택, 그리고 MCP 서버 구축 중 마주한 기술적 한계와 '품질 표준화'에 대한 깊은 고민을 기록했습니다.

---

---

---