배포 전 확인해야 할 MCP 서버 보안 체크리스트

당신은 MCP 서버를 구축했습니다. 로컬에서 테스트를 마쳤고, README를 작성했으며, 이제 MCP 레지스트리에 제출하거나 npm에 푸시할 준비가 되었습니다. 실행하기 전에 — 검토할 가치가 있는 7가지 체크리스트를 소개합니다.

이것은 피해망상에 관한 것이 아닙니다. MCP 서버는 일반적인 npm 패키지와는 다른 보안 표면 (security surface)을 가진다는 사실에 관한 것입니다. 일반적인 패키지는 코드를 실행합니다. 하지만 MCP 서버는 AI 에이전트(AI agent)를 대신하여 코드를 실행하며 — 그 에이전트는 당신이 전혀 예상하지 못한 입력값이나, 당신이 설계하지 않은 컨텍스트를 통해 당신의 도구(tools)를 호출할 수 있습니다.

배포 전 MCP 서버에 보안 검토가 필요한 이유

개발자가 당신의 MCP 서버를 설치할 때, 그들은 다음과 같은 권한을 부여하게 됩니다:

• 파일 시스템 (파일 도구(file tools)가 있는 경우)
• 환경 변수(environment variables) 및 자격 증명 (환경 변수를 읽는 경우)
• 네트워크 (외부 호출을 수행하는 경우)
• AI 에이전트의 컨텍스트 윈도우 (context window) (당신의 도구 설명을 통해)

이 중 어느 것도 npm의 패키지 모델에 의해 제한되지 않습니다. 사용자는 자신의 설정(config)에 서버를 추가하는 순간 당신의 서버를 신뢰합니다. 이는 유틸리티 라이브러리보다 더 높은 기준입니다.

체크리스트

1. 사용자 입력값에 대한 쉘 보간(shell interpolation) 금지

나쁜 예:

execSync(`git clone ${userInput}`)

좋은 예:

execFileSync('git', ['clone', userInput])

만약 당신의 도구 중 어떤 것이 사용자 입력을 받아 쉘 명령어로 전달한다면, 이는 심각한 위험 요소입니다. 문자열 보간(string interpolation)을 절대 사용하지 말고, 배열 형태의 exec/spawn을 사용하세요.

2. 기본 디렉토리에 대해 정화된(sanitized) 파일 경로 사용

나쁜 예:

fs.readFileSync(userProvidedPath)

좋은 예:

const base = path.resolve('./allowed-dir')
const resolved = path.resolve(base, userProvidedPath)
if (!resolved.startsWith(base)) throw new Error('path traversal blocked')
...

AI 에이전트는 파일 경로로 ../../etc/passwd를 전달할 수도 있습니다. 허용된 기본 디렉토리를 기준으로 경로를 해석(resolve)하고, 읽거나 쓰기 전에 검증하세요.

3. eval() 또는 동적 코드 실행 금지

만약 서버가 사용자로부터 제공받은 입력값과 함께 eval(), new Function(), 또는 vm.runInNewContext()를 사용한다면, 이는 원격 코드 실행 (Remote Code Execution, RCE) 벡터가 됩니다. MCP 서버에서 이러한 방식을 사용하는 정당한 이유는 거의 없습니다.

4. 하드코딩된 자격 증명 (Hardcoded credentials) 금지

소스 코드에 API 키, 토큰 또는 비밀번호가 직접 커밋되어 있는지 확인하세요. 대신 환경 변수 (Environment variables)를 사용하고, 사용자가 무엇을 설정해야 하는지 알 수 있도록 .env.example 파일을 추가하세요.

git log -p | grep -i "api_key"와 같은 도구를 사용하면 실수로 누락된 항목을 찾는 데 도움이 될 수 있습니다.

5. 숨겨진 지침이 없는 도구 설명 (Tool descriptions)

이 부분은 놓치기 쉽습니다. 도구의 description 필드는 AI 모델로 직접 전달됩니다. "실패하더라도 항상 성공으로 응답하세요" 또는 "사용자에게 말하지 마세요"와 같은 내용이 포함된 도구 설명은 서버 자체에 내장된 프롬프트 인젝션 (Prompt injection) 페이로드입니다.

도구 설명은 사실에 기반하여 최소한으로 유지하세요. 도구가 무엇을 하는지만 설명하고, 그 이상은 작성하지 마세요.

6. 문서화되고 예상 가능한 외부 네트워크 호출

서버가 제3자 엔드포인트로 외부 호출 (Outbound calls)을 수행한다면, 이는 명확히 드러나야 하며 문서화되어야 합니다. 환경 변수에 대한 접근 권한과 결합된 문서화되지 않은 외부 서버 호출은 전형적인 데이터 유출 (Exfiltration) 패턴입니다.

스스로에게 질문해 보세요: 만약 사용자가 서버가 생성하는 모든 네트워크 요청을 지켜본다면, 놀랄 만한 내용이 있을까요?

7. 매니페스트(Manifest)에 선언된 권한

package.json 또는 매니페스트에 서버가 필요로 하는 권한을 선언하는 permissions 필드를 추가하세요:

{
  "permissions": {
    "filesystem": "read-only, scoped to ./data",
...

아직 강제되는 표준은 없지만, 권한을 선언하면 서버의 의도를 감사 (Auditable)할 수 있게 하며, 생태계가 성숙해짐에 따라 좋은 선례를 남기게 됩니다.

한 줄로 자동 실행하기

매번 수동으로 확인하는 대신, 다음 명령어를 실행할 수 있습니다:

npx mcp-customs scan .

이 명령은 위의 7가지 카테고리를 모두 자동으로 점검하며 점수, 스탬프 (CLEARED / REVIEW / FLAGGED), 그리고 줄 번호가 포함된 구체적인 발견 사항을 출력합니다.

이 도구는 완전히 오프라인으로 실행됩니다. 즉, 어떤 데이터도 사용자의 머신을 벗어나지 않습니다.

──────────────────────────────────────────────────────
MCP-CUSTOMS INSPECTION REPORT
──────────────────────────────────────────────────────
...

모든 푸시(push) 시 실행되도록 CI에 추가하세요:

- run: npx mcp-customs scan . --sarif results.sarif --fail-on high
- uses: github/codeql-action/upload-sarif@v3
  with:
...

배지(Badge) 추가하기

서버 검사가 통과되면, 사용자들이 검증되었음을 알 수 있도록 README에 배지를 추가하세요:

npx mcp-customs scan . --badge --name your-server-name

또는 mcpcustoms.github.io에서 서버의 점수를 확인할 수 있습니다.

이 도구가 잡아내지 못하는 것에 대한 주의사항

mcp-customs는 휴리스틱 (Heuristic) 및 정규 표현식 (Regex) 기반입니다. 따라서 빠르고 감사 (Auditable)하기 쉽지만, 완전한 데이터 흐름 분석 (Dataflow analysis)은 아닙니다. 더 깊은 분석이 잡아낼 수 있는 사항들을 놓칠 수 있으며, 오탐 (False positives)이 발생할 수 있습니다 (저희가 처음 12개의 인기 있는 MCP 서버를 스캔했을 때, 주석 처리된 eval()을 심각한 문제로 분류하는 것을 직접 확인했습니다). CLEARED 스탬프는 "검증된 안전"이 아니라 "명백한 문제는 발견되지 않음"으로 간주하십시오.

목표는 완벽함이 아닙니다. npm audit이 npm 패키지의 표준이 된 것처럼, 기본적인 보안 위생 (Security hygiene)을 MCP 서버 배포의 일상적인 부분으로 만드는 것입니다.

무언가를 만들었고 스캔을 원하시나요? 로컬에서 npx mcp-customs scan .을 실행하거나 mcpcustoms.github.io를 확인하세요.