[IT-LLM] Agentic AI를 “프로덕션”으로 만드는 핵심: MCP(Model Context Protocol) 기술 해부

Agentic AI를 “프로덕션”으로 만드는 핵심: MCP(Model Context Protocol) 기술 해부

에이전트(Agentic AI)는 결국 외부 시스템(데이터·도구)과의 연결 품질로 성패가 갈립니다. 문제는, 지금까지의 “도구 연동”이 모델/프레임워크/제품마다 제각각이어서 유지보수 비용·보안 통제·이식성(Portability)이 항상 발목을 잡았다는 점입니다.

MCP(Model Context Protocol)는 이 연결을 표준 프로토콜(JSON-RPC 기반, 표준 전송 방식 포함)로 정의해, 에이전트가 “툴/리소스/프롬프트”를 일관되게 발견·호출·운영할 수 있게 만듭니다. 즉, MCP는 Agentic AI의 “데모”를 “운영”으로 끌어올리는 연동 표준 + 운영 설계의 기준점입니다.

 

[그림 1] Agentic AI와 MCP(Model Context Protocol) 기본 개념 

이 글에서 얻을 수 있는 것
1) MCP의 내부 구조(역할/레이어/전송/Capability)를 기술적으로 이해
2) MCP vs 기존 연동 방식(Function Calling/Plugins/Direct API/RAG) 비교로 도입 판단
3) 보안·운영(권한/OAuth/감사로그/배포)까지 포함한 실무 체크리스트

 

목 차

1. MCP가 해결하는 문제와 프로토콜 구조
2. MCP vs 기존 기술 비교(Function Calling/Plugins/Direct API/RAG)
3. MCP 실무 적용 포인트: 아키텍처·배포·운영 설계
4. MCP 리스크/한계: 보안·권한·공급망·운영 사고 포인트
5. MCP 체크리스트 + FAQ

 

1. MCP(Model Context Protocol)가 해결하는 문제와 프로토콜 구조

1.1 “연동의 표준화”가 왜 Agentic AI의 본질인가

Agentic AI는 계획(Plan) → 도구 호출(Act) → 검증/반성(Check/Reflect) → 반복으로 목표를 달성합니다.
이때 실제 가치가 생기는 구간은 “도구 호출”인데, 기존에는 각 도구를 모델별·프레임워크별·제품별로 다른 방식으로 붙여야 했고, 결과적으로 “연동 코드가 자산”이 아니라 “부채”가 되는 경우가 많았습니다.
MCP는 이 문제를 클라이언트-서버 표준 프로토콜로 해결합니다. AI 앱(Host)이 MCP Client를 통해 여러 MCP Server에 연결하고, 서버가 제공하는 기능을 “표준 형태”로 노출합니다.

포인트: MCP는 “도구 호출”을 프롬프트 테크닉이 아니라 프로토콜/운영 레이어로 끌어올려 확장성과 통제를 동시에 노립니다.

 

1.2 MCP의 기술 스택: JSON-RPC + 표준 전송(Transports) + Capability

MCP의 핵심은 JSON-RPC 기반 메시징과 표준 전송 방식(Transports)입니다. 공식 스펙은 메시지 인코딩으로 JSON-RPC를 사용하며, 전송으로 stdio와 Streamable HTTP를 표준으로 정의합니다. 또한 서버는 기능을 “ Capabilities”로 선언하며 대표적으로 Tools(실행 함수), Resources(읽기 리소스), Prompts(표준 프롬프트 템플릿)를 제공합니다.

• Local 연동: stdio 기반으로 “로컬 프로세스” MCP 서버를 붙이기 유리
• Remote 연동: Streamable HTTP로 다수 클라이언트/세션을 처리하기 유리
• Capability 모델: 서버가 제공 가능한 기능을 표준 형태로 “발견(Discovery)” 가능

[그림 2] Agentic AI × MCP(Model Context Protocol) 참조 아키텍처: Host–Client–Server 연동과 운영 통제 레이어

 

[그림 2] 아키텍처는 에이전트가 동작하는 Host/Agent App(LLM 오케스트레이션, 플래닝, 메모리, 가드레일 포함)이 MCP Client를 통해 외부 기능을 “표준 방식”으로 발견(Discovery)하고 호출하는 흐름을 보여주며, 호출은 Transports(로컬은 stdio, 원격은 Streamable HTTP)를 통해 하나 이상의 MCP Server로 전달되고 서버는 Capabilities로서 Tools(실행), Resources(읽기), Prompts(템플릿)를 일관된 형태로 제공함으로써 에이전트의 도구/데이터 연동을 확장 가능하게 만든다는 점을 강조합니다; 동시에 중앙의 Cross-cutting Controls 레이어가 인증/인가(AuthN/AuthZ), 정책·승인(HITL), 감사로그·모니터링·레이트리밋을 전 구간에 걸쳐 적용해, “에이전트 자동화”를 프로덕션 수준에서 통제 가능하고 관측 가능한 운영 체계로 끌어올리는 구조임을 나타냅니다.

 

실무적으로는 “연결(Transport)”과 “권한(Authorization)”을 표준화했다는 점이 큽니다. 권한 관점에서 MCP는 OAuth 2.1 기반의 리소스 서버로서 토큰 검증(예: audience 검증)을 요구하는 규정까지 명시합니다.

(권한/보안: Authorization Tutorial, Authorization Spec, Security Best Practices)

 

2. MCP vs 기존 기술 비교(Function Calling/Plugins/Direct API/RAG)

구분	설명
Direct API 연동	가장 전통적인 방식. 앱이 각 시스템 REST/gRPC를 직접 붙임. 장점: 단순/명확. 단점: 시스템이 늘수록 연동 코드가 폭증하고 권한/로그/스키마/버전 관리가 제각각이 됨.
Function Calling	모델이 “함수 스키마”를 보고 필요한 호출을 선택하는 패턴(주로 요청-응답 중심). 장점: 빠른 도입. 단점: 스키마/도구 등록이 모델 또는 특정 런타임에 강결합되기 쉬움(이식성/표준성 한계). MCP는 이를 “프로토콜 레벨”로 일반화하여 서버(도구 제공자)만 바꿔도 클라이언트가 재사용되도록 설계. (참고: Anthropic MCP 소개)
Plugins(구형 확장)	특정 제품 생태계에 종속된 확장 모델이 많아 벤더 락인과 운영 일관성 문제가 발생하기 쉬움. MCP는 “호스트-클라이언트-서버” 구조로 연동 컴포넌트를 분리해 교체/확장에 유리. (아키텍처: MCP Architecture)
RAG(검색증강)	지식 정확도를 올리는 대표 패턴. 다만 RAG는 기본적으로 “읽기/검색” 중심이며, 실행(액션)·권한·감사로그는 별도 설계가 필요. MCP는 Resources(읽기)와 Tools(실행)를 함께 다루며, 권한/보안을 스펙으로 끌고 옴. (Base Protocol/Features: Base Protocol)
MCP(표준 프로토콜)	JSON-RPC 기반 메시징 + 표준 전송(stdio/Streamable HTTP) + 기능 캡ability(Tools/Resources/Prompts). 강점: 표준화·확장성·운영 통제(권한/OAuth/보안 베스트프랙티스)를 한 세트로 제공. 스펙: Transports, Authorization

 

3. MCP 실무 적용 포인트: 아키텍처·배포·운영 설계

MCP를 “기술적으로 제대로” 도입하려면, 단순히 서버를 띄우는 수준을 넘어 연동 경계(서버 분리), 권한 모델, 관측(Observability)까지 함께 설계해야 합니다.

• 서버 분리 전략: “시스템/도메인” 단위로 MCP Server를 나눠 권한·감사로그·장애 범위를 격리
• Transport 선택: 로컬 자동화(개발자 PC/에이전트 워크스테이션)는 stdio, 중앙 서비스/다중 사용자 환경은 Streamable HTTP 고려 (스펙: Transports)
• Capability 설계: Tools는 “업무 행위” 단위로 작게 쪼개고, Resources는 “읽기 전용”을 기본값으로 설정
• 버전/스키마 관리: Tool 입력/출력 스키마는 변경에 취약하므로 하위호환 규칙과 마이그레이션 정책을 문서화
• 제품 연동 현실: 일부 상용 커넥터는 스펙 전체를 100% 지원하지 않을 수 있음(예: 특정 커넥터는 Tool call 중심 등).
  예: Claude API의 MCP 커넥터는 제한사항(예: 공개 HTTP 요구, 일부 기능 지원 범위)을 명시 (Claude MCP Connector)

권장 운영 패턴은 Read-first(읽기 우선) → Draft 생성 → Human-in-the-loop 승인 → Write 실행입니다.
이 패턴은 Agentic AI의 장점(자동화)을 살리면서도 권한 남용·오작동 리스크를 현실적으로 줄여줍니다.

 

4. MCP(Model Context Protocol) 리스크 / 한계 / 오해 정리

자주 하는 오해와 현실적인 판단 기준을 정리합니다.

• 오해 1) MCP만 붙이면 보안이 해결된다
  MCP는 보안을 “자동으로” 해결하지 않습니다. 다만 OAuth 2.1 기반 권한 모델과 보안 베스트프랙티스를 스펙으로 제공해 조직이 일관된 방식으로 구현할 수 있게 합니다. (권한/보안: Authorization, Security Best Practices)
• 오해 2) MCP는 Function Calling의 “대체재”다
  실제로는 “대체”라기보다 연동을 프로토콜로 분리/표준화해 모델/프레임워크가 바뀌어도 재사용 가능한 방향을 목표로 합니다. (MCP 소개: Anthropic News)
• 리스크 1) Prompt Injection → Tool 오남용
  공격자는 “문서/웹페이지/이슈 텍스트”에 악성 지시문을 숨겨 에이전트가 잘못된 Tool을 실행하게 만들 수 있습니다.
  도구별 권한 분리, 승인 단계, 민감 작업 분리(별도 서버)가 필요합니다. (보안 가이드: Security Best Practices)
• 리스크 2) MCP 서버 공급망(서드파티 서버) 문제
  “편리한 MCP 서버”를 무심코 붙이면 데이터가 외부로 흐르거나, 권한이 과대 부여될 수 있습니다.
  서버 검증(소유/운영 주체), 최소권한, 감사로그가 기본값이어야 합니다.

 

5. MCP(Model Context Protocol) 체크리스트 + FAQ

5.1 실무 체크리스트

No	체크 항목
1	Server 분리: 도메인/시스템별로 MCP Server를 분리해 권한·로그·장애 범위를 격리했는가?
2	Transport 정책: 로컬(stdio) vs 원격(Streamable HTTP) 기준과 네트워크 보안 정책이 정의되었는가? (스펙: Transports)
3	최소권한: OAuth 2.1 기반으로 사용자/작업 단위 권한이 분리되고, 토큰 검증(audience 등)이 구현되었는가? (권한: Authorization)
4	Read-first: Resources(읽기)와 Tools(실행)를 분리하고, 쓰기 작업은 승인 플로우를 강제하는가?
5	감사로그/관측: 어떤 Tool/Resource가 언제/왜 호출됐는지, 비용/지연/오류율을 추적 가능한가?
6	프롬프트 인젝션 방어: 외부 컨텐츠를 “명령”으로 해석하지 않도록 정책/필터/승인 단계를 설계했는가? (가이드: Security Best Practices)

 

5.2 FAQ

Q. MCP를 도입하면 Function Calling은 필요 없나요?
A. 상황에 따라 다릅니다. 단순한 “단일 API 호출”만 필요하면 Function Calling만으로도 충분할 수 있습니다.
하지만 도구/시스템이 늘어나고 운영 통제(권한/로그/표준화)가 중요해지면, MCP처럼 연동을 프로토콜로 분리한 구조가 장기적으로 유지보수에 유리합니다. (배경: Anthropic MCP)

Q. MCP의 “가장 큰 기술적 차별점”은 무엇인가요?
A. JSON-RPC 기반 표준 메시징 + 표준 전송(stdio/Streamable HTTP) + 권한(OAuth 2.1) + 보안 베스트프랙티스를 “스펙으로” 묶었다는 점입니다.
즉, 연결을 “코딩 관행”이 아니라 운영 가능한 표준으로 정리했습니다. (스펙: Transports, Authorization)

Q. 도입 시 가장 흔한 실패 요인은요?
A. 권한을 크게 주고(과권한), 감사로그 없이 운영하는 것입니다.
초기에는 “읽기 중심 + 승인 기반 쓰기”로 시작하고, 서버를 도메인별로 분리해 리스크를 통제하는 것이 안전합니다. (가이드: Security Best Practices)

 

 

마무리: Agentic AI의 실전 경쟁력은 “모델 성능”보다 연동 표준 + 권한/운영 설계에서 갈립니다.
MCP는 그 연동을 JSON-RPC/표준 전송/Capability/권한(OAuth)로 정리해, 에이전트를 “운영 가능한 시스템”으로 만드는 기반을 제공합니다.
핵심은 MCP 기반 표준화와 최소권한·감사로그·승인 플로우입니다.