MCP라는 말을 한 번쯤 보셨을 거예요. 쉽게 말해 AI를 노션이나 광고 계정, 분석 도구 같은 외부 시스템에 연결하는 공용 규격이에요. 챗지피티나 클로드에 노션을 붙여 쓰고 계시다면 그 연결선이 바로 MCP고요.
이 규격이 7월 28일에 최대 개정판을 확정합니다. 출시 이후 가장 큰 변경이고 하위호환이 깨진다는 말이 같이 붙어 있어서, 붙여둔 게 다 끊기는 건 아닌지 걱정하는 분들이 있더라고요.
그런데 찾아보니 끊길 걱정이 제일 작은 항목이었어요. 신구 버전이 서로 만나면 옛 방식으로 되돌아가도록 폴백이 양쪽에 다 들어가 있거든요. 정작 눈여겨봐야 할 건 규격이 원래 강제하던 안전장치 몇 개를 걷어내고 그 책임을 만드는 쪽에 넘겼다는 대목이었어요.
무엇이 바뀌는지, 왜 끊김 걱정은 접어도 되는지, 그리고 MCP를 붙여 쓰는 입장에서 이번 주에 실제로 확인할 게 뭔지 제가 찾아본 걸 순서대로 풀어볼게요.
7월 28일에 확정되는 MCP 개정판
버전 이름부터 날짜예요. 2026-07-28이고, 초안은 5월 21일에 잠갔고, 그 뒤 열 주를 각 언어 개발 도구가 맞춰보는 검증 기간으로 뒀어요. 파이썬과 타입스크립트, 고, 씨샵 네 언어의 베타 도구가 6월 29일에 먼저 나왔고요. 규격 하나 바꾸는 데 이 정도 활주로를 깔았다는 게 규모를 짐작하게 해요.
연결을 붙잡지 않는 MCP로
가장 큰 변화는 연결을 붙잡고 있지 않게 된 거예요. 지금까지는 대화를 시작할 때 서로 인사를 나누고(핸드셰이크) 그 대화에 번호표(세션 아이디)를 붙여서, 이후 모든 요청이 그 번호를 들고 다녔어요. 전화를 걸어 통화를 계속 유지하는 방식에 가까웠죠.
개정판은 그 인사 절차와 번호표를 아예 없앴어요. 대신 필요한 정보를 요청마다 봉투에 같이 넣어 보내요. 전화 대신 매번 편지를 부치는 셈이에요. 그래서 요청이 어느 서버에 떨어져도 상관이 없어졌고요.
원래 MCP는 내 노트북에 붙여 쓰는 개인 도구로 설계됐는데, 그 구조 그대로 클라우드에 올리다 보니 운영이 복잡해진 걸 되돌린 거예요. 이제는 평범한 웹 서버처럼 굴러가서 서버 여러 대에 그냥 올리면 되고, 배포 중에 진행 중이던 작업이 끊기는 일도 줄어요.
서버가 화면까지 띄우는 MCP 앱
두 번째는 MCP 앱이에요. 지금까지 MCP 서버가 보낼 수 있는 건 사실상 글자였어요. 요청을 받고 결과를 텍스트나 데이터로 돌려주는 게 전부였죠.
개정판부터는 서버가 화면 자체를 보낼 수 있어요. 대화창 안에 서버가 만든 진짜 화면이 뜨는 거예요.
승인 버튼이 달린 확인 창, 항목을 골라 담는 화면, 간단한 대시보드 같은 게 채팅 안에서 바로 돌아간다고 보시면 돼요. 사내 대시보드나 승인 절차를 붙이려고 따로 웹사이트를 만들던 비용이 내려가는 쪽이라, 반가운 변화이긴 해요.
여기에 하나가 더 붙어요. 작업 중간에 서버가 사용자한테 되물을 수 있는 방식도 새로 정리됐거든요. 예를 들어 백만 건을 지우기 직전에 정말 지울지 확인을 받아야 하면, 예전엔 통화를 붙잡은 채 답을 기다렸는데 이제는 질문을 봉투에 담아 돌려보내고 답을 받아 다시 이어가요.
폐기되는 세 가지와 12개월 유예
기존 기능 셋에 폐기 딱지가 붙었어요. 어디까지 파일을 열어도 되는지 경계를 알려주던 기능(roots), 서버가 AI한테 대신 생각을 시키던 기능(sampling), 그리고 기록을 남기던 기능(logging)이에요. 대신 최소 12개월은 그대로 동작하고, 앞으로는 폐기와 삭제 사이에 최소 1년을 두는 규칙 자체가 규격에 박혔어요.
오래 걸리는 작업을 따로 떼는 구조도 실험 딱지를 떼고 정식 확장으로 옮겨갔어요. 실험판을 쓰고 있었다면 이건 손을 봐야 하고요.
구버전 MCP도 계속 붙는 이유
여기가 제가 제일 오해했던 부분이에요. 하위호환이 깨진다는 표현만 보고 신버전 서버와 구버전 클라이언트가 서로 못 붙는 줄 알았거든요. 그런데 개발 도구 베타 안내를 읽어보니 양쪽 다 폴백이 들어가 있었어요.
신버전 서버는 옛날 방식의 인사 절차에도 계속 답해요. 구버전 클라이언트가 찾아오면 예전처럼 받아준다는 뜻이고요. 반대로 신버전 클라이언트가 옛 서버를 만나면 스스로 옛 방식으로 되돌아가요. 그러니까 규격이 바뀌었다는 이유만으로 쓰던 연결이 8월에 뚝 끊기는 그림은 잘 안 나와요.
실제로 깨지는 자리는 훨씬 좁아요. 실험판 상태이던 작업 기능을 쓰고 있었거나, 오류 번호를 코드에 그대로 박아둔 경우 정도예요. 자료를 못 찾았을 때 돌려주던 번호가 MCP 고유 번호에서 업계 표준 번호로 바뀌는데, 그 숫자를 직접 비교하도록 짜뒀다면 그 줄이 어긋나요.
다만 이건 규격이 원인일 때 이야기고요. 실제로는 서버를 굴리는 쪽이 새 구조로 옮기는 과정에서 손이 미끄러지는 게 더 흔해요. 특히 로그인과 권한 처리를 잘못 건드리면 붙던 게 안 붙거나, 더 나쁘게는 붙지 말아야 할 게 붙어요. 그래서 8월 초에 한 번씩 돌려보는 건 여전히 필요하고, 이유가 다를 뿐이에요.
진짜 바뀐 건 안전장치가 있던 자리
끊김 걱정을 내려놓고 나니 다른 게 보이더라고요. 보안 업체 백슬래시(Backslash)가 이번 개정으로 새로 열리는 공격면 세 가지를 짚었는데, 셋 다 성격이 같았어요. 규격이 대신 지켜주던 걸 걷어내고 그 자리를 만드는 쪽 재량으로 넘긴 항목들이에요. 보안 도구를 파는 회사라 위험을 세게 말하는 건 감안하고 봤는데, 구조 자체는 규격 문서와 맞아떨어졌어요.
파일 경계가 규격에서 각자 알아서로
폐기된 셋 중 roots가 그 경계를 담당하던 기능이에요. 어디까지가 작업 범위인지를 규격 차원에서 알려주던 자리였죠. 이게 빠지면 경계를 지키는 방식이 만드는 사람마다 달라져요. 지키는 곳도 있고 안 지키는 곳도 생기는 거예요.
백슬래시가 든 예가 인상적이었어요. 보고서 하나 만들라고 시킨 도구가 340개 넘는 다른 파일을 같이 열어봤고, 그 안에 비밀번호와 열쇠가 담긴 파일들이 있었다는 거예요. 해킹당한 것도 아니고 도구가 오작동한 것도 아니에요. 막아주는 선이 없으니 그냥 다 열어본 거죠.
접근 열쇠가 헤더에서 대화 본문으로
번호표가 사라지면서 그 자리를 손잡이 같은 문자열이 대신해요. 예전 번호표는 사람 눈에 안 보이는 통신 헤더에 들어 있었는데, 새 손잡이는 대화 안에 그대로 등장해요. 그 문자열이 대화에 보여야 AI도 들고 다닐 수 있으니까요.
문제는 대화가 남는 곳이 한둘이 아니라는 점이에요. 채팅 기록에도 남고, 캡처해서 붙인 티켓이나 공유한 화면에도 남아요. 그 문자열을 가진 사람이 곧 접근 권한을 가지는 구조라면, 퇴사한 사람의 옛 대화 로그가 유효한 열쇠로 남을 수도 있고요.
서버가 보내는 게 글자에서 화면으로
MCP 앱이 반가운 만큼 조심스러운 이유가 여기 있어요. 그동안 서버는 글자만 보냈으니 그 글자를 믿을지 말지만 판단하면 됐는데, 이제는 화면을 보내요. 화면은 사람을 훨씬 쉽게 속이거든요.
규격도 이걸 알고 방어선을 여러 겹 깔아뒀어요. 서버가 보낸 화면은 격리된 상자 안에서만 돌고, 바깥의 파일이나 쿠키에 손댈 수 없어요. 어디로 통신할지도 미리 신고한 곳만 허용하고, 오가는 메시지는 전부 기록에 남고요. 설계는 꼼꼼한 편이에요.
그런데 격리가 막는 건 화면이 몰래 뭘 훔쳐가는 경우지, 화면이 사람을 속여 스스로 내주게 만드는 경우가 아니에요. 진짜 로그인 창처럼 생긴 화면을 띄워놓고 비밀번호를 받아 가면, 격리는 아무 일도 안 일어난 걸로 봐요. 사용자가 직접 입력해서 직접 보낸 거니까요.
이미 승인한 MCP 서버가 나중에 바뀐 사건
이 대목에서 실제로 벌어졌던 일을 하나 보고 가면 감이 잡혀요. 2025년 9월에 발견된 첫 악성 MCP 서버 사건이에요. 이메일 발송 서비스인 포스트마크의 공식 커넥터를 그대로 베껴서 같은 이름으로 올린 가짜였어요.
핵심은 수법이에요. 1.0.0부터 1.0.15까지 열다섯 개 버전을 진짜와 똑같이 멀쩡하게 굴렸어요. 쓰는 사람들은 잘 되니까 믿었고 설치도 늘었고요.
그러다 9월 17일에 올린 1.0.16 버전에 한 줄을 끼워 넣었어요. 이 도구로 나가는 모든 메일이 공격자 주소로 몰래 숨은 참조까지 함께 발송되도록요.
숨은 참조라 받는 사람도 보내는 사람도 몰라요. 통신 기록만 보면 정상적인 메일 발송이라 회사 보안 장비도 안 걸렀고요. 스나이크(Snyk)를 비롯한 보안 업체들이 잡아낼 때까지 주당 1,500회쯤 내려받아지고 있었어요.
여기서 남는 교훈은 검사 시점이에요. 우리는 보통 붙일 때 한 번 확인하고 그다음부턴 안 봐요. 그런데 커넥터는 설치하고 끝나는 물건이 아니라 계속 갱신되는 물건이라, 승인한 시점의 그것과 지금 도는 그것이 같다는 보장이 없어요. 이번 개정으로 서버가 할 수 있는 일이 넓어질수록 이 격차가 더 크게 벌어지고요.
MCP 붙여 쓰는 사람이 이번 주에 할 것
그래서 규격 문서를 읽을 일이 없는 입장에서 실제로 뭘 하면 되냐면, 세 가지면 충분하더라고요.
붙어 있는 커넥터 목록부터 세어보기
제일 먼저 할 건 목록 만들기예요. 시시해 보이는데 이게 제일 안 돼 있어요. 저도 제 작업 환경에 뭐가 붙어 있나 세어보니 열 개가 넘었고, 그중 몇 개는 언제 왜 붙였는지 기억이 안 났어요.
목록에 이름만 적지 말고 옆에 두 가지를 같이 적어보시길 권해요. 어디서 받은 건지, 그리고 읽기만 하는지 쓰기도 하는지요. 읽기만 필요한데 쓰기 권한까지 준 게 있으면 그게 제일 먼저 손볼 자리고요.
예약으로 조용히 도는 것부터 확인
목록이 나오면 순서를 정하는데, 사람이 눈으로 보면서 쓰는 것보다 예약으로 도는 것이 먼저예요. 사람이 쓰는 건 안 되면 그 자리에서 아니까요.
반대로 새벽에 알아서 돌아가는 파이프라인은 조용히 깨져도 한참 뒤에 알아요. 저도 자동화를 붙여 굴리면서 제일 무서운 게 이거였어요. 실패하면 알림이 오는 게 아니라 그냥 결과가 안 쌓이는 거라, 며칠 지나서야 이상하다 싶어 열어보게 되거든요. 8월 첫 주에 예약 건들을 한 번씩 손으로 돌려보시면 좋겠어요.
화면을 띄우는 커넥터엔 아무것도 입력하지 않기
마지막은 습관 하나예요. 앞으로 대화창 안에서 화면이 뜨는 일이 늘어날 텐데, 그 화면에는 비밀번호도 카드번호도 넣지 않는다고 정해두시면 돼요.
기준은 간단해요. 진짜 로그인 창은 쓰던 앱이나 브라우저가 띄우지, 대화 안에서 뜨지 않아요. 로그인이 필요하면 원래 사이트를 직접 열어서 하시고, 대화 안에서 뜬 화면이 자격 정보를 요구하면 그건 일단 닫는 게 맞아요. 격리가 막아주지 못하는 게 정확히 이 지점이라서요.
단단해진 MCP 규격, 늘어난 내 점검 몫
정리하면 이번 개정은 나쁜 소식이 아니에요. 운영이 훨씬 단순해졌고, 로그인과 권한 쪽은 오히려 업계 표준에 맞춰 여섯 갈래로 조여졌어요. 서버가 화면을 띄울 수 있게 된 것도 대체로 반가운 변화고요. 다만 몇몇 안전장치가 규격의 의무에서 만드는 쪽의 선택으로 내려왔고, 그만큼 고르는 사람의 눈이 하는 일이 늘었어요.
MCP는 이제 무시하기 어려운 크기가 됐어요. 공개된 서버가 만 개를 넘었다는 발표가 작년 말이었고, 세는 곳마다 기준이 달라 숫자는 벌어지지만 방향은 한쪽이에요. 붙일 곳이 늘어난다는 건 고를 일도 늘어난다는 뜻이더라고요.
혹시 오늘 딱 하나만 하신다면 목록 세기부터 해보시길 권해요. 저는 그 목록을 적고 나서야 안 쓰는 걸 세 개 뗐고, 읽기만 하면 되는데 쓰기까지 열려 있던 것도 하나 찾았어요. 다들 몇 개나 붙어 있는지, 저도 궁금하네요.
지금 쓰는 커넥터를 8월 전에 갈아치워야 하나요
그건 아니에요. 폐기된 기능들도 최소 1년은 그대로 돌아가고, 신구 버전이 서로 만나면 옛 방식으로 되돌아가는 장치가 양쪽에 다 있어요. 갈아치우기보다 한 번씩 돌려보면서 이상 없는지 확인하는 쪽이 맞고, 새로 붙이는 것만 새 규격을 지원하는지 보고 시작하시면 돼요.
MCP 앱은 꺼둘 수 있나요
서버가 화면을 띄우는 기능은 규격의 필수가 아니라 선택 확장이에요. 모든 커넥터가 화면을 띄우는 게 아니라, 그렇게 만든 커넥터만 띄운다는 뜻이고요. 다만 켜고 끄는 스위치가 어디에 있는지는 쓰는 프로그램마다 달라서, 쓰시는 도구의 설정에서 확인하셔야 해요.
개인이 혼자 쓰는데도 신경 써야 하나요
혼자 쓰는 쪽이 오히려 점검을 건너뛰기 쉬워요. 회사는 누가 뭘 붙였는지 관리하는 절차라도 있는데, 혼자 굴리면 붙였다 잊는 게 자연스럽거든요. 대신 규모가 작으니 목록 한 장이면 다 잡혀요.
댓글을 남겨주세요