MCP가 없던 시절, 서비스를 연동하는 과정은 이렇듯 어려웠습니다:
① 각 서비스마다 별도의 도구 스키마와 함수를 작성해야 했습니다.
② 서비스가 업데이트되면, 여러분의 통합 코드를 함께 수정해야 했습니다.
③ 연결하는 서비스가 많아질수록 유지보수량이 기하급수적으로 늘어났습니다.
④ 겉으로는 도구가 있는 것처럼 보이지만, 실제로는 각기 다른 방식으로 만든 잡다한 조합에 불과했습니다. 2/7
오직 하나의 길만 선택해야 합니다: 도구 정의와 실행의 부담을 전용 MCP 서버로 이전하는 것입니다. 다른 길(직접 API 호출)을 택한다면—스키마와 함수를 모두 직접 작성하고, 테스트하고, 유지보수해야 하며, 서비스가 많아질수록 감당하기 어렵습니다. 모든 것을 혼자 처리하려는 서버는 결국 프리랜서처럼 지치게 됩니다.
다음 4단계를 따르세요:
① 여러분의 서버 자체가 MCP Client가 되어 MCP Server에 연결합니다.
② 이미 패키징된 해당 서비스를 제공하는 서버를 선택합니다—도구, 프롬프트, 리소스가 모두 그 안에 있습니다.
③ GitHub에서 처리되지 않은 병합 요청을 확인하고 싶다면, 그냥 물어보면 됩니다. Server 내부의 get_repos() 함수가 GitHub API에 직접 연결됩니다.
④ 서비스 제공자의 구현 세부 사항은 전적으로 해당 서버가 처리합니다. 4/7
연동 후 스스로 점검해 볼 질문 3가지:
① 도구 스키마를 여전히 직접 작성해야 하나요? 그렇지 않아야 합니다. 이미 다른 사람이 정의했을 것입니다.
② 서비스가 업데이트될 때, 여러분의 코드를 수정해야 하나요? 그렇지 않아야 합니다. 수정을 하는 것은 MCP Server입니다.
③ MCP와 도구 사용을 구분할 수 있나요? 구분이 안 된다면 아직 제대로 이해하지 못한 것입니다—하나는 누가 정의했는지를 관리하고, 다른 하나는 어떻게 호출하는지를 관리합니다. 5/7
한마디로 요약하자면: MCP는 도구가 누구에 의해 정의되고, 누구에 의해 실행되는지를 답변합니다. 반면, 도구 사용은 Claude가 어떻게 호출할지를 답변합니다. 이 두 가지를 혼합하면 결국 잡다한 조합이 될 수밖에 없습니다. 감당하기 힘들 때 부담을 이전하는 것은 게으름이 아니라 유일한 출구입니다. 6/7
원문: Anthropic Academy《Introduction to Model Context Protocol》
https://anthropic.skilljar.com/introduction-to-model-context-protocol/296689
...
오늘의 선물: MCP 세 가지 질문 자가 점검표—① 서버 작성자는 누구인가요? 누구나 만들 수 있지만, 서비스 제공자가 공식 버전을 내놓는 경우가 많습니다. ② API와 무엇이 다른가요? 스키마와 함수를 직접 작성할 필요가 없습니다. ③ 도구 사용과 무엇이 다른가요? 하나는 누가 정의했는지 관리하고, 다른 하나는 어떻게 호출하는지를 관리합니다.
현재 연동한 서비스의 통합 부담을 과연 스스로 얼마나 감당해야 할까요? 댓글로 가장 까다로웠던 연동 경험에 대해 이야기해 주세요.