클로드 스킬은 왜 규칙 파일 하나로 안 만들고 여섯 개로 쪼갰나

AI에게 지시를 미리 넣어두는 방법은 원래 하나였습니다. 프로젝트 루트에 규칙 파일을 하나 두고 거기에 다 적는 것. 그런데 superpowers는 같은 일을 스킬 여섯 개로 쪼개서 합니다. 파일 하나면 될 것을 왜 나눴을까요. 뜯어보니 그 분할 자체가 이 도구의 핵심이었습니다.

규칙 파일이 길어져 뭘 지우고 뭘 남길지 고민하다 막힌 분이라면 이 글이 그 기준을 줍니다.

규칙 파일과 스킬의 차이

규칙 파일은 항상 읽힙니다. 세션이 시작되면 통째로 컨텍스트에 올라가고, 지금 하는 일과 무관한 규칙도 자리를 차지합니다. 스킬은 다릅니다. 시작할 때는 이름과 설명만 올라가고, 본문은 조건이 맞을 때 꺼내집니다. 같은 분량의 지시를 넣어도 상시 점유량이 다릅니다. 이 구조를 progressive disclosure라고 부릅니다.

발동 조건이 설명문에 적혀 있는 이유

각 스킬 파일 맨 앞에는 description 한 줄이 있습니다. brainstorming에는 "어떤 창작 작업 전에도 반드시 사용할 것", verification-before-completion에는 "완료·수정·통과를 주장하려 할 때, 커밋이나 PR 생성 전"이라고 적혀 있습니다.

이건 사람이 읽으라고 쓴 소개문이 아니라 모델이 읽는 조건절입니다. 그래서 사용자가 스킬 이름을 알 필요가 없습니다. "가계부 앱 만들어줘"라는 말이 조건에 걸리면 brainstorming이 붙고, "다 됐어?"가 걸리면 verification이 붙습니다. 진입 비용이 0에 가까운 게 이 설계의 실질적 이득입니다.

수십 개를 깔아도 되는가

여기는 결론이 갈립니다.

주장	근거	반대 근거
많이 깔면 손해	컨텍스트가 빨리 차고, 어떤 단계는 한 시간까지 걸렸다는 이슈 신고	—
수십 개도 괜찮다	시작 시 이름과 설명만 로드(스킬당 수십 토큰), 본문은 지연 로드	—

양쪽 다 같은 구조를 근거로 씁니다. 지연 로드가 실제로 작동하면 두 번째가 맞고, 스킬 수가 늘어 설명문 자체의 총량이 커지면 첫 번째가 맞습니다. 저는 늘려가며 재보는 중이고, 아직 어느 쪽이라고 말할 만한 자체 측정치가 없습니다.

자기 채점 문제

verification-before-completion의 철칙은 원문 그대로 NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE입니다. 검증 절차는 다섯 단계로 못 박혀 있습니다. 증명할 명령어를 특정하고, 새로 전부 실행하고, 출력 전문과 종료 코드를 읽고, 그게 주장을 뒷받침하는지 대조하고, 그다음에만 말한다. 한 단계라도 건너뛰면 "검증이 아니라 거짓말"이라고 적어놨습니다.

그런데 이 목록은 작업한 본인이 자기한테 들이대는 것입니다. 완료를 판단하는 쪽과 검증하는 쪽이 같으면 구조가 그대로예요. 그래서 requesting-code-review가 따로 있습니다. 맥락이 깨끗한 검사원을 새로 부르고, 그 검사원은 앞의 대화를 보지 않습니다. 바뀐 부분만 받고 결과를 치명·중요·경미 세 단계로 돌려줍니다. 같은 문서에 "검사원이 성공이라고 해도 직접 확인하라"는 줄도 함께 있습니다.

단계별로 쪼갠 설계의 대가

분할에는 비용이 따릅니다. 기획 칸에 brainstorming을 걸면 시작이 답답해집니다. 뚝딱 만들어주던 게 질문부터 하니까요. 설계 칸에 계획 스킬을 걸면 코드를 만지기 전에 계획서를 승인하는 단계가 하나 늘어납니다.

이걸 답답하다고 꺼버리면 걸어둔 의미가 없어집니다. 그 답답함이 버그가 아니라 기능이라서요. 다만 한 줄 고치는 일에까지 계획서를 요구하지는 않습니다. 문서에 "사소한 수정에 계획은 낭비니 건너뛰라"는 단서가 붙어 있습니다.

보안 칸만 설계가 다른 이유

여섯 개 중 /security-review만 설치가 필요 없습니다. 클로드 코드에 내장된 명령이라서요. 앤트로픽이 자기네 코드에 돌렸을 때 원격 코드 실행과 SSRF를 합치기 전에 잡았다고 공개했습니다.

내장으로 넣은 이유는 짐작이 갑니다. 보안 검사를 선택 사항으로 두면 안 하게 되거든요. Veracode가 100개 넘는 모델에 80개 코딩 과제를 시켰더니, 안전한 방식과 아닌 방식 중 고를 수 있을 때 45%가 안전하지 않은 쪽을 골랐습니다. SQL 인젝션은 82%를 막는데 XSS는 15%밖에 못 막습니다. 아는 자리는 알고 모르는 자리는 계속 모른다는 뜻이라, 세대가 바뀌길 기다리는 걸로는 안 메워집니다.

이 구조의 가장 약한 고리

스킬은 결국 남의 저장소에서 받아오는 실행 가능한 지시문입니다. 파일 형식이 공개 표준이라 도구 여러 개가 같은 파일을 읽고, 위험도 그대로 옮겨 다닙니다.

Check Point가 찾아낸 CVE-2025-59536(CVSS 8.7)은 저장소에 심어둔 스크립트가 신뢰 확인 창이 뜨기 전에 실행되는 문제였고, 2025년 9월 클로드 코드 1.0.111에서 패치됐습니다. Snyk이 공개 스킬 3,984개를 조사했을 때는 36%에서 숨겨진 명령이 나왔습니다. 다만 그 조사 대상은 다른 도구가 쓰는 별개 장터이고, 공식 마켓의 대량 유통은 확인된 바 없습니다.

앤트로픽도 방어를 넣어뒀습니다. 스킬 안에서 명령이 바로 실행되는 걸 꺼두는 설정이 있고, 처음 여는 폴더는 신뢰할지 먼저 묻습니다. 그런데 공식 문서에는 이렇게도 적혀 있습니다. 밖에서 붙여 쓰는 연결 서버는 보안 감사하지 않으며, 승인 전 검토 책임은 쓰는 사람에게 있다.

무엇을 확인하지 못했나

• 스킬을 걸어둔 상태와 아닌 상태의 작업 시간 차이를 측정하지 않았습니다. "몇 % 빨라진다"는 수치는 근거가 없어 넣지 않았습니다.
• progressive disclosure의 실제 토큰 절감량도 자체 계측하지 않았습니다. 위 표의 양쪽 주장은 모두 공개 이슈와 설계 문서 기반입니다.
• 6개를 장기간 걸어두고 나온 부작용은 아직 관찰 기간이 짧습니다.

설계를 뜯어보고 남은 인상은 하나였습니다. 이 도구는 모델을 똑똑하게 만들려 하지 않습니다. 말하기 전에 증거를 요구하는 자리를 만들 뿐입니다.

혹시 이 구조에 반례가 될 만한 경험이 있으신가요. 스킬을 걸었는데 오히려 방해가 됐던 케이스라면 특히 궁금합니다. 유튜브 방구석컴퍼니 댓글이나 오픈톡 방구석모각코에서 이야기 나눠요.