Claude 스킬 vs. 슬래시 명령어 vs. 서브에이전트

2026년 8월 업데이트.

TL;DR: 슬래시 명령어는 자주 입력하는 프롬프트의 단축어입니다—이름을 불러 직접 실행합니다. 서브에이전트는 자체 컨텍스트 창을 가진 병렬 작업자입니다—경계가 명확한 작업을 위해 당신(또는 Claude)이 생성하고 결과를 돌려받습니다. 스킬은 Claude가 요청 내용을 보고 스스로 판단해 불러오는 패키지화된 전문 지식입니다—당신은 아무것도 이름으로 지정하지 않습니다. 대부분의 사람들은 슬래시 명령어면 충분한 곳에 커스텀 에이전트를 쓰고, 실제로 필요했던 것이 Claude가 스스로 트리거할 수 있는 스킬이었던 곳에 슬래시 명령어를 씁니다.

[운영자 노트] 저는 두 개의 사업체에서 30개 이상의 프로덕션 에이전트를 운영하고 있는데, 명령어인지 서브에이전트인지 스킬인지를 둘러싼 이 정확한 혼란이 거의 모든 에이전트에서 처음 맞닥뜨리는 설계 질문입니다. 이걸 잘못 판단하면 아무도 이름을 기억하지 못하는 명령어 열 개를 만들거나, 너무 광범위해서 안정적으로 트리거되지 않는 스킬 하나를 만들게 됩니다. 해법은 어림짐작이 아니라, 실행할 때마다 실제로 무엇이 달라지는지 묻는 것입니다.

Table of contents

Open Table of contents

• 세 가지 기본 요소는 각기 다른 문제를 해결한다
• 슬래시 명령어: 자주 입력하는 프롬프트의 단축어
• 서브에이전트: 자체 컨텍스트 창을 가진 병렬 작업자
• 스킬: Claude가 스스로 로드하는 패키지화된 전문 지식
• 의사결정 프레임워크
• 제가 가장 자주 보는 실수
• 운영자로서의 결론
• FAQ
  • Claude 스킬과 슬래시 명령어의 차이는 무엇인가요?
  • 서브에이전트를 스킬 대신 언제 써야 하나요?
  • 스킬이 발행이나 결제 같은 행동을 자동으로 실행하게 두어도 안전한가요?
  • 결국 셋 다 만들어야 하나요?

세 가지 기본 요소는 각기 다른 문제를 해결한다

셋 다 지시사항을 한 번 패키징해서 재사용할 수 있게 해줍니다. 유사성은 거기서 끝나는데, 바로 그 지점 때문에 사람들이 혼동하기도 합니다—겉에서 보면 “짧게 입력하고 유용한 결과를 얻는다”는 점에서, 내부에서 어떤 요소가 작동하든 똑같아 보이기 때문입니다.

진짜 차이는 누가 그것을 호출하기로 결정하는가, 그리고 어떤 컨텍스트에서 실행되는가입니다:

• 슬래시 명령어는 당신이 이름을 불러 호출합니다. /deploy나 /review를 입력하면 Claude가 이를 더 상세한 지시사항으로 전개하고, 지금 하고 있는 대화 안에서 실행됩니다.
• 서브에이전트는 당신 또는 Claude가, 경계가 명확한 작업을 위해 호출합니다. 자체 컨텍스트 창을 가지고 작업을 수행한 뒤 결과를 보고합니다—당신의 대화 전체를 보지 못하고, 당신도 요청하지 않는 한 중간 단계를 보지 못합니다.
• 스킬은 요청 내용이 그 스킬의 설명이 다루는 범위와 일치할 때 Claude가 자동으로 호출합니다. 이름을 입력할 일이 없습니다. 스킬이 처리하는 무언가를 요청하지 않으면, 그 스킬은 절대 로드되지 않습니다.

명시적 호출이 없다는 이 세 번째 특성이야말로 사람들이 가장 저평가하는 부분입니다. 그리고 패키지화된 워크플로가 몇 개를 넘어가는 순간, 무엇을 어떻게 이름 붙였는지 더 이상 기억할 필요가 없어지기 때문에 가장 큰 레버리지를 발휘하는 부분이기도 합니다.

슬래시 명령어: 자주 입력하는 프롬프트의 단축어

트리거가 “나는 기본적으로 같은 지시사항을 계속 입력하고 있다”는 것이라면 슬래시 명령어를 만드세요. 명령어는 당신이 고른 짧은 이름에서 전개되어, 지금 하고 있는 대화 안에서, 항상 같은 기저 프롬프트로 귀결됩니다. 별도의 컨텍스트도, 자율적인 호출도 없습니다—매번 언제 실행할지는 당신이 결정합니다.

잘 맞는 예: 고정된 릴리스 체크리스트, 당신의 규칙이 내장된 코드 리뷰 패스, “이 PR 요약해줘” 같은 단축 작업. 명령어는 실행할지 말지를 판단할 필요가 없습니다—그 판단은 입력하는 당신이 이미 내리는 것이니까요.

실패 패턴은 실제로 모델이 적용 여부를 판단해야 하는 무언가를 위해 명령어를 만드는 것입니다. 사용 사례의 절반이 “잠깐, 이게 여기 해당하나?”라면—그건 명령어의 문제가 아니라 스킬의 문제입니다. 명령어는 스스로를 트리거할 방법이 없기 때문입니다.

서브에이전트: 자체 컨텍스트 창을 가진 병렬 작업자

작업이 경계가 명확하고, 위임 가능하고, 그렇지 않으면 굳이 볼 필요 없는 단계들로 메인 대화를 오염시킬 것 같다면 서브에이전트를 만드세요. 서브에이전트는 자체 컨텍스트—자체 도구 호출, 자체 주고받기—를 실행하고 결과를 돌려줍니다. 이는 제가 컨텍스트 엔지니어링에서 쓴 것과 같은 원리입니다: 추가되는 모든 도구 호출과 중간 단계는 메인 스레드가 굳이 짊어질 필요 없는 컨텍스트이며, 서브에이전트는 그런 잡음을 밖으로 빼내는 방법입니다.

잘 맞는 예: “이걸 조사해서 보고해줘”, “이 다섯 개의 독립적인 체크를 병렬로 실행해줘”, “이 파일 하나만 따로 고쳐줘.” 작업에는 시작과 끝, 그리고 결과물이 있습니다—제가 에이전트를 출시할 때 쓰는 평가 하네스가 하나의 채점 가능한 단위로 취급하는 것과 정확히 같은 형태입니다.

실패 패턴은 다음 단계가 서브에이전트의 요약에서 빠진 세부사항에 의존하기 때문에 메인 컨텍스트에 남아 있어야 했던 작업을 위해 서브에이전트를 생성하는 것입니다. 서브에이전트에게 “잠깐, 정확히 뭘 찾았어?”라고 계속 재질문하게 된다면, 경계 설정이 잘못된 것입니다—메인 스레드로 다시 합치거나, 서브에이전트의 보고 형식을 번역 과정에서 아무것도 유실되지 않을 만큼 구조화하세요.

스킬: Claude가 스스로 로드하는 패키지화된 전문 지식

트리거 조건이 당신이 이름을 기억해야 하는 무언가가 아니라, Claude가 당신의 요청에서 인식해야 하는 무언가라면 스킬을 만드세요. 스킬은 설명 하나와 지시사항·스크립트 묶음입니다. Claude는 설명을 읽고, 당신의 요청이 일치하는지 판단하고, 일치할 때만 전체 지시사항을 로드합니다. /skill-name을 입력할 일이 없습니다.

제가 제시할 수 있는 가장 명확한 예는 이 블로그를 운영하는 파이프라인입니다. alejandrorioja.com은 13개 언어로 발행하는데, 생성 → 번역 → 렌더링 → 검토로 이어지는 전체 흐름이 스킬 하나에 담겨 있습니다: 언제 사용할지(“새 글 생성”, “모든 로케일로 번역”, “홍보 문구 초안 작성”)를 설명하는 SKILL.md 파일과, 실제 작업을 수행하는 스크립트들입니다. 저는 네 개의 개별 명령어를 따로 실행하고 순서를 외우지 않습니다. 원하는 것을 평범한 말로 말하면, 스킬의 설명이 충분히 구체적이어서 Claude가 이를 인식하고 올바른 단계를 실행합니다—페이스북 광고 스킬이 명령어 이름을 입력하지 않아도 “내 광고 확인해줘”에 반응해 트리거되는 것과 같은 방식입니다.

스킬이 스스로 적용 여부를 판단한다는 이 설계 선택은, 안전 기본값이 명령어나 서브에이전트보다 여기서 더 중요한 이유이기도 합니다. 슬래시 명령어는 당신이 입력할 때만 실행되지만, 스킬은 모델이 실행해야 한다고 판단할 때 실행됩니다. 제 콘텐츠 스킬은 기본적으로 초안만 작성하며, 발행하거나 푸시하기 전에는 명시적이고 별도의 승인 단계를 반드시 거치도록 요구합니다—스스로를 트리거해 실제 결과가 따르는 행동으로 이어질 수 있는 스킬이라면 어디서든 제가 적용하는 것과 같은 휴먼인더루프 패턴입니다.

잘 맞는 예: 인식 가능한 트리거 문구와 그 뒤의 반복 가능한 절차가 있는 모든 것—“보고서 생성”, “이 제출물 채점”, “슬랙용 요약 초안 작성.” 실패 패턴은 원하지 않을 때도 발동할 만큼 너무 광범위하거나, 원할 때도 발동하지 않을 만큼 너무 좁은 스킬 설명입니다. 함수 이름을 짓듯이 쓰지 말고, 신입 직원에게 트리거 조건을 설명하듯 설명을 작성하세요.

의사결정 프레임워크

이 질문을 해보세요	예라면 →	이유
이걸 트리거하려면 항상 이름을 입력하고 싶은가?	슬래시 명령어	트리거는 모델이 아니라 당신
작업이 경계가 명확하고, 위임 가능하며, 메인 컨텍스트 밖에 두는 게 나은가?	서브에이전트	자체 컨텍스트 창, 결과 반환
Claude가 아무것도 이름 붙이지 않아도 필요성을 인식해야 하는가?	스킬	설명 매칭, 자동 호출
돈, 발행, 되돌리기 어려운 무언가와 관련이 있는가?	셋 중 무엇이든, 명시적 승인 게이트 추가	자동 호출이 자동 실행을 의미하지 않는다

실제 워크플로는 대부분 하나만 고르는 게 아니라 이들이 쌓인 형태입니다. 제 콘텐츠 파이프라인은 스킬이며(“글 작성해줘”로 자동 트리거), 내부적으로 서브에이전트를 호출하고(로케일당 하나씩, 병렬 실행), 절대 제가 명시적으로 말하지 않고는 일어나서는 안 되는 한 단계—실제 발행—를 위해 슬래시 명령어(/publish)를 노출합니다.

제가 가장 자주 보는 실수

실제로는 슬래시 명령어가 옷을 갈아입은 것에 불과한 무언가를 위해 자체 스케줄링, 자체 상태, 자체 배포를 갖춘 완전한 커스텀 에이전트를 만드는 것입니다. 작업이 “내가 말할 때 이 정확한 절차를 실행한다”라면, 자율성도 메모리도 트리거 조건도 필요 없습니다. 필요한 것은 이름과 프롬프트뿐입니다. 서브에이전트-스킬 장치는 경계(서브에이전트)나 트리거(스킬)가 실제로 어떤 역할을 하는 작업을 위해 아껴두세요. 이미 단순했던 무언가에 인프라만 얹는 게 아니라요.

운영자로서의 결론

무엇을 만들지 묻기 전에 누가 호출을 결정하는지부터 물으세요. 매번 당신이 이름으로 결정한다면 → 슬래시 명령어. 메인 컨텍스트 밖에 두고 싶은 경계가 명확한 작업이라면 → 서브에이전트. Claude가 스스로 필요성을 인식한다면 → 스킬, 되돌릴 수 없는 것에는 승인 게이트를 추가하세요. 이 질문 하나만 제대로 맞히면, 나머지—파일에 무엇을 담을지, 지시사항을 얼마나 묶을지—는 대체로 저절로 풀립니다.

FAQ

Claude 스킬과 슬래시 명령어의 차이는 무엇인가요?

슬래시 명령어는 실행하고 싶을 때마다 이름을 불러 명시적으로 호출합니다. 스킬은 자동으로 호출됩니다—Claude가 당신의 요청을 스킬의 설명과 대조해 아무것도 이름 붙이지 않아도 로드합니다. 항상 당신이 직접 트리거를 결정한다면 명령어를 사용하고, 모델이 스스로 인식해야 하는 트리거 조건이라면 스킬을 사용하세요.

서브에이전트를 스킬 대신 언제 써야 하나요?

작업이 경계가 명확하고 위임 가능하며, 메인 대화와 분리된 자체 컨텍스트 창에서 실행하고 싶을 때—어떻게 트리거되는지가 아니라 어디서 작업이 이루어지는지가 이유입니다. 스킬과 서브에이전트는 상호 배타적이지 않습니다. 스킬이 내부적으로 서브에이전트를 생성할 수 있습니다. 번역 스킬이 로케일당 서브에이전트 하나씩으로 글을 분산시키는 것처럼요.

스킬이 발행이나 결제 같은 행동을 자동으로 실행하게 두어도 안전한가요?

결과가 따르는 단계에 명시적 승인 게이트가 있을 때만 안전합니다. 스킬 자체의 자동 호출은 문제가 없습니다—그건 그저 Claude가 당신이 요청한 것을 인식했다는 의미일 뿐입니다. 위험한 것은 되돌리기 어려운 무언가의 자동 실행입니다. 초안 작성, 읽기, 보고는 자동 트리거되는 스킬 안에 두고, 발행·결제·삭제에는 별도의 명시적 확인을 요구하세요.

결국 셋 다 만들어야 하나요?

워크플로가 실제로 세 가지 형태를 모두 갖고 있을 때만 그렇습니다. 반복 가능한 작업이 몇 개뿐인 1인 운영자라면 오랫동안 슬래시 명령어만으로도 충분히 살아갈 수 있습니다. 스킬과 서브에이전트의 필요성은 명령어 이름을 더는 기억할 수 없을 만큼 서로 다른 트리거 조건이 많아지거나, 메인 컨텍스트에 남겨두면 품질이 떨어지기 시작할 만큼 경계가 명확한 하위 작업이 많아질 때 나타납니다.

---

Related: 페이스북 광고를 운영하는 Claude 스킬 · 컨텍스트 엔지니어링: 컨텍스트 창에 무엇을 담을 것인가 · 휴먼인더루프 AI 에이전트: 승인 게이트는 언제 만들어야 하나 · 제가 30개 이상의 프로덕션 에이전트를 운영하는 에이전트 스택

무엇을 자동화할지, 어떻게 해야 할지 도움이 필요하신가요? 문의하기 — 저는 운영팀을 위한 프로덕션 에이전트 시스템을 설계합니다.