Claude Code의 Skill 기능을 사용하기 시작하면서, 업무 곳곳을 조금씩 스킬로 만들어 왔습니다.

어느덧 직접 만든 스킬은 누적 24개.

그중 7개는 사용하지 않게 되어 삭제했으므로, 현재 현역으로 사용 중인 것은 17개입니다.

아침의 태스크 정리, 의존성 패키지(dependency package) 조사, 월간 정형 업무, 코드 리뷰까지, "매번 하는 일"을 계속해서 스킬로 구현하고 있습니다.

이 기사에서는 현역 17개 중에서 「이것은 정말 효과가 있었다」라고 느낀 스킬 8가지를 무엇을 하는 것인지, 왜 효과적인지와 함께 소개합니다.

아울러, 버린 7개가 왜 사용되지 않게 되었는지와 그로부터 알 수 있었던 **「효과적인 스킬의 공통점」**도 정리했습니다.

직접 스킬을 만들어 보고 싶은 분들에게 참고가 된다면 좋겠습니다.

Skill 기능 자체에 대한 설명은 생략하겠습니다. 「SKILL.md라는 Markdown에 절차서를 작성해 두면, Claude가 의뢰 내용과의 관련성을 판단하여 호출해 주는 구조(/스킬명으로 명시적 호출도 가능)」 정도로 이해하고 읽으셔도 됩니다.

본론에 들어가기에 앞서, 스킬화의 효과를 한마디로 정의하자면 다음과 같습니다.

스킬이란, "매번 수행하는 작업의 절차와 판단 기준을 Markdown으로 작성한 것"입니다.

한 번 작성해 두면, 말을 거는 것만으로 Claude가 그 절차대로 움직여 줍니다.

효과는 크게 3가지입니다.

절차를 외울 필요가 없어진다 - 오랜만의 작업이라도 스킬이 절차를 가지고 있음

판단이 흔들리지 않는다 - "무엇을 우선할 것인가"를 명문화하므로 품질이 흔들리기 어려움

속인화(属人化, Silo)를 해소한다 - 자신의 머릿속에 있던 암묵지(tacit knowledge)가 누구나 사용할 수 있는 형태가 됨

그럼 실제로 효과가 있었던 8가지를 살펴보겠습니다.

캘린더, 태스크, 목표, Slack을 횡단하여, 오늘 해야 할 일을 우선순위와 함께 제안해 주는 스킬입니다.

매일 아침 "무엇부터 할까" 고민하며 사라지던 10~15분이, "브리핑해 줘"라고 말하는 것만으로 해결되었습니다.

메커니즘의 상세 내용은 별도 기사에 정리해 두었습니다: Claude Code로 캘린더, Obsidian, Slack을 횡단하여 매일 아침 태스크를 정리해 주는 비서를 만들었다

매달 1회 있는 정형 업무(특정 사이트의 리소스 상황 업데이트)를 공정별로 스킬화했습니다.

• 작업용 issue 생성
• CMS 값 업데이트
• 공지 기사 추가
• 완료 보고 게시

한 달에 한 번밖에 하지 않는 작업일수록 절차를 잊어버립니다.

스킬로 만들어 두면 "방법을 떠올리는" 비용이 제로가 되며, 환경만 갖춰져 있다면 누구나 동일한 절차로 실행할 수 있게 됩니다.

월간 업무를 스킬화하며 깨달은 점은, **「정해진 절차는 스킬, 판단이 필요한 부분은 대화」**라는 구분선의 중요성입니다.

전부 자동화하기보다, 변화할 수 있는 부분(확인·조정)은 대화로 남겨두는 편이 결과적으로 더 안정적이었습니다.

이 부분이 개인적으로 가장 효과를 보고 있는 영역입니다.

리뷰나 조사의 관점을 스킬에 심어 두면, 체크 누락이 크게 줄어듭니다.

Dependabot이 생성하는 의존성 업데이트 PR을, 의존성 체인(dependency chain)을 거슬러 올라가 루트 패키지(root package)를 특정하고 업데이트 전략을 제안해 주는 스킬입니다.

package-lock.json을 추적하거나 루트 패키지의 향후 버전을 조사하는 등의, 수고스럽지만 시간이 걸리는 1차 조사를 대신해 줍니다.

건당 5~10분 정도 걸리던 조사가 거의 순식간에 끝납니다.

CVE 번호나 GitHub Security Advisory URL을 전달하면, 지정된 리포지토리의 lock file을 해석하여 「우리에게 영향이 있는가」를 판정해 주는 스킬입니다.

"이 취약점, 우리랑 상관있나?"를 매번 수동으로 조사하는 것은 힘들지만, 스킬로 만들어 두면 입력값을 전달하는 것만으로 영향 여부와 대응 필요성을 반환합니다.

자신(Claude)의 조사 결과나 기사를 다른 AI(Codex)에게 독립적으로 리뷰시키는 스킬입니다.

기사를 쓰거나 기술 조사를 정리한 후, 이 스킬을 통해 Codex에게 팩트 체크(fact check)를 의뢰합니다.

버전 차이, 최신 사양, 전언(hearsay)의 혼입 등, 혼자서 확인하면 놓치기 쉬운 오류를 독립된 검증자가 다시 한번 씻어내 줍니다.

실제로 이 스킬을 통해 기사 내용 중 "확인되지 않은 예측을 단정적으로 작성했던" 부분이나 사실 오인을 여러 번 찾아낼 수 있었습니다.

AI의 결론을 다른 AI로 더블 체크(double check)하는 이 체제를 시스템화할 수 있다는 점이 흥미로운 부분입니다.

기술 블로그 작성을 지원하는 스킬로, 기획 아이디어 브레인스토밍(기획 모드)과 초안 체크(체크 모드)의 2가지 모드를 갖추고 있습니다.

포인트는 "독자에게 가치가 있는가", "구성의 비약이 없는가"와 같은 편집자의 관점을 스킬 측에 명문화해 두었다는 점입니다.

작성자인 자신과는 별개의 역할을 Claude에게 부여함으로써, 셀프 리뷰로는 알아차릴 수 없는 "자기만족적인 구성"을 지적해 줍니다.

이 기사의 초안도 이 스킬로 체크한 뒤에 공개하고 있습니다.

GitHub / Slack으로부터 그날의 자신의 액티비티를 자동으로 수집하여, 대화를 통해 소감을 끌어낸 뒤 일보(日報)를 생성하는 스킬입니다.

일보 작성에서 가장 시간이 많이 걸리는 것은 쓰는 것보다 "오늘 무엇을 했더라"라고 떠올리는 일입니다.

그 부분을 자동 수집에 맡기고, 인간은 소감이나 깨달음을 말하기만 하도록 만들었습니다.

프로젝트별 분류 규칙이나 표기법의 세세한 취향도 스킬에 적혀 있으므로, 매일 동일한 포맷으로 완성됩니다.

클라이언트에게 보내는 의뢰문이나 Slack 메시지를 전제를 모르는 상대에게도 전달될 수 있는 형태로 다듬는 스킬입니다.

"이 문구, 최적화해줘"라고 건네면, 애매한 표현이나 누락된 전제를 보완하여 긍정적이고 명확한 텍스트로 만들어 줍니다.

전달 방식 때문에 소모되기 쉬운 커뮤니케이션을 한 단계 더 편하게 만들어 주었습니다.

"효과를 본 8가지"만 보면 성공담처럼 보일 수도 있지만, 실제로는 24개를 만들어 7개를 버렸습니다.

얼마 전 스킬의 재고 조사를 하며 사용하지 않는 것들을 정리했습니다. 버린 목록은 다음과 같습니다.

범용 지식계 (3개): 퍼포먼스 최적화 · 프로그레시브 인핸스먼트 (Progressive Enhancement) · 보안 리뷰의 "관점 모음" 스킬. Claude가 이미 알고 있는 일반론을 스킬로 만들어도 쓸 일이 없었습니다 -
빈도가 부족했던 것 (1개): ADR (의사결정 기록) 작성 스킬. 작업 자체의 발생 빈도가 낮아 스킬화하는 비용을 회수할 수 없었습니다 -
콘텐츠용 (1개): 독설 리뷰를 해주는 "마사카리 소년" 스킬. 재미는 있었지만, 업무에서는 결국 부르지 않았습니다 -
역할을 다한 것 (2개): 일보 스킬의 구버전(⑦의 전신)과 Figma와 구현의 차이점 체크 스킬. 전자는 신버전으로 계승되었고, 후자는 사용할 상황이 이어지지 않았습니다

나열해 보면, 버린 이유는 **"일반론", "저빈도", "콘텐츠용", "역할을 다함"**의 4가지로 나뉩니다.

반대로 살아남은 것은 자신의 업무에 고유한 절차와 판단을 적은 스킬뿐이었습니다.

24개를 만들어 7개를 버린 경험을 통해, "효과적인 스킬"과 "만들었지만 쓰지 않는 스킬"의 차이가 보였습니다.

효과적인 스킬은 예외 없이 반복적으로 발생하는 작업이 대상입니다.

한 번밖에 하지 않을 일을 스킬로 만들어도 만드는 비용이 더 많이 듭니다.

"이거 전에도 했었지"라고 느껴지는 순간이 스킬화의 신호입니다.

"절차"뿐만 아니라, "무엇을 우선할 것인가", "어떻게 판단할 것인가"의 기준까지 적은 스킬일수록 출력이 안정됩니다.

반대로 절차만 있는 스킬은 상황이 조금만 바뀌어도 사용하기 어려워지기 쉽습니다.

스킬은 frontmatter의 description을 단서로 Claude가 "지금의 요청과 관련이 있는가"를 판단하여 실행됩니다 (키워드의 완전 일치가 아닙니다).

그렇기에 자신이 평소 사용하는 말투를 description에 폭넓게 넣어두면, 자연스러운 언어로 호출할 수 있어 결과적으로 자주 사용하게 됩니다.

의외일 수도 있지만, 판단이나 조정이 필요한 부분은 대화로 남기는 스킬이 더 오래 사용할 수 있습니다.

정해진 처리는 스킬로, 변화할 수 있는 부분은 대화로. 이 경계 짓기가 실용성을 가릅니다.

카테고리	스킬	효과
루틴 자동화	① 브리핑 / ② 월간 업무	매일·매월의 정형 업무를 말만 하면 됨
...

본 기사의 요점은 다음과 같습니다.

• 스킬이란 "매번 하는 작업의 절차와 판단 기준을 Markdown으로 적어 내려간 것"
• 반복하는 작업이야말로 스킬화의 대상. 단 한 번뿐인 작업은 수지타산이 맞지 않음
• 일반론적인 스킬은 사용되지 않음. 자신의 업무에 고유한 절차와 판단을 적은 스킬만이 살아남음
• 절차뿐만 아니라 판단 기준까지 적으면 출력이 안정됨
• 전부 자동화하지 않고, 판단이 필요한 부분은 대화로 남기는 것이 더 오래 쓸 수 있음
• 리뷰나 조사의 "관점"을 심어두는 스킬은 특히 비용 대비 효과가 높음

「이거, 전에도 했던 작업인데」라고 느껴지는 작업이 있다면, 그것은 스킬화(Skillization)의 기회입니다.

우선 가장 반복하고 있는 작업을 하나 골라 SKILL.md에 적는 것부터 시작해 보세요 (frontmatter의 description에 평소 사용하는 말투를 넣는 것을 잊지 마세요).