MCP는 RPC보다 컨텍스트 배포(Context Distribution)로서 더 유용합니다.
대부분의 사람들은 도구 호출(tool calling)을 위해 Model Context Protocol (MCP)을 이야기합니다.
사람들은 이를 AI가 외부 도구를 호출하는 방법으로 봅니다. AI가 GitHub 이슈를 읽거나 파일을 가져오는 식이죠. 이로 인해 MCP는 에이전트를 위한 RPC 레이어처럼 보이게 됩니다.
이는 유용하지만, 가장 중요한 유스케이스는 아닙니다.
MCP의 진정한 힘은 컨텍스트 배포(context distribution)에 있습니다. MCP는 규칙, 기술(skills), 그리고 계약(contracts)을 AI 클라이언트에 배포할 수 있습니다.
RAG는 한 가지 질문에 답하는 데 도움을 줍니다: "어떤 정보가 관련이 있는가?" RAG는 문서를 찾아 모델에게 전달합니다.
하지만 팀에게는 단순한 정보 그 이상이 필요합니다. 팀에게는 규칙이 필요합니다.
팀은 다음을 알아야 합니다:
- 무엇이 권위 있는 소스인가?
- AI는 언제 멈춰야 하는가?
- 언제 사람의 확인이 필요한가?
- 이 작업에는 어떤 워크플로우가 적용되는가?
- 어떤 증거를 기록해야 하는가?
RAG는 이러한 규칙을 설명하는 문서를 검색하지만, 문서는 단지 컨텍스트일 뿐입니다. 많은 팀이 이를 프롬프트로 해결하려 합니다. "우리의 코딩 규칙을 따르세요"와 같은 지침을 작성하는 식이죠.
이는 확장성이 없습니다. 개발자마다 로컬 프롬프트가 제각각이기 때문입니다. 작업의 품질이 AI를 사용하는 사람에 따라 달라집니다. 이것은 팀 시스템이 아닙니다.
MCP는 이를 변화시킵니다. 작업 중에 단순히 도구를 호출하는 대신, AI는 작업을 시작하기 전에 작업 규칙을 전달받을 수 있습니다.
세션이 시작될 때, AI 클라이언트는 startup function을 호출합니다. 해당 함수는 다음을 반환합니다:
- 액세스 정책 (Access policies)
- 권위 있는 컨텍스트 소스 (Authoritative context sources)
- 사용 가능한 기술 (Available skills)
- 워크플로우 카탈로그 (Workflow catalogs)
- 미지의 상황을 처리하기 위한 규칙 (Rules for handling unknowns)
모델은 단순히 도구에 접근할 수 있는 것이 아닙니다. 업무의 규칙을 갖게 되는 것입니다.
이는 명확한 차이를 만듭니다:
- RPC 방식의 MCP: 모델이 작업 중에 도구를 호출합니다.
- 컨텍스트 배포 방식의 MCP: 모델이 작업을 시작하기 전에 규칙을 전달받습니다.
이 접근 방식은 도메인 지식을 휴대 가능하게(portable) 만듭니다. 모든 사용자가 긴 문서를 읽거나 로컬 프롬프트를 업데이트하는 대신, 시니어 엔지니어가 MCP 서버에 기술(skill)을 한 번만 정의하면 됩니다.
이제 기술을 정의하는 사람과 기술을 사용하는 사람이 분리됩니다.
이는 오래된 정보(stale information) 문제도 해결합니다. 사용자는 규칙 전체를 담은 레포지토리를 로컬에 가지고 있을 필요가 없습니다. MCP 연결만 있으면 됩니다. 권위 있는 정의는 서버에 유지됩니다.
RAG는 답합니다: "어떤 정보가 관련이 있을 수 있는가?" MCP 컨텍스트 배포는 답합니다: "이 작업을 규정해야 하는 규칙은 무엇인가?"
RAG는 지식을 검색하는 것에 관한 것이라면, MCP 컨텍스트 배포는 작업이 어떻게 이루어지는지 정의하는 것에 관한 것입니다.
AI가 어떤 도구를 호출할 수 있는지 묻는 것을 멈추십시오. 대신 AI가 시작하기 전에 어떤 컨텍스트를 로드해야 하는지 묻기 시작하십시오.
Source: https://dev.to/synthaicode_commander/mcp-is-more-useful-as-context-distribution-than-as-rpc-ai4
Optional learning community: https://t.me/GyaanSetuAi