MCP 쓰다가 Skills까지 써본 후 정리한 차이

MCP로 업무 자동화를 시작했다. 지금은 PR 작성, 지라 티켓, 위키 문서 작업 대부분을 Skills로 처리하고, MCP는 정말 필요할 때만 곁들인다.

두 개가 경쟁 관계인 줄 알았는데 실제로 써보니 아니었다. MCP는 도구를 연결하는 통로고, Skills는 반복되는 업무 절차 자체를 담아두는 지침이다. 이 글은 그 차이를 개념으로만 정리한 게 아니라, 실제로 어디서 갈렸는지를 기준으로 썼다.

 

 

MCP 이미 쓰는데 Skills를 왜 또 배워야 하나

MCP를 이미 쓰고 있어도, 정확성이 필요한 반복 업무에는 MCP만으로 부족해 Skills가 따로 필요하다.

PR 작성, 지라 티켓 작성, 위키 문서 작성. 이 세 가지가 내가 매일 반복하는 일이었다. MCP로 지라나 컨플루언스 같은 도구에 연결은 됐다. 문제는 그다음이었다.

연결만 되어 있다고 원하는 결과물이 나오는 게 아니었다. 매번 같은 톤, 같은 형식으로 문서를 쓰고 싶은데, MCP는 그 판단까지 해주지 않았다. 도구에 접근할 길을 열어줄 뿐, "이런 상황에서는 이렇게 써라"는 절차와 기준은 별도로 챙겨야 했다.

 

 

MCP만으로 부족했던 순간

특히 로직이 복잡하거나 요구사항이 애매한 작업에서 MCP는 힘을 못 썼다. 고려할 게 많고 정확성이 필요한 순간일수록 MCP 혼자로는 결과물이 들쭉날쭉했다. 이게 스킬 위주로 넘어온 결정적인 계기였다.

 

 

MCP와 Skills, 실제로 뭐가 다른가

MCP는 모델을 외부 도구·데이터에 연결하는 프로토콜이고, Skills는 반복 작업의 절차와 지식을 저장해두는 파일 기반 지침이다.

 

MCP — 도구를 연결하는 프로토콜

MCP(Model Context Protocol)는 Anthropic이 공개한 표준이다. 지라, 깃허브, 사내 위키 같은 외부 시스템에 접근할 길을 뚫어주는 "커넥터(connector)"라고 보면 된다.

다만 툴 정의가 늘어날수록 컨텍스트가 무거워지는 경향이 있다. 도구가 많아질수록 모델이 참고할 정보량이 늘고, 속도와 정확도에서 손해를 볼 여지가 커진다.

 

Skills — 절차와 지식을 담아두는 파일

Skills는 frontmatter(요약), 본문(지침), 필요하면 스크립트까지 포함하는 3단 구조의 파일이다. 평소엔 요약만 읽어두다가, 실제로 필요한 순간에만 본문과 스크립트를 불러온다. 이 방식을 점진적 노출(progressive disclosure)이라고 부른다.

 

Skills의 점진적 노출 구조를 나타낸 다이어그램 — frontmatter는 항상 로드되고 본문과 스크립트는 필요할 때만 불러온다

 

내가 만든 PR 작성 스킬도 구조는 단순하다. frontmatter에는 "PR 문구를 작성할 때 쓰는 스킬"이라는 요약만 적혀 있고, 본문에는 어떤 톤으로, 어떤 항목을 채워서 PR을 쓸지가 지침으로 들어가 있다.

 

직접 만든 PR 작성 스킬의 frontmatter 요약과 본문 지침이 나뉜 실제 파일 구조

 

항목	MCP	Skills
연결 대상	외부 도구·API·데이터	없음 (모델 내부 지침)
정의 위치	서버 스펙(프로토콜)	frontmatter + 본문 파일
실패 지점	복잡한 로직·정확성 요구 작업	외부 시스템 접근이 필요한 작업
적합한 작업	도구 연동, 데이터 조회	반복 절차, 톤·형식이 중요한 문서 작업

 

 

실제로 써보니 다른 지점 — MCP가 실패하는 순간

MCP는 도구를 '연결'해줄 뿐 로직이 복잡하고 정확성이 필요한 작업에서는 실패하기 쉽고, Skills로 전환한 뒤 문서 작성 시간이 10분에서 2~3분으로 줄었다.

 

"그저 통하는 게이트웨이" — MCP가 해결해주지 않는 것

MCP를 한동안 쓰면서 든 생각은 이거였다. MCP는 그저 통하는 게이트웨이일 뿐, 실제 문제 해결 자체를 빠르게 해주지는 않는다.

연결은 됐는데 결과물의 질은 별개였다. 고려사항이 많고 정확성이 요구되는 작업일수록 이 간극이 두드러졌다. 통로는 뚫려 있는데, 그 통로를 지나서 나오는 결과물을 다듬는 건 여전히 내 몫이었다.

 

Skills로 넘어오고 달라진 것

체감이 가장 컸던 건 문서 작성 시간이다. 예전엔 PR이나 위키 문서 하나 쓰는 데 10분 정도 걸렸는데, Skills로 넘어온 뒤로는 2~3분이면 끝난다. 하루에 이런 문서 작업을 4~5건 정도 처리하는 걸 감안하면 체감 차이가 꽤 크다.

 

PR 작성 스킬을 실행해 결과물이 실제로 출력된 화면

 

시간이 줄어든 것보다 더 중요하게 느낀 변화는 따로 있다. 매번 "이걸 어떻게 써야 하지"를 새로 고민하지 않아도 된다는 점이다. 판단을 이미 스킬 안에 넣어뒀으니, 그 고민 자체를 반복하지 않게 됐다.

물론 처음부터 믿고 맡긴 건 아니었다. PR 작성 스킬은 세 번째 정도 써본 뒤부터 결과물을 믿게 됐다. 그전까지는 원하는 톤과 문구가 나올 때까지 지시문을 계속 가다듬는 과정이 필요했다. 오해하지 않았으면 한다. 스킬이 오류를 낸 걸 고친 게 아니라, 원하는 톤이 나올 때까지 반복해서 다듬은 것이다.

 

 

실무에서 이렇게 조합해 쓴다 — PR·지라·위키 스킬 + MCP 3개 연결

PR·지라 티켓·위키 작성은 Skills로, 그 외 도구 연동은 MCP 서버 3개만 최소로 연결해 병행하는 게 실무에서 검증한 조합이다.

지금 업무 환경은 Claude Code와 ChatGPT를 섞어서 쓴다. 반복 문서 작업은 Skills로 처리하고, 외부 도구에 접근해야 할 때는 MCP를 함께 쓴다. 둘을 완전히 분리하기보다는 각자 잘하는 영역에 맡기는 쪽이다.

 

 

왜 3개만 연결하는가

MCP 서버는 보통 3개 정도만 연결해서 운영한다. 정직하게 밝혀두면, 서버를 여러 개 연결했다가 느려져서 줄인 시행착오는 아니다. "MCP를 너무 많이 연결하면 컨텍스트를 잡아먹는다"는 권고를 미리 참고해서, 처음부터 딱 필요한 것만 골라 연결해온 것이다.

 

MCP 서버 3개를 연결해 운영 중인 실제 설정 화면

 

frontmatter가 잘못 로드돼 스킬이 안 먹힌 경험도 아직까지는 없다.

큰 작업은 서브에이전트를 여러 개 붙여서 나눠 처리하는 방식도 있지만, PR·지라·위키 규모의 반복 업무에서는 Skills 하나로 충분했다.

이 글 작성 시점(2026년 8월) 기준으로 정리하면, MCP 서버 3개 연결 + Skills 중심 운영이 지금 내 워크플로다. 이 비율이나 로딩 방식은 앞으로 바뀔 수 있는 부분이라 그때그때 다시 확인할 여지를 남겨둔다.

 

 

그래서 MCP는 필요 없나 — 평판을 건 판단

MCP가 아예 필요 없다고 단정할 수는 없지만, 에이전트를 실무에 쓴다면 Skills가 먼저고 MCP는 필요할 때만 보조로 쓰는 게 낫다.

직접 써본 입장에서 솔직히 말하면, MCP는 굳이 필요 없을지도 모른다는 쪽으로 기운다. 반면 Skills는 에이전트를 실무에 쓰는 이상 필수라고 본다. 둘 중 하나만 고르라면 나는 Skills를 고른다.

물론 MCP를 먼저 깊게 써본 사람이나 얼리어답터 입장에서는 다르게 볼 수 있다. 외부 시스템 연동이 핵심인 워크플로라면 MCP가 여전히 중심일 수 있다. 다만 내가 겪은 범위 안에서는, 정확성이 필요한 반복 업무일수록 Skills 쪽이 먼저 손이 갔다.

 

 

지금 시작한다면 뭐부터 — 첫 Skill 만드는 법

Skills는 frontmatter에 요약을, 본문에 지침을 적는 것부터 시작하면 되고, 비개발자도 마크다운 파일 하나로 첫 스킬을 만들 수 있다.

 

frontmatter부터 시작하기

거창하게 시작할 필요는 없다. frontmatter에 이 스킬이 뭘 하는지 한두 줄로 요약을 적고, 본문에 실제로 어떤 절차·톤·형식을 따를지 지침을 풀어 쓰면 그게 첫 스킬이다. 코드를 다룰 필요가 없는 문서 작업(PR 문구, 티켓 양식, 위키 포맷)일수록 진입장벽이 낮다.

처음부터 완벽하게 쓸 필요도 없다. 결과물이 마음에 안 들면 지침 문장을 조금씩 고쳐가면서 원하는 톤에 맞춰가면 된다. 나도 지금 쓰는 스킬들이 처음 버전 그대로는 아니다.

 

 

자주 묻는 질문

 

Skills와 서브에이전트는 뭐가 다른가?

서브에이전트는 큰 작업을 여러 에이전트로 나눠 처리하는 방식이고, Skills는 반복되는 절차 하나를 지침 파일로 담아두는 것이다. PR·지라 티켓처럼 정해진 업무엔 서브에이전트 없이 Skills 하나로 충분했다.

 

Skills는 클로드에서만 쓸 수 있나?

Skills는 Anthropic이 공개한 클로드 전용 시스템이라, 나도 클로드 코드에서만 쓰고 있고 같이 쓰는 ChatGPT 쪽 작업에는 적용하지 않는다.

 

참고 자료

1. Anthropic, Introducing the Model Context Protocol — MCP가 Anthropic이 공개한 개방형 프로토콜이라는 정의의 출처.
2. Anthropic Engineering, Code execution with MCP — 연결된 툴 정의가 늘어날수록 컨텍스트 사용량이 커진다는 설명의 출처.
3. Anthropic, Agent Skills — Claude Platform Docs — Skills의 frontmatter·본문·번들 리소스 3단 구조와 점진적 노출(progressive disclosure) 정의의 출처.