MCP는 왜 갑자기 표준이 됐나

요즘은 도구를 붙일 때마다 MCP를 지원하는지부터 본다. 이 블로그도 글을 올릴 때 그 규약을 쓴다. 가족이 쓰는 논문 블로그는 아예 관리자 페이지 없이, 대화창에서 글을 쓰고 고치고 발행한다. 그 통로가 MCP다.

이름만 보면 대단한 신기술 같지만 실제로 하는 일은 단순하다. AI가 바깥 도구를 부를 때 쓰는 말투를 하나로 정한 것이다. 그런데 그 단순한 합의가 2년도 안 돼 업계 표준이 됐다. 왜 그랬는지 정리해 둔다.

곱셈을 덧셈으로 바꾼다

MCP 이전에는 AI 앱마다 도구마다 연동을 따로 만들었다. 챗봇 다섯 개와 도구 스무 개를 붙이려면 백 개의 연결이 필요했다. 도구를 하나 더 만들면 다섯 곳에 각각 붙여야 했다.

가운데에 공통 규약을 하나 두면 이 곱셈이 덧셈이 된다. 도구는 규약만 지키면 되고, AI 앱도 규약만 알면 된다.

USB-C에 비유하는 이유가 이것이다. 케이블 종류를 줄인 게 아니라, 케이블을 만드는 사람과 포트를 만드는 사람이 서로를 몰라도 되게 만든 것이다.

무엇으로 만들어졌나

앤트로픽이 2024년 11월에 공개했다. 기반은 새로 만들지 않고 이미 있던 규약을 가져왔다.

• 메시지 형식은 JSON-RPC 2.0. 20년 가까이 쓰인 평범한 원격 호출 규약이다.
• 구조는 LSP(언어 서버 프로토콜)에서 가져왔다. 편집기마다 언어마다 플러그인을 따로 만들던 문제를, 편집기와 언어 서버 사이 규약 하나로 푼 그 방식이다. MCP는 같은 해법을 AI와 도구 사이에 적용했다.
• 연결 방식은 두 가지다. 내 컴퓨터에서 프로그램을 직접 띄우는 stdio, 원격 서버에 접속하는 HTTP.

flowchart LR
  H["AI 앱 (호스트)"] --- C1["클라이언트 1"] --- S1["서버: 파일"]
  H --- C2["클라이언트 2"] --- S2["서버: 깃"]
  H --- C3["클라이언트 3"] --- S3["서버: 사내 DB"]

서버가 내놓는 것은 세 가지다. 실행할 수 있는 도구, 읽을 수 있는 자료, 미리 준비된 프롬프트. 모델은 목록을 받아 보고 필요한 것을 직접 고른다. 어떤 도구가 있는지 개발자가 프롬프트에 일일이 적어 넣지 않아도 된다.

왜 갑자기 다들 쓰나

규약은 혼자 잘 만들어서 표준이 되지 않는다. 경쟁사가 채택해야 표준이 된다. MCP는 빠르게 퍼졌다.

기증이 중요했다. 한 회사가 쥐고 있는 규약에 경쟁사가 자기 제품을 얹기는 어렵다. 소유권을 내려놓자 도입을 망설일 이유가 줄었다.

올해 7월 개정으로 서버가 접속 상태를 들고 있지 않아도 되게 바뀐 점도 컸다. 요청마다 아무 서버 인스턴스로 보내도 되니, 로드밸런서 뒤에 그냥 늘어놓으면 된다.

AI와 붙었을 때 달라지는 것

MCP 자체에는 지능이 없다. 값어치는 모델 쪽에서 나온다.

도구 목록을 글로 설명해 주면 모델이 상황에 맞는 것을 고른다. 결과를 받아 다음에 무엇을 할지도 스스로 정한다. 사람이 “이럴 때는 이 API를 불러라”를 미리 적어 두는 방식과 다르다. 도구를 하나 더 꽂으면 모델이 알아서 쓴다.

그래서 붙이는 비용이 낮아질수록 효과가 커진다. 서버 하나를 만들면 클로드·ChatGPT·코파일럿에서 모두 쓸 수 있다. 규약이 덧셈으로 만들어 준 여유가 그대로 모델의 선택지가 된다.

남의 도구에 내 계정을 맡기는 문제

원격 서버로 넘어가면서 인증이 진짜 문제가 됐다. 내 캘린더와 저장소, 사내 DB를 AI 앱에 열어 주는 일이기 때문이다.

지금 사양은 이렇게 정리돼 있다.

• MCP 서버는 OAuth 2.1 리소스 서버다. 로그인은 직접 처리하지 않고 인가 서버에 넘긴다.
• 클라이언트는 어느 인가 서버에 요청할지 /.well-known 메타데이터(RFC 9728)로 찾는다.
• 토큰을 받을 때 어느 서버에 쓸 토큰인지를 명시한다(RFC 8707). 이게 없으면 악의적인 서버가 받아 낸 토큰을 다른 서버에 들고 가 쓸 수 있다.
• 받은 토큰을 그대로 다른 곳에 넘기는 것은 금지다. 토큰은 자기 앞으로 발급된 것만 받는다.

sequenceDiagram
  participant A as AI 앱
  participant M as MCP 서버
  participant S as 인가 서버
  A->>M: 도구 호출 (토큰 없음)
  M-->>A: 401 + 인가 서버 위치
  A->>S: 로그인 · 동의 (PKCE)
  S-->>A: 액세스 토큰 (대상: 이 MCP 서버)
  A->>M: 도구 호출 + 토큰
  M->>M: 서명·만료·대상·권한 검증
  M-->>A: 결과

JWT를 쓴다면 검증에서 빠뜨리기 쉬운 것이 있다. 서명 알고리즘을 서버가 고정할 것, 만료를 짧게 두고 갱신 토큰을 돌릴 것, 그리고 aud(대상)를 반드시 확인할 것. 앞의 둘은 대개 챙기지만 마지막은 빠뜨리기 쉽다. 그러면 다른 서비스용으로 발급된 멀쩡한 토큰이 내 서버에서도 통과한다.

가족 블로그에 붙인 서버는 이렇게 만들었다. 로그인은 구글에 맡기고, 허용한 이메일인지만 확인한 뒤, 그 뒤로 쓰는 토큰은 내 서버가 직접 발급한다. 구글 토큰은 저장하지 않는다. 남의 인증을 빌려 쓰되 내 자원에 대한 권한은 내가 관리하는 형태다.

토큰만 챙기면 되는 것도 아니다. 도구 설명문에 악의적인 지시를 심는 공격이 2025년 4월에 보고됐다. 모델은 도구 설명을 읽고 판단하므로, 그 설명 자체가 공격 표면이 된다. 서버를 아무거나 붙이지 않는 것, 파괴적인 동작에는 사람 확인을 끼우는 것이 현재로서는 기본이다.

정리

MCP가 표준이 된 이유는 기술이 새로워서가 아니다. JSON-RPC도 LSP 방식도 원래 있던 것이다. 새로 한 일은 붙이는 비용을 곱셈에서 덧셈으로 바꾼 것, 그리고 그 규약을 한 회사가 쥐고 있지 않게 만든 것이다.

이제는 무엇을 붙일지보다 무엇을 안 붙일지 고민할 단계에 왔다. 그 판단 기준을 세우는 일이 다음 숙제다.