클로드 기초 및 활용 31회: 스킬 관리와 문제 해결 — 안 불릴 때, 너무 자주 불릴 때

만드는 건 쉽고, 관리는 어렵습니다

30회에서 스킬을 만들어 보셨습니다. 그런데 몇 주 지나면 이런 일이 생깁니다.

어떤 스킬은 한 번도 안 불려오고, 어떤 스킬은 부르지도 않았는데 자꾸 튀어나오고, 비슷한 게 세 개나 생겨 뭐가 뭔지 모르게 됩니다.

오늘은 그 관리법입니다. 그리고 제6부를 마무리합니다.

오늘의 목표

오늘이 끝나면 할 수 있게 되는 것: 스킬이 안 불릴 때 원인을 찾고, 너무 자주 불릴 때 조절하고, 정기적으로 정리하고, 팀과 공유할 수 있게 됩니다.

🔴 안 불릴 때 — 점검 순서 다섯 단계

가장 흔한 문제입니다. 위에서부터 순서대로 확인하세요.

1단계: 목록에 있나 — /를 쳐서 확인합니다. 없으면 파일 위치나 재시작 문제입니다(24회).

2단계: 불러서는 되나 — /이름으로 직접 불러 봅니다. 이것도 안 되면 파일 자체의 문제입니다.

3단계: 설명문에 상황이 적혀 있나 — "무엇을 한다"만 있고 "언제"가 없으면 판단할 수 없습니다(30회).

4단계: 내가 쓰는 표현이 들어 있나 — 설명문에 "회의록"만 있는데 나는 "미팅 정리"라고 말한다면 안 걸립니다.

5단계: 다른 스킬과 겹치나 — 비슷한 스킬이 여럿이면 다른 것이 선택될 수 있습니다.

진단을 클로드에게 시키기

가장 빠른 방법입니다.

"'회의록' 스킬의 설명문을 읽고, 어떤 상황에서 불려올 것 같은지 알려 줘. 그리고 제가 '이 미팅 내용 좀 정리해 줘'라고 했을 때 이 스킬이 선택될지 판단해 줘."

구체적인 문장을 주고 판단시키는 것이 요령입니다. 실제로 내가 쓰는 말로 시험하세요.

너무 자주 불릴 때

반대 문제입니다. 관련 없는 상황에서 자꾸 튀어나옵니다.

대처 세 가지

① 제외 조건 추가 — 30회에서 배운 것입니다. "○○에는 쓰지 않는다"를 명시합니다.

② 설명문 좁히기 — 너무 넓게 적힌 표현을 구체적으로 바꿉니다. "문서를 다룰 때" → "회의 내용을 정리할 때".

③ 수동 전용으로 만들기 — 설명문에 "이 스킬은 사용자가 직접 부를 때만 사용한다"고 적습니다. 자동 호출을 끄는 방법입니다.

③은 위험한 작업을 하는 스킬에 특히 유용합니다. 파일을 대량으로 바꾸는 종류라면 자동으로 불려오지 않는 편이 안전합니다.

비슷한 스킬이 여럿일 때

가장 골치 아픈 경우입니다. /정리, /요약, /회의록이 다 있으면 클로드도 헷갈립니다.

해결책은 셋 중 하나입니다.

• 합치기 — 하나로 통합하고 인자로 구분합니다. /정리 회의록처럼요
• 경계를 명확히 — 각 설명문에 "○○일 때는 △△ 스킬을 쓴다"고 서로 가리키게 합니다
• 지우기 — 안 쓰는 것을 없애는 게 가장 간단합니다

정기 정리 — 세 달에 한 번

12회·28회에서 반복한 이야기가 스킬에도 적용됩니다.

정리 순서

• 1. "내 스킬 목록을 보여 주고, 각각 무슨 일을 하는지 한 줄로 요약해 줘"
• 2. 한 번도 안 쓴 것을 확인 → 대개 지워도 됩니다
• 3. 서로 겹치는 것을 확인 → 합치거나 경계를 명확히
• 4. 내용이 낡은 것을 확인 → 고치거나 지웁니다

지우기를 망설이지 마세요. 필요하면 다시 만들면 됩니다. 그리고 다시 만들 때는 더 나은 것이 나옵니다.

고치는 법

말로 하면 됩니다. 24·30회에서 배운 그대로입니다.

"'회의록' 스킬의 설명 부분에 '미팅', '논의', '회의 내용' 같은 표현을 추가해 줘."

또는 파일을 직접 열어 고쳐도 됩니다. 어느 쪽이든 고친 뒤 재시작하고 시험하는 것을 잊지 마세요.

팀과 공유하기

스킬의 큰 가치 중 하나입니다. 노하우를 파일로 넘길 수 있다는 것요.

방법: 프로젝트용 스킬(작업 폴더의 .claude/skills/)로 만들고 폴더를 공유하면 됩니다. 그 폴더를 쓰는 사람 모두에게 적용됩니다.

공유 전 확인할 것

• 개인 취향이 섞이지 않았나 — 25회에서 말한 것과 같습니다
• 민감한 정보가 없나 — 스킬 파일도 평범한 텍스트 파일입니다
• 왜 그렇게 하는지 적혀 있나 — 15회에서 말한 "이유를 함께"가 여기서도 중요합니다

따라 하기 ① 현황 파악

"내 스킬 목록을 보여 주고, 각각 언제 쓰는 것인지 한 줄로 정리해 줘."

목록을 보고 "이건 뭐였지?" 싶은 게 있다면, 그건 설명이 부실하거나 안 쓰는 것입니다.

따라 하기 ② 실제 말투로 시험하기

스킬 하나를 골라, 평소 내가 쓰는 표현 세 가지로 시험해 보세요.

예를 들어 회의록 스킬이라면 — "회의 정리해 줘", "미팅 내용 좀 봐 줘", "이거 회의록으로 만들어 줘".

셋 중 하나라도 안 걸리면 그 표현을 설명문에 추가하세요.

따라 하기 ③ 안 쓰는 것 정리

목록에서 최근 한 달간 한 번도 안 쓴 것을 찾으세요.

왜 안 썼는지 판단합니다. 필요가 없어서라면 지우고, 불려오지 않아서라면 설명문을 고칩니다.

이 구분이 중요합니다. 후자를 지워 버리면 좋은 스킬을 잃습니다.

따라 하기 ④ 하나를 수동 전용으로

파일을 고치는 종류의 스킬이 있다면, 수동 전용으로 바꿔 보세요.

"이 스킬의 설명에 '사용자가 직접 이름을 불러 요청할 때만 사용한다'를 추가해 줘."

그리고 자동으로 안 불려오는지 확인하세요. 안전과 자동화의 균형을 직접 조절해 보는 실습입니다.

자주 겪는 오류 ① "고쳤는데 그대로예요"

재시작을 안 한 경우가 대부분입니다. /exit 후 다시 실행하세요.

그래도 그대로면 다른 파일을 고친 것일 수 있습니다. 개인용과 프로젝트용에 같은 이름의 스킬이 있으면 헷갈립니다. 경로를 확인하세요.

오류 ② "스킬이 절차를 건너뛰어요"

절차가 너무 길거나 모호한 경우입니다.

대책은 번호를 매기고 짧게 쓰는 것입니다. "① … ② … ③ …" 형태가 잘 지켜집니다.

그리고 단계마다 결과를 명시하면 더 좋습니다. "① 목록을 만든다 → 목록을 사용자에게 보여 준다"처럼요.

오류 ③ "스킬이 지침 파일과 충돌해요"

30회에서 다룬 문제입니다. 공통 규칙은 지침 파일에, 그 작업만의 것은 스킬에 두세요.

충돌이 이미 있다면 스킬 쪽에서 빼는 것이 원칙입니다. 지침 파일이 더 넓은 범위를 담당하니까요.

오류 ④ "너무 많이 만들었어요"

흔한 경로가 있습니다. 재미있어서 열 개를 만들고, 세 개만 쓰게 되는 것요.

일곱 개를 정리하세요. 아깝지 않습니다. 안 쓰는 스킬은 있는 것만으로도 방해가 됩니다. 자동 호출의 정확도를 떨어뜨리니까요.

실전 사례 ① 스킬 하나로 시작해 늘려 가기

권하는 방식입니다. 처음부터 여러 개 만들지 마세요.

• 1주차: 스킬 하나 만들고 실제로 씁니다
• 2주차: 아쉬운 점을 반영해 다듬습니다
• 3주차: 자동 호출이 잘 되는지 확인하고 설명문을 조정합니다
• 4주차: 그때 두 번째 스킬을 만듭니다

이 속도가 답답해 보이지만, 결과적으로 쓸모 있는 스킬만 남습니다.

실전 사례 ② 사고를 스킬에 반영하기

26회에서 "사고 한 번 = 규칙 한 줄"이라고 했습니다. 스킬에도 그대로 적용됩니다.

예를 들어 회의록 스킬이 없는 숫자를 만들어 낸 적이 있다면, 그 즉시 "하지 말 것"에 추가합니다.

"원문에 없는 수치는 절대 만들어 내지 않는다. 불명확하면 '확인 필요'라고 표시한다."

이렇게 쌓인 "하지 말 것" 목록이 그 스킬의 진짜 가치입니다.

실전 사례 ③ 저시력 사용자를 위한 스킬 점검

30회에서 만든 /읽기좋게 같은 접근성 스킬은 특별한 점검 항목이 있습니다.

① 자동 호출이 되는가 — 여기서는 이게 특히 중요합니다. 매번 이름을 불러야 한다면, "짧게 해 주세요"를 매번 말하던 것과 다를 게 없습니다. 안 불려온다면 설명문을 넓히세요. "결과가 길어질 것으로 예상될 때"처럼 조건을 폭넓게 적는 편이 이 경우엔 낫습니다.

② 예외 상황에서 방해가 되지 않는가. 가끔은 전체 내용을 봐야 할 때가 있습니다. 그때 스킬이 계속 요약만 준다면 답답합니다. "사용자가 '전체를 보여 달라'고 요청하면 이 스킬을 적용하지 않는다"를 넣어 두세요.

③ 지침 파일과 역할이 겹치지 않는가. 27·29회에서 다룬 구분입니다. 짧은 공통 규칙은 지침에, 여러 단계 절차는 스킬에. 양쪽에 같은 말이 있으면 하나를 지우세요.

정리하면 접근성 스킬은 일반 스킬과 조절 방향이 반대입니다. 보통은 "너무 자주 불리지 않게" 좁히지만, 이건 "놓치지 않게" 넓히는 쪽입니다. 매번 요청하는 부담을 없애는 것이 목적이니까요.

제6부를 마치며

27회부터 31회까지, 「메모리와 스킬」을 마칩니다.

• 27회 — 세 가지 기억 구분하기
• 28회 — 메모리 저장·관리와 개인정보 기준선
• 29회 — 스킬의 정체와 자동 호출
• 30회 — 스킬 만들기, 설명문이 핵심
• 31회 — 관리와 문제 해결

이 부의 주제는 "클로드가 나를 기억하게 만들기"였습니다. 제2부와 제5부가 반복을 줄이는 이야기였다면, 제6부는 쌓아 가는 이야기였습니다.

핵심 정리 3줄

• 안 불리면 설명문 문제입니다. 다섯 단계 점검 순서로 확인하세요.
• 안 쓰는 스킬은 지우세요. 있는 것만으로도 자동 호출의 정확도를 떨어뜨립니다.
• 하나씩 늘리세요. 한 달에 하나면 충분하고, 그래야 쓸모 있는 것만 남습니다.

용어 정리

• 점검 순서 — 목록 확인 → 직접 호출 → 설명문 → 표현 → 중복. 위에서부터 봅니다.
• 제외 조건 — "○○에는 쓰지 않는다". 엉뚱한 호출을 막습니다.
• 수동 전용 — 자동 호출을 끄고 직접 부를 때만 쓰게 하는 설정.
• 정기 정리 — 세 달에 한 번 목록을 훑고 안 쓰는 것을 지우는 일.

다음 회차 예고와 실습 과제

다음 회차부터 제7부 「MCP와 외부 서비스 연결」(32~35회)이 시작됩니다. 클로드를 "대화 상대"에서 "내 도구들을 다루는 비서"로 바꾸는 구간입니다. 비개발자에게 가장 진입장벽이 높은 주제라 네 회차에 걸쳐 충분히 나눠 다룹니다. 32회는 비유로 시작합니다.

실습 과제 두 가지

• ① 만든 스킬을 평소 쓰는 표현 세 가지로 시험하고, 안 걸리는 표현을 설명문에 추가해 보세요.
• ② 스킬 목록을 훑고 안 쓰는 것을 정리해 보세요. 지울지 고칠지 구분하는 것이 요령입니다.

①번에서 "이 표현으로는 안 걸리더라"는 사례가 있으면 댓글로 남겨 주세요. 설명문 쓰기의 실전 감각은 실패 사례에서 가장 잘 배웁니다.

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

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