상태 없는 MCP 2.0, 다시 실무의 선택지가 된 이유

배경: 열기가 식었던 MCP가 돌아왔다

MCP(Model Context Protocol)는 앤트로픽이 2024년 11월 공개한, LLM 기반 에이전트에 외부 도구를 노출하는 표준 방식이다. 2025년 내내 관심이 치솟았지만, 같은 앤트로픽이 내놓은 Skills가 부각되며 한동안 뒷전으로 밀렸다. 터미널과 curl에 접근할 수 있는 에이전트 하네스라면 MCP가 하던 일 대부분을 더 유연하게 처리할 수 있다는 인식이 퍼졌기 때문이다. 그런데 2026년 7월 28일자 명세, 이른바 'MCP 2.0'이 공개되면서 분위기가 다시 바뀌고 있다. 사이먼 윌리슨은 이를 MCP 출시 이후 가장 중요한 변화라고 평가하며, 개인적으로 식었던 관심이 되살아났다고 밝혔다.

무엇이 달라졌나: 세션에서 단일 요청으로

핵심은 '상태 없음(stateless)'이다. 기존의 상태 유지형 MCP(레거시 MCP)는 도구 하나를 호출하려면 HTTP 요청이 두 번 필요했다. 첫 요청으로 세션을 초기화해 Mcp-Session-Id를 발급받고, 두 번째 요청에서 실제로 도구를 호출하는 구조다. 새 명세는 이를 단일 HTTP 요청으로 압축했다. 클라이언트와 서버 양쪽 구현이 훨씬 단순해질 뿐 아니라, 확장 가능한 웹 애플리케이션에도 잘 맞는다. 서버가 세션 ID를 추적하려고 상태를 들고 있을 필요가 없고, 같은 세션을 같은 백엔드 장비로 라우팅해야 하는 부담도 사라지기 때문이다.

이 단순함은 곧바로 실물 결과로 이어졌다. 윌리슨은 한 주 동안 세 가지 도구를 직접 만들었다. 첫째는 mcp-explorer로, MCP 서버를 대화형으로 탐색하는 상태 없는 파이썬 CLI다. 설치 없이 uvx로 바로 실행할 수 있고, 서버가 제공하는 도구 목록과 입출력 JSON 스키마를 조회한다. 둘째는 datasette-mcp로, 임의의 Datasette 인스턴스에 /-/mcp 엔드포인트를 붙이는 플러그인이다. list_databases(), get_database_schema(database_name), execute_sql(database_name, sql) 세 가지 도구만 제공하며, execute_sql은 현재 읽기 전용이다. 셋째는 그의 LLM 도구를 위한 알파 단계 플러그인 llm-mcp-client로, 향후 LLM 코어에 직접 통합하는 방안도 검토 중이다.

datasette-mcp는 그가 네 번째로 시도한 끝에 비로소 공개할 만하다고 느낀 버전이라는 점이 눈길을 끈다. 상태 없는 명세 덕분에 구현 난도가 실제로 낮아졌다는 방증이다. 그는 자신의 블로그를 미러링한 Datasette 인스턴스에 이를 붙여 ChatGPT와 Claude에 연결했고, 한 질문에 Claude가 7개의 SQL 쿼리를 잇달아 실행해 답을 찾아냈다고 전한다.

왜 지금 다시 MCP인가: 통제 가능성

윌리슨이 MCP로 돌아온 이유는 단순한 편의성이 아니라 보안과 통제에 관한 판단이다. 에이전트에 셸 환경과 인터넷 접근 권한을 통째로 주는 방식은 위험이 크고, 그런 환경을 능숙하게 다루려면 강력한 모델이 필요하다. 반면 MCP 도구는 감사와 통제가 쉽고, 노트북에서 돌아가는 작은 모델도 어느 정도 다룰 수 있을 만큼 단순하다. 도구의 경계가 명확하니 에이전트가 무엇을 할 수 있고 무엇이 잘못될 수 있는지 추론하기가, 열린 네트워크에서의 임의 명령 실행보다 훨씬 수월하다는 것이다.

다만 MCP가 보안 만능은 아니다. 윌리슨은 MCP 공개 몇 달 뒤 프롬프트 인젝션 문제를 지적한 바 있다. 최종 사용자가 여러 도구를 뒤섞어 쓰는 구조는 데이터 유출 공격을 막을 책임을 사용자에게 떠넘기는데, 이는 그가 훗날 '치명적 삼요소(Lethal Trifecta)'라 이름 붙인 위험과 정확히 맞닿아 있다. 요컨대 MCP는 임의 셸 접근보다 위험 표면이 작고 다루기 쉬운 선택지이지, 위험이 사라진 안전지대는 아니다.

한국 실무자에게 주는 함의

정리하면, 상태 없는 MCP는 세션 관리라는 서버 측 복잡성을 걷어내 도구 서버를 일반적인 무상태 웹 서비스처럼 배포하고 확장할 수 있게 했다. 사내 데이터베이스나 내부 API를 에이전트에 연결하려는 팀이라면, 셸을 통째로 여는 대신 읽기 전용 SQL처럼 권한이 명확히 제한된 소수의 도구만 노출하는 접근이 감사와 운영 양면에서 유리하다. 다만 여러 도구를 조합할 때 생기는 유출 위험은 프로토콜이 대신 막아주지 않으므로, 어떤 도구를 함께 붙일지에 대한 판단은 여전히 도입하는 쪽의 몫으로 남는다.