MCP가 ‘멋진 사양’에서 ‘아마도 필요할 거야’로 약 1년 만에 변했다

Source: Dev.to

번역을 진행하려면 전체 텍스트(코드 블록 및 URL 제외)를 제공해 주시겠어요? 텍스트를 받는 대로 요청하신 대로 한국어로 번역해 드리겠습니다.

MCP가 하는 일의 간략 버전

MCP 이전에는 모든 AI‑에이전트‑툴 통합에 각각 맞춤형 커넥터가 필요했습니다:

• GitHub → 맞춤형 GitHub 통합
• Slack → 맞춤형 Slack 통합
• …등등.

MCP가 이를 표준화합니다.
하나의 프로토콜로, 어떤 MCP 클라이언트든 어떤 MCP 서버와도 통신할 수 있습니다. 사람들은 이를 “AI용 USB‑C” 라고 부르는데—진부하지만 꽤 정확합니다.

• 전송 방식: JSON‑RPC 2.0 (특별한 것이 없음).
• 가치: 모델에게 어떤 도구가 존재하고, 그것이 무엇을 하며, 어떻게 호출하는지 알려주는 계약.
• 핵심 구분:
  • 프롬프트는 모델에게 어떻게 행동할지 알려줍니다.
  • MCP는 모델에게 무엇을 볼 수 있고 호출할 수 있는지 알려줍니다.

챗봇 데모를 넘어 실제 운영 시스템으로 이동할 때, 이 구분은 매우 중요합니다.

2025‑2026년에 폭발적으로 성장한 이유

세 가지 동시 진행되는 힘이 빠른 채택을 이끌었습니다:

1. Agents가 샌드박스를 떠남

   • 실제 업무 흐름 – 회의 예약, 데이터베이스 조회, 배포 트리거, 코드 작성 및 실행.
   • 프로덕션 에이전트는 구조화된 컨텍스트가 필요합니다; 즉석에서 프롬프트를 채워넣는 것만으로는 충분하지 않습니다.

2. Tool‑calling이 기본 기능이 됨

   • OpenAI, Anthropic, Google, Amazon 등은 이제 툴 호출을 바로 지원합니다.
   • MCP 이전에는 각 통합이 벤더‑특정(Claude‑전용, GPT‑전용) 이었습니다.
   • MCP는 툴을 모델 간에 포터블하게 만들어 대규모 채택을 촉발했습니다.

3. 거버넌스와 컴플라이언스가 등장

   • 보안 및 컴플라이언스 팀이 답을 요구했습니다:
     • 누가 툴 호출을 승인했는가?
     • 어떤 데이터에 접근했는가?
     • 감사 로그가 존재하는가?
   • MCP의 구조화된 접근 방식은 이러한 답변을 제공할 수 있습니다—올바르게 구성한다면.

제가 불편함을 느끼는 부분

최근에 Claude Desktop으로 MCP를 설정했습니다:

1. Filesystem server – Claude가 내 머신에서 파일을 읽고 쓸 수 있게 합니다.
2. GitHub server – JSON 설정 파일에 붙여넣는 개인 액세스 토큰(PAT)이 필요했습니다.

그 토큰은 평문으로 저장되며 전체 저장소 접근 권한을 부여합니다. 위험성이 명확해졌습니다:

프로덕션에서 MCP에 대해 생각하는 방식

모든 답을 가지고 있지는 않지만, 직접 사용하고 침해 보고서를 읽어본 뒤 제가 정립한 사고 모델을 공유합니다.

1. MCP를 인프라처럼 다루기

   • 이것은 “멋진 기능”이 아니라 배관(plumbing)입니다.
   • 데이터베이스 연결이나 API 게이트웨이에 적용하는 것과 같은 엄격함으로 배포하세요.

2. 항상 최소 권한 원칙

   • PAT 및 기타 자격 증명을 적극적으로 범위 제한하세요.
   • 각 MCP 서버에 실제로 필요한 권한만 부여하십시오.

3. LLM의 결정에 무조건 신뢰하지 않기

   • 기존 소프트웨어에서는 직접 만든 API를 호출하므로 신뢰합니다.
   • MCP에서는 LLM이 어떤 도구를 호출할지, 어떤 파라미터로 호출할지를 스스로 결정합니다.
   • 특히 파괴적이거나 민감한 작업에 대해서는 LLM의 제안과 실제 실행 사이에 검증 레이어를 삽입하세요.

4. MCP ≠ 워크플로 엔진

   • MCP는 모델에 컨텍스트가 전달되는 방식을 담당합니다.
   • 도구 실행을 스케줄링하거나 실패를 관리하고, 인간‑인‑루프 체크포인트를 강제하는 역할은 하지 않습니다.
   • MCP 위에 오케스트레이션 레이어를 구축하거나 기존 워크플로 엔진을 사용하세요.

5. 모든 것을 로그에 남기기

   • 모든 도구 호출, 파라미터, 응답을 반드시 기록하십시오.
   • 포괄적인 로그는 감사, 디버깅, 사고 대응에 필수적입니다.

TL;DR

• MCP는 LLM에게 도구를 발견하고 호출할 수 있는 표준화된 구조화 방식을 제공합니다.
• 현재 OpenAI, Google, Microsoft, Amazon 등 다수 기업에서 프로덕션 AI 에이전트의 핵심 인프라로 활용되고 있습니다.
• 보안이 가장 큰 미해결 과제입니다: 과도한 권한을 가진 토큰, 악의적인 MCP 서버, 그리고 환상적인 호출이 데이터 유출이나 공급망 공격으로 이어질 수 있습니다.
• MCP를 중요한 인프라로 간주하고, 최소 권한 원칙을 적용하며, LLM 결정을 검증하고, 오케스트레이션을 추가하고, 로그를 꾸준히 남기세요.

경계를 늦추지 마세요 – 프로토콜 자체는 견고하지만, 생태계는 아직 성숙 단계에 있습니다.

내가 주시하는 세 가지

• The Agentic AI Foundation
  Anthropic은 2025년 12월에 MCP를 이 새로운 Linux Foundation 기금에 기부했습니다. Block과 OpenAI가 공동 설립했습니다. 이는 거버넌스가 더 이상 단일 기업의 결정이 아니라는 의미입니다. 그들이 빠른 채택과 보안 성숙도를 어떻게 균형 잡느냐에 따라 MCP가 AI의 TCP/IP가 될지, 아니면 또 다른 버려진 표준이 될지가 결정됩니다.

• Google의 A2A 프로토콜
  MCP는 에이전트를 도구와 연결합니다. A2A는 에이전트를 서로 연결합니다. 이 두 프로토콜은 수렴하거나 경쟁하게 될 것입니다. 저는 결국 수렴할 것이라고 베팅하지만, 당분간은 혼란스러울 것입니다.

• 첫 번째 대규모 프로덕션 침해
  연구 단계의 취약점도 이미 심각합니다. 실제 프로덕션 환경에서 MCP 경로를 통한 대규모 침해가 발생하면(그리고 반드시 발생할 것입니다), 생태계의 대응이 모든 것을 알려줄 것입니다. 보안 성숙도가 가속화되거나, 신뢰 붕괴를 초래할 것입니다. 지켜보죠.

Where I land

MCP는 실제 문제를 해결합니다. 모든 모델‑툴 조합마다 맞춤형 커넥터를 만드는 옛 방식은 지속 가능하지 않았습니다. 표준 프로토콜을 갖는 것이 진정으로 더 좋으며, 채택 수치가 업계가 동의한다는 것을 증명합니다.

하지만 현재 우리는 “빠르게 움직이기” 단계에 있으며, “망가뜨리지 않기” 부분은 아직 따라오지 못했습니다. 보안 표면은 보안 도구보다 더 빠르게 커지고 있습니다. 편리함은 현실이며, 위험도 마찬가지입니다.

우리는 이전에도 이런 상황을 경험했습니다: 컨테이너, 마이크로서비스, 서버리스. 강력한 추상화가 등장하고, 보안 이야기가 준비되기 전에 모두가 이를 채택하고, 그 후에 우리가 처음부터 시작했어야 할 가드레일을 몇 년 동안 뒤늦게 추가하게 됩니다.

MCP가 그 주기를 반복할 필요는 없지만, 엔지니어가 이를 인프라가 아닌 장난감처럼 다룬다면 그렇게 될 것입니다.

그것으로 빌드하세요. 신중하게 빌드하세요.

다른 개발자들이 어떤 것을 보고 있는지 궁금합니다. 여러분은 MCP를 프로덕션에서 운영하고 있나요, 아니면 아직 실험 중인가요? 어떤 보안 패턴이 효과적이었나요? 댓글을 남겨 주세요—정말 알고 싶습니다.