제3장 — 서버 프리미티브: 컨텍스트와 능력의 노출

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 세 번째 글입니다. MCP 서버가 실제로 무엇을 말할 수 있는지를 배웁니다 — 세 개의 명사, 세 개의 라이프사이클, 세 개의 오류 모델 — 그리고 알맞은 것을 고르는 규율이 서버가 확장되느냐 누적되느냐를 가르는 이유.

이 장이 존재하는 이유

프로토콜은 그것이 여러분이 말하게 해 주는 것만큼만 쓸모가 있습니다. 제2장은 host, client, server의 멘탈 모델을 세웠고, 능력 협상을 통해 세션이 살아 오는 모습을 보았습니다. 악수가 끝나고 양측이 상대가 무엇을 할 수 있는지 알게 되면, 구체적으로 무엇이 탁자 위에 있을까요? MCP는 세 개의 명사로 답합니다. Resources, Prompts, Tools. 표면적으로는 비슷해 보입니다 — 각각이 서버가 만들거나 돌릴 수 있는, 이름 붙은 스키마 기술된 무언가입니다 — 하지만 그것들은 세 개의 별개 의도에 대응합니다. Resources는 읽기 상태입니다. Prompts는 재사용 가능한 스캐폴드입니다. Tools는 쓰기 행동입니다. 이 장은 각각을 차례로 걸어 갑니다. 스키마, 라이프사이클, 오류 모델, 그리고 엔지니어가 잘못 짚는 곳들.

3.1 Resources: 읽기 전용 컨텍스트 데이터

리소스는 서버가 컨텍스트로 모델에 건넬 수 있는 데이터입니다. 정의어는 읽기 전용입니다. 리소스는 세상을 변이시키지 않습니다. 세상을 기술합니다. 한 번의 페치가 다른 곳에 상태 변화를 일으킨다면 — 감사 로그 행, 증가된 카운터, 발사된 웹훅 — 그것은 리소스가 아니라 의상을 입은 도구입니다. 이 선을 날카롭게 긋는 것이 MCP 서버 설계의 첫 규율입니다.

각 리소스는 서버가 고른 스킴(file://, postgres://, linear://issue/ENG-1234) 안의 안정된 URI와 메타데이터 — 이름, 선택적 기술, MIME 타입, 선택적 크기 — 를 가집니다. 이 필드들 중 어느 것도 장식이 아닙니다. 기술 없는 리소스는 모델이 평가할 수 없는 리소스입니다. 라이프사이클은 직설적입니다. resources/list로 열거하고, resources/read로 페치합니다. resources/write는 없습니다 — 서버가 쓰기를 원한다면 도구를 노출해야 합니다. 그 비대칭이 신뢰 경계를 가시화합니다.

스케일에서 리소스를 실용적으로 만드는 두 패턴. URI 템플릿은 서버가 수백만 행을 열거하는 대신 파라미터화된 읽기 엔드포인트(db://orders/{order_id})를 노출하게 합니다. 구독은 호스트가 URI에 관심을 등록하고 기저 데이터가 바뀔 때 notifications/resources/updated를 받게 합니다 — 대안은 LLM 속도로 폴링하는 것이며, 양쪽에 낭비입니다. 피해야 할 함정은 세션 시작에 모든 내부 객체를 리소스 목록에 쏟아 붓는 것입니다. 삼천 개의 리소스 목록은 사용자가 타이핑하기 전에 수만 토큰을 먹습니다. 잘 큐레이션된 최상위와 템플릿을 노출하고, 모델이 긴 꼬리를 검색하게 두십시오.

3.2 Prompts: 재사용 가능한 템플릿과 워크플로

MCP의 프롬프트는 LLM의 시스템 프롬프트와는 아무 관계가 없습니다. 그것들은 사용자가 — 또는 사용자를 대신하는 호스트가 — 특정 상호작용을 시작하기 위해 호출할 수 있는, 재사용 가능한 서버 정의 템플릿입니다. 프롬프트는 인격보다는 슬래시 명령에 더 가깝습니다. 요점은 서버가 자신이 노출하는 도구와 리소스 옆에 알려진 좋은 상호작용 패턴을 함께 출하해, 키보드 앞 사람이 요청을 어떻게 표현할지 외울 필요가 없게 하는 것입니다.

프롬프트는 이름, 선택적 기술, 그리고 인자 목록을 가집니다. 호스트는 발견하려고 prompts/list를, 다음에 프롬프트를 호스트가 자기 모델 루프에 먹일 수 있는 메시지 시퀀스로 펼치려고 prompts/get을 호출합니다. 프롬프트는 URI로 리소스를 참조할 수 있으며, 그 경우 호스트는 보내기 전에 인라인합니다. 서버는 여는 턴을 스크립트하고, 모델이 거기서 이어 받습니다.

프롬프트와 시스템 메시지의 구별은 중요합니다. /review_pr을 호출한 사용자는 자신의 대화 로그에서 어시스턴트가 리뷰 작업을 시작하는 모습을 봅니다 — 무엇이 시작되었는지 이해하고, 끼어들 수 있고, 감사할 수 있습니다. 서버가 대신 조용히 호스트의 시스템 프롬프트에 지시를 덧붙였다면, 사용자는 어시스턴트가 갑자기 다르게 행동하는 이유를 알 길이 없을 것입니다. 프롬프트는 사용자에게 보이는 스캐폴드이고, 시스템 프롬프트는 호스트의 프레이밍입니다. 둘은 혼동되어서는 안 됩니다. 규율은, 명시적으로 보였을 때 사용자가 승인하지 않을 만한 프롬프트 내용은 결함이라는 것입니다.

3.3 Tools: 행동, 구조화된 출력, 멱등성

도구는 MCP가 똑같이 흥미롭고 위험해지는 자리입니다. 리소스는 읽기, 프롬프트는 스캐폴드, 도구는 쓰기입니다 — 행을 만들고, 메시지를 보내고, 서비스를 배포하고, 카드를 청구합니다. 모든 도구는 이름, 기술, JSON Schema 형식의 입력 스키마를 가집니다. 기술은 전체 MCP 표면에서 가장 중요한 필드입니다. 그것이 모델이 도구를 호출할지, 언제 호출할지, 어떤 인자로 호출할지 결정하는 데 쓰는 텍스트이기 때문입니다. 「이메일을 보냅니다」라고 적힌 기술은 이메일 모양 의도가 나타날 때마다 모델이 손을 뻗을 도구입니다. 「마케팅 플랫폼을 통해 트랜잭션 이메일을 보냅니다. 검증된 고객 주소에만, 개인 서신용이 아닙니다」라고 적힌 기술은 모델이 더 분별 있게 쓰는 도구입니다.

오류 모델은 두 개의 채널을 가집니다. 프로토콜 오류(잘못된 형식의 인자, 알 수 없는 도구)는 JSON-RPC 오류를 반환하며 프레이밍 실패입니다. 도구 오류(수신자 반송, 디스크 가득)는 성공적 응답을 isError: true와 무엇이 일어났는지 설명하는 콘텐츠 블록과 함께 반환합니다. 구별이 중요합니다. 모델은 도구 오류를 보고 적응해야 합니다. 호스트는 프로토콜 오류를 보고 전송을 회복해야 합니다. 둘을 합치면 모델이 필요로 하는 정보를 빼앗는 셈입니다.

현대 MCP는 선언된 outputSchema를 따르는 산문 콘텐츠 배열 옆의 structuredContent를 지원합니다. 긴 추적에서 누적 효과는 실제적입니다. 짧고 구조화된 도구 출력은 모델에게 실제 추론을 위한 여유를 남깁니다. 길고 산문적인 출력은 컨텍스트 예산을 먹어 치웁니다. 이름 붙일 만한 추가 규율 두 가지. 최소성: 잘 기술된 도구 열두 개는 거의 모든 벤치마크에서 예순 개를 이깁니다. list_users, get_user, search_users, count_users보다는 구조화된 필터를 가진 find_users를 노출하십시오. 멱등성: 재시도 폭풍은 불가피합니다. 멱등성 키를 받거나 결정적 식별자 스킴을 쓰는 도구는 네트워크 깜빡임을 데이터 무결성 사고가 아니라 무동작으로 바꿉니다.

3.4 조합: 세 프리미티브가 함께 일하는 법

프리미티브는 함께 일할 때 가장 쓸모 있습니다. 잘 설계된 서버는 보통 각각의 일부를 노출합니다. 흔한 상호작용의 씨앗이 될 프롬프트 몇 개, 중요한 행동을 위한 작은 도구 집합, 그리고 컨텍스트를 공급하는 — 어쩌면 큰 — 리소스 집합. 고객 지원 서버는 고객 프로필과 티켓 이력을 리소스로, reply_to_ticket과 escalate_ticket을 도구로, /triage_ticket을 알맞은 리소스를 적재하고 모델에게 분류를 요청하는 프롬프트로 노출할 수 있습니다. 프롬프트는 씨앗을 뿌리고, 리소스는 상황을 채우며, 도구는 세상을 바꿉니다.

프리미티브가 얼마나 유연한지 보고 나면 유혹은 모든 것을 하나로 미는 것입니다. 읽기 전용 도구로 리소스를 흉내 낼 수 있고, 모델을 명령 출력으로 살짝 미는 프롬프트로 도구를 흉내 낼 수 있고, 지시가 든 리소스로 프롬프트를 흉내 낼 수 있습니다. 각각은 설계 공간을 압축하고 무언가를 잃습니다. 도구로 흉내 낸 리소스는 캐시되거나, 구독되거나, 프롬프트 펼침에 인라인될 수 없습니다. 프롬프트로 흉내 낸 도구는 호출 지점에서 권한 부여될 수 없고 구조화된 출력 채널이 없습니다. 프리미티브는 임의적이지 않습니다. 호스트가 각각을 어떻게 안전히 다루어야 할지 알도록 인수분해된 것입니다. 그 인수분해를 존중하는 것이 프로토콜 계약의 일부입니다.

제3장이 준비하는 것

여러분은 거래의 서버 측을 걸었습니다. 서버는 Resources, Prompts, Tools를 각자의 스키마, 라이프사이클, 오류 모델과 함께 노출합니다. 규율은 서버가 할 수 있는 각 일에 알맞은 프리미티브를 고르고, 신중히 이름 붙이고 기술하며, 과부하를 거부하는 것입니다. 그러나 MCP는 일방통행이 아닙니다. 호스트도 능력을 서버로 되돌려 노출할 수 있습니다 — 그리고 그것이 프로토콜의 가장 흥미롭고 가장 보안 민감한 설계 선택이 사는 곳입니다.

다음 → 제4장: 클라이언트 프리미티브 — 샘플링, 루트, 일리시테이션. 역방향 표면 — 호스트가 서버에 되돌려주는 것 — 과 신뢰 경계를 넘어 건네지는 모든 능력에 따라오는 보안적 함의.