기존 MCP 서버 고르는 법

2026-09-15Views 9약 9분생성형 AI 활용

Summary

서버를 고르는 일은 앱 설치보다 권한 승인에 가깝다

MCP 서버를 설치하는 일은 단순히 새 프로그램을 까는 일이 아니다. AI에게 "이 문서를 읽어도 된다", "이 브라우저를 조작해도 된다", "이 데이터베이스에 질의해도 된다"는 통로를 열어 주는 일이다. 그래서 MCP 서버를 고를 때는 기능보다 먼저 권한을 봐야 한다.

좋은 MCP 서버는 두 가지를 분명히 말한다.

첫째, 무엇을 할 수 있는가. 파일을 읽는지, 브라우저를 조작하는지, 이슈를 생성하는지, 데이터베이스에 질의하는지 명확해야 한다.

둘째, 무엇을 요구하는가. 로컬 파일 접근, API 토큰, OAuth 권한, 네트워크 접근, 셸 실행 권한 같은 요구 사항이 README에 드러나야 한다.

앞 장에서 MCP 서버를 설정 파일에 추가하는 법을 봤다. 이제는 그 전에 해야 할 일을 다룬다. 바로 "이 서버를 내 환경에 들여도 되는가"를 판단하는 일이다.

기존 MCP 서버 고르는 법 AI 생성 이미지

세 종류의 서버를 구분하라

공개 MCP 서버는 대체로 세 부류로 나눌 수 있다.

첫째는 공식 또는 공식에 가까운 서버다. MCP 프로젝트 조직, 공식 레지스트리, 주요 호스트의 문서에서 안내되는 서버가 여기에 들어간다. 공식 MCP Registry는 서버 이름, 버전, 상태를 조회할 수 있는 API를 제공하며, 서버 상태도 active, deprecated, deleted처럼 구분할 수 있다¹. 이런 서버는 발견성과 메타데이터 측면에서 유리하다. 다만 "레지스트리에 있다"는 말이 "내 회사 PC에서 안전하다"는 뜻은 아니다. 레지스트리는 서버 정보를 찾고 배포 상태를 확인하는 장소이지, 모든 실행 권한을 대신 심사해 주는 보안 승인 시스템이 아니다.

둘째는 벤더 제공 서버다. 특정 서비스 회사가 자기 제품과 연결하기 위해 제공하는 서버다. 예를 들어 협업 도구, 개발 플랫폼, 클라우드 서비스, 데이터베이스 회사가 직접 배포하는 MCP 서버가 여기에 해당한다. 장점은 API 변경에 맞춰 유지보수될 가능성이 높고, 인증 방식이 비교적 명확하다는 점이다. 단점은 요구 권한이 넓을 수 있다는 점이다. "이슈 읽기"만 필요한데 "조직 전체 저장소 쓰기" 권한을 요구한다면 다시 생각해야 한다.

셋째는 커뮤니티 서버다. 개인 개발자나 작은 팀이 만든 서버다. 가장 빠르게 새로운 기능이 나오고, 특정 틈새 업무를 잘 해결하는 경우가 많다. 대신 유지보수 중단, 패키지 이름 혼동, 권한 과다 요청, 문서 부족의 위험이 크다. 커뮤니티 서버를 무조건 피할 필요는 없다. 다만 업무용 계정과 회사 데이터에 연결하기 전에는 더 엄격하게 봐야 한다.

간단히 정리하면 이렇다.

구분	장점	주의할 점
공식·공식 레지스트리 기반	발견하기 쉽고 메타데이터 확인 가능	등록 여부가 안전 보증은 아님
벤더 제공	서비스 API와 인증 변화에 대응 가능성 높음	OAuth 범위와 데이터 사용 정책 확인 필요
커뮤니티	기능이 빠르고 다양함	유지보수, 보안, 권한 과다 요청 확인 필요

README에서 먼저 볼 것

README는 서버의 자기소개서다. 설치 명령보다 먼저 다음 항목을 찾아야 한다.

1. 지원 기능

서버가 제공하는 기능이 Tools, Resources, Prompts 중 어디에 가까운지 확인한다. 다만 실제 서버는 이 셋을 섞어서 제공하는 경우가 많다. 문서 검색처럼 보기에는 Resources에 가까운 기능도 search_docs 같은 Tool로 노출될 수 있다. 그래서 분류 이름만 보지 말고, 실제로 어떤 이름의 도구와 리소스가 열리는지까지 확인해야 한다.

문서, 파일, 로그를 읽기만 한다면 주로 Resources 또는 읽기 전용 Tools 성격이다.
이슈 생성, 메시지 발송, 파일 수정, DB 변경을 한다면 Tools 성격이 강하다.
반복 업무 양식이나 정해진 지시문 템플릿을 제공한다면 Prompts가 포함될 수 있다.

README에 "무엇을 할 수 있다"만 있고 "어떤 도구 이름으로 노출된다"가 없다면 한 단계 더 조심해야 한다. 좋은 서버는 보통 사용 가능한 도구 목록, 입력값 예시, 실행 결과 예시를 제공한다.

예를 들어 다음처럼 설명되어 있으면 판단하기 쉽다.

Tools:
- search_docs(query, limit): 문서 검색
- create_issue(title, body, labels): 이슈 생성

Resources:
- docs://team-handbook
- docs://api-reference

반대로 "AI가 당신의 업무 도구를 완전히 자동화합니다" 같은 문장만 있고 실제 도구 목록이 없다면 설치를 미루는 편이 낫다.

2. 요구 권한

설치 명령보다 중요한 것은 권한이다. README에서 다음 표현을 찾는다.

어떤 환경변수가 필요한가: API_KEY, GITHUB_TOKEN, DATABASE_URL 등
토큰에 어떤 스코프가 필요한가: 읽기 전용인지, 쓰기 권한인지, 관리자 권한인지
로컬 파일 접근 범위를 제한할 수 있는가
네트워크 요청을 어디로 보내는가
브라우저나 셸을 제어하는가

특히 shell, exec, browser, filesystem, database, cloud, admin 같은 단어가 보이면 멈춰서 읽어야 한다. 이 단어들은 강력한 기능을 뜻한다. 강력한 기능은 곧 큰 피해 가능성을 뜻한다.

3. 실행 방식

MCP 서버는 여러 방식으로 실행된다.

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"],
      "env": {
        "API_KEY": "..."
      }
    }
  }
}

이런 로컬 실행 방식은 편하지만, 내 PC에서 패키지가 직접 실행된다는 뜻이다. npx, uvx, pipx, docker, 로컬 바이너리 중 무엇을 쓰는지 확인해야 한다. 패키지 매니저를 통해 즉석 실행하는 방식은 빠르지만, 결국 내 계정 권한으로 코드가 실행된다는 점을 잊으면 안 된다.

원격 서버라면 관점이 달라진다. 호스트마다 설정 문법은 다르지만, 대체로 로컬 명령 대신 서버 URL과 인증 정보를 넣는 식이다.

{
  "mcpServers": {
    "example-remote": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ..."
      }
    }
  }
}

원격 방식은 로컬 설치 부담이 적지만, 내 요청과 일부 맥락이 외부 서버로 나갈 수 있다. 업무 문서, 고객 정보, 코드 조각이 포함될 가능성이 있다면 서비스 약관과 데이터 처리 방식을 확인해야 한다. 로컬 서버는 "내 PC에서 무엇을 실행하는가"가 핵심이고, 원격 서버는 "내 데이터가 어디로 가는가"가 핵심이다.

4. 유지보수 상태

README 상단이 화려해도 저장소가 방치되어 있으면 위험하다. MCP와 호스트 앱은 빠르게 바뀐다. 오래된 서버는 연결 방식, 인증 방식, 도구 스키마가 현재 호스트와 맞지 않을 수 있다.

다음 순서로 본다.

최근 커밋이 언제인가
최근 릴리스가 있는가
열린 이슈에 답변이 달리는가
설치 실패 이슈가 반복되고 있지 않은가
보안 관련 이슈를 방치하고 있지 않은가
테스트, CI, 타입 검사 같은 기본 장치가 있는가

GitHub 스타 수는 참고 신호일 뿐이다. 스타가 많아도 1년째 릴리스가 없고 이슈가 쌓여 있으면 업무용으로는 불안하다. 반대로 스타가 적어도 최근 커밋이 꾸준하고, 이슈 응답이 빠르고, 문서가 정확하면 실무에 더 적합할 수 있다.

메타데이터가 있는 서버가 더 검토하기 쉽다

공식 레지스트리나 패키지 레지스트리에 잘 등록된 서버는 검토가 쉽다. 서버 이름, 버전, 설명, 저장소 URL, 패키지 정보가 분리되어 있으면 "무엇을 설치하는지" 추적할 수 있기 때문이다.

여기서 중요한 점은 레지스트리가 보통 서버 코드 자체를 담는 곳이 아니라는 사실이다. 공식 MCP Registry는 서버의 이름, 버전, 패키지 위치, 실행 방식 같은 메타데이터를 제공하고, 실제 코드는 npm, PyPI, NuGet, Docker Hub, GitHub Releases 같은 패키지 배포처에서 내려받는 구조에 가깝다. 그래서 레지스트리 정보와 실제 패키지 정보가 서로 맞는지 함께 봐야 한다.

Microsoft의 MCP Registry 게시 가이드는 .mcp/server.json 같은 매니페스트에 서버 이름, 버전, 설명, 패키지, 전송 방식, 저장소 정보를 명시하는 흐름을 설명한다². 이 내용은 게시자를 위한 문서지만, 사용자에게도 좋은 평가 기준이 된다. 잘 관리되는 서버라면 다음 정보가 어딘가에 드러나야 한다.

서버의 고유 이름
현재 버전
간단하고 구체적인 설명
저장소 URL
패키지 배포 위치
실행 방식: stdio인지 원격 HTTP인지
필요한 환경변수
문서 또는 웹사이트 링크

이 정보가 흩어져 있거나 서로 다르면 조심해야 한다. README에는 example-server라고 되어 있는데 패키지 이름은 전혀 다르고, 저장소 링크도 없고, 누가 관리하는지 알 수 없다면 검토 비용이 커진다.

권한의 민감도는 서버 종류마다 다르다

MCP 서버의 위험은 "AI가 똑똑한가"보다 "서버가 어디까지 접근하는가"에 더 좌우된다.

파일 시스템 서버

파일 시스템 서버는 로컬 파일을 읽거나 쓸 수 있다. 가장 유용하면서도 가장 쉽게 위험해진다. 프로젝트 폴더만 읽게 하면 개발 보조 도구가 되지만, 홈 디렉터리 전체를 열면 SSH 키, 브라우저 설정, 개인 문서, 회사 자료까지 노출될 수 있다.

업무용으로는 반드시 접근 경로를 제한한다.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "some-filesystem-server", "/Users/me/work/project-a"]
    }
  }
}

좋은 기준은 간단하다. "이 서버가 읽어도 되는 폴더만 넘긴다." 전체 디스크 접근은 피한다.

브라우저 서버

브라우저 자동화 서버는 웹사이트를 열고 버튼을 누르고 폼을 제출할 수 있다. 테스트 자동화, 리서치, 반복 입력에는 유용하다. 하지만 로그인된 브라우저를 조작할 수 있다면 이야기가 달라진다. 결제, 관리자 콘솔, 사내 시스템에서 의도하지 않은 클릭이 일어날 수 있다.

브라우저 서버는 가능하면 별도 프로필이나 테스트 계정으로 실행한다. 중요한 계정이 로그인된 브라우저를 그대로 연결하지 않는다.

데이터베이스 서버

DB 서버는 읽기 전용이어도 민감하다. 고객 정보, 매출, 로그, 내부 운영 데이터가 들어 있을 수 있기 때문이다. 쓰기 권한까지 있으면 더 위험하다. 잘못된 도구 호출 하나가 데이터를 수정하거나 삭제할 수 있다.

처음에는 읽기 전용 계정을 만든다. 가능하면 특정 스키마, 특정 테이블, 특정 뷰만 접근하게 한다. 운영 DB에 직접 붙이는 것은 마지막 선택이어야 한다.

클라우드 계정 서버

클라우드 서버는 권한 범위가 넓어지기 쉽다. 파일 저장소, 메일, 캘린더, 이슈, 배포 환경, 로그, 비밀값 관리 도구까지 이어질 수 있다. OAuth 승인 화면에서 "읽기"와 "쓰기"를 구분하고, 조직 관리자 권한을 요구하는지 확인해야 한다.

토큰은 개인 계정보다 용도별 서비스 계정이 낫다. 또한 언제든 폐기할 수 있어야 한다. 실험용 MCP 서버에 장기 관리자 토큰을 넣는 것은 피해야 한다.

스타보다 중요한 네 가지 신호

공개 저장소를 볼 때 숫자에 끌리기 쉽다. 하지만 MCP 서버에서는 다음 네 가지가 더 중요하다.

첫째, 최근성이다. 최근 몇 달 안에 커밋이나 릴리스가 있었는가. MCP 호스트와 SDK가 바뀌면 서버도 맞춰 바뀌어야 한다.

둘째, 응답성이다. 설치 실패, 인증 오류, 보안 문의에 관리자가 답하는가. 문제는 생길 수 있다. 중요한 것은 방치하지 않는 태도다.

셋째, 명확성이다. 도구 목록, 권한, 설정 예시, 오류 해결법이 문서화되어 있는가. 문서가 불명확하면 사용자는 과도한 권한을 넣어 문제를 해결하려 한다.

넷째, 제한 가능성이다. 파일 경로, API 스코프, 읽기 전용 모드, 허용 도메인, 실행 가능한 명령을 제한할 수 있는가. 좋은 서버는 강력한 기능을 제공하더라도 좁게 쓸 수 있게 만든다.

제3자 보안 레지스트리나 분석 도구도 참고할 수 있다. 예를 들어 일부 도구는 MCP 서버의 파일 입출력, 네트워크 접근, 브라우저 제어, DB 질의, 셸 실행 같은 권한 지도를 보여 주고 위험 신호를 요약한다³. 다만 이런 점수는 보조 신호일 뿐이다. 최종 판단은 내 데이터와 내 환경을 기준으로 해야 한다.

개인 실험 환경과 업무용 PC의 기준은 달라야 한다

개인 노트북에서 샘플 문서로 실험하는 것과 회사 PC에서 고객 데이터에 접근하는 것은 전혀 다른 일이다. 같은 MCP 서버라도 설치 기준이 달라져야 한다.

개인 실험 환경에서는 새 서버를 빠르게 시험해 볼 수 있다. 그래도 최소한의 원칙은 지킨다.

테스트 폴더만 연결한다.
임시 토큰을 사용한다.
중요한 계정으로 로그인된 브라우저를 쓰지 않는다.
설치 후 설정 파일에서 불필요한 서버를 제거한다.

업무용 PC에서는 기준을 더 높인다.

출처가 확인된 서버만 사용한다.
회사 보안 정책과 소프트웨어 설치 규칙을 확인한다.
읽기 전용 권한부터 시작한다.
고객 정보, 영업 정보, 소스 코드 접근 여부를 따로 검토한다.
팀 단위로 승인된 설정 예시를 공유한다.
토큰을 설정 파일에 직접 적지 않고 안전한 비밀 관리 방식을 쓴다.

가장 피해야 할 방식은 "일단 설치해 보고 안 되면 권한을 더 준다"는 습관이다. MCP에서는 반대로 해야 한다. 가장 좁은 권한으로 시작하고, 필요한 이유가 확인될 때만 넓힌다.

설치 전 10분 체크리스트

새 MCP 서버를 발견했다면 바로 설정 파일에 넣지 말고 다음 질문에 답해 보자.

누가 만들었는가: 공식, 벤더, 커뮤니티 중 어디인가?
저장소와 패키지 이름이 서로 일치하는가?
README에 도구 목록과 사용 예시가 있는가?
어떤 권한을 요구하는가?
읽기 전용 모드나 접근 범위 제한이 가능한가?
최근 커밋과 릴리스가 있는가?
이슈에 관리자가 응답하는가?
민감한 환경변수나 토큰을 요구하는가?
원격 서버라면 데이터가 어디로 전송되는가?
이 서버를 업무용 PC에 설치해도 설명할 수 있는가?

마지막 질문이 중요하다. "왜 이 서버가 필요하고, 어떤 데이터에 접근하며, 문제가 생기면 어떻게 끊을 수 있는가"를 설명할 수 있어야 한다. 설명할 수 없는 서버는 아직 설치할 준비가 되지 않은 서버다.

좋은 서버는 기능보다 경계가 선명하다

쓸 만한 MCP 서버는 많은 일을 하는 서버가 아니다. 자신이 하는 일과 하지 않는 일을 분명히 말하는 서버다. 좋은 README는 설치 명령만 보여 주지 않는다. 지원 기능, 요구 권한, 실행 방식, 제한 방법, 문제 해결법을 함께 제공한다.

MCP의 장점은 AI와 외부 도구를 빠르게 연결하는 데 있다. 하지만 빠른 연결은 빠른 노출이 될 수도 있다. 공개 서버를 고를 때는 기능 소개보다 권한 표를 먼저 보고, 스타 수보다 최근 유지보수를 보고, 개인 실험과 업무 환경을 구분하자.

이 기준만 지켜도 무작정 설치하는 단계에서 벗어날 수 있다. 다음 장에서는 이 기준을 바탕으로 파일, 문서, 지식베이스를 실제로 연결할 때 어떤 서버와 권한 구성이 적절한지 살펴본다.

참고

¹Official MCP Registry API

²Publish an MCP server on NuGet.org to the Official MCP Registry

³Vet – MCP Server Security Registry

책 목록

MCP: AI 에이전트 연결의 표준

전체 목차 보기