매출 DB에 MCP까지 필요할까: 오버엔지니어링과 보안의 경계선

마케팅 대행사에서 관리자용 인사이트 도구를 만들던 한 실무자가 사내 매출 데이터에 FastMCP로 서버를 붙이려다 커뮤니티에서 제동이 걸렸다. "그냥 API나 쿼리 정리한 스킬로 충분한 거 아니냐"는 지적이었다. 요즘 MCP를 둘러싼 논쟁이 이 장면 하나에 그대로 압축돼 있다. Model Context Protocol(MCP)은 2024년 11월 Anthropic이 발표한 이후 AI 에이전트와 외부 시스템을 연결하는 사실상 표준으로 자리 잡았지만, 동시에 "아무 데나 MCP부터 만들고 보는" 유행에 대한 반작용도 커지고 있다. 클로드코드 사용자 커뮤니티 '클코단'에서 오간 논의를 계기로, MCP를 언제 쓰고 언제 걸러야 하는지, 쓴다면 어떤 보안 원칙을 지켜야 하는지 짚어봤다.

MCP는 원래 무엇을 위한 프로토콜인가

MCP는 AI 모델이 데이터 소스와 도구에 접근하는 방식을 표준화한 개방형 프로토콜이다. Anthropic은 이를 'USB-C 포트'에 비유한다. 어떤 기기든 같은 규격의 케이블로 연결할 수 있듯, MCP를 지원하는 AI 클라이언트라면 어떤 MCP 서버든 별도의 커스텀 코드 없이 연결할 수 있다는 뜻이다. 서버는 도구(tools)·리소스(resources)·프롬프트(prompts)라는 세 가지 기본 요소를 통해 AI에게 기능을 노출한다. 2025년 이후 Python 진영에서는 FastMCP가 사실상 표준 프레임워크로 자리 잡았다. Jeremiah Lowin이 만들고 Prefect가 유지해온 프로젝트다. 데코레이터 몇 줄로 스키마·검증·문서화를 자동 생성해주는 덕분에 채택이 빨랐고, 2026년 3월 기준 일일 다운로드 400만 건을 넘어섰다. MCP 자체도 계속 성장하는 중이다. 최근 Anthropic은 이 프로토콜을 리눅스재단 산하 'Agentic AI Foundation'에 기증했는데, 이 재단에는 Block·OpenAI가 함께 참여하고 Google·Microsoft·AWS·Cloudflare 등이 지원사로 이름을 올리고 있다. 특정 기업 종속이 아닌 업계 공용 표준으로 넘긴 셈이다.

"그냥 API면 되는데"가 나오는 이유

방 논의에서 나온 첫 반응 그대로, 업계에서도 MCP 오버엔지니어링에 대한 경계론이 뚜렷하다. 개발 블로그 Evil Martians는 "대부분의 MCP 서버는 존재할 필요가 없다"는 도발적인 제목의 글에서, 언제 어떤 도구를 부를지 사람이나 스크립트가 항상 결정하는 구조라면 MCP가 아니라 그냥 함수 하나면 충분하다고 짚었다. 단일 앱이 단일 백엔드에 붙는 경우, 혹은 세 개 남짓의 정해진 엔드포인트만 호출하는 경우도 마찬가지다. MCP 자체는 도구를 세팅하고 인증을 구성하고 트랜스포트를 설정하고 테스트하는 절차가 필요해 API 직접 호출보다 무겁다. 성능 면에서도 단순 요청에는 API가 더 빠르고 가볍다는 게 여러 비교 글의 공통된 결론이다. 방에서 나온 지적처럼, 사내 매출 데이터를 조회하는 게 목적이라면 쿼리와 스키마를 정리한 스킬(마크다운 지침 파일)로 처리하는 편이 구성도 단순하고 토큰 비용도 적다.

반대로 MCP가 정말 필요해지는 지점

반론도 근거가 있다. MCP가 힘을 발휘하는 지점은 AI 에이전트 스스로 어떤 도구를 호출할지 판단해야 하거나, 여러 클라이언트(Claude, Cursor, 사내에서 만든 에이전트 등)가 같은 기능을 공유해서 써야 할 때다. 방 논의에서 나온 "여러 팀 서비스에 접근권한이 없이 데이터를 가져와야 하는 경우"는 정확히 MCP의 인증 체계가 겨냥한 시나리오이기도 하다. MCP 인증 규격은 2025년 3월 OAuth 2.1과 PKCE를 표준으로 못 박은 뒤, 6월에는 악의적 서버가 토큰을 가로채지 못하도록 리소스 인디케이터(RFC 8707)를 의무화했다. 11월에는 '엔터프라이즈 관리형 인가' 확장까지 추가됐는데, 클라이언트가 사내 IdP(계정관리 시스템)에서 직접 토큰을 발급받는 방식이다. 팀마다 흩어진 서비스에 개별 권한을 나눠 받는 대신, 조직 차원의 IdP를 거쳐 접근권을 통일해서 관리할 수 있게 된 셈이다. 이 정도 인증 인프라가 필요한 조직이라면 단순 API 나열보다 MCP+OAuth 조합이 실제로 유효하다.

Read 전용 원칙과 커지는 보안 리스크

방 논의에서 가장 의견이 모인 지점은 "CRUD 중 Read만 허용해야 한다"는 원칙이었는데, 이는 업계 가이드와도 정확히 일치한다. MongoDB의 공식 MCP 서버는 아예 `--readOnly` 플래그를 기본 권장 설정으로 제시하고, 읽기 전용 DB 계정을 별도로 만들어 연결하라고 안내한다. admin 키를 평문으로 공유하는 관행에 대한 경고도 근거가 있다. OWASP가 2025년부터 정리 중인 'MCP Top 10'은 토큰 관리 소홀과 비밀정보 노출, 도구 설명에 악성 지시를 심는 '툴 포이즈닝(tool poisoning)'을 주요 위험군으로 꼽는다. 실제로 2026년 1~2월 두 달 동안만 MCP 생태계에서 CVE(보안 취약점 식별번호)가 30건 넘게 새로 등록됐고, 이 중 43%가 셸 인젝션 계열이었다. mcp-remote 패키지에서는 CVSS 9.6점짜리 원격 코드 실행 취약점(CVE-2025-6514)이 43만 건 넘는 다운로드 이력과 함께 발견되기도 했다. 2025년에는 WhatsApp MCP 서버가 도구 설명에 심어진 악성 지시만으로 대화 기록 전체를 빼돌릴 수 있다는 사례도 보고됐다. Read 전용 강제는 이런 위협을 원천 차단하지는 못해도 피해 범위를 크게 줄이는 최소한의 방어선이다.

내부망이 없는 조직은 어떻게 해야 하나

방에서는 내부망·샌드박스 분리도 대안으로 제안됐지만, 마케팅 대행사 규모에서는 그런 인프라 자체가 없을 수 있다는 현실적 한계가 함께 언급됐다. 이는 실제로 많은 소규모 조직이 마주치는 문제다. 보안 전문가들이 제시하는 절충안은 계층을 나눠 가능한 것부터 처리하는 방식이다. 가장 먼저 손댈 수 있는 건 읽기 전용 DB 계정 발급으로, 설정에 5분이면 충분하다는 게 업계의 공통된 조언이다. 다만 읽기 전용 권한만으로는 무거운 쿼리로 서버 자원을 소진시키는 공격까지 막지는 못한다는 지적도 있어, 애플리케이션 서버의 IP에서만 접속을 허용하는 네트워크 수준 제한, 작업이 끝나면 자격증명을 즉시 회수하는 시크릿 스코핑 같은 장치를 순서대로 얹는 방식이 권장된다. 전용 내부망이 없더라도 클라우드 DB의 접근 제어 목록(ACL)이나 VPC 설정만으로 상당 부분을 구현할 수 있다는 게 실무자들의 공통된 견해다.

정리

결국 이번 논의가 남긴 결론은 두 갈래다. 단순 조회가 목적이라면 MCP 없이 쿼리와 스키마를 정리한 스킬로 시작하는 편이 낫다는 의견이 우세했고, 여러 팀의 서비스에 흩어진 데이터를 통합해서 가져와야 하거나 여러 AI 클라이언트가 같은 기능을 공유해야 하는 상황이라면 OAuth 기반 MCP가 정당화된다는 데도 이견이 적었다. 어느 쪽을 택하든 Read 전용 권한과 최소한의 접근 제어는 타협 대상이 아니라는 점은 분명하다. 2026년 들어 MCP 관련 취약점 보고가 급증한 상황을 감안하면, "일단 붙이고 본다"는 접근은 그 자체로 위험 신호에 가깝다.