요즘은 모두가 모든 것에 모델 컨텍스트 프로토콜(MCP) 서버를 추가하고 있습니다. 그 이유도 이해합니다. MCP는 깔끔하고 표준화되어 있습니다. 서버를 작성하고 몇 가지 도구를 노출하기만 하면, LLM이 곧바로 로그 플랫폼을 쿼리하고 대시보드를 불러오며 알림을 생성할 수 있습니다. 이것이 적절한 접근 방식처럼 보입니다.
하지만 상당한 규모의 기업에서 스킬로 구현했어야 할 워크플로를 위해 MCP 통합을 구축하느라 몇 주를 허비하거나, 반대로 실제로 MCP가 필요한 작업을 스킬로 구축하는 팀을 보아 왔습니다. 이러한 혼동으로 인해 실제로 상당한 시간이 낭비되고 있습니다.
이를 구분하는 방식은 다음과 같습니다.
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 서버는 인프라입니다. 스킬은 팀의 전문 지식을 패키지화한 것입니다. 둘 다 중요하지만, 서로 다른 질문에 대한 답일 뿐입니다.
현재 어느 쪽에 더 치우쳐 있나요? MCP에 지나치게 의존하고 있나요, 아니면 스킬을 본격적으로 다루기 시작했나요?
더 중요한 질문은 이것입니다. 실행 단계에서 자율성과 도구 액세스를 어떻게 제어하고 있습나요?
