"MCP는 죽었다." 🫠
근 이주간 이런 글을 세번 정도 본 것 같습니다. 그리고 저도 요즘 Claude Code로 하네스를 열심히 깎다보니 이에 대해 많은 생각들을 하게되었습니다.
MCP가 죽었다는 사람들의 말을 종합해보면 그 이유는 이 네가지 정도로 귀결될 것 같습니다.
첫째, 사전에 로드되는 Tool 설명으로 인한 컨텍스트의 비대화. 둘째, 미사용 기능까지 읽으면서 발생하는 컨텍스트 오염과 토큰 비효율 셋째, 디버깅 문제 넷째, MCP로 인해 발생하는 과설계
동의합니다. 반면에 Skills는 매력적입니다.
필요한 순간에만 로드되고, 모듈화되어있으며, 로컬에서 개인 폴더로 존재하니 투명하고 이해하기 쉽습니다. CLI는 디버깅하기도 쉽죠.
에이전트의 사고 능력과 개발 속도를 최적화하는게 목적이라면 Skills는 강력한 선택지가 맞습니다. 그리고 저도 사실 같은 이유로, 개인 프로젝트를 할때는 MCP를 이용하지 않습니다. 모든 자동화는 Skills를 통해 만들고 있습니다.
그런데, 정말 과도기의 유물이 된걸까
MCP는 정말 과도기의 유물이 된걸까요?
IBM에서 제가 배운건 개인의 환경과 기업의 환경은 많이 다르다는 겁니다.
에이전트가 조직의 경계를 넘어야할때 어떤게 필요한가요? 자율 에이전트가 코어 뱅킹 시스템을 호출해야한다면요? ERP에서 재고 데이터를 가져오거나, 규제가 걸린 고객 데이터 플랫폼에 접근해야한다면요?
이 순간에 통제된 외부 연결이 필수적이라는 데는 이견이 없을 겁니다. 그럼 이제 이야기해야할 것은 그 연결을 어떻게 구현할 것인가입니다.
선택지는 많습니다. REST API를 직접 호출할수도 있고, gRPC나 GraphQL을 쓸 수도 있고, SI를 통해 직접 통합 레이어를 만들수도 있을겁니다.
그럼에도 기업이 MCP를 선택해야하는 이유를 저는 3가지 정도로 정리할 수 있을 것 같습니다.
첫째: 통합의 일관성
에이전트가 연결해야할 외부 시스템이 적을때는 각각 커스텀 어댑터를 만들어도 될겁니다. 하지만 N개가 된다면 시스템마다 다른 인터페이스 규격과 다른 인증방식 등을 개별 관리하는 건 불가능합니다. MCP가 표준 프로토콜로써 일관된 연결을 제공합니다.
둘째: 거버넌스 계층의 기반
MCP 자체가 보안이나 감사를 제공하는건 아닙니다. 하지만 연결 방식이 표준화되어 있다면, 그 위에 인증, 감사로그, 정책, 트래픽 제어를 일관되게 구축할 수가 있습니다. 연결방식이 제각각이면 거버넌스도 제각각이 됩니다. 이건 규제산업에서 치명적입니다.
셋째: 벤더 종속을 줄이는 방어선
개방형 프로토콜 기반의 연결을 사용하면 에이전트 프레임워크가 교체되더라도 연결 계층은 유지가 됩니다. AI는 빠르게 바뀝니다. MCP는 이에 대한 방어 수단이 될 수 있습니다.
문제는 프로토콜이 아니라 아키텍처
제가 느끼기에 MCP로 인해 발생하는 대부분의 문제는 프로토콜의 한계가 아닌, 아키텍처 설계의 문제입니다. 모든 기능을 MCP로 노출하면 컨텍스트 오버헤드가 분명 발생합니다. 하지만 우리는 여기서 MCP를 쓰지 말자 는 결론이 아닌, MCP를 어디에 쓸지 전략적으로 선택해야한다 는 결론을 얻어야합니다.
엔터프라이즈 레벨의 Agentic AI는 이런 계층적 분리가 필요합니다.
- 사고 계층: LLM과 Skills가 에이전트의 추론과 판단을 담당
- 연결 계층: MCP가 외부 시스템과의 인터페이스를 일관되게 관리
- 거버넌스 계층: 연결 계층 위에 인증, 권한, 감사, 정책을 적용
핵심은 MCP 서버를 3-5개의 전략적 외부 연계 지점에만 집중하는겁니다. 인증이 필요한 외부 SaaS API, 온프렘 레거시 시스템, 규제 대상 데이터 소스 같은 곳에서 MCP는 여전히 강력합니다.
마치며
MCP가 죽은게 아닙니다. MCP의 불안정함을 Skills를 통해 극복할 수 있게 되었고, MCP는 이제 그 목적에 더 잘 어울리는 곳에서 역할에 더 집중할 수 있게 되었습니다.
앞으로 MCP와 Skills의 포지션은 어떻게 변화해갈까요? 어떻게 생각하시나요?