4. 스킬과 슬래시 커맨드 — 어떤 반복을 한 줄로 응고할 가치가 있는가

이 글은 시리즈 Alice 활용법의 4편이다. 2편 페르소나 설계와 3편 메모리 시스템이 mind를 어디에 새기고 어디에 잡아 두는가를 다뤘다면, 이 글은 그 다음 단계 — mind의 반복되는 동작을 어떻게 한 줄로 줄일 것인가에 대한 기록이다.

0. 스킬은 mind의 반복을 한 줄로 응고한다

운영자의 mind에는 두 종류의 내용이 있다. 한 종류는 "지금 무엇을 결정해야 하는가"고, 다른 종류는 "이 결정을 어떤 절차로 풀어 갈 것인가"다. 앞의 것은 매번 다르다. 뒤의 것은 자주 같다.

매일 같은 절차가 반복되는데 매일 같은 말로 협업자에게 설명하고 있다면, 그 절차는 mind의 동작 패턴으로 굳어진 것이다. 굳어진 동작은 한 줄짜리 이름을 가질 자격이 있다.

스킬과 슬래시 커맨드는 그 이름이다. mind의 반복되는 동작 패턴을 한 단어 호출로 응고하는 일. 같은 절차를 매일 풀어 설명하지 않아도 되도록, 그 절차에 이름을 붙여 두는 것.

이 글은 어떤 반복이 그 이름을 받을 자격이 있는지, 그리고 그 이름을 어떻게 설계하는지에 대한 기준의 모음이다.

참고로 "스킬"이라는 메커니즘 자체는 Anthropic Claude Code의 Skill 시스템에서 차용했다. 이 글은 그 메커니즘을 어떻게 활용했는가에 대한 기록이지, 그 자체의 발명이 아니다.

1. 승급 기준 — 어떤 반복이 스킬로 올라가는가

운영자가 매일 하는 절차의 모두가 스킬이 되어야 하는 것은 아니다. 다음 다섯 가지 기준을 모두 통과하는 것만 한 줄짜리 이름을 받는다.

1.1 두 번 이상 반복되었는가

한 번은 우연이다. 두 번은 패턴이다. 두 번 이상 같은 절차를 한 적이 있어야 스킬 후보가 된다.

이 기준이 가장 단순하지만 가장 자주 어겨진다. "이거 매번 할 것 같으니 미리 스킬로 만들어 두자" 같은 충동을 거른다. 미래의 반복은 추정이고, 두 번의 반복은 사실이다. 사실 기반으로만 승급.

1.2 시작-끝이 명확한가

스킬은 시작 조건과 끝나는 조건이 명확해야 한다. "프로젝트에 진입한다", "세션을 마무리한다", "lint 후 빌드한다" 같은 것은 시작과 끝이 분명하다. 반면 "코드를 작성한다" 같은 것은 시작도 끝도 흐려서 스킬이 되지 않는다.

명확하지 않으면 스킬을 호출한 뒤 협업자가 어디서 멈춰야 할지 모른다. 끝이 모호한 스킬은 결국 매번 운영자가 멈춰 세워야 한다.

1.3 호출 시점이 결정 가능한가

호출 시점은 두 가지로 나뉜다. 운영자가 의식적으로 호출(슬래시 커맨드)하거나, 시스템이 자동으로 호출(훅 — 다음 편 주제)하거나. 어느 쪽이든 호출 시점이 결정 가능해야 한다.

호출 시점이 "그때그때 다르다" 같은 것은 스킬이 아니다. 그런 것은 협업자가 매번 판단해야 하는 일이고, 그 판단 자체가 매번 다른 mind를 요구한다.

1.4 매번 같은 입력을 받는가 (또는 단순한 인자만 받는가)

스킬의 입력은 단순해야 한다. 인자가 없거나, 한 두 개의 짧은 인자만 받거나. 인자가 많으면 그것을 매번 채워 넣는 것 자체가 새로운 절차가 되어 버린다.

좋은 스킬 인자	나쁜 스킬 인자
없음 (/session-end)	5개 이상 옵션
짧은 식별자 1개 (/start vsub)	긴 자유 텍스트
명확한 enum (/loop 5m)	"어떻게 처리할지 알려줘" 같은 의도

1.5 결과가 일관되게 검증 가능한가

스킬은 실행 후 결과를 협업자가 자체 검증할 수 있어야 한다. "성공" "실패" "필요한 조건이 빠짐" 같은 신호가 명확해야 한다.

검증할 수 없는 스킬은 운영자가 매번 결과를 직접 확인해야 한다는 뜻이다. 그러면 스킬을 만든 이득의 절반이 사라진다.

2. 스킬 · 슬래시 커맨드 · 함수의 역할 분리

이 셋은 모두 "반복을 줄이는 도구"지만 역할이 다르다.

도구	호출 주체	컨텍스트 인지	적합한 일
함수 / 일반 코드	협업자 자체	없음 (순수 입력→출력)	결정적 계산, 변환, 파일 처리
슬래시 커맨드	운영자가 명시적	현재 세션 인지	운영자의 의도가 시작점인 절차 (/start, /session-end)
훅	시스템이 이벤트 기반	이벤트 컨텍스트 인지	잊지 말아야 할 자동 발동 (다음 편 주제)

스킬은 슬래시 커맨드와 훅 양쪽에서 호출 가능한 공통의 절차 정의다. 같은 /verify라는 절차를 운영자가 직접 /verify 칠 수도 있고, 작업 완료 보고 직전에 훅이 자동으로 호출할 수도 있다. 두 호출 경로 모두 같은 스킬을 가리킨다.

이 분리가 분명하지 않으면 — 모든 자동화가 함수로만 만들어지고, 협업자의 컨텍스트 인지가 활용되지 않거나, 반대로 모든 것이 슬래시 커맨드가 되어 매번 운영자가 호출해야 한다.

3. 운영 중인 스킬 예시 — 누적된 효과

운영자가 실제로 매일 호출하는 스킬 중 일부.

3.1 /start <프로젝트> — 프로젝트 진입

지정 프로젝트로 진입한 뒤, README.md · CLAUDE.md · HANDOFF.md · PLAN.md 등 필수 문서를 자동 로드하고 현재 git 상태와 직전 세션 인계 사항을 한 화면에 보고한다. 보고 후 멈춰서 운영자의 다음 지시를 기다린다.

이 스킬이 없으면 매번 운영자가 "그 프로젝트 폴더 가서 README 읽고, HANDOFF 읽고, git status 보고, 마지막 commit 메시지 보고 알려 줘" 같은 말을 풀어서 해야 한다. 한 단어로 응고했다.

3.2 /session-end — 세션 마무리

작업 로그 작성, HANDOFF.md 갱신(다음 세션이 자동 로드할 인계서), 커밋, 푸시까지 한 호흡에 처리한다. 매번 운영자가 "오늘 한 일 정리해서 history.md에 추가하고, HANDOFF에 다음 세션이 봐야 할 것 적고, 커밋해서 푸시해 줘" 풀어 말할 필요가 없다.

3.3 /verify — 검증 루프

코드 변경 후 lint · 빌드 · 테스트 · 보안 검사 · diff 점검까지 자동으로 돈다. 통과해야 "완료" 보고가 나갈 수 있다. 자세한 내용은 시리즈 후반에 별도로 다룬다.

3.4 /council — 4관점 병렬 분석

결정이 모호한 사안에 대해 아키텍트 · 회의주의자 · 실용주의자 · 비평가 네 관점을 병렬로 돌리고 결과를 종합한다. 이 패턴은 Andrej Karpathy가 제안한 LLM 다관점 비판(multi-perspective critique) 방법론에서 차용했다.

3.5 누적된 효과

이 스킬들은 각각으로는 큰 발명이 아니다. 그러나 매일 호출되는 한 줄짜리 이름이 30개 정도 누적되면, 운영자가 절차를 풀어 설명하는 시간이 거의 사라진다. 운영자의 mind는 "지금 무엇을 결정해야 하는가"에만 집중하면 되고, "이 결정을 어떻게 풀어 갈 것인가"는 이름이 처리한다.

4. 설계 원칙 — 스킬을 만들 때 지키는 것

스킬을 만들 때 운영자가 수렴한 원칙.

4.1 멱등성 (Idempotent)

같은 인자로 두 번 호출해도 같은 결과가 나오거나, 적어도 깨지지 않아야 한다. 멱등하지 않은 스킬은 운영자가 "지금 호출해도 되나" 매번 따져야 한다. 그게 또 새로운 mind 부담이다.

4.2 Fail-fast

전제 조건이 갖춰지지 않으면 스킬은 첫 줄에서 멈추고 명확한 메시지를 낸다. "이 디렉토리는 git 저장소가 아닙니다. git init 후 다시 시도하세요." 같은 식. 어중간한 상태로 절반만 실행되는 스킬은 가장 위험하다.

4.3 짧은 출력

스킬이 끝났을 때 출력은 짧아야 한다. "성공: 3 파일 푸시" 한 줄. 자세한 로그는 필요할 때만 별도 옵션으로. 출력이 길면 협업자가 매번 그 출력을 요약해야 하고, 운영자도 다시 읽어야 한다.

4.4 부수 효과 명시

스킬이 외부 상태를 바꾸면 — 파일을 쓰거나, 네트워크를 호출하거나, 푸시하거나 — 그 사실은 스킬 정의 상단에 명시한다. "이 스킬은 origin으로 push합니다." 같은 식. 운영자가 호출하기 전에 그 사실을 알아야 한다.

4.5 단일 책임

한 스킬은 한 가지 일만 한다. /start 안에 "그리고 의존성도 깔아 줘" 같은 부가 동작을 끼워 넣지 않는다. 그건 별도 스킬로. 단일 책임이 깨지면 스킬 이름이 더 이상 그 동작을 설명하지 못한다.

5. 스킬이 모이면 — 네트워크 효과

스킬 한 개의 가치는 시간 절약이다. 하지만 스킬이 30개 모이면 더 큰 일이 일어난다. 스킬들이 서로를 호출하기 시작한다.

예를 들어:

• /session-end는 내부적으로 /verify를 호출한다 — 검증되지 않은 변경은 푸시하지 않는다
• /start는 자동으로 메모리 인덱스를 갱신한다
• /council은 결정 후 /btw(결정 큐 처리) 호출 여부를 제안한다

각 스킬이 다른 스킬을 잘 정의된 인터페이스로 호출할 수 있으면, 운영자의 mind는 더 큰 단위에서 작동한다. "오늘 작업 마무리"라는 한 단위 결정이 내부적으로는 7-8개의 스킬 호출로 풀린다. 운영자는 그 7-8개를 일일이 인식하지 않아도 된다.

이게 누적된 스킬 모음의 진짜 가치다. 시간 절약은 부수 효과고, mind가 더 큰 단위로 작동할 수 있게 되는 것이 본질이다.

6. 스킬로 만들면 안 되는 것 — 함정

승급 기준의 반대편. 다음은 스킬로 만들면 손해다.

6.1 한 번만 쓸 가능성이 높은 절차

"이 마이그레이션 한 번 하면 끝나는 거니까 스크립트만 짜 두자." 그게 스킬이 되면 안 된다. 한 번짜리 절차는 그냥 한 번 실행하고 끝. 스킬로 만들면 유지보수 대상이 되고, 6개월 뒤 "이거 뭐였더라" 추적해야 한다.

6.2 컨텍스트 의존이 너무 큰 것

"이 코드 리뷰해 줘" 같은 것은 매번 다른 컨텍스트가 필요해서 스킬이 되지 않는다. 인자로 컨텍스트를 다 받으려면 결국 매번 길게 설명해야 하고, 그러면 스킬을 만든 이득이 사라진다.

6.3 mind 자체를 외부화하는 것

"내가 어떤 결정을 해야 할지 알려 줘" 같은 것은 스킬이 아니다. 그건 운영자의 mind를 외부에 위탁하는 일이고, 그러면 운영자가 결정 결과의 주인이 아니게 된다.

스킬은 운영자의 mind를 도와주는 것이지, 대체하는 것이 아니다.

6.4 너무 자주 바뀌는 절차

스킬은 한 번 정의되면 며칠은 그대로 쓰여야 한다. 매주 절차가 바뀌는 것은 스킬로 굳히지 않는다. 굳혀 봤자 다음 주에 깨진다.

7. 진화 패턴 — 스킬은 어떻게 다듬어지는가

운영자가 본 스킬의 자연스러운 수명 주기.

1. 반복 발견: 같은 절차를 2번 이상 풀어 설명함 → 후보
2. 수동 정리: 절차를 README나 메모에 단계별로 정리함 → 손으로 따라할 수 있는 상태
3. 스킬화: 단계가 안정되면 슬래시 커맨드 또는 스킬 정의로 응고
4. 사용 중 다듬기: 실제 호출하면서 발견되는 엣지 케이스를 수정
5. 외부 호출 가능화: 다른 스킬에서 호출 가능한 인터페이스로 정리
6. 승급 또는 강등: 자주 쓰이면 페르소나에 자동 발동 트리거 추가 (다음 편 훅 주제) / 안 쓰이면 외부로 강등 또는 삭제

이 주기를 거치지 않은 스킬은 오래 살아남지 못한다. 만들기는 쉽고 유지보수는 어렵기 때문에, 자연 선택이 필요하다.

8. 한 원칙으로 압축

스킬과 슬래시 커맨드 설계의 핵심은 한 문장으로 줄어든다.

"매일 반복되는 mind의 동작 패턴에만 한 줄짜리 이름을 준다. 그 외에는 풀어 쓴다."

이 원칙이 지켜지면 스킬 모음은 운영자의 mind를 가속하는 도구가 된다. 지켜지지 않으면 — 너무 일찍 만들어졌거나 너무 복잡한 스킬들이 — 운영자가 매번 신경 써야 하는 부담이 된다.

다음 글에서는 스킬과 짝을 이루는 다른 절반 — 훅과 자동화, 즉 운영자가 호출하지 않아도 시스템이 자동 발동시키는 절차들에 대해 다룬다.