MCP은 정말 끝났을까? AI 에이전트 통합의 현실과 한계

갑자기 'MCP는 죽었다'라는 말이 나온 이유

작년부터 AI 개발자 사이에서 가장 뜨거웠던 단어 중 하나가 바로 MCP(Model Context Protocol) 였어요. Anthropic이 공개한 이 프로토콜은 "AI 에이전트가 외부 도구나 데이터에 접근하는 방식을 표준화하자"는 야심찬 목표를 가지고 등장했죠. 쉽게 말하면 USB-C 같은 거예요. 예전엔 모니터, 충전기, 외장하드마다 케이블이 다 달랐잖아요? MCP도 "LLM이 슬랙이든 깃허브든 노션이든 같은 방식으로 연결하게 하자"는 발상이었거든요.

그런데 Quandri 엔지니어링 팀에서 "MCP는 죽었다"라는 도발적인 글을 올렸어요. 직접 프로덕션에서 MCP 서버를 운영해본 결과, 약속했던 만큼의 가치를 주지 못한다는 거죠. 한참 핫했던 기술에 대한 반대 의견이라서, AI 에이전트를 만들고 있는 팀이라면 한번쯤 짚고 넘어갈 만한 이야기예요.

무엇이 문제였나

글의 핵심 주장을 정리하면 이래요. MCP가 풀려고 했던 문제는 "AI 에이전트가 도구를 동적으로 발견하고 사용한다"는 거였는데, 실제로 해보니 에이전트가 도구를 잘 못 고르더라는 거예요. 도구가 10개만 넘어가도 LLM이 헷갈려서 엉뚱한 걸 호출하거나, 같은 작업을 반복하거나, 비용만 쓰고 결과는 시원찮은 일이 자주 벌어진다는 거죠.

또 하나는 컨텍스트 윈도우 낭비 문제예요. MCP는 사용 가능한 도구들의 설명(스키마)을 프롬프트에 다 박아 넣어야 하는데, 도구가 늘어날수록 토큰을 어마어마하게 잡아먹어요. 정작 사용자의 진짜 질문을 처리할 토큰은 줄어드는 본말전도가 생기는 거죠. 글쓴이는 "차라리 우리가 필요한 워크플로우를 결정론적인 코드로 짜고, LLM은 핵심적인 추론 부분에만 호출하는 게 훨씬 안정적이고 저렴했다"고 말해요.

세 번째는 보안과 권한 관리예요. MCP 서버를 통해 외부 시스템에 접근할 수 있게 열어두면, LLM이 잘못된 판단으로 데이터를 지우거나 잘못된 API를 호출할 위험이 생겨요. 프롬프트 인젝션 공격에도 취약하고요. 결국 "사람이 일일이 확인 버튼을 누르거나, 권한을 매우 좁게 제한해야 한다"는 결론이 되는데, 그러면 처음에 약속했던 "자율적인 에이전트"의 매력이 많이 사라지는 셈이죠.

그럼 대안은 뭘까

글쓴이가 추천하는 방향은 "워크플로우 우선, LLM은 보조" 패턴이에요. 한국식으로 풀면 "기존 백엔드 개발하듯이 흐름을 명확히 설계하고, 그 안에서 자연어 이해나 판단이 필요한 지점에만 LLM을 부르는" 방식이죠. LangGraph나 Inngest처럼 워크플로우 엔진을 쓰거나, 그냥 평범한 함수 호출로 구성하는 거예요.

이건 사실 업계 전반에서 비슷한 흐름이 보여요. OpenAI의 Agents SDK, Anthropic의 Claude Skills, 그리고 LangChain 진영 모두 "완전 자율 에이전트"보다는 "잘 짜여진 파이프라인 + 부분적 LLM 추론" 쪽으로 무게중심을 옮기고 있거든요. MCP 자체가 죽었다기보다는, "MCP를 만능 해결사로 쓰지 마라" 정도로 받아들이는 게 정확할 거예요.

한국 개발자에게 주는 시사점

요즘 사내에서 AI 에이전트 PoC를 돌려보는 팀이 많아졌죠. 슬랙 봇에 MCP 붙여서 사내 시스템 다 연결하면 만능 비서가 될 것 같다는 기대도 흔하고요. 하지만 이 글이 던지는 메시지는 분명해요. "도구 목록만 늘린다고 똑똑한 에이전트가 되는 게 아니다" 라는 거죠.

실무에 적용한다면 이런 점을 고려해보면 좋아요. 자주 쓰는 워크플로우 5~6개는 차라리 코드로 명시적으로 짜고, LLM은 분류나 요약처럼 자연어 처리가 꼭 필요한 부분에만 부르는 게 안정적이에요. 그리고 MCP 서버를 붙일 거면 도구 개수를 10개 이하로 제한하고, 도구 설명도 최대한 짧고 명확하게 쓰는 게 토큰 절약에 도움이 돼요.