앱은 조용해 보여도, 뒤에서는 아주 바쁘다
앞 장에서 우리는 무대 위 등장인물을 만났습니다. Host가 전체를 조율하고, Client가 실제 연결을 맡고, Server가 기능을 제공합니다.
이번 장에서는 그다음 질문으로 들어갑니다.
"그래서 얘네는 실제로 무슨 말로 대화하는데?"
사용자는 그냥 이렇게 말합니다.
"README 읽고 요약해 줘."
하지만 뒤에서는 생각보다 질서정연한 대화가 오갑니다. 아무 말이나 툭 던지는 게 아니라, 정해진 형식으로 요청하고, 결과를 돌려주고, 필요하면 중간 진행 상황도 알려 줍니다.
이 장을 읽고 나면 다음이 깔끔해집니다.
로컬에서 내 컴퓨터 안에 서버를 띄우는 이유가 무엇인지, 반대로 어떤 서버는 URL로 원격 접속하는지, 그리고 둘 다 결국 같은 MCP 대화법을 쓴다는 점까지 한 번에 이해할 수 있습니다.
쉽게 말해, 이번 장은 MCP의 말투와 통화 방식을 배우는 시간입니다.
먼저 전체 흐름부터 한 번에 보자
복잡한 용어보다 장면이 먼저 잡히면 이해가 쉽습니다.
예를 들어 사용자가 VS Code 같은 Host에서 이렇게 말한다고 해 봅시다.
"현재 프로젝트에서 package.json을 읽고, 주요 라이브러리를 요약해 줘."
이 요청 뒤에서는 대략 이런 흐름이 일어납니다.
Host가 "이건 파일을 읽어야 하네"라고 판단합니다.
Host 안의 Client가 파일 시스템 MCP 서버와 연결합니다.
Client는 정해진 JSON 형식으로 "이 기능을 실행해 줘" 또는 "이 자료를 읽게 해 줘"라고 요청합니다.
Server는 요청을 처리하고 결과를 돌려줍니다.
Host는 그 결과를 바탕으로 사람에게 자연스럽게 설명합니다.
겉으로는 한 번의 질문처럼 보이지만, 안쪽에서는 초기 연결 → 기능 확인 → 요청 → 응답 → 필요하면 알림 같은 절차가 정돈되어 있습니다.
이 절차를 가능하게 해 주는 핵심이 바로 JSON-RPC, 세션, 전송 방식(Transport) 입니다.
JSON-RPC: MCP가 쓰는 공용어
MCP는 메시지를 주고받을 때 JSON-RPC 2.0 기반 형식을 사용합니다.
이 말을 처음 들으면 괜히 어렵게 느껴집니다. 하지만 뜻은 단순합니다.
JSON은 데이터를 적는 방식입니다. 중괄호와 키-값으로 이루어진 익숙한 형식이죠.
RPC는 Remote Procedure Call의 줄임말인데, 멀리 있는 기능을 마치 함수 부르듯 호출한다는 뜻입니다.
쉽게 말하면 JSON-RPC는 이런 느낌입니다.
"이름이 있는 기능을, 정해진 인자와 함께 호출하고, 결과를 구조화된 형식으로 받는 대화법"
MCP는 이 공용어를 쓰기 때문에, Python으로 만든 서버든 TypeScript로 만든 서버든, 로컬 프로그램이든 원격 서비스든 같은 방식으로 대화할 수 있습니다.
즉, 전송 방법은 달라도 메시지의 문법은 최대한 같게 유지됩니다.
JSON-RPC의 세 가지 기본 문장
MCP에서 가장 자주 만나는 메시지는 세 종류입니다.
요청(Request): "이 작업 해 줘."
응답(Response): "해 봤더니 이런 결과야."
알림(Notification): "참고로 이런 일이 있었어. 답장은 안 해도 돼."
이 셋만 이해해도 MCP 메시지의 성격이 거의 보입니다.
요청: 일을 시키는 문장
요청은 클라이언트가 서버에게 어떤 기능을 수행해 달라고 보낼 때 씁니다.
예를 들어 파일 읽기 도구를 호출하는 상황을 단순화하면 이런 모습입니다.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "read_file",
"arguments": {
"path": "/project/package.json"
}
}
}여기서 눈여겨볼 것은 세 가지입니다.
method는 어떤 종류의 일을 요청하는지 나타냅니다. params는 그 일에 필요한 입력값입니다. 그리고 id는 이 요청을 나중에 응답과 짝지어 주는 번호표입니다.
식당으로 비유하면 id는 주문 번호입니다. 주문이 많아도 "아, 이 응답은 아까 1번 주문에 대한 결과구나" 하고 연결할 수 있게 해 줍니다.
응답: 결과를 돌려주는 문장
서버는 요청을 처리한 뒤 성공 또는 실패 형태로 응답합니다.
성공한 경우는 보통 result가 들어갑니다.
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "{ \"name\": \"demo\", \"dependencies\": { ... } }"
}
]
}
}핵심은 응답에도 같은 id가 들어간다는 점입니다. 그래야 누가 누구에게 답한 건지 헷갈리지 않습니다.
실패한 경우는 result 대신 error가 들어갑니다.
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32602,
"message": "Invalid path"
}
}이 구조가 좋은 이유는 실패도 그냥 문자열 한 줄로 얼버무리지 않는다는 데 있습니다. 코드와 메시지가 분리되어 있으니, 클라이언트가 더 정확하게 처리할 수 있습니다.
알림: 답장을 기대하지 않는 문장
알림은 "이런 일이 있었다"를 알려 주는 단방향 메시지입니다. 여기에는 보통 id가 없습니다.
{
"jsonrpc": "2.0",
"method": "notifications/progress",
"params": {
"message": "파일을 읽는 중입니다",
"percent": 50
}
}이건 요청이 아니라 방송에 가깝습니다. 예를 들어 긴 작업을 하는 동안 진행 상황을 알려 주거나, 어떤 목록이 바뀌었다는 사실을 알려 줄 때 유용합니다.
즉, 요청과 응답이 전화라면, 알림은 무전기 방송에 가깝습니다.
id가 중요한 이유: 여러 대화가 섞여도 안 꼬이게
MCP 통신은 생각보다 바쁠 수 있습니다. 도구 목록을 물어보고, 동시에 어떤 리소스를 읽고, 긴 작업의 진행 상황 알림까지 받을 수 있습니다.
이럴 때 id가 없으면 큰일 납니다.
"이 응답이 아까 파일 읽기에 대한 건지, 도구 실행에 대한 건지"를 구분할 수 없기 때문입니다.
그래서 요청에는 id가 있고, 그 요청에 대한 응답은 같은 id를 돌려준다는 규칙이 아주 중요합니다.
반대로 알림은 답장을 기대하지 않으므로 id가 없습니다.
이 차이 하나만 기억해도 메시지 구조가 훨씬 선명하게 보입니다.
MCP는 연결하고 끝이 아니라, 시작 인사를 한다
MCP는 보통 아무 메시지부터 막 던지지 않습니다. 먼저 초기화(initialization) 과정을 거칩니다.
쉽게 말하면 첫 만남에서 서로 이런 말을 하는 겁니다.
"안녕하세요, 저는 이런 클라이언트입니다."
"반갑습니다, 저는 이런 서버이고 이런 기능을 지원합니다."
이 초기화 단계에서 확인하는 것은 주로 다음과 같습니다.
서로 어떤 프로토콜 버전까지 이해하는지
어떤 기능이나 능력(capabilities)을 지원하는지
서버 이름과 버전 같은 기본 정보
이 단계는 처음 악수하는 시간이라고 생각하면 됩니다. 악수를 제대로 해야 그다음 도구 목록 조회도, 리소스 읽기도, 알림 처리도 매끄럽게 흘러갑니다.
세션: 한 번 이어진 관계를 이어 가는 방법
이제 세션(session) 이야기를 해 봅시다.
세션은 쉽게 말해 "지금 이 클라이언트와 저 서버가 이어져 있는 하나의 대화 맥락" 입니다.
왜 이런 개념이 필요할까요? 이유는 간단합니다.
한 번 연결하고 끝나는 일이 아니라, 연결 후에 여러 요청과 응답이 이어지기 때문입니다. 그리고 그 과정에서 누가 누구와 이야기하는지, 어떤 상태가 유지되고 있는지 알아야 하기 때문입니다.
예를 들어 클라이언트가 어떤 서버와 연결한 뒤 다음 순서로 움직일 수 있습니다.
초기화한다.
도구 목록을 가져온다.
특정 도구를 실행한다.
긴 작업 동안 진행 알림을 받는다.
나중에 연결을 종료한다.
이런 흐름은 서로 이어진 하나의 관계 안에서 일어납니다. 그 관계를 가리키는 개념이 세션입니다.
세션이 특히 중요한 순간
세션은 단순히 멋있어 보이려고 있는 게 아닙니다. 실제로 매우 쓸모가 있습니다.
첫째, 연결된 상대를 식별할 수 있습니다. 특히 원격 서버는 여러 클라이언트가 동시에 붙을 수 있으니 누구와의 대화인지 알아야 합니다.
둘째, 상태를 유지할 수 있습니다. 예를 들어 어떤 기능을 지원하는지, 어떤 구독을 걸어 두었는지, 어떤 진행 작업이 있는지 관리할 수 있습니다.
셋째, 끊겼다가 다시 시작할 때 처리 방향이 생깁니다. 어떤 서버는 세션이 끊기면 새로 초기화하라고 하고, 어떤 서버는 재연결을 지원할 수 있습니다.
쉽게 말해 세션은 "전화 연결이 살아 있는 동안의 통화 상태"와 비슷합니다.
stdio와 HTTP에서 세션 감각은 조금 다르다
세션은 전송 방식에 따라 체감이 달라집니다.
stdio에서의 세션
stdio는 보통 Host가 서버를 자식 프로세스로 직접 실행합니다. 그리고 그 프로세스의 표준 입력(stdin)과 표준 출력(stdout)으로 메시지를 주고받습니다.
이 경우 세션 감각은 꽤 단순합니다.
서버 프로세스가 살아 있는 동안, 대화도 살아 있습니다. 프로세스가 끝나면 세션도 사실상 끝납니다.
즉, stdio에서는 "프로세스 생명주기"와 "연결 생명주기"가 거의 붙어 다닙니다.
Streamable HTTP에서의 세션
반대로 원격의 Streamable HTTP 서버는 독립적으로 떠 있는 서비스입니다. 여러 클라이언트를 동시에 상대할 수 있고, HTTP 요청도 여러 번 나뉘어 들어옵니다.
그래서 여기서는 세션을 더 명시적으로 다루는 경우가 있습니다. 서버는 초기화 응답에서 세션 ID를 헤더로 내려줄 수 있고, 클라이언트는 이후 요청마다 그 세션 정보를 함께 보냅니다.
이렇게 하면 서버는 "아, 이 요청은 아까 초기화한 그 클라이언트 대화의 연장선이구나" 하고 이해할 수 있습니다.
즉, stdio에서는 세션이 비교적 자연스럽게 붙어 있고, Streamable HTTP에서는 세션을 조금 더 관리형으로 다룰 수 있습니다.
전송 방식이란 무엇인가
이제 핵심 질문으로 들어가 봅시다.
전송 방식(Transport) 은 MCP 메시지를 실제로 어떻게 주고받을지 정하는 통신 통로입니다.
중요한 포인트는 이것입니다.
JSON-RPC는 대화의 문법이고, Transport는 그 문장을 실어 나르는 길입니다.
같은 한국어 문장을 종이에 적어 전달할 수도 있고, 전화로 말할 수도 있고, 메신저로 보낼 수도 있죠. 문장은 같아도 전달 수단은 다를 수 있습니다. MCP도 비슷합니다.
현재 MCP에서 핵심적으로 알아두면 좋은 전송 방식은 두 가지입니다.
stdio: 같은 컴퓨터 안에서 프로세스끼리 직접 대화
Streamable HTTP: HTTP 기반으로 로컬 또는 원격 서버와 대화
예전 자료를 보면 HTTP+SSE라는 별도 전송 방식 설명이 나올 수 있습니다. 지금은 이 방식이 Streamable HTTP로 대체되었고, 최신 문서에서는 Streamable HTTP를 중심으로 읽는 편이 좋습니다. 다만 Streamable HTTP 안에서도 서버가 SSE를 이용해 스트리밍 메시지를 보낼 수 있기 때문에, 문서마다 SSE라는 단어가 계속 보일 수는 있습니다.
stdio: 가장 가까운 거리의 대화
stdio는 이름 그대로 표준 입력과 표준 출력을 통해 통신하는 방식입니다.
Host가 MCP 서버를 직접 실행하면, 서버는 stdin으로 메시지를 읽고 stdout으로 메시지를 씁니다. 이 둘 사이를 JSON-RPC 메시지가 오갑니다.
그림처럼 표현하면 이런 느낌입니다.
Host -> 서버의 stdin
서버의 stdout -> Host
이 방식의 가장 큰 장점은 간단함입니다. 포트도 필요 없고, URL도 필요 없고, 네트워크 방화벽도 신경 쓸 일이 거의 없습니다.
그래서 다음 같은 상황에 아주 잘 맞습니다.
로컬 파일 시스템 접근
개인용 자동화 도구
IDE 안에서 직접 실행하는 개발용 서버
빠른 실험과 테스트
즉, 내 컴퓨터 안에서 돌아가는 작은 조수에게는 stdio가 아주 잘 어울립니다.
stdio가 특히 좋은 이유
stdio의 매력은 생각보다 큽니다.
첫째, 빠르고 단순합니다. 네트워크를 거치지 않으니 오버헤드가 적습니다.
둘째, 로컬 자원과 궁합이 좋습니다. 파일, 로컬 명령어, 빌드 도구처럼 내 컴퓨터 안의 것을 다루기 좋습니다.
셋째, 보안 경계가 비교적 명확합니다. 기본적으로 같은 머신 안에서만 돌기 때문에, 실수로 외부에 서버를 열어 둘 일이 적습니다.
그래서 Claude Desktop, Cursor, VS Code 같은 도구에서 로컬 MCP 서버를 붙일 때 stdio를 많이 씁니다.
stdio의 한계
하지만 stdio는 못 하는 일도 분명합니다.
가장 큰 한계는 원격 공유가 어렵다는 점입니다. 서버가 내 로컬 프로세스로 실행되니, 다른 사람의 앱이 인터넷 너머에서 그 서버를 같이 쓰는 구조와는 잘 맞지 않습니다.
또 보통 한 서버 프로세스가 하나의 클라이언트 흐름에 가깝게 묶이는 경우가 많아서, 팀 공용 서비스처럼 운영하기엔 불편할 수 있습니다.
즉, stdio는 "내 노트북 속 조수"에는 최고지만, "회사 공용 서비스"로는 불리한 경우가 많습니다.
Streamable HTTP: 멀리 있어도 대화할 수 있는 길
HTTP 기반 전송은 독립 실행 중인 서버와 통신할 수 있게 해 줍니다. 서버가 로컬에 있을 수도 있지만, 진짜 매력은 원격 서버를 붙일 수 있다는 데 있습니다.
예를 들어 사내 문서 검색 서버, GitHub 연동 서버, SaaS형 분석 서버처럼 여러 사용자가 함께 써야 하는 기능이라면 HTTP 기반이 훨씬 자연스럽습니다.
요즘 기준으로는 보통 Streamable HTTP를 많이 이야기합니다.
이 이름이 낯설어 보여도 뜻은 어렵지 않습니다. 일반 HTTP 요청/응답의 장점을 유지하면서, 필요하면 스트리밍처럼 여러 메시지를 이어 보낼 수 있는 방식입니다.
즉, 간단한 요청은 일반 JSON 응답 하나로 끝낼 수 있고, 긴 작업은 스트리밍 방식으로 진행 상황이나 여러 메시지를 순서대로 보낼 수도 있습니다.
그리고 여기서 중요한 디테일 하나가 있습니다. SSE는 더 이상 예전처럼 별도 전송 방식 이름으로 외우기보다, Streamable HTTP 안에서 서버가 스트리밍을 구현할 때 사용할 수 있는 수단으로 이해하는 편이 최신 문서와 더 잘 맞습니다.
Streamable HTTP가 좋은 이유
이 방식이 빛나는 상황은 분명합니다.
여러 클라이언트가 하나의 서버를 공유해야 할 때
서버를 클라우드나 사내 인프라에 배포해야 할 때
인증 헤더, 토큰, 프록시 같은 웹 인프라와 잘 붙어야 할 때
원격 서비스로 운영하고 싶을 때
쉽게 말해 stdio가 "내 방 안 인터폰"이라면, Streamable HTTP는 "대표번호가 있는 고객센터"에 가깝습니다.
여러 사람이 걸 수 있고, 서버도 독립적으로 운영할 수 있습니다.
왜 어떤 서버는 로컬이고, 어떤 서버는 원격일까
이제 이번 장의 핵심 질문에 정확히 답할 차례입니다.
왜 어떤 MCP 서버는 내 컴퓨터에서 직접 실행되고, 어떤 서버는 URL로 붙을까요?
답은 거의 항상 전송 방식과 운영 목적에 있습니다.
로컬에서 도는 서버가 어울리는 경우
다음 같은 기능은 로컬 서버가 자연스럽습니다.
내 컴퓨터 파일 읽기와 쓰기
로컬 Git 저장소 조작
빌드 도구, 테스트 도구, 터미널 명령 실행
개인 비밀키나 로컬 환경 변수에 접근하는 작업
이런 경우에는 내 기계 안에서 직접 실행되는 stdio 서버가 편하고 빠릅니다. 그리고 외부에 서버를 따로 배포하지 않아도 되니 시작 장벽도 낮습니다.
원격으로 붙는 서버가 어울리는 경우
반대로 이런 경우는 원격 서버가 잘 맞습니다.
회사 공용 문서 검색
SaaS API 연동
중앙 데이터베이스 접근
여러 사람이 함께 쓰는 조직용 도구
인증과 감사 로그를 중앙에서 관리해야 하는 작업
이런 기능을 각자 노트북에서 제각각 돌리는 것보다, 중앙 서버로 운영하는 편이 관리와 보안 면에서 유리합니다. 이때 Streamable HTTP가 힘을 발휘합니다.
즉, 구분 기준은 의외로 단순합니다.
내 컴퓨터 가까이 붙어야 하는 기능이면 stdio가 잘 맞고, 여러 사용자와 서비스가 함께 써야 하면 HTTP가 잘 맞는다고 생각하면 됩니다.
같은 MCP라도 느낌이 달라지는 이유
여기서 초보자가 자주 하는 오해가 하나 있습니다.
"stdio 서버와 HTTP 서버는 완전히 다른 기술 아닌가요?"
사실 핵심은 그렇게 다르지 않습니다.
둘 다 MCP 메시지를 주고받고, JSON-RPC를 기반으로 하고, 도구와 리소스와 프롬프트를 제공할 수 있습니다. 차이는 대화의 내용보다 대화를 실어 나르는 길에 더 가깝습니다.
그래서 같은 서버 기능도 환경에 따라 다른 방식으로 노출될 수 있습니다. 예를 들어 로컬에서 테스트할 때는 stdio로 돌리고, 운영 환경에서는 HTTP로 내보내는 식의 설계도 충분히 가능합니다.
이 관점을 가지면 전송 방식이 덜 무섭습니다. 문법은 비슷하고, 도로만 다르다고 생각하면 됩니다.
메시지 흐름을 실제 상황처럼 따라가 보자
이제 아주 전형적인 흐름을 하나 이야기처럼 따라가 보겠습니다.
사용자가 Claude 계열 앱이나 IDE에서 이렇게 묻습니다.
"현재 저장소의 변경된 파일을 확인하고, 커밋 메시지 초안을 만들어 줘."
먼저 Host는 이 요청을 해석합니다. 파일 상태를 확인하려면 Git 관련 기능이 필요하다고 판단합니다.
그다음 Host 안의 Client가 Git MCP 서버와 이미 연결되어 있거나, 연결을 시작합니다. 연결 직후에는 초기화 과정을 통해 서로 지원 기능을 확인합니다.
그 후 클라이언트는 서버에 어떤 도구들이 있는지 물어볼 수 있습니다. 예를 들어 git_status, git_diff, create_commit_message_prompt 같은 기능이 보일 수 있습니다.
이제 Host는 실제로 필요한 도구를 호출합니다. 서버는 변경 파일 목록을 응답으로 보내고, 필요하면 긴 작업 진행 상황을 알림으로 보낼 수도 있습니다.
마지막으로 Host는 받은 결과를 바탕으로 LLM이 자연어 설명을 만들게 하고, 사용자에게 이렇게 말합니다.
"변경된 파일은 3개입니다. 이 내용을 바탕으로 이런 커밋 메시지가 어울립니다…"
이 한 장면 안에 사실상 오늘 배운 모든 것이 들어 있습니다. JSON-RPC 요청과 응답, 초기화, 세션, 도구 발견, 실제 호출, 그리고 전송 방식이 함께 움직입니다.
만드는 사람이라면 꼭 알아야 할 디테일
이 책은 쓰는 사람뿐 아니라 만드는 사람도 함께 보니까, 서버 제작자 관점에서 중요한 포인트도 잠깐 짚고 가겠습니다.
stdout은 통신용, 로그는 stderr로
stdio 서버를 만들 때 가장 흔한 실수 중 하나는 디버그 로그를 stdout으로 찍는 것입니다.
문제는 stdout이 MCP 메시지가 지나가는 길이라는 점입니다. 여기에 로그 문자열이 섞이면 클라이언트 입장에서는 갑자기 대화 중간에 잡음이 끼는 셈입니다. 그러면 JSON 파싱이 깨지고, 연결이 이상해질 수 있습니다.
그래서 통신 메시지는 stdout, 로그는 stderr로 분리하는 습관이 매우 중요합니다.
쉽게 말해 통역 중인 전화선에 옆사람 잡담을 끼워 넣으면 안 되는 것과 같습니다.
긴 작업은 알림이 중요하다
도구 실행이 오래 걸리는 경우, 결과만 마지막에 덜렁 주는 것보다 진행 상황 알림을 함께 보내 주는 편이 좋습니다.
사용자 입장에서는 "멈췄나?"라는 불안이 줄고, Host도 더 나은 인터페이스를 보여 줄 수 있습니다.
즉, 좋은 MCP 서버는 결과만 주는 서버가 아니라, 기다리는 동안의 경험도 챙기는 서버입니다.
HTTP 서버는 인증과 보안을 더 신경 써야 한다
원격 서버가 되면 이야기가 달라집니다. 로컬 stdio 서버보다 훨씬 많은 보안 고민이 필요합니다.
누가 이 서버에 접속할 수 있는지, 어떤 헤더나 토큰으로 인증하는지, 어떤 도구는 읽기 전용이고 어떤 도구는 위험한 쓰기 작업인지 같은 점을 더 엄격하게 봐야 합니다.
또 Streamable HTTP 서버는 최신 사양 기준으로 Origin 검증, 적절한 인증, 로컬 실행 시 localhost 바인딩 같은 기본 보안 수칙도 매우 중요합니다.
즉, HTTP는 편리하지만 공용도로인 만큼 신호등도 더 많아야 합니다.
사용자 입장에서 기억하면 좋은 판단 기준
사용자라면 모든 프로토콜 세부를 외울 필요는 없습니다. 대신 다음 감각만 가지면 충분합니다.
로컬 자원을 다루는 서버는 stdio일 가능성이 높다.
팀 공유나 원격 서비스는 HTTP일 가능성이 높다.
옛 문서에 HTTP+SSE가 보여도 놀라지 말고, 최신 흐름은 Streamable HTTP 중심으로 읽으면 된다.
연결 문제는 메시지 내용보다 전송 방식과 세션 처리에서 생기는 경우가 많다.
이 정도만 알아도 "왜 이 서버는 명령어로 실행하고, 저 서버는 URL을 넣어 연결하지?"라는 혼란이 많이 줄어듭니다.
한 줄 요약이 아니라, 한 문단 요약
이 장의 핵심을 한 문단으로 묶어 보겠습니다.
MCP는 JSON-RPC라는 공용어로 요청, 응답, 알림을 주고받습니다. 이 대화는 초기화 과정을 통해 서로의 기능을 확인한 뒤 진행되고, 여러 요청이 이어지는 관계는 세션이라는 흐름 안에서 관리됩니다. 그리고 이 메시지를 실제로 실어 나르는 길이 전송 방식인데, 같은 컴퓨터 안에서 단순하고 빠르게 붙을 때는 stdio가, 여러 사용자와 원격 환경에서 운영할 때는 Streamable HTTP가 잘 맞습니다. 그래서 어떤 MCP 서버는 로컬에서 실행되고, 어떤 서버는 원격 URL로 연결되는 것입니다.
갑자기 "왜 로컬 서버와 원격 서버가 섞여 있지?"라는 의문이 훨씬 덜 이상하게 느껴지지 않나요?
다음 장으로 가기 전에
이번 장에서는 MCP가 어떻게 대화하는지를 봤습니다. 이제 여러분은 적어도 이런 문장을 읽어도 덜 당황할 겁니다.
"클라이언트가 초기화 후 세션을 유지하면서 JSON-RPC 요청을 보내고, 서버는 stdio 또는 HTTP 전송 위에서 응답과 알림을 보낸다."
예전 같으면 문장 전체가 철제 캐비닛처럼 딱딱했겠지만, 이제는 꽤 사람 말처럼 들릴 겁니다.
다음 장에서는 이 흐름을 실제 사용자 관점으로 끌고 갑니다. Claude, VS Code, Cursor 같은 도구에서 MCP를 어떻게 붙이는지, 즉 말투를 배웠으니 이제 실제 연결 버튼을 눌러 보는 단계로 넘어갑니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.