▲

나는 여전히 Skills보다 MCP를 선호한다

 (david.coffee)
3P by GN⁺ 5시간전 | ★ favorite | 댓글 5개
  • MCP는 LLM이 도구의 내부 구조를 몰라도 작업을 요청할 수 있는 API 추상화 기반 표준 인터페이스로, 원격 사용과 자동 업데이트를 지원함
  • Zero-Install 구조, OAuth 인증, 샌드박싱 보안을 통해 설치 부담과 권한 문제를 줄이고, 어떤 플랫폼에서도 동일한 환경을 제공함
  • 반면 Skills는 CLI 설치 의존성과 인증·배포 복잡성, 플랫폼별 호환성 문제 등으로 인해 실제 실행 환경에서 마찰이 큼
  • Skills는 지식 계층, MCP는 연결 계층으로 구분되어야 하며, LLM이 외부 시스템과 상호작용할 때는 MCP를, 절차적 지식 전달에는 Skills를 사용하는 것이 적절함
  • MCP Nest와 같은 클라우드 터널링 서비스로 로컬 MCP 서버를 원격에서 접근할 수 있어, 표준화된 AI 통합 환경 구축의 핵심으로 평가됨

MCP의 장점

  • Model Context Protocol(MCP) 은 LLM이 도구의 내부 동작을 이해하지 않아도, 단순히 요청만으로 작업을 수행할 수 있는 API 추상화 구조를 기반으로 함
    • 예: LLM이 DEVONthink와 상호작용할 때 devonthink.do_x()를 호출하면 MCP 서버가 모든 처리를 담당
  • Zero-Install 원격 사용이 가능해, 클라이언트는 MCP 서버 URL만 지정하면 별도 설치 없이 바로 작동
  • 자동 업데이트가 지원되어, 원격 MCP 서버가 새로운 도구나 리소스로 갱신되면 모든 클라이언트가 즉시 최신 버전을 사용 가능
  • OAuth 기반 인증으로 보안이 강화되며, 사용자가 직접 토큰을 관리할 필요 없음
  • 이식성이 높아, Mac·모바일·웹 등 어떤 환경에서도 동일한 MCP 서버를 통해 접근 가능
  • 샌드박싱 구조로 로컬 환경의 직접 실행 권한을 제한하고, 제어된 인터페이스만 노출
  • 스마트 검색 및 자동 업데이트 기능을 통해 필요한 도구만 로드하고, 로컬 설치 시에도 실행 시 자동 갱신 가능

Skills의 한계와 마찰

  • Skills는 LLM에게 특정 지식이나 사용법을 가르치는 데는 유용하지만, 실제 동작 수행 시 CLI 의존성이 문제로 작용
  • 대부분의 Skill은 별도의 CLI 설치를 요구하지만, ChatGPT·Perplexity·Claude 웹 버전 등은 CLI 실행이 불가능
  • 이로 인해 다음과 같은 문제가 발생함
    • 배포 복잡성: CLI를 바이너리·NPM·uv 등으로 배포·관리해야 함
    • 비밀 관리 문제: 인증 토큰을 .env 파일에 평문 저장하거나, 세션이 초기화되면 인증이 사라짐
    • 생태계 단절: Skill 설치·업데이트 방식이 플랫폼마다 달라 호환성 문제와 YAML 파싱 오류 발생
    • 컨텍스트 낭비: LLM이 단일 함수 호출만 필요해도 전체 SKILL.md를 로드해야 함
  • “CLI를 먼저 설치하라”는 지침이 포함된 Skill은 불필요한 복잡성을 추가하며, 원격 MCP로 대체하는 것이 더 효율적임

적절한 도구 선택 기준

  • MCP 사용 시점: LLM이 웹사이트·서비스·애플리케이션 등 외부 시스템과 연결될 때 표준 인터페이스로 활용
    • 예: Google Calendar는 OAuth 기반 원격 MCP로 인증과 실행을 처리해야 하며, CLI 설치를 요구하지 않아야 함
    • Chrome·Hopper·Xcode·Notion 등도 각각의 기능 제어를 위한 내장 MCP 엔드포인트를 제공하는 것이 이상적임
  • Skills 사용 시점: 순수 지식 전달과 맥락 제공에 집중해야 함
    • 이미 설치된 도구(curl, git, gh, gcloud)의 사용법을 가르치는 용도
    • 조직 내 용어·업무 흐름·문체 표준화
    • PDF 처리나 비밀 관리(fnox 사용법 등)와 같은 절차적 지식 공유
  • Skills는 지식 계층, MCP는 연결 계층으로 구분되어야 함

커넥터와 매뉴얼

  • Skills와 MCP의 역할을 명확히 구분하기 위해, Skills는 LLM 매뉴얼(LLM_MANUAL.md), MCP는 커넥터(Connector) 로 불러야 한다는 제안
  • 실제 운영 중인 예시
    • mcp-server-devonthink: LLM이 DEVONthink를 직접 제어할 수 있는 로컬 MCP 서버
    • microfn: mcp.microfn.dev에서 원격 MCP 제공
    • Kikuyo: mcp.kikuyo.dev에서 원격 MCP 제공
    • MCP Nest: 로컬 MCP 서버를 클라우드로 터널링해 원격 접근 가능하게 하는 서비스 (mcp.mcpnest.dev/mcp)
  • 일부 프로젝트에서는 CLI용 Skill도 함께 제공하지만, MCP 사용법을 설명하는 Skill이 더 유용함
    • Skill은 MCP의 기능·도구 관계·사용 시점 등을 설명하는 지식 레이어로 작동
    • MCP는 실제 연결과 실행을 담당
  • 이 조합을 통해 LLM이 반복적인 시행착오 없이 효율적으로 MCP를 활용할 수 있음

MCP와 Skill의 병행 활용

  • MCP 사용 중 발견한 날짜 형식 오류나 검색 제한 등 비직관적 패턴을 Skill로 정리해 재사용
  • 이렇게 생성된 Skill은 MCP의 치트시트 역할을 하며, LLM이 불필요한 토큰 낭비 없이 정확히 동작하도록 지원
  • .claude/skills 폴더를 통해 프로젝트별 AI 행동 지침을 유지하고, 자주 쓰는 절차를 dotfiles 형태로 관리
  • AI 통합의 미래는 표준화된 인터페이스(MCP) 에 달려 있으며, CLI 기반의 파편화된 접근은 지양해야 함
  • Skyscanner·Booking.com·Trip.com·Agoda.com 등 주요 서비스의 공식 MCP 제공이 기대됨

MCP Nest 소개

  • MCP Nest는 로컬 전용 MCP 서버(Fastmail, Gmail 등)를 클라우드 터널링을 통해 원격 접근 가능하게 하는 서비스
  • Claude·ChatGPT·Perplexity 등 MCP 지원 클라이언트에서 동일하게 사용 가능
  • 로컬 머신을 직접 노출하지 않고도 모든 기기에서 동일한 MCP 환경을 유지할 수 있음

함께 보면 좋은 글 β

▲
ide127 18분전  [-]

Skills나 MCP는 서로 다른 역할을 하는 건데, 이런 글들 때문에 계속 혼동이 생기는거 같아요.

답변달기
▲
ide127 17분전  [-]

안그래도 사이비 전도사가 판치는 폭풍의 AI 업계인데

답변달기
▲
jujumilk3 3시간전  [-]

그냥 두개가 아예 다른건데 왜이런 얘기들이 계속 나올까요

답변달기
▲
xguru 3시간전  [-]

글 마지막에 MCP Nest 홍보해야해서요.. ㅎㅎㅎ 뭔가 비교성 주장들이 많이 힘을 받나봐요

답변달기
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 내가 강조하고 싶은 건 개인의 선호보다 LLM이 최적으로 일하기 위해 필요한 도구 설계에 집중해야 한다는 점임
    MCP는 오히려 마찰을 추가함. 예를 들어, 임베디드 시스템을 다룬다면 LLM이 직접 디버깅·리셋·에뮬레이터 실행 등을 할 수 있는 CLI 기반 모니터링 인터페이스를 만들게 하고, 그 사용법을 skill 파일로 문서화하면 됨
    단순한 작업이라면 MCP는 불필요함. 예를 들어 git이나 AWS 요금 계산 같은 건 LLM이 이미 잘 다룸. 복잡한 시스템만 직접 도구를 만들고 문서화하는 게 효율적임

    • MCP 논의가 너무 많은 개념을 섞어버린 느낌임. 핵심은 세션 지속성임
      일회성이라면 CLI나 API로 충분하지만, 지속적 접근이 필요하다면 MCP 서버가 유용함
      잘 구성된 MCP는 프롬프트 낭비 없이 에이전트에게 사용법을 알려줌. 지속적 접근을 skill 파일로 흉내내는 건 비효율적임. MCP는 외부 도구를 에이전트 세션에 통합하는 가장 효과적인 방식임
    • MCP와 skill은 보완 관계임. 둘을 대립적으로 보는 건 오해임
    • 현재 LLM 도구 체인은 아직 표준화되지 않은 과도기 같음. .md나 skill 등 다양한 위치에 정보를 넣는 대신, 자동화된 자기반성 루프를 통해 최적 위치로 정리하는 표준이 필요함
    • 나도 비슷한 접근을 함. 대부분의 CLI 도구를 Claude가 직접 만들었고, IDE를 거의 안 씀
      JetBrains 리팩토링 기능도 스크립트로 대체해서 세션 속도가 5분에서 10초로 줄었음
      아직 MCP는 전혀 안 씀. REST + Swagger + codegen + Claude + skill 조합이면 충분함
    • MCP의 장점은 권한 제어임. 예를 들어 AI가 git에 쓰기 권한을 갖지 않게 하려면 MCP로 노출 범위를 제한할 수 있음. 단순히 READ_ONLY_SKILL로는 부족함

  • 이 논쟁은 결국 개인 개발자 vs 조직 규모 협업의 문제임
    혼자서 빠른 피드백 루프를 원하면 CLI가 낫고, 조직 단위로 통제와 일관성이 필요하면 MCP가 맞음
    현재 MCP는 컨텍스트를 많이 잡아먹지만, 점진적 공개 방식으로 개선될 예정임

    • 조직에서는 MCP 접근 제어가 어렵다는 문제가 있음. 사람은 실수로 두 개만 지워도 되지만, 에이전트는 순식간에 수천 개를 삭제할 수 있음. CLI는 접근 범위를 제한할 수 있어 안전함
    • 컨텍스트 낭비는 클라이언트 구현 문제임. 점진적 로딩은 스펙 변경 없이도 가능함
    • MCP와 CLI는 서로 다른 목적을 가진 도구로, 함께 쓸 때 가장 강력함

  • 나는 API보다 기존 CLI 도구를 그대로 쓰는 에이전트를 원함
    로컬에서 CLI를 쓰는데 굳이 MCP를 추가할 이유가 없음. 원격 모델도 원치 않음
    API 호출이 필요하면 skill로 충분함

    • 나도 curl 명령을 skill에 직접 넣어 커스텀 API를 호출함. LLM이 이런 걸 잘 다룸
    • 하지만 비밀키 관리는 MCP가 더 안전함. MCP 서버를 먼저 띄우면 에이전트 환경에 키가 노출되지 않음
    • MCP는 에이전트와 외부 세계 사이의 보안 경계층 역할을 함. 항상 필요한 건 아니지만 유용함
    • 어떤 환경에서는 LLM이 CLI 접근 권한이 없을 수도 있음. 그땐 skill 기반 CLI 호출이 무용지물임
    • 인증(authn)과 권한(authz) 문제도 있음. MCP는 이를 미들웨어로 제어할 수 있음

  • MCP와 Skill은 제로섬 관계가 아님
    MCP는 인프라 계층의 표준화된 인터페이스를, Skill은 프로젝트별 행동 맥락을 담당함
    둘을 조합하면 안정성과 유연성을 모두 얻을 수 있음

    • MCP는 결국 CLI를 포장한 형태임. 오히려 MCP가 더 컨텍스트 오버헤드가 큼
    • 일부 유료 MCP는 실제로 가치가 있음. 예를 들어 웹 검색용 MCP는 직접 크롤러를 돌리는 것보다 편함
    • 클라우드 호스팅된 에이전트에서는 Skill + MCP 조합이 핵심 구조임. 인증과 의존성 관리가 쉬움
    • 글쓴이도 이 조합을 지지함. MCP는 이식성이 높아 ChatGPT, Claude, Perplexity 등 어디서든 동일하게 사용 가능함
    • Skill은 LLM이 무시할 수 있지만, MCP 정책은 서버 단에서 강제력이 있음

  • 대부분의 논의는 로컬에서 코딩 에이전트를 돌리는 사람들 중심임
    그런 환경에서는 Skill이 더 편하지만, 일반 사용자는 ChatGPT 같은 클라우드 기반을 씀
    이 경우 MCP가 기본 선택지가 됨. 인증과 원격 접근이 강점임

    • 하지만 어떤 사람은 MCP가 단순히 시끄러운 API 래퍼일 뿐이라고 봄
      서버를 띄워야 하고, LLM에게는 오히려 부담임. Skill은 API 문서를 LLM 친화적으로 인코딩하므로 더 간단함
    • “대부분의 사용자가 로컬 에이전트를 안 쓴다”는 주장엔 근거가 필요하다는 반박도 있었음
    • ‘agronomic’ 오타를 ‘ergonomic’으로 지적하는 농담도 있었음

  • 나는 Skill을 선호함. 사람이 쓰는 CLI 도구를 그대로 재사용할 수 있기 때문임
    Skill은 사람이 읽고 쓸 수 있는 문서로, LLM과 인간이 같은 도구를 공유함
    반면 MCP는 LLM 전용 API를 새로 만들어야 하고, 문서도 따로 관리해야 함
    Skill은 필요할 때만 로드되어 컨텍스트를 깔끔하게 유지함

  • “Skill만” 주장하는 사람은 비기술자, “CLI만” 주장은 개인 개발자에게 많음
    MCP는 엔터프라이즈 환경에 적합함. 인증과 인터페이스를 표준화함

    • 많은 사람이 JIRA MCP의 불안정성 때문에 MCP에 부정적임. acli 기반 Skill이 더 안정적이었음
    • 나는 회사 내부용 MCP를 직접 구축했음. Google Workspace 인증을 붙이고, Claude가 내부 데이터 조회나 앱 배포를 안전하게 하도록 함
      MCP는 업데이트와 배포가 쉬워 비기술자에게도 접근성이 높음
    • 기업은 이미 내부 인증 체계를 갖고 있으므로 CLI가 더 낫다는 주장도 있음
      MCP는 결국 API의 하위 집합을 구조화한 것에 불과함
    • MCP는 빠르게 띄울 수 있음. Codex → LiteLLM → VLLM → MCP로 이어지는 구성은 몇 분이면 됨
    • 나는 기존 SaaS 시스템을 레거시로 보고 있음. 데이터 접근이 어려운 API보다 로컬 SQL DB가 더 효율적임
      MCP는 단지 또 하나의 RPC 프로토콜일 뿐이며, 인증 문제도 여전히 미해결임

  • 나는 인간의 비합리성 때문에 MCP가 필요하다고 봄
    많은 조직이 여전히 API나 CLI를 제공하지 않음. MCP는 이런 디지털 단절을 메움
    기업 내 보고 체계나 정치적 구조가 자동화를 막고 있는데, MCP는 이를 우회할 수 있음

    • 나도 동의함. 동료의 에이전트가 대신 협업할 수 있다면 조직 디지털화가 훨씬 쉬워짐. MCP는 이런 배선 복잡성을 숨겨줘서 좋음

  • Skill은 전체 문서를 컨텍스트에 넣어야 하는 context bloat 문제가 있음
    MCP도 비슷하지만, 도구 검색 기능으로 점진적 로딩이 가능함
    더 큰 문제는 MCP 출력이 바로 에이전트 컨텍스트로 들어간다는 점임. CLI를 통해 MCP 서비스를 호출하면 필터링이나 캐싱이 가능함

    • “그럴 거면 그냥 HTTP 요청 쓰면 되지 않냐”는 반응도 있었음
    • 글쓴이는 최신 MCP는 이미 도구 검색 기반 지연 로딩으로 해결했다고 설명함. Claude Code는 서브에이전트를 활용해 로그 폭주를 막음
    • 나는 로컬 MCP를 메모리 캐시로 감싸서 해결함. 각 도구 출력에 ID를 부여하고, 그 ID로 다른 도구를 호출함. 토큰 절약과 속도 향상에 효과적임

  • Skill은 직관적 지식을 담기에 좋고, MCP는 반복 가능한 자동화에 적합함
    LLM이 같은 스크립트를 여러 번 작성한다면, 그걸 도구로 고정하는 게 효율적임

    • 대부분의 프로세스는 스크립트로 전처리하고, LLM은 계획 수립과 검증에만 관여하면 됨
      즉, 가능한 한 많은 부분을 스크립트로 전처리하는 게 핵심임
    • 스크립트를 skill 안에 직접 포함할 수도 있음. skill은 코드도 담을 수 있음
    • 원문 작성자는 AI가 아니라 실제 사람이 비행 중에 쓴 글이라고 밝힘
    • 어떤 사람은 skill을 반복 작업에도 쓴다고 했고, 이에 대해 MCP의 API 계약 관점에서 설명이 이어짐
      작은 스크립트라면 그냥 컨텍스트에 넣고 “이걸 써라”라고 하면 충분함
답변달기