Claude Code CLI로 여러 에이전트를 활용하다 보면 Subagents, Agent Teams, Skills, 하네스(Harness) 같은 용어가 한꺼번에 등장해요. 무엇을 따로 활성화해야 하는지 헷갈리기 쉬운데요. 먼저 각 개념의 차이를 정리하고, Claude Code와 Codex CLI에서 실전 하네스를 구축하는 방법까지 살펴볼게요.
서브에이전트, Agent Teams, 하네스의 차이
Claude Code CLI에서는 일반 서브에이전트(Subagent)와 에이전트 팀(Agent Teams)의 활성화 방식이 달라요. 핵심은 다음과 같습니다.
| 기능 | 별도 활성화 | 설명 |
|---|---|---|
| Subagents | 필요 없음 | Claude Code가 작업을 별도 에이전트에 위임 |
| Agent Teams | 필요 | 여러 Claude Code 인스턴스가 팀을 구성해 협업 |
| Harness | 일반적으로 불필요 | 에이전트 실행·도구·검증 등을 관리하는 운영 구조 |
| Skills | 필요 없음 | 필요할 때 스킬을 자동 또는 명시적으로 호출 |
즉, 서브에이전트를 사용하기 위해 Agent Teams를 활성화할 필요는 없어요.
1. Agent Teams 활성화 방법
macOS에서 ~/.claude/settings.json 파일을 열고 다음 설정을 추가하면 됩니다.
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}이미 settings.json에 다른 설정이 있다면 기존 설정을 유지하면서 env 항목에 병합하세요.
설정 후 Claude Code CLI를 재시작하면 됩니다. 공식 문서에서도 이 환경 변수를 통해 실험적 Agent Teams 기능을 활성화하도록 안내합니다.
일회성으로 테스트하려면 터미널에서 다음과 같이 실행할 수도 있어요.
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude2. 서브에이전트와 Agent Teams 차이
- Subagents — 기본 사용 가능: 메인 에이전트가 작업을 위임하고 결과를 받는 구조
- Agent Teams — 별도 활성화: 팀원들이 독립적인 컨텍스트를 가지고 서로 협업하는 구조
3. 하네스(Harness)는 별도 활성화해야 할까?
일반적으로 아니에요. 하네스는 특정한 Agent Teams 기능이 아니라 에이전트를 실행하고 통제하는 구조를 의미합니다.
예를 들어 CLAUDE.md, Skills, Subagents, Hooks, MCP, 테스트 및 검증 절차 등을 조합하여 하네스를 구성할 수 있어요. 따라서 하네스를 구축한다고 해서 Agent Teams를 반드시 활성화해야 하는 것은 아닙니다.
4. 추천 설정
개인 웹앱 개발에서 여러 에이전트를 활용할 계획이라면 다음과 같이 시작하는 것을 추천해요.
- 기본 개발: Subagents 활용
- 독립적인 프론트엔드·백엔드·테스트 병렬 작업: Agent Teams 활용
- 품질 관리: CLAUDE.md + Hooks + 테스트 자동화
- 반복 개발 프로세스: Skills로 작업 절차 표준화
참고: Agent Teams는 각 팀원이 별도 컨텍스트를 사용하므로 토큰 소비가 더 많을 수 있어요.
공식 문서: Claude Code Agent Teams
Claude Code CLI 실전 하네스 구축 가이드
개인 웹앱 개발을 기준으로 PRD → 설계 → 구현 → 코드 리뷰 → 테스트까지 Claude Code의 Subagents, Agent Teams, Skills, Hooks를 조합하는 방법을 설명할게요.
목표는 Claude에게 단순히 코드를 작성시키는 것이 아니라, 역할별 전문 에이전트가 정해진 개발 절차와 품질 기준에 따라 협업하는 환경을 만드는 것입니다.
1. 하네스의 전체 구조
사용자 (개발 목표 전달)
예: Firebase 기반 To-Do 웹앱 개발
│
▼
Claude Code — Main Agent
작업 분해 · 위임 · 진행 관리 · 결과 통합
│
├── 01 Planner PRD · 요구사항
├── 02 Architect 설계 · 데이터 구조
├── 03 Developer 코드 구현
└── 04 Reviewer / QA 검토 · 테스트
공통 하네스: CLAUDE.md · Skills · Hooks · 테스트 · Git여기서 중요한 점은 모든 에이전트를 동시에 실행할 필요가 없다는 거예요.
PRD 작성과 아키텍처 설계는 순차적으로 진행하고, 독립적인 구현 작업은 병렬화하며, 코드 리뷰와 테스트는 구현 결과를 기반으로 수행하는 것이 효율적입니다.
2. 추천 프로젝트 폴더 구조
my-webapp/
├── CLAUDE.md
├── .claude/
│ ├── settings.json
│ ├── agents/
│ │ ├── planner.md
│ │ ├── architect.md
│ │ ├── developer.md
│ │ └── reviewer.md
│ └── skills/
│ ├── create-prd/
│ │ └── SKILL.md
│ └── code-review/
│ └── SKILL.md
├── docs/
│ ├── PRD.md
│ ├── ARCHITECTURE.md
│ └── DESIGN_SYSTEM.md
├── src/
├── tests/
└── package.json각 구성 요소의 역할은 다음과 같습니다.
| 구성 | 역할 |
|---|---|
CLAUDE.md | 프로젝트 전체 개발 규칙 |
agents/ | 전문 서브에이전트 정의 |
skills/ | 재사용 가능한 작업 절차 |
settings.json | 권한 및 Hooks 설정 |
docs/ | 요구사항과 설계의 기준 문서 |
tests/ | 구현 결과 자동 검증 |
3. 실제 설정 파일 작성
① 프로젝트 규칙: CLAUDE.md
이 파일은 모든 개발 작업의 공통 기준이에요.
# Project Development Rules
## Tech Stack
- Next.js + TypeScript
- Tailwind CSS
- Firebase
- Vercel
## Development Workflow
1. Requirements (PRD)
2. Architecture Design
3. UI/UX Design
4. Implementation
5. Code Review
6. Testing
## Mandatory Rules
- PRD 승인 전 구현 금지
- 설계 변경 시 관련 문서 먼저 수정
- TypeScript strict mode 사용
- 기존 코드 스타일 유지
- 불필요한 의존성 추가 금지
- 변경된 기능에 대한 테스트 수행
- 배포 및 Git push는 사용자 승인 필요
## Agent Delegation
- planner: 요구사항 및 PRD
- architect: 시스템 설계
- developer: 구현
- reviewer: 코드 검토
## Quality Gate
- TypeScript 검사 통과
- ESLint 검사 통과
- 테스트 통과
- 심각한 보안 취약점 없음특히 PRD 승인 전 구현 금지라는 규칙을 두면 설계 단계에서 Claude가 임의로 코드를 작성하는 일을 줄일 수 있어요.
다만 CLAUDE.md는 에이전트에 제공하는 지침이지 기술적으로 모든 작업을 강제 차단하는 보안 장치는 아닙니다. 중요한 제한은 권한 설정이나 Hooks로 보완해야 해요.
② Subagent 정의: .claude/agents/planner.md
---
name: planner
description: 요구사항 분석과 PRD 작성 전문 에이전트
tools: Read, Write, Glob, Grep
model: sonnet
---
You are a senior product manager.
Responsibilities:
- 사용자 요구사항 분석
- 기능 및 비기능 요구사항 정의
- MVP 범위 결정
- 사용자 시나리오 작성
- PRD 문서 작성
Rules:
- 코드를 구현하지 않는다.
- 모호한 요구사항은 질문한다.
- 문서는 docs/PRD.md에 작성한다.
- 완료 후 사용자 승인을 요청한다.이렇게 하면 Planner는 기획 업무에 집중하도록 구성됩니다.
③ 코드 리뷰 에이전트: .claude/agents/reviewer.md
---
name: reviewer
description: 코드 품질 및 보안 검토 전문 에이전트
tools: Read, Glob, Grep, Bash
model: sonnet
---
You are a senior code reviewer.
Review Criteria:
1. TypeScript type safety
2. Security vulnerabilities
3. Performance problems
4. Error handling
5. Code maintainability
6. PRD compliance
Rules:
- 코드를 직접 수정하지 않는다.
- 문제의 심각도를 구분한다.
- 파일명과 수정 권장사항을 제시한다.
- 문제가 없다면 승인 의견을 작성한다.Architect와 Developer도 동일한 구조로 만들 수 있어요. Architect에는 설계 문서 작성 책임을, Developer에는 승인된 설계 범위 내 구현 책임을 부여합니다.
4. Skills로 작업 절차 표준화
Subagent가 누가 작업하는지 정의한다면, Skill은 어떤 절차로 작업하는지 정의해요.
예를 들어 .claude/skills/create-prd/SKILL.md를 다음처럼 작성합니다.
---
name: create-prd
description: 표준 PRD 문서 생성
---
# PRD Creation
Follow these steps:
1. 사용자 목표 분석
2. 대상 사용자 정의
3. 핵심 기능 목록 작성
4. MVP 범위 결정
5. 사용자 흐름 정의
6. 비기능 요구사항 작성
7. 수용 기준 작성
8. 미결정 사항 정리
Output:
docs/PRD.md
Do not implement code.이제 Claude Code에서 다음과 같이 요청할 수 있어요.
/create-prd
Firebase 기반 개인 To-Do 앱의
PRD를 작성해줘.5. Agent Teams 활성화 및 활용
Agent Teams는 프로젝트 또는 전역 설정에서 활성화할 수 있어요. 프로젝트 전용 .claude/settings.json 예시입니다.
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}이 설정은 공식 환경 변수 문서에서도 확인됩니다. 이후 Claude Code에서 다음과 같이 요청합니다.
Agent Team을 구성해줘.
팀원 1: 프론트엔드 구현
팀원 2: Firebase 백엔드 구현
팀원 3: 테스트 코드 작성
docs/PRD.md와
docs/ARCHITECTURE.md를 기준으로 작업해.
서로 수정하는 파일이 겹치지 않게 하고,
작업 완료 후 결과를 통합해서 검증해줘.Agent Teams는 Subagents와 달리 팀원들이 서로 메시지를 주고받으며 협업할 수 있어요. 다만 별도 인스턴스를 실행하므로 토큰 사용량이 증가합니다.
6. Hooks로 자동 품질 검사 구성
Hooks는 특정 이벤트가 발생했을 때 지정된 명령을 실행하는 기능이에요. 예를 들어 Claude가 파일을 수정한 뒤 자동으로 ESLint 검사를 실행하도록 설정할 수 있습니다.
.claude/settings.json 예시:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
},
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "npm run lint",
"timeout": 120
}
]
}
]
}
}이 설정은 프로젝트에 lint 스크립트가 존재한다는 전제예요. 파일 수정마다 실행되므로 대규모 프로젝트에서는 비용이 커질 수 있습니다.
또한 PostToolUse는 작업 이후에 실행되므로 수정 자체를 막지는 못해요. PRD 승인 전 코드 수정을 실제로 차단하려면 PreToolUse와 별도의 검증 스크립트가 필요합니다.
7. 실제 개발 진행 시나리오
- 기획 — Planner
PRD.md작성 → 사용자 검토 → 승인- 완료 기준: MVP 범위와 수용 기준 확정
- 설계 — Architect
ARCHITECTURE.md, 데이터 모델, API 및 화면 구조 작성- 완료 기준: 설계 검토 및 승인
- 구현 — Developer 또는 Agent Teams
- 독립적인 UI, 백엔드, 테스트 작업 병렬 진행
- 완료 기준: 기능 구현 및 통합
- 검토 — Reviewer
- 보안, 코드 품질, 설계 준수 여부 점검
- 완료 기준: 주요 문제 해결
- 검증 — 테스트 및 Hooks
- TypeScript, ESLint, 단위 테스트, 빌드 확인
- 완료 기준: 모든 필수 검사 통과
8. 어떤 구성을 추천할까?
| 구성 | 적합한 상황 | 토큰 사용량 |
|---|---|---|
| Main Agent만 사용 | 작은 버그 수정 | 낮음 |
| Main + Subagents | 일반적인 웹앱 개발 | 중간 |
| Agent Teams | 독립적인 기능 병렬 개발 | 높음 |
| Subagents + Skills + Hooks | 반복적인 개인 프로젝트 | 중간 |
| Agent Teams + 전체 Harness | 규모가 큰 복합 프로젝트 | 매우 높음 |
개인 웹앱 개발이라면 Subagents + Skills + Hooks를 기본 하네스로 추천해요. Agent Teams는 여러 기능을 병렬 구현해야 할 때 선택적으로 활성화하는 편이 효율적입니다.
그리고 하네스를 처음부터 지나치게 복잡하게 만들기보다는 Planner, Architect, Developer, Reviewer의 4개 역할과 2~3개의 핵심 Skill부터 시작하는 것이 좋아요.
이렇게 구축하면 새로운 Next.js/Firebase 프로젝트를 만들 때마다 동일한 개발 절차와 품질 기준을 재사용할 수 있습니다.
참고할 공식 문서: Subagents · Skills · Hooks
Codex CLI 하네스 구축 가이드 — Claude Code와 공통 활용
OpenAI의 Codex CLI에서도 Claude Code와 유사한 에이전트 기반 개발 하네스를 구축할 수 있어요. 다만 두 도구는 설정 파일, 에이전트 정의 방식, 병렬 작업 관리 방식에 차이가 있습니다.
개인 웹앱 개발에서 가장 효율적인 방법은 PRD, 설계 문서, 개발 규칙, 작업 절차는 공통으로 관리하고, 에이전트 실행 설정만 CLI별로 분리하는 거예요.
1. Claude Code와 Codex CLI 비교
| 구분 | Claude Code | Codex CLI |
|---|---|---|
| 프로젝트 공통 지침 | CLAUDE.md | AGENTS.md |
| 전역 설정 | ~/.claude/settings.json | ~/.codex/config.toml |
| 프로젝트 설정 | .claude/settings.json | .codex/config.toml |
| 재사용 절차 | Skills | Skills |
| 전문 에이전트 | Subagents | Multi-agent |
| 팀 협업 | Agent Teams | Multi-agent 협업 |
| 자동 검증 | Hooks | 테스트 명령, 실행 정책, 외부 자동화 |
| 실행 권한 | Permissions | Sandbox / Approval |
두 CLI 모두 개발 자동화에 활용할 수 있지만, 설정 파일을 그대로 공유할 수는 없어요.
2. Codex CLI에서 Multi-agent 활성화
Codex CLI에는 여러 에이전트에게 작업을 분담하는 Multi-agent 기능이 있어요. 우선 터미널에서 버전을 확인합니다.
codex --version그다음 설정 파일을 엽니다.
nano ~/.codex/config.tomlMulti-agent 기능이 실험적 기능으로 제공되는 버전에서는 다음 설정을 사용합니다.
[features]
multi_agent = true기존 [features] 섹션이 있다면 그 아래에 multi_agent = true만 추가하세요.
설정 후 Codex CLI를 재시작합니다. 단, Codex 버전에 따라 기능의 기본 활성화 여부와 설정 키가 달라질 수 있으므로 설치된 버전에서 다음 명령으로 확인하는 것이 좋아요.
codex features list공식 문서에서는 기본 worker, explorer 에이전트와 사용자 정의 에이전트를 지원하는 구조를 안내합니다.
3. Claude Code와 Codex CLI 공통 프로젝트 구조
두 CLI를 동일한 프로젝트에서 사용할 수 있도록 다음 구조를 추천해요.
my-webapp/
│
├── CLAUDE.md # Claude Code 지침
├── AGENTS.md # Codex 지침
│
├── .claude/
│ ├── settings.json
│ ├── agents/
│ │ ├── planner.md
│ │ ├── architect.md
│ │ ├── developer.md
│ │ └── reviewer.md
│ └── skills/
│
├── .codex/
│ ├── config.toml
│ └── agents/
│ ├── planner.toml
│ ├── architect.toml
│ ├── developer.toml
│ └── reviewer.toml
│
├── .agents/
│ └── skills/
│ ├── create-prd/
│ │ └── SKILL.md
│ ├── architecture/
│ │ └── SKILL.md
│ └── code-review/
│ └── SKILL.md
│
├── docs/
│ ├── PRD.md
│ ├── ARCHITECTURE.md
│ └── DESIGN_SYSTEM.md
│
├── harness/
│ ├── PLANS.md
│ ├── build-log.md
│ └── context/
│
├── src/
└── tests/여기서 중요한 설계 원칙은 다음과 같습니다.
docs/: 두 CLI가 공유하는 프로젝트 설계 자료.agents/skills/: 공통으로 재사용할 수 있는 Skill.claude/: Claude Code 전용 에이전트와 설정.codex/: Codex CLI 전용 에이전트와 설정harness/: 진행 상황, 작업 계획, 검증 기록
harness/와 같은 구조는 Codex 공식 개발 워크플로 예제에서도 활용하는 방식이에요. 필수 시스템 디렉터리는 아니며 프로젝트에 맞게 설계할 수 있습니다.
4. Codex 전용 에이전트 정의
Codex에서는 .codex/agents/ 아래에 TOML 파일로 전문 에이전트를 정의할 수 있어요.
① Planner 에이전트
name = "planner"
description = "PRD 작성과 요구사항 분석 전문 에이전트"
developer_instructions = """
You are a senior product manager.
Responsibilities:
- Analyze requirements
- Define MVP scope
- Write user stories
- Define acceptance criteria
- Create docs/PRD.md
Rules:
- Do not implement code.
- Ask about unclear requirements.
- Request approval before implementation.
"""② Architect 에이전트
name = "architect"
description = "시스템 구조 및 데이터 설계 전문 에이전트"
developer_instructions = """
You are a senior software architect.
Responsibilities:
- Review the approved PRD
- Design application architecture
- Design Firebase data models
- Define API boundaries
- Create docs/ARCHITECTURE.md
Rules:
- Prefer simple architectures.
- Minimize unnecessary dependencies.
- Do not implement features.
"""③ Developer 에이전트
name = "developer"
description = "승인된 설계를 기반으로 기능을 구현하는 에이전트"
developer_instructions = """
You are a senior full-stack developer.
Responsibilities:
- Implement approved features
- Follow architecture documents
- Write maintainable TypeScript
- Add relevant tests
Rules:
- Do not change requirements.
- Avoid unnecessary refactoring.
- Report implementation results.
"""④ Reviewer 에이전트
name = "reviewer"
description = "코드 품질과 보안을 검토하는 에이전트"
developer_instructions = """
You are a senior code reviewer.
Review:
- Type safety
- Security
- Error handling
- Performance
- Architecture compliance
- Test coverage
Rules:
- Do not modify source code.
- Report findings by severity.
- Provide file references.
"""이렇게 하면 Claude Code와 Codex CLI에서 동일한 4개 역할을 사용할 수 있어요.
5. Codex 공통 개발 규칙: AGENTS.md
프로젝트 루트에 다음 파일을 만듭니다.
# Project Agent Instructions
## Development Workflow
1. PRD
2. Architecture
3. UI/UX Design
4. Implementation
5. Code Review
6. Testing
## Rules
- Do not implement before PRD approval.
- Follow docs/PRD.md.
- Follow docs/ARCHITECTURE.md.
- Prefer simple and maintainable code.
- Use TypeScript strict mode.
- Ask before installing dependencies.
- Never deploy without approval.
## Agent Roles
- planner: Requirements and PRD
- architect: System design
- developer: Implementation
- reviewer: Code review
## Verification
Before completing implementation:
1. Run TypeScript checks.
2. Run ESLint.
3. Run relevant tests.
4. Report failures.
5. Update harness/build-log.md.Codex는 AGENTS.md를 프로젝트 지침으로 자동 탐색해요. 전역 규칙은 ~/.codex/AGENTS.md에 둘 수도 있습니다.
6. Codex 실행 환경 설정
~/.codex/config.toml에서 기본 권한과 샌드박스를 설정할 수 있어요.
sandbox_mode = "workspace-write"
approval_policy = "on-request"
[features]
multi_agent = true이 구성은 프로젝트 내부의 일반적인 개발 작업을 허용하면서, 샌드박스 범위를 벗어나는 작업에 대해 승인을 요청하도록 하는 방향입니다.
설정 파일이 프로젝트에 존재한다는 사실만으로 모든 설정이 적용되는 것은 아니에요. 프로젝트 설정은 신뢰 여부와 설정 우선순위의 영향을 받으므로, 초기에는 전역 설정을 사용하고 프로젝트별 규칙은 AGENTS.md에 두는 것이 간단합니다.
7. 실제 Codex CLI 사용 방법
터미널에서 프로젝트 폴더로 이동합니다.
cd my-webapp
codex그다음 아래처럼 요청합니다.
기획 단계 요청 예시
planner 에이전트를 사용해서 개인용 To-Do 웹앱의 PRD를 작성해줘. docs/PRD.md에 저장하고, 구현은 시작하지 마. 완료 후 사용자 승인을 기다려.
병렬 개발 요청 예시
Multi-agent를 활용해서 승인된 PRD와 설계를 기반으로 개발해줘. developer는 UI 구현, 별도 worker는 Firebase 연동, reviewer는 읽기 전용 코드 검토를 맡아줘. 파일 수정 충돌을 피하고, 마지막에 테스트 결과를 보고해줘.
에이전트는 작업에 맞춰 선택·생성되므로, 요청에 역할과 책임을 명확히 지정하는 것이 좋아요.
8. Codex에서 하네스를 더 발전시키는 방법
Codex의 공식 개발 워크플로 예제는 AGENTS.md 외에도 PLANS.md, 단계별 구현 문서, 실행 로그, 컨텍스트 기록을 활용해요.
특히 CLI를 종료하고 다시 실행하거나 Claude Code와 Codex를 번갈아 사용할 때 이러한 문서가 중요합니다. 예를 들어 harness/build-log.md를 다음과 같이 유지할 수 있어요.
# Build Log
## Phase 01: PRD
Status: Approved
Artifact: docs/PRD.md
## Phase 02: Architecture
Status: Approved
Artifact: docs/ARCHITECTURE.md
## Phase 03: Implementation
Status: In Progress
Completed:
- Authentication UI
Pending:
- Firebase integration
- Unit tests
Verification:
- TypeScript: Passed
- ESLint: Passed
- Tests: Not yet run이 문서는 Claude Code와 Codex가 공유할 수 있는 작업 이력이에요. 다만 상태는 실제 실행 결과를 확인한 후 기록해야 합니다.
9. 최종 추천 구성
개인 웹앱 개발용 Dual-CLI Harness
Claude Code Codex CLI
Subagents + Teams Multi-agent
\ /
공통 개발 자산
PRD · 설계 문서 · Skills · 개발 계획 · 작업 로그 · 테스트처음부터 복잡한 병렬 에이전트 환경을 구성하기보다는 4개 전문 에이전트 + 공통 Skills + 단계별 승인 + 자동 테스트를 기본으로 구축하는 것을 권장해요.
그리고 Claude Code와 Codex가 동일한 작업 파일을 동시에 수정하지 않도록 Git 브랜치나 Worktree를 분리하면 더욱 안전합니다.
공식 참고 자료: Codex 개발자 문서 · Codex Harness 개발 워크플로 예제
마무리
Subagents와 Skills는 별도 설정 없이 바로 쓸 수 있고, Agent Teams만 환경 변수로 활성화하면 돼요. 하네스는 켜는 기능이 아니라 CLAUDE.md·AGENTS.md, 전문 에이전트, Skills, Hooks, 테스트를 엮어 만드는 개발 구조입니다. 작은 구성에서 시작해 필요할 때 Agent Teams와 Multi-agent로 확장해 보세요.
