AI 에이전트의 도구 연결, MCP vs Skills — 왜 아직도 MCP가 나은 선택일까

MCP가 뭔데, Skills는 또 뭔데?

요즘 AI 에이전트를 만들다 보면 빠지지 않는 키워드가 있어요. 바로 MCP(Model Context Protocol)인데요. 이게 뭐냐면, AI 모델이 외부 도구나 데이터에 접근할 수 있도록 해주는 표준 프로토콜이에요. 쉽게 말하면, ChatGPT나 Claude 같은 AI가 "이메일 보내줘", "데이터베이스 조회해줘" 같은 요청을 받았을 때, 실제로 그 작업을 수행할 수 있게 연결해주는 다리 역할을 해요.

반면 Skills라는 접근 방식도 있어요. 이건 AI 에이전트에게 특정 작업을 수행하는 능력(스킬)을 미리 정의해서 내장하는 방식이에요. 예를 들어 "파일 읽기 스킬", "API 호출 스킬" 같은 걸 만들어서 에이전트가 필요할 때 골라 쓰는 구조죠. Microsoft의 Semantic Kernel이나 일부 에이전트 프레임워크에서 이 패턴을 사용해요.

최근 한 개발자가 두 방식을 꽤 오래 써본 뒤 "여전히 MCP를 선호한다"는 글을 작성했는데, 그 이유가 꽤 설득력 있어요.

MCP의 핵심 장점: 표준화와 상호 운용성

MCP를 선호하는 가장 큰 이유는 표준화에 있어요. MCP는 Anthropic이 주도해서 만든 오픈 프로토콜인데, 핵심 아이디어는 "도구를 한 번 만들면 어떤 AI 클라이언트에서든 쓸 수 있게 하자"는 거예요.

이걸 비유하면 USB 같은 거예요. 예전에는 프린터마다, 카메라마다 다른 케이블을 썼잖아요? USB가 나오면서 하나의 표준 케이블로 뭐든 연결할 수 있게 됐죠. MCP도 마찬가지예요. MCP 서버를 하나 만들어 두면, Claude Desktop에서도, VS Code Copilot에서도, 커스텀 에이전트에서도 그 도구를 가져다 쓸 수 있어요.

반면 Skills 방식은 프레임워크에 종속되는 경향이 있어요. Semantic Kernel의 스킬을 LangChain에서 바로 쓸 수 없고, 그 반대도 마찬가지예요. 특정 프레임워크에 묶이면 나중에 다른 모델이나 플랫폼으로 갈아타고 싶을 때 마이그레이션 비용이 커지거든요.

개발 경험의 차이

MCP는 개발 경험(DX) 측면에서도 장점이 있어요. MCP 서버는 독립적인 프로세스로 동작하기 때문에, 어떤 언어로든 만들 수 있어요. Python으로 만들어도 되고, TypeScript로 만들어도 되고, Go로 만들어도 돼요. AI 에이전트가 Python이든 뭐든 상관없이, MCP 프로토콜만 맞추면 통신이 되니까요.

Skills는 보통 에이전트가 사용하는 언어와 프레임워크 안에서 정의해야 해요. 에이전트가 Python이면 스킬도 Python으로, TypeScript면 TypeScript로. 이게 간단한 스킬에서는 문제가 안 되지만, 기존에 Go로 작성된 사내 CLI 도구를 에이전트에 연결하고 싶다면 래퍼를 새로 짜야 하는 번거로움이 생겨요.

MCP의 또 다른 편리한 점은 디버깅과 테스트예요. MCP 서버는 독립적으로 실행되니까, AI 클라이언트 없이도 서버만 띄워서 도구가 잘 동작하는지 테스트할 수 있어요. curl이나 간단한 JSON-RPC 클라이언트로 직접 호출해볼 수 있거든요.

그렇다고 Skills가 나쁜 건 아니에요

Skills 방식에도 장점이 있어요. 단일 프레임워크 안에서 완결되니까 설정이 단순하고, 별도의 서버 프로세스를 관리할 필요가 없어요. 작은 프로젝트나 빠른 프로토타이핑에서는 오히려 Skills가 더 빠르게 결과를 낼 수 있죠.

또한 Skills는 에이전트의 내부 상태에 직접 접근할 수 있어서, 에이전트의 메모리나 컨텍스트와 긴밀하게 연동되는 복잡한 로직을 짜기 쉬워요. MCP는 프로세스 간 통신이라 이런 밀결합(tight coupling)이 상대적으로 어렵거든요.

하지만 장기적으로 보면, 에이전트 생태계가 빠르게 변하는 지금, 특정 프레임워크에 종속되지 않는 MCP가 더 안전한 투자라는 게 글쓴이의 핵심 주장이에요.

업계 흐름: MCP가 사실상 표준이 되어가는 중

MCP는 Anthropic이 처음 만들었지만, 이제는 다양한 회사와 커뮤니티에서 채택하고 있어요. OpenAI도 자체 에이전트 도구 연결에 MCP 호환을 고려하고 있고, GitHub Copilot, Cursor, Windsurf 같은 AI 코딩 도구들도 MCP를 지원하기 시작했어요. MCP 서버를 모아놓은 오픈소스 레지스트리도 빠르게 성장하고 있고요.

이런 흐름은 프로그래밍 언어의 LSP(Language Server Protocol)와 비슷해요. LSP가 나오기 전에는 각 에디터마다 언어 지원을 따로 만들어야 했는데, LSP가 표준이 되면서 하나의 언어 서버로 VS Code, Vim, Emacs 어디서든 쓸 수 있게 됐잖아요. MCP도 비슷한 역할을 AI 도구 생태계에서 하려는 거예요.

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

AI 에이전트를 직접 만들거나, 사내 시스템에 AI를 연동하는 작업을 하고 계신다면, MCP를 먼저 살펴보는 게 좋아요. 특히 여러 AI 모델이나 플랫폼을 오가며 써야 하는 환경이라면 MCP의 상호 운용성이 빛을 발해요.

실용적인 시작점으로는, 사내에서 자주 쓰는 도구(Jira 조회, 슬랙 메시지, DB 쿼리 등)를 MCP 서버로 감싸보는 거예요. 한 번 만들어 두면 Claude Desktop에서도, 직접 만든 에이전트에서도, 나중에 나올 새로운 AI 도구에서도 재활용할 수 있어요.

물론 아직 MCP 생태계가 완전히 성숙하지는 않았어요. 인증/인가 처리, 서버 배포 및 관리, 에러 핸들링 같은 부분은 계속 발전 중이에요. 하지만 방향성은 확실히 MCP 쪽으로 기울고 있어요.

마무리

AI 에이전트가 세상의 도구들과 대화하는 방식은 결국 표준 프로토콜로 수렴할 가능성이 높고, 지금 그 자리에 가장 가까운 건 MCP예요.

여러분은 AI 에이전트에 도구를 연결할 때 어떤 방식을 쓰고 계신가요? MCP를 이미 써보셨다면 어떤 경험이었는지 궁금해요.