GYMCODING

클로드 코드 스킬 추천 5개: 설치 방법·실전 프롬프트·코드 예시

클로드 코드 스킬 5개의 차이와 설치 방법을 정리했습니다. 바로 복사할 실전 프롬프트와 UI 애니메이션·프로토타입·AI 디자인 검사 예시까지 확인하세요.

이런 분을 위한 글입니다

  • Claude Code에 스킬을 설치해 실무에 활용하고 싶은 분
  • AI가 만든 UI의 완성도를 높이고 싶은 프론트엔드 개발자
  • 코드를 만들기 전에 더 빠르게 검증하고 싶은 분

읽고 나면 이렇게 달라집니다

  • Claude Code 스킬 5개의 역할을 구분할 수 있다
  • 각 스킬의 설치 명령어와 바로 복사해 쓸 프롬프트를 얻는다
  • 결과를 코드에 반영할 때 무엇을 확인해야 하는지 알 수 있다

Claude Code를 오래 써도 결과가 비슷하게 느껴질 때가 있습니다. 코드는 만들어주지만 어떤 UI 라이브러리를 골라야 할지, 어디에 애니메이션이 필요한지, AI 특유의 디자인을 어떻게 걷어낼지는 결국 사용자가 다시 판단해야 합니다.

이럴 때 스킬을 추가하면 Claude Code에 특정 분야의 판단 기준과 작업 절차를 더할 수 있습니다. 이번 글에서는 이전 콘텐츠에서 다루지 않았던 다섯 가지 스킬만 살펴봅니다. 각 스킬 제작자가 공개한 원문을 기준으로 역할, 설치 방법, 복사해서 쓸 프롬프트와 코드 예시를 함께 정리했습니다.

  • find-animation-opportunities: 움직임이 필요한 곳을 찾습니다.
  • pick-ui-library: 상황에 맞는 UI 라이브러리 하나를 고릅니다.
  • prototype: 하나의 질문에 답하는 작은 실험을 만듭니다.
  • animate: 실제 애니메이션을 구체적인 값과 코드로 구현합니다.
  • kill-ai-slop: AI가 만든 티가 나는 디자인과 문장을 찾습니다.

핵심 요약: 어떤 스킬을 언제 써야 할까

Claude Code 스킬을 하나만 고른다면 지금 해결하려는 문제를 기준으로 선택하세요. 구현 전 방향 검증은 prototype, UI 도구 선택은 pick-ui-library, 애니메이션 후보 탐색은 find-animation-opportunities, 실제 모션 구현은 animate, AI 특유의 디자인과 문장 점검은 kill-ai-slop이 맞습니다.

질문
어디에 애니메이션을 넣어야 할까?find-animation-opportunities로 후보만 찾습니다.
어떤 UI 라이브러리를 써야 할까?pick-ui-library로 현재 프로젝트에 맞는 하나를 고릅니다.
이 아이디어를 개발해도 될까?prototype으로 질문 하나만 빠르게 검증합니다.
선택한 UI를 자연스럽게 움직이려면?animate로 값과 코드를 구현합니다.
결과물에서 AI가 만든 티를 줄이려면?kill-ai-slop으로 검사한 뒤 의도하지 않은 항목만 수정합니다.
이 글의 프롬프트는 그대로 복사해도 됩니다. 다만 src/app, Dashboard, Toast 같은 경로나 이름은 자신의 프로젝트에 맞게 바꾸세요.

시작하기 전에 알아둘 점

이 글에서는 여러 코딩 에이전트를 지원하는 오픈 소스 skills CLI로 스킬을 설치합니다. Claude Code 자체에 내장된 설치 명령은 아닙니다. 프로젝트 폴더에서 터미널을 열고 npx skills add 명령을 실행한 뒤, 설치 대상을 묻는 화면에서 Claude Code를 선택하세요. 프로젝트가 아니라 사용자 전체에 설치하려면 -g 옵션을 추가할 수 있습니다.

설치가 끝난 뒤에는 스킬 이름만 말하기보다 대상, 목표, 제약, 원하는 결과 형식을 함께 적는 것이 좋습니다.

[대상] src/components 안의 UI를 확인해줘.
[목표] 사용자가 상태 변화를 더 쉽게 알아차리게 해줘.
[제약] 기존 디자인 토큰을 유지하고 과한 효과는 제외해줘.
[결과] 파일과 줄 번호, 이유, 적용할 값 순서로 정리해줘.

1. find-animation-opportunities: 어디를 움직여야 할지 찾기

npx skills add emilkowalski/skills --skill find-animation-opportunities

이 스킬은 애니메이션을 직접 구현하지 않습니다. 프로젝트를 읽고 움직임이 정말 필요한 부분만 골라서 제안합니다. “화면을 더 화려하게 만들어줘”보다 “사용자가 놓치는 상태 변화를 찾아줘”라는 요청에 잘 맞습니다.

원본 스킬은 후보를 네 가지 기준으로 거릅니다. 사용 빈도, 움직임의 목적, 적절한 속도, 기능에 도움이 되는지를 확인합니다. 자주 여닫는 메뉴나 키보드 중심 기능에는 애니메이션이 오히려 느리게 느껴질 수 있습니다. 반대로 모달, 토스트, 빈 화면, 완료 상태처럼 가끔 보는 장면은 움직임이 상태를 설명하는 데 도움이 됩니다.

그대로 복사할 프롬프트

find-animation-opportunities 스킬을 사용해 현재 프로젝트를 점검해줘.

대상:
- src/components
- src/app/dashboard

목표:
- 상태가 갑자기 바뀌어 사용자가 흐름을 놓치는 곳을 찾아줘.
- 버튼 클릭 피드백이 없는 곳을 찾아줘.
- 패널, 모달, 토스트가 등장한 위치와 사라지는 방향이 어긋나는지 확인해줘.

제약:
- 코드는 수정하지 마.
- 단순히 예뻐 보이기 위한 애니메이션은 제외해줘.
- 최대 5개만 중요도순으로 제안해줘.
- 기존 애니메이션 라이브러리와 디자인 토큰을 우선 사용해줘.

각 제안마다 파일과 줄 번호, 움직임의 목적, duration, easing,
시작 상태와 종료 상태를 적어줘.

프로젝트마다 결과는 다르지만 다음처럼 실행 가능한 제안을 받을 수 있습니다.

대상: src/components/SaveButton.tsx:42
목적: 클릭 피드백
제안: active 상태에서 scale(0.97)
시간: 160ms
곡선: ease-out
이유: 저장 요청을 눌렀다는 즉각적인 피드백이 없음
.saveButton {
  transition: transform 160ms ease-out;
}

.saveButton:active {
  transform: scale(0.97);
}
이 스킬은 조사와 제안이 목적입니다. 코드를 바꾸지 않도록 프롬프트에 명시하고, 마음에 드는 제안만 다음 단계에서 구현하세요.

2. pick-ui-library: 후보 말고 하나를 고르게 하기

npx skills add emilkowalski/skills --skill pick-ui-library

Claude Code에 “토스트 라이브러리 추천해줘”라고 물으면 여러 후보와 장단점을 길게 나열할 때가 있습니다. 문제는 마지막 선택이 다시 사용자 몫으로 남는다는 것입니다.

pick-ui-library는 요구사항과 현재 기술 구성을 확인한 뒤 제작자가 선별한 목록에서 라이브러리 하나를 선택하도록 돕습니다. 먼저 package.json을 확인하고, 이미 목록 안의 라이브러리를 쓰고 있다면 그 도구를 유지합니다. 경쟁 라이브러리가 설치돼 있을 때는 사용자가 요청하지 않은 의존성 교체를 강행하지 않습니다. 이미 잘 만들어진 도구가 있는데 토스트나 다이얼로그를 처음부터 직접 구현하는 일을 피하는 데 특히 유용합니다.

그대로 복사할 프롬프트

pick-ui-library 스킬을 사용해 이 프로젝트의 토스트 라이브러리를 골라줘.

먼저 package.json과 기존 UI 코드를 확인해줘.
요구사항은 다음과 같아.

- React와 TypeScript를 사용 중이야.
- 저장 성공과 실패 메시지가 필요해.
- 키보드 접근성과 화면 읽기 도구를 지원해야 해.
- 번들 크기가 과하게 커지면 안 돼.
- 유지보수가 활발한 라이브러리를 원해.

후보를 여러 개 나열하지 말고 가장 적합한 하나만 선택해줘.
선택 이유, 설치 명령어, 최소 사용 예시, 도입할 때 주의할 점을 알려줘.
아직 코드는 수정하지 마.

예를 들어 Sonner가 선택됐다면 다음 정도로 시작할 수 있습니다.

npm install sonner

다음 코드는 Sonner의 toast 함수를 이미 불러왔다는 전제의 사용 예시입니다.

async function handleSave() {
  try {
    await saveData();
    toast.success("저장했습니다.");
  } catch {
    toast.error("저장하지 못했습니다.");
  }
}

실제 React 프로젝트에서는 패키지 공식 문서의 ESM 방식으로 toast와 알림 표시 컴포넌트를 불러옵니다. 앱의 최상위 레이아웃에는 알림 표시 컴포넌트를 한 번만 배치하고, 각 기능에서는 위 코드처럼 성공과 실패 시점에 toast 함수를 호출합니다.

중요한 것은 특정 라이브러리 이름을 외우는 것이 아닙니다. 프로젝트의 프레임워크, 이미 설치된 패키지, 접근성 요구사항을 먼저 읽게 한 뒤 하나를 선택하게 하는 과정이 핵심입니다.

이 스킬은 제작자가 선별한 목록에서 도구를 고릅니다. 패키지의 최신 배포일, 보안 공지, 현재 번들 크기를 실시간으로 보증하는 도구는 아니므로 중요한 프로젝트라면 선택 후 공식 문서와 패키지 정보를 한 번 더 확인하세요.

선택 후 이어서 쓸 프롬프트

방금 선택한 라이브러리로 구현 계획을 세워줘.

- Toaster를 어느 레이아웃에 한 번만 배치할지 정해줘.
- 기존 alert 호출을 교체할 파일을 찾아줘.
- 성공, 실패, 로딩 메시지의 사용 기준을 정해줘.
- 먼저 변경할 파일 목록과 이유만 보여주고 내 확인을 기다려줘.

3. prototype: 개발 전에 질문 하나만 검증하기

npx skills add mattpocock/skills --skill prototype

프로토타입은 작은 완성품이 아닙니다. 하나의 질문에 답하기 위한 버리는 코드입니다.

예를 들어 결제 상태가 다섯 가지라면 문서만 읽고 예외 상황을 모두 떠올리기 어렵습니다. 이때 작은 터미널 프로그램으로 상태 변화를 눌러보면 모델이 맞는지 빠르게 확인할 수 있습니다. 화면 구성이 고민이라면 같은 데이터를 사용한 서로 다른 UI 시안을 한 화면에서 전환해 비교할 수 있습니다.

  • 로직 질문: 상태를 바꿔보는 작은 터미널 프로그램
  • UI 질문: 한 경로에서 전환하며 비교하는 여러 UI 시안

UI를 비교하는 프롬프트

prototype 스킬을 사용해 다음 질문에 답하는 일회용 UI 프로토타입을 만들어줘.

질문:
대시보드에서 사용자가 이번 달 운동 달성률과 다음 운동을
동시에 가장 빠르게 파악할 수 있는 구성은 무엇인가?

조건:
- 같은 데이터를 사용한 서로 다른 시안 3개를 만들어줘.
- 하단 전환 바에서 시안을 즉시 바꿀 수 있게 해줘.
- 기존 프로젝트의 폰트와 색상 토큰만 사용해줘.
- 데이터 저장, API 연결, 테스트, 예외 처리는 만들지 마.
- PROTOTYPE임을 파일 상단과 화면에 표시해줘.
- 실행 명령어는 하나만 제공해줘.

완성한 뒤 각 시안의 장단점과 확인해야 할 질문을 정리해줘.
프로덕션 코드에는 합치지 마.

상태 모델을 확인하는 프롬프트

prototype 스킬을 사용해 구독 상태 모델을 검증해줘.

확인할 질문:
trial 사용자가 결제에 실패한 뒤 재시도하고 취소할 때
상태 전이가 모순 없이 동작하는가?

상태: trial, active, past_due, canceled
동작: start_trial, pay, payment_failed, retry, cancel

요구사항:
- 터미널에서 동작을 선택할 수 있게 해줘.
- 매 동작 뒤 전체 상태와 가능한 다음 동작을 출력해줘.
- 상태는 메모리에만 보관해줘.
- 테스트, 데이터베이스, 추상화는 만들지 마.
- 잘못된 전이를 발견하면 마지막에 목록으로 정리해줘.

프로토타입이 답을 줬다면 검증된 결정만 실제 코드에 반영합니다. 실험 코드를 그대로 제품 코드로 발전시키기 시작하면 빠른 검증이라는 목적을 잃기 쉽습니다.

프로토타입의 결과물보다 “어떤 질문에 어떤 답을 얻었는가”를 남기는 것이 중요합니다. 결정은 이슈나 문서에 기록하고, 실험 코드는 제품 코드와 분리하세요.

4. animate: 움직임을 구체적인 값으로 구현하기

npx skills add emilkowalski/skills --skill animate

find-animation-opportunities가 움직일 곳을 찾는 스킬이라면 animate는 선택한 장면을 실제 코드로 만드는 스킬입니다.

좋은 애니메이션 요청에는 “부드럽게” 같은 느낌만 들어가면 부족합니다. 무엇이 움직이는지, 어디서 시작하는지, 얼마나 걸리는지, 중간에 다시 조작했을 때 어떻게 반응하는지를 함께 정해야 합니다.

그대로 복사할 프롬프트

animate 스킬을 사용해 설정 패널의 열기와 닫기 애니메이션을 구현해줘.

대상:
- src/components/SettingsPanel.tsx
- 해당 스타일 파일

목표:
- 패널이 버튼에서 이어져 나오는 것처럼 느껴져야 해.
- 열기와 닫기 도중 다시 클릭해도 자연스럽게 방향을 바꿔야 해.
- 배경 콘텐츠는 움직이지 않아야 해.

제약:
- 기존 패키지와 디자인 토큰을 먼저 확인해줘.
- 새 라이브러리는 꼭 필요할 때만 추가해줘.
- transform과 opacity를 우선 사용해줘.
- prefers-reduced-motion도 지원해줘.
- scale(0)에서 시작하지 마.
- 구현 후 변경한 duration과 easing의 이유를 설명해줘.

예를 들어 작은 팝오버라면 다음처럼 시작점을 잡을 수 있습니다.

.popover {
  opacity: 1;
  transform: scale(1);
  transform-origin: var(--transform-origin, top right);
  transition:
    opacity 180ms cubic-bezier(0.23, 1, 0.32, 1),
    transform 180ms cubic-bezier(0.23, 1, 0.32, 1);
}

@starting-style {
  .popover {
    opacity: 0;
    transform: scale(0.97);
  }
}

@media (prefers-reduced-motion: reduce) {
  .popover {
    transform: none;
    transition: opacity 120ms ease-out;
  }

  @starting-style {
    .popover {
      opacity: 0;
      transform: none;
    }
  }
}

scale(0) 대신 형태가 남는 scale(0.97)에서 시작합니다. Base UI처럼 --transform-origin을 제공하는 라이브러리에서는 클릭한 요소를 기준으로 커지고, 변수가 없으면 예시의 top right가 대체값으로 사용됩니다. @starting-style을 지원하지 않는 브라우저까지 대응해야 한다면 상태 속성이나 모션 라이브러리를 이용한 대체 구현이 필요합니다. 움직임 줄이기 설정에서는 위치와 크기 변화는 없애고, 상태 이해를 돕는 짧은 투명도 전환만 남깁니다.

구현 뒤 검증 프롬프트

방금 구현한 애니메이션을 다시 확인해줘.

- 빠르게 두 번 클릭했을 때 처음부터 재시작하지 않는지 확인해줘.
- 열기와 닫기의 이동 경로가 대칭인지 확인해줘.
- 키보드로 조작해도 포커스가 올바른지 확인해줘.
- 느린 기기에서 레이아웃 변경을 반복해서 일으키는 속성이 없는지 확인해줘.
- 문제가 있으면 수정 전과 수정 후 코드를 비교해서 보여줘.

5. kill-ai-slop: AI가 만든 티를 코드에서 찾기

npx skills add yetone/kill-ai-slop --skill kill-ai-slop

AI가 만든 웹 화면은 서로 다른 서비스인데도 비슷해 보일 때가 있습니다. 보라색 그라데이션, 유리 효과, 이모지 아이콘, 과한 알약 모양 배지, 카드 안의 카드처럼 자주 반복되는 선택 때문입니다.

kill-ai-slop은 현재 스킬 내부 taxonomy 문서를 기준으로 35가지 AI 특유의 디자인·문장 패턴을 프로젝트에서 찾아 파일과 줄 번호로 보여줍니다. React, Vue, Svelte, Astro, Tailwind, HTML, PHP, 마크다운처럼 웹 프로젝트에서 자주 쓰는 파일을 검사할 수 있습니다.

먼저 검사만 하는 프롬프트

kill-ai-slop 스킬을 사용해 이 프로젝트를 검사해줘.

대상:
- src
- README.md

진행 방식:
1. 먼저 검사만 하고 코드는 수정하지 마.
2. 발견한 항목을 파일과 줄 번호로 정리해줘.
3. 사용자 경험에 미치는 영향이 큰 순서로 묶어줘.
4. 브랜드 의도로 보이는 표현은 자동으로 제거하지 말고 따로 표시해줘.
5. 각 항목마다 왜 AI가 만든 것처럼 보이는지 설명해줘.
6. 수정한다면 무엇으로 바꿀지 한 줄씩 제안해줘.

일반적인 설치에서는 Claude Code에 위 프롬프트를 입력하면 스킬이 포함한 스캐너를 찾아 실행합니다. 아래 명령은 공식 저장소를 직접 내려받아 저장소 루트에서 실행할 때만 사용하세요.

node skill/scripts/scan.mjs path/to/project
node skill/scripts/scan.mjs path/to/project --json

스캐너는 의존성 없이 동작하며 파일을 자동 수정하지 않습니다. 결과는 출발점일 뿐이므로 실제 코드를 읽어 의도된 디자인인지 다시 판단해야 합니다. 검사 결과는 대략 다음과 같은 형태입니다.

slop 15  이모지 도배         src/App.tsx:1254
slop 19  유리 효과           src/App.tsx:1301
slop 26  튕기는 호버         src/App.tsx:1311
slop 30  01/02/03 번호       src/App.tsx:757

골라서 수정하는 프롬프트

검사 결과 중 아래 항목만 수정해줘.

- 과한 그라데이션 글자
- 카드 안에 다시 들어간 카드
- 의미 없이 반복되는 알약 배지
- “단순한 X가 아니라 Y입니다” 형식의 문장

제약:
- 브랜드 색상과 정보 구조는 유지해줘.
- 디자인을 밋밋하게 만드는 것이 아니라 계층을 명확하게 만들어줘.
- 한 번에 한 유형씩 수정하고 변경 내용을 보여줘.
- 각 단계가 끝날 때 검사기를 다시 실행해 남은 항목을 알려줘.
- 내가 확인하기 전에는 다음 유형으로 넘어가지 마.
검사에 잡혔다고 무조건 나쁜 디자인은 아닙니다. 브랜드가 의도적으로 사용하는 그라데이션이나 배지도 있을 수 있습니다. 자동 삭제보다 “왜 필요한가”를 설명할 수 없는 요소부터 정리하세요.

다섯 스킬을 어떤 순서로 쓰면 좋을까

1단계: prototype으로 방향을 확인합니다 화면이나 상태 모델에서 가장 중요한 질문 하나를 정하고 작은 실험으로 답을 얻습니다.

2단계: pick-ui-library로 도구를 결정합니다 직접 만들 필요가 없는 UI 기능은 프로젝트에 맞는 검증된 라이브러리 하나를 선택합니다.

3단계: find-animation-opportunities로 필요한 움직임만 찾습니다 코드를 수정하기 전에 상태 변화와 피드백이 부족한 부분을 최대 다섯 개로 좁힙니다.

4단계: animate로 선택한 장면을 구현합니다 시작 상태, 종료 상태, 시간, 곡선, 중단 가능성, 움직임 줄이기 설정까지 코드에 반영합니다.

5단계: kill-ai-slop으로 마지막 흔적을 점검합니다 AI가 반복해서 선택하는 디자인과 문장 패턴을 찾고 브랜드 의도가 없는 항목만 정리합니다.

지금 가진 문제사용할 스킬
화면 방향을 정하지 못했다prototype
어떤 UI 도구를 써야 할지 모르겠다pick-ui-library
어디에 움직임이 필요한지 모르겠다find-animation-opportunities
움직임을 실제 코드로 만들고 싶다animate
결과물에서 AI가 만든 티를 줄이고 싶다kill-ai-slop

자주 묻는 질문

마무리

스킬을 많이 설치한다고 Claude Code의 결과가 자동으로 좋아지는 것은 아닙니다. 더 중요한 것은 현재 문제를 정확히 구분하는 일입니다.

방향을 검증해야 하는지, 라이브러리를 골라야 하는지, 움직일 곳을 찾아야 하는지, 실제 애니메이션을 구현해야 하는지, 마지막으로 AI 특유의 흔적을 지워야 하는지부터 판단하세요. 그런 다음 맞는 스킬 하나와 구체적인 프롬프트를 사용하면 됩니다.

이 글의 프롬프트를 자신의 프로젝트 경로와 목표에 맞게 바꿔서 바로 사용해보세요.

짐코딩 뉴스레터
AI 개발·클로드 코드 실전 노하우를 이메일로 받아보세요. 도움 되는 글만.

구독하면 마케팅 정보 수신 및 개인정보처리방침에 따른 이메일 수집·이용에 동의하게 됩니다. 언제든 수신거부할 수 있어요.