MCP와 Skill, Hook의 차이 및 적용 기준

Claude Code를 오래 쓰다 보면 같은 요구를 MCP 서버로 풀지, Skill로 풀지, Hook으로 풀지 고민하게 된다. 셋은 모두 Claude Code를 확장하지만 누가 실행을 결정하는지, 무엇을 더해 주는지, 컨텍스트를 얼마나 쓰는지가 다르다. 이 글은 세 가지의 차이를 실제 설정을 예로 정리하고, 새 기능을 붙일 때 어느 것을 고를지 판단하는 기준을 제시한다.

한 문장씩으로 정리하면

• MCP는 모델에게 없던 능력(외부 시스템에 닿는 도구)을 준다.
• Skill은 모델에게 방법(절차, 규칙, 스크립트)을 알려 준다.
• Hook은 모델과 상관없이 반드시 일어나야 할 일을 하네스가 실행한다.

어디서 동작하는가

세 가지는 Claude Code 안에서 서로 다른 자리에 붙는다.

• Skill은 모델의 컨텍스트 안에 들어간다. 평소엔 name과 description만 있고, 요청이 맞으면 본문을 읽는다.
• MCP는 모델이 부를 수 있는 도구 목록에 들어간다. 이름은 mcp__서버__도구 형태다.
• Hook은 모델 바깥, 하네스가 이벤트마다 실행한다. 모델은 Hook을 부를 수도, 건너뛸 수도 없다.

MCP: 능력이 없을 때

MCP(Model Context Protocol) 서버는 모델이 직접 할 수 없는 일, 즉 외부 시스템에 닿는 일을 도구로 감싸 준다. 이 블로그를 운영하는 환경에는 사용자 설정에 MCP 서버 4개(디자인 편집기, 한글 문서 편집, 이미지·영상 생성, 코드 탐색)가 있고, 플러그인과 연결 서비스로 브라우저 조작, 문서 도구 등이 더 붙어 있다.

# 프로젝트에 MCP 서버 추가 (설정은 .mcp.json 또는 사용자 설정에 저장된다)
claude mcp add <이름> -- <서버 실행 명령>

MCP를 고를 때 확인할 것:

• 정말 외부 접근이 필요한가. 로컬 CLI로 되는 일(예: gh, vercel)이면 Bash로 충분하다. 서버를 하나 더 띄울 이유가 없다.
• 도구 정의 비용. 도구가 수십 개인 서버는 그 정의가 컨텍스트를 차지한다. 필요한 서버만 켜 둔다.
• 권한. MCP 도구도 쓰기·삭제·발송을 할 수 있다. 되돌리기 어려운 도구는 권한 설정에서 확인을 받게 둔다.

Skill: 방법을 알려 줄 때

Skill은 "이 일은 이렇게 한다"를 파일로 남긴 것이다. 같은 지시를 세 번째 타이핑하고 있다면 Skill로 만들 때다. 이 블로그의 기술 아티클도 blog-tech-article 스킬로 쓴다. 원고 규칙, 다이어그램·삽화 생성, 배포, 발행, 공개 확인까지 순서와 끝 기준이 들어 있다.

---
name: blog-tech-article
description: 주제를 받아 블로그 '기술 아티클' 게시판에 한국어 기술 글을 써서 발행한다. (...)
  "기술 아티클에 ○○ 주제로 글 올려줘" 처럼 블로그 기술 글 작성·발행을 원하면
  스킬 이름을 말하지 않아도 이 스킬을 쓴다.
---

Skill을 고를 때 확인할 것:

• 트리거는 description이다. 사용자가 실제로 칠 문장을 예시로 넣어야 모델이 고른다.
• 계산은 스크립트로. 측정·변환·검사처럼 매번 같은 결과가 나와야 하는 일은 scripts/에 두고 본문에서는 언제 실행할지만 적는다.
• Skill은 확실하지 않다. 모델이 고르지 않으면 실행되지 않는다. "절대 빠지면 안 되는 일"은 Skill이 아니라 Hook으로 보낸다.

MCP와 Skill은 자주 같이 쓴다. MCP가 브라우저를 조작하는 도구를 주고, Skill이 그 도구로 로그인 확인 → 입력 → 저장 → 결과 확인을 어떤 순서로 할지 알려 준다.

Hook: 반드시 일어나야 할 때

Hook은 하네스가 특정 시점에 실행하는 셸 명령이다. 모델이 잊어도, 지시를 무시해도 실행된다. 이 환경의 사용자 설정에는 Hook이 49개 걸려 있고, 그중 도구 실행 전(PreToolUse)이 13개, 실행 후(PostToolUse)가 11개다.

자주 쓰는 이벤트:

설정은 이벤트 → 도구 이름 매처 → 명령 순서다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "npx block-no-verify@1.1.2" }]
      }
    ]
  }
}

위 예시는 실제로 쓰는 Hook으로, git commit --no-verify처럼 검사를 건너뛰는 명령을 막는다. PreToolUse Hook이 종료 코드 2로 끝나면 도구 실행이 막히고 표준 오류 내용이 모델에게 전달돼, 모델이 왜 막혔는지 알고 방법을 바꾼다.

Hook을 고를 때 확인할 것:

• 빠르고 조용해야 한다. 모든 도구 호출마다 돈다. 느린 명령은 작업 전체를 느리게 만든다.
• 출력은 곧 컨텍스트다. Hook이 내보낸 글자는 모델이 읽는다. 필요한 한 줄만 출력한다.
• 막을 때는 이유를 말한다. 차단 메시지에 대안을 적어야 모델이 같은 명령을 반복하지 않는다.

무엇을 고를까: 판단 순서

새 기능을 붙일 때 아래 순서로 물으면 대부분 하나로 정해진다.

자주 하는 실수

• 꼭 지켜야 할 규칙을 Skill이나 CLAUDE.md에만 둔다. 모델이 놓치는 날이 반드시 온다. 차단이 필요하면 Hook과 권한 설정으로 보낸다.
• CLI로 되는 일에 MCP 서버를 붙인다. 도구 정의만큼 컨텍스트가 줄고 관리할 프로세스가 늘어난다.
• Hook에서 말이 많다. 매 호출마다 긴 출력이 컨텍스트를 채워 정작 작업할 공간이 줄어든다.
• Skill description을 기능 소개로 쓴다. 사용자가 칠 문장이 없으면 모델이 고르지 않는다.
• 한 기능을 셋에 나눠 같은 규칙을 반복한다. 규칙은 한 곳에 두고, 나머지는 그곳을 가리킨다.

점검표

• 새 기능이 외부 접근, 반복 절차, 강제 실행 중 무엇인지 먼저 정했다
• MCP는 CLI로 대체할 수 없는 경우에만 추가했다
• 되돌리기 어려운 MCP 도구는 권한 확인을 받게 했다
• Skill description에 실제 요청 문장 예시가 있다
• Skill의 계산·검사는 스크립트로 뺐다
• 반드시 지켜야 할 규칙은 Hook이나 권한 설정으로 강제했다
• Hook은 빠르고, 출력이 짧고, 차단 시 이유와 대안을 말한다
• 같은 규칙이 여러 곳에 중복되어 있지 않다

정리하면 능력이 없으면 MCP, 방법을 모르면 Skill, 잊으면 안 되면 Hook이다. 셋 중 무엇이 필요한지 먼저 묻고 나서 만들면, 확장이 늘어나도 서로 겹치지 않는다.