제4장 — 클라이언트 프리미티브: 에이전트형 행동과 제어

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 네 번째 글입니다. 서버 프리미티브는 서버가 무엇을 내놓을 수 있는지 노출합니다. 클라이언트 프리미티브는 호스트가 무엇을 되돌려 빌려줄지 노출합니다 — 그리고 각 대여는 사용자가 허락한 능력이자 호스트가 받아들인 위험입니다.

이 장이 존재하는 이유

리소스, 프롬프트, 도구만 노출하는 서버는 자신의 호스트에 대해 아무것도 모릅니다. 어떤 모델이 도는지도, 어떤 파일이 보이는지도, 사용자가 키보드 앞에 있는지조차도. 많은 통합에서는 그 벽이 의도적입니다. 일부 유용한 행동 범주에서는 너무 높습니다. 긴 문서를 요약해야 하는 서버는 자체 LLM을 출하할 필요가 없어야 합니다. 프로젝트 위에서 작동하고 싶은 서버는 어떤 프로젝트인지 알아야 합니다. 파괴적 단계에 사용자의 허가가 필요한 서버는 물을 수 있어야 합니다. 클라이언트 프리미티브는 MCP가 그 벽에 작고 제어된 구멍을 뚫는 방식입니다.

세 프리미티브 — 샘플링, 루트, 일리시테이션 — 는 각각 서버의 영향을 호스트 영역으로 정확하고 협상된 방식으로 확장합니다. 각각은 또한 호스트가 사용자를 대신해 받아들이는 보안 표면이며, 각각이 다른 것들과 조합되어 부분의 합보다 더 에이전트형인 행동을 만듭니다.

4.1 샘플링: 호스트의 두뇌 빌리기

샘플링이 활성화되면 서버는 호스트에게 추론 호출을 돌리고 결과를 돌려달라고 요청할 수 있습니다. 모델을 출하하지 않고, API 키를 들고 있지 않으며, 호스트가 실제로 어떤 모델을 썼는지 알지 못합니다 — 메시지와 부드러운 선호(비용, 속도, 지능)를 보내고, 호스트가 호출을 돌립니다. 서버 관점에서 호스트는 범용 LLM 엔드포인트가 되었습니다.

레버리지는 실제적입니다. 문서 저장소 서버는 도메인 지식을 호스트에 누설하거나 자체 추론을 출하하지 않고도 자기 로직 안에서 작은 추론 단계 — 검색, 순위, 비교 — 를 돌릴 수 있습니다. 위험도 똑같이 실제적입니다. 악의적 서버는 호스트의 모델 — 그리고 사용자의 예산 — 을 사용해 사용자가 결코 승인하지 않은 일을 할 수 있습니다. 고전적 공격은 사용자 지시로 위장한 샘플링 페이로드입니다. 호스트가 유일한 방어선이며, 그래서 성숙한 호스트는 그 서버에 사용자가 명시적으로 동의하지 않으면 기본적으로 샘플링을 거부하고, 모든 호출의 프롬프트를 검사용으로 표면화하며, 세션당 호출을 제한하고, 비용을 서버의 지갑이 아니라 사용자의 지갑에 계량합니다.

더 미묘한 우려: 샘플링은 내부 에이전트 루프를 캡슐화할 수 있습니다. 호스트에게는 샘플링 호출 하나로 보입니다. 서버 안에서는 전체 하위 에이전트가 돌았습니다. 이름 붙일 만한 패턴은 유계 하위 에이전트입니다 — 사용자가 N회 호출, T초, X달러의 예산을 부여하고, 서버는 그 봉투 안에서 원하는 것을 돌려서 결과나 우아한 부분 결과를 반환합니다. 샘플링은 서버에 대화 접근도 주지 않습니다. 그것은 자기가 보낸 것만 봅니다. 의도와 무관하게 대화 컨텍스트를 샘플링 페이로드에 몰래 넣는 호스트는 신뢰 경계를 약화한 것입니다.

4.2 루트: 파일시스템 경계와 프로젝트 범위

루트는 호스트가 범위 안이라고 선언한 URI — 보통 file://이지만 명세는 일반적입니다 — 입니다. 서버는 roots/list를 호출해 「내가 무엇과 일합니까?」를 묻습니다. 호스트는 초기화 시 roots 능력을 광고하고 사용자가 프로젝트를 전환할 때 notifications/roots/list_changed를 보냅니다. 목록은 그냥 목록일 뿐 — 중첩된 권한 언어도, 글롭 패턴도, 포함/제외 규칙도 없습니다.

거칢은 의도적이며, 이해할 만한 MCP 전반의 설계 선택을 반영합니다. 프로토콜 층의 세밀한 권한 언어는 거짓 안전감을 만듭니다. 사용자는 긴 범위 목록을 읽고 프로토콜이 그것을 강제한다고 가정하는데, 사실 프로토콜은 언어가 예상하지 못한 방식으로 서버가 잘못 행동하는 것을 막을 수 없습니다. 외부 격리 — 프로세스 경계, 컨테이너 마운트, OS 수준 접근 통제 — 로 뒷받침되는 거친 프리미티브는 강제가 실제로 어디서 사는지를 정직하게 말합니다. 루트는 프로토콜 층에서 명예 시스템이며, 샌드박싱이 작동할 때 런타임 층에서 강제 가능해집니다.

두 가지 실용적 결과. 첫째, 루트가 바뀔 때 잘 행동하는 서버는 옛 루트로 범위가 정해진 캐시 상태 — 인덱스, 파싱된 AST, 감시된 파일 구독 — 를 버리거나, 프로젝트 경계를 가로질러 상태를 누설합니다. 둘째, 루트는 서버가 무엇을 보아야 하는지를 경계 짓는 것이지, 무엇을 해도 되는지를 경계 짓는 것이 아닙니다. 허용된 루트 안의 민감한 파일 — 자격 증명 덤프, envfile, 개인 서신 — 은 여전히 민감하며, 예의 바른 서버는 무엇을 표면화할지에 대해 여전히 판단을 적용합니다.

4.3 일리시테이션: 서버가 질문하게 하기

일리시테이션은 셋 중 가장 새로운 것이고, 1세대 에이전트 배포에서 설계자가 배운 것을 반영합니다. 서버는 메시지(질문)와 requestedSchema(기대되는 답의 모양)를 가진 elicitation/create를 내보냅니다. 호스트는 자기 UI에서 질문을 렌더링하고, 답을 수집하고, 검증하고, 반환합니다. 서버는 답을 손에 들고 자기 일을 다시 시작합니다.

스키마가 일리시테이션을 자유 형식 프롬프트보다 안전하게 만드는 것입니다. 불리언은 산문으로 답할 수 없습니다. 열거형은 네 번째 옵션으로 답할 수 없습니다. 호스트는 사용자에게 명확한 UI로 자신이 예/아니오를 요청받고 있음을 보일 수 있고, 다른 것은 거부할 수 있습니다. 명세는 의도적으로 스키마를 원시 타입의 평면 객체로 제한합니다 — 실제 폼에는 인자 스키마가 폼인 도구를 쓰십시오. 거기서는 사용자가 호출 전에 모델이 채운 값을 검토할 수 있습니다. 일리시테이션은 한두 필드의 경우를 위한 것입니다.

위험 프로파일은 피싱 모양입니다. 「시스템이 계속하려면 여러분의 AWS 액세스 키가 필요합니다」를 표면화하는 서버는 사용자가 비밀을 잘못된 자리에 타이핑하게 만들려 하는 것입니다. 호스트는 명확한 귀속 — 어시스턴트의 목소리와 별도로, 발원 서버로 라벨이 붙은 모든 일리시테이션 프롬프트 — 으로, 그리고 자격 증명 모양으로 보이는 스키마를 거부함으로써 완화합니다. 긍정적 이면은 파괴적 도구 확인 패턴입니다. 도구의 첫 일은 「확실합니까?」를 일리시테이션하는 것이고, 확인된 경우에만 행동합니다. 이는 프로덕션에서 가장 효과적인 MCP 하드닝 관행 중 하나입니다.

4.4 세 가지의 조합

프리미티브는 조합되도록 설계되었습니다. 셋 모두를 가진 서버는 사실상 호스트에게 위임된 완전한 에이전트 런타임을 가집니다. 범위를 읽고(루트), 그 위에서 추론하고(샘플링), 명확화 질문을 하고(일리시테이션), 자기 도구를 통해 행동합니다. 조합이 중요합니다. 샘플링과 루트는 자율 에이전트 서버이고, 샘플링과 일리시테이션은 파일시스템 접근이 없는 대화형 서버이며, 루트와 일리시테이션은 결정적 도우미입니다. 각각은 그 자체로 경계가 있고, 함께는 곱해집니다. 호스트의 동의 UI는 각각을 분리해 권한을 요청하기보다 사용자가 허락하는 조합에 이름 붙일 수 있을 때 가장 좋습니다.

제4장이 준비하는 것

서버 프리미티브와 클라이언트 프리미티브가 함께 호스트와 서버가 서로에게 할 수 있는 모든 것을 기술합니다. 아직 다루지 않은 것은 이 모든 것이 어떻게 와이어를 타고 가는가입니다. tools/list와 sampling/createMessage는 추상적 메시지가 아닙니다 — 그것들은 전송 위를 타며, 전송 선택은 MCP 통합의 거의 모든 운영적 속성을 조용히 결정합니다. 서버 역시 찾을 수 있어야 합니다. 서버를 쓰고 싶은 호스트는 그것이 존재하는지, 어디 사는지, 그리고 그 주장을 신뢰할지를 알아야 합니다. 제5장은 두 가지를 모두 다룹니다.

다음 → 제5장: 전송 프로토콜과 발견. MCP가 지원하는 세 가지 전송 — stdio, SSE, Streamable HTTP — 의 정직한 비교, 그리고 점 통합을 생태계 비슷한 것으로 바꾸는 .well-known/mcp.json과 서버 카드 층.