저는 Claude Code, Cursor, 그리고 Gemini CLI에서 작동하는 MCP 서버를 구축하고 유지 관리하고 있습니다. 이를 한동안 수행하면서 불편한 사실 하나를 깨달았습니다. 등록된 MCP 서버와 해당 서버가 노출하는 모든 것에 대한 완전한 접근 권한 사이의 거리는 거의 제로에 가깝다는 점입니다. 편리함이 곧 노출입니다.

따라서 팀이 에이전트(agent)를 "데모에서 작동하는 수준"에서 "실제 시스템을 건드리는 수준"으로 옮길 때, 매번 동일한 격차들이 나타납니다. 도구(Tool) 접근 권한이 작업(operation) 단위가 아닌 서버 단위로 부여됩니다. 아무도 의도하지 않았지만 'Fail-open(오류 시 개방)'이 기본값이 되어버립니다. 새로운 서버는 설정을 편집하고 재시작함으로써 나타나며, 검토 게이트(review gate)나 고정된 버전(pinned versions)이 없습니다. 종종 에이전트(agent) → 게이트웨이(gateway) → 모델(model) → 도구(tool)로 이어지는 호출을 추적할 수 있는 것이 없으며, 멀티 모델(multi-model) 사용은 라우팅 정책(routing policy) 없이 실행되어 월말에 예상치 못한 청구서로 돌아옵니다.

이 문제들의 대부분은 저장소(repo)를 읽어봄으로써 확인할 수 있습니다. 저는 이를 일일이 수동으로 읽는 것에 지쳐 mcp-gateway-scan을 작성했습니다.

점검 항목

이것은 일곱 가지 차원에 걸친 정적(static), 읽기 전용(read-only) 스캔입니다:

1. 도구 접근 / RBAC (Role-Based Access Control) — 도구가 신원(identity)에 대해 작업 단위로 범위가 지정되어 있는지, 아니면 서버를 등록하는 것만으로 전체 표면(surface)을 넘겨주게 되는지 확인합니다.
2. Fail-close — 모델, 게이트웨이, 또는 도구 의존성이 저하될 때, 시스템이 안전하게 거부하는지 아니면 임기응변식으로 작동하는지 확인합니다.
3. 온보딩 / 공급망 고정 (Onboarding / supply-chain pinning) — 서버를 추가하는 것이 고정된 버전을 가진 검토된 선언적 변경(declarative change)인지, 아니면 단순한 설정 편집과 재시작인지 확인합니다.
4. 관측 가능성 / OTel (Observability / OpenTelemetry) — 호출을 재구성할 수 있는 엔드 투 엔드 트레이싱(end-to-end tracing)이 있는지 확인합니다.
5. 멀티 LLM 라우팅 및 비용 (Multi-LLM routing & cost) — 라우팅 정책, 폴백(fallback) 동작, 팀별 비용 귀속(cost attribution)이 있는지, 아니면 하나의 하드코딩된 모델에 의존하며 요행을 바라는지 확인합니다.
6. 비밀 정보 / 신원 (Secrets / identity) — 설정 파일 내의 자격 증명(credentials) 대 참조(references) 방식의 차이, 그리고 신원이 도구 호출로 전파되는지 확인합니다.
7. 운영 준비성 (Production-readiness) — 킬 스위치(kill-switch), 속도 제한(rate limits), 평가 게이트(eval gates) 등 운영을 위한 필수 요건들을 확인합니다.

이 도구는 설계 단계부터 읽기 전용(read-only)으로 제작되었습니다. 사용자의 코드를 절대 실행하지 않으며, 비밀 값(secret value)을 절대 출력하지 않습니다. 기껏해야 설정 파일 내에 포함되어 있어서는 안 될 위치에 있는 비밀 리터럴(secret literal)을 가리킬 뿐입니다. 즉, 판결을 내리는 것이 아니라 확인해야 할 위치를 알려주는 역할을 합니다.

일곱 가지 차원은 공식 MCP 보안 가이드라인과 OWASP LLM Top 10에서 지적하는 실패 모드(failure modes)를 추적합니다. 여기에는 과도하게 넓은 도구 액세스(over-broad tool access), 실패 시 권한이 허용되는 에이전시(fail-open agency), 고정되지 않은 공급망(unpinned supply chains) 등이 포함됩니다 (MCP security best practices, OWASP LLM Top 10).

실행하는 세 가지 방법

일회성 읽기를 위한 CLI:

npx mcp-gateway-scan ./your-repo

CI 게이트, 오류 발생 시 0이 아닌 종료 코드 반환:

npx mcp-gateway-scan --ci ./your-repo

MCP 서버, 에이전트가 요청 시 스캔할 수 있도록 설정:

claude mcp add gateway-scan -- npx -y mcp-gateway-scan mcp

그 다음 Claude나 Cursor에게 "scan my gateway"라고 요청하면 에이전트가 직접 도구를 호출합니다. 에이전트 스택을 스캔하는 도구가 에이전트 도구(agent tool)라는 점은 참으로 적절합니다.

출력 결과의 모습

mcp-gateway-scan ./your-repo

  Tool-access / RBAC ............ yellow  tools registered per-server; no per-operation grants
...

빨간색(Red)은 다음 배포 전에 반드시 수정해야 할 항목입니다. 노란색(Yellow)은 "기초는 마련되어 있으나, 아직 연결(wired through)되지 않았다"는 의미입니다. 초록색(Green)은 해당 패턴이 단순히 의도된 것이 아니라 실제로 적용되어 있음을 의미합니다.

CI 게이트 연결하기

대부분의 팀에게 있어 --ci 플래그는 이 도구의 진가를 발휘하는 부분입니다. 워크플로(workflow)에 추가하면 새로운 빨간색 항목이 발견될 경우 머지(merge)를 차단합니다:

- name: Gateway readiness gate
  run: npx mcp-gateway-scan --ci ${{ github.workspace }}

빨간색 항목이 있으면 0이 아닌 종료 코드를 반환하고, 그렇지 않으면 0을 반환합니다. 단계적으로 강화할 수도 있습니다. 우선 노란색 항목을 허용하며 배포한 뒤, 빨간색 항목을 모두 해결하고 나면 노란색 항목에서도 실패하도록 게이트를 조일 수 있습니다. 이 스캐너는 빠르고 네트워크 의존성이 없기 때문에 모든 PR(Pull Request)에서 실행하기에 비용 부담이 적습니다.

이 도구가 수행하지 않는 것

이것은 일차적인 검토일 뿐, 최종 판결이 아닙니다. 정적 스캔 (Static scan)은 설정에 폴백 정책 (fallback policy)이 없다는 사실을 알려줄 수는 있지만, 부하 상황에서 실제 페일 클로즈 (fail-close) 동작이 유지되는지는 알려줄 수 없습니다. 왜냐하면 이를 확인하려면 실행 중인 시스템에 대한 결함 주입 (fault injection)이 필요하기 때문입니다. 이 도구는 당신이 선언한 내용을 읽을 뿐, 제공업체의 속도 제한 (rate-limit)으로 인해 새벽 3시에 실제로 발생하는 상황을 읽지는 못합니다.

보정 (Calibration)을 위해, 저는 특정 커밋에 고정된 성숙하고 널리 배포된 프록시인 LiteLLM에 7차원 방법론을 적용해 보았습니다. 결과는 녹색 4개 / 황색 3개 / 적색 0개로 나왔습니다. 즉, 운영 준비가 된 상태였으나, 잘 짜여진 코드베이스에서 구조적 검사 (structured pass)를 통해 드러나는 일반적인 예외 사항들이 발견되었습니다: 다른 구성 요소들은 페일 클로즈 (fail-close)되는 반면 페일 오픈 (fail-open)되는 인증 리졸버 (authorization resolver) 하나, 고정되지 않은(unpinned) 제3자 MCP 서버들, 그리고 도구별 최소 권한 원칙 (least-privilege)이 선택 사항(opt-in)으로 남겨진 점 등입니다. 그 후, 저는 의도적으로 결함이 있도록 설계하여 동일한 검사들을 통과하지 못하는 참조 게이트웨이 (reference gateway)를 구축했습니다. 여기서의 스캐너는 해당 방법론의 정적 슬라이스 (static slice), 즉 더 깊은 검토를 수행하기 전 몇 초 만에 실행할 수 있는 부분을 자동화합니다.

사용해 보기

• 실행하기: npx mcp-gateway-scan ./your-repo — MIT 라이선스, github.com/willianpinho/mcp-gateway-scan
• npm: mcp-gateway-scan

더 심층적인 버전을 원하신다면, 저는 willianpinho.com/mcp-audit에서 전체 Provenwright MCP 게이트웨이 준비성 감사 (Provenwright MCP Gateway Readiness Audit) (실시간 결함 주입, 트레이스 검증, 90일 개선 로드맵 포함)를 수행하고 있습니다. 무료 스캐너만으로도 충분히 가치가 있지만, 그 이상의 서비스가 필요하다면 해당 링크를 확인해 주세요.