MCP·스킬 + 브랜드 컨텍스트

프로젝트 폴더를 Claude Code 또는 Codex에서 열고, 필요한 자료를 첨부한 뒤 요청문 옆 복사 버튼을 누릅니다. 대괄호가 있는 요청은 내 내용으로 바꿔 붙여넣으며, 답변을 받은 뒤에는 안내된 파일이나 화면을 직접 확인합니다.

project-brief.md에는 다섯 가지를 정합니다. 이후 brand.md나 workflow.md로 갈라지는 모든 개인화 작업이 여기서 출발합니다.

• 만들 결과물
• 사용할 사람
• 현재 가진 자료
• 완료 기준
• 하지 않을 일

파일은 직접 채우지 않습니다.

• Claude Code에게 한 번에 한 질문씩 묻게 합니다. 순서대로 답만 하면 브리프가 완성됩니다.
• 답이 모호하면 예시 3개를 보여 달라고 요청해 그중에서 고릅니다.

완료 기준은 확인 가능한 문장으로 적습니다.

• 애매한 기준 — “결과물이 좋아 보인다”
• 확인 가능한 기준 — “A4 한 장, 고객 3유형, 금지 표현 5개가 들어간다”

확인할 수 없는 기준은 나중에 결과물을 두고 다시 논쟁하게 됩니다.

아래 요청문을 복사해 붙여넣고 project-brief.md 인터뷰를 시작합니다.

project-brief.md 다음 단계는 brand.md이고, 다섯 질문으로 정리합니다.

• 대상 고객
• 지금 겪는 문제
• 남기고 싶은 인상
• 자주 쓸 말과 쓰지 않을 말
• 참고할 브랜드

파일은 직접 채우지 않습니다.

• project-brief.md를 먼저 읽게 하고, 다섯 항목을 한 번에 한 질문씩 물어보게 합니다.
• 답이 끝나면 사실, 결정, 아직 모르는 것을 구분해서 정리해 달라고 요청합니다.

색과 폰트처럼 아직 정하지 않은 항목은 추측으로 채우지 않습니다.

• “미정”으로 남겨 두고, 다음 시각 탐색 단계에서 다시 결정합니다.
• 모르는 것을 안다고 적어 두면 이후 모든 요청이 그 위에서 어긋납니다.

아래 요청문을 복사해 붙여넣고 brand.md 인터뷰를 시작합니다.

design.md와 image.md는 역할이 다릅니다.

• design.md — 색·폰트·여백 같은 화면 규칙
• image.md — 이미지에서 고정할 요소와 바꿔도 되는 요소

파일은 직접 채우지 않습니다.

• 기존 결과물과 참고 이미지를 먼저 보여주고, 한 번에 한 질문씩 인터뷰를 받습니다.
• “감성적”, “세련된” 같은 형용사는 그대로 두지 않고 HEX 값, 폰트 이름, px처럼 관찰 가능한 값으로 바꿉니다. 형용사는 사람마다 다르게 읽지만 값은 누가 읽어도 같습니다.

image.md에서는 요소를 두 갈래로 나눕니다.

• 매번 유지할 요소 — 피사체, 구도, 광원, 팔레트
• 바꿔도 되는 요소 — 장면, 소품

이 구분이 있어야 이미지를 여러 장 만들어도 같은 브랜드로 보입니다.

아래 요청문을 복사해 붙여넣고 design.md 인터뷰를 시작합니다.

다른 AI 도구에서도 같은 디자인 기준 사용하기

DESIGN.md는 색·글꼴·여백 같은 디자인 규칙과 그 규칙을 사용하는 이유를 적는 문서 파일입니다. Google은 2026년 4월 21일 Stitch의 DESIGN.md 작성 규격 초안을 공개했습니다. 공식 규격은 정확한 값을 적는 부분과 적용 방법을 설명하는 본문을 함께 사용합니다.

이 수업의 design.md는 같은 목적으로 쓰는 수업용 문서이며, Google 규격을 그대로 따르는 파일인지는 별도로 확인해야 합니다. 이미 쓰는 파일이 있다면 그 이름을 유지하고, 대소문자만 다른 파일을 추가로 만들지 않습니다.

기존 자료에서 기준 정리하기

브랜드 안내서나 기존 화면을 AI에 보여 주고 아래 요청문을 붙여넣습니다. 웹사이트를 읽을 수 없는 도구에서는 화면 이미지나 파일을 첨부합니다. 사진만 보고 정확한 글꼴이나 색을 확정하지 않도록 확인된 값과 미정인 항목을 나눕니다.

제가 제공한 브랜드 안내서, 기존 화면과 현재 폴더의 디자인 문서를 읽어 주세요. 이미 design.md 또는 DESIGN.md가 있다면 그 파일부터 확인해 주세요.

배경·본문·강조 색, 제목·본문 글꼴, 여백과 화면 폭을 정리하고 각 항목에 확인한 파일 또는 페이지를 적어 주세요. 각 색과 글꼴을 어디에 쓰는지도 설명해 주세요. 자료만으로 알 수 없는 값은 미정으로 남기고, 기존 기준과 충돌하는 항목은 제게 한 가지씩 질문해 주세요.

확인한 뒤 기존 디자인 문서에 추가할 내용을 보여 주세요. 파일이 없다면 design.md 초안을 작성해 주세요. 저장할 수 없는 도구라면 제가 내려받거나 복사해 저장할 수 있도록 문서 전문을 보여 주세요.

새 대화에서 읽었는지 확인하기

새 대화나 다른 AI 도구에서는 파일을 첨부하거나 파일이 있는 폴더를 연결하고, 아래 요청문으로 읽은 내용을 확인합니다. 파일을 저장해 둔 것만으로 모든 도구가 자동으로 읽거나 이후 대화까지 기억한다고 가정하지 않습니다.

첨부한 design.md 또는 현재 작업 폴더의 디자인 문서를 먼저 읽어 주세요. 실제로 읽은 파일 이름과 배경색, 본문 글꼴, 여백 기준을 요약하고 아직 미정인 항목도 알려 주세요. 파일이 보이지 않으면 추측하지 말고 필요한 파일을 요청해 주세요. 아직 화면이나 이미지는 만들지 마세요.

AI가 답한 값과 문서의 값이 일치하는지 대조합니다. 이후 결과물을 만들 때도 같은 문서를 함께 전달하고, 완성한 화면에서 색·글꼴·여백이 기준과 맞는지 확인합니다.

공식 설명

• Google Labs의 DESIGN.md 공개 안내
• Google의 DESIGN.md 규격과 예제

클로드 디자인은 claude.ai/design에서 열리는 디자인 도구입니다. 프롬프트를 넣으면 카드뉴스, 슬라이드, 웹 화면 시안을 만들어 줍니다.

Claude Code와 역할이 다릅니다.

• Claude Code — 폴더에서 파일을 직접 만들고 고칩니다.
• 클로드 디자인 — 결과 화면을 눈으로 보면서 고칩니다.

시안을 만들기 전에 기준을 먼저 넣는 것이 중요합니다.

• design.md를 첨부하면, 클로드 디자인이 그 색·폰트·여백에 맞춰 화면을 만듭니다.
• 피그마 디자인 시스템이 있으면 .fig 파일로 등록해 둘 수도 있습니다.
• 기준 없이 “만들어 줘”라고만 하면 어디서 본 듯한 평균적인 화면이 나옵니다. design.md로 잡아 둔 기준이 여기서 그대로 쓰입니다.

한 번에 한 가지만 받지 말고 3가지 방향으로 받습니다. 서로 다른 안을 나란히 놓고 고른 다음, 채팅으로 색·문구·배치를 고쳐 나갑니다.

Pro 이상 구독에서 열리고, 무료 계정에서는 화면이 나타나지 않습니다.

순서 아래 요청을 claude.ai/design 입력창에 붙여넣어 첫 시안을 만들어 보세요.

voice.md와 swipe.md는 역할이 다릅니다.

• voice.md — 어미·어휘·금지 표현 같은 규칙
• swipe.md — 승인된 실제 문장을 출처와 함께 쌓는 기록

파일은 직접 채우지 않습니다.

• 최근 실제로 발행한 글과 마음에 드는 문장을 먼저 보여주고, 한 번에 한 질문씩 인터뷰를 받습니다.
• 규칙은 실제 문장과 짝을 이룰 때 작동하므로, 승인 예시와 거절 예시를 함께 넣습니다.

swipe.md는 한 번 만들고 끝나는 파일이 아니라 발행할 때마다 좋은 문장을 한 줄씩 쌓는 파일입니다.

• 출처를 모르는 외부 문장은 인용하지 않습니다.
• 확인되지 않은 수치와 성과는 쓰지 않습니다.

아래 요청문을 복사해 붙여넣고 voice.md 인터뷰를 시작합니다.

workflow.md는 project-brief.md 다음 단계로 만들고, 다섯 항목으로 실제 업무 흐름을 정리합니다.

• 입력 — 일이 시작될 때 들어오는 자료
• 판단 — 사람이 결정해야 하는 기준
• 실행 — 반복해서 하는 단계
• 출력 — 마지막에 나와야 하는 결과
• 예외 — 자동으로 처리하면 안 되는 경우

project-brief.md를 먼저 읽게 하고, 실제로 하는 일을 인터뷰하게 합니다. 다섯 항목을 한 번에 한 질문씩 구분해서 묻게 합니다.

• 결제, 발송, 삭제, 공개처럼 되돌리기 어려운 단계는 자동 실행 대상으로 두지 않습니다. 먼저 사람이 확인하는 승인 지점으로 표시해 둡니다.
• 마지막에는 현재 흐름과 개선 후보를 분리해서 정리합니다. 지금 하는 일과 나중에 자동화할 일이 섞이지 않습니다.

아래 요청문을 복사해 붙여넣고 workflow.md 인터뷰를 시작합니다.

매번 “이모지 빼고, 존댓말로” 같은 규칙을 다시 적어야 한다면, 그만큼 요청이 길어지고 깜빡 빠뜨린 요청만 규칙에서 벗어난 결과를 받게 됩니다.

CLAUDE.md는 세션이 시작될 때 자동으로 읽히는 규칙 파일입니다.

• 폴더 구조, 금지 사항, 톤, 자주 쓰는 명령어처럼 매번 설명하던 내용을 적어 둡니다. 이후 요청에서는 생략할 수 있습니다.
• 빈 프로젝트라면 /init을 실행해 코드와 문서를 분석한 초안을 먼저 받습니다.

파일은 크게 두 층입니다. 같은 내용이 두 파일에 있으면 프로젝트 파일이 우선 적용됩니다.

• 프로젝트 루트의 CLAUDE.md — 그 프로젝트에서 함께 일하는 사람과 공유하는 규칙
• 사용자 홈 폴더의 ~/.claude/CLAUDE.md — 어떤 프로젝트를 열어도 항상 적용되는 개인 규칙

규칙은 쌓기보다 관리합니다.

• 온갖 규칙을 한 파일에 계속 이어 붙이면 필요한 기준을 찾기 어려워집니다.
• 안 쓰는 규칙은 지우고, 자주 어기는 규칙은 눈에 잘 띄는 자리로 옮깁니다.

/context를 입력하면 현재 세션이 어떤 CLAUDE.md 파일을 불러왔는지 확인할 수 있습니다. /memory는 메모리 파일 위치를 열어 관리할 때 사용합니다.

CLAUDE.md에 적은 문장은 판단에 참고할 규칙입니다. 특정 단어가 있는 파일 저장을 반드시 막아야 한다면 Hooks — 자동 검수에서 PreToolUse Hook으로 같은 조건을 검사합니다.

순서의 각 단계 아래 붙여넣기 예제가 있습니다. 위에서부터 하나씩 실행해 보세요.

같은 프로젝트를 여러 날에 걸쳐 진행하면, 지난번에 정한 값이 어디에도 안 남아 있는 일이 생깁니다. 대화는 끝나면 사라지고, 기획서에는 정하기 전의 값이 그대로 적혀 있습니다.

무엇을 적나요

한 항목에 네 칸이면 충분합니다.

버린 안을 적어 두는 것이 특히 도움이 됩니다. 몇 주 뒤에 같은 안이 좋아 보여 다시 올라올 때, 왜 안 쓰기로 했는지가 그 자리에 있으면 다시 검토하지 않아도 됩니다.

새 항목은 맨 위에

파일 끝에 붙이면 최신을 보려고 매번 끝까지 내려가야 합니다. 맨 위에 넣으면 파일을 여는 순간 최신이 보입니다.

기획서와 다를 때

기획서·제안서·초안은 그 시점의 스냅샷입니다. 그 뒤에 값이 바뀌어도 문서가 자동으로 고쳐지지 않으므로, 원장과 다르면 원장을 따릅니다.

밀려난 문서는 지우지 말고 머리에 한 줄 붙입니다.

> 폐기 2026-08-13: 색 기준은 decisions.md 최신 항목을 따릅니다.

지우지 않는 이유는 되짚기 위해서입니다. 왜 그때 그렇게 정했는지가 남아 있으면 다음 결정이 쉬워집니다.

요청할 때 같이 붙입니다

색을 고르거나 문구를 쓰거나 화면 구조를 만들기 전에, 원장을 같이 읽게 합니다. CLAUDE.md에 “시각·문구 작업 전 decisions.md 최신 항목을 먼저 읽는다”를 한 줄 넣어 두면 매번 말하지 않아도 됩니다.

확정은 내가 합니다

AI가 대화 중에 스스로 확정이라고 적지 않게 하세요. 원장에 들어가는 것은 내가 정한 것뿐입니다. 후보를 뽑아 달라고 하는 것과, 그 후보를 확정으로 올리는 것은 다른 단계입니다.

research-brief.md는 project-brief.md 다음 단계로 만듭니다. 질문, 출처, 최신성, 범위, 형식 다섯 항목으로 조사 기준을 정리합니다.

project-brief.md를 먼저 읽게 하고, 알아내야 하는 것을 인터뷰하게 합니다. 다음을 한 번에 한 질문씩 구분해서 묻게 합니다.

• 이 조사로 답하려는 질문
• 인정할 출처와 인정하지 않을 출처
• 언제 이후 자료만 쓸지
• 조사에서 뺄 범위
• 결과를 어떻게 정리해 받을지

출처 기준은 조사 주제마다 다릅니다.

• 공식 발표와 원문만 쓸지, 업계 기사까지 인정할지, 커뮤니티 글은 참고로만 둘지 미리 정해 두면 결과를 받아 놓고 다시 걸러 내지 않아도 됩니다.
• 기준 날짜도 함께 정합니다. 날짜를 정하지 않으면 몇 해 전 자료가 지금 상황처럼 섞여 들어옵니다.

가장 자주 어긋나는 곳은 수치와 인용입니다. 출처가 없어도 문장은 그럴듯하게 채워지므로, 수치와 인용에는 링크를 함께 달게 하고 몇 개는 직접 열어 확인합니다. 찾지 못한 항목은 사실로 적지 않고 확인하지 못한 것으로 따로 빼 둡니다.

아래 요청문을 복사해 붙여넣고 research-brief.md 인터뷰를 시작합니다.

“발행물은 여기, 임시 산출물은 저기, 원본은 건드리지 않는다”는 위치 규칙을 먼저 정합니다. 규칙이 없으면 매번 위치를 새로 지정해야 하고, 나중에 어디 있는지 찾는 것도 일이 됩니다.

SSoT(Single Source of Truth, 단일 진실 출처)를 정해 두는 이유도 같습니다.

• 같은 정보가 여러 파일에 흩어져 있으면 어느 쪽이 최신인지 매번 확인해야 합니다.
• 정본 파일 하나를 정하고 나머지는 그 파일을 가리키게 합니다.

마케터가 캠페인 자료를 만들 때 발행본과 초안이 같은 폴더에 섞여 있으면, 어느 파일이 최종본인지 매번 물어봐야 합니다.

• “최종”, “진짜최종”, “최종_수정2”처럼 파일명으로 버전을 구분하는 방식은 피합니다.
• 발행 폴더와 초안 폴더를 나누고 발행 폴더에 있는 것만 정본으로 취급하면, 파일명에 기대지 않아도 됩니다.
• 공개 범위도 구조에 포함됩니다. 외부에 나가도 되는 폴더와 내부용 폴더를 나눠 두면, 발행 작업을 맡길 때 비공개 자료가 실수로 섞여 나가는 일을 줄일 수 있습니다.

순서의 각 단계 아래 붙여넣기 예제가 있습니다. 위에서부터 하나씩 실행해 보세요.

파일이 직접 바뀌는 만큼, 무엇이 어떻게 달라졌는지 확인할 방법이 없으면 결과가 마음에 안 들어도 되돌리기 어렵습니다. Git이 그 방법입니다.

branch(작업 갈래)를 나눠 두면 실험적인 요청과 완성된 작업을 분리할 수 있습니다.

• 새 작업을 시작할 때 branch를 하나 만들고, 그 안에서 Claude에게 작업을 맡깁니다.
• 결과를 그대로 받아들이기 전에 diff(변경 내역 화면)를 봅니다.
• 어떤 줄이 지워지고 어떤 줄이 추가됐는지 보면, 의도와 다르게 바뀐 부분을 commit(기록) 전에 잡을 수 있습니다.

기획서 여러 장을 한 번에 고쳐 달라고 맡긴 뒤 diff를 보지 않고 그대로 commit하는 것은 피해야 할 습관입니다. 의도와 다르게 지워진 문단이 나중에야 발견됩니다.

• 뉴스레터 문구를 수정할 때도 마찬가지로, commit 전에 “무엇이 바뀌었는지 보여줘”라고 요청해 diff를 확인하면 커밋 전에 실수를 잡을 수 있습니다.
• commit은 확인이 끝난 상태를 기록하는 지점입니다. 문제가 있으면 commit 이전으로 되돌릴 수 있으므로, 큰 작업을 맡기기 전에 commit해 두면 안전망이 생깁니다.

순서의 각 단계 아래 붙여넣기 예제가 있습니다. 위에서부터 하나씩 실행해 보세요.

세 단어는 커밋 → 푸시와 브랜치 → 머지라는 두 흐름으로 이어집니다. 첫 저장에서는 커밋한 뒤 푸시하고, 나중에 작업을 따로 나누었을 때 머지를 사용합니다.

• 커밋(commit) — 블록 집을 사진으로 남기고 “여기까지 만들었습니다”라고 메모하는 것과 같습니다. 실제로는 지금까지 바꾼 파일을 내 컴퓨터에 기록 하나로 남깁니다.

아래 그림에서는 확인한 문서에 도장을 찍어 기록을 남깁니다.

• 푸시(push) — 사진첩을 인터넷 보관함에 올리는 것과 같습니다. 실제로는 내 컴퓨터의 커밋을 GitHub 저장소로 보냅니다. 커밋만 하고 푸시하지 않으면 GitHub 웹에는 아직 보이지 않습니다.

• 머지(merge) — 다른 책상에서 만든 창문을 완성할 블록 집에 붙이는 것과 같습니다. 실제로는 다른 브랜치에서 만든 변경을 main에 합칩니다.

아래 그림에서는 따로 만든 작업을 최종본에 합칩니다.

다음에 만나는 네 단어

• 브랜치(branch) — 변경 기록을 나눠 진행할 때 붙이는 이름입니다. 시안 복사본을 하나 더 만들어 실험하는 것과 비슷하게 사용할 수 있습니다.

아래 그림에서는 최종본을 그대로 둔 채 브랜치에서 실험합니다.

• main — 프로젝트가 기본으로 사용하는 브랜치 이름입니다. 확인을 마친 변경을 모으는 방식으로 운영할 수 있지만, Git이 완성본으로 정해 놓은 이름은 아닙니다.
• origin — 원격 저장소 주소에 붙이는 이름입니다. 흔히 GitHub 주소를 가리키지만 다른 서버도 가리킬 수 있습니다.
• 워크트리(worktree) — 같은 Git 저장소에 연결된 별도 작업 폴더입니다. 두 작업을 동시에 진행할 때 파일이 섞이지 않게 도와줍니다.

아래 그림에서는 두 작업을 다른 폴더에 나란히 펼칩니다.

Codex나 Claude Code에는 “지금까지를 기록해 줘”, “GitHub에 올려 줘”, “따로 만든 작업을 main에 합쳐 줘”라고 말해도 됩니다. 작업이 끝난 뒤에는 커밋, 푸시, 머지 가운데 무엇을 했는지 확인합니다.

GitHub는 프로젝트 파일과 변경 기록을 함께 보관합니다. 계정이 없다면 GitHub 계정과 첫 저장소 만들기를 먼저 열고 가입을 마칩니다. 첫 저장에서는 웹에서 빈 비공개 저장소를 먼저 만들고, 올릴 파일과 제외할 파일을 확인합니다.

저장 전에 공개하면 안 되는 파일을 확인합니다

비밀번호, 토큰, API 키, .env 파일, 고객·직원 개인정보는 비공개 저장소에도 올리지 않습니다. GitHub가 비밀 값을 감지해 푸시를 막으면 차단을 넘기지 않고 파일에서 값을 제거합니다.

웹에서 파일과 커밋을 함께 확인합니다

명령이 성공했다는 답만으로 저장을 끝내지 않습니다. GitHub의 Code 화면에서 저장소 이름, main 브랜치, 최근 커밋, 프로젝트 파일을 확인합니다. 네 항목이 보이면 내 컴퓨터의 기록이 GitHub에도 올라간 상태입니다.

GitHub 저장소 주소는 파일을 보는 주소입니다. 완성한 사이트를 방문자에게 보여 주려면 빌드와 배포가 별도로 필요합니다.

Claude Code는 로컬 파일만 다루지 않습니다. Notion, Slack, 데이터베이스처럼 파일 시스템 밖에 있는 데이터를 매번 복사해 옮기면 서식이 깨지거나 최신 값을 놓치기 쉽습니다.

MCP는 Claude Code가 외부 서비스와 대화하는 표준 통로입니다. 추천 목록에 나온 MCP를 모두 연결할 필요는 없으며, 선택 기준은 스킬·플러그인·MCP 구분 카드에서 확인할 수 있습니다.

이 카드에서는 Notion 공식 MCP 하나만 연결하고 지정한 페이지를 수정하지 않은 채 읽어 봅니다. 연결 목록에 이름이 보이는 것만으로 끝내지 않고 실제 페이지 조회와 공유 범위를 함께 확인합니다.

• 설정 파일을 직접 만질 필요는 없습니다. “Notion 연결해 줘” 같은 요청으로 설치와 인증 과정을 Claude Code에게 맡길 수 있습니다.
• 연결이 끝나면 Notion 페이지 검색·조회·작성 같은 요청을 문장으로 할 수 있습니다.

기본 연결은 지금 열어 둔 폴더(프로젝트) 단위로 저장됩니다.

• 같은 도구를 다른 폴더에서도 쓰려면 그 폴더에서 다시 연결해야 합니다.
• 모든 폴더에서 공용으로 쓰고 싶으면 “이 연결을 모든 프로젝트에서 쓸 수 있게 해 줘”라고 요청하면 되고 이 경우 새 폴더를 열 때마다 다시 연결하지 않아도 됩니다.

순서 아래 실행 요청을 그대로 붙여넣어 지금 연결된 외부 도구부터 확인해 보세요.

이미지나 영상 생성이 필요한 사람은 이 실습을 마친 뒤 Higgsfield 연결 카드로 이어갑니다. 그 연결은 생성 전에 잔여 크레딧과 한 건의 예상 비용부터 확인합니다.

서브에이전트는 별도 맥락에서 작업하고 결과만 본 대화로 돌려주는 워커입니다. “서브에이전트로 조사해 줘”처럼 요청하면 Claude가 워커를 골라 위임합니다.

본 대화에서 직접 조사하면 중간 결과와 읽고 안 쓴 파일이 그대로 쌓입니다. 맥락이 무거워지면 이후 요청에서 처음 규칙을 놓칩니다.

• 파일 여러 개를 뒤지거나 같은 조사를 반복할 때 씁니다.
• 한두 줄로 끝나는 질문은 직접 답하는 게 빠릅니다.
• 위임한 작업은 끝나거나 막히면 스스로 보고합니다.

범위 밖의 일은 칩으로 떼어 두기

칩(chip)은 지금 범위 밖의 일을 별도 세션으로 미뤄 두는 방법입니다. “이건 새 칩으로 띄워 줘”라고 요청하면 화면에 칩이 생기고, 누르면 그 일만 다루는 세션이 열립니다. 지금 대화는 그대로 이어집니다.

아래 요청문을 복사해 붙여넣고 조사 하나를 서브에이전트에 맡깁니다.

세 가지를 구분합니다

• 스킬: 한 가지 작업을 잘하도록 만든 지침입니다. Claude가 읽고 그대로 따릅니다.
• MCP(Model Context Protocol): Claude와 Notion·Figma 같은 외부 앱을 연결하는 규격입니다.
• 플러그인: 스킬·서브에이전트·훅·외부 연결을 묶은 패키지입니다.

플러그인은 배포 단위여서 그 안에 스킬과 MCP 설정이 함께 들어 있기도 합니다. 이때도 외부 서비스에 실제로 접속하는 일은 그 안의 MCP가 맡습니다.

나머지 둘까지 놓고 보면

무엇이 늘어나는지로 보면 다섯 가지 확장이 세 갈래로 묶입니다.

서브에이전트와 훅은 남이 만든 것을 받는 대신 직접 만드는 쪽이라 뒤 단원에서 다룹니다. 스킬은 Claude가 읽고 따르는 글이어서 지나칠 수 있지만 훅은 정해진 시점에 자동으로 실행돼 지나칠 수 없습니다.

MCP는 계정 권한을 사용합니다. 연결할 앱과 허용 범위를 먼저 확인합니다.

MCP는 내 작업으로 고릅니다

아래 다섯 MCP는 서로 다른 일을 맡기므로 모두 연결할 필요가 없습니다. 반복해서 쓰는 서비스가 있고 Claude가 그 서비스의 자료를 읽거나 작업해야 할 때 하나를 고릅니다.

Notion은 문서 하나를 읽어 보는 첫 실습에 적합합니다. Notion 연결 카드에서는 페이지를 수정하지 않고 연결과 읽기 범위부터 확인합니다. Higgsfield가 필요한 사람은 Higgsfield 연결 카드에서 생성 전에 잔액과 예상 크레딧을 확인합니다. Higgsfield 웹 요금제에 무료·무제한 생성이 포함되어 있어도 MCP로 생성하면 크레딧이 차감됩니다.

세 종류의 예시 보기

설치 전에 세 가지만 봅니다

• 필요성: 지금 할 일에 필요한 하나만 고릅니다.
• 출처: 제작자와 최신 안내를 살펴봅니다.
• 조건: 권한·비용·설치 위치를 확인합니다.

명령은 Claude Code에 입력합니다. MCP는 설정 화면에서 연결합니다. 설치할 항목 고르기

작은 작업 하나로 확인합니다

• 요청: 원하는 결과를 한 문장으로 말합니다.
• 확인: 생성된 파일이나 앱 변경을 직접 엽니다.
• 판단: 다시 쓸 만하면 유지합니다. 권한이 과하면 제거합니다.

처음부터 끝까지 따라 할 사례가 필요하면 eli5로 설명 아티팩트 열기로 이어갑니다.

MCP로 외부 앱을 바꿀 때는 읽기와 수정 범위를 구분합니다.

Skill(스킬)은 특정 작업의 절차와 규칙을 SKILL.md 파일에 정리해 둔 것입니다. 이름을 불러 실행하면 매번 설명했던 순서와 기준을 다시 적지 않아도 됩니다.

description(스킬 설명글)에 실제로 쓸 법한 표현을 적어 두면 Claude가 요청 맥락을 보고 스스로 스킬을 불러옵니다. 설명이 부실하면 이름을 직접 불러야만 실행됩니다.

Plugin(플러그인)은 Skill·서브에이전트·Hook(정해진 시점에 자동 실행되는 규칙) 여러 개를 묶어 다른 프로젝트나 사람에게 그대로 옮기는 꾸러미입니다. 한 프로젝트에서 다듬은 조합을 다른 곳에도 쓰고 싶을 때 이 단위로 옮깁니다.

• 카피라이터가 매주 같은 형식으로 뉴스레터 초안을 뽑는다면, 그 절차를 스킬로 만들어 두고 다음부터는 이름만 불러 실행하면 됩니다.
• description에 “뉴스레터용”처럼 짧게만 적어 두면 실제 요청 문장과 맞아떨어지지 않아 자동으로 불려 오지 않습니다.

처음부터 완벽하게 만들 필요는 없습니다. 반복하다 보면 빠진 단계나 잘못된 가정이 드러나므로, 실제로 쓰면서 다듬는 편이 낫습니다.

아래 요청문을 복사해 붙여넣고 반복 절차 하나를 스킬로 만듭니다.