Agent에게 티켓 시스템을 쓰게 하려면 그 시스템의 API를 부르는 도구를 만들면 됩니다. 그런데 AI 앱이 여러 개이고 연결할 시스템도 여러 개라면 앱마다 시스템마다 따로 만들어야 합니다. 앱이 3개이고 시스템이 3개면 연결 부품이 9개입니다.
MCP(Model Context Protocol)는 AI 앱과 외부 시스템을 잇는 공개 표준입니다. 공식 문서는 AI 앱을 위한 USB-C 단자에 비유합니다. 앱과 시스템이 모두 이 규격을 따르면 연결 부품이 앱 수와 시스템 수의 합으로 줄어듭니다. 개수를 바꿔 가며 눌러 보세요.
설명을 위한 예시입니다. USB-C 비유는 MCP 공식 문서의 표현입니다. USB-C가 모양만 맞추는 것과 달리 MCP는 주고받는 메시지의 규칙까지 정합니다.
MCP에는 세 역할이 있습니다. AI 앱인 호스트(host)가 연결을 총괄하고 서버마다 클라이언트(client)를 하나씩 만들어 전용 연결을 유지합니다. 서버(server)는 도구와 자료를 내놓는 프로그램입니다.
서버는 내 컴퓨터에서 실행될 수도 있고 원격에서 실행될 수도 있습니다. 위치가 아니라 연결 방식으로 나뉩니다. 내 컴퓨터의 서버는 표준 입출력(stdio)으로 연결하고 원격 서버는 HTTP 기반의 Streamable HTTP로 연결합니다. 서버를 눌러 확인하세요.
서버가 클라이언트에게 줄 수 있는 것은 세 가지입니다. 도구(tools)는 AI 모델이 실행하는 함수입니다. 자료(resources)는 사용자나 모델이 읽는 데이터이고 프롬프트(prompts)는 사용자를 위한 틀입니다. 셋은 쓰는 주체가 서로 다르니 눈여겨보세요.
공식 문서의 예는 데이터베이스 서버입니다. 이 서버는 질의를 실행하는 도구, 표 구조를 담은 자료, 질문 예시를 담은 프롬프트를 함께 내놓을 수 있습니다. 서랍을 눌러 보세요.
메시지는 JSON-RPC 2.0이라는 형식을 씁니다. 요청과 응답을 번호로 짝지어 주고받는 약속입니다. 클라이언트는 필요하면 서버의 능력을 묻는 server/discover를 보내고 tools/list로 도구 목록을 받은 뒤 tools/call로 하나를 실행합니다.
목록을 먼저 받으니 서버가 도구를 늘리거나 바꿔도 앱은 고칠 필요가 없습니다. 스크롤하며 메시지가 오가는 순서를 보세요.
클라이언트가 server/discover를 보내면 서버가 지원하는 규격 버전, 능력, 이름을 알려 줍니다. 꼭 거쳐야 하는 단계는 아닙니다.
tools/list 응답에는 도구마다 이름, 설명, 입력 모양(JSON Schema)이 담겨 옵니다. 앱은 이 목록을 모델에게 전해 줍니다.
모델이 도구를 고르면 앱이 tools/call에 도구 이름과 인자를 담아 서버에 보냅니다.
서버가 도구를 실행하고 content 목록에 결과를 담아 돌려줍니다. 앱은 이 결과를 모델에게 전합니다.
{ "jsonrpc": "2.0", "id": 3, "method": "tools/call",
"params": {
"name": "weather_current",
"arguments": { "location": "San Francisco", "units": "imperial" }
}
}
{ "jsonrpc": "2.0", "id": 3,
"result": {
"resultType": "complete",
"content": [
{ "type": "text",
"text": "Current weather in San Francisco: 68°F, partly cloudy ..." }
]
}
}name은 tools/list로 받은 이름과 같아야 하고 arguments는 그 도구의 입력 모양을 따릅니다. 앞서 배운 도구의 이름과 설명, 입력 스키마가 그대로 쓰입니다.id가 요청과 같아 어느 요청의 답인지 알 수 있습니다. content에는 글뿐 아니라 이미지나 자료도 담을 수 있습니다.모든 요청에는 규격 버전과 클라이언트 정보를 담는 _meta가 붙는데 위 예시에서는 줄였습니다. 메시지는 MCP 2026-07-28 공식 문서에서 가져왔고 이 글에서 직접 실행한 것은 아닙니다.
도구를 부르는 길에는 두 구간이 있습니다. 모델과 앱 사이에서 모델이 "이 도구를 이 인자로 불러 주세요"라고 말하는 구간이 tool calling입니다. 이 형식은 모델 제공사의 API가 정합니다.
앱과 도구 사이에서 도구 목록을 얻고 실제로 실행하는 구간이 MCP입니다. 모델은 도구가 MCP 서버에서 왔는지 직접 만든 함수인지 알 필요가 없습니다. 단계를 눌러 어느 구간이 움직이는지 보세요.
현재 최신 규격은 2026-07-28 판입니다. MCP가 무상태(stateless)가 된 것이 가장 큰 변화입니다. 모든 요청이 규격 버전과 클라이언트의 능력을 _meta에 직접 싣기 때문에 서버가 이전 요청을 기억하지 않아도 요청 하나만 읽고 처리할 수 있습니다. 덕분에 서버를 여러 대로 늘리기도 쉬워집니다.
서버가 처리 도중 사용자에게 물어야 할 때는 다중 왕복 요청(MRTR, Multi Round-Trip Requests) 방식을 씁니다. 서버가 먼저 사용자에게 묻는 대신 "추가 입력이 필요합니다"라는 결과를 돌려주고 클라이언트가 답을 모아 같은 요청을 다시 보냅니다. 단계를 눌러 보세요.
같은 규격은 오래 걸리는 작업을 위한 Tasks 확장도 정의합니다. 서버가 작업을 가리키는 표(handle)를 돌려주면 클라이언트가 나중에 상태를 확인하고 결과를 가져갑니다. 확장은 서버와 클라이언트가 모두 지원할 때만 쓰입니다. 서버가 모델 답변을 대신 요청하던 sampling과 로그 전달은 이번 판에서 폐지 예고(deprecated)되었습니다.
A2A(Agent2Agent)는 Agent끼리 일을 주고받는 규격입니다. A2A 공식 사이트는 MCP를 세로, A2A를 가로로 비유합니다. MCP는 Agent 하나를 도구로 깊게 만들고 A2A는 그 경계를 넘어 Agent들을 잇습니다.
두 규격은 경쟁하는 사이가 아니라 맡은 역할이 다릅니다. 각 Agent는 자기 도구를 쓸 때 MCP를, 서로 협력할 때 A2A를 함께 씁니다. 다음 글에서는 사내 티켓 시스템을 MCP 서버로 직접 만들어 보겠습니다.