일을 하다 보면 나만의 순서와 기준이 생기는데, 그걸 매번 말로 다시 풀어 쓰는 건 꽤 번거롭더라. 아빠도 처음엔 같은 부탁을 몇 번이고 새로 적으면서도, 원래 AI는 그렇게 쓰는 건 줄 알았어.
Claude Skills는 그 반복하던 부탁을 작은 업무 도구처럼 묶어 두는 방법이야. 코딩부터 배워야 하는 이야기가 아니니 겁먹지 말고, 오늘 한 입만 해보자.
늘 하던 부탁을 한 번만 적어 재사용할 수 있게 포장해 두면, 다음부터 Claude가 알아서 같은 방식으로 일해. 무엇을 묶으면 좋은지부터 안전하게 쓰는 법까지 차근차근 짚어 볼게.
언제 Claude Skill을 만들면 좋을까요
꼭 모든 일에 Skill이 필요한 건 아니에요. 다음과 같은 신호가 보인다면, 그때가 하나 만들어 둘 때예요.
- 대화마다 같은 기준 문서를 들고 검토하거나 작성할 때 — 예를 들어 '우리 팀 회의록 정리 규칙'을 대화마다 다시 붙여넣고 있다면요.
- 같은 형식이나 체크리스트를 반복해서 적용할 때.
- 팀원 여러 명이 보고서 톤이나 문서 형식을 똑같이 맞춰야 할 때.
Claude Skill은 어렵게 생각하지 않으셔도 됩니다 — 필요할 때 Claude가 알아서 꺼내 쓰는, 지침이 든 묶음이라고 보시면 돼요. 한 번 만들어 두면 여러 대화에서 자동으로 다시 쓰여서, 같은 안내를 되풀이할 필요가 없어집니다.
이런 신호가 보이면 '내가 뭔가 잘못 쓰고 있나' 싶을 수도 있는데, 전혀 그렇지 않아요. 오히려 그동안 손에 익은 그 기준이야말로 한 번 묶어 둘 가치가 있다는 뜻이거든요. 거창하게 시작할 필요도 없이, '회의록은 이렇게', '번역은 이 기준으로'처럼 자주 반복하던 한 가지부터면 충분합니다.
한 가지만 짚고 넘어갈게요. 이 사이트에서 말하는 Claude Skills는 Claude의 제품 기능(반복 작업 방식을 재사용 단위로 포장한 것)을 가리킵니다. 한편 기여하기에서는 직접 만든 Claude Skill 파일을 사례 글의 첨부로 공유합니다 — 즉 여기서 Skills는 "배우는 대상"이자 "기여 글에 붙이는 첨부 객체"이고, 별도의 콘텐츠 종류가 아니에요.
프롬프트·Projects·Claude Skills, 무엇이 다른가요
비슷해 보여 헷갈리기 쉬운 세 가지를, 사다리처럼 한 칸씩 올라가며 구분해 볼게요.
프롬프트는 그 대화 한 번에만 적용되는 일회성 지시예요. 같은 결과가 또 필요하면 다시 설명해야 하죠. 프롬프트 자체를 더 잘 쓰는 법은 프롬프트 잘 쓰는 법에 따로 모아 두었어요.
Projects는 늘 배경에 깔려 있는 고정 작업공간이에요. 자세한 건 Projects에서 다루니, 여기서는 '배경 작업공간'이라는 위치만 기억하면 돼요.
Claude Skills는 반복하는 작업 방식을 재사용 단위로 포장해 둔 것이에요. Projects처럼 늘 켜져 있는 게 아니라, 관련된 일이 생겼을 때만 켜지고, 또 어느 대화에서나 따라옵니다. 개념상으로는 한 번 쓰고 끝나던 지시(프롬프트)를 '반복될 때 다시 꺼내 쓰도록 포장한 보완재'로 이해하면 쉬워요. 프롬프트와 같은 것은 아니지만, 같은 부탁이 자꾸 반복된다면 Skill로 포장하는 단계로 한 칸 올라가는 셈이죠.
| 구분 | 한 줄로 보는 자리 |
|---|---|
| 프롬프트 | 그 대화에만 적용되는 1회성 지시 |
| Projects | 항상 로드되는 고정 배경 작업공간 |
| Claude Skills | 반복 작업 방식을 포장 — 필요할 때만 켜지고 어디서나 따라옴 |
그래서 '이번 한 번만 잘 되면 되는 일'은 프롬프트로, '앞으로도 같은 방식으로 반복할 일'은 Skill로 — 이렇게 가르면 헷갈릴 일이 줄어요.
부르는 방법도 부담 없어요. Claude가 작업과 관련된 Skill을 알아서 골라 적용하고, 필요하면 직접 불러올 수도 있습니다(정확한 방법은 내 계정 환경에서 확인해 주세요).
참고 — 다른 AI 도구에도 '자주 쓰는 작업 방식을 저장'하는 비슷한 기능이 등장하고 있어요. 다만 이름·동작이 빠르게 바뀌고 있어서, 여기서는 Claude Skills에 집중할게요.
팀의 기준을 한 번에 맞추는 실제 예시
Claude Skills가 빛나는 순간은 팀에서 같은 기준을 반복해야 할 때예요. 한 사람이 프롬프트를 길게 쓰지 않아도 되고, 사람마다 조금씩 달라지는 표현도 줄일 수 있습니다.
예를 들어 회의록을 정리한다고 해 볼게요. 지금은 회의 녹취나 메모를 붙여넣은 뒤, 회의 때마다 이렇게 부탁하고 계실지도 몰라요.
결정사항, 담당자, 마감일, 후속 확인이 필요한 내용을 분리해서 정리해 주세요. 불확실한 내용은 추측하지 말고 '확인 필요'로 표시해 주세요.
이 기준이 한두 번이면 프롬프트로 충분해요. 그런데 매주 팀 회의, 고객 미팅, 내부 검토 회의마다 같은 방식으로 정리한다면 Skill로 포장해 둘 만합니다. 그러면 다음부터는 회의록 정리 작업에서 Claude가 그 기준을 참고해 같은 형식으로 결과를 돌려줘요. 손에 잡히는 예시 몇 가지를 더 볼게요. 모두 매번 같은 기준 → 한 번 Skill로 포장 → 그다음부터 자동 적용이라는 같은 흐름이에요.
- 회의록 정리 규칙 — 결정사항·담당자·마감일·리스크·확인 필요 항목을 늘 같은 순서로 정리하도록.
- 보고서 톤 — 너무 구어체인 표현을 줄이고, 내부 보고에 맞는 간결한 문장으로 다듬도록.
- 번역 품질 기준 — 직역투를 줄이고, 제품명·부서명·고객 표현을 정해진 기준에 맞추도록.
- AI 결과 검토 체크리스트 — 출처가 필요한 문장, 숫자, 일정, 담당자 정보를 따로 표시해 내보내기 전에 점검하도록.
앞서 든 '보고서 톤'을 손에 잡히게 하나만 더 풀어 볼게요. 매주 금요일마다 같은 양식의 주간 보고서를 쓰는데, 그때마다 '결론을 맨 위로, 표현은 내부 보고 톤으로' 하고 똑같이 당부해 오셨다면 — 그 당부를 '보고서 톤' Skill 하나로 묶어 둘 수 있어요. 그러면 다음부터는 초안만 건네도 같은 결로 다듬어진 글이 돌아오고, 작성자가 바뀌어도 보고서의 톤이 들쭉날쭉해지지 않습니다.
좋은 소식은, 이걸 만드는 데 코딩이 필요 없다는 거예요. 마크다운으로 지침 몇 줄만 적어 두면 충분하고, 스크립트나 추가 파일은 선택일 뿐입니다. 처음에는 "이 작업은 어떤 순서로 처리할지", "결과는 어떤 형식으로 낼지", "주의할 점은 무엇인지"만 적어도 충분해요. 예를 들어 회의록 규칙이라면 이 정도로 시작해도 됩니다.
--- name: meeting-notes description: 회의록을 안건·결정사항·할 일 순서로 정리한다 --- 회의록을 정리할 때는 다음을 지킨다. - 맨 위에 안건을 한 줄로 요약한다. - 결정사항을 항목으로 정리한다. - 담당자별 할 일을 따로 모은다.
이렇게 평범한 글로 적어 두는 게 전부예요. 이 한 토막을 SKILL.md 한 파일로 두는 게 가장 단순한 형태고, 내 요금제에서 가능하다면 skill-creator라는 도구가 무엇을 자주 하는지 대화로 물어보면서 필요할 때 폴더 구조와 추가 파일까지 알아서 묶어 줘요. PowerPoint·Excel·Word·PDF 같은 기본 스킬은 문서를 만들 때 자동으로 동작하고(제공되는 목록은 바뀔 수 있어요), 직접 만든 Skill도 같은 방식으로 더해지는 거죠.
처음부터 완벽하게 채우려 애쓰지 않으셔도 됩니다. 실제로 몇 번 써 보면서 "이 항목은 빠지면 안 되겠다", "이 표현은 우리 팀 톤과 다르다" 같은 부분을 조금씩 고치면 돼요. 좋은 Skill은 한 번에 완성되는 문서라기보다, 팀의 반복 업무가 쌓이면서 다듬어지는 작은 업무 표준에 가깝습니다. 다만 내 계정에서 커스텀 Skill을 직접 만들거나 올릴 수 있는지는 설정에 따라 다를 수 있으니, 가능한 환경이라면 이렇게 가볍게 시작해 보세요. 부탁을 더 잘 전하는 법이 궁금하면 프롬프트 잘 쓰는 법을 참고하시고요.
안전하게 쓰려면 두 가지만
겁먹을 필요 없어요. 두 가지만 챙기면 마음 놓고 쓰실 수 있습니다.
첫째, Skill 안에 넣지 말아야 할 것. 지침이나 첨부에 (비밀번호·키 / 나·남의 개인정보 / 회사 기밀)은 담지 마세요. 자세한 기준은 안전하게 쓰는 법에 모아 두었어요.
둘째, 믿을 수 있는 출처의 Skill만 쓰기. 직접 만든 것이나 Anthropic이 제공하는 Skill이라면 안심하고 쓰셔도 됩니다. 외부에서 받은 Skill은 신뢰할 수 있는지 먼저 확인한 뒤 사용하세요 — 악성 Skill은 Claude가 의도와 다르게 도구를 호출하거나 코드를 실행하게 만들 수 있거든요. 낯선 소프트웨어를 설치할 때 한 번 점검하듯 보시면 편해요.
출처에 따라 한 번씩만 짚어 보면 한결 마음이 놓여요.
- 직접 만든 Skill — 지침에 민감한 내용이 섞이지 않았는지, 결과 형식이 우리 업무 기준과 맞는지 살핍니다.
- 팀에서 받은 Skill — 누가 어떤 업무에 쓰려고 만들었는지, 최신 기준이 반영돼 있는지 살핍니다.
- 외부에서 받은 Skill — 출처와 내용을 먼저 검토하고, 필요 이상으로 넓은 접근(파일·도구)을 요구하지 않는지 살핍니다.
외부 연결이나 파일 접근을 쓰는 Skill의 안전 점검 기준도 안전하게 쓰는 법에 함께 정리해 두었으니, 그쪽을 먼저 살펴보시면 됩니다.
검수가 막막할 땐 '이 Skill이 무슨 일을 하려는지 한 문장으로 말할 수 있나?'만 떠올려도 충분해요. 한 문장으로 설명하기 어렵다면 지침이 너무 넓거나 여러 일이 한데 섞였다는 신호니, 업무 하나에 초점을 맞춰 다시 좁히면 됩니다. 이 두 가지만 챙기면, 나머지는 편하게 시도하셔도 괜찮아요.
잘 만든 Skill은 팀의 자산이 됩니다
Skill은 혼자만의 도구로 끝나지 않아요. 개인이나 팀에서 직접 써 보다가 '이건 다른 사람한테도 도움이 되겠다' 싶은 방식이 생기면, 그걸 사례 글로 남겨 둘 수 있습니다. 잘 만든 Skill 하나가 팀 전체의 자산이 되는 거죠.
예를 들어 '회의록 정리에 드는 시간을 줄이려고 결정사항·담당자·마감일을 고정 형식으로 뽑는 Skill을 만들었다'처럼, 어떤 문제를 어떻게 풀었는지 함께 적어 두면 다른 팀에서도 바로 가져다 쓰기 좋아요. 공유 흐름은 생각보다 단순합니다.
- 개인이나 팀에서 먼저 써 봅니다 — 실제 업무에 몇 번 적용해 결과가 안정적인지 확인하는 단계예요.
- 효과가 반복되면 사례 글로 남깁니다 — 어떤 반복 업무에서 어떤 기준을 포장했는지, 무엇이 좋아졌는지 적습니다.
- 직접 만든 Claude Skill 파일을 그 글에 함께 둡니다 — 팀 위키·공용 폴더·블로그 어디든 좋아요.
- 동료가 그대로 내려받아 자기 계정에 올려 보면, 바로 참고할 수 있어요.
직접 써서 효과를 본 방식이 있다면 팀이나 커뮤니티에 사례로 남겨 주세요. 한 사람의 정리가 여러 사람의 시간을 아껴 줍니다. Claude Skills는 거창한 자동화 프로젝트가 아니에요 — 매번 같은 말을 반복하지 않도록, 우리 팀의 일하는 방식을 작게 포장해 두는 방법입니다.
이어서 보면 좋은 곳을 모아 뒀습니다.
- 프롬프트 잘 쓰는 법 — 한 번의 요청을 더 정확하게 쓰고 싶을 때.
- Projects — 자료와 배경지식을 작업공간으로 묶고 싶을 때.
- 안전하게 쓰는 법 — 넣어도 되는 정보와 넣지 말아야 할 정보를 확인할 때.
- 용어집·FAQ — 낯선 AI 용어를 빠르게 확인하고 싶을 때.
잘 다듬은 Skill 하나가 생겼다면, 같은 일을 반복하는 동료나 가족에게도 한 입 나눠줘 봐.