🐹🦜 이 글에 등장하는 두 캐릭터
- 🐹
모찌 (햄스터)… AI는 아직 공부 중. “그거 무슨 뜻이야?”라고 순수하게 질문하는 학생 역할 - 🦜
키나코 (사랑앵무)… AI로 자료 조사를 하는 해설자 역할. 상냥하게 깊이 파고들어 가르치는 선생님 역할
이 글은 두 캐릭터의 대화를 받아 적은 형식입니다. 발언 시작 부분에 있는 이모지 + 이름이 화자입니다.
🐹 모찌: “MCP라는 걸 요즘 자주 듣는데, 대기업 엔지니어들이 전문 지식을 총동원해서 사용하는 어려운 시스템이라는 느낌이야.”
🦜 키나코: “대기업만 사용할 수 있다고 생각하는 마음은 충분히 이해해. 이전까지는 연결 메커니즘 자체가 상당히 복잡했었거든.”
🦜 키나코: “그 감각은 사실 이제 구식이야. 2026년 7월 28일에 MCP의 사양(仕様)이 바뀌면서 상황이 많이 달라졌어.”
🐹 모찌: “에, 사양이 바뀌었다니? 나는 전혀 몰랐는데….”
🦜 키나코: “무리가 아니야. 공식적으로 발표된 게 불과 지난달이라서 그래. 여기서부터 차근차근 내용을 같이 보자.”
🦜 키나코: “쌍방향으로 계속 연결을 유지하는 방식에서, 요청(Request)마다 완결되는 단순한 형태로 재설계됐거든.”
🐹 모찌: “뿌리부터 바뀌었다는 거네? 그거 꽤 큰 이야기잖아.”
🦜 키나코: “응. 게다가 구현 난이도도 동시에 낮아지고 있어. 다만 인증(Authentication)에서 절대 빼놓을 수 없는 3가지 필수 요소(MUST)가 있는데, 거기서 벗어나면 쉽게 사고를 치게 돼.”
🐹 모찌: “3가지 MUST…? 뭔가 무서운 울림이야.”
🐹 모찌: “구현이 쉬워진 건 기쁘지만, 쉬워진 만큼 어딘가에 피해가 몰릴 것 같아서 좀 경계하게 되네.”
🦜 키나코: “그 직감은 틀리지 않아. 구현이 쉬워진 만큼, 그 여파는 전부 인증 쪽에 집중되고 있어. 그래서 오늘은 그 부분을 가장 중점적으로 자세히 다룰 거야.”
🦜 키나코: “무엇이 바뀌었고, 지금부터 MCP 서버를 만든다면 실제로 어떻게 코딩해야 하는지, 공식 문서 원문과 함께 3가지 MUST까지 순서대로 보여줄게.”
🐹 모찌: “저기 키나코. MCP라는 게 말이야, 연결하기 전에 서로 인사하고, 그 다음에 대화를 시작하는 시스템이잖아? 내가 예전에 배웠을 때 그렇게 기억했는데, 그거 맞아?”
🦜 키나코: “응, 그런 기억법은 이전까지는 완전히 정답이었어. 하지만 지금 최신 사양서를 열어보면, 그 인사가 이미 빠져 있거든. 나도 처음엔 놓친 건가 싶어서 두 번이나 확인했어.”
🐹 모찌: “에? 없어졌다고? 내가 배운 게 어디로 가버린 거야. 아직 새로운 이야기라고 생각했는데, 내가 외웠던 게 통째로 쓸모없어진 거야?”
🦜 키나코: “쓸모없는 건 아니야. 우선 MCP의 사양은 버전이 숫자가 아니라 날짜로 관리되고 있어. 이전 안정판이 2025년 11월 25일이었고, 지금 최신이 2026년 7월 28일이야.”
🐹 모찌: “날짜? 버전 1.0이나 2.0 같은 게 아니잖아. 나는 숫자가 계속 늘어나는 것만 알았는데. 날짜로 하면 뭐가 좋은 거야?”
🦜 키나코: “언제 시점의 이야기인지 한 번에 알 수 있다는 점이야. 그리고 말이야, 이 7월 28일 버전에서는 초기화(Initialize)라는 첫 악수와 세션 ID를 가지고 다니는 헤더가 둘 다 깔끔하게 폐지됐어.”
🐹 모찌: “에? 세션 ID라니, 나 얼마 전에 배운 건데! 그게 이미 폐지되었다니 무슨 일이야. 내 기억의 유통기한이 너무 짧잖아!”
🦜 키나코: “마음은 이해해. 공식 블로그에는 쌍방향으로 상태 저장형(Stateful) 프로토콜에서, 요청과 응답의 무상태형(Stateless) 프로토콜로 바뀐다고 명확하게 쓰여 있어.”
🐹 모찌: “상태 저장형에 무상태형… 미안, 나한테는 완전히 주문 같은 거야. 쉽게 말해서, 이쪽을 기억해 주는 담당자가 사라진다는 뜻이야?”
🦜 키나코: “가까워. 전에는 처음에 악수하고, 그 대화의 연속을 계속 기억하게 해줬었어. 지금은 한 번의 요청만으로 이야기가 완결되기 때문에, 애초에 기억해 줄 필요가 없는 거야.”
🐹 모찌: “아, 접수처에서 이름을 외워주는 걸 안 하고, 매번 전부 종이에 적어서 창구에 내미는 느낌인가. 좀 귀찮긴 하지만, 그래도 나도 어떻게든 상상할 수 있겠어.”
🦜 키나코: “응, 그 번거로움의 대신 큰 이득이 있어. 같은 기계로 돌아갈 필요가 없기 때문에, 순서대로 여기저기 배포하기만 하면 되고, 어느 서버가 받아도 제대로 작동하는 거야.”
🐹 모찌: “그럼 사람이 붐빌 때는 빈 곳으로 돌릴 수 있다는 거네. 가게에 비유하자면, 어떤 계산대에 줄을 서든 상관없이 대기열을 처리하는 느낌이잖아. 그건 확실히 가게 입장에서도 편할 것 같아.”
🦜 키나코: 응, 부하 분산이 훨씬 쉬워져. 아니면 또 하나, 연결된 채로 두는 구식 HTTP + SSE 방식의 통신 방법도 이번 버전을 기점으로 공식적으로 비권장(deprecated)되었어.
🐹 모치ー: 에? 비권장이라니, 이제 쓰면 안 된다는 거야? 지금 그걸로 돌아가고 있는 사람들은 언젠가 갑자기 멈춰버리면 큰일 아닌가. 나 같으면 절대 울 거야.
🦜 키나코: 거긴 괜찮아. 무려 1년 전체의 전환 기간이 주어지거든. 여기까지 오면서 시스템이 바뀌었다는 건 이해했지? 그런데 구현 난이도까지 낮아졌다는 이야기는 사실 더 의외야.
🐹 모치ー: 구현 난이도가 낮아졌다 해도, 전문가가 며칠씩 공들여서 하는 큰일이라는 이미지가 떨쳐지지 않는데.
🦜 키나코: 그럼 실물을 보여줄게. 공식 Python SDK는 mcp라는 패키지로, Python 3.10 이상만 있으면 바로 시작할 수 있어.
🐹 모치ー: 애초에 '툴 등록(tool registration)'이 뭘 하는 거야? AI가 쓸 수 있는 도구장에 내 함수를 나열하는 작업 같은 건가?
🦜 키나코: 그 이해로 맞아. 지금까지는 이 목록을 위해 JSON Schema라는 명세서를 손으로 작성해야 했거든.
🐹 모치ー: 에, 그 JSON Schema라는 걸 안 써도 되는 거야? 나는 저 파란색 중괄호들이 줄줄이 늘어선 것만 봐도 잠이 올 것 같은데.
🦜 키나코: 쓸 필요 없어. 함수 위에 @mcp.tool()이라는 한 줄을 추가하는 것만으로 돼. 파싱 코드도 검증 코드도 단 한 줄도 필요하지 않아.
🐹 모치ー: 데코레이터(Decorator)라는 건 케이크에 딸기를 동글동글 올려놓는 느낌 같은데, 맞아?
🦜 키나코: 비슷해. 함수에 '이건 툴이야'라는 표시를 붙이는 한 줄일 뿐이야. 내용은 평소 쓰던 Python 코드를 그대로 사용하면 돼.
🐹 모치ー: 음... 아직 반신반의네. 실제로 돌아가는 코드를 화면으로 보여줬으면 좋겠어.
🦜 키나코: 공식 README 예시가 이래. @mcp.tool() 다음 줄에 def add(a: int, b: int) -> int 이렇게 끝이야.
🐹 모치ー: 어? 잠깐만. 그냥 덧셈 함수잖아. 입문서 맨 첫 페이지랑 아무것도 달라진 게 없는데.
🦜 키나코: 호출할 수 있어. 이 한 줄이 붙는 것만으로, 일반 함수의 세 가지 요소가 AI가 볼 수 있는 형태로 자동으로 변환되어 등록되는 거야.
🐹 모치ー: 세 가지요? 어디랑 어디예요? 순서대로 하나씩 알려줬으면 좋겠는데.
🦜 키나코: 먼저 함수 이름인 add가 그대로 툴의 식별자가 돼. 두 번째는 docstring, 즉 함수 아래에 적는 설명문이야.
🐹 모치ー: 에, 주석처럼 가볍게 쓰는 설명문이 AI용 사용설명서가 된다는 거야? 놀랍다.
🦜 키나코: 그런 거지. 세 번째는 타입 힌트(Type Hint)로, a: int 같은 부분이 그대로 입력 스키마가 되는 거야.
🐹 모치ー: 잠깐만요. 함수에서 설명서까지 자동으로 만들어내는 거라니 복잡한 시스템이네요. 그거 누가 준비해 준 거예요?
🦜 키나코: FastMCP라는 프레임워크야. 공식 Python SDK는 이게 기반이 된 거야.
🦜 키나코: 언어도 Python만은 아니야. TypeScript라면 @modelcontextprotocol/sdk로, Node.js 18 이상이면 같은 최소 구성으로 만들 수 있어.
🐹 모치ー: 완성된 서버가 AI랑은 어떻게 연결되는 거예요? 그 부분만 점과 점이 이어지지 않아서 좀 찜찜해요.
🦜 키나코: 연결 방식은 전송 방식(Transport)이라고 해. Python SDK는 stdio와 Streamable HTTP, 그리고 SSE 세 가지를 지원하고 있어.
🐹 모치ー: 이렇게 간단해도 괜찮을까... 싶었는데, 쉬운 만큼 위험한 부분이 있지 않을까요? 뭔가 불길한 예감이 드는데요.
🦜 키나코: 모치ー, 날카롭네. 솔직히 말하면 나도 처음엔 인가(Authorization) 장을 뒤로 미뤘었어. 나중에 보면 된다는 안일한 생각이 들었던 거지.
🐹 모치ー: 에? 키나코가 뒤로 미룬 건 엄청난 거잖아. 나 방금까지 신났는데 갑자기 등골이 오싹해지네.
🦜 키나코: 맞아, 여기가 오늘 가장 중요한 부분이야. 함수 하나만으로 돌아가기 때문에 인증 절차를 건너뛰기 쉽거든. MCP의 인가는 OAuth 2.1을 기반으로 해.
🐹 모치ー: 오오스(OAuth)라니, 앱에서 '접근 허용하시겠습니까?' 하고 뜨는 그 화면 말하는 거죠?
🦜 키나코: 응, 그 시스템의 새로운 버전이야. 명세서상으로는 MCP 서버가 토큰을 지키는 쪽이고, 클라이언트가 가져오는 쪽이라는 역할이 정해져 있어.
🐹 모치ー: 지키는 쪽과 가져오는 쪽으로 역할이 확실히 나뉘었네요. 지키는 쪽의 MCP 서버는 무엇까지 확인해야 하는 거예요?
🦜 키나코: "게다가 공식 문서에서는 대문자 MUST로 '절대 지켜야 한다'는 세 가지 조건을 두고 있어. 여기를 벗어나는 순간 사고가 날 수 있는, 가장 위험한 포인트지."
🐹 모찌: "세 개나 있어? 아까까지 '데코레이터 하나로 완성'이라며 기뻐했는데, 갑자기 이야기가 무거워졌잖아."
🦜 키나코: "첫 번째는 토큰의 패스쓰루(Pass-through) 금지야. 사양 원문은 '자신에게 발행된 토큰 외에는 받아서는 안 된다'고 되어 있어. MUST NOT이야."
🐹 모찌: "손님한테 받은 열쇠를 그대로 뒤쪽 금고에 꽂으면 안 된다는 거야? 나 같으면 그냥 계속 재사용할 것 같은데."
🦜 키나코: "바로 그거야. 사내 API를 호출할 때는 클라이언트의 열쇠를 그대로 전달하지 않고, 상위 권한 서버가 발행한 다른 토큰을 사용해야 해."
🐹 모찌: "클라이언트의 열쇠와 사내 API에 쓸 열쇠는 완전히 별개라는 거네. 그냥 넘겨도 작동하니까 눈치채지 못하는 사람들이 많겠어."
🦜 키나코: "거부한 후의 처리 방식도 정해져 있어. 툴 측의 실패는 isError 플래그와 이유 문장으로 반환하고, 모르는 툴을 호출당하면 JSON-RPC 에러 코드로 돌려줘야 해."
🐹 모찌: "그냥 실패했다고 거절만 하는 게 아니네. 문전박대할 때도 사유서를 건네는 느낌인가? 그냥 조용히 내쫓으면 아무도 고칠 수가 없잖아."
🦜 키나코: "두 번째는 오디언스 바인딩(audience binding)이야. RFC 8707에 따라 토큰이 자신을 위한 것인지 검증해야 하고, 다른 것이면 반드시 거부해야 해."
🐹 모찌: "수신자가 자신이 아닌 택배는 받지 않는다는 뜻이네. 내용물도 확인하지 않고 도장을 찍으면 안 된다는 이야기인가?
🦜 키나코: "맞아. 공식 보안 문서에서는 '혼란한 대리인(confused deputy)' 공격에 대한 방어책으로, 클라이언트별 동의 관리를 MUST로 하고 있어."
🦜 키나코: "같은 문서에는 SSRF(Server-Side Request Forgery)도 언급하고 있어. 가져오는 출처를 확인하지 않고 연결하면, 클라우드의 내부 정보까지 들여다보게 되고 서버 전체가 탈취되는 이야기도 실려 있거든."
🐹 모찌: "갑자기 무서운 이름들이 나오네. 그럼 가장 중요한 세 번째는 뭐야? 나중에 와서 울고불고하는 건 이제 싫으니까."
🦜 키나코: "세 번째는 클라이언트 측 이야기야. 2026년 7월 28일 개정으로, 권한 응답(authorization response)의 iss, 즉 발행원을 나타내는 값을 RFC 9207에 따라 검증하는 것이 필수화됐어."
🐹 모찌: "발행원의 명찰을 매번 확인하라는 거야? 가짜 권한 서버로 속아 넘어갔다간 사내 내용물 전부를 가져가 버리겠네."
🦜 키나코: "응, 그게 mix-up 공격에 대한 방어책이야. 구현은 함수 하나로 끝날 수도 있지만, 이 세 가지 중 하나라도 빠지면 사내 데이터가 그냥 새어나가는 거야."
🐹 모찌: "휴... 인증 이야기는 머리에서 김이 날 것 같았어. 그런데 말이야, 그렇게 만든 서버는 결국 어떻게 내 클라우드(Claude)에 연결하는 거야?"
🦜 키나코: "거기는 정말 간단해서 깜짝 놀랄 정도야. 터미널을 열고 claude mcp add라고 입력하면 돼. 그걸로 끝이야."
🐹 모찌: "명령어 하나?! 아까까지 오디언스 같은 걸로 위협받았는데, 연결하는 건 이렇게 가벼워? 나도 할 수 있겠네!"
🦜 키나코: "무거운 건 내부를 지키는 이야기고, 연결 작업 자체는 간단한 거야. 자신의 컴퓨터에서 실행할 거라면, stdio가 기본값이니까 지정할 필요도 없어."
🐹 모찌: "stdio라는 게 같은 컴퓨터 안에서 입으로 전달하듯이 직접 주고받으니까 주소도 필요 없다는 얘기였지?"
🦜 키나코: "응, 잘 기억하고 있네. 그래서 첫 단계에 적합한 거야."
🐹 모찌: "그럼 회사 서버에 두고 다 같이 쓰는 타입은 어떻게 돼?"
🦜 키나코: "거기는 URL로 도착하는 호스트형이니까, --transport http를 추가하면 돼. 공식 문서에 예시가 있으니까 그걸 수정하면 괜찮아."
🐹 모찌: "연결한 후에 제대로 작동하는지 확인할 방법 같은 건 있어? 모르겠으면 털 고르는 데 도망갈 것 같거든."
🦜 키나코: "공식 MCP Inspector가 있어. npx로 실행하면 웹 화면, 명령어, 터미널 표시의 세 가지 방식으로 내용을 들여다볼 수 있어."
🐹 모찌: "화면으로 볼 수 있으면 안심이네. 그래도 서버 자체를 처음부터 짜는 건 역시 무리인 것 같고."
🦜 키나코: "공식 서버 모음집들이 좋은 참고가 돼. Microsoft도 PostgreSQL 연결 예시를 권한 처리 방식까지 공개하고 있거든."
🐹 모찌: "좋아, 연결하는 방법은 알겠어. 그럼 결국 우리 회사 오래된 툴에 연결하려면 어떻게 만들어야 해?"
🦜 키나코: "좋은 질문이야. 우선 기존 사내 API 앞에 접수 창구(접점)를 딱 하나 추가하는 방식. 내부 메커니즘은 수정하지 않아."
🐹 모치- "에, 다시 만들 필요가 없다고? 우리 오래된 재고 관리 시스템으로도 괜찮을까?"
🦜 키나코 "거기가 핵심이야. 이렇게 얇은 창구(게이트웨이)를 추가하는 방식을 Resource Gateway 패턴이라고 불러."
🐹 모치- "헤에, 일부러 이름까지 붙여놨네. 다른 패턴들도 있고, 상황에 따라 골라 쓰는 거라는 거지?"
🦜 키나코 "그 감각으로 맞아. 두 번째는 Semantic Adapter 패턴이야. 사내 데이터를 의미가 전달되는 형태로 가다듬어서 넘겨주는 방식이지."
🐹 모치- "그건 나도 알 것 같아. 전표 번호만 받으면 무슨 전표인지 모르잖아. 세 번째는?"
🦜 키나코 "세 번째가 API Gateway 패턴이야. 여기저기 흩어진 사내 API들을 하나로 모으는 형태로, 해외 대기업들도 사용하고 있다고 보도되고 있어."
🦜 키나코 "오늘 이야기를 되돌아보면, MCP는 스테이트리스화(Stateless)·SSE 비권장·인가 강화라는 세 가지 큰 변화를 거치고 있어."
🐹 모치- "어려워 보였는데, 일단 돌아가게만 한다면 나도 할 수 있을 것 같은데."
🦜 키나코 "그 마음가짐이 가장 중요해. 어려워 보여도 실제로 직접 손을 움직여보면 이해 속도가 완전히 달라지거든."
🦜 키나코 "그렇게 생각해 준다면, 오늘부터 할 수 있는 한 걸음이 있어. 명령어 하나만 치면 되거든."
🐹 모치- "명령어 하나? 그 정도라면 집에 가서 바로 시도해 볼 수 있겠는데."
🦜 키나코 "npx @modelcontextprotocol/inspector 라고 치기만 하면, 공식 MCP Inspector 화면이 열린단 말이야."
🐹 모치- "그 정도라면 오늘 중에는 나도 할 수 있겠는데."
🦜 키나코 "다만, 실제로 사내 API에 연결할 때는 오늘 이야기한 세 가지 MUST—토큰 패스스루 금지(Token Pass-through Prohibition)·audience 검증·iss 검증을 절대 잊으면 안 돼."
🐹 모치- "구현은 함수 하나로 할 수 있는데, 인증만은 그렇게 신경을 써야 하네. 격차가 엄청나다."
🦜 키나코 "응. 쉬운 부분과 무거운 부분의 차이가 명확하게 드러나는 게, 지금 MCP의 모습인 거지."
🐹 모치- "무거운 부분, 제대로 명심할게. 일단 구현하는 것부터 차근차근 손을 움직여 볼게."
🦜 키나코 "MCP 서버를 실제로 사내 API에 연결해서 구동해 본 이야기는, 사실 또 다른 영상으로 만들었거든."
🦜 키나코 "오늘 내용과 연결해서 봐주면, 사내 도구 연결 이미지가 더 선명해질 거라고 생각해."
🐹 모치- "확실히, 책상 위 이야기만으로는 아직 와닿지 않는 부분이 있고, 실제로 작동하는 걸 내 눈으로 보면 이해가 급격히 깊어질 것 같은 기분이 들어."
🐹 모치- "에, 그거 엄청 궁금한데. 오늘 이야기가 끝나면, 무조건 나중에 자세히 보러 갈게."
🐹 모치- "그러고 보니 주인도 요즘 이런 도구에 대해 잘 알게 되면서, 우리들 태블릿 사용 시간이 또 늘어난 것 같아."
🦜 키나코 "착각은 아닌 것 같아. 뭐, 우리도 남의 말 할 순 없지만. 댓글 창에서 질문이나 감상도 많이 기다릴게."
키나코모치-의 테크 깊이 파기 에서는 AI/LLM을 중심으로 한 기술 전반을 햄스터(🐹 모치-)와 지능새(🦜 키나코)의 대화 형식으로 재미있게 해설하고 있습니다.
▶️ 영상으로 보기 → MCP 서버 자작은 쉬울까? 하지만 인증의 3가지 MUST는 놓칠 수 없다
👍 이 글이 도움이 되었다면 LGTM·저장해 주시면 큰 힘이 됩니다!
📺 채널 구독하기 → 키나코모치-의 테크 깊이 파기
🔗 다른 해설 영상 보기 → 키나코모치-의 테크 깊이 파기 영상 목록
