MCP는 에이전트 구조에서 어디에 둘까라는 질문은 단순히 “도구 연결 표준을 쓸까 말까”의 문제가 아닙니다. 에이전트가 외부 시스템과 만나는 지점을 행동, 맥락, 작업 템플릿으로 나누는 문제에 가깝습니다.
2편에서 tool calling의 안전 경계를 봤다면, 3편에서는 그 도구와 맥락을 어떤 구조로 연결할지 봐야 합니다. MCP는 모델을 똑똑하게 만드는 마법이 아니라, 모델이 쓸 수 있는 외부 기능을 정리하는 연결 경계입니다.
MCP 공식 명세는 tools, resources, prompts를 서로 다른 user interaction model로 설명합니다. 이 차이를 에이전트 설계 관점으로 풀어보겠습니다.
MCP는 에이전트와 외부 시스템 사이의 경계다
MCP 아키텍처 문서는 host가 여러 client를 만들고, 각 client가 특정 server와 1:1 세션을 유지하는 구조를 설명합니다. 이 구조에서 host는 권한, 승인, 보안 경계를 관리하고 server는 특정 기능과 맥락을 제공합니다.
중요한 점은 MCP server가 전체 대화를 다 들여다보는 구조가 아니라는 것입니다. 공식 아키텍처 문서는 server가 필요한 맥락만 받고, 전체 대화 기록과 cross-server 제어는 host 쪽 경계에 남는다는 원칙을 강조합니다.
MCP 구성요소를 먼저 한 장으로 보기
에이전트 설계에서 MCP를 이해하려면 세 가지를 섞지 않는 것이 먼저입니다. tools는 행동입니다. resources는 맥락입니다. prompts는 사용자가 고르는 작업 템플릿입니다.
tools는 모델이 호출하는 행동 계층이다
MCP tools 문서는 tools를 language model이 호출할 수 있는 기능으로 설명합니다. 데이터베이스 조회, API 호출, 계산 실행처럼 외부 시스템에 실제 행동을 일으키는 지점입니다.
그래서 tools는 위험도 기준을 반드시 가져야 합니다. 날씨 조회처럼 읽기만 하는 도구와 결제 취소, 파일 삭제, 배포 실행처럼 상태를 바꾸는 도구는 같은 방식으로 다루면 안 됩니다.
{
"name": "deploy_service",
"description": "Deploy a service to production",
"inputSchema": {
"type": "object",
"properties": {
"service": {"type": "string"},
"version": {"type": "string"}
},
"required": ["service", "version"]
}
}이런 도구는 모델이 호출할 수 있다고 해서 바로 실행하면 위험합니다. 2편에서 본 것처럼 human approval, 권한 범위, 로그 기록, 실패 비용을 함께 설계해야 합니다.
resources는 앱이 넣어주는 맥락 계층이다
MCP resources 문서는 resources를 파일, 데이터베이스 스키마, 애플리케이션 정보처럼 모델에게 맥락을 제공하는 데이터로 설명합니다. interaction model도 tools와 다릅니다. resources는 model-controlled가 아니라 application-driven입니다.
이 차이가 중요합니다. 모델이 마음대로 모든 파일을 뒤지는 구조가 아니라, host 애플리케이션이 어떤 resource를 어떤 상황에 넣을지 결정합니다. 사용자가 선택할 수도 있고, 앱이 검색과 필터링을 제공할 수도 있습니다.
- 프로젝트 README: 사용자가 선택해서 현재 작업 맥락에 넣는다
- DB schema: SQL 생성 작업에서만 제한적으로 넣는다
- 최근 장애 로그: 운영 분석 작업에서 필요한 범위만 넣는다
- 고객 데이터: 권한과 마스킹 없이는 resource로 노출하지 않는다
resources를 잘못 설계하면 RAG와 비슷한 문제가 생깁니다. 너무 많은 맥락을 넣으면 비용이 늘고 답변이 흐려집니다. 너무 적게 넣으면 모델이 근거 없이 추측합니다.
prompts는 사용자가 고르는 작업 템플릿이다
MCP prompts 문서는 prompts를 server가 제공하는 구조화된 메시지와 instruction template으로 설명합니다. tools와 resources와 달리 prompts는 user-controlled입니다. 사용자가 명시적으로 고르는 slash command나 작업 템플릿에 가깝습니다.
예를 들어 코드 리뷰, 릴리스 노트 작성, 장애 원인 분석 같은 반복 작업은 prompt template로 둘 수 있습니다. 이때 prompt는 행동을 실행하는 도구가 아니라 작업을 시작하는 형태입니다.
{
"name": "incident_review",
"description": "장애 로그와 변경 이력을 바탕으로 원인 후보를 정리한다",
"arguments": [
{"name": "service", "required": true},
{"name": "time_range", "required": true}
]
}prompt에 필요한 로그나 변경 이력은 resource로 들어올 수 있고, 추가 조회가 필요하면 tool을 호출할 수 있습니다. 이렇게 보면 prompts, resources, tools가 서로 연결되지만 역할은 다릅니다.
작은 업무 자동화 예시로 보면 더 쉽다
예를 들어 “배포 전 점검 에이전트”를 만든다고 해보겠습니다. 이 에이전트는 배포 노트를 읽고, 최근 오류 로그를 보고, 위험하면 사람에게 승인을 요청해야 합니다.
- prompt: 배포 전 점검이라는 작업 템플릿을 시작한다
- resource: 배포 노트, 변경 파일 목록, 최근 오류 로그를 맥락으로 제공한다
- tool: 테스트 실행, 상태 조회, 배포 요청 같은 실제 행동을 담당한다
- host: 어떤 도구를 노출할지, 어떤 단계에서 승인을 받을지 결정한다
이 구조에서 MCP는 에이전트 전체를 대신하지 않습니다. 대신 에이전트가 외부 세계를 만나는 접점을 정리합니다. workflow, memory, eval, tracing은 여전히 별도 설계가 필요합니다.
MCP를 잘못 놓으면 생기는 문제
MCP를 단순히 “도구 연결”로만 보면 모든 것을 tool로 만들고 싶어집니다. 하지만 README 읽기, DB schema 제공, 코드 리뷰 템플릿까지 모두 tool로 만들면 모델이 해야 할 행동과 앱이 제공해야 할 맥락이 섞입니다.
- context로 제공할 문서를 tool 호출로만 만들면 모델이 필요한 맥락을 놓칠 수 있다
- 위험한 쓰기 작업을 일반 tool처럼 노출하면 승인 경계가 약해진다
- 반복 작업 템플릿을 prompt가 아니라 긴 시스템 프롬프트로만 관리하면 재사용성이 떨어진다
- server가 너무 많은 책임을 가지면 host가 보안 경계를 관리하기 어려워진다
반대로 모든 것을 resource로만 두면 실제 행동을 실행할 수 없습니다. 모든 것을 prompt로만 두면 매번 같은 작업을 말로만 시작해야 합니다. 설계의 핵심은 무엇을 어디에 둘지 나누는 것입니다.
MCP 서버 설계 체크리스트
- 이 기능은 실제 행동인가, 맥락인가, 작업 템플릿인가?
- 모델이 자동으로 호출해도 되는가, 사용자가 직접 선택해야 하는가?
- 읽기 작업인가, 쓰기 작업인가, 비용이나 권한이 필요한 작업인가?
- tool inputSchema와 outputSchema를 검증할 수 있는가?
- resource URI와 권한을 검증하고 민감 정보를 제한했는가?
- prompt argument를 검증하고 prompt injection 가능성을 줄였는가?
- host에서 승인 UI와 로그 기록을 제공할 수 있는가?
이 체크리스트를 통과하지 못한 기능은 MCP server에 넣기 전에 한 번 더 쪼개야 합니다.
정리
MCP는 에이전트 구조에서 외부 시스템과 만나는 연결 경계입니다. tools는 행동, resources는 맥락, prompts는 작업 템플릿으로 나누어 보면 역할이 선명해집니다.
다음 편에서는 이 구조 안에서 RAG가 어디에 들어가는지 보겠습니다. RAG는 단순히 문서를 검색해 넣는 기능이 아니라, 에이전트가 근거를 가져오는 context layer로 봐야 합니다.
