안전한 LLM 통합을 위한 모델 컨텍스트 프로토콜 보안 구현법

새로운 프로토콜은 언제나 고유한 복잡성을 수반한다. 따라서 새로운 프로토콜이 등장하면 가장 먼저 던져야 할 질문은 “이것이 정말 필요한가?”이다. 여기서는 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)에 그 질문을 적용해 보자.

최근 챗GPT 같은 도구로 촉발된 에이전트형 앱의 물결은 LLM(Large Language Model)을 기반으로 한다. LLM은 요약, 콘텐츠 생성, 이미지 처리 같은 작업에 강점을 보이지만, 동시에 근본적인 한계를 지닌다. 대표적으로 다음과 같은 문제가 있다.

• - 실시간 데이터 접근 불가
• - 비공개 데이터 접근 불가
• - 외부 도구 실행 불가

MCP는 에이전틱 앱을 실제 데이터와 도구에 연결하는 범용 프로토콜 역할을 수행함으로써 위와 같은 한계를 해소한다. 하지만 여기서 의문이 생긴다. 이미 보안성과 성능을 갖춘 API가 존재하는데, 왜 굳이 새로운 프로토콜을 도입해야 할까?

오늘날의 강력한 API를 에이전틱 앱에 연결할 수는 있지만 문제가 하나 있다. API마다 방식이 제각각이라는 점이다. API는 REST, 그래프QL(GraphQL), gRPC 등 다양한 형태가 있으며, HTTP, 웹소켓(WebSockets), Pub/Sub 같은 프로토콜을 사용한다. 인증 방식도 API 키, OAuth2처럼 다르다. 결국 각 통합은 모두 개별 작업이 될 수밖에 없다. 개발자는 문서를 읽고, 플로우를 설계하고, API를 하나하나 연결해야 한다.

WSO2

정적 통합 모델은 오랫동안 효과가 확인된 방식이지만, 에이전틱 앱의 동적 특성과는 맞지 않는다. 바로 이 지점에서 MCP가 등장한다. MCP는 클라이언트–서버 역할, 표준 프로토콜 형식, 라이프사이클을 명확히 정의하며, 사실상 LLM과 외부 시스템을 잇는 범용 커넥터 역할을 한다. 쉽게 말해, MCP는 API 세계의 USB-C라고 볼 수 있다.

MCP의 동작 방식

MCP는 3가지 핵심 역할을 정의한다. 바로 호스트(Host), 클라이언트(Client), 그리고 서버(Server)다.

• - 호스트 : 클라이언트의 수명 주기를 관리하고 보안을 강제하는 에이전틱 애플리케이션
• - 클라이언트 : 호스트 내부의 경량 커넥터로, MCP 서버와 1:1 세션을 설정
• - 서버 : MCP 클라이언트를 데이터 소스와 도구에 연결하는 프로그램으로, 로컬 또는 원격에서 동작 가능

WSO2

각 역할은 고유한 기능 세트를 제공한다. MCP 서버는 리소스(예 : 캘린더 이벤트 같은 컨텍스트 데이터), 프롬프트(사용자 입력을 구조화해 LLM 출력 품질을 높이는 템플릿), 도구(실행 가능한 함수)를 제공한다. MCP 클라이언트는 MCP 서버에 연결해 데이터를 요청하고, 도구를 실행하며, 에이전트를 조율한다.

MCP는 요청과 응답을 위한 경량 구조화 프로토콜인 JSON-RPC를 사용한다. 또한 클라이언트–서버 간 통신을 위해 2가지 표준 전송 메커니즘을 정의한다. 바로 STDIO(standard input/output)와 스트리밍할 수 있는 HTTP다.

로컬 MCP 서버 보안

MCP 서버가 로컬에서 실행될 때는 STDIO 전송 방식을 사용하는 것이 권장된다. 실제로는 에이전틱 앱이 MCP 서버를 하위 프로세스로 실행하고, 표준 입출력 스트림을 통해 통신하는 방식이다. 이 통신은 전적으로 로컬 시스템 내부에서만 이뤄지므로 본질적으로 안전하며, MCP 인증 사양에서도 별도의 보안 조치를 요구하지 않는다.

WSO2

그러나 MCP 서버가 백엔드 API와 인터넷을 통해 통신할 때는 보안이 최우선 과제가 된다. 이는 MCP 인증 사양의 범위 밖에 해당한다. 그렇다고 해서 새로운 보안 메커니즘이 필요한 것은 아니다. 기존의 API 보안 프랙티스만으로 충분하다. 대표적인 접근 방식은 다음과 같다.

• - 장기 토큰 : 며칠에서 몇 달 동안 유효한 API 키나 토큰으로, 별도의 채널을 통해 발급받아 MCP 서버에 설정한다.
• - 단기 토큰 : 1시간 미만의 짧은 수명을 가지며, 수동으로 설정할 수 없다. 대신 MCP 서버가 실행 시점에 사용자 승인을 받아 동적으로 요청해야 한다. 대표적인 예로 OAuth2 액세스 토큰과 JWT(Json Web Token)가 있다.

원격 MCP 서버 보안

MCP 클라이언트는 원격 MCP 서버의 엔드포인트 URL에 요청을 보내 HTTP를 통해 연결한다. MCP 인증 사양에 따라 이 엔드포인트는 반드시 OAuth 2.1으로 보호돼야 하며, 클라이언트는 유효한 액세스 토큰을 제시해야 한다.

WSO2

MCP 인증 사양은 동적이고 에이전트 기반 통합을 지원하기 위해 설계된 토큰 획득 절차를 정의한다. 이 과정은 다음 단계로 이루어진다.

WSO2

서버 메타데이터 탐색

MCP 서버 URL이 구성 파라미터로 제공되면, 클라이언트는 해당 URL에서 경로(path) 요소를 제거하고 /well-known/oauth-authorization-server 경로를 덧붙여 서버 메타데이터 엔드포인트를 생성한다. 이후 클라이언트는 이 엔드포인트에서 JSON 형식의 서버 메타데이터 문서를 가져온다. 엔드포인트와 문서는 모두 OAuth 2.0 인증 서버 메타데이터(OAuth 2.0 Authorization Server Metadata) 사양을 준수해야 한다. 이 메타데이터는 클라이언트가 이후 단계에서 필요한 다음 정보를 확인하는 데 활용된다.

• - 등록 엔드포인트(Registration endpoint)
• - 인증 및 토큰 엔드포인트(Authorization and token endpoints)
• - 지원되는 그랜트 유형과 스코프(Grant types and scopes)

MCP 서버 URL에서 서버 메타데이터 엔드포인트를 파생하는 방식은 클라이언트가 단일 구성 파라미터로 동작할 수 있도록 설계된 것이었다. 그러나 이 접근 방식은 인증 서버와 리소스 서버의 역할을 강하게 결합시켜, 기존 OAuth 2.0 인프라와 목적별 아이덴티티 솔루션 활용을 제한하는 한계가 있다. 이를 해결하기 위해, 곧 공개될 MCP 인증 사양에서는 이 메커니즘을 OAuth 2.0 보호 자원 메타데이터(OAuth 2.0 Protected Resource Metadata) 사양으로 대체할 예정이다.

클라이언트 등록

클라이언트 애플리케이션은 서버 메타데이터 문서에서 가져온 정보를 바탕으로 클라이언트 등록 엔드포인트에 등록 요청을 보낸다. MCP 인증 사양은 클라이언트를 OAuth 2.1 클라이언트로 등록하기 위해 OAuth 2.0 동적 클라이언트 등록(Dynamic Client Registration, DCR) 프로토콜을 채택한다. DCR 응답에서 클라이언트 애플리케이션은 client_id를 받고, 비공개 클라이언트의 경우 client_secret도 함께 수신한다. 이 두 값은 다음 단계 수행에 필요하다.

DCR은 널리 채택된 방식이지만, 공개 등록(open registration)에 대해서는 의견이 분분하다. 사양 자체도 등록 엔드포인트를 OAuth 2.0으로 보호할 수 있도록 허용한다. 다만 단일 파라미터 구성을 지원하기 위해 MCP 인증 사양은 공개 등록을 권장한다. 향후 이 방식이 어떻게 발전할지는 지켜봐야 한다.

액세스 토큰 획득

이 단계에서 클라이언트는 액세스 토큰 요청에 필요한 모든 정보를 갖추게 된다. 이후 사용례에 따라 다음 중 하나의 OAuth 2.1 그랜트 유형을 사용한다.

• - 클라이언트 자격 증명 : 클라이언트 애플리케이션이 MCP 서버에 직접 접근할 경우, 클라이언트 자격 증명 그랜트(Client Credentials Grant)를 사용한다. 이때 등록 과정에서 발급받은 client_id와 client_secret, 그리고 서버 메타데이터에서 확인한 토큰 엔드포인트와 스코프를 함께 사용한다.
• - 인가 코드 : 클라이언트가 최종 사용자를 대신해 MCP 서버에 접근할 경우 인가 코드 그랜트(Authorization Code Grant)를 사용한다. 이 플로우에서는 등록 과정에서 발급받은 client_id와 client_secret, 그리고 서버 메타데이터에 포함된 인가 엔드포인트, 토큰 엔드포인트, 스코프가 필요하다. 또한 OAuth 2.1 규격에 따라 클라이언트는 PKCE(Proof Key for Code Exchange)를 반드시 사용해 보안을 강화해야 한다.

WSO2

모든 과정이 정상적으로 진행되면 클라이언트 애플리케이션은 유효한 액세스 토큰을 발급받게 된다. 이후 클라이언트는 이 토큰을 Authorization HTTP header에 포함해 MCP 서버 URL로 연결 요청을 보낸다. MCP 서버는 전달받은 토큰을 검증하고, 유효하다면 연결을 수립한다.

궁극적으로 이 보안 플로우는 MCP 서버 URL에서 서버 메타데이터 URL을 파생하는 초기 단계를 제외하면 전형적인 OAuth 기반 API 보안 플로우와 동일하다.

*Sagara Gunathunga는 오픈소스 기반의 API 및 통합 솔루션 업체 WSO2의 솔루션 아키텍처 디렉터다.

dl-itworldkorea@foundryco.com

No Author editor@itworld.co.kr
저작권자 Foundry & ITWorld, 무단 전재 및 재배포 금지