MCP에서 발생할 수 있는 주요 문제점들 - LLM 에이전트가 도구를 "실제로" 사용할 수 있게 만든 MCP, 그 가능성과 위험을 살펴보다

 

지금 MCP를 알아야 하는 이유

“도구 연결만 잘하면 AI가 진짜 일할 수 있다는데... 믿어도 될까?”

요즘 Claude나 ChatGPT 같은 LLM 어시스턴트가 폭발적으로 발전하면서, 단순한 대화형 AI를 넘어서 외부 도구를 연결해 실제 업무까지 처리하는 시대가 열리고 있습니다. 바로 이런 연결을 가능하게 해주는 기술 표준이 **MCP(Model Context Protocol)**입니다.

MCP는 지금 이 순간에도 개발자 IDE, 브라우저, 업무 자동화 환경에 조용히 들어와 변화의 중심이 되고 있습니다. 하지만 동시에, 아직 보안 문제, UX 한계, LLM 신뢰성과 같은 민감한 문제들도 함께 제기되고 있죠.

이 글에서는 단순히 MCP가 무엇인지 설명하는 것을 넘어,

• 왜 이 기술이 주목받는지,
• 어디에 활용되고 있고,
• 무엇이 문제인지
  당신이 도입을 고민하기 전에 꼭 알아야 할 정보들을 모두 정리해드립니다.

반응형

---

1️⃣ MCP란 무엇인가?

🧩 정의 및 등장 배경

MCP는 LLM이 외부 도구를 사용할 수 있도록 연결해주는 통신 프로토콜입니다.
쉽게 말해, ChatGPT나 Claude 같은 LLM이 단순히 말을 이해하는 데서 멈추지 않고, 실제 동작—예를 들면 “구글 캘린더에 회의 추가”, “디버깅 결과 이메일로 전송”—를 수행할 수 있도록 해주는 방식입니다.

MCP는 특히 아래와 같은 특징을 가집니다:

• BYOT (Bring Your Own Tools) 방식 지원: 다양한 서드파티 도구를 연결할 수 있음
• JSON-RPC와 SSE 기반 설계: 단순하고 텍스트 중심의 통신 구조
• IDE, 디버깅 환경에서도 활용 가능: 개발자 친화적

💡 예를 들어 이런 명령도 가능해집니다:

“논문을 검색해서 인용이 빠진 부분을 찾고, 그 작업이 끝나면 책상 옆 램프를 초록색으로 켜줘”

---

2️⃣ MCP의 유용한 사용 사례

🔧 LLM 에이전트 자율성 강화

MCP를 통해 에이전트는 여러 단계를 자동으로 처리할 수 있습니다. 단순 질의응답이 아닌, 툴을 순차적으로 호출하고 결과를 판단하여 다음 행동을 선택하는 수준까지 가능해지죠.

💻 개발 IDE와 연계한 실시간 디버깅

예: Cursor 에디터에서 LLM이 오류 코드를 분석하고 자동으로 수정 제안. 이때 MCP는 로컬 디버거와 LLM 간 중간 다리 역할을 합니다.

🧠 자동 문맥 제공

에이전트가 명령을 수행하는 데 필요한 정보(사용자 이전 대화, 환경 변수 등)를 자동으로 주입해줍니다. 이를 통해 더 자연스럽고 맥락에 맞는 도구 사용이 가능해집니다.

---

3️⃣ 기존 도구 연동 표준과 뭐가 다를까?

방식 차이점

ChatGPT Plugins	초기 SDK는 설정이 복잡하고, LLM 모델별 지원 기능에 제한이 있었음
Anthropic Tool-Calling	구조 유사하지만, MCP는 네트워크 연결과 명세가 더 명확
Alexa/Google Assistant SDKs	IoT 친화형, 하지만 복잡하고 XML 기반인 경우 많음
REST/SOAP/GraphQL	데이터 중심 API. MCP는 더 높은 수준에서 작동하며 사용자 인터페이스와 직접 연결됨

결국, MCP는 단순한 API가 아닌, LLM이 도구와 ‘의사소통’할 수 있게 만드는 연결 언어입니다.

---

4️⃣ MCP의 한계와 잠재적 문제들

MCP는 분명 강력하지만, 실제 도입에 앞서 아래의 4가지 핵심 리스크를 이해하고 대비해야 합니다.

---

⚠️ 문제 1: 프로토콜 보안

• 인증 미비: 초기엔 인증이 없었고, 이후 추가된 OAuth 방식도 복잡하고 일관성 부족
• 로컬 실행 취약점: STDIO 방식으로 MCP 서버가 악성 코드 실행 통로가 될 수 있음
• 입력 신뢰 과도: 사용자 입력을 그대로 실행하는 구현 사례 존재 (RCE 가능성)

---

⚠️ 문제 2: UI/UX 한계

• 도구 위험도 구분 없음: 파일 삭제 도구와 단순 조회 도구가 같은 수준으로 다뤄짐
• 비용 통제 어려움: 응답 길이에 따라 요금 증가, 불필요한 툴 호출로 과금 리스크
• 비구조적 응답 설계: JSON 등 구조화된 정보 대신 텍스트만 주고받아 시각적 피드백 부족

---

⚠️ 문제 3: LLM 보안 리스크

• 프롬프트 인젝션 강화: 도구가 system 프롬프트 일부로 오염 가능
• 도구 설명 동적 변경 가능: 사용 승인 후 이름과 설명을 바꾸는 'rug pull' 공격 가능
• 제4자 인젝션: 하나의 MCP가 또 다른 서버의 데이터를 신뢰할 경우 공격 경로 증가
• 민감 데이터 누출 가능성: 단순 읽기 작업으로도 사용자 정보 외부 유출 가능

---

⚠️ 문제 4: LLM 한계

• 성능 저하: 도구 수가 많아질수록 응답 품질은 떨어질 수 있음
• 도구 사용 정확도 낮음: 최신 LLM조차 복잡한 툴 사용 성공률 낮음 (16% 수준)
• 문맥 부족 문제: 많은 도구 호출로 문맥 과부하 발생
• 도구 설계 차이로 인한 호환성 문제: 같은 도구라도 LLM에 따라 작동 여부 달라질 수 있음

---

728x90

도입 전 알아야 할 체크리스트

MCP는 LLM을 실질적인 업무 도구로 탈바꿈시키는 핵심 기술입니다. 에이전트의 자율성을 높이고, 자동화를 가능하게 만들지만 동시에 기존에 없던 리스크도 수반됩니다.

✅ 도입 전 체크포인트

• 도구별 위험도 구분 가능한지?
• 인증/보안 구조가 명확한지?
• LLM이 실제 도구를 정확히 사용할 수 있는지?
• 사용자에게 충분한 컨트롤권이 주어지는지?

https://blog.sshh.io/p/everything-wrong-with-mcp

Everything Wrong with MCP