MCP 서버 실전 구축과 프로덕션 보안: ‘대시보드 없는 업무흐름’의 대가를 계산하라

배경: MCP는 ‘에이전트 시대의 통합 인터페이스’가 된다

Anthropic에서 시작해 Linux Foundation으로 넘어간 MCP(Model Context Protocol)는, 에이전트(Claude Code, Cursor 등)가 외부 시스템을 표준화된 “도구(tool)” 호출로 연결하는 방식이 빠르게 굳어지고 있습니다. dev.to의 번역 관리 툴(Verba) MCP 서버 구축 사례는 MCP의 본질이 “기술 데모”가 아니라 업무 흐름의 재설계(컨텍스트 스위칭 제거)임을 보여줍니다. 사용자는 더 이상 ‘웹 대시보드’에 들어가 키를 만들고 번역을 확인하는 대신, IDE 안에서 “프랑스어 누락 키 보여줘”, “일본어 추가해줘”처럼 자연어로 운영 작업까지 수행합니다(동일 맥락에서 Kent C. Dodds 인터뷰 기사도 ‘Chat as interface’를 강조). 이는 우리 팀 관점에서 UI/대시보드보다 API/권한/감사가 제품 경쟁력이 되는 방향 전환입니다.

핵심 분석: Verba 사례가 말해주는 ‘실전 MCP 서버’의 최소 단위

Verba MCP 서버는 의도적으로 “얇은 래퍼(thin wrapper)”로 설계됩니다. TypeScript로 MCP SDK를 붙이고, 서버는 로컬에서 stdio(JSON-RPC over stdin/stdout)로 떠서 AI 클라이언트가 서브프로세스로 실행합니다. 핵심 포인트는 3가지입니다.

1) 비즈니스 로직/DB를 MCP 서버에 넣지 않는다: MCP 서버는 Verba REST API만 호출하고 상태를 갖지 않습니다. 결과적으로 코드베이스 변경은 “새 서버”가 아니라 기존 API의 도구화입니다. 우리도 MCP를 붙일 때, 먼저 “이미 있는 내부 API/어드민 API를 도구로 래핑”하는 쪽이 마이그레이션 비용이 낮습니다.

2) 시크릿은 로컬 환경 변수에 남긴다: 로컬 stdio 모델에서는 API 키가 로컬 환경에만 존재하고, MCP 서버가 이를 읽어 외부 API를 호출합니다. 이는 ‘가볍게 시작하는’ 방식으로는 좋지만, 팀/조직 단위 운영으로 가면 곧바로 “키 배포/회수/감사” 문제가 터집니다.

3) 도구 설계가 곧 제품 UX: “키 생성/언어 추가/미번역 조회/정리” 같은 작업은 대시보드 UX가 아니라 tool schema(입력/출력/에러) 품질로 결정됩니다. 즉, 우리 코드베이스에는 ‘엔드포인트’가 아니라 에이전트 친화적인 작업 단위(예: listMissingTranslations, addLocale, deleteKeyPrefix)로 API를 재구성해야 합니다.

비교/대조: stdio 로컬 MCP vs SSE/원격 MCP(프로덕션)

로컬 stdio는 “개인 생산성”엔 최적이지만, 조직/프로덕션으로 갈수록 SSE(HTTP)나 원격 MCP가 필요해집니다. 여기서 비용이 갈립니다.

stdio(로컬)
장점: 네트워크 노출이 작고, TLS/인증을 덜 고민해도 됨(기본적으로 로컬 프로세스 간 통신).
단점: 개발자 PC마다 설정/키/버전이 달라 재현성이 낮음. 온보딩 시 “설정 지옥”이 생김.
SSE/원격(팀/조직)
장점: 도구 버전, 정책, 감사로그를 중앙에서 통제 가능.
단점: 네트워크 상에서 인증·암호화·권한분리·레이트리밋이 필수. dev.to 보안 체크리스트가 지적하듯 HTTP(S) 설정 실수 한 번에 크리덴셜이 평문 노출될 수 있음.

현실적 결론: 1단계는 stdio로 “워크플로우가 실제로 이득인지”를 검증하고, 2단계에서 원격화하며 보안/감사/권한을 제품 수준으로 올리는 2단 로드맵이 합리적입니다.

시사점: 우리 코드베이스에 생기는 변화(기능 추가가 아니라 운영면적 증가)

MCP 도입의 진짜 비용은 ‘서버 한 개 더’가 아니라, 에이전트가 호출하는 순간부터 시스템이 자동화 가능한 운영 API로 바뀐다는 점입니다.

API 표면적 재정의: 기존 REST가 “화면 단위”였다면, MCP tool은 “작업 단위”여야 합니다. 예: POST /translations보다 tool.addTranslationKey(defaultText, keyHint, locales[])가 에이전트에 안전합니다(입력 제한/검증이 쉬움).
권한모델 세분화: “읽기 전용/쓰기/삭제”를 최소 2~3단계로 나누지 않으면, 에이전트 실수 한 번에 대량 삭제/변경이 납니다.
감사로그가 기능 요구사항으로 승격: 누가(어떤 MCP 서버가) 언제 어떤 키를 만들고 삭제했는지 추적이 안 되면, 운영 사고의 원인 규명이 불가능합니다.
테스트 전략 변경: 단위테스트보다 “도구 호출 시나리오” 테스트가 중요해집니다. 예: ‘미번역 조회 → 번역 생성 → 검수 상태 변경’ 같은 체인 테스트.

정량적으로 보면, 단순 래퍼 MCP는 1~2일 안에 PoC가 가능하지만(Verba처럼 단일 TS 파일 수준), 프로덕션 등급(권한/감사/회수/레이트리밋)까지 포함하면 보통 2~4주 스프린트 1회는 각오해야 합니다(기존 IAM/로깅 인프라 성숙도에 따라 변동).

실행 가이드: ‘실전 구축 + 프로덕션 보안’ 체크리스트(코드 레벨)

아래는 Verba 구축 글의 아키텍처 단순성(Thin wrapper)과, dev.to 보안 체크리스트의 운영 리스크 항목을 합쳐 우리 팀이 바로 적용할 형태로 재구성한 항목입니다.

1) Tool 설계: 안전한 작업 단위로 쪼개기

삭제/파괴적 작업은 별도 tool로 분리: deleteKeysByPrefix 같은 것은 dryRun=true 기본값 + 결과 리턴 후 “확인 tool”을 한 번 더 호출하게 설계(2-step).
입력 스키마에 제약을 박아라: prefix 길이 최소 3자, 삭제 최대 N개(예: 100) 제한, locale은 enum 강제.
멱등성(idempotency): addLanguageToProject는 이미 존재해도 성공 처리(에이전트가 중복 호출하기 쉬움).

2) 시크릿/설정: ‘로컬 편의’에서 ‘회수 가능’으로

MCP 설정 파일에 키 금지: 체크리스트가 지적한 것처럼 claude_desktop_config.json, .cursor/mcp.json에 평문 키가 들어가기 쉽습니다. CI에 grep -rn 'sk-|password|token|api_key'류 스캔을 넣어 사전 차단.
환경 분리(DEV/PROD 키 공유 금지): 이름부터 DEV_*, PROD_*로 갈라 실수 확률을 낮춤.
회전(rotate) 목표시간 SLO 설정: ‘키 교체 5분 내’ 같은 내부 기준을 두고, 이를 못 맞추면 중앙화(Secrets Manager 또는 전용 Secret MCP)로 이동.

3) 권한 최소화: read-only와 write 분리

최소 2종의 크리덴셜을 발급: TRANSLATION_READ_TOKEN, TRANSLATION_WRITE_TOKEN.
repo/org 범위 제한: 가능하면 프로젝트/리포지토리 단위로 scope를 좁힘(체크리스트의 “repo:*는 위험”과 동일 논리).

4) 전송/배포: stdio는 시작, 원격은 TLS 강제

로컬 PoC는 stdio로 시작(네트워크 공격면적 최소).
SSE/원격 MCP로 가면 HTTPS 강제 + 인증(mTLS 또는 OIDC/JWT) 없이는 배포 금지. 설정 파일에서 http:// 스캔을 자동화.

5) 감사로그/관측성: “누가 무엇을 했나”를 남겨라

최소 필드: tool_name, request_id, actor(서버/사용자), resource_id, diff 요약, timestamp, result(success/fail).
민감정보 마스킹: 입력 args 전체를 남기지 말고(특히 토큰/PII), 해시/요약 필드로 분리.
운영 질문에 답 가능해야 함: “지난 24시간 어떤 시크릿이 조회됐나?”, “이 변경을 만든 MCP 서버는 무엇인가?”(보안 체크리스트 핵심).

6) 실패 모드 설계: 에이전트는 항상 ‘예상 밖’으로 호출한다

레이트리밋/쿼터: 예) 분당 tool 호출 60, 파괴 작업 10.
타임아웃/재시도 정책 통일: API 호출은 3회 지수 백오프, 총 10초 상한.
서킷브레이커: 외부 API 장애 시 ‘읽기 tool만 허용’ 같은 degrade 모드.

7) 마이그레이션 전략(권장 순서)

1주차: 로컬 stdio PoC(핵심 3~5개 tool)로 업무시간 절감 효과 측정(예: 번역 키 추가/정리 작업 소요시간 30~50% 감소 목표). 2~3주차: 권한 분리/감사로그/테스트 시나리오 추가. 4주차: 원격(SSE) 검토 및 조직형 시크릿 관리(중앙 회전/감사)로 확장.

위 3개 dev.to 글(Verba 구축기, MCP 보안 체크리스트, ‘chat as interface’ 논의)이 공통으로 말하는 결론은 단순합니다. MCP는 “연동 방식”이 아니라 업무 인터페이스의 중심 이동이고, 그 순간부터 보안과 운영(권한·감사·회전)이 기능 요구사항이 됩니다. 우리 팀은 ‘얇게 래핑해 빠르게 검증’하되, 프로덕션으로 갈수록 “운영면적 증가 비용”을 정면으로 예산화해야 합니다.