Claude Code가 직접 시스템에 손을 뻗는 순간
지금 당신 팀에서도 이런 장면이 반복되고 있을 것이다. Claude에게 프로덕션 상태를 물어보면, Claude는 직접 볼 수 없다. 그래서 팀원이 SSH로 접속해 명령을 실행하고, 출력을 복사해서 채팅에 붙여넣는다. Claude가 다음 명령을 요청하면 다시 반복한다. 결국 개발자가 Claude와 시스템 사이의 '고비용 복붙 버퍼'가 되는 구조다.
MCP(Model Context Protocol)는 이 루프를 끊는다. Claude Code가 직접 호출할 수 있는 함수 집합—즉 도구를 정의해두면, Claude는 인간 릴레이 없이 시스템과 직접 대화한다. dev.to에 연재 중인 Claude Code, Beyond the Prompt 시리즈(Part 4)는 이 전환을 "chat in a terminal"에서 "operational interface"로의 도약이라고 표현한다. 정확한 묘사다.
문제는 '줄 수 있느냐'가 아니라 '어떻게 줄 것인가'
팀 리드 입장에서 MCP 도입의 핵심 질문은 "이게 작동하는가?"가 아니다. "이걸 팀원이 잘못 설정했을 때 무슨 일이 벌어지는가?"다.
MCP 서버는 Claude가 요청할 때마다 실제 코드를 실행한다. 데이터베이스에 쿼리를 날리고, 로그를 읽고, 서비스 상태를 확인하고, 심지어 파일을 배포할 수도 있다. 여기서 핵심 설계 원칙이 등장한다: 도구가 규칙을 강제해야 한다. 프롬프트가 아니라.
"Claude에게 DELETE 하지 말라고 했으니 괜찮다"는 생각은 위험하다. SELECT만 허용하는 코드 검사가 있어야 안전한 것이다. Claude가 아무리 영리해도, 모델에 의존하는 안전 장치는 안전 기능이 아니라 안전 요청에 불과하다.
실제 설계에서 지켜야 할 다섯 가지 원칙
두 소스 기사—Python FastMCP를 활용한 실전 사례와 Go SDK 기반 구현 가이드—를 교차하면, 팀이 MCP 서버를 설계할 때 반드시 내재화해야 할 원칙이 수렴된다.
1. 읽기 전용을 기본값으로 삼아라 쿼리, 로그 확인, 상태 체크—Claude가 필요로 하는 것의 80%는 읽기다. 쓰기·배포 도구는 나중에, 하나씩, 의도적으로 강화해서 추가한다. 먼저 안전한 것부터 쌓는 것이 팀의 실수 비용을 낮춘다.
2. 도구의 폭발 반경(blast radius)을 코드로 제한하라
행 수 제한, 타임아웃, 경로 탐색 차단—이것들은 성능 최적화가 아니라 사고 방지 장치다. run_shell 같은 만능 도구 하나보다 db_query_ro 같은 좁고 명확한 도구 여러 개가 훨씬 안전하다. 노출하지 않은 기능은 발생할 수 없는 인시던트다.
3. 모든 도구 호출을 로깅하라 감사 로그는 "뭔가 이상한 일이 생기지 않았으면 좋겠다"를 "정확히 무엇이 언제 실행됐는지 알고 있다"로 바꾼다. Claude에게 실제 시스템 접근 권한을 줬다면, 그 원장(ledger)이 팀이 밤에 잠들 수 있게 해주는 근거다.
4. 응답 크기를 도구가 통제하라 5,000줄 로그를 통째로 돌려주는 도구는 컨텍스트 창을 낭비하고 비용을 키운다. 20줄만 돌려줘라. 도구의 출력 설계는 곧 토큰 예산 설계다.
5. 도구 설명은 카피라이팅처럼 써라 Go SDK 기반 구현 사례에서 특히 강조된 포인트다. "search"라는 설명은 Claude에게 아무것도 말해주지 않는다. "날짜순으로 정렬된 청구서를 최대 limit건 전문 검색하여 반환"이라고 써야 Claude가 언제, 어떻게 호출할지 정확히 판단한다. 도구 설명은 사실상 그 도구의 시스템 프롬프트다.
트랜스포트 선택이 보안 아키텍처를 결정한다
Go SDK 구현 사례가 짚어주는 중요한 포인트가 하나 더 있다: stdio와 HTTP 트랜스포트의 차이는 단순한 기술적 선택이 아니라 보안 아키텍처 선택이다.
stdio는 클라이언트가 로컬에서 서브프로세스로 실행한다. 인증은 머신 수준에서 상속된다. 개인 도구, 로컬 개발환경에 적합하다. 반면 HTTP 트랜스포트는 팀 공유 서버, SaaS 연동에 쓰인다—그리고 이 순간부터 네트워크 공격 면적이 생긴다. 인증 미들웨어 없는 HTTP MCP 서버는 사실상 자기 시스템에 대한 셀프서비스 RCE(원격 코드 실행)를 열어두는 것이다.
프로토타입은 stdio로 시작하지만, 팀에 배포하는 순간 HTTP로 전환하면서 반드시 인증·타임아웃·로깅 미들웨어를 함께 붙여야 한다. 이 전환을 나중으로 미루면 기술 부채가 아니라 보안 부채가 된다.
acpdbg가 보여주는 다음 단계: 디버거까지 에이전트의 클라이언트가 된다
MCP와 유사한 방향으로 등장한 흥미로운 사례가 있다. acpdbg는 LLDB 디버거를 ACP(Agent Client Protocol) 클라이언트로 만드는 도구다. C/C++/Rust/Swift 프로그램이 크래시하거나 브레이크포인트에 걸리면, 백트레이스와 소스 컨텍스트를 캡처해 Claude Code나 GitHub Copilot에 전달한다. 에이전트는 거기서 멈추지 않고 MCP 툴 브리지를 통해 실제로 디버거 명령을 실행하며 가설을 검증할 수 있다.
이게 MCP 안전 설계 관점에서 흥미로운 이유는 하나다: 에이전트가 접근할 수 있는 시스템의 범위가 계속 확장되고 있다는 것. 데이터베이스 쿼리에서 로그 테일링, 파일 배포, 그리고 이제 런타임 디버거까지. 통합 대상이 늘수록 각 도구마다 권한 범위를 명시적으로 설계해야 한다는 원칙은 더 엄격해진다.
팀 도입 전에 체크해야 할 것들
MCP를 팀에 도입할 때 드는 비용을 냉정하게 짚어보자. 도구 하나 만드는 것 자체는 어렵지 않다. Python FastMCP로 읽기 전용 DB 쿼리 도구를 만드는 데 반나절이면 충분하다. 문제는 그 이후다.
첫 번째, 거버넌스 설계 비용. 어떤 도구를 누가 만들고, 어떤 기준으로 팀 MCP 서버에 추가되는지 프로세스가 없으면 도구가 쌓일수록 관리가 어려워진다. 두 번째, 로그 관리. 모든 호출을 로깅하겠다는 원칙은 좋지만, 그 로그를 누가 모니터링하고 어떤 기준으로 이상 징후를 판단하는지 정해져 있지 않으면 감사 로그는 그냥 쌓이는 파일이 된다. 세 번째, 팀원 교육. MCP 도구를 잘 설계하는 것과 그 도구를 Claude가 어떻게 활용하는지 이해하는 것은 다른 능력이다. 도구 설명을 잘 쓰는 감각, 도구 결과를 어떻게 해석하는지—이건 한 번의 세션으로 해결되지 않는다.
AI에게 '손'을 주기 전에 먼저 '울타리'를 코드로 짜라
MCP는 분명히 AI-First 워크플로우에서 가장 큰 생산성 도약 중 하나다. Claude가 직접 시스템과 대화하면서 팀원이 복붙 버퍼 역할에서 벗어나는 것—그 가치는 실재한다.
그러나 이 전환의 전제 조건은 명확하다: AI를 믿는 것이 아니라 도구 설계를 믿는 것. 모델이 신중하게 행동하기를 기대하는 것이 아니라, 코드가 부주의하게 행동할 수 없도록 만드는 것. 읽기 전용으로 시작하고, 폭발 반경을 코드로 제한하고, 모든 호출을 기록하고, 응답 크기를 통제하고, 도구 설명을 정확하게 쓰는 것.
팀에 MCP를 도입한다면, 첫 번째 도구는 가장 자주 반복되는 복붙 작업 하나를 제거하는 좁고 읽기 전용인 무언가여야 한다. 그것만으로도 완전한 첫 번째 MCP 서버다. 다음 도구는 실제 작업이 요구할 때 추가하면 된다.