MCP에 관한 대부분의 논의는 도구 호출 (tool calling)에 집중되어 있습니다.

그것은 자연스러운 현상입니다.

사람들이 MCP를 처음 접할 때, 명백한 유스케이스 (use case)는 간단합니다:

AI가 외부 도구를 호출하게 하라.

모델은 GitHub 이슈를 읽을 수 있습니다.
모델은 데이터베이스를 쿼리할 수 있습니다.
모델은 파일을 업데이트할 수 있습니다.
모델은 API를 호출할 수 있습니다.

그런 의미에서, MCP는 AI 에이전트 (AI agents)를 위한 RPC 계층처럼 보입니다.

그것은 유용합니다.
하지만 저는 이것이 MCP의 가장 중요한 용도는 아닐 수도 있다고 생각합니다.

더 흥미로운 용도는 이것입니다:

MCP는 AI 클라이언트 (AI clients)에게 컨텍스트 (context), 규칙 (rules), 기술 (skills), 그리고 운영 계약 (operating contracts)을 배포할 수 있다.

다시 말해, MCP는 AI가 작업 중에 도구를 호출하는 방법일 뿐만 아니라, 작업이 시작되기 전에 작업 환경을 정의하는 방법이 될 수도 있습니다.

RAG의 문제점

RAG는 보통 다음과 같은 질문에 답하기 위해 사용됩니다:

이 요청과 관련이 있을 법한 정보는 무엇인가?

시스템은 문서를 검색하고, 청크 (chunks)를 추출하여 모델에게 전달합니다.

이 방식은 많은 경우에 잘 작동합니다.
하지만 구조적인 한계가 있습니다.

RAG는 관련성이 높을 것으로 보이는 정보를 검색합니다.
그것이 반드시 작업이 어떻게 수행되어야 하는지를 정의하지는 않습니다.

팀 단위의 AI 작업에서 이것은 문제입니다.

팀은 정보만을 필요로 하지 않습니다.
팀은 공유된 규칙도 필요로 합니다.

예를 들어:

• 권위 있는 소스 (authoritative source)는 무엇인가?
• 무엇을 알 수 없는 상태로 취급해야 하는가?
• AI는 언제 멈춰야 하는가?
• 언제 인간의 확인이 필요한가?
• 종료 조건 (closure condition)은 무엇인가?
• 어떤 워크플로 (workflow)를 사용해야 하는가?
• 어떤 도메인 기술 (domain skill)이 적용되는가?
• 어떤 증거를 기록해야 하는가?

RAG는 이러한 규칙을 설명하는 문서를 검색할 수 있습니다.
하지만 검색 (retrieval)은 거버넌스 (governance)와 같지 않습니다.

검색된 청크는 단지 컨텍스트일 뿐입니다.
그것이 반드시 운영 계약인 것은 아닙니다.

로컬 프롬프트 (local prompts)의 문제점

많은 팀이 프롬프트 (prompts)를 통해 이 문제를 해결하려고 시도합니다.

그들은 다음과 같은 지침을 작성합니다:

우리의 코딩 규칙을 따르세요.
이 설계 문서를 사용하세요.
불분명할 때는 질문하세요.
위험한 변경을 하지 마세요.

이것이 도움이 되기는 하지만, 확장성 (scale)이 좋지 않습니다.

각 개발자는 서로 다른 로컬 프롬프트 (local prompt)를 가질 수 있습니다.
각 AI 클라이언트 (AI client)는 서로 다른 파일을 로드할 수 있습니다.
각 저장소 (repository)는 규칙의 약간씩 다른 버전을 포함할 수 있습니다.
어떤 사람들은 지침 (instructions)을 업데이트하는 것을 잊어버릴 수도 있습니다.
어떤 사람들은 올바른 컨텍스트 (context)를 아예 로드하지 않을 수도 있습니다.

그 결과, AI 출력의 품질이 개별 사용자에게 너무 많이 의존하게 됩니다.

한 개발자는 도메인 (domain)을 설명하는 방법을 알기 때문에 좋은 출력을 얻습니다.
다른 개발자는 어떤 컨텍스트가 중요한지 모르기 때문에 저조한 출력을 얻습니다.

이것은 팀 수준의 시스템이 아닙니다.
이것은 개인적인 프롬프트 제작 기술 (prompt craftsmanship)일 뿐입니다.

MCP를 사용하는 다른 방법

만약 MCP가 도구 호출 (tool calls)뿐만 아니라, 시작 컨텍스트 (startup context)를 위해서도 사용된다면 어떨까요?

세션 시작 시, AI 클라이언트는 시작 함수 (startup function)를 호출합니다.

해당 함수는 다음을 반환합니다:

• 액세스 정책 (access policy)
• 권위 있는 컨텍스트 소스 (authoritative context source)
• 사용 가능한 기술 (available skills)
• 워크플로 카탈로그 (workflow catalog)
• 미확인 항목 처리 규칙 (unknown handling rules)
• 클로저 규칙 (closure rules)
• 도구 계약 (tool contracts)
• 문서 리졸버 (document resolvers)

이제 모델은 단순히 도구에 접근할 수 있는 것에 그치지 않습니다.
모델은 통제된 컨텍스트 (governed context) 내부에서 시작합니다.

이것이 MCP의 역할을 변화시킵니다.

RPC 스타일의 MCP:

모델은 작업 중에 도구를 호출합니다.

컨텍스트 배포 (Context-distribution) 방식의 MCP:

모델은 작업이 시작되기 전에 작업 규칙을 전달받습니다.

그 차이는 매우 중요합니다.

시작 컨텍스트가 중요한 이유

MCP 서버가 존재한다고 해서 모델이 그것을 반드시 사용한다는 의미는 아닙니다.

모델은 MCP가 선택적인 백그라운드 인프라가 아니라는 점을 알아야 합니다.
모델은 MCP가 해당 세션의 권위 있는 소스 (authoritative source)라는 점을 알아야 합니다.

이를 위해서는 클라이언트 측의 부트스트래핑 규칙 (bootstrapping rule)이 필요합니다.

예를 들면 다음과 같습니다:

세션 시작 시, 프로젝트 MCP 서버가 구성되어 있다면, 먼저 get_startup_context를 호출하고 반환된 액세스 정책을 권위 있는 것으로 간주한다.

이것은 작은 규칙이지만, 시스템의 동작을 변화시킵니다.

이 규칙이 없다면, AI는 기억, 로컬 파일 또는 부분적인 컨텍스트를 바탕으로 답변하려고 시도할 수 있습니다.
이 규칙이 있다면, AI는 먼저 MCP 서버에 작업이 어떻게 통제되어야 하는지 질문합니다.

그것이 바로 “MCP를 사용할 수 있다”와 “MCP가 작업 컨텍스트 (working context)를 제어한다”의 차이입니다.

지식 검색에서 기술 배포로

이는 도메인 지식 (domain knowledge)이 배포되는 방식 또한 변화시킵니다.

많은 조직에서 도메인 지식은 숙련된 전문가들이 보유하고 있습니다.

그들은 다음을 알고 있습니다:

• 어떤 문서가 중요한지
• 어떤 규칙이 더 이상 유효하지 않은지
• 어떤 용어가 특별한 의미를 갖는지
• 어떤 변경 사항이 위험한지
• 어떤 가정이 금지되어 있는지
• 완료 전에 어떤 확인 절차가 필요한지

만약 이 지식이 단지 문서로만 작성되어 있다면, 모든 사용자가 이를 읽고 이해해야 합니다.

만약 이 지식이 프롬프트 (prompts)에 내장되어 있다면, 모든 사용자가 자신의 프롬프트를 최신 상태로 유지해야 합니다.

하지만 이 지식이 MCP로 접근 가능한 기술 (skills)로 패키징된다면, 배포 모델이 바뀝니다.

기술 작성자는 도메인 기술을 중앙에서 관리합니다.
사용자는 MCP를 통해 이를 소비합니다.
AI 클라이언트 (AI client)는 런타임 (runtime)에 동일한 기술 정의를 전달받습니다.

이는 두 가지 역할을 분리합니다:

• 기술을 정의하는 사람들
• 기술을 사용하는 사람들

이러한 분리는 매우 중요합니다.

이는 시니어 엔지니어가 도메인 특화 기술을 한 번만 정의하면, 여러 개발자가 자신의 AI 클라이언트를 통해 동일한 기술을 사용할 수 있음을 의미합니다.

목표는 단순히 더 나은 답변을 얻는 것만이 아닙니다.
목표는 팀 전체에서 더 일관된 결과물 (output)을 만들어내는 것입니다.

로컬 체크아웃이 필요하지 않아야 합니다

또 다른 장점은 이식성 (portability)입니다.

만약 모든 사용자가 거버넌스 저장소 (governance repository)를 로컬에 체크아웃 (local checkout)해야 한다면, 시스템은 취약해집니다.

로컬 복사본은 오래된 상태가 됩니다.
사용자마다 서로 다른 버전을 가질 수 있습니다.
설정 과정이 무거워집니다.
온보딩 (onboarding)이 느려집니다.
업데이트를 전파하기가 더 어려워집니다.

MCP 기반의 컨텍스트 배포 (context distribution)를 사용하면, 로컬 클라이언트는 거버넌스 저장소 전체를 가질 필요가 없습니다.

로컬 클라이언트에는 부트스트래핑 지침 (bootstrapping instruction)과 MCP 접근 권한만 있으면 됩니다.

권위 있는 정의 (authoritative definitions)는 MCP 서버에 머물러 있습니다.

AI는 이름이 지정된 MCP 도구 (MCP tools)를 통해 문서, 기술, 워크플로 (workflows), 그리고 계약 (contracts)을 해결합니다.

이것이 거버넌스 계층을 이식 가능하게 만듭니다.

사용자는 전체 컨텍스트 시스템을 로컬에 보유하지 않습니다.
사용자는 그것에 연결합니다.

RAG vs MCP 컨텍스트 배포 (Context Distribution)

그 차이점은 다음과 같이 요약할 수 있습니다.

RAG는 다음과 같이 답합니다:

어떤 정보가 관련이 있을 수 있는가?

MCP 컨텍스트 배포 (Context Distribution)는 다음과 같이 답합니다:

이 작업을 규정해야 하는 컨텍스트와 규칙은 무엇인가?

RAG는 지식 파편을 검색(retrieve)합니다.
MCP는 권위 있는 컨텍스트를 노출할 수 있습니다.

RAG는 질문에 답하는 데 유용합니다.
MCP는 작업을 제어하는 데 유용할 수 있습니다.

RAG는 종종 확률적 검색 (probabilistic retrieval)입니다.
MCP는 명명된 리졸버 (named resolvers), 카탈로그 (catalogs), 정책 (policies), 그리고 계약 (contracts)을 제공할 수 있습니다.

RAG는 모델에게 무언가를 알려줄 수 있습니다.
MCP는 모델에게 어떻게 진행하도록 허용되는지를 알려줄 수 있습니다.

이것이 제가 MCP를 RPC로서의 역할보다 컨텍스트 배포 (context distribution)로서의 역할이 더 중요할 수 있다고 생각하는 이유입니다.

미확인 사항 (Unknowns)은 런타임 (runtime)의 일부여야 합니다

한 가지 예는 미확인 사항 (unknown handling) 처리입니다.

일반적인 AI 사용 환경에서, 불확실성은 종종 유창한 텍스트 속으로 사라져 버립니다.

모델은 그럴듯한 말을 할 수도 있습니다.
사용자는 중요한 가정이 해결되지 않았다는 사실을 알아차리지 못할 수도 있습니다.

진지한 작업을 위해서는 미확인 사항 (unknowns)이 숨겨져서는 안 됩니다.

미확인 사항은 일급 런타임 신호 (first-class runtime signal)여야 합니다.

예를 들어:

• 모델이 필수적인 사실을 알지 못함
• 모델이 요구 사항을 이해하지 못함
• 모델에게 도메인 규칙 (domain rule)이 부족함
• 모델이 가정을 검증할 수 없음
• 모델이 진행하기 전에 인간의 확인이 필요함

만약 미확인 사항 처리가 단지 프롬프트 지시 사항 (prompt instruction)에 불과하다면, 그것은 취약합니다.

하지만 미확인 사항 처리가 MCP로 배포된 운영 계약 (operating contract)의 일부라면, 모든 기술과 워크플로 (workflows)가 동일한 규칙을 공유할 수 있습니다.

모델은 미확인 사항을 기록하도록 요구될 수 있습니다.
해결되지 않은 미확인 사항이 남아 있으면 종료 (closure)가 차단될 수 있습니다.
위험한 변경 사항은 에스컬레이션 (escalation)을 요구할 수 있습니다.

이것은 일반적인 검색이 아닙니다.
이것은 거버넌스 (governance)입니다.

AI 작업을 위한 운영 계층으로서의 MCP

이제 저는 MCP를 단순한 도구 호출 (tool-calling) 프로토콜보다 더 넓은 개념으로 보고 있습니다.

MCP는 AI 지원 작업 (AI-assisted work)을 위한 운영 계층 (operating layer)이 될 수 있습니다.

전통적인 의미의 운영 체제 (operating system)는 아니지만, 다음과 같은 것들을 정의하는 계층입니다:

• 어떤 컨텍스트가 권위(authoritative)를 갖는지
• 어떤 기술(skills)을 사용할 수 있는지
• 어떤 워크플로우(workflows)가 적용되는지
• 불확실성(uncertainty)을 어떻게 처리하는지
• 언제 작업을 중단해야 하는지
• 종료(closure)를 어떻게 판단하는지
• 어떤 증거를 기록해야 하는지

이는 RPC보다 훨씬 더 많은 것을 의미합니다.

RPC는 모델이 무언가를 할 수 있게 해줍니다.
컨텍스트 배포(Context distribution)는 모델에게 어떻게 일해야 하는지를 알려줍니다.

개별적인 실험 단계에서는 이것이 그리 중요하지 않을 수 있습니다.

하지만 팀 단위에서는 매우 중요합니다.

팀은 강력한 AI만을 필요로 하는 것이 아니라,
반복 가능한 AI 보조 작업(AI-assisted work)을 필요로 하기 때문입니다.

핵심 아이디어

핵심 아이디어는 간단합니다:

AI에게 도구만 제공하지 마세요.
AI에게 관리되는 작업 컨텍스트(governed working context)를 제공하세요.

MCP는 행동(actions)뿐만 아니라 리소스(resources), 프롬프트(prompts), 카탈로그(catalogs), 리졸버(resolvers), 그리고 계약(contracts)까지 노출할 수 있기 때문에 이를 가능하게 합니다.

이는 MCP 기반 시스템이 나아가야 할 다른 방향을 제시합니다.

다음과 같이 묻는 대신:

AI가 호출할 수 있는 도구는 무엇인가?

우리는 다음과 같이 물어야 합니다:

AI가 시작하기 전에 어떤 컨텍스트를 로드해야 하는가?
어떤 규칙이 작업을 관리해야 하는가?
모든 사용자에게 어떤 기술을 배포해야 하는가?
안전하지 않거나 불완전한 종료(closure)를 방지하기 위해 무엇이 필요한가?

이 지점이 바로 MCP가 가장 가치 있어지는 지점일 수 있습니다.

에이전트를 위한 RPC 계층으로서가 아니라,
팀 단위의 AI 작업을 위한 휴대 가능한 컨텍스트 배포 계층(portable context distribution layer)으로서 말입니다.