저는 본업이 개발자는 아닙니다. Raven Tools, TapClicks에서 약 20년 동안 SEO 분야에서 활동해 왔으며, 현재는 저만의 seo agency shop과 podcast network를 운영하고 있습니다. 하지만 지난 1년 사이, 저는 Model Context Protocol (MCP) 서버에서 실행되고, 11개의 WordPress 설치 환경에 게시하며, 8개의 소셜 플랫폼에 걸쳐 일정을 예약하고, 샌드박스 컨테이너 내에서 ffmpeg로 비디오를 합성하는 프로덕션 콘텐츠 파이프라인을 유지 관리하게 되었습니다.

이 시스템은 작동합니다. 하지만 어떤 MCP 튜토리얼에서도 언급하지 않는 약 12가지 방식의 문제들이 발생했습니다. 왜냐하면 모든 MCP 튜토리얼은 "이제 모델이 당신의 파일을 읽을 수 있습니다!"라는 단계에서 멈추기 때문입니다.
그 이후의 단계가 바로 여기 있습니다.
MCP는 터무니없이 쉽습니다. 그것이 함정입니다.

MCP 서버는 HTTP 호출을 감싸는 얇은 래퍼 (wrapper)일 뿐입니다. 정말 그게 전부입니다. Express 라우트를 작성할 수 있다면, MCP 서버를 작성할 수 있습니다. 저는 Claude Code가 단 하루 만에 이를 스캐폴딩 (scaffold) 하는 것을 보았습니다.

이는 통합 계획을 세우는 순간, 프로토콜이 제약 사항이 아니라는 것을 의미합니다. 제약 사항은 항상 다음 중 하나입니다:

1. 플랫폼이 토큰 (token)을 발급해 줄 것인가?

2. 도구가 절반만 작동할 때 어떤 동작을 하는가?

3. 도구가 모델에게 거짓말을 할 때 모델은 어떻게 반응하는가?

4. Claude가 무언가 고장 났음에도 작동하는 척할 때 어떤 일이 벌어지는가?

1번은 비즈니스 문제입니다. 2번과 3번은 제가 실제로 몇 주를 허비하게 만든 지점입니다. 저는 데스크톱용 Claude가 제 Obsidian Vault에 접근하는 척하면서 실제로는 이전 채팅 내용에서 답변을 캐내고 있었던 상황 때문에 꼬박 2주를 보냈습니다. 이 거짓말은 제가 터미널 사용을 늘리고 데스크톱 자료를 더 이상 제공하지 않게 되면서 드러났습니다.