MCP 서버를 AI에 연결하기 전에는 다섯 가지를 확인하면 됩니다. 서버를 누가 운영하는지, 어떤 도구를 여는지, 어떤 자료가 서버로 나가는지, 권한이 어디까지인지, 보내거나 지우는 일에 사람의 승인이 남아 있는지입니다. MCP 규격 문서도 도구 호출에는 사람이 거부할 수 있는 자리가 있어야 한다고 권고합니다. 이 글은 공개 문서에서 확인한 내용과, 그 위에 DMS.Labs가 제안하는 점검 순서를 정리했습니다.
2026년 10월 23일 확인한 공개 자료 기준입니다. 읽은 자료는 MCP 공식 사이트의 소개 문서, 도구(Tools) 규격 문서, 보안 모범 사례 문서와 OpenAI의 MCP 연결 가이드입니다. 특정 현장이나 고객 사례가 아니며, 제가 MCP 서버를 직접 연결해 시험한 결과도 아닙니다. 뒤에 나오는 대조표는 이 자료를 읽고 만든 DMS.Labs의 제안이고 규격의 요구사항이 아닙니다.
창가 나무 책상 위에 열린 노트북과 인쇄한 목록, 연필, 찻잔이 놓인 장면원본 전체 보기
MCP는 무엇이고, 왜 연결 전에 확인해야 합니까?
MCP(Model Context Protocol)는 AI 앱을 외부 시스템에 연결하는 개방형 표준입니다. 공식 소개 문서는 Claude나 ChatGPT 같은 앱이 MCP로 파일과 데이터베이스 같은 자료원, 검색 엔진과 계산기 같은 도구, 특화된 프롬프트 같은 작업 흐름에 접근할 수 있다고 설명하고, AI 앱을 위한 USB-C 포트에 비유합니다. 표준이 있으면 연결은 쉬워집니다. 연결된 쪽이 믿을 만한지는 표준이 정해 주지 않습니다.
도구 규격 문서에는 이 점이 직접 적혀 있습니다. MCP의 도구는 언어 모델이 문맥에 맞춰 스스로 찾아 호출하도록 설계되었고, 그래서 신뢰와 안전을 위해 도구 호출을 사람이 거부할 수 있어야 한다고 권고합니다. 이 권고는 규격에서 'SHOULD'로 표기됩니다. 반드시 지켜야 하는 'MUST'가 아니라 권장입니다. 실제 앱이 승인 창을 어떻게 보여 주는지는 앱마다 다를 텐데, 저는 특정 앱의 화면을 확인하지 않았습니다.
서버를 누가 운영하는지 먼저 보는 이유는 무엇입니까?
모델이 서버로 보내는 내용은 그 서버의 운영자에게 가기 때문입니다. OpenAI 가이드는 신뢰할 수 있는 서버만 써야 한다고 강조하면서, 악의적인 서버는 모델의 문맥에 들어온 어떤 민감한 자료든 빼돌릴 수 있다고 경고합니다. 같은 문서는 서비스 제공자가 직접 운영하는 서버를 고르라고 권합니다. Stripe를 예로 들어 Stripe가 호스팅하는 mcp.stripe.com에 연결하고, 제3자가 호스팅하는 Stripe용 서버는 피하라고 합니다. 공식 서버가 아직 많지 않아 서비스를 중계해 주는 제3자 서버에 끌릴 수 있는데, 그럴 때는 그 업체가 자료를 어떻게 쓰는지 꼼꼼히 살펴야 한다고 덧붙입니다.
내 컴퓨터에서 돌리는 로컬 서버라면 확인할 것이 하나 더 있습니다. 보안 모범 사례 문서에 따르면 로컬 서버는 사용자의 컴퓨터에서 내려받아 실행하는 프로그램이고 클라이언트와 같은 권한으로 돌아갑니다. 설정에 악의적인 시작 명령이 들어 있으면 임의의 명령이 실행될 수 있습니다. 그래서 문서는 원클릭으로 로컬 서버를 설정해 주는 클라이언트가 실행할 명령을 잘라내지 않고 그대로 보여 주고 사용자의 명시적인 승인을 받아야 한다고 요구합니다. 이 요구는 클라이언트를 만드는 쪽을 향한 것입니다. 쓰는 사람이 할 수 있는 일은 설정에 적힌 시작 명령을 직접 읽어 보는 것입니다. 읽어도 무슨 명령인지 모르겠다면 저는 연결하지 않겠습니다.
도구 목록은 어떻게 읽습니까?
이름보다 그 도구가 무엇을 바꾸는지를 읽습니다. 연결하면 서버가 도구 목록을 내려 주고, 모델은 그 안에서 호출할 도구를 고릅니다. 예를 들어 일정 조회와 일정 삭제가 같은 캘린더 서버에 들어 있다면 모델에게는 둘 다 호출할 수 있는 도구입니다.
규격은 클라이언트가 도구의 주석(annotations, 도구의 동작을 설명하는 선택 항목)을 신뢰할 수 없는 정보로 다루어야 한다고 정해 둡니다. 신뢰하는 서버가 준 것이 아니라면 서버가 읽기 전용이라고 적어 두었더라도 그대로 믿지 않는다는 뜻입니다.
서버의 도구 목록은 시간이 지나며 바뀔 수 있고, 바뀌면 알림을 보내는 기능(listChanged)도 규격에 있습니다. OpenAI 가이드도 MCP 서버가 도구의 동작을 예고 없이 바꿀 수 있다고 경고합니다. 처음 확인한 목록이 계속 같을 것이라고 가정하면 안 됩니다.
서버에 도구가 수십 개 있으면 비용과 지연이 커질 수 있다는 것이 OpenAI 가이드의 설명이고, 필요한 도구만 가져오는 allowed_tools 설정을 쓰라고 안내합니다. 이 설정은 OpenAI Responses API의 항목이라 앱마다 같은 기능이 있지는 않겠지만, 필요한 도구만 열어 둔다는 생각은 어느 앱에나 적용됩니다.
내 자료는 어디까지 서버로 나갑니까?
모델의 문맥에 들어간 것은 모두 후보입니다. 규격은 클라이언트가 도구를 호출하기 전에 서버로 가는 입력을 사용자에게 보여 주어 악의적이거나 실수로 인한 자료 유출을 막아야 한다고 권고합니다. OpenAI 가이드는 기본 설정에서 자료를 커넥터나 원격 MCP 서버와 공유하기 전에 승인을 요청한다고 설명하고, 승인하기 전에 요청된 도구와 인자를 확인하라고 안내합니다. 승인 하나는 도구 호출 한 건에만 적용됩니다.
제가 제안하는 기준은 단순합니다. 처음 연결하는 서버에는 공개해도 되는 자료만 문맥에 넣습니다. 문맥에는 내가 붙여 넣은 글뿐 아니라 앞선 도구가 돌려준 결과도 들어갑니다. 예를 들어 고객 연락처가 오간 대화에 새 서버를 붙이면 그 연락처가 서버로 갈 길이 열립니다. OpenAI 가이드가 경고한 것이 이런 경우입니다. 무엇을 넣어도 되는지 판단이 어려우면 새 대화를 열고 필요한 자료만 넣어 시작합니다.
권한은 어디서 시작합니까?
읽기만 되는 권한에서 시작합니다. 보안 모범 사례 문서의 범위 최소화(scope minimization) 항목은 처음에는 탐색과 읽기 같은 위험이 낮은 작업만 담은 최소 범위로 시작하고, 높은 권한이 필요한 작업을 처음 시도할 때 단계적으로 올리라고 권합니다. 같은 항목은 흔한 실수로 서버가 지원하는 모든 범위를 한꺼번에 공개하는 것과 *, all, full-access 같은 포괄 범위를 쓰는 것을 꼽습니다. 토큰이 새어 나갔을 때 피해 범위가 넓어지고 폐기하기도 어려워지기 때문입니다. 이 문서는 서버를 설계하는 쪽을 향하지만 연결 화면에서 권한을 요구받는 사용자에게도 기준이 됩니다. 읽기 범위만 요청하는 연결과 포괄 범위를 요청하는 연결 중에서 고를 수 있다면 앞의 것을 먼저 씁니다.
승인 창이 번거로우면 꺼도 됩니까?
끌 수 있는 서버와 끄면 안 되는 서버가 따로 있다는 것이 제 판단입니다. OpenAI 가이드는 서버를 신뢰하게 되면 승인을 생략해 지연을 줄일 수 있다고 하고, 승인 생략을 도구별로 지정하는 방법도 보여 줍니다. 가이드의 첫 예시는 OpenAI 문서를 검색하는 공개 서버로, 읽기 전용 도구만 제공하고 인증이 필요 없어서 승인을 건너뜁니다. 예시 설명은 민감한 자료를 다룰 때는 승인을 쓰라고 덧붙입니다. 같은 가이드는 민감한 작업에는 항상 승인을 요구하라고도 합니다.
제안하는 구분은 이렇습니다. 공개 자료를 읽기만 하는 도구는 승인 생략을 검토할 수 있습니다. 메일 발송, 파일 삭제, 결제, 외부 게시처럼 한번 나가면 되돌리기 어려운 도구는 승인을 남깁니다. 승인 창이 매번 뜨면 사람이 내용을 읽지 않고 누르게 된다는 반론이 있을 수 있습니다. 맞을 수 있는 말이지만 제가 확인한 자료에는 그 빈도를 잰 값이 없습니다. 그래서 승인을 없애기보다 승인이 필요한 도구의 수를 줄이는 쪽으로 풀겠습니다. 규격은 클라이언트가 도구 사용 기록을 남기라는 권고도 담고 있습니다. 승인을 생략하는 도구일수록 기록은 더 챙겨야 합니다.
연결 전에 무엇을 대조합니까?
다섯 가지를 순서대로 대조합니다.
자물쇠가 걸린 작은 나무 상자와 펼친 노트, 닫힌 노트북이 놓인 책상원본 전체 보기
표가 넓으면 좌우로 스크롤하여 확인하세요.
| 순서 | 확인할 것 | 확인하는 곳 | 답이 없을 때 |
|---|---|---|---|
| 1 | 서버 운영자 | 서비스 제공자의 공식 안내, 서버 주소 | 중계 업체의 자료 사용 방침을 읽고, 그것도 없으면 연결하지 않습니다 |
| 2 | 도구 목록 | 연결 화면, 서버 문서 | 바꾸거나 지우는 도구는 닫아 둡니다 |
| 3 | 나가는 자료 | 대화에 들어 있는 자료, 승인 창의 입력값 | 공개해도 되는 자료만 넣은 새 대화에서 시작합니다 |
| 4 | 권한 범위 | 연결 화면의 권한 요청 | 읽기 범위만 요청하는 방식을 먼저 씁니다 |
| 5 | 승인과 기록 | 앱의 승인 설정, 사용 기록 | 보내기, 삭제, 결제 도구는 승인을 남기고, 기록을 볼 방법이 없으면 쓰기 도구는 열지 않습니다 |
1번 칸은 설정을 건드리기 전에 확인할 수 있습니다. 서버가 누구 것인지 모르면 나머지 칸을 채워도 근거가 없으니, 저는 1번 칸에서 멈추겠습니다. 다섯 칸을 모두 통과한 뒤에도 규격은 도구 목록이 바뀔 수 있다고 하고 OpenAI 가이드는 서버로 보낸 자료를 로그로 남겨 정기적으로 살펴보라고 권합니다. 연결한 날 한 번 확인하고 끝내지 말고 목록과 기록을 가끔 다시 열어 봅니다.
직원 다섯 명의 사무실이 공유 캘린더를 붙인다면 어떻게 됩니까?
가정해 보겠습니다. 직원이 다섯 명인 사무실이 공유 캘린더와 연결되는 MCP 서버를 AI에 붙이려 합니다. 가상의 상황이며 실제 고객이나 현장 사례가 아닙니다. 위 표의 순서를 적용하면 이렇게 됩니다.
먼저 캘린더 서비스를 운영하는 회사가 직접 제공하는 서버가 있는지 찾습니다. 없으면 중계 서버의 자료 사용 방침을 읽습니다. 서버의 도구 목록이 일정 조회, 일정 생성, 일정 삭제로 나뉘어 있다면 처음에는 조회만 허용합니다. 처음 연결하는 날에는 대외비 일정이 없는 새 대화에서 시작하고, 연결 화면이 읽기 범위만 요청하는지 봅니다. 생성과 삭제는 승인을 남겨 둡니다. 일주일쯤 쓴 뒤 도구 목록이 바뀌지 않았는지 대조하고, 사용 기록을 읽어 본 다음에 쓰기 도구를 열지 정합니다. 이 과정은 제안하는 순서이고 실제로 해 본 결과가 아닙니다.
다음에 볼 것
AI 자동화를 업무에 붙이는 방법은 DMS.Labs 업무 자동화 페이지에서 볼 수 있습니다. 권한을 몇 단계로 나눠 주는 방법은 AI 자동화, 권한을 세 단계로 나눠 주기에, 자율성 수준별로 운영자와 맺을 약속은 자동화는 권한이 아니라 계약이다: 자율성 레이어별 운영자 계약서에 정리했습니다.
참고한 자료
2026년 10월 23일에 확인했습니다. 도구 규격 문서는 확인 시점에 2026-07-28 판의 하위 문서를 가리키고 있었으며, 판이 바뀌면 표현이 달라질 수 있습니다. 이 글의 사진 두 장은 AI로 만든 예시 이미지이며 실제 현장 기록이 아닙니다.
