MCP 서버를 고객 서비스에 열 때: OAuth 인증과 비용 구조

고객사 웹서비스에 AI 기능을 붙이자는 이야기가 나오면 요즘은 "MCP 서버부터 만들자"는 말이 같이 나옵니다. 그런데 구조를 그려 보면, 우리 서비스 안에서 우리 챗봇이 우리 API 키로 모델을 부르는 경우에는 MCP 서버가 할 일이 없습니다.

흔한 오해, AI 기능에는 MCP 서버가 필요하다는 생각

MCP를 "AI가 도구를 쓰게 해 주는 기술"로 이해하면 AI 기능마다 MCP 서버가 있어야 할 것처럼 보입니다. 그러나 도구 호출은 모델 API가 이미 제공합니다. 서버 안의 함수를 도구 정의로 적어 모델에 넘기고, 모델이 고른 도구를 서버가 실행해 결과를 돌려주면 끝입니다. 이 사이에 MCP 서버를 끼우면 같은 함수를 부르는 길에 서버가 하나 늘 뿐입니다.

MCP는 도구를 부르는 기술이라기보다 남의 AI 앱이 우리 도구를 찾아 쓰게 하는 약속에 가깝습니다. Claude 같은 외부 앱은 우리 코드를 모릅니다. 그러니 도구 목록을 묻고 부르는 방법이 표준으로 정해져 있어야 하고, 그 표준이 MCP입니다.

MCP가 값을 하는 두 경우

첫째는 고객이 자기 AI 앱에서 우리 서비스를 쓰고 싶어 할 때입니다. 고객사 직원이 평소 쓰는 Claude 대화창에서 "이번 주 들어온 문의 보여줘"라고 하면 우리 서비스의 데이터가 나오는 그림입니다.

둘째는 같은 도구를 여러 곳에서 다시 쓸 때입니다. 우리 챗봇, 고객의 AI 앱, 사내 도구가 도구 서버 하나를 같이 보면 도구를 고칠 곳도 하나가 됩니다.

저라면 순서를 이렇게 잡겠습니다. 처음에는 서비스 안 챗봇에 도구를 직접 연결합니다. 고객이 자기 AI에서 쓰고 싶다는 요구가 실제로 나오면 그때 같은 도구를 MCP로 감싸서 엽니다. 처음부터 도구를 API 단위가 아니라 사용자가 하는 일 단위로 나눠 두면, 나중에 감싸는 작업은 얇은 포장에 그칩니다.

고객 구독이 토큰 비용을 내는 구조

MCP 서버는 도구만 내놓고 모델은 돌리지 않습니다. 모델은 사용자의 AI 앱이 돌립니다. 그래서 고객이 자기 구독으로 연결하면 우리 쪽에는 토큰 비용이 생기지 않습니다.

대신 내주는 것도 분명합니다. 모델이 도구를 언제 어떻게 부를지 우리가 정할 수 없고, 사용량 한도도 고객 구독을 따릅니다. 외부 MCP 연결이 되는 요금제인지도 고객 쪽 사정입니다. 조건이 제공사마다 다르고 자주 바뀌므로, 도입 전에 고객이 쓰는 서비스의 현재 조건을 확인해야 합니다.

	우리 API 키 (서비스 안 챗봇)	고객 구독 (MCP)
토큰 비용	우리가 냄	고객 구독에 포함
모델과 프롬프트	우리가 정함	고객 앱이 정함
데이터에 적용되는 약관	우리와 AI 회사의 계약	고객 계정의 약관
사용량 한도	우리 계약 기준	고객 구독 기준

어느 쪽이든 AI 회사로 넘어가는 데이터

고객 구독으로 돌리면 데이터가 우리 손을 떠나지 않는다고 생각하기 쉽습니다. 그렇지 않습니다. 도구가 돌려준 결과는 모델이 읽어야 하니, 어느 방식이든 질문과 데이터는 AI 회사 서버로 갑니다. 달라지는 것은 적용되는 약관입니다. API 키 방식은 우리가 AI 회사와 직접 계약하므로 보관 기간이나 위탁 관계를 따지기 쉽습니다. 고객 구독 방식은 고객이 맺은 계약이 적용되고, 우리는 그 설정을 알 수도 바꿀 수도 없습니다.

그래서 가장 확실한 대책은 넘기는 양을 줄이는 것입니다. 주민등록번호나 연락처처럼 답에 필요 없는 항목은 도구가 아예 돌려주지 않게 만듭니다. 고객 구독 방식을 쓴다면 이 데이터 흐름을 계약서와 개인정보 처리방침에 적어 두는 것이 좋습니다. 국외 이전 고지가 필요한지, 위탁인지 제3자 제공인지는 구조마다 판단이 갈리므로 법률 검토를 받아야 하는 부분입니다.

기존 로그인과 OTP를 그대로 쓰는 OAuth 흐름

원격 MCP 서버의 인증은 OAuth입니다. MCP 인증 명세(2026-07-28판)는 OAuth 2.1을 바탕으로 MCP 서버를 리소스 서버로, AI 앱을 클라이언트로 둡니다. 인증 자체는 선택 사항이지만 HTTP로 여는 서버가 인증을 한다면 이 명세를 따르라고 합니다. 로컬에서 stdio로 도는 서버는 대상이 아니고, 자격 증명을 환경 변수로 받습니다.

흐름은 이렇습니다. AI 앱이 처음 연결하면 우리 로그인 화면이 뜹니다. 사용자가 평소처럼 비밀번호와 OTP를 통과하면 서버가 토큰을 발급하고, 이후 호출은 그 토큰으로만 합니다. 이미 있는 로그인과 OTP는 그대로 쓰고, 새로 만들 것은 토큰을 발급하는 인증 서버 부분입니다. 명세는 이 인증 서버를 MCP 서버와 같이 두든 따로 두든 상관하지 않습니다.

토큰이 없거나 만료된 요청에는 401로 답하고 인증 정보가 어디 있는지 알려 줍니다. 명세의 예시는 이렇습니다.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

명세가 MUST로 못 박은 네 가지

직접 구현하면 놓치기 쉬운 것이 이 부분입니다. 명세에서 반드시(MUST)로 적힌 것만 추리면 넷입니다.

첫째, 서버는 RFC 9728 보호 리소스 메타데이터를 내놓아야 합니다. AI 앱은 여기서 어느 인증 서버로 가야 하는지 찾습니다. 둘째, 클라이언트는 PKCE를 써야 하고 가능하면 S256 방식을 씁니다. 인증 서버 메타데이터에 PKCE 지원 표시가 없으면 클라이언트는 진행을 거부하게 되어 있으니, 직접 만든 인증 서버라면 이 표시를 빠뜨리면 안 됩니다.

셋째, 토큰의 대상(audience)을 묶습니다. 클라이언트는 인가 요청과 토큰 요청 모두에 RFC 8707의 resource 값으로 MCP 서버 주소를 보내고, 서버는 자기 앞으로 발급되지 않은 토큰을 거절해야 합니다. 넷째, 받은 토큰을 뒤쪽 API로 그대로 넘기면 안 됩니다. MCP 서버가 다른 API를 불러야 한다면 그 API용 토큰을 따로 받아야 한다고 명세가 분명히 적어 두었습니다.

클라이언트 등록 방식은 판마다 바뀌었습니다. 2025-06-18판에서 권장이던 동적 클라이언트 등록(RFC 7591)은 2026-07-28판에서 하위 호환용으로만 남았고, Client ID Metadata Documents가 권장으로 올라왔습니다. 예제 코드나 글을 참고할 때 어느 판을 기준으로 쓰였는지부터 봐야 하는 이유입니다.

민감한 도구 앞의 두 번째 OTP

OTP를 호출마다 받으면 AI 앱으로는 쓸 수가 없습니다. 연결할 때 한 번 받고, 대신 토큰 유효 시간을 짧게 잡는 것이 현실적입니다.

수정이나 삭제처럼 되돌리기 어려운 도구는 다르게 봅니다. 저는 이런 도구에 한해 실행 직전에 OTP를 한 번 더 받는 쪽을 권합니다. 명세에도 이걸 얹을 틈이 있습니다. 토큰의 권한 범위(scope)가 모자라면 서버는 403과 error="insufficient_scope"로 필요한 scope를 알려 주게 되어 있습니다. 쓰기 도구를 별도 scope로 나누고, 그 scope를 받는 단계에서 OTP를 다시 요구하면 됩니다. 다만 AI 앱마다 이 403을 받아 재인증 화면을 띄우는 동작이 같다고는 장담하지 못합니다. 쓰려는 앱에서 직접 시험해 봐야 하는 부분입니다.

나머지는 일반적인 API 보안과 같습니다. 토큰에는 사용자와 권한 범위를 담고, 서버는 도구 호출마다 그 사용자가 그 데이터에 접근할 수 있는지 다시 확인합니다. 연결을 해제하거나 계정을 정지하면 토큰이 바로 무효가 되어야 하고, 호출 기록에는 사용자 번호를 남깁니다.

도구 설명 한 줄에 달린 서비스 품질

AI는 도구 이름과 설명만 보고 무엇을 부를지 정합니다. MCP 서버에서는 도구 설계가 곧 서비스 품질입니다.

API 하나를 도구 하나로 옮기면 비슷한 도구가 수십 개 생기고, 모델은 그 사이에서 자주 헷갈립니다. "문의 목록 조회"처럼 사용자가 하는 일 단위로 묶는 편이 낫습니다. 설명에는 언제 쓰는지와 함께 언제 쓰지 말아야 하는지를 적습니다. 모델에게는 그 문장이 사용 설명서입니다.

돌려주는 데이터도 필요한 칸만 고릅니다. 레코드 전체를 주면 앞에서 말한 개인정보가 따라가고, 고객이 남긴 문의 내용에 숨은 지시문까지 모델이 그대로 읽습니다. 관리자용 도구와 일반 사용자용 도구는 같은 서버에 섞지 않습니다. 권한 설계를 더 깊이 다룬 글로는 MCP 데이터베이스 서버: 에이전트에 DB를 열어 줄 때의 권한 설계가 있습니다.

처음 열 때의 범위

처음에는 조회 도구만 엽니다. 고객사 한 곳에서 조회 도구 몇 개와 사용자별 로그인, 호출 기록만 넣고 시작하는 정도가 적당합니다. 쓰기 도구는 사용자 확인 절차를 붙인 뒤에 엽니다. 호출 횟수 제한과 기록은 나중에 붙이기보다 처음부터 넣는 편이 쌉니다.

범위는 서면으로 남깁니다. 어떤 도구를 여는지, 조회만 하는지, 누가 쓰는지를 한 장으로 합의하고, 도구를 더하거나 AI 회사나 모델을 바꿀 때 어떻게 알릴지도 정해 둡니다. 저는 고객이 모르는 사이 데이터 흐름이 바뀌는 것이 이 구조에서 다툼이 가장 생기기 쉬운 곳이라고 봅니다. 책임 범위와 면책 조항의 문구는 변호사 확인을 받아야 합니다.