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

> Clean Markdown view of GeekNews topic #28404. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28404](https://news.hada.io/topic?id=28404)
- GeekNews Markdown: [https://news.hada.io/topic/28404.md](https://news.hada.io/topic/28404.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-11T09:50:47+09:00
- Updated: 2026-04-11T09:50:47+09:00
- Original source: [david.coffee](https://david.coffee/i-still-prefer-mcp-over-skills/)
- Points: 6
- Comments: 6

## Summary

Skills와 MCP를 **지식 계층 vs 연결 계층**으로 구분해야 한다는 주장입니다. Skills는 에이전트에게 절차적 지식을 가르치는 데 좋지만, CLI 의존성·인증·플랫폼 호환성에서 마찰이 크고, MCP는 Zero-Install·OAuth·샌드박싱으로 **어떤 환경에서든 동일하게 작동**하는 API 추상화라는 것이 핵심입니다. 요즘 Skills가 주목받고 있지만 MCP와 역할이 다르다는 시각이라, 이번 주 메인에서 다룬 스킬 공유 흐름과 함께 읽으면 **어디에 뭘 써야 하는지** 판단하는 데 도움이 됩니다.

## Topic Body

- **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 환경**을 유지할 수 있음

## Comments



### Comment 55094

- Author: jujumilk3
- Created: 2026-04-11T11:01:15+09:00
- Points: 2

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

### Comment 55095

- Author: xguru
- Created: 2026-04-11T11:18:22+09:00
- Points: 3
- Parent comment: 55094
- Depth: 1

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

### Comment 55103

- Author: jjw9512151
- Created: 2026-04-11T18:07:17+09:00
- Points: 1

Skills는 검술이고 mcp는 검입니다.. 용도가 다르고 둘다 필요하죠

### Comment 55097

- Author: ide127
- Created: 2026-04-11T14:05:14+09:00
- Points: 1

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

### Comment 55098

- Author: ide127
- Created: 2026-04-11T14:06:20+09:00
- Points: 1
- Parent comment: 55097
- Depth: 1

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

### Comment 55089

- Author: neo
- Created: 2026-04-11T09:50:48+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47712718) 
- 내가 강조하고 싶은 건 개인의 **선호**보다 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 계약** 관점에서 설명이 이어짐  
    작은 스크립트라면 그냥 컨텍스트에 넣고 “이걸 써라”라고 하면 충분함