B-9 무엇을 쓸까 — 스킬 · 에이전트

개념한 문장

셋은 경쟁 관계가 아니다

스킬 · 에이전트 · 플러그인은 서로 대체하는 것이 아닙니다. 각각 담당하는 층이 달라서, 실제로는 같이 씁니다.

	비유	실체
스킬	업무 매뉴얼	절차를 적어둔 문서 — 필요할 때 펼쳐 읽는다
에이전트	일을 맡길 담당자	별도 문맥에서 스스로 판단하며 도는 일꾼
플러그인	둘을 담은 상자	스킬·에이전트를 묶어 한 번에 배포하는 단위

가장 흔한 오해"에이전트가 스킬보다 좋은 것"이 아닙니다. 절차가 이미 정해진 일에 에이전트를 쓰면 느리고 결과도 흔들립니다.

판단질문 세 개

위에서부터 물어본다

고민되면 아래 순서로 묻습니다. 처음 "예"가 나온 곳이 답입니다.

매번 같은 절차로 끝나는 일인가? → 스킬

순서가 정해져 있고 판단이 거의 필요 없다면 적어두는 것으로 충분합니다. 주간보고 서식, 릴리스 노트, 배포 순서 — 대부분 여기에 해당합니다.

스스로 찾고 판단해야 하는 일인가? → 에이전트

무엇을 볼지 미리 정할 수 없고, 결과를 보며 다음을 정해야 하면 맡겨야 합니다. 코드 조사, 리뷰, 원인 추적처럼 탐색이 필요한 일입니다.

남에게 나눠줘야 하는 일인가? → 플러그인

스킬·에이전트가 여러 개 모여 하나의 세트가 되었고, 팀이나 외부에 배포해야 한다면 묶어서 설치·업데이트할 단위가 필요합니다.

그럼 훅과 명령어는?둘은 성격이 다릅니다 — 훅은 "반드시" 지켜야 할 통제, 명령어는 내가 직접 부르는 단축키입니다. B-5에서 다뤘습니다.

비교한 표로

무엇이 어떻게 다른가

	스킬	에이전트	플러그인
맡기는 것	정해진 절차	판단이 필요한 작업	구성 묶음의 배포
부르는 방법	상황에 맞으면 자동	Claude가 위임 / 내가 지정	설치하면 안의 것들이 등록됨
문맥	메인 문맥에 본문만 로드	별도 문맥 — 메인이 깨끗	해당 없음 (그릇)
비용 · 속도	가볍다	무겁다 — 왕복이 생김	해당 없음
공유 방법	폴더 커밋	폴더 커밋	설치 한 줄
적합 규모	절차 1개	역할 1개	구성 3개 이상

비용 감각에이전트는 별도 문맥을 새로 채웁니다. 문맥 절약에는 유리하지만 왕복 시간과 토큰이 듭니다 — 절차로 끝날 일에 쓰면 손해입니다.

사례이럴 때 이걸

실무 상황으로 고르기

상황	답	왜
매주 같은 서식으로 주간보고를 쓴다	스킬	절차가 고정 — 적어두면 끝
릴리스 노트를 태그 사이 커밋으로 만든다	스킬	단계가 명확하고 매번 동일
배포 전 점검 목록을 순서대로 돈다	스킬	판단보다 빠뜨리지 않는 것이 중요
이 기능이 어디에 구현됐는지 찾아야 한다	에이전트	어디를 볼지 미리 알 수 없다 — 탐색
커밋 전 변경분을 리뷰한다	에이전트	결과에 따라 더 파봐야 한다 — 판단
테스트가 왜 깨졌는지 원인을 찾는다	에이전트	가설을 세우고 확인하는 반복이 필요
큰 코드베이스를 조사하는데 문맥이 찬다	에이전트	별도 문맥에서 조사하고 요약만 받는다
우리 팀 표준 작업 세트를 전 팀원에게 깐다	플러그인	설치 한 줄로 동일 환경 — 업데이트도 함께
부서별 규칙 세트를 여러 저장소에 적용한다	플러그인	복사·붙여넣기로는 버전이 갈린다
스킬 5개 + 에이전트 3개가 한 흐름으로 돈다	플러그인	묶어야 순서와 버전을 관리할 수 있다

조합실제로는 함께

같이 쓰는 모양

규모가 커지면 셋이 계층으로 겹칩니다. 플러그인이 그릇, 안에 에이전트와 스킬이 들어갑니다.

[플러그인]  주간보고 세트          ← 설치 한 줄로 팀 배포
   ├── [에이전트] 수집 담당      ← 커밋 · 티켓을 찾아온다 (판단 필요)
   ├── [에이전트] 검토 담당      ← 숫자가 원본과 맞는지 확인
   ├── [스킬] 요약 작성          ← 서식이 고정된 절차
   ├── [스킬] 배포               ← 어디에 올릴지 정해져 있다
   └── [스킬] orchestrator       ← 누가 언제 무엇을 (전체 흐름)

이 조합을 손으로 설계하지 않아도 됩니다. B-8 하네스가 도메인 설명을 받아 이런 구조를 만들어 줍니다.

커지는 순서스킬 하나 → 스킬 몇 개 → 에이전트 추가 → 플러그인으로 묶음. 반대 순서로 시작하면 거의 실패합니다.

주의흔한 실수

이렇게는 쓰지 않는다

흔한 실수	왜 문제인가	대신
절차로 끝날 일에 에이전트를 쓴다	느리고 매번 결과가 달라진다	스킬로 절차를 고정
에이전트 정의에 절차를 다 적는다	길어져 지켜지지 않고, 재사용도 안 된다	절차는 스킬로 분리해 참조
혼자 쓰면서 플러그인화한다	관리 비용만 늘고 얻는 게 없다	폴더 커밋으로 충분
"반드시" 지킬 일을 스킬에 적는다	스킬은 지침이라 100% 보장 안 됨	훅으로 강제 (B-5)
처음부터 에이전트 8개를 만든다	어디서 틀어졌는지 추적이 안 된다	2~3개가 확실히 도는 것부터

실습10분

내 업무를 분류해보기

반복하는 업무 3개를 적고, 각각 무엇으로 만들지 판단해봅니다. 아래를 그대로 붙여 쓰세요.

내가 반복하는 업무 3개를 적을게. 각각 스킬 / 에이전트 / 플러그인 중
무엇으로 만들면 좋은지 판단하고, 이유를 한 줄로 말해줘.

판단 기준:
- 절차가 고정되어 있으면 스킬
- 스스로 찾고 판단해야 하면 에이전트
- 여러 개를 묶어 팀에 배포해야 하면 플러그인

업무:
1) (예: 매주 월요일 주간보고 작성)
2)
3)

답이 나오면 가장 자주 하는 것 하나만 골라 실제로 만들어 봅니다.

세 가지의 역할 차이를 한 문장으로 말할 수 있다
질문 세 개로 내 업무를 분류해봤다
에이전트가 비싼 선택인 이유를 안다
훅·명령어가 왜 다른 층인지 구분할 수 있다
가장 자주 하는 업무 하나를 실제로 만들었다

다음트랙 B가 끝났습니다. 캡스톤에서 지금까지의 도구를 하나의 워크플로로 묶습니다.

클로드코드 시작하기트랙 B · 개발자