커맨드와 스킬

02이 차시를 마치면

• 1.자신이 반복해서 요청하고 있는 프롬프트 패턴을 스스로 찾아낼 수 있다.
• 2.반복되는 요청을 커스텀 슬래시 커맨드로 만들어 이름만으로 실행할 수 있다.
• 3.여러 단계로 이어지는 작업 절차를 스킬 하나로 묶어 패키징할 수 있다.
• 4.만든 커맨드와 스킬을 저장소에 커밋하고 문서화해 팀원과 공유할 수 있다.

03왜 필요한가

이번 주에도 PR을 올릴 때마다 '변경사항 요약해줘, 영향받는 파일 나열해줘, 테스트 결과 붙여줘'라는 문장을 매번 새로 타이핑했다고 해보자. 지난주에도 똑같이 썼고, 지지난주에도 똑같이 썼다. 매번 프롬프트를 다시 구성하는 데 드는 시간 자체는 크지 않지만, 미묘하게 다르게 표현할 때마다 결과 형식도 조금씩 달라져서 팀원이 리뷰할 때 일관성이 떨어진다. 팀원에게 '이렇게 물어보면 돼'라고 말로 설명해줘도, 그 사람은 또 자기 방식대로 새로 프롬프트를 짠다.

• ·같은 요청을 매번 처음부터 다시 타이핑하느라 시간이 샌다.
• ·조금씩 다르게 표현할 때마다 결과 형식이 들쭉날쭉해 팀원이 리뷰하기 어렵다.
• ·여러 단계로 이어지는 작업(예: 배포 전 점검)은 순서를 매번 기억해서 불러줘야 한다.
• ·나만 아는 노하우로 남아, 내가 자리를 비우면 그 작업 방식 자체가 사라진다.

04개념 설명

05실습 가이드

1. 1. 내 반복 작업 패턴 찾기

   • -최근 1~2주 동안 Claude Code와 나눈 대화 기록이나 터미널 히스토리를 훑어본다.
   • -세 번 이상 비슷한 형태로 요청한 프롬프트가 있는지 찾는다. (예: PR 요약 요청, 테스트 실행 후 정리 요청, 배포 전 점검 요청)
   • -후보를 최소 3개 이상 목록으로 적어둔다.

   예상 결과 — 반복 패턴 후보 3개 이상이 적힌 목록이 생긴다.

   안 될 때 — 딱히 반복한 기억이 안 나면 P5-1 프롬프트로 AI에게 최근 대화를 분석해달라고 요청한다.

2. 2. 커맨드 후보 3개 고르기

   • -목록 중 결과 형식이 매번 같아야 하는 것, 팀원도 똑같이 쓸 만한 것 위주로 3개를 고른다.
   • -이번 실습에서는 PR 요약, 테스트 실행 후 정리, 배포 전 점검 세 가지를 예시로 다룬다. 자신의 업무에 맞는 이름으로 바꿔도 된다.
   • -각 커맨드가 실행될 때 매번 달라질 값(예: PR 번호, 배포 대상 환경)이 무엇인지 미리 적어둔다.

   예상 결과 — 만들 커맨드 3개의 이름과, 각각 바뀌는 값이 정리된다.

   안 될 때 — 3개를 못 채우겠으면 하나는 이번 차시 예시(배포 전 점검)를 그대로 따라 만들어도 된다.

3. 3. 첫 번째 커맨드 만들기 — PR 요약

   • -P5-2 프롬프트로 AI에게 PR 요약 커맨드를 만들어달라고 요청한다.
   • -AI가 안내하는 위치에 파일을 만들고 내용을 채운다.
   • -실제 브랜치나 최근 커밋을 대상으로 커맨드를 한 번 실행해본다.

   예상 결과 — 커맨드를 실행하면 변경사항 요약, 영향받는 파일 목록이 정해진 형식으로 나온다.

   안 될 때 — 커맨드가 인식되지 않으면 파일 위치나 이름 규칙이 잘못됐을 수 있다. P5-6(복구 프롬프트)으로 AI에게 위치를 다시 확인받는다.

4. 4. 두 번째 커맨드 만들기 — 테스트 실행 후 정리

   • -P5-3 프롬프트로 테스트를 실행하고 실패/성공 결과를 보기 좋게 정리해주는 커맨드를 요청한다.
   • -일부러 테스트 하나를 실패하게 만들어보고, 실패 원인이 정리된 형태로 나오는지 확인한다.

   예상 결과 — 커맨드 실행 시 테스트 결과가 통과/실패로 구분되어 요약된다.

   안 될 때 — 프로젝트에 테스트가 아직 없다면, 이전 실습에서 만든 기능 중 하나에 간단한 테스트를 먼저 추가한 뒤 다시 시도한다.

5. 5. 세 번째 커맨드 만들기 — 배포 전 점검

   • -P5-4 프롬프트로 배포 전 점검(환경변수 확인, 빌드 확인, .gitignore 확인 등)을 자동으로 훑어주는 커맨드를 요청한다.
   • -실제로 배포하기 직전 상황을 가정하고 커맨드를 실행해본다.

   예상 결과 — 점검 항목별로 통과/미흡이 정리된 체크리스트가 출력된다.

   안 될 때 — 점검 항목이 프로젝트와 안 맞으면, 어떤 항목을 빼고 넣을지 AI에게 직접 알려주고 커맨드를 수정한다.

6. 6. 커맨드 3개를 스킬 하나로 묶기

   • -P5-5 프롬프트로 방금 만든 커맨드 3개를 순서대로 엮은 '릴리스 준비' 스킬을 만들어달라고 요청한다.
   • -스킬 안에 각 단계에서 무엇을 확인해야 하는지, 어떤 경우 중단해야 하는지 판단 기준도 같이 넣어달라고 요청한다.

   예상 결과 — 스킬 하나를 실행(또는 호출)하면 세 커맨드의 절차가 순서대로 이어져 진행된다.

   안 될 때 — 세 단계가 한 번에 안 이어지면, 먼저 두 단계만 묶어보고 성공하면 세 번째를 추가하는 식으로 범위를 줄여 접근한다.

7. 7. 스킬 동작 검증하기

   • -스킬을 실제 상황(또는 연습용 가짜 PR)에 적용해 처음부터 끝까지 실행해본다.
   • -중간에 문제가 있는 상태(예: 테스트 실패 상태)를 일부러 만들어, 스킬이 그 지점에서 멈추고 알려주는지 확인한다.

   예상 결과 — 정상 상황에서는 끝까지 진행되고, 문제 상황에서는 중간에 멈춰 원인을 알려준다.

   안 될 때 — 문제 상황에서도 그냥 통과해버리면, 중단 조건을 더 구체적으로 적어달라고 AI에게 요청해 스킬을 보완한다.

8. 8. 문서화하고 저장소에 커밋해 공유하기

   • -커맨드 3개와 스킬 1개 각각에 이름, 용도, 사용 예시를 짧게 적은 설명을 추가한다.
   • -만든 파일들을 프로젝트 저장소에 커밋한다.
   • -팀원(또는 스터디 동료)에게 저장소를 내려받아 실행해보게 하고, 설명만 보고 바로 쓸 수 있는지 피드백을 받는다.

   예상 결과 — 다른 사람이 저장소를 내려받아 설명만 보고 커맨드/스킬을 실행할 수 있다.

   안 될 때 — 상대가 못 찾겠다고 하면 파일 위치나 이름이 직관적이지 않은 것이다. README나 안내 문서에 목록을 추가한다.

06실전 프롬프트

최근 나눈 대화나 내가 자주 하는 요청들을 돌아보고,
비슷한 형태로 세 번 이상 반복한 요청 패턴이 있는지 찾아줘.

각 패턴마다
1. 어떤 상황에서 이 요청을 하는지
2. 매번 달라지는 값은 뭔지
3. 커맨드나 스킬로 만들면 좋을지 아닌지
를 정리해서 알려줘.

PR을 올릴 때마다 매번 요청하는 게 있어.
1. 변경된 파일 목록
2. 무엇을 왜 바꿨는지 요약
3. 영향받을 수 있는 다른 파일이나 기능

이걸 [/pr-summary] 같은 이름으로 불러서
바로 실행할 수 있는 커맨드로 만들어줘.

PR 번호나 브랜치 이름처럼 매번 달라지는 값은
실행할 때 내가 넣을 수 있게 해줘.
파일을 어디에 어떻게 만들면 되는지도 알려줘.

테스트를 돌릴 때마다 결과를 직접 눈으로 훑어서
통과/실패를 정리하는 게 번거로워.

테스트를 실행하고, 결과를
· 통과한 테스트 수
· 실패한 테스트 이름과 이유
· 다음에 뭘 확인해야 하는지
형태로 정리해서 보여주는 커맨드를 만들어줘.

이름은 [/test-report] 정도로 하고 싶어.

배포하기 직전에 매번 확인하는 게 있어.
1. 코드에 API 키나 비밀번호가 그대로 적혀 있는지
2. .gitignore에 빠진 게 없는지
3. 빌드가 에러 없이 되는지

이걸 [/pre-deploy-check]라는 커맨드로 만들어서
실행 한 번으로 항목별 통과/미흡을 체크리스트로 보여주게 해줘.

방금 만든 [/pr-summary], [/test-report], [/pre-deploy-check]
세 커맨드를 순서대로 이어서 "릴리스 준비"라는
스킬 하나로 묶어줘.

각 단계에서 문제가 있으면(예: 테스트 실패)
다음 단계로 넘어가지 말고 멈춰서 나에게 알려주는
판단 기준도 같이 넣어줘.

스킬을 어떻게 실행하거나 부르면 되는지도 알려줘.

방금 만든 [커맨드 또는 스킬 이름]을 실행했는데
이런 문제가 있어.

[실행했더니 나온 결과 또는 에러 그대로 붙여넣기]

내가 한 것: [실행한 순서 그대로]
기대했던 것: [원래 기대한 결과]

파일 위치나 형식이 문제인지, 지시문 내용이 문제인지
먼저 원인을 짚어주고 고친 버전을 줘.

07이것만은 주의

08자가 점검

09과제

이번 실습에서 만든 PR 요약·테스트 정리·배포 전 점검 외에, 자신의 실제 업무나 프로젝트에서 반복되는 작업 패턴을 하나 더 찾아 커맨드 또는 스킬로 만들어본다. 팀에서 함께 쓰는 저장소가 있다면 실제로 커밋해 팀원에게 공유하고 피드백을 받아본다.

제출 형식 — ① 새로 만든 커맨드(또는 스킬) 파일 ② 실행 전/후 화면 스크린샷 ③ 어떤 반복 패턴에서 착안했는지와 팀원 피드백(있다면)을 정리한 문서로 제출한다.

10더 알아보기

• Claude Code 공식 문서 — 커스텀 슬래시 커맨드 — 파일 위치와 이름 규칙, 매개변수 문법의 최신 사양 확인용
• Claude Code 공식 문서 — 스킬 — 스킬 구조와 자동 트리거 조건의 최신 사양 확인용

커스텀 슬래시 커맨드

— 자주 쓰는 프롬프트를 파일로 저장해두고 이름을 불러 실행하는 재사용 단위.

스킬(Skill)

— 여러 단계로 이어지는 작업 절차와 판단 기준을 하나로 묶어 패키징한 재사용 워크플로.

매개변수(placeholder)

— 커맨드나 스킬을 실행할 때마다 달라지는 값을 넣을 자리.

다음 차시 예고 — 다음 차시에서는 '부탁하는 규칙'과 '강제하는 장치'의 차이를 다룹니다. 이번 차시에서 만든 커맨드와 스킬을 실수로 건너뛰어도, 훅을 걸어두면 애초에 건너뛸 수 없게 만드는 방법을 배웁니다.