4부·17장 MCP 서버와 스킬의 결합

스킬을 배웠다면 이제 이런 생각이 들기 시작한다. "좋아, 에이전트한테 일하는 법은 가르쳤다. 그런데 Notion, Linear, GitHub, 사내 문서함 같은 진짜 업무 시스템은 어떻게 더 안정적으로 붙이지?" 바로 여기서 MCP가 등장한다.

핵심은 어렵지 않다. 스킬은 일의 순서와 판단 기준을 적는 문서이고, MCP 서버는 외부 서비스에 손을 뻗게 해 주는 표준 연결층이다. 스킬만 있으면 에이전트는 똑똑한 매뉴얼을 읽는 비서가 된다. MCP만 있으면 도구가 많은 작업대 앞에 선다. 둘을 결합하면 비로소 "무엇을, 어떤 순서로, 어디까지" 해도 되는지 아는 실무자가 된다.¹²

스킬만으로는 버거워지는 순간

초반에는 스킬만으로도 많은 일을 할 수 있다. 예를 들어 curl로 Notion API를 호출하게 하거나, 웹 요청과 셸 명령을 섞어 간단한 자동화를 만들 수 있다. 빠르게 프로토타입을 만드는 데는 이 방식이 꽤 유용하다.

하지만 반복해서 쓰기 시작하면 금세 삐걱거린다. 인증 헤더를 매번 챙겨야 하고, 페이지 구조나 필드 이름이 바뀌면 스킬 본문을 다시 고쳐야 하며, 검색·조회·생성·수정이 섞일수록 지시문이 뚱뚱해진다. 특히 Notion이나 Linear처럼 데이터 구조가 분명한 SaaS는 "API를 어떻게 부를까"보다 "언제 어떤 도구를 어떤 순서로 쓸까"가 더 중요한데, 이 둘을 한 파일에 욱여넣으면 유지보수가 급격히 어려워진다.¹⁴

그래서 역할을 나누는 편이 낫다.

• MCP 서버는 인증, 연결, 도구 스키마, 응답 형식을 맡는다.

• 스킬은 어떤 상황에서 그 도구를 써야 하는지 결정한다.

• 에이전트는 그 위에서 실제 문맥 판단과 실행을 맡는다.

비유하면 MCP는 공구함이고, 스킬은 작업 매뉴얼이다. 공구함만 있으면 망치도 드라이버도 많지만 순서가 없다. 매뉴얼만 있으면 순서는 훌륭하지만 손에 공구가 없다. 둘이 붙어야 책상 위 보고서가 실제 Notion 페이지가 되고, 텔레그램 메시지가 실제 Linear 이슈가 된다.

MCP만 붙여도 충분할까

여기서 많은 사람이 한 번 더 헷갈린다. "MCP 서버만 연결하면 되는 것 아닌가?" 반은 맞고, 반은 틀리다.

MCP 서버만 연결해도 에이전트는 외부 도구를 볼 수 있다. 파일을 읽고, 이슈를 만들고, 문서를 검색할 수 있다. 탐색이나 실험 단계에서는 이것만으로도 꽤 강력하다. 하지만 업무가 반복되면 문제가 생긴다. 도구는 많아졌는데, 에이전트가 어떤 때 어떤 도구를 우선 써야 하는지 기준이 흐려지기 때문이다. 커뮤니티 글들에서도 요즘 활성 스킬의 큰 비중이 실제로는 밑단의 MCP 서버를 감싸는 형태라고 설명한다. 이유는 단순하다. MCP가 능력을 주고, 스킬이 습관을 만든다는 점이 현장에서 더 잘 먹히기 때문이다.²

판단 기준은 이렇게 잡으면 쉽다.

• 로컬 파일, 셸, 운영체제 제어처럼 호스트와 밀착된 작업은 네이티브 스킬이 더 낫다.

• 여러 AI 클라이언트에서 재사용할 데이터 연결은 MCP 서버가 더 낫다.

• 반복 업무를 안정적으로 굴릴 때는 MCP 서버를 스킬로 감싸는 하이브리드가 가장 강하다.¹

한마디로 줄이면 이렇다. MCP만 쓰면 만능 리모컨이고, 스킬까지 얹으면 자주 누르는 버튼에 이름표를 붙인 셈이다.

OpenClaw에서 결합되는 최소 구조

OpenClaw는 바깥의 MCP 서버를 등록해 두고, 실행 시 그것을 도구 표면으로 불러올 수 있다. 공식 문서 기준으로는 openclaw mcp set, list, show, unset 명령으로 OpenClaw가 사용할 outbound MCP 서버 정의를 관리한다. 전송 방식도 로컬 하위 프로세스를 띄우는 stdio, 원격 서버에 붙는 SSE와 streamable-http를 지원한다.³

혼자 쓰는 환경이라면 대개 stdio가 가장 단순하고 안정적이다. 같은 머신에서 프로세스를 띄우고 표준 입출력으로 통신하니, 네트워크 문제와 인증 계층이 줄어든다. 반대로 여러 에이전트나 여러 사용자가 하나의 원격 MCP 서버를 공유해야 한다면 HTTP 계열 전송이 낫다. 그때는 인증 헤더, 타임아웃, 접근 제어까지 함께 설계해야 한다.³

예를 들어 Notion용 MCP 서버를 등록한다면 흐름은 보통 이렇다.

openclaw mcp set notion '{"command":"npx","args":["-y","@notionhq/mcp-server"],"env":{"NOTION_API_KEY":"${NOTION_API_KEY}"}}'
openclaw mcp list

중요한 포인트는 딱 하나다. 비밀값을 설정 파일에 박아 넣지 말고 환경 변수로 주입하라는 것이다. 토큰은 언젠가 백업되고, 복사되고, 로그에 스친다. 비밀을 글자로 남기지 않는 습관이 장기 운영에서 차이를 만든다.³⁴

그 다음 스킬에서는 이런 결정을 적는다. "사용자가 회의록을 정리해 달라고 하면 Notion에서 관련 페이지를 먼저 찾고, 없으면 새 페이지를 만들고, 본문은 한국어 제목 규칙에 맞게 정리하고, 쓰기 전에는 어떤 데이터베이스에 넣을지 한 번 확인할 것." 도구 호출 자체는 MCP가 맡고, 스킬은 절차와 가드레일을 맡는다.

패턴 1: Notion — 문서는 MCP가 읽고, 스킬은 문서화 습관을 강제한다

Notion은 MCP와 스킬의 결합 효과가 아주 잘 보이는 사례다. 이유는 Notion이 단순 메모장이 아니기 때문이다. 페이지, 블록, 데이터베이스, 속성, 권한 공유, 부모-자식 관계가 다 따로 있다. 게다가 API는 페이지 접근 권한을 별도로 공유해야 하고, 블록 구조가 계층형이라 읽기와 쓰기 전략이 생각보다 중요하다. 요청 제한도 있어 무작정 긁어오거나 반복 호출하면 금방 느려진다.⁶

그래서 Notion 연동은 "연결했다"보다 "운영 규칙을 정했다"가 더 중요하다.

좋은 패턴은 대체로 이렇다.

첫째, MCP 서버는 검색, 페이지 읽기, 블록 추가, 데이터베이스 조회 같은 기본 능력을 제공한다.

둘째, 스킬은 문서 작성 습관을 결정한다. 예를 들어 회의록이라면 제목 규칙, 날짜 표기, 담당자 섹션, 액션 아이템 형식을 고정해 둔다.

셋째, 에이전트는 사용자의 요청을 받아 기존 페이지를 업데이트할지, 새 문서를 만들지, 아니면 초안만 만들고 멈출지를 판단한다.

이 구조가 좋은 이유는 문서형 SaaS에서 가장 비싼 실수가 대개 "잘못 만든 한 장"이기 때문이다. 페이지가 중복 생성되거나, 같은 회의록이 세 군데 흩어지거나, 데이터베이스 필드가 어설프게 채워지면 나중에 사람이 수습하느라 더 오래 걸린다. 스킬이 그 혼란을 막아 준다.

예를 들어 "오늘 고객 인터뷰 내용을 Notion에 정리해 줘"라는 요청이 들어왔다고 해 보자. 잘 설계된 스킬은 바로 쓰지 않는다. 먼저 관련 인터뷰 데이터베이스나 프로젝트 페이지를 찾고, 비슷한 제목의 문서가 있는지 확인하고, 있으면 append 중심으로 업데이트하고, 없으면 정해 둔 템플릿대로 새 페이지를 만든다. 마지막에는 "생성 위치, 제목, 추가한 블록 수"처럼 사람이 검토하기 쉬운 짧은 보고만 남긴다. 이 작은 차이가 누적되면 Notion이 잡동사니 창고가 아니라 진짜 작업 기록 시스템이 된다.

패턴 2: Linear — 티켓은 도구로 만들고, 우선순위는 스킬이 정한다

Linear도 비슷하다. MCP 서버만 있으면 이슈 생성, 조회, 상태 변경, 담당자 확인 같은 동작은 할 수 있다. 하지만 실무에서 중요한 건 버튼 클릭이 아니다. 무엇을 이슈로 승격할지, 어떤 팀에 넣을지, 즉시 발행할지 초안으로 둘지가 더 중요하다.

특히 솔로 창업가나 작은 팀에서는 문제가 자주 생긴다. 텔레그램으로 떠오른 생각을 던졌더니 에이전트가 매번 새 이슈를 만들어 버리는 것이다. 나중에 보면 비슷한 카드가 열 장 쌓여 있다. 에이전트가 일을 안 한 게 아니다. 일을 너무 성실하게 해서 문제다.

그래서 Linear 앞에는 스킬이 하나 끼어드는 편이 좋다. 개발자 워크플로를 다룬 사례들에서도 GitHub, Linear, Notion을 함께 묶어 다루는 패턴이 자주 등장한다.⁵

이때 스킬이 맡기 좋은 규칙은 이런 것들이다.

• 단순 메모는 Linear 이슈로 만들지 말고 임시 메모로 남긴다.

• 기존 이슈와 유사한 제목이 있으면 먼저 검색한다.

• 버그, 개선, 조사 요청을 구분해서 다른 템플릿을 쓴다.

• 사용자가 "지금 바로 등록"이라고 말하지 않았다면 초안 요약만 먼저 보여 준다.

이렇게 해 두면 Linear MCP 서버는 CRUD 엔진으로 조용히 일하고, 스킬은 일의 분류기 역할을 한다. 결국 사람은 "이걸 티켓으로 올릴 만한가?"만 판단하면 되고, 나머지 필드 매핑과 서식 정리는 에이전트가 맡는다.

한국어 환경에서는 이 방식이 더 유리하다. 사용자는 "이거 로그인 깨지는 것 같은데 내일 전에 확인 필요"처럼 말하고, 스킬은 그 문장을 severity, priority, assignee, project, due date 같은 구조화된 필드로 번역한다. 영어 중심 SaaS의 딱딱한 입력 칸과 한국어 메신저 대화 사이를 스킬이 통역해 주는 셈이다.

패턴 3: 문서 SaaS와 업무 SaaS를 엮는 허브 패턴

MCP의 진짜 매력은 단일 앱 연결이 아니라 교차 앱 워크플로에 있다. GitHub만 붙였을 때보다 GitHub와 Notion을 함께 붙였을 때, Linear만 붙였을 때보다 Linear와 Slack, Telegram, 캘린더를 엮었을 때 체감이 훨씬 커진다. MCP는 도구를 같은 규격으로 노출하고, 스킬은 그 도구들을 하나의 흐름으로 묶는다.⁴

예를 들어 이런 흐름이 가능해진다.

• GitHub에서 이번 주 열린 버그 이슈를 찾는다.

• Linear에서 이미 연결된 티켓이 있는지 확인한다.

• 없으면 새 티켓을 만들고 우선순위를 초안으로 제안한다.

• Notion에는 주간 이슈 브리핑 문서를 만든다.

• 마지막으로 텔레그램으로 "검토할 초안 3건"만 짧게 보낸다.

이 패턴이 중요한 이유는 에이전트가 더 이상 앱 하나의 조수가 아니게 되기 때문이다. 문서형 SaaS, 작업형 SaaS, 메신저형 인터페이스 사이를 왕복하며 맥락을 이어 붙이는 운영자에 가까워진다.

MCP가 도구뿐 아니라 리소스와 프롬프트 같은 표면도 노출할 수 있다는 점도 여기서 빛난다. 문서를 읽는 SaaS는 리소스 중심으로, 티켓이나 캘린더를 조작하는 SaaS는 도구 중심으로 연결해도, 에이전트 입장에서는 같은 대화 안에서 자연스럽게 섞어 쓸 수 있다.⁴

많이 연결할수록 좋은 것은 아니다

여기서 욕심이 올라온다. "좋아, Notion도 되고 Linear도 되네? 그럼 Slack, Jira, HubSpot, Stripe, Google Drive, 사내 DB까지 한 번에 다 붙이자." 이 순간부터 도구는 늘어나는데 자동화는 오히려 흐려질 수 있다.

도구가 많아질수록 생기는 문제는 세 가지다.

• 에이전트가 어떤 도구를 먼저 써야 할지 선택 비용이 커진다.

• 비슷한 기능의 도구가 겹치면 잘못된 호출이 늘어난다.

• 권한과 인증 관리가 복잡해져 운영 리스크가 커진다.

그래서 처음에는 "앱 수"가 아니라 "반복 흐름 수"를 기준으로 설계하는 편이 좋다. 예를 들어 고객 미팅 메모 → Notion 정리, 텔레그램 아이디어 → Linear 초안, GitHub PR 상태 → 아침 브리핑처럼 딱 세 흐름만 먼저 완성하자. 앱은 다섯 개를 붙여도 되지만, 흐름은 세 개면 충분하다. AI 에이전트는 백화점이 아니라 주방이다. 조미료를 백 개 사는 것보다 자주 해 먹는 요리 세 개가 먼저다.

도구가 정말 많아진다면, 인증을 중앙에서 위임하고 필요한 도구만 동적으로 노출하는 라우터나 게이트웨이 계열 접근을 검토할 수도 있다. 특히 여러 SaaS를 묶는 환경에서는 이런 구조가 컨텍스트 낭비와 자격 증명 노출을 줄이는 데 도움이 된다.⁷

실제로 가장 잘 굴러가는 결합 순서

실전에선 거창한 설계보다 순서가 더 중요하다. 잘 굴러가는 조합은 대개 아래 순서를 따른다.

1. 반복되는 한 가지 업무를 고른다. "노션 연결"이 아니라 "회의 메모를 Notion에 정리"처럼 동사까지 붙은 작업을 고른다.

2. MCP 서버부터 읽기 전용으로 붙인다. 처음부터 쓰기 권한을 주지 말고 검색, 조회, 목록 확인만 먼저 성공시킨다.

3. 가장 작은 검증을 한다. Notion이면 페이지 하나 읽기, Linear면 내 이슈 목록 보기처럼 30초 안에 확인 가능한 테스트를 먼저 한다.

4. 스킬로 절차를 고정한다. 언제 검색하고, 언제 생성하고, 언제 사람 승인을 받는지 문장으로 적는다.

5. 마지막에 자동화를 붙인다. 하트비트나 정기 브리핑, 웹훅 연동은 이 단계에서 붙인다. 연결도 안 된 상태에서 스케줄부터 얹으면 디버깅 지옥이 열린다.

이 순서가 좋은 이유는 문제를 한 겹씩 분리해 주기 때문이다. 연결 문제인지, 권한 문제인지, 스킬 설계 문제인지, 자동화 트리거 문제인지 구분이 쉬워진다.

자주 쓰는 실전 문장 설계법

스킬로 MCP를 감쌀 때는 긴 설명보다 좋은 문장이 중요하다. 특히 description과 규칙 문장은 에이전트의 행동 품질을 크게 바꾼다.

좋은 문장은 대개 세 가지를 분명하게 말한다.

• 이 스킬은 언제 쓰는가

• 어떤 MCP 도구를 어떤 순서로 쓰는가

• 어디서 멈추고 사람에게 묻는가

예를 들면 이런 식이다.

"사용자가 회의록, 인터뷰 요약, 주간 정리 문서를 요청할 때 사용한다. 먼저 Notion에서 같은 프로젝트 문서를 검색하고, 있으면 갱신 여부를 판단한다. 새 문서를 만들 때는 제목 규칙과 날짜 형식을 따른다. 데이터베이스가 두 개 이상 후보로 나오면 생성 전에 반드시 사용자 확인을 받는다."

이 문장 안에는 이미 절반의 안정성이 들어 있다. 도구 이름을 장황하게 나열하는 것보다, 호출 순서와 승인 지점을 써 주는 편이 훨씬 실무적이다.

더 큰 자동화 생태계로 넘어가는 발판

MCP와 스킬의 결합이 중요한 진짜 이유는 여기서 끝나지 않기 때문이다. 이 구조에 익숙해지면, 이후에는 특정 앱 하나에 종속되지 않는다. Notion에서 시작했더라도, 나중에는 Confluence나 Google Docs로 비슷한 패턴을 옮길 수 있다. Linear를 쓰다가 Jira로 옮겨도 스킬의 상위 규칙은 상당 부분 유지된다. 바뀌는 것은 밑단의 MCP 서버이고, 유지되는 것은 당신의 업무 절차다.¹⁴

바로 이 점이 OpenClaw를 단순 설치형 챗봇이 아니라 운영체제로 보게 만드는 순간이다. 스킬은 당신의 일하는 방식을 적고, MCP는 그 방식을 여러 도구 세계에 연결한다. 둘을 함께 익히면, 에이전트는 더 이상 한 앱의 기능 시연자가 아니라 여러 SaaS를 가로지르는 디지털 분신으로 자라기 시작한다.

잘 만든 조합은 화려하지 않다. 아침에 텔레그램으로 한 줄 보내면, 에이전트가 관련 문서를 찾고, 필요한 티켓을 정리하고, 사람 검토가 필요한 초안만 딱 남긴다. 겉으로는 조용하다. 그런데 그 조용함이야말로 좋은 자동화의 표정이다.

참고

¹MCP vs. OpenClaw Skills: A Compatibility Breakdown

²OpenClaw Skills: How to Find, Install, and Build Custom Skills

³MCP - OpenClaw

⁴OpenClaw and MCP: How to Connect Your AI Agent to Every App You Use

⁵개발자를 위한 OpenClaw: GitHub, Linear, Notion과 AI 기반 개발 워크플로

⁶How to Connect OpenClaw to Notion

⁷How to integrate Notion MCP with OpenClaw