Claude Code를 단순히 "코드 짜주는 챗봇"으로만 쓰고 있다면 절반도 못 쓰고 있는 겁니다. Anthropic 내부 엔지니어, 특히 Claude Code 제품 리드인 Boris Cherny가 실제로 어떻게 일하는지를 보면 완전히 다른 활용법이 보입니다. 이 글에서는 CLAUDE.md를 헌법처럼 쓰는 법부터 Hooks로 규칙을 강제하는 법, Git Worktree로 여러 에이전트를 동시에 돌리는 법까지 정리합니다.
핵심 요약
Boris Cherny는 터미널 5개, claude.ai/code 5~10개, iPhone까지 합쳐서 10~15개의 병렬 세션을 동시에 운영합니다. 핵심 원칙은 CLAUDE.md를 헌법처럼 쓰고, Hooks로 결정론적 자동화를 적용하고, Skills로 워크플로우를 재사용하고, Subagents로 컨텍스트를 격리하는 네 가지입니다. Git Worktree는 2026년 2월 20일 CLI 지원이 추가되면서 병렬 에이전트 운영의 인프라 기반이 됐습니다. 컨텍스트 관리는 50% 지점에서 /compact를 쓰고, 태스크를 전환할 때는 /clear를 쓰며, 모든 작업에 Plan→Execute→Verify 사이클을 적용하는 방식입니다. v2.1.101(2026년 4월 11일)에서는 커스텀 슬래시 명령이 Skills로 통합됐고, v2.1.142(2026년 5월 15일)가 현재 최신 버전으로 Agent View와 /goal 기능이 추가됐습니다. 설치는 네이티브 바이너리가 권장되며 NPM 방식은 deprecated 상태입니다. 2026년 4월 24일에는 서브에이전트와 MCP의 병렬 초기화가 추가되어 멀티 에이전트 환경의 시작 시간이 대폭 줄었습니다.
실전 1 — CLAUDE.md: 에이전트 헌법
CLAUDE.md는 README가 아닙니다. 인간이 읽는 문서가 아니라 에이전트가 매 세션 시작마다 읽는 행동 헌법입니다. 이 차이를 이해하지 못하면 CLAUDE.md를 프로젝트 소개글처럼 써버리게 되는데, 그러면 에이전트 행동에 거의 영향을 주지 못합니다.
아래는 README처럼 잘못 쓴 예시입니다. 프로젝트 개요와 기술 스택, 팀원 정보만 나열되어 있어서 에이전트가 실제로 어떻게 행동해야 하는지에 대한 정보가 거의 없습니다.
# CLAUDE.md — 잘못된 예시 (README처럼 쓴 것)
## 프로젝트 개요
이 프로젝트는 FastAPI 기반 REST API 서버입니다.
사용자 인증과 결제를 처리합니다.
팀원: Alice, Bob, Carol
## 기술 스택
- Python 3.12
- FastAPI
- PostgreSQL
반대로 올바르게 쓴 예시는 빌드·테스트 명령어, 반드시 따라야 할 규칙, 건드리면 안 되는 파일, 자동 실행 허용·금지 목록까지 구체적으로 명시합니다.
# CLAUDE.md — 올바른 예시 (에이전트 행동 제어)
## 빌드 및 테스트 명령어
\`\`\`bash
# 개발 서버
uv run uvicorn app.main:app --reload
# 테스트 실행 (항상 이 명령어)
uv run pytest tests/ -x -v
# 타입 체크
uv run mypy app/
# 린팅
uv run ruff check app/ --fix
\`\`\`
## 핵심 규칙 — 반드시 따를 것
1. 타입 힌트 필수: 모든 함수에 파라미터·반환 타입 명시
2. 테스트 먼저: 새 기능 구현 전 테스트 작성
3. 절대 건드리지 말 것: app/core/security.py — Carol 소유, PR 필요
4. 마이그레이션 자동 실행 금지: alembic upgrade head 절대 자동 실행 않음
5. 환경변수 하드코딩 금지: .env.example 참조
6. 커밋 메시지 형식: feat(module): description / fix(module): description
## 아키텍처 결정 기록
- ORM: SQLAlchemy 2.0 async (Tortoise 아님 — 2025년 마이그레이션 완료)
- 인증: JWT + refresh token (세션 기반 아님)
- 결제: Stripe v7 (Toss 아님 — 2026년 Q1 결정)
- 캐싱: Redis (Memcached 아님)
## 에러 처리 패턴
모든 API 에러는 다음 형식:
{"error": {"code": "ERROR_CODE", "message": "한국어 메시지"}}
## 파일 소유권
| 파일/디렉토리 | 소유자 | 변경 시 |
|---|---|---|
| app/core/security.py | Carol | PR + 리뷰 필수 |
| app/payments/ | Bob | Slack 알림 필수 |
| alembic/ | Alice | 직접 수정 금지 |
## 자동 실행 허용 목록
pytest, mypy, ruff (항상 허용), git add, git commit (허용), docker-compose up (허용)
## 자동 실행 금지 목록
alembic upgrade (금지 — 항상 확인 요청), git push --force (금지), DROP TABLE (금지), rm -rf (금지)
핵심은 WHAT/WHY/HOW 프레임워크로 적는 것입니다. WHAT은 무엇을 해야 하는지에 대한 규칙과 명령어, WHY는 왜 그렇게 해야 하는지에 대한 맥락과 히스토리, HOW는 어떻게 하는지에 대한 구체적 패턴과 예시입니다. 예를 들어 "Stripe v7 사용"이라는 WHAT만 적으면, Claude가 더 좋아 보이는 다른 결제 라이브러리로 바꿔버릴 수 있습니다. 하지만 "2026년 Q1에 Toss에서 마이그레이션 완료, 레거시 코드가 남아있을 수 있음"이라는 WHY를 함께 적으면 Claude가 맥락을 이해하고 그 결정을 지킵니다.
실전 2 — Hooks: 결정론적 자동화
Hooks는 Claude의 해석에 의존하지 않고 특정 이벤트가 발생하면 결정론적으로 실행됩니다. 프롬프트로 "이건 하지 마세요"라고 적어두는 방식과는 다르게, 할루시네이션으로 우회될 여지가 없다는 게 핵심 차이입니다. 설정은 프로젝트 전용이면 .claude/hooks.yaml에, 모든 프로젝트에 적용하고 싶으면 ~/.claude/hooks.yaml에 작성하고, 현재 등록된 Hooks는 /hooks 명령으로 확인할 수 있습니다.
아래는 프로젝트 단위 Hooks 설정 예시입니다. 위험한 명령어를 사전에 차단하고, 결제 모듈을 변경할 때는 확인을 받고, Python 파일을 저장하면 자동으로 린팅하고, 테스트 파일을 수정하면 자동으로 테스트를 실행하고, 태스크가 끝나면 알림을 보내고, 워크트리를 생성하면 환경을 자동으로 초기화하는 구성입니다.
# .claude/hooks.yaml
hooks:
# 위험 명령어 사전 차단
PreToolUse:
- name: "위험 명령어 차단"
match:
tool: Bash
command_pattern: "(rm -rf|DROP TABLE|git push --force|alembic upgrade)"
action:
type: block
message: "⛔ 위험한 명령어입니다. 수동으로 실행하세요."
- name: "결제 모듈 보호"
match:
tool: Write
path_pattern: "app/payments/.*"
action:
type: confirm
message: "💳 결제 모듈을 변경합니다. Bob에게 Slack 알림을 보내셨나요?"
# 파일 저장 후 자동 처리
PostToolUse:
- name: "Python 자동 린팅"
match:
tool: Write
path_pattern: ".*\\.py$"
action:
type: run
command: |
uv run ruff check "$CLAUDE_TOOL_PATH" --fix --quiet
uv run ruff format "$CLAUDE_TOOL_PATH" --quiet
- name: "테스트 자동 실행"
match:
tool: Write
path_pattern: "tests/.*\\.py$"
action:
type: run
command: uv run pytest "$CLAUDE_TOOL_PATH" -x -q --tb=short
# 태스크 완료 시 알림
Stop:
- name: "태스크 완료 알림"
action:
type: run
command: |
osascript -e 'display notification "Claude Code 태스크 완료" with title "Claude Code"'
echo -e '\a'
# 워크트리 생성 시 환경 자동 세팅
WorktreeCreate:
- name: "워크트리 환경 초기화"
action:
type: run
command: |
cd "$CLAUDE_WORKTREE_PATH"
uv sync
cp ../.env .env
echo "✅ 워크트리 환경 초기화 완료: $CLAUDE_WORKTREE_PATH"
전역 Hooks에는 모든 프로젝트에 공통으로 적용할 보안 규칙을 두는 게 효과적입니다. 아래는 API 키 하드코딩을 감지해서 차단하고, 모든 툴 호출을 감사 로그로 남기는 설정입니다.
# 전역 Hooks (~/.claude/hooks.yaml) — 모든 프로젝트 공통
hooks:
PreToolUse:
- name: "시크릿 감지"
match:
tool: Write
content_pattern: "(sk-ant-|sk-or-|AIzaSy|ghp_)[a-zA-Z0-9]+"
action:
type: block
message: "🔑 API 키가 코드에 포함됐습니다. .env 파일을 사용하세요."
- name: "감사 로그"
action:
type: run
command: |
echo "$(date -Iseconds) | $CLAUDE_TOOL_NAME | $CLAUDE_SESSION_ID" \
>> ~/.claude/audit.log
Hook 이벤트는 다섯 종류가 있습니다. PreToolUse는 툴 실행 전에 작동해서 차단이 가능하고, PostToolUse는 툴 실행 후 린팅이나 테스트 같은 후처리를 담당합니다. Stop은 세션 종료 시 알림이나 정리 작업에 쓰이고, WorktreeCreate는 워크트리가 생성될 때 환경을 초기화하며, Notification은 Claude가 입력을 기다릴 때 트리거됩니다. Hook 안에서는 $CLAUDE_TOOL_NAME, $CLAUDE_TOOL_PATH, $CLAUDE_SESSION_ID, $CLAUDE_WORKTREE_PATH 같은 환경변수를 참조할 수 있습니다.
실전 3 — Git Worktree로 병렬 에이전트
Boris Cherny가 10~15개의 병렬 세션을 운영할 수 있는 것은 Git Worktree 덕분입니다. 각 에이전트가 독립된 브랜치에서 작업하기 때문에 같은 레포지토리 안에서도 충돌 없이 동시에 작업할 수 있습니다.
설치와 기본 사용법은 아래와 같습니다.
# 기본 설치 및 설정
curl -fsSL https://claude.ai/install.sh | bash
claude auth login
# Worktree 기반 병렬 작업
claude --worktree feat-login # 터미널 1: 로그인 기능 개발
claude --worktree fix-search-bug # 터미널 2: 검색 버그 수정 (동시에)
claude --worktree refactor-payments # 터미널 3: 리팩토링 (동시에)
각 워크트리는 .claude/worktrees/feat-login/ 같은 경로에 자동 생성되고 해당 브랜치를 체크아웃하며 Hook으로 환경이 자동 초기화됩니다. 세 에이전트가 동시에 작업해도 독립된 브랜치이기 때문에 git 충돌이 발생하지 않고, 작업이 끝나면 각자 PR을 생성해서 코드 리뷰를 받는 흐름입니다.
Boris Cherny의 실제 워크플로우를 보면 아침에 iPhone에서 Claude Code 앱으로 "user-auth 모듈의 JWT 만료 처리 개선해줘" 같은 태스크를 시작해두고 백그라운드에서 진행시킵니다. 사무실에 도착하면 터미널 탭을 5개 열어서 각 탭마다 다른 워크트리로 Claude Code를 실행합니다.
# Tab 1
claude --worktree feat-login
# Tab 2
claude --worktree fix-perf
# Tab 3
claude --worktree docs-update
각 탭에서는 Plan → Execute → Verify 사이클을 따릅니다. Plan 단계에서 "이 태스크를 어떻게 접근할지 계획 세워줘"라고 요청하고, Execute 단계에서 "계획대로 구현해줘"라고 요청하면, Verify 단계는 자동으로 pytest && mypy && ruff가 실행되는 식입니다. 컨텍스트가 50%에 도달하면 /compact로 압축해서 중요 컨텍스트를 유지하고, 태스크를 전환할 때는 /clear로 완전히 초기화해서 이전 컨텍스트가 오염되지 않도록 합니다.
워크트리 관리를 더 편하게 해주는 별도 유틸리티인 wt도 있습니다. wt switch -x claude -c feat-login -- 'login with email/password 구현'처럼 워크트리 생성과 Claude 실행을 한 번에 처리할 수 있고, wt list로 현재 워크트리 목록과 상태를 확인하고, wt merge feat-login --cleanup으로 완료된 워크트리를 정리할 수 있습니다.
실전 4 — Skills: 팀 공용 재사용 워크플로우
Skills는 프로젝트 전체에 적용하려면 .claude/skills/SKILL.md에, 특정 태스크용이면 .claude/skills/deploy/SKILL.md처럼 하위 폴더에, 개인 전역으로 쓰려면 ~/.claude/skills/에 저장합니다.
코드 리뷰를 자동화하는 Skill은 보안, 성능, 테스트 커버리지를 순서대로 체크하고 정해진 형식으로 결과를 출력하도록 구성할 수 있습니다.
<!-- .claude/skills/code-review/SKILL.md -->
---
name: code-review
description: PR 코드 리뷰 실행 — 보안·성능·테스트 커버리지 체크
---
# 코드 리뷰 가이드라인
다음 순서로 코드를 리뷰합니다:
## 1. 보안 체크
- SQL 인젝션 가능성
- 하드코딩된 시크릿
- 입력 검증 누락
- 인증/인가 우회 가능성
## 2. 성능 체크
- N+1 쿼리 패턴
- 불필요한 DB 조회
- 메모리 누수 가능성
- 동기 코드의 비동기 대체 가능성
## 3. 테스트 커버리지
- 새로운 코드에 테스트 있는지
- 엣지 케이스 처리 여부
- 에러 케이스 테스트 여부
## 4. 출력 형식
\`\`\`markdown
## 코드 리뷰 결과
### 🔴 Critical (즉시 수정 필요)
### 🟡 Warning (권장 수정)
### 🟢 Good (잘 된 점)
### 📊 요약
- 전체 품질: X/10
- 배포 권장: Yes/No
\`\`\`
배포처럼 위험도가 높은 작업은 disable-model-invocation: true를 설정해서 Claude가 실수로 자동 호출하지 못하게 막아둘 수 있습니다.
<!-- .claude/skills/deploy/SKILL.md -->
---
name: deploy
description: 스테이징 또는 프로덕션 배포
disable-model-invocation: true
allowed-tools:
- Bash(gh *)
- Bash(git *)
---
# 배포 가이드
$ARGUMENTS를 배포합니다 (staging | production).
## 사전 체크리스트
1. 테스트 전체 통과 확인: uv run pytest tests/ -x
2. 타입 체크: uv run mypy app/
3. 린팅: uv run ruff check app/
4. 변경사항 요약 작성
## 스테이징 배포
gh workflow run deploy.yml -f environment=staging
## 프로덕션 배포
gh workflow run deploy.yml -f environment=production
(반드시 수동 확인 후 실행, Slack #deployments 공지 필수)
이렇게 만든 Skills는 /code-review, /deploy staging, /deploy production처럼 슬래시 명령으로 호출합니다. 2026년 기준 내장 Skills로는 대규모 병렬 변경을 오케스트레이션하는 /batch, 언어별 API 레퍼런스를 로드하는 /claude-api, 디버그 로깅을 켜는 /debug, 반복 간격으로 프롬프트를 실행하는 /loop, 3개 병렬 리뷰 에이전트로 코드 품질을 체크하는 /simplify, 신규 팀원 온보딩 문서를 자동 생성하는 /team-onboarding이 제공됩니다.
실전 5 — Subagents로 컨텍스트 격리
Subagent는 프로젝트 전용이면 .claude/agents/에, 전역이면 ~/.claude/agents/에 저장합니다. 내장 타입으로는 읽기 전용 코드베이스 탐색을 담당하는 Explore, 실행 없이 계획만 세우는 Plan, 실행까지 포함하는 범용 타입이 있습니다.
보안 분석처럼 신중함이 필요한 작업은 쓰기 권한 없이 읽기 전용으로 구성하고, 가장 성능이 좋은 모델을 배정하는 게 안전합니다.
<!-- .claude/agents/security-reviewer.md -->
---
name: security-reviewer
description: 보안 취약점 전문 분석 에이전트
model: claude-opus-4-7
tools:
- Read
- Bash(grep *)
- Bash(find *)
---
당신은 보안 전문가입니다. 다음 관점에서만 코드를 분석합니다:
1. OWASP Top 10 취약점
2. 한국 KISA 보안 가이드라인
3. Stripe PCI DSS 요구사항
분석 후 심각도(Critical/High/Medium/Low)로 분류하고
구체적인 수정 방법을 제시합니다.
절대 코드를 수정하지 않습니다. 분석과 권고만 합니다.
테스트 작성처럼 비교적 단순한 작업은 더 가벼운 모델로도 충분합니다.
<!-- .claude/agents/test-writer.md -->
---
name: test-writer
description: pytest 단위 테스트 자동 작성
model: claude-sonnet-4-6
tools:
- Read
- Write
- Bash(uv run pytest *)
---
당신은 pytest 전문가입니다.
테스트 작성 규칙:
1. 모든 엣지 케이스 포함 (빈 입력, None, 최대값)
2. Given/When/Then 패턴
3. 픽스처는 conftest.py에
4. 모킹은 unittest.mock 사용
5. 테스트 실행 후 결과 보고
작성 후 반드시 실행해서 통과 확인합니다.
서브에이전트의 가장 큰 장점은 메인 컨텍스트를 오염시키지 않는다는 점입니다. 하나의 메시지로 여러 서브에이전트를 동시에 호출할 수 있는데, 예를 들어 "security-reviewer로 app/payments/ 보안 분석하고, test-writer로 app/users/auth.py 테스트 작성하고, Explore 에이전트로 현재 API 문서 현황 파악해줘"라고 요청하면 세 개의 서브에이전트가 각자 독립된 컨텍스트 윈도우에서 동시에 작업하고, 완료된 결과만 메인 세션으로 반환됩니다. Ctrl+B로 서브에이전트를 백그라운드로 전환하면 메인 세션을 계속 쓰면서 백그라운드 작업이 끝나면 알림을 받을 수도 있습니다.
서브에이전트를 쓸지 메인 에이전트가 직접 처리할지는 작업 성격에 따라 판단해야 합니다. 단순하고 빠른 작업, 메인 컨텍스트와 밀접하게 연관된 작업, 10단계 이하의 작업이라면 메인 에이전트가 직접 처리하는 게 낫습니다. 반면 코드베이스 전체를 읽어야 하는 탐색, 컨텍스트를 오염시킬 수 있는 대규모 검색, 병렬로 독립 실행 가능한 작업, 보안이나 테스트처럼 특정 전문 역할이 필요한 작업은 서브에이전트로 분리하는 게 효율적입니다. 모델 라우팅 측면에서는 보안 분석이나 아키텍처 결정처럼 중요한 판단에는 Opus를, 코드 생성이나 리팩토링, 테스트 작성에는 Sonnet을, 분류나 요약, 단순 검색에는 Haiku를 배정해서 비용을 최적화하는 방식이 일반적입니다.
실전 6 — 컨텍스트 관리 마스터하기
세션 중에는 하단 상태바에서 컨텍스트 사용량을 실시간으로 확인할 수 있습니다. 65% 정도면 아직 여유가 있는 상태고, 85%에 가까워지면 /compact를 써야 할 시점이며, 100%에 도달하면 강제 압축이나 에러가 발생합니다.
/compact는 같은 태스크를 계속 진행하면서 이전 맥락이 필요할 때, 50~80% 구간에서 사용하는 게 적절합니다. /clear는 완전히 다른 태스크로 전환할 때, 이전 맥락이 새 태스크를 오염시킬 우려가 있을 때 씁니다. 예를 들어 버그 디버깅을 마치고 새 기능 개발을 시작하는 시점이 대표적인 /clear 사용 타이밍입니다. v2.1.142에서 추가된 /goal은 현재 목표를 명시적으로 설정하는 기능입니다.
모든 태스크에는 Plan → Execute → Verify 사이클을 강제하는 게 권장됩니다. Plan 단계에서는 "이 기능을 어떻게 구현할지 계획만 세워줘. 코드는 아직 작성하지 마"라고 요청해서 Claude가 접근법을 설명하면 이를 검토하고 승인합니다. Execute 단계에서는 "계획대로 구현해줘"라고 요청해서 실제 코드를 작성하게 합니다. Verify 단계는 Hook이 자동으로 처리하도록 구성해두면 "테스트 실행하고 타입 체크해줘"라고 매번 말할 필요 없이 uv run pytest && uv run mypy app/ && uv run ruff check app/가 자동으로 실행됩니다.
Claude Code는 세션 간 학습도 자동으로 축적합니다. 어떤 빌드 명령이 작동하는지, 디버깅에서 어떤 접근이 성공했는지, 암묵적인 코딩 선호도 같은 정보가 쌓이는데, /memory 명령으로 현재 축적된 내용을 확인할 수 있습니다. 특정 패턴을 명시적으로 기억시키고 싶다면 "이 패턴을 기억해줘: FastAPI 엔드포인트는 항상 async def로 작성하고 Depends()로 의존성 주입"처럼 직접 요청하면 됩니다.
실전 7 — MCP 연동으로 외부 도구 통합
MCP 서버는 명령줄에서 바로 추가할 수 있습니다.
claude mcp add github -- gh api
claude mcp add postgres -- psql "$DATABASE_URL"
프로젝트별로 세밀하게 설정하려면 .claude/config.json에 아래처럼 작성합니다.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
},
"postgres": {
"command": "npx",
"args": ["@modelcontextprotocol/server-postgres", "${DATABASE_URL}"]
},
"slack": {
"command": "npx",
"args": ["@modelcontextprotocol/server-slack"],
"env": { "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}" }
}
}
}
MCP를 연동하면 "GitHub에서 오픈 PR 목록 가져와서 리뷰 우선순위 정해줘", "DB에서 슬로우 쿼리 찾아서 최적화해줘", "Slack #backend 채널 오늘 메시지에서 버그 리포트 찾아줘"처럼 외부 서비스와 직접 연동된 작업을 자연어로 요청할 수 있습니다. 2026년 4월 24일에 추가된 서브에이전트와 MCP의 병렬 초기화 기능 덕분에 멀티 에이전트와 멀티 MCP를 함께 쓰는 환경에서도 시작 시간이 대폭 줄었습니다.
팀 도입 체크리스트
도입 첫날에는 claude auth login으로 로그인하고, WHAT/WHY/HOW 프레임워크로 CLAUDE.md를 프로젝트 루트에 작성하면서 핵심 규칙 5~7개와 절대 건드리면 안 되는 파일·디렉토리, 자동 실행 허용·금지 목록을 명시합니다.
첫 주에는 .claude/hooks.yaml을 만들어서 위험 명령어 차단, Python 파일 저장 시 자동 린팅, 태스크 완료 알림 같은 Hook을 설정하고, /compact를 50~80% 구간에서 쓰는 습관을 들이며 Plan → Execute → Verify 사이클을 적용합니다.
첫 달에는 팀 공용 Skills를 /code-review, /pr-summary 같은 형태로 2~3개 작성하고, Git Worktree 병렬 작업 환경을 세팅하고, security-reviewer나 test-writer 같은 서브에이전트를 1~2개 정의하고, GitHub과 DB에 MCP 서버를 연결하고, /batch로 대규모 리팩토링을 실험해봅니다.
비용 최적화 측면에서는 서브에이전트 모델 라우팅을 설정해서 복잡한 태스크에는 claude-opus-4-7, 일반 태스크에는 claude-sonnet-4-6, 분류와 요약에는 claude-haiku-4-5를 배정하는 게 권장됩니다. CLAUDE.md는 항상 로드되어 컨텍스트를 차지하기 때문에 거기에는 핵심만 담고, 필요할 때만 로드되는 Skills로 나머지를 분리하는 것도 비용 절감에 도움이 됩니다. 컨텍스트가 50%를 넘기기 전에 /compact하는 습관도 함께 들이는 게 좋습니다.
마무리
핵심 원칙은 세 가지로 정리됩니다. CLAUDE.md는 AI 팀원을 위한 헌법이지 README가 아니라는 점, 중요한 규칙은 프롬프트가 아니라 Hooks 같은 코드로 강제해야 한다는 점, 그리고 한 에이전트가 작업하는 동안 다른 작업을 검토하면서 기다리는 시간 없이 병렬로 일하는 게 핵심이라는 점입니다. Boris Cherny의 워크플로우를 요약하면 각자 독립된 Git Worktree에서 10~15개의 병렬 세션을 운영하고, 컨텍스트가 50%에 도달하면 /compact, 태스크를 전환하면 /clear를 쓰고, 항상 Plan → Execute → Verify 순서를 지키며, 서브에이전트로 컨텍스트를 격리하는 방식입니다.
흔히 저지르는 실수도 정리해두면, CLAUDE.md를 README처럼 WHY 없이 WHAT만 적어버리는 것, 모든 작업을 메인 에이전트 하나로 처리해서 컨텍스트를 오염시키는 것, /compact 없이 컨텍스트 100%까지 끌고 가서 성능이 급락하는 것, Hooks 없이 프롬프트로만 규칙을 강제해서 할루시네이션으로 우회당하는 것, 그리고 병렬로 처리할 수 있는 작업을 직렬로 처리하면서 에이전트가 일하는 동안 그냥 기다리는 것입니다.
관련 글
'AI 개발' 카테고리의 다른 글
| OpenAI, 사상 최대 IPO를 향해 달린다 — S-1 비밀 제출, 지금 개발자가 알아야 할 것 (0) | 2026.05.22 |
|---|---|
| Policy-as-Code 실전 — AI가 짠 코드도 에이전트 행동도 자동으로 검사하는 법 (0) | 2026.05.21 |
| Wan2.2-T2V-A14B 완전 가이드 — 오픈소스 영상 생성 모델 로컬 서빙과 실전 영상 만들기 (0) | 2026.05.20 |
| LiteLLM 완전 가이드 4편 — LangChain·LangGraph 통합, 가드레일, Prometheus 모니터링, 프로덕션 운영 (0) | 2026.05.19 |
| LiteLLM 완전 가이드 3편 — Proxy 서버 모드: 팀 공용 LLM 게이트웨이 구축 실전 (0) | 2026.05.19 |