가끔 쓰는 규칙은 Claude Code 스킬로 빼라는데, 과연 진짜 싸질까?

이번 시간에는 가끔만 쓰는 규칙을 지침 파일(CLAUDE.md)에 둘 때와 스킬로 뺄 때 각각 얼마를 내는지를 claude -p로 잰 숫자로 따져 보며 배워가는 시간입니다.

지침을 정리하다 보면 마이그레이션 규칙 같은 게 걸려요. 마이그레이션 작업을 자주 하지는 않지만, 할 때는 그 규칙이 반드시 필요하거든요. 지워 버리면 정작 필요한 날에 규칙 없이 작업하게 됩니다.

그렇다고 지침에 그냥 두자니 아깝죠. 백 번 요청하는 동안 한 번 쓸까 말까 한 규칙인데, 백 번 다 실리니까요.

버릴 수도 없고 매번 싣기도 아까운 규칙. 이 글에서 다룰 게 이겁니다.

이런 규칙은 스킬로 빼라는 이야기, 아마 다들 알고 계실 거예요. 스킬은 이름이랑 설명만 먼저 실리고 본문은 필요할 때 불려 온다는 것도요.

근데 그 값을 실제로 재 보신 적 있으세요? 저는 이 글을 준비하면서 처음 재 봤는데, 결과가 제 예상이랑 달랐습니다. 방향은 맞았어요. 그런데 제가 알고 있던 이유가 틀렸습니다.

그래서 세 가지를 재 볼게요.

• 첫 번째, 그 규칙을 안 쓰는 요청에서 얼마나 아끼는지.
• 두 번째, 실제로 쓰는 요청에서는 얼마를 내는지.
• 세 번째, 한 번 쓰고 난 다음에는 어떻게 되는지.

일반 모드에서, 같은 환경 안의 차이로만 봅니다

claude --safe-mode로 실행하면 CLAUDE.md, 스킬, 플러그인, 훅, MCP 서버 같은 사용자 설정을 끄고 열 수 있어요. 각자 환경이 숫자에 섞이지 않으니 재기에는 편하죠. 그런데 이 모드는 스킬도 끕니다. 스킬을 재야 하니 이번에는 통째로 일반 모드에서 쟀어요.

일반 모드니까 절댓값에는 각자 환경이 얹힙니다. 그래서 이 글의 비교는 전부 같은 환경 안에서의 차이로만 볼게요.

그리고 스킬은 환경이 얹히는 정도가 지침보다 큽니다. 이미 쓰고 계신 개인 스킬(~/.claude/skills/에 둔 스킬)이 있으면 그것도 같이 올라오거든요. Claude Code에서 /skills를 쳐 보시면 지금 몇 개가 올라와 있는지 보입니다. 한번 세어 두세요.

제 경우는 개인 스킬이 여든 개가 넘습니다. 그래서 이 글의 절댓값은 여러분 화면이랑 꽤 다를 거예요. 그래도 세 조건 모두에 같은 환경이 똑같이 얹히니까, 조건 사이의 차이는 그대로 보입니다.

같은 규칙을 위치만 바꿔 세 조건으로 둡니다

조건부 규칙 세 가지를 준비했어요. 마이그레이션, API 응답 규격, 벤치마크요. 실무에서 이런 규칙 문서 하나쯤은 다들 가지고 계실 거예요.

재는 건 이 규칙을 어디에 두느냐입니다. 그래서 규칙 내용은 그대로 두고 위치만 다른 상태를 세 개 만들었어요.

• 규칙 없음: 규칙이 아예 없는 상태예요. 비교의 바닥입니다.
• 스킬: 규칙이 스킬에 있는 상태예요. 이름이랑 설명만 실리고 본문은 필요할 때 불려 온다는, 이번에 검증할 그 상태죠.
• 지침: 규칙이 지침(CLAUDE.md)에 통째로 들어간 상태예요. 본문까지 매 요청에 실립니다.

여기서 조건 하나가 중요합니다. 세 상태에 들어가는 규칙 내용이 글자 하나까지 같아야 해요. 내용이 다르면 값의 차이가 위치 때문인지 내용 때문인지 구분이 안 되니까요.

스킬은 디렉터리 구조랑 파일 이름이 정해져 있어요. 규칙 하나가 디렉터리 하나고, 그 안에 SKILL.md라는 이름으로 본문을 둡니다. 프로젝트에 둘 때 위치는 .claude/skills/<이름>/SKILL.md예요. 그래서 .claude/skills/ 아래에 migration-rules, api-response-rules, benchmark-rules 디렉터리를 두고 디렉터리마다 SKILL.md를 하나씩 넣었습니다.

그중 migration-rules/SKILL.md 전체는 이렇습니다.

---
name: migration-rules
description: DB 마이그레이션 파일을 만들거나 수정할 때 따르는 규칙
---

# 마이그레이션 규칙

- 마이그레이션 파일 이름은 `NNN_설명.sql` 형식이다. 번호는 세 자리로 0을 채우고, 설명은 소문자와 밑줄만 쓴다.
- 마이그레이션에는 반드시 되돌리기 절을 주석으로 남긴다. 파일 끝에 `-- rollback:` 블록을 두고 원복 SQL을 적는다.
- 이미 적용된 마이그레이션 파일은 절대 수정하지 않는다. 잘못된 내용도 새 번호로 추가한다.
- 인덱스를 추가할 때는 대상 테이블의 행 수를 주석으로 남긴다.
- 컬럼을 지우는 마이그레이션은 두 단계로 나눈다. 코드에서 사용을 없앤 뒤 다음 릴리스에서 지운다.
- 마이그레이션 하나에 테이블 하나만 다룬다.
- 로컬에서 되돌리기를 실제로 실행해 보고 커밋한다.

맨 위에 ---로 감싼 부분 보이시죠? 이 부분을 머리말이라고 부를게요. 여기 있는 name이랑 description만 평소 컨텍스트에 실리고, 그 아래 본문은 스킬이 발동할 때 불려 옵니다. 재 볼 게 바로 이 구조예요.

나머지 두 스킬(API 응답, 벤치마크)도 머리말 형태가 같고, 본문은 규칙 여섯일곱 줄씩입니다.

Claude Code는 작업 디렉터리의 CLAUDE.md를 세션을 시작할 때 자동으로 읽어서 매 요청 앞부분에 싣습니다. 상위 디렉터리의 CLAUDE.md랑 ~/.claude/CLAUDE.md도 같이 실려요. 그래서 조건은 CLAUDE.md 내용을 갈아 끼우고 .claude/skills/를 넣었다 뺐다 하는 방식으로 바꿨어요.

• 규칙 없음과 스킬 조건의 CLAUDE.md: "# 프로젝트 지침" 제목과 "이 저장소는 티켓 관리 서비스와 측정 도구를 함께 담고 있다." 한 줄뿐이에요. 스킬 디렉터리는 스킬 조건에만 둡니다.
• 지침 조건의 CLAUDE.md: 위 두 줄 뒤에 세 스킬의 본문을 머리말만 떼고 그대로 이어 붙였어요. 손으로 옮겨 적지 않고 복사해서 글자 하나까지 같게 했습니다.

측정 명령의 핵심은 이 한 줄입니다.

claude -p "파이썬에서 리스트와 튜플의 차이를 한 줄로 말해." --output-format json --max-turns 4

결과 JSON의 usage에 입력이 세 항목으로 나뉘어 나와요. 새로 처리한 입력(input_tokens), 캐시에 새로 쓴 입력(cache_creation_input_tokens), 캐시에서 읽은 입력(cache_read_input_tokens)입니다. 이 셋을 더한 값을 이 글에서는 입력 합이라고 부를게요.

그 규칙을 안 쓰는 요청에서는 얼마나 아낄까요?

먼저 그 규칙을 안 쓰는 요청부터 보겠습니다. 세 조건 모두에 규칙이랑 전혀 상관없는 질문, 방금 본 "파이썬에서 리스트와 튜플의 차이를 한 줄로 말해."를 던졌어요.

이 부분은 제가 실측한 결과를 기반으로 알려드릴게요. 조건마다 세 번씩 돌렸는데 세 번 모두 같은 값이 나왔습니다.

• 규칙 없음: 36,639
• 스킬: 36,763
• 지침: 39,216

지침에 통째로 넣은 조건은 39,216 − 36,639 = 2,577토큰이 더 나갔어요. 규칙 이야기가 한 마디도 안 나오는 질문인데도 매 요청마다 규칙 분량이 그대로 나간 거죠.

스킬로 뺀 조건은 36,763 − 36,639 = 124토큰이었어요. 규칙이 없는 조건이랑 거의 차이가 없습니다. 이름이랑 설명 세 줄분만 실린 거예요.

지침 대비로 보면 (2,577 − 124) ÷ 2,577 ≈ 95%가 줄었어요. 그리고 이건 그 규칙을 안 쓰는 요청마다 반복되는 절감입니다.

여기까지는 아마 예상하셨을 거예요.

그럼 실제로 쓰는 요청에서는 얼마를 낼까요?

이제 반대쪽입니다. 스킬이 실제로 불려 오는 요청에서는 얼마를 낼까요.

같은 세 조건에, 이번에는 그 규칙을 묻는 질문을 던졌어요. 질문 원문은 이렇습니다.

"마이그레이션 파일을 새로 만들려는데 이름 규칙과 되돌리기 규칙만 알려 줘. 파일은 읽지 말고 지침에 있는 내용만."

명령은 앞의 한 줄에서 질문만 바꾸고 --max-turns 6으로 돌렸어요. 이번에는 입력 합이랑 같이 num_turns를 봐야 합니다. num_turns는 이번 실행 안에서 모델과 주고받은 왕복 수예요. 이번 비교의 핵심이 이 왕복 수입니다.

그 전에 스킬이 정말 불려 온 건지부터 확실히 하고 가죠. 왕복이 늘었다는 건 간접 근거니까요. Claude가 스스로 스킬을 발동하면 세션 로그(~/.claude/projects/ 아래의 .jsonl 파일)에 어떤 스킬을 호출했는지가 그대로 남습니다.

스킬 조건의 결과 JSON을 ask-skill.json으로 저장해 뒀다면, 이렇게 확인할 수 있어요.

SKILL_LOG="$(find "$HOME/.claude/projects" -type f -name "$(jq -r .session_id ask-skill.json).jsonl" -print -quit)"
grep -o '"name":"Skill","input":{"skill":"[^"]*"' "$SKILL_LOG"

첫 줄은 결과 JSON에서 session_id 값을 꺼내서, 그 이름으로 된 세션 로그 파일을 찾습니다. 둘째 줄은 그 로그에서 스킬을 호출한 기록만 뽑아요.

migration-rules가 찍혀 나오면 그 스킬이 실제로 불려 온 겁니다. 아무것도 안 나오면 안 불려 온 거고요. 그러면 왕복이 늘어난 이유가 스킬이 아니라 다른 것이니까, 뒤에 나올 이야기는 그대로 적용되지 않습니다. 참고로 /migration-rules처럼 사람이 직접 스킬을 부르면 이 형태가 아니라 사용자 메시지로 들어가요. 이 확인은 Claude가 스스로 발동한 경우에 쓰는 방법입니다.

제 실행에서는 migration-rules 호출이 찍혀 있었고, 숫자는 이랬어요. 두 번 돌려 같은 결과가 재현됐습니다.

• 규칙 없음: 36,677, 1왕복, 이름 규칙(NNN 형식)과 되돌리기(rollback) 규칙을 말하지 못함
• 스킬: 76,580, 3왕복, 규칙을 제대로 말함
• 지침: 39,254, 1왕복, 규칙을 제대로 말함

스킬 조건이 압도적으로 비쌌습니다. 규칙이 없는 조건보다 76,580 − 36,677 = 39,903토큰, 지침 조건보다도 76,580 − 39,254 = 37,326토큰이 더 나갔어요. 지침 조건은 규칙 없는 조건보다 39,254 − 36,677 = 2,577토큰 많아서, 앞의 무관한 질문 때와 간격이 똑같았고요.

그런데 이상하지 않나요? 위에서 본 SKILL.md는 머리말까지 합쳐도 436자(줄바꿈 포함)입니다. 불려 올 때 붙는 내용을 더해도 수백 토큰이에요. 4만이 아니라요.

여기서 num_turns를 보시면 답이 나옵니다. 지침에 통째로 넣은 조건은 1왕복에 끝났는데, 스킬 조건은 3왕복으로 늘었어요.

이게 핵심입니다. 스킬을 불러오는 행위가 왕복을 더 만듭니다. 모델이 먼저 스킬을 호출하고, 본문을 받은 다음에야 답을 쓰니까요.

그리고 모델에 요청을 한 번 더 보내면, 그때까지의 앞부분(시스템 프롬프트, 지침, 도구 목록, 그때까지의 대화)이 통째로 한 번 더 실려요. 이 실험에서 앞부분은 3만 7천 정도였어요. num_turns는 2 늘었지만, 요청이 두 번 늘었다면 앞부분 두 벌, 7만 넘게 더 실렸어야 합니다. 늘어난 건 39,903이라 앞부분을 한 번 더 보낸 크기에 가까워요.

그러니까 스킬을 쓸 때 내는 비용은 본문 크기가 아니라 왕복에서 나옵니다.

본문 몫은 많아야 수백 토큰이라 39,903에서 차지하는 비중이 작아요. 그래서 본문을 100자로 줄여도 이 비용은 거의 줄지 않을 거예요. 스킬을 잘게 쪼개서 본문을 줄이면 이득이라는 흔한 조언이, 적어도 이 지점에서는 성립하지 않는다는 겁니다.

한 번 쓰고 나면 세션 내내 따라옵니다

불러온 스킬 본문이 그 왕복에만 실리고 사라질까요, 아니면 계속 남아 있을까요?

그래서 방금 스킬 조건의 세션을 --resume <세션 ID>로 이어받아, 이번에는 다시 규칙과 무관한 질문("파이썬에서 리스트와 튜플의 차이를 한 줄로 말해.")을 던졌어요. 이어받기 전에 환경은 스킬 조건으로 되돌려 뒀습니다. 지침 조건 그대로면 규칙 분량이 같이 실려 측정이 섞이니까요.

비교 대상은 규칙 없는 조건의 세션을 같은 방식으로 이어받아 같은 질문을 던진 실행이에요. 이어받은 실행의 total_cost_usd는 세션 전체 누적이라 비교에 쓰지 않고, 이번에도 usage의 입력 합을 봤습니다.

• 스킬 조건 세션을 이어받은 실행: 40,274
• 규칙 없는 조건 세션을 이어받은 실행: 39,309

40,274 − 39,309 = 965토큰이 더 나갔어요. 이 안에는 스킬 목록 몫 124도 들어 있으니, 그걸 빼면 965 − 124 = 841이 남습니다. 대부분은 불러온 본문과 그 호출 기록이 대화에 남은 몫으로 보여요. 두 세션은 앞 답변도 달라서 그 길이 차이도 조금 섞여 있습니다.

발동한 스킬 본문은 메시지 하나로 대화에 들어가고, 그 세션이 끝날 때까지 이후 요청에도 대화의 일부로 계속 실립니다. 메시지로 덧붙는 거라 캐시된 앞부분을 깨지는 않지만, 실리는 양은 그만큼 늘어납니다.

그러니까 스킬을 한 번 쓰고 나면, 그 세션 안에서는 그 규칙 하나를 지침에 넣어 둔 거랑 비슷한 상태가 됩니다.

이 시리즈의 다음 글에서는 이렇게 작업할수록 쌓이는 대화 이력을 언제 이어 가고 언제 끊을지 다룹니다.

그래서 언제 스킬로 빼야 할까요

자 이제 계산을 해 보죠. 앞에서 본 숫자 네 개면 됩니다.

• 지침 쪽: 요청 하나당 2,577(규칙 분량)
• 스킬 쪽 평소: 요청 하나당 124(이름과 설명)
• 스킬 쪽 쓸 때: 한 번에 76,580 − 36,677 = 39,903(늘어난 왕복)
• 스킬 쪽 쓴 뒤: 그 세션이 끝날 때까지 요청 하나당 965(평소 몫 124 포함)

지침에 두면 백 번 요청할 때 100 × 2,577 = 257,700이 나갑니다.

여기서 전제를 분명히 하고 갈게요. 백 번을 한 세션에서 이어서 요청하고, 그 규칙을 첫 요청부터 쓴다고 봤어요. 잔류가 가장 오래 남는 경우예요. 그리고 같은 세션에서 두 번째로 부를 때 본문이 또 쌓이는지는 재지 않았어요. 아래 식은 쓸 때마다 39,903이 붙고 잔류는 965에 머문다고 놓은 계산입니다.

그 규칙을 k번 쓴다고 하면 스킬 쪽 합은 이렇게 됩니다. 쓰는 요청 k번은 39,903씩, 나머지 100 − k번은 잔류가 실린 965씩이에요.

이 값이 지침 쪽 257,700과 같아지는 k를 구하면 됩니다. k × 39,903 + (100 − k) × 965 = 257,700을 풀면 k = (257,700 − 96,500) ÷ (39,903 − 965) = 161,200 ÷ 38,938 ≈ 4.1이에요.

네 번이면 4 × 39,903 + 96 × 965 = 252,252로 스킬이 5,448 덜 냅니다. 다섯 번이면 5 × 39,903 + 95 × 965 = 291,190으로 지침에 두는 쪽이 싸져요. 이 가정에서는 네 번까지 스킬이 근소하게 이기고, 다섯 번부터는 지침이 이깁니다.

반대로 부를 때마다 잔류 몫(841, 대부분 본문으로 보이는 값)이 한 벌씩 더 쌓인다고 치면, 쓴 뒤 요청 하나당 값이 124 + k × 841이 됩니다. k × 39,903 + (100 − k) × (124 + k × 841)로 계산하면 두 번이 256,794로 지침(257,700)과 거의 같고, 세 번이면 376,468로 크게 넘어서요. 분기점이 두 번 안팎으로 당겨지는 거죠.

그래서 이 숫자들로 말할 수 있는 손익분기는 두 번에서 네 번 사이입니다.

직접 계산하실 때 하나만 조심하세요. 965는 스킬이 없는 조건과 비교한 값이라 이름과 설명 몫 124가 이미 들어 있어요. 124를 백 번 따로 더하고 965를 또 더하면 같은 몫을 두 번 세게 됩니다.

이게 제가 예상과 달랐다고 말씀드린 부분이에요. "가끔 쓰는 규칙은 스킬로"라는 말 자체는 맞는데, 여기서 말하는 가끔이 생각보다 훨씬 드물어야 한다는 거예요. 하루 백 번을 한 세션에서 요청하는 분이라면, 그 규칙을 세 번째에서 다섯 번째 쓰는 사이에 스킬이 손해로 돌아섭니다.

세션을 자주 끊으면 잔류가 빠져서 분기점이 뒤로 갑니다. 잔류가 전혀 없다고 치면 k = (257,700 − 12,400) ÷ (39,903 − 124) = 245,300 ÷ 39,779 ≈ 6.2예요. 가져가실 건 숫자 하나가 아니라, 세션을 길게 쓸수록 스킬이 더 빨리 손해로 돌아선다는 쪽입니다.

계산에 깔린 한계도 두 가지 밝혀 둘게요.

• 쓸 때 붙는 39,903은 앞부분이 3만 7천 정도인 짧은 세션에서 잰 값이에요. 추가 요청이 앞부분을 통째로 다시 싣는 구조라, 대화가 길어진 뒤에 쓰면 이 값이 더 커질 거라고 봅니다. 이 경우는 재지 않았어요.
• 계산은 입력 토큰 합 기준이에요. 실제 금액은 그 안에서 캐시 읽기(기본 입력 단가의 0.1배, 일부 최신 모델은 더 쌉니다)와 캐시 쓰기(5분 캐시면 1.25배, 1시간 캐시면 2배)가 얼마씩인지에 따라 달라지는데, 항목별 값은 비교하지 않아서 금액으로는 계산하지 않았습니다.

기준을 정리하면 이렇습니다. 분기점이 두 번에서 네 번 사이니, 매일 여러 번 걸리는 규칙은 지침에 두는 쪽이 안전해요. 주에 한두 번 걸리는 규칙이라야 확실히 스킬입니다. 그 사이가 애매하면 위 식에 여러분 빈도를 넣어 계산해 보세요.

예상이 빗나간 실측도 하나 말씀드릴게요

정직하게 하나 더 말씀드리겠습니다.

이 측정을 설계할 때 저는 실패 사례를 하나 넣으려고 했어요.

스킬은 description만 보고 불러올지 판단하니까, 그걸 성의 없게 쓰면 규칙이 있어도 안 불려 올 거라고 생각했거든요. 토큰은 줄었는데 규칙은 사라진 상태, 줄이다가 빠지기 쉬운 함정이죠.

그래서 마이그레이션 스킬의 description을 "규칙" 한 단어로 망가뜨리고 다시 재 봤어요.

그런데 그대로 불려 왔어요. 입력 합 76,618에 3왕복으로 원래 스킬 조건(76,580, 3왕복)과 거의 같았고, 규칙도 제대로 적용됐습니다. 두 번 돌렸는데 두 번 다요. 앞의 세션 로그 확인 명령에도 migration-rules 호출이 찍혀 있었어요.

제 예상이 빗나갔죠. 근데 이걸 "description은 대충 써도 된다"로 읽으시면 안 돼요. 두 번뿐인 실행이고, 이 프로젝트에 넣은 스킬은 셋뿐이라 후보가 좁았습니다. 스킬이 스무 개쯤 되고 설명이 서로 비슷하면 이야기가 달라질 거예요.

스킬 수가 많을 때 달라질 근거도 있어요. 스킬 목록(이름과 설명)에 쓸 수 있는 분량에는 전체 상한이 있어서, 스킬이 많아 넘치면 덜 쓰는 스킬의 설명부터 목록에서 빠집니다. 설명이 아주 길면 중간에서 잘리기도 하고요.

앞에서 /skills로 세어 두신 개수가 많다면, 여러분 환경에서는 설명을 망가뜨린 스킬이 안 불려 올 수 있습니다. 그건 실패가 아니라 더 현실에 가까운 결과예요.

여기서 가져가실 건 결과가 아니라 태도입니다. 제 예상도 틀렸고, 여러분이 어디서 읽은 이야기도 틀릴 수 있어요. 자기 환경에서 재 보기 전까지는 전부 가설입니다.

정리

범위: 조건부 규칙 세 가지를 규칙 없음, 스킬, 지침 세 위치에 두고 claude -p 일반 모드(개인 스킬 80개 넘게 설치)에서 잰 입력 합의 조건 간 차이와, 그 값으로 계산한 손익분기.

• 조건부 규칙을 스킬로 빼면 그 규칙을 안 쓰는 요청에서 크게 아낍니다. 지침에 넣으면 요청마다 2,577, 스킬이면 124가 더 나가서 95%가 줄었어요(3회 모두 같은 값).
• 대신 쓰는 요청에서는 왕복이 1에서 3으로 늘면서 규칙 없는 조건보다 39,903을 더 냈어요. 본문 크기가 아니라 왕복 때문이라, 본문을 줄여도 이 값은 거의 줄지 않을 거예요.
• 한 번 불러온 본문은 그 세션 내내 따라옵니다. 이어받은 무관한 질문에서 965가 더 나갔어요. 스킬을 한 번 쓴 세션은 그 규칙 하나를 지침에 넣어 둔 것과 비슷해집니다.
• 손익분기는 빈도로 계산하세요. 측정값으로 계산하면 100요청 한 세션, 첫 요청부터 쓰는 경우 두 번에서 네 번 사이였어요(다시 부를 때 본문이 또 쌓이면 약 두 번, 잔류가 965에 머물면 약 4.1번, 재지 않은 가정). 잔류가 없다고 치면 약 6.2번이고, 세션을 길게 쓸수록 분기점이 앞당겨집니다.
• description을 "규칙" 한 단어로 망가뜨려도 스킬 셋뿐인 프로젝트에서는 두 번 다 불려 왔어요. 스킬이 많으면 달라질 수 있으니 세션 로그의 호출 기록으로 직접 확인하세요.