클로드 기초 및 활용 29회: 스킬이란 무엇인가 — 반복 작업의 설명서

부르지도 않았는데 알아서 쓰는 것

24회에서 나만의 명령을 만들어 보셨습니다. 그런데 그때 마지막에 이런 이야기를 했습니다. "스킬은 여러분이 부르지 않아도 클로드가 스스로 쓸 수 있습니다."

이게 스킬의 핵심입니다. 그리고 이 성질 때문에 스킬은 단순한 단축키 이상이 됩니다.

오늘은 그 구조를 이해합니다. 이해하고 나면 30회에서 훨씬 나은 스킬을 만들 수 있습니다.

오늘의 목표

오늘이 끝나면 할 수 있게 되는 것: 스킬의 정체를 설명할 수 있고, 명령어·지침 파일과 어떻게 다른지 구분하고, 언제 자동으로 불려오는지 이해하고, 무엇을 스킬로 만들지 판단할 수 있게 됩니다.

스킬 = 반복 작업의 설명서

가장 정확한 비유입니다. 스킬은 "이 일은 이렇게 하는 겁니다"라고 적어 둔 설명서입니다.

회사에 신입이 들어왔다고 생각해 보세요. 매번 옆에서 알려 주는 대신 업무 매뉴얼을 주면, 그 사람이 필요할 때 꺼내 봅니다.

스킬이 정확히 그것입니다. 클로드에게 주는 매뉴얼이고, 필요하다고 판단하면 꺼내 봅니다.

명령어와 무엇이 다른가

24회에서 /정리 같은 것을 만들었습니다. 그건 스킬을 명령처럼 쓴 것입니다.

차이는 누가 꺼내는가에 있습니다.

• 명령으로 쓸 때 — 내가 /정리라고 부릅니다
• 스킬로 동작할 때 — 클로드가 "지금 이 상황엔 그 설명서가 필요하겠다"고 판단해 꺼냅니다

같은 파일이 두 가지 방식으로 쓰입니다. 그래서 24회에서 만든 것들도 이미 스킬이었던 겁니다.

지침 파일과 무엇이 다른가

25회의 CLAUDE.md와 헷갈리기 쉽습니다. 차이는 언제 읽히는가입니다.

• 지침 파일 — 항상 읽습니다. 작업 시작할 때마다요
• 스킬 — 필요할 때만 읽습니다. 관련 있는 상황에서만요

이 차이가 중요한 이유가 있습니다. 항상 읽는 것은 짧아야 합니다(25회에서 "길수록 나빠진다"고 한 이유). 반면 스킬은 길어도 됩니다. 필요할 때만 펼쳐지니까요.

🔴 나누는 기준

정리하면 이렇습니다.

• 모든 작업에 해당하는 짧은 규칙 → 지침 파일(CLAUDE.md)
• 특정 작업의 자세한 절차 → 스킬

예를 들어 "답은 짧게"는 모든 작업에 해당하니 지침 파일. "회의록을 정리하는 방법 열 줄"은 회의록 작업에만 해당하니 스킬.

이 기준 하나로 대부분 정리됩니다.

자동으로 불려오는 원리

클로드는 어떻게 "지금 이 스킬이 필요하다"고 판단할까요?

스킬 파일에 적힌 설명을 읽고 판단합니다. 그래서 설명을 어떻게 쓰느냐가 성패를 가릅니다. 30회의 핵심 주제가 바로 이것입니다.

모호하게 적으면 안 불려오거나, 엉뚱한 상황에서 불려옵니다. "언제 쓰는 것인지"를 분명히 적어야 합니다.

자동 호출이 왜 좋은가

내가 부르면 되는데 왜 자동이 필요할까요? 세 가지 이유가 있습니다.

① 이름을 기억할 필요가 없습니다. 스킬이 열 개를 넘어가면 뭐가 있었는지 잊습니다.

② 있는 줄도 몰랐던 상황에서 도움을 받습니다. 예전에 만들어 둔 스킬이 몇 달 뒤 비슷한 상황에서 자동으로 쓰입니다.

③ 남이 만든 것도 쓸 수 있습니다. 팀에서 공유한 스킬을, 그게 있는 줄 몰라도 클로드가 알아서 씁니다.

무엇을 스킬로 만드나

12회의 판별 기준이 여기서도 적용됩니다. 여기에 스킬 고유의 조건을 더하면 이렇습니다.

• 같은 일을 세 번 이상 했는가
• 절차가 여러 단계인가 — 한 줄로 끝나는 건 스킬이 아니어도 됩니다
• 지켜야 할 규칙이 있는가 — "이건 하면 안 된다" 같은 것
• 매번 같은 품질이 나와야 하는가

둘 이상 해당하면 스킬로 만들 가치가 있습니다.

스킬로 만들면 안 되는 것

• 한 문장으로 끝나는 요청 — "요약해 줘"는 그냥 말하는 게 빠릅니다
• 매번 조건이 완전히 다른 일 — 고정할 게 없습니다
• 모든 작업에 적용될 규칙 — 그건 지침 파일입니다

좋은 스킬의 구조

30회에서 실제로 만들 텐데, 미리 뼈대를 보여 드립니다. 잘 동작하는 스킬은 이런 요소를 갖습니다.

• 이름 — 짧고 기억나는 것
• 언제 쓰는가 — 자동 호출의 근거가 되는 부분. 가장 중요합니다
• 어떻게 하는가 — 실제 절차
• 하지 말 것 — 겪었던 실패
• 결과 형식 — 어떤 모양으로 내놓을지

두 번째 항목이 스킬을 스킬답게 만듭니다. 이게 없으면 그냥 저장된 요청문일 뿐입니다.

따라 하기 ① 지금 있는 스킬 확인하기

클로드 코드에서 /를 쳐서 목록을 보세요. 24회에서 만든 것이 있다면 거기 있을 겁니다.

기본으로 제공되는 것들도 있습니다. 어떤 것들이 있는지 훑어보세요. 이름과 설명만 봐도 스킬이 어떤 형태인지 감이 옵니다.

따라 하기 ② 자동 호출 관찰하기

재미있는 실습입니다. 24회에서 만든 스킬이 있다면, 이름을 부르지 말고 그 상황을 만들어 보세요.

예를 들어 /정리 스킬이 있다면, "이 메모 좀 봐 줘"라고만 하고 메모를 붙여 넣어 보세요.

클로드가 스스로 그 스킬을 쓰는지 관찰합니다. 쓴다면 설명이 잘 적힌 것이고, 안 쓴다면 설명이 모호한 것입니다.

따라 하기 ③ 후보 찾기

최근 한 달 동안 여러 번 반복한 작업을 세 개 적어 보세요.

그리고 각각에 대해 앞의 조건을 확인합니다. 세 번 이상 / 여러 단계 / 규칙 있음 / 품질 일정. 둘 이상 해당하는 것이 30회에서 만들 후보입니다.

따라 하기 ④ 클로드에게 물어보기

가장 쉬운 방법입니다.

"제가 최근에 반복적으로 요청한 작업 중에서, 스킬로 만들면 좋을 만한 게 있을까요? 이유와 함께 알려 주세요."

대화 기록을 보고 판단해 줍니다. 내가 못 보던 패턴이 나오기도 합니다.

자주 겪는 오해 ① "스킬은 프로그램이다"

아닙니다. 24회에서 말한 대로 글로 적은 지시문입니다.

코드가 실행되는 게 아니라, 클로드가 그 글을 읽고 그대로 행동합니다. 그래서 한국어로 적어도 되고, 애매하게 적으면 애매하게 동작합니다.

오해 ② "스킬과 명령어는 다른 것이다"

같은 것입니다. 부르는 방식이 두 가지일 뿐입니다.

내가 /이름으로 부르거나, 클로드가 상황을 보고 꺼내거나. 파일은 하나입니다.

오해 ③ "스킬이 많을수록 좋다"

아닙니다. 31회에서 다룰 주제인데, 너무 많으면 오히려 문제가 생깁니다.

비슷한 스킬이 여럿이면 클로드가 어느 것을 써야 할지 헷갈립니다. 그리고 자동 호출이 부정확해집니다.

적고 뚜렷한 것이 많고 흐릿한 것보다 낫습니다.

오해 ④ "자동으로 불려오면 위험한 것 아닌가"

합리적인 걱정입니다. 정리하면 이렇습니다.

스킬은 지시문일 뿐, 권한을 늘리지 않습니다. 20회에서 배운 승인 절차는 그대로 적용됩니다. 스킬이 파일을 고치려 해도 여전히 물어봅니다.

다만 스킬 안에 위험한 지시를 적어 두면 그건 문제입니다. 그래서 30회에서 "하지 말 것"을 적는 법을 다룹니다.

실전 사례 ① 문서 검토 스킬

스킬이 빛나는 전형적인 예입니다. 문서를 검토할 때마다 같은 것을 확인해야 하는 상황이요.

스킬에 적을 것: 언제 쓰는가(문서를 검토해 달라고 할 때) / 확인할 항목 목록 / 지적하는 형식 / 확실하지 않은 것은 표시할 것.

이렇게 해 두면 "이 문서 좀 봐 줘"라고만 해도 매번 같은 기준으로 검토됩니다. 부를 필요조차 없습니다.

실전 사례 ② 팀에서 기준 공유하기

15회에서 디자인 규격을 나누는 이야기를 했습니다. 스킬은 그것의 확장판입니다.

규격은 "이렇게 만들라"는 기준이고, 스킬은 "이런 상황엔 이렇게 하라"는 절차까지 담습니다.

프로젝트 폴더에 스킬을 넣어 두면(24회), 그 폴더를 쓰는 모든 팀원에게 같은 절차가 적용됩니다. 사람마다 다른 방식으로 하던 일이 통일됩니다.

실전 사례 ③ 저시력 사용자를 위한 스킬의 가치

24회에서 /짧게 스킬을 소개했습니다. 오늘 배운 자동 호출을 알고 나면 한 걸음 더 갈 수 있습니다.

부르지 않아도 적용되게 만드는 것입니다. 스킬 설명에 이렇게 적으면 됩니다.

"이 스킬은 사용자가 정보를 요청하는 모든 상황에서 적용한다. 결과는 다섯 줄 이내, 핵심부터, 목록은 다섯 항목 이내로 제시한다."

다만 여기서 중요한 판단이 하나 있습니다. 이런 성격의 것은 지침 파일에 두는 편이 대개 낫습니다(오늘 배운 기준: 모든 작업에 해당하는 짧은 규칙 → 지침 파일).

그러면 스킬은 언제 쓰느냐 — 절차가 여러 단계인 접근성 작업일 때입니다. 예를 들면 이런 것입니다.

스킬 이름: /읽기좋게
언제: 긴 문서나 복잡한 표를 다뤄 달라고 할 때
절차: ① 전체를 훑고 구조부터 세 줄로 알려 준다 ② 사용자가 볼 부분을 고르게 한다 ③ 고른 부분만 다섯 줄 이내로 정리한다 ④ 표가 필요하면 문장 설명을 반드시 병기한다
하지 말 것: 전체 내용을 한 번에 출력하지 않는다

이건 여러 단계 절차라 지침 파일에 넣기엔 길고, 특정 상황에만 필요하니 스킬이 맞습니다. 그리고 자동 호출이 되면 긴 문서를 만날 때마다 알아서 이 절차를 따릅니다.

핵심 정리 3줄

• 스킬은 반복 작업의 설명서입니다. 내가 부를 수도, 클로드가 꺼낼 수도 있습니다.
• 항상 필요한 짧은 규칙은 지침 파일, 특정 작업의 자세한 절차는 스킬.
• "언제 쓰는가"를 잘 적는 것이 핵심입니다. 자동 호출의 근거가 됩니다.

용어 정리

• 스킬 — 특정 작업의 절차를 적어 둔 파일. 명령으로 부르거나 자동으로 불려옵니다.
• 자동 호출 — 클로드가 상황을 보고 스스로 스킬을 꺼내 쓰는 것.
• 설명(언제 쓰는가) — 자동 호출의 판단 근거가 되는 부분.
• 지침 파일과의 차이 — 지침은 항상 읽히고 짧아야 하며, 스킬은 필요할 때만 읽히고 길어도 됩니다.

다음 회차 예고와 실습 과제

30회 「스킬 직접 만들기」에서는 실제로 만듭니다. 특히 설명문을 쓰는 법에 집중합니다. 오늘 여러 번 말한 대로, 그 한 줄이 스킬의 성패를 가릅니다.

실습 과제 두 가지

• ① 24회에서 만든 스킬이 있다면, 이름을 부르지 말고 그 상황을 만들어 자동으로 불려오는지 관찰해 보세요.
• ② 클로드에게 "제 요청 중 스킬로 만들 만한 게 있을까요?"라고 물어 후보를 받아 보세요.

①번에서 자동으로 안 불려왔다면 그 스킬의 설명이 어떻게 적혀 있었는지 댓글로 남겨 주세요. 30회에서 다룰 좋은 예/나쁜 예의 실제 재료가 됩니다.

본 회차는 2026년 8월 2일 기준입니다. 스킬의 동작 방식과 자동 호출 사양은 버전에 따라 바뀔 수 있습니다. 화면과 이 글이 다르면 화면이 맞습니다.

협업문의 : kuroicode@gmail.com
블로그 : https://ghost-production-0ec2.up.railway.app/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/