MCP 서버 코드나 예제를 보다 보면 resources, tools, prompts, roots 같은 용어들이 계속 나옵니다. 그냥 구현 디테일처럼 보이지만, 사실 이건 MCP의 핵심 설계 철학을 담은 원시 타입(primitives)입니다.
이 5가지 원시 타입의 역할과 분리 원칙을 이해하면, MCP 서버를 더 잘 설계할 수 있고 AI 에이전트가 어떻게 동작할지 예측 가능해집니다. AI 개발 플랫폼 Portkey가 MCP 원시 타입의 개념적 구조를 정리한 글을 발표했습니다.
출처: MCP primitives: the mental model behind the protocol – Portkey
Resources와 Tools, 읽기와 실행의 명확한 분리
MCP에서 가장 중요한 설계 원칙은 데이터 접근과 실행을 철저히 분리한다는 겁니다.
Resources는 AI 에이전트가 읽거나 참조할 수 있는 데이터와 컨텍스트를 나타냅니다. 파일이든, 문서든, 데이터베이스 레코드든 관계없이 중요한 건 실행 불가능하다는 점이죠. Resources는 순수하게 맥락을 제공하는 역할만 합니다.
반면 Tools는 서버가 수행할 수 있는 실행 가능한 작업입니다. 각 Tool은 명확한 이름, 정의된 입력값, 그리고 명확한 출력을 가집니다. Tool이 호출되면 실제로 뭔가가 일어납니다. 데이터베이스 쿼리, 파일 쓰기, API 호출, 시스템 상태 변경 같은 부수 효과(side effects)를 일으킬 수 있죠.
왜 이렇게 나눴을까요? AI 에이전트가 추론할 때와 행동할 때를 명확히 구분하기 위해섭니다. Resources를 읽는 건 아무 일도 일어나지 않지만, Tools를 호출하면 시스템 상태가 바뀝니다. 이 구분이 명확하면 나중에 디버깅할 때도, 권한 제어를 할 때도 훨씬 수월합니다.
MCP는 Tool을 JSON Schema로 검증하고, 필요한 경우 사용자 동의를 요구할 수 있게 설계되어 있습니다.
Prompts와 Sampling, 무엇을 할지와 어떻게 할지
MCP는 AI 모델에게 주는 지시사항도 두 개로 분리합니다.
Prompts는 서버가 제공하는 재사용 가능한 지시사항입니다. 클라이언트나 에이전트마다 각자 지시사항을 정의하는 대신, MCP 서버가 Prompts를 한 번 정의해두면 여러 에이전트가 일관되게 사용할 수 있습니다. 중요한 건 Prompts 자체는 실행을 하지 않는다는 점입니다. 그저 모델이 특정 작업을 어떻게 수행해야 하는지 안내할 뿐이죠.
Sampling은 모델이 출력을 생성하는 방식을 제어합니다. 랜덤성, 출력 길이 같은 생성 파라미터가 여기 해당합니다. Prompt와 분리되어 있기 때문에, “무엇을 할지”는 Prompt가 결정하고, “어떻게 생성할지”는 Sampling이 제어합니다.
이 분리가 왜 중요할까요? 예를 들어 일관성이 중요한 시스템이라면 Sampling 파라미터만 조정해서 생성 동작을 바꿀 수 있습니다. Prompt 내용은 건드리지 않아도 되죠. 안전성 검증이나 평가를 할 때도 이 분리 덕분에 생성 동작을 따로 추적하고 조정할 수 있습니다.
Roots, 스코프를 명확히 정의하기
Roots는 MCP에서 범위(scope)를 정의합니다.
Root는 Resources, Tools, Prompts가 노출되는 경계를 나타냅니다. 그 경계 밖의 것들은 클라이언트가 볼 수 없습니다. 이게 중요한 이유는 AI 에이전트가 무엇에 접근할 수 있는지 추측하지 않고 명확히 알 수 있기 때문입니다.
예를 들어 프로젝트마다, 사용자마다, 환경마다 다른 Root를 설정해서 안전하게 기능을 노출할 수 있습니다. 프로토콜의 다른 부분을 바꾸지 않고도 격리(isolation)를 구현할 수 있는 거죠.
함께 작동하는 원시 타입들
MCP의 원시 타입들은 따로 쓰이는 게 아니라 함께 작동하도록 설계되었습니다. 전형적인 상호작용은 이런 식으로 흘러갑니다.
Root가 범위를 정의하면, Resources가 에이전트가 읽을 수 있는 맥락을 제공합니다. Prompts가 모델이 어떻게 추론해야 할지 형태를 잡아주고, Sampling이 생성 방식을 제어합니다. 그리고 실제 행동이 필요할 때만 Tools가 명시적으로 호출되죠.
각 단계가 명확합니다. 맥락, 지시사항, 동작, 실행이 서로 섞이지 않습니다. 이 분리 덕분에 시스템이 커져도 이해 가능한 상태로 유지됩니다. 문제가 생겼을 때도 맥락이 부족한 건지, 지시사항이 불명확한 건지, 생성 동작이 잘못된 건지, 의도치 않은 Tool 호출이 있었는지 더 쉽게 파악할 수 있습니다.
MCP는 워크플로우를 강제하지 않습니다. 대신 신뢰할 수 있는 워크플로우를 만들 수 있는 원시 타입을 제공합니다. 이 원시 타입들이 명확해지면 MCP는 추론하기도, 확장하기도, 실제 시스템에서 운영하기도 훨씬 쉬워집니다.
참고자료:
답글 남기기