어떤 팀은 AI 에이전트에게 도구를 잔뜩 붙여 놓고도 실망한다. GitHub도 연결했고, Notion도 연결했고, 데이터베이스도 열어 줬는데 결과물이 들쭉날쭉하기 때문이다. 반대로 어떤 팀은 지침 문서를 아주 정성껏 써 놓고도 답답해한다. 절차는 완벽한데, 정작 실시간 데이터에 접근하지 못해 마지막 한 걸음에서 멈추기 때문이다.
이때 필요한 것은 더 많은 기능이 아니다. 역할 분리다. Skill과 MCP를 같은 상자에 넣어 생각하면 설계가 금방 복잡해진다. 하지만 Skill은 어떻게 할지를 가르치고, MCP는 어디에 연결할지를 제공한다고 나누는 순간 구조가 단순해진다. Anthropic도 이 관계를 아주 명확하게 설명한다. MCP는 외부 도구와 시스템 연결을 맡고, Skill은 그 연결을 팀의 워크플로에 맞게 쓰는 방법을 가르친다.1
이 구분은 생각보다 강력하다. 절차와 연결을 분리하면, 회사의 일하는 방식은 Skill에 남기고 시스템 접근은 MCP에 맡길 수 있다. ERP를 바꾸거나 Notion을 Confluence로 옮겨도 업무 절차 전체를 갈아엎지 않아도 되는 이유가 여기서 나온다.
Skill은 레시피이고, MCP는 주방 설비다
가장 쉬운 비유는 요리다. Skill은 레시피다. 어떤 재료를 먼저 준비하고, 어느 단계에서 불을 줄이고, 실패하면 어떻게 복구하는지를 알려 준다. 반면 MCP는 냉장고, 오븐, 칼, 계량기 같은 설비다. 재료에 접근하고 실제 동작을 수행하게 해 준다.12
레시피만 있어서는 요리가 완성되지 않는다. 냉장고를 열 수 없고 칼을 쓸 수 없기 때문이다. 그렇다고 설비만 있다고 요리가 저절로 되지도 않는다. 오븐은 있는데 언제 예열해야 하는지, 어떤 순서로 구워야 하는지 모르면 결과는 매번 달라진다.
실무에서도 똑같다. 예를 들어 "주간 영업 리포트를 작성하라"는 업무를 생각해 보자. 지난주 매출을 어디서 읽을지, 담당자 메모를 어디서 찾을지, 수치가 비정상일 때 누구 확인을 받을지, 최종 문서를 어떤 형식으로 써야 할지는 Skill이 정의해야 한다. 하지만 실제로 CRM에서 데이터를 읽고, 슬랙에서 최근 대화를 찾고, 문서 시스템에 결과를 저장하는 일은 MCP가 맡는다.
이렇게 나누면 판단이 빨라진다. 지금 설계하려는 것이 지식인가, 연결인가. 절차인가, 접근 권한인가. 레시피인가, 설비인가. 이 질문만 잘 던져도 반은 끝난다.
언제 MCP가 필요한가
모든 업무에 MCP가 필요한 것은 아니다. 이미 에이전트가 기본으로 가진 파일 읽기나 웹 검색만으로 충분한 경우도 있다. MCP가 필요한 순간은 대체로 세 가지다.
첫째, 실시간 외부 데이터가 필요할 때다. 데이터베이스 조회, 최신 주문 상태 확인, 오늘의 재고 수량 확인처럼 대화 바깥의 현재 상태를 읽어야 한다면 텍스트 지침만으로는 해결되지 않는다.
둘째, 외부 시스템에 행동을 일으켜야 할 때다. 이슈 생성, 캘린더 일정 등록, 슬랙 메시지 전송, SaaS 문서 업데이트처럼 실제 변경이 일어나는 작업은 연결 계층이 필요하다.
셋째, 인증과 권한 경계를 분리해야 할 때다. 데이터베이스 비밀번호나 SaaS 토큰을 Skill 문서에 적어 둘 수는 없다. 이런 민감한 연결 정보는 MCP 서버 쪽에서 관리하고, 에이전트에는 제한된 도구 인터페이스만 노출하는 편이 안전하다.2
조금 더 현실적으로 나눠 보자.
로컬 파일에서의 경계
프로젝트 안의 코딩 규칙, 템플릿, 브랜드 가이드처럼 정적인 자료는 대개 Skill 폴더 안의 references/나 assets/로 충분하다. 이런 것은 연결 문제가 아니라 지식 문제다.
하지만 여러 디렉터리에 흩어진 문서를 탐색하거나, 접근 가능한 경로를 제한하면서 읽기·쓰기 권한을 제어해야 한다면 파일시스템 MCP가 유리해진다. 특히 로컬 파일 접근 범위를 안전하게 제한해야 하는 팀 환경에서는 MCP가 단순 편의 기능이 아니라 신뢰 경계가 된다.
다만 여기서 흔한 실수가 있다. 단지 파일 몇 개를 읽는다는 이유만으로 무조건 MCP를 붙이는 것이다. 이미 에이전트 환경에 적절한 파일 접근 도구가 있고 권한 문제도 없다면, 굳이 새 MCP를 만들 필요는 없다. 설비가 필요한지부터 따져야지, 설비를 먼저 만들고 나서 쓸 곳을 찾으면 안 된다.
데이터베이스에서의 경계
데이터베이스는 MCP가 특히 빛나는 영역이다. Skill은 "어떤 테이블을 먼저 확인하고, 이상치가 보이면 무엇을 의심하며, 합계가 맞지 않으면 어느 기준으로 재검산할지"를 정의한다. 반면 MCP는 승인된 쿼리 도구, 읽기 전용 접근, 결과 스키마 같은 실행 연결을 담당한다.2
이 구분이 중요한 이유는 데이터베이스 업무가 대부분 고위험이기 때문이다. SQL을 직접 프롬프트 안에서 설명하며 처리하려 하면, 지침과 실행 권한이 한 덩어리가 된다. 그러면 쿼리 문법이 바뀔 때 Skill도 흔들리고, 권한 정책이 바뀔 때 문서도 함께 고쳐야 한다. 반대로 MCP가 읽기 전용 쿼리 도구를 제공하고, Skill이 "항상 요약 전에 원본 행 수를 검증하라" 같은 절차를 가르치면 구조가 훨씬 안정적이다.
SaaS 연결에서의 경계
GitHub, Notion, Slack, Google Drive, 캘린더, CRM 같은 SaaS는 대부분 MCP와 잘 맞는다. 최신 상태를 읽고, API를 호출하고, 인증을 관리해야 하기 때문이다. Skill은 여기서 "무엇을 먼저 찾을지", "어떤 순서로 교차 확인할지", "어떤 형식으로 결과를 낼지"를 담당한다.
예를 들어 회의 준비 Skill을 만든다고 해 보자. Notion에서 프로젝트 페이지를 찾고, 이전 회의록을 읽고, 이해관계자 메모를 모아 사전 브리프를 만드는 절차는 Skill이 정의한다. 실제 Notion 검색과 문서 읽기, 새 페이지 생성은 MCP가 담당한다. 이 조합이 바로 가장 실전적인 형태다.1
Skill 안에서 MCP 호출 순서를 어떻게 문서화할까
많은 팀이 여기서 한 번 꼬인다. MCP를 붙인 뒤에 Skill에 "필요하면 적절히 사용하라" 정도만 적어 두는 것이다. 그러면 에이전트는 도구는 많지만, 어느 순간에 무엇을 먼저 해야 하는지 스스로 추측해야 한다. 이때부터 결과가 흔들린다.
좋은 Skill은 MCP를 단순히 나열하지 않는다. 호출 순서와 판단 기준까지 적는다. 가장 실용적인 문서화 방식은 다음 다섯 덩어리로 나누는 것이다.
어떤 MCP 도구가 필요한지 적는 전제 조건
어떤 상황에서 어떤 도구를 쓰는지 적는 선택 기준
어떤 순서로 호출하는지 적는 실행 단계
실패했을 때 무엇으로 우회하는지 적는 대체 경로
쓰기 작업 전에 누구 확인을 받을지 적는 승인 규칙
예를 들어 SKILL.md의 일부를 이렇게 쓸 수 있다.
## Prerequisites
- MCP servers: github, filesystem, slack
- GitHub는 PR 읽기/코멘트 작성 권한만 허용
- Slack은 #eng-reviews 채널 메시지 전송만 허용
## Workflow
1. GitHub MCP로 PR 변경 파일과 설명을 읽는다.
2. filesystem 또는 내장 도구로 관련 테스트 파일을 확인한다.
3. 테스트가 없으면 "테스트 누락" 항목을 우선순위 높음으로 기록한다.
4. 보안 관련 파일이 바뀌었으면 GitHub MCP로 관련 설정 파일을 추가 조회한다.
5. 리뷰 초안을 만든 뒤, 실제 PR 코멘트 작성 전에는 사용자 승인 여부를 확인한다.
## Fallback
- GitHub MCP 호출 실패 시 PR 링크와 변경 파일 목록을 사용자에게 요청한다.
- Slack 전송 실패 시 본문 끝에 공유용 요약 블록을 추가하고 전송은 생략한다.
## Approval Gate
- 외부 시스템에 쓰기 작업을 수행하기 전에는 항상 승인받는다.
- 승인 없이는 코멘트 작성, 상태 변경, 메시지 전송을 하지 않는다.이 문서의 핵심은 멋진 문장이 아니다. 에이전트가 망설이지 않게 만드는 것이다. "어떤 도구가 있나"보다 "언제 무엇을 먼저 쓰나"가 훨씬 중요하다.
잘 작동하는 Skill + MCP 조합 패턴
실전에서 자주 통하는 패턴은 생각보다 단순하다.
첫 번째는 하나의 Skill이 여러 MCP를 오케스트레이션하는 패턴이다. 예를 들어 리서치 Skill 하나가 웹 검색, 사내 문서, CRM, 슬라이드 저장 도구를 순서대로 묶는다. 사용자는 하나의 업무를 요청했지만, Skill은 여러 연결점을 질서 있게 사용한다. Anthropic도 바로 이 점을 Skills와 MCP의 결합 강점으로 설명한다.1
두 번째는 하나의 MCP를 여러 Skill이 공유하는 패턴이다. 같은 GitHub MCP를 코드 리뷰 Skill, 릴리스 노트 Skill, 버그 재현 Skill이 함께 쓸 수 있다. 연결은 재사용하고, 절차만 업무별로 다르게 가져가는 방식이다. 이 구조가 관리에 강하다. GitHub 인증 방식이 바뀌어도 세 Skill의 본문을 전부 고칠 필요가 줄어든다.
세 번째는 읽기와 쓰기를 분리하는 패턴이다. 먼저 읽기 전용 단계에서 정보를 모으고 검증한 뒤, 마지막에만 쓰기 권한 도구를 호출한다. 이 패턴은 안전성과 일관성 둘 다 챙긴다. 특히 외부 시스템을 바꾸는 작업에서는 거의 기본 습관처럼 가져가야 한다.
네 번째는 검증 후 실행 패턴이다. 데이터베이스 수치를 읽고 바로 보고서를 쓰는 대신, 먼저 행 수 확인, 기간 확인, 단위 확인을 거친 뒤 결과를 내게 한다. Skill은 검증 체크리스트를 맡고, MCP는 실제 조회를 맡는다. 이 조합은 데이터 분석, 재무 리포트, 운영 리포트에서 매우 강력하다.
다섯 번째는 사람 승인 포함 패턴이다. 초안 작성과 근거 수집은 자동으로 하되, 발송·수정·삭제 같은 외부 영향이 큰 작업은 마지막에 사람 확인을 받는다. 자동화의 속도를 살리면서도 사고를 크게 줄이는 방식이다.
흔한 설계 실수는 대부분 경계가 흐릴 때 생긴다
Skill과 MCP를 함께 쓸 때 실패는 보통 기술 부족 때문이 아니다. 경계가 흐려졌기 때문이다.
가장 흔한 실수는 규칙을 MCP로 만들려는 것이다. "우리 팀은 PR 설명을 이렇게 쓴다", "번역 품질 기준은 이렇다", "코드 리뷰에서 이 항목을 본다" 같은 내용은 Skill에 넣어야 한다. 이것은 연결 문제가 아니라 팀 지식이기 때문이다. 이런 정적 지식을 굳이 서버 프로세스로 만들면 운영 비용만 늘고, 수정도 느려진다.3
그 반대 실수도 많다. 외부 API 작업을 Skill 안의 자연어로만 처리하려는 것이다. "DeepL API를 호출해서 번역한다", "슬랙에 메시지를 보낸다", "데이터베이스에서 최신 주문을 조회한다" 같은 일은 실제 연결 계층이 필요하다. Skill에 장황한 설명을 써 넣는다고 실행 능력이 생기지는 않는다.3
또 다른 실수는 Skill이 특정 MCP 도구 이름에 과하게 결합되는 것이다. 예를 들어 본문 전체가 특정 서버의 내부 도구명과 파라미터 구조에 지나치게 매여 있으면, 나중에 서버를 교체하기 어렵다. Skill에서는 가능하면 도구의 역할을 중심으로 설명하고, 서버별 세부 호출 규칙은 필요한 범위로만 제한하는 편이 좋다. 절차는 남기고 구현 세부는 덜어내야 이식성이 생긴다.
마지막으로 자주 놓치는 것이 대체 경로 부재다. MCP는 결국 외부 연결이다. 장애가 난다. 인증이 만료된다. 응답이 느려진다. 그런데도 많은 Skill은 실패를 전혀 가정하지 않는다. 이건 비 오는 날 우산 없이 나가는 것과 비슷하다. 젖지 않을 수도 있지만, 설계라고 부르기 어렵다.
MCP 장애가 났을 때는 어떻게 설계해야 하나
실무에서는 "정상 작동"보다 "실패했을 때 어떻게 덜 망가질 것인가"가 더 중요하다. MCP 장애 대응은 네 단계로 설계하면 좋다.
첫째, 재시도 가능한 실패인지 먼저 구분한다. 일시적 타임아웃이면 짧은 재시도로 복구할 수 있다. 이 경우 Skill에 재시도 횟수와 간격을 적어 두면 된다.
둘째, 읽기 전용 축소 모드로 전환할 수 있는지 본다. 예를 들어 문서 저장 MCP가 죽었더라도 초안 생성과 검토까지는 계속할 수 있다. 이 경우 최종 저장만 생략하고 결과를 본문에 남기면 된다.
셋째, 대체 입력 경로를 둔다. GitHub MCP가 실패하면 PR 링크와 diff를 사용자에게 직접 받게 하거나, 데이터베이스 MCP가 안 되면 CSV 내보내기 파일을 업로드하게 하는 식이다. 자동 연결이 끊겨도 업무 자체가 완전히 멈추지 않게 하는 장치다.
넷째, 사람 승인 경로를 명시한다. 예를 들어 슬랙 전송 MCP가 실패했는데도 보고는 오늘 안에 되어야 한다면, "전송 실패 사실과 요약본을 사용자에게 제시하고 직접 전송 여부를 확인받는다" 같은 규칙이 필요하다. 외부 행동이 필요한 순간일수록 승인 문구는 구체적이어야 한다.
이 네 단계를 Skill 안에서 문장으로 남겨 두면, 장애 상황에서도 에이전트가 엉뚱하게 굴 가능성이 크게 줄어든다.
사람 승인 경로는 마지막 장식이 아니라 핵심 구조다
많은 자동화 설계가 "되면 좋고, 안 되면 사람에게 물어보자" 수준에서 끝난다. 하지만 승인 경로는 부록이 아니라 본문이다. 특히 MCP가 쓰기 권한을 가진 순간부터는 더 그렇다.
승인이 필요한 작업은 대체로 세 부류다.
외부 시스템 상태를 변경하는 작업
금전, 일정, 고객 커뮤니케이션처럼 영향 범위가 큰 작업
민감정보가 포함되거나 규정 위반 위험이 있는 작업
이 경우 Skill에는 최소한 세 가지를 적어 두는 편이 좋다. 무엇을 하려는지, 어떤 근거로 그렇게 판단했는지, 승인하지 않으면 무엇이 생략되는지다. 사용자는 "승인하시겠습니까?"보다 "현재 재고 0개가 확인되었고, 구매 요청 메일 초안을 준비했습니다. 실제 발송 전에 승인해 주세요. 승인하지 않으면 초안만 저장합니다."라는 문장을 훨씬 신뢰한다.
승인 설계를 잘하면 자동화는 더 느려지는 것이 아니라 더 넓어진다. 위험한 단계를 사람에게 맡길 수 있기 때문에, 나머지 단계는 오히려 자신 있게 자동화할 수 있기 때문이다.
설계를 단순하게 만드는 질문들
Skill과 MCP의 경계가 헷갈릴 때는 복잡한 이론보다 다음 질문이 더 유용하다.
이것은 팀의 일하는 방식인가, 외부 시스템 접근인가?
이 내용은 문서로 자주 수정될 것인가, 서버로 안정 운영되어야 하는가?
실시간 데이터가 없으면 성립하지 않는가?
인증, 권한, 감사 로그가 중요한가?
실패했을 때 읽기 전용으로라도 계속할 수 있는가?
실제 변경 전에 사람 승인이 필요한가?
앞의 두세 질문에 "업무 방식, 문서, 절차"가 많이 걸리면 Skill 쪽이다. "실시간 데이터, 인증, 외부 변경"이 많으면 MCP 쪽이다. 둘 다 걸리면 십중팔구 함께 써야 한다.
결국 좋은 구조는 절차와 연결을 분리한다
실전에서 Skill과 MCP는 경쟁하지 않는다. 서로 다른 문제를 푼다. Skill은 에이전트가 일을 어떤 순서와 기준으로 수행할지를 고정한다. MCP는 에이전트가 어떤 시스템에 닿아 실제 데이터를 읽고 행동할 수 있을지를 제공한다.12
이 둘을 섞지 않으면 설계가 단순해진다. 업무 절차는 Skill에 남고, 시스템 연결은 MCP에 남는다. 팀의 노하우는 문서와 스크립트로 축적되고, 인증과 권한은 연결 계층에서 통제된다. 도구가 바뀌어도 절차 자산이 남고, 절차가 바뀌어도 연결 구조는 재사용된다.
한마디로 정리하면 이렇다. 절차는 Skill, 연결은 MCP, 영향이 큰 실행은 승인 경로까지 설계하라. 이 문장만 붙잡아도 에이전트 설계는 훨씬 덜 헷갈린다. 그리고 바로 그 단순함이, AI를 신기한 도우미에서 믿고 맡길 수 있는 실행 시스템으로 바꾸는 출발점이 된다.
참고
1Extending Claude's capabilities with skills and MCP servers
2AI Skills vs MCP: The Critical Differencein AI Agent Extension
3MCP vs Skills: Fundamental Differences and Selection Criteria
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.