모두가 지금 모든 것에 모델 컨텍스트 프로토콜(MCP) 서버를 추가하고 있습니다. 저도 그 이유를 잘 알고 있습니다. MCP는 구조가 깔끔합니다. 표준화되어 있습니다. 서버를 만들고 몇 가지 도구를 노출하면, 곧바로 LLM이 로그 플랫폼을 쿼리하고, 대시보드를 가져오고, 알림을 발송할 수 있게 됩니다. 올바른 추상화처럼 느껴집니다.
하지만 저는 유수의 기업 팀들이 스킬이어야 할 워크플로에 MCP 통합을 구축하느라 몇 주를 소모하고, 정작 MCP가 필요했던 작업에는 스킬을 만들고 있는 것을 보았습니다. 이러한 혼란 때문에 사람들이 상당한 시간을 잃고 있습니다.
저는 이렇게 구분합니다.
MCP는 배관과 같습니다. 스킬은 전문성입니다.
MCP 서버는 다음 질문에 답합니다. 에이전트는 무엇을 할 수 있는가?
모델에게 도구에 대한 접근 권한을 제공합니다. 이 API를 쿼리하도록 지시합니다. 이 데이터셋을 읽습니다. 이 시스템에 씁니다. MCP는 LLM과 현실 세계를 연결하는 계층입니다. 이는 역량을 부여하는 것입니다.
스킬은 다른 질문에 답합니다. 에이전트는 이 유형의 문제를 어떻게 생각해야 하는가?
스킬은 패키지화된 판단력입니다. 전문가가 적용하는 일련의 단계, 도메인별 휴리스틱, “X를 보면 Z를 하기 전에 Y를 하라”는 식의 사고방식입니다. 스킬은 워크플로를 코드화합니다. MCP는 접근 권한을 코드화합니다.
둘 다 필요합니다. 하지만 이 둘은 서로 대체할 수 없으며, 필요한 곳에 다른 하나를 사용하면 좋지 않은 결과를 초래합니다.
제가 이 구분이 흔들리는 지점
로그 분석 플랫폼에서 운영되는 보안 운영 팀을 예로 들어 보겠습니다. 그들은 AI를 활용해 경보 조사를 지원받고자 합니다. 본능적으로 MCP 서버를 구축하려고 합니다. 로그를 검색하는 도구를 노출합니다. 위협 인텔리전스를 조회하는 도구를 노출합니다. 자산 컨텍스트를 가져오는 도구를 노출합니다. 이제 LLM은 경고를 “조사”할 수 있습니다.
하지만 실제로는 그렇지 않습니다. 완전히 그렇지는 않습니다.
에이전트에게 부여한 것은 접근 권한입니다. 조사 워크플로는 제공하지 않았습니다. S3 버킷에 대한 CSPM 경고가 발생하면 먼저 CloudTrail을 확인하고, 지난 24시간 동안의 IAM 활동을 교차 확인한 다음, 버킷이 민감한 것으로 태그되어 있는지 점검한 후에야 에스컬레이션해야 한다는 점을 코드로 구현하지 않았습니다. 그건 MCP 문제가 아닙니다. 그건 스킬의 문제입니다.
MCP 도구만 있고 스킬이 없는 에이전트는, 환경의 모든 시스템에 접근할 수 있지만 한 번도 조사를 해본 적이 없는 신입 분석가와 같습니다. 무엇이든 쿼리할 수 있습니다. 하지만 무엇을, 어떤 순서로, 어떤 가설을 가지고 쿼리해야 하는지는 알지 못합니다.
스킬은 곧 훈련입니다. MCP는 출입증입니다.
MCP가 실제로 필요할 때
에이전트가 다른 방법으로는 도달할 수 없는 실시간 데이터나 시스템에 대한 실시간 액세스가 필요할 때 MCP 서버가 필요합니다.
- 특정 시간 범위 내 이벤트를 로그 플랫폼에서 조회하기
- SIEM에서 현재 경고 상태 가져오기
- 프로그램 방식으로 모니터 생성 또는 업데이트하기
- 실시간 CMDB를 기준으로 자산 목록 확인하기
이것들은 툴 호출입니다. 상태를 저장하지 않고, 데이터를 반환하며, 동작을 수행합니다. MCP는 올바른 추상화입니다.
여러 에이전트나 여러 인터페이스가 동일한 기능에 대한 액세스를 공유해야 할 때도 MCP가 필요합니다. 로그 플랫폼용 MCP 서버 한 대. 모든 에이전트, 모든 통합, 모든 IDE 플러그인이 모두 동일한 서버와 통신합니다. 그게 바로 이 프로토콜을 올바르게 사용하는 방식입니다.
스킬이 정말로 필요할 때
아래 예시와 같이 판단력이 내재된 반복 가능한 워크플로를 인코딩할 때는 스킬이 필요합니다.
- 이 경고 유형을 조사하세요(올바른 순서는 무엇이고, 검증해야 할 가설은 무엇이며, 출력을 어떻게 구조화해야 하는지).
- 이 로그 형식을 파싱하세요(에지 케이스는 무엇이고, 공급업체가 잘못하는 부분은 어디이며, 올바른 필드 추출 방법은 무엇인지).
- 이 위협 패턴에 대한 탐지 규칙을 만드세요(방법론은 무엇이고, 규칙이 시끄러운 경우와 정확한 경우를 가르는 기준은 무엇인지).
- 사고 회고를 수행하세요(가져와야 할 내용, 타임라인을 구성하는 방법, 답해야 할 질문이 무엇인지).
이것들은 도구 호출이 아닙니다. 이것들은 워크플로입니다. 에이전트는 도구가 존재한다는 사실만이 아니라, 자신이 가진 도구를 어떻게 활용해야 하는지도 알아야 합니다.
스킬은 MCP 도구를 호출할 수 있습니다. 이게 실제로 효과적인 패턴입니다. 스킬은 추론 프레임워크를 제공하고, MCP는 데이터 액세스를 제공합니다. 스킬이 전체를 오케스트레이션합니다. MCP가 실행합니다.
제가 사용하는 기준
누군가 저에게 “이게 스킬이어야 할까요, 아니면 MCP 서버여야 할까요?”라고 물으면 저는 한 가지를 되묻습니다.
만약 팀의 선임 전문가가 이 작업을 수동으로 수행한다면, 가장 어려운 부분은 데이터에 접근하는 것일까요?아니면 데이터를 얻고 난 뒤에 무엇을 해야 하는지 아는 것일까요?
어려운 부분이 접근이라면 MCP가 필요합니다. 판단이 어려운 부분이라면 스킬이 필요합니다.
솔직히 말하면 대부분의 경우 어려운 부분은 판단입니다. 그래서 MCP 서버만으로는 사람들이 기대하는 대로 잘 동작하지 않습니다. 당신은 에이전트에게 열쇠를 쥐여 줬습니다. 하지만 운전하는 법은 가르치지 않았습니다.
실용적인 버전
실제로 워크플로 문제인 것들에 대해 MCP 서버를 구축하는 것을 중단하세요. 스킬을 일급 아티팩트로 취급하기 시작하세요. 마치 런북을 관리하듯, 시간이 지남에 따라 설계하고, 테스트하고, 버전 관리하고, 개선해야 할 대상으로 보세요.
MCP 서버는 인프라입니다. 스킬은 팀의 전문성을 패키징한 것입니다. 둘 다 중요합니다. 둘은 단지 서로 다른 질문에 대한 서로 다른 답일 뿐입니다.
현재 비중은 어떻습니까? MCP에 과도하게 치우쳐 있습니까, 아니면 스킬을 진지하게 다루기 시작했습니까?
더 중요한 것은 실행 수준에서 자율성과 도구 접근 권한을 어떻게 제어하고 있습니까?
