클로드에게 일을 시키고 있습니다.

그런데 이상합니다.

AI가 일을 하는데
계획은 내가 세웁니다.

결과도 내가 확인합니다.

틀린 부분을 찾아 다시 지시하는 것도 나입니다.

다른 작업을 시킬 때마다
이전 내용을 복사해서 다시 설명합니다.

이렇게 사용하면 AI가 아무리 빨라도
사람이 계속 중간에 들어가야 합니다.

이번에는 방법을 조금 바꿔보겠습니다.

플래너 → 코더 → 테스터 → 리뷰어

4개의 클로드 AI 에이전트에게 역할을 하나씩 맡기겠습니다.

그리고 앞에서 나온 결과를 다음 에이전트가 자동으로 이어받게 만들어보겠습니다.

이번 글에서는 개념 설명에서 끝내지 않습니다.

실제로 Claude Code에 넣어서 사용할 수 있는 프롬프트와 파일 구조까지 만들어보겠습니다.

---

먼저 알아둘 점, 일반 클로드 채팅과는 조금 다릅니다

Claude 웹사이트에서 채팅창 4개를 열어놓는다고
에이전트 팀이 만들어지는 것은 아닙니다.

이번 글에서 사용하는 것은 Claude Code의 Custom Subagent 기능입니다.

현재 Claude Code에서는 프로젝트 안에

.claude/agents/

폴더를 만들고 Markdown 파일을 넣어
각기 다른 역할과 도구를 가진 서브에이전트를 정의할 수 있습니다. (Claude Platform Docs)

반복해서 사용할 작업 절차는

.claude/skills/

안에 Skill로 만들 수 있습니다.

예전의 .claude/commands/ 방식도 계속 작동하지만, 현재 공식 문서에서는 반복 작업을 새로 만들 때 Skills 방식을 사용하도록 안내하고 있습니다.

Claude Code는 이런 서브에이전트를 순서대로 실행할 수도 있습니다.

첫 번째 에이전트가 작업을 끝내면 결과를 받아
다음 에이전트에게 넘기는 방식입니다.

이 기능을 이용하겠습니다.

---

오늘 만들 AI 에이전트 팀

구조는 단순합니다.

사용자 요청
   ↓
Planner
   ↓
Coder
   ↓
Tester
   ↓
Reviewer
   ↓
최종 결과

각 에이전트가 하는 일도 하나만 정합니다.

Planner

무엇을 만들어야 하는지 분석합니다.

코드는 작성하지 않습니다.

Coder

Planner가 만든 계획을 읽고
그 내용만 구현합니다.

Tester

Coder가 만든 결과가
요구사항대로 작동하는지 검사합니다.

직접 고치지는 않습니다.

Reviewer

계획, 변경 내용, 테스트 결과를 모두 읽습니다.

마지막으로

SHIP / NEEDS WORK / BLOCK

중 하나를 결정합니다.

---

초보자도 이해하기 쉽게 실제 예제로 만들어보겠습니다

개발자 이야기만 하면 어렵습니다.

이번에는 이런 요청을 예제로 사용하겠습니다.

부모님과 제주도 2박 3일 여행을 준비하고 있습니다.
여행 일정을 한눈에 볼 수 있는 간단한 HTML 페이지를 만들어주세요.

조건도 몇 개 넣겠습니다.

• 60대 부모님과 함께 여행
• 하루 일정은 최대 3개
• 너무 많은 이동은 피할 것
• 아침·점심·저녁을 구분할 것
• 휴대폰에서도 보기 편할 것
• 글씨를 너무 작게 만들지 않을 것

이제 이 작업을 사람 대신
4명의 AI 에이전트가 나눠서 처리하게 만들어보겠습니다.

---

1단계. 프로젝트 폴더를 이렇게 만듭니다

Claude Code를 실행하는 프로젝트 안에 다음 구조를 만듭니다.

my-project/
│
├─ .claude/
│  ├─ agents/
│  │  ├─ planner.md
│  │  ├─ coder.md
│  │  ├─ tester.md
│  │  └─ reviewer.md
│  │
│  └─ skills/
│     └─ ship/
│        └─ SKILL.md
│
└─ .pipeline/

어렵게 보이지만 실제로 필요한 것은 Markdown 파일 5개입니다.

Claude Code의 프로젝트용 서브에이전트는 .claude/agents/ 아래에 저장할 수 있습니다. 각 파일에는 YAML 설정과 해당 에이전트의 역할을 설명하는 프롬프트를 넣습니다.

.pipeline 폴더는 우리가 임의로 만드는 작업 폴더입니다.

각 에이전트가 자신이 한 일을 여기에 기록하게 하겠습니다.

---

2단계. Planner 에이전트를 만듭니다

다음 파일을 만듭니다.

.claude/agents/planner.md

내용은 아래처럼 작성합니다.

---
name: planner
description: 사용자의 요청을 분석하고 구현 전에 상세 작업 계획과 완료 기준을 만드는 플래너
tools: Read, Glob, Grep, Write
---

당신은 이 프로젝트의 Planner입니다.

당신의 역할은 코드를 작성하는 것이 아니라
사용자의 요청을 명확한 구현 계획으로 바꾸는 것입니다.

반드시 다음 순서로 작업하세요.

1. 사용자의 요청을 정확하게 분석합니다.
2. 현재 프로젝트의 파일 구조를 확인합니다.
3. 기존 파일과 구조를 최대한 유지하는 방향으로 계획합니다.
4. 변경이 필요한 파일을 구체적으로 적습니다.
5. 필요한 기능을 정리합니다.
6. 예외 상황과 실패 가능성을 정리합니다.
7. 완료 여부를 판단할 수 있는 Acceptance Criteria를 작성합니다.
8. 중요한 정보가 부족하면 임의로 추측하지 말고 질문이 필요하다고 표시합니다.

금지 사항:

- 실제 제품 코드를 수정하지 마세요.
- 요청받지 않은 기능을 추가하지 마세요.
- 불확실한 요구사항을 임의로 결정하지 마세요.

작업이 끝나면 반드시 다음 파일에 결과를 저장하세요.

.pipeline/spec.md

spec.md는 다음 형식을 사용하세요.

# Goal
사용자가 원하는 최종 결과

# Requirements
필수 요구사항

# Files
변경하거나 생성할 파일

# Implementation Plan
구현 순서

# Edge Cases
예외 상황

# Acceptance Criteria
완료 여부를 판단할 구체적인 조건

# Questions
확인이 필요한 내용

여기서 중요한 부분이 있습니다.

Planner에게 코드를 쓰지 말라고 명확하게 제한했습니다.

계획과 실행을 한 AI에게 모두 맡기면
계획을 세우다가 바로 코드를 수정해버릴 수 있기 때문입니다.

역할을 나누려면
하지 말아야 할 일도 프롬프트에 적어주는 것이 좋습니다.

---

3단계. Coder 에이전트를 만듭니다

다음 파일입니다.

.claude/agents/coder.md

내용은 아래처럼 작성합니다.

---
name: coder
description: Planner가 작성한 spec을 읽고 요구된 범위만 실제 코드로 구현하는 개발 에이전트
tools: Read, Glob, Grep, Write, Edit, Bash
---

당신은 이 프로젝트의 Coder입니다.

구현을 시작하기 전에 반드시 다음 파일을 읽으세요.

.pipeline/spec.md

Planner가 작성한 계획과 Acceptance Criteria를 기준으로만 작업합니다.

작업 규칙:

1. spec.md에 명시된 요구사항만 구현합니다.
2. 기존 프로젝트의 코드 구조와 스타일을 먼저 확인합니다.
3. 기존 파일을 최대한 유지합니다.
4. 필요한 경우에만 새 파일을 만듭니다.
5. 요청하지 않은 기능을 임의로 추가하지 않습니다.
6. 기존 기능을 불필요하게 변경하지 않습니다.
7. 구현이 끝나면 가능한 범위에서 기본적인 실행 여부를 확인합니다.

중요:

당신은 Planner가 아닙니다.

요구사항을 다시 설계하거나 범위를 확대하지 마세요.

당신은 Reviewer도 아닙니다.

자신의 결과를 최종 승인하지 마세요.

작업 완료 후 다음 파일을 작성하세요.

.pipeline/changes.md

다음 내용을 포함하세요.

# Changed Files
변경한 파일 목록

# Changes
각 파일에서 변경한 내용

# Reason
왜 변경했는지

# Not Implemented
구현하지 못했거나 보류한 내용

# Notes
Tester가 알아야 할 내용

이번에는 반대로
Coder에게 계획을 다시 세우지 말라고 했습니다.

Coder의 일은 하나입니다.

Planner가 만든 명세대로 구현하는 것입니다.

---

4단계. Tester 에이전트를 만듭니다

다음 파일입니다.

.claude/agents/tester.md

아래 프롬프트를 사용합니다.

---
name: tester
description: 구현 결과가 Planner의 요구사항과 완료 기준을 충족하는지 검사하는 테스트 에이전트
tools: Read, Glob, Grep, Bash, Write
---

당신은 이 프로젝트의 Tester입니다.

반드시 다음 파일을 먼저 읽으세요.

.pipeline/spec.md
.pipeline/changes.md

그리고 실제 변경된 프로젝트 파일을 확인하세요.

당신의 역할은 문제를 찾고 보고하는 것입니다.

코드를 직접 수정하면 안 됩니다.

다음 항목을 검사하세요.

1. Planner의 모든 Requirements가 구현되었는지
2. Acceptance Criteria를 각각 통과하는지
3. 정상적인 사용 상황에서 문제가 없는지
4. Planner가 지정한 Edge Cases가 처리되는지
5. 기존 기능을 깨뜨린 부분이 없는지
6. 실행 가능한 테스트나 빌드 명령이 있다면 직접 실행할 것

각 Acceptance Criteria에 대해 반드시

PASS
또는
FAIL

중 하나를 표시하세요.

문제가 발견되어도 직접 고치지 마세요.

문제와 재현 방법만 정확하게 기록하세요.

결과는 다음 파일에 저장하세요.

.pipeline/test-results.md

형식:

# Test Summary
전체 결과

# Acceptance Criteria

- 조건 1: PASS / FAIL
- 조건 2: PASS / FAIL

# Failed Tests
실패한 내용

# Reproduction
문제를 다시 확인하는 방법

# Risks
추가로 확인해야 할 위험 요소

# Final Test Status
PASS 또는 FAIL

이 부분은 꽤 중요합니다.

보통 AI에게

테스트하고 문제 있으면 알아서 고쳐줘.

라고 합니다.

편하지만 역할이 섞입니다.

이번에는 다르게 합니다.

Tester에게는

찾기까지만 하세요. 고치지는 마세요.

라고 지시했습니다.

그래야 Tester가 Coder의 결과를 독립적으로 검증할 수 있습니다.

---

5단계. 마지막 Reviewer를 만듭니다

이제 마지막입니다.

.claude/agents/reviewer.md

프롬프트는 다음과 같습니다.

---
name: reviewer
description: 계획, 코드 변경, 테스트 결과를 종합해서 최종 승인 여부를 결정하는 리뷰 에이전트
tools: Read, Glob, Grep, Bash, Write
---

당신은 이 프로젝트의 최종 Reviewer입니다.

반드시 다음 파일을 모두 읽으세요.

.pipeline/spec.md
.pipeline/changes.md
.pipeline/test-results.md

그리고 실제 변경된 파일도 확인하세요.

검토 순서:

1. 사용자의 최초 요구사항이 충족되었는지 확인
2. spec.md의 Requirements 확인
3. Acceptance Criteria 확인
4. 실제 변경 파일 확인
5. test-results.md 확인
6. 요청하지 않은 변경이 포함되었는지 확인
7. 명백한 오류나 위험 요소가 없는지 확인

당신은 코드를 수정하지 않습니다.

문제를 발견하면 무엇이 문제인지 적어주세요.

최종 판정은 반드시 다음 3개 중 하나만 사용하세요.

SHIP
모든 필수 조건을 충족했고 배포 가능한 상태

NEEDS WORK
전체 방향은 맞지만 수정해야 할 문제가 있음

BLOCK
중요한 요구사항 누락, 심각한 오류 또는 안전 문제가 있음

결과를 다음 파일에 저장하세요.

.pipeline/review.md

형식:

# Review Summary

# Requirements Check

# Test Result

# Issues

# Final Verdict
SHIP / NEEDS WORK / BLOCK

# Reason
판정 이유

이제 4명의 역할이 완성됐습니다.

---

그런데 매번 4명을 직접 호출하면 귀찮지 않을까요?

맞습니다.

이 상태에서는 이렇게 해야 합니다.

Planner 실행
↓
완료 기다림
↓
Coder 실행
↓
완료 기다림
↓
Tester 실행
↓
완료 기다림
↓
Reviewer 실행

이것도 사람이 계속 개입하는 구조입니다.

그래서 마지막으로 오케스트레이터 역할을 하는 Skill을 하나 만듭니다.

현재 Claude Code는 반복적인 절차를 .claude/skills/<skill-name>/SKILL.md에 저장하고 /skill-name으로 직접 실행할 수 있습니다. (Claude Platform Docs)

---

6단계. /ship 명령을 만듭니다

다음 파일을 만듭니다.

.claude/skills/ship/SKILL.md

그리고 아래 내용을 넣습니다.

---
name: ship
description: Planner → Coder → Tester → Reviewer 순서로 전체 작업을 실행하는 4단계 개발 워크플로우
disable-model-invocation: true
argument-hint: "[작업 내용]"
---

사용자 요청:

$ARGUMENTS

이 작업을 다음 4단계로 순서대로 처리하세요.

반드시 앞 단계가 완료된 뒤 다음 단계로 진행하세요.

## STEP 1 - Planner

planner 서브에이전트를 실행하세요.

사용자의 전체 요청을 전달하고

.pipeline/spec.md

를 작성하게 하세요.

완료 후 spec.md를 읽으세요.

중대한 질문이 남아 구현할 수 없는 경우 작업을 중단하고 사용자에게 질문하세요.

## STEP 2 - Coder

coder 서브에이전트를 실행하세요.

반드시

.pipeline/spec.md

를 기준으로 구현하도록 지시하세요.

구현 완료 후

.pipeline/changes.md

가 생성되었는지 확인하세요.

## STEP 3 - Tester

tester 서브에이전트를 실행하세요.

다음을 기준으로 검증하게 하세요.

.pipeline/spec.md
.pipeline/changes.md
실제 변경된 파일

검증 결과는

.pipeline/test-results.md

에 저장하게 하세요.

Tester는 코드를 수정하면 안 됩니다.

## STEP 4 - Reviewer

reviewer 서브에이전트를 실행하세요.

다음 자료를 모두 검토하게 하세요.

.pipeline/spec.md
.pipeline/changes.md
.pipeline/test-results.md
실제 변경 파일

결과를

.pipeline/review.md

에 저장하게 하세요.

## 완료 후

사용자에게 다음 내용만 간단히 보고하세요.

- 변경한 내용
- 테스트 결과
- 최종 판정
- 사용자가 직접 확인해야 할 내용

최종 판정은 반드시 다음 중 하나여야 합니다.

SHIP
NEEDS WORK
BLOCK

중요:

사용자의 별도 요청이 없다면
git commit, push, 배포는 하지 마세요.

이제 준비가 끝났습니다.

---

실제로 어떻게 사용하나요?

Claude Code에서 이제 이렇게 입력하면 됩니다.

/ship 부모님과 제주도 2박 3일 여행 일정을 볼 수 있는 반응형 HTML 페이지를 만들어줘.

조건:
- 60대 부모님과 함께 가는 여행
- 하루 일정 최대 3개
- 아침, 점심, 저녁 구분
- 이동이 너무 많지 않게 구성
- 스마트폰에서도 보기 편할 것
- 본문 글씨는 너무 작지 않을 것
- 날짜별 카드를 사용
- 별도의 프레임워크 없이 HTML, CSS, JavaScript만 사용할 것

사용자가 입력하는 명령은 이것 하나입니다.

Claude Code 안에서는 다음 순서로 작업하게 됩니다.

/ship
  ↓
Planner
  ↓
.pipeline/spec.md
  ↓
Coder
  ↓
.pipeline/changes.md
  ↓
Tester
  ↓
.pipeline/test-results.md
  ↓
Reviewer
  ↓
.pipeline/review.md

Claude Code 공식 문서에서도 여러 단계가 필요한 작업에서 서브에이전트를 순차적으로 연결해 앞 작업의 결과를 다음 서브에이전트에 전달하는 방식을 안내하고 있습니다. (Claude Platform Docs)

---

Planner는 실제로 이런 문서를 만들게 됩니다

예를 들어 spec.md에는 이런 내용이 들어갈 수 있습니다.

# Goal

60대 부모님과 함께하는 2박 3일 제주 여행 일정을
스마트폰에서 쉽게 확인할 수 있는 HTML 페이지로 만든다.

# Requirements

- 3일 일정
- 하루 최대 3개 일정
- 아침/점심/저녁 구분
- 모바일 우선 디자인
- 큰 글씨 사용
- 날짜별 카드 구성

# Files

- index.html
- style.css
- script.js

# Acceptance Criteria

1. 360px 화면에서도 가로 스크롤이 생기지 않는다.
2. 날짜별 일정이 명확하게 구분된다.
3. 본문 주요 글씨가 지나치게 작지 않다.
4. 하루 일정이 3개를 넘지 않는다.
5. HTML 파일을 브라우저에서 정상적으로 열 수 있다.

Coder는 이것을 보고 구현합니다.

Tester는 다시 이 조건을 읽고

360px에서 가로 스크롤이 생기는가?
날짜가 구분되어 있는가?
하루 일정이 3개 이하인가?

를 검사합니다.

Reviewer는 마지막으로 전체 결과를 확인합니다.

---

프롬프트에서 꼭 넣어야 하는 문장이 있습니다

에이전트를 만들 때 단순히

너는 Tester야.

라고만 하면 부족합니다.

실무에서는 최소한 다음 5가지는 넣는 것이 좋습니다.

1. 무엇을 해야 하는가

당신의 역할은 구현 결과를 검사하는 것입니다.

2. 무엇을 하지 말아야 하는가

문제를 발견해도 직접 코드를 수정하지 마세요.

3. 무엇을 읽어야 하는가

작업 전에 spec.md와 changes.md를 반드시 읽으세요.

4. 결과를 어디에 남길 것인가

결과는 .pipeline/test-results.md에 저장하세요.

5. 완료 기준은 무엇인가

각 Acceptance Criteria를 PASS 또는 FAIL로 판정하세요.

이 다섯 가지가 있어야
각 에이전트의 역할이 섞이는 것을 줄일 수 있습니다.

---

특히 Acceptance Criteria를 빼면 안 됩니다

AI에게

보기 좋은 페이지 만들어줘.

라고 하면 Tester가 무엇을 검사해야 할지 애매합니다.

반대로 이렇게 작성하면 달라집니다.

- 모바일 360px 화면에서 가로 스크롤이 없어야 한다.
- 하루 일정은 최대 3개여야 한다.
- 날짜별 일정이 시각적으로 구분되어야 한다.
- index.html을 직접 열었을 때 오류 없이 표시되어야 한다.

판단할 수 있는 조건이 생겼습니다.

그래야 Tester가

조건 1 PASS
조건 2 PASS
조건 3 FAIL
조건 4 PASS

처럼 결과를 낼 수 있습니다.

“잘 만들어졌는지 확인해줘”보다 “어떤 상태면 통과인지”를 먼저 정의하는 편이 훨씬 명확합니다.

---

Tester가 FAIL을 냈다면 어떻게 해야 할까요?

예를 들어 이런 결과가 나왔다고 하겠습니다.

Final Test Status: FAIL

문제:
360px 화면에서 일정 카드가 화면 밖으로 넘어감

Reviewer는 테스트 결과를 읽습니다.

그리고

NEEDS WORK

판정을 내릴 수 있습니다.

이때 다시 이렇게 실행하면 됩니다.

/ship 기존 테스트 결과에서 발견된 모바일 가로 넘침 문제를 수정해줘.
다른 기능과 디자인은 변경하지 마.

다시

계획
→ 수정
→ 테스트
→ 리뷰

과정이 진행됩니다.

이렇게 반복하면서 결과를 다듬을 수 있습니다.

---

모든 작업을 4개의 에이전트로 나눌 필요는 없습니다

처음 사용하는 분이라면
4개를 한꺼번에 만들 필요도 없습니다.

먼저 두 개만 사용해보세요.

Planner
↓
Coder

이 구조가 잘 작동하면 Tester를 추가합니다.

Planner
↓
Coder
↓
Tester

여기까지 익숙해지면
Reviewer를 마지막에 추가하면 됩니다.

Claude Code는 프로젝트용 커스텀 서브에이전트를 .claude/agents/에 저장해 반복해서 사용할 수 있기 때문에 한번 만들어두면 같은 역할을 다른 작업에서도 다시 사용할 수 있습니다.

---

브라우저에서 실제 화면까지 자동 검사하고 싶다면?

여기에는 한 단계가 더 필요합니다.

현재 예제 Tester는 프로젝트 파일과 실행 가능한 명령을 검사합니다.

실제 브라우저를 열어서

• 버튼을 클릭하고
• 화면 크기를 변경하고
• 페이지를 캡처하고
• 사용자처럼 기능을 실행하는 것

까지 검사하려면 브라우저를 조작할 수 있는 별도의 도구가 필요합니다.

Claude Code의 서브에이전트는 필요한 경우 MCP 서버 같은 외부 도구를 특정 에이전트에 연결할 수 있으며, Anthropic 공식 문서에서도 Playwright를 연결한 브라우저 테스트 에이전트 예제를 제공합니다. (Claude Platform Docs)

처음에는 여기까지 할 필요 없습니다.

파일 검사와 기본 테스트부터 시작하는 편이 쉽습니다.

---

AI 에이전트 팀을 만들 때 자주 하는 실수

역할을 너무 많이 줍니다

Planner에게

계획도 하고,
구현도 하고,
테스트하고,
잘못되면 수정하고,
최종 검토까지 해줘.

라고 하면 다시 AI 한 명에게 모든 일을 맡기는 것과 비슷해집니다.

역할을 작게 나누는 편이 좋습니다.

에이전트마다 같은 일을 시킵니다

Coder도 코드를 검토합니다.

Tester도 수정합니다.

Reviewer도 다시 구현합니다.

이렇게 되면 역할을 나눈 의미가 줄어듭니다.

결과 형식을 지정하지 않습니다

각 에이전트가 서로 다른 형태로 결과를 만들면
다음 단계에서 읽기가 어려워집니다.

그래서

spec.md
changes.md
test-results.md
review.md

처럼 결과물을 미리 정해두는 것입니다.

실패했을 때 멈추는 조건이 없습니다

AI에게 무조건 끝까지 진행하라고 하면
잘못된 계획을 기반으로 다음 작업까지 진행할 수 있습니다.

그래서

중대한 정보가 부족하면 실행하지 말고 질문하세요.

같은 중단 조건도 넣어두는 것이 좋습니다.

---

AI를 많이 쓰는 것과 AI가 서로 일하게 만드는 것은 다릅니다

기존에는 사람이 가운데 있었습니다.

나
↓
AI에게 계획 요청

나
↓
결과 복사

나
↓
AI에게 실행 요청

나
↓
결과 확인

나
↓
AI에게 테스트 요청

에이전트 구조에서는 이를 이렇게 바꿀 수 있습니다.

나
↓
/ship 한 줄 입력

Planner
↓
Coder
↓
Tester
↓
Reviewer

사람이 없어지는 것은 아닙니다.

마지막 결과를 확인하고
중요한 판단을 하는 사람은 여전히 필요합니다.

대신 사람이 계속 복사하고 붙여넣고 다음 단계를 설명하는 일을 줄일 수 있습니다.

처음에는 거창한 자동화를 만들 필요 없습니다.

반복해서 AI에게 시키는 작업 하나를 골라보세요.

그리고 먼저 이렇게 나눠보시면 됩니다.

계획하는 AI
+
실행하는 AI

여기에 검사가 필요해지면 Tester를 추가합니다.

최종 판단이 중요해지면 Reviewer까지 붙입니다.

그렇게 하나씩 연결하면
혼자 사용하는 클로드도 역할이 나뉜 AI 팀처럼 활용할 수 있습니다.

---

자주 묻는 질문

Claude 웹 채팅에서도 똑같이 만들 수 있나요?

역할별 프롬프트를 각각 사용해 비슷한 작업 흐름을 수동으로 체험할 수는 있습니다. 다만 이 글처럼 프로젝트 파일을 읽고 쓰면서 커스텀 서브에이전트를 정의하고 순차적으로 연결하려면 Claude Code 환경이 더 적합합니다. Claude Code는 현재 터미널, IDE, 데스크톱 앱, 웹 등 여러 환경에서 사용할 수 있습니다. (Claude Platform Docs)

.claude/commands/ship.md를 만들면 안 되나요?

기존 방식도 계속 작동합니다. 다만 Anthropic은 Custom Commands를 Skills에 통합했으며, 새로 만드는 반복 작업은 .claude/skills/ship/SKILL.md 형태로 구성할 수 있습니다. /ship처럼 호출하는 방식은 동일합니다. (Claude Platform Docs)

에이전트끼리 정말 순서대로 실행할 수 있나요?

가능합니다. Anthropic 공식 문서에서도 다단계 작업에서 한 서브에이전트가 완료된 뒤 결과를 다음 서브에이전트에 전달하는 체인 방식을 안내하고 있습니다. (Claude Platform Docs)

에이전트가 많을수록 좋은가요?

그렇지는 않습니다.

간단한 작업이라면 하나의 Claude가 처리하는 편이 더 빠를 수 있습니다.

역할이 명확하게 나뉘고 중간 검증이 필요한 작업부터 두세 개의 에이전트로 나눠보는 편이 좋습니다.