Claude Code 개발자 Boris Cherny의 실전 가이드

X의 Boris Cherny님(@bcherny)

X의 Boris Cherny님(@bcherny)

 

Boris Cherny는 2026년 1월과 2월, 두 차례에 걸쳐 자신의 Claude Code 워크플로우를 공개했다.

1월 글(13단계)은 개인 셋업을, 2월 글(10가지 팁)은 Claude Code 팀 전체에서 수집한 실전 노하우를 담았다.

두 글을 합치면 내용이 겹치는 부분도 있고, 2월 글에서 새롭게 추가된 것도 있다.

 

중복을 제거하고 하나의 체계로 종합했다.

---

전체 구조: 다섯 개의 층위

Boris의 모든 팁은 다섯 가지 층위로 분류할 수 있다.

01. 환경 구성 — 어떻게 돌릴 것인가
02. 계획 수립 — 무엇을 시킬 것인가
03. 실행과 자동화 — 어떻게 반복을 줄일 것인가
04. 품질 보장 — 어떻게 검증할 것인가
05. 확장 활용 — 코딩 이외에 무엇에 쓸 것인가

---

1. 환경 구성

병렬 실행이 최고의 생산성 팁이다

핵심은 git worktree다.

3~5개의 worktree를 동시에 만들고 각각에 별도의 Claude 세션을 붙인다.

하나의 Claude에게 큰 작업을 맡기는 것이 아니라, 여러 Claude에게 독립된 작업을 병렬로 맡기는 것이다.

 

이 패턴이 워낙 보편화되어 Claude Desktop 앱에 네이티브 worktree 지원이 추가되었다.

실전 팁으로는 worktree마다 이름을 붙이고 shell alias(za, zb, zc 등)를 설정해서 한 번의 키 입력으로 전환하는 방식이 있다. 한 팀원은 로그 확인과 BigQuery 실행 전용 “analysis” worktree를 별도로 운영한다.

 

웹(claude.ai/code)에서도 5~10개의 세션을 추가로 병렬 실행한다.

로컬 세션을 웹으로 넘기려면 &를, 웹에서 로컬로 가져오려면 --teleport를 쓴다.

iOS 앱에서 아침에 세션을 시작해두고 나중에 확인하는 방식도 활용한다.

---

터미널 셋업

Claude Code 팀은 Ghostty 터미널을 선호한다.

Ghostty – 터미널 에뮬레이터 | GeekNews

• 동기화 렌더링, 24비트 컬러, 유니코드 지원이 장점이다.
• /statusline으로 상태바를 커스터마이징해서 컨텍스트 사용량과 현재 git 브랜치를 항상 표시한다.
• 터미널 탭에 색상 코드와 이름을 붙이고 tmux를 사용하는데, 작업/worktree 당 하나의 탭을 배정한다.

현 시점에서 Windows 사용자가 Ghostty를 굳이 세팅할 필요는 거의 없다.
Windows에서 Ghostty를 쓰려면...
- WSL2를 설치하고,
- Ubuntu를 올리고,
- Zig 컴파일러를 깔고,
- 소스를 빌드하고,
- 테마 URL이 깨진 것까지 수동으로 패치해야 한다.

과정을 거쳐서 얻는 결과물은 WSLg 위에서 돌아가는 "Linux용 Ghostty"이다.
네이티브 Windows 앱이 아니다.
Windows의 클립보드 통합, 알림, 파일 탐색기 연동 같은 OS 수준의 기능이 매끄럽지 않다는 뜻이고,
Ghostty가 자랑하는 "네이티브 UI"라는 핵심 강점이 WSL 레이어 위에서는 사실상 무의미해진다.

Claude Code 팀이 Ghostty를 선택한 이유를 다시 돌아보면,
동기식 렌더링, 24비트 컬러, 유니코드 지원, 네이티브 분할 패널이었다.
그런데 Windows Terminal은 이 중 상당 부분을 이미 지원한다.
macOS나 Linux를 메인으로 쓰는 개발자에게 Ghostty는 확실히 추천할 만하다고 하다.

음성 받아쓰기도 적극 권장한다.

macOS에서 fn 키 두 번으로 활성화할 수 있으며, 타이핑보다 약 3배 빠르게 말할 수 있어 프롬프트가 훨씬 상세해진다.

 

추가 팁 : https://code.claude.com/docs/en/terminal-config

Optimize your terminal setup - Claude Code Docs

모델 선택

모든 작업에 Opus 4.5 with thinking을 사용한다. Sonnet보다 느리고 비싸지만, 조정(steering)이 적게 필요하고 도구 활용 능력이 뛰어나 최종 결과 도출까지의 총 시간은 오히려 짧다.

---

2. 계획 수립

Plan 모드가 모든 것의 시작이다

1월 글에서도 핵심이었고, 2월 글에서도 반복 강조되었다.

복잡한 작업은 반드시 Plan 모드(Shift+Tab 두 번)로 시작하고,

계획 수립에 에너지를 쏟아 Claude가 한 번에 구현을 완료하도록 유도한다.

 

2월 글에서 새롭게 추가된 팁이 두 가지 있다.

• 첫째, 두 번째 Claude를 “스태프 엔지니어” 역할로 띄워 첫 번째 Claude의 계획을 검토시키는 패턴이다.
• 둘째, 작업이 잘못되는 순간 즉시 Plan 모드로 돌아가 재계획하라는 것이다. 무리하게 밀어붙이면 품질이 급격히 무너진다. 검증 단계에서도 명시적으로 Plan 모드 진입을 지시하는 것이 효과적이다.

계획이 확정되면 auto-accept 모드로 전환한다. 이 시점부터 Claude는 사람의 개입 없이 한 번에(1-shot) 작업을 완성한다.

---

구체적인 적용 방법은:

방법 1) 터미널 탭 두 개로 수동 운용 (가장 간단)

터미널 탭 1 (Planner) — Plan 모드로 계획을 세운다.

# 터미널 탭 1에서 Claude Code 실행
claude

# Shift+Tab 두 번 → Plan 모드 진입 후 프롬프트 입력
"사용자 인증 시스템을 JWT 기반으로 리팩터링하려고 해.
현재 코드 구조를 분석하고 구현 계획을 세워줘."

Claude가 계획을 만들면 그 계획을 파일로 저장한다.

"이 계획을 docs/auth-refactor-plan.md에 저장해줘."

---

터미널 탭 2 (Reviewer) — 새 Claude 세션을 열어 계획을 검토한다.

# 터미널 탭 2에서 별도의 Claude Code 세션 실행
claude

# 프롬프트 입력
"docs/auth-refactor-plan.md를 읽고 스태프 엔지니어 관점에서 검토해줘.
다음 기준으로 평가해:
- 빠뜨린 엣지 케이스가 있는가
- 기존 기능에 영향을 주는 breaking change가 있는가
- 보안 취약점이 생길 가능성이 있는가
- 단계 분할이 적절한가 (각 단계가 독립적으로 검증 가능한가)
문제가 있으면 구체적으로 지적하고 대안을 제시해."

• Reviewer Claude가 지적한 사항을 반영해서 탭 1로 돌아가 계획을 수정한다.
• Reviewer의 피드백도 마찬가지로 docs/plan-review.md 같은 파일로 저장하게 한 뒤, 터미널 1에서 "리뷰 피드백을 반영해서 계획을 수정해줘"라고 지시하면 된다. 모든 소통이 사람이 중간에서 파일을 매개로 넘겨주는 구조!
• 계획이 양쪽 모두에게 만족스러우면 그때 auto-accept로 전환해서 실행한다.

핵심은 계획을 세우는 Claude와 검토하는 Claude의 컨텍스트가 완전히 분리된다는 것이다.

같은 세션에서 "이 계획 괜찮아?"라고 물으면 자기가 만든 것이라 비판적으로 보지 못한다고 한다.

별도 세션의 Claude는 계획서만 보기 때문에 훨씬 객관적인 검토가 가능하다...!

---

방법 2: git worktree + 역할 분리 (Boris 팀 패턴)

Boris 팀이 실제로 쓰는 방식에 더 가까운 방법

# 메인 작업용 worktree
git worktree add ../auth-refactor feature/auth-refactor

# 리뷰 전용 worktree (같은 브랜치를 읽기 전용으로)
git worktree add ../auth-review feature/auth-refactor

# 터미널 탭 A: Planner (auth-refactor 디렉터리)
cd ../auth-refactor
claude
# Plan 모드로 진입 → 계획 수립 → docs/plan.md 저장

# 터미널 탭 B: Reviewer (auth-review 디렉터리)
cd ../auth-review
claude
# "docs/plan.md를 스태프 엔지니어로서 검토해줘"

worktree를 쓰면 두 Claude가 같은 코드를 보면서도 서로의 세션에 영향을 주지 않는다.

Reviewer가 코드 구조를 직접 탐색하면서 계획의 현실성을 더 정확하게 평가할 수 있다는 점이 방법 1보다 낫다.

---

방법 3: Agent Teams 활용 (최신 기능)

2026년 2월에 추가된 Claude Code의 Agent Teams 기능을 쓰면 이 패턴을 더 체계적으로 구성할 수 있다.

# Claude Code 세션에서 직접 지시
"이 작업을 agent team으로 진행해줘.
 - Agent 1 (Planner): Plan 모드에서 구현 계획을 작성
 - Agent 2 (Reviewer): Planner의 계획을 스태프 엔지니어 관점에서 검토
 Reviewer의 승인이 나올 때까지 계획을 반복 수정하고,
 최종 승인 후에만 실행에 들어가."

Agent Teams는 메인 에이전트가 “테크 리드” 역할을 하며 팀원 에이전트에게 작업을 위임하고 결과를 통합하는 구조!

다만 이 기능은 아직 비교적 새로워서, 수동으로 쓰는 방법이 현재로서는 가장 안정적이다. (그리고 토큰 많이 든다... )

---

실전에서의 팁

Reviewer에게 구체적인 검토 기준을 주세요.

"검토해줘"라고만 하면 "좋은 계획입니다"라는 답이 돌아온다.

“빠뜨린 엣지 케이스”, “breaking change 가능성”, “각 단계의 독립 검증 가능성” 같은 체크리스트를 명시해야 실질적인 피드백이 나온다.

 

CLAUDE.md에 리뷰 기준을 넣어두면 매번 반복하지 않아도 됩니다.

예를 들어:

## Plan Review Checklist
- 각 단계는 독립적으로 검증 가능해야 함
- 기존 테스트가 깨지는 변경은 반드시 명시
- 보안 관련 변경은 별도 단계로 분리

 

계획이 2회 이상 수정되면 그때가 적정 수준입니다.

Boris 팀의 경험상, 검토 없이 바로 실행하면 중간에 방향을 틀어야 할 확률이 높고,

4회 이상 검토를 반복하면 오히려 과잉 설계에 빠진다. 1~2회 수정 후 실행하는 것이 실전적인 균형점이다.

---

3. 실행과 자동화

CLAUDE.md는 복리로 축적되는 팀 자산이다

1월 글에서 "팀 전체가 공유하는 단일 파일, 주 단위로 여러 번 업데이트"라고 설명했고,

2월 글에서는 구체적인 운용법이 추가되었다.

 

매번 Claude의 실수를 수정할 때마다 “CLAUDE.md를 업데이트해서 같은 실수를 반복하지 않도록 해라”라고 지시한다. Claude는 스스로 지켜야 할 규칙을 잘 문서화하는 특성이 있어, 이 과정이 자연스럽게 작동한다.

시간이 지나면 실수율이 측정 가능하게 줄어든다.

 

한 엔지니어는 모든 작업/프로젝트에 대해 notes 디렉터리를 유지하고, PR마다 업데이트하도록 Claude에 지시한다. CLAUDE.md가 이 notes를 참조하도록 설정해서, 프로젝트별 맥락이 자연스럽게 축적된다.

코드 리뷰 시 동료 PR에 @.claude를 태그하면 Claude Code GitHub Action이 CLAUDE.md를 업데이트한다.
Dan Shipper의 “Compounding Engineering” 개념과 같은 맥락이다.
다만 크기는 1,000토큰 이하를 유지해야 한다. 커지면 slash command나 skills로 분리한다.

---

Skill과 Slash Command로 반복을 제거한다

1월 글에서 /commit-push-pr 커맨드를 소개했고, 2월 글에서는 팀 전체의 활용 사례가 추가되었다.

Boris가 제시한 원칙은 명확하다: 하루에 한 번 이상 반복하는 작업은 Skill 또는 Slash Command로 만들어라.

팀 내 실제 사례들은 다음과 같다. /techdebt 커맨드로 세션 종료 시 중복 코드를 찾아 제거한다.

 

7일치 Slack, GDrive, Asana, GitHub를 하나의 컨텍스트 덤프로 동기화하는 커맨드를 만들어 사용한다.

analytics-engineer 스타일 에이전트를 만들어 dbt 모델 작성, 코드 리뷰, dev 환경 테스트를 수행한다.

---

서브에이전트로 컨텍스트를 깨끗하게 유지한다

1월 글에서 code-simplifier와 verify-app 서브에이전트를 소개했고, 2월 글에서는 사용법이 구체화되었다.

Claude가 더 많은 연산을 투입하길 원하면 요청에 “use subagents”를 추가하면 된다.

개별 작업을 서브에이전트에 위임하면 메인 에이전트의 컨텍스트 윈도우가 깨끗하고 집중된 상태로 유지된다.

이는 "컨텍스트를 자주 초기화하라"는 원칙의 자동화 버전이다.

 

권한 요청을 Opus 4.5로 라우팅하는 hook을 설정하면, 공격적인 스캔 후 안전한 요청은 자동 승인된다.

---

버그 수정은 Claude에게 맡긴다

2월 글에서 새롭게 추가된 실전 패턴이다.

Slack MCP를 활성화하고 Slack 버그 스레드를 Claude에 붙여넣은 뒤 "fix"라고만 입력하면, 컨텍스트 전환 없이 수정이 가능하다. "Go fix the failing CI tests"라고만 지시하고 방법은 Claude에게 맡기는 것도 효과적이다.

 

docker logs를 Claude에 전달해 분산 시스템 트러블슈팅에 활용하는 것도 가능하며, Boris는 이를 "놀라울 정도로 유능하다"고 표현했다.

---

4. 품질 보장

피드백 루프가 가장 중요한 단일 요소다

두 글 모두에서 Boris가 가장 중요하다고 명시한 항목이다.

Claude에게 작업을 검증할 수 있는 수단을 제공하면 최종 결과물 품질이 2~3배 향상된다.

 

검증 수단은 도메인마다 다르다. bash 명령 실행처럼 단순할 수도 있고, 테스트 스위트 실행이나, Claude Chrome 확장 프로그램으로 브라우저를 열어 UI를 직접 테스트하는 것일 수도 있다.

 

2월 글에서 추가된 프롬프트 기법도 품질 보장과 직결된다.

"이 변경사항을 엄격히 검토하고, 내가 테스트를 통과할 때까지 PR 만들지 마"라고 지시해 Claude를 리뷰어로 활용한다.

 

"이게 작동한다는 걸 증명해봐"라고 하며 main 브랜치와 feature 브랜치 간 동작 차이를 diff하도록 요청한다. 평균적인 결과가 나오면 "지금까지 알게 된 모든 것을 바탕으로 이걸 버리고 우아한 솔루션을 구현해"라고 지시한다.

---

PostToolUse 훅과 권한 관리

PostToolUse 훅으로 Claude가 파일을 수정할 때마다 자동으로 포매터를 실행한다. Claude 자체가 잘 포매팅된 코드를 생성하지만, 훅이 나머지 10%를 처리해 CI에서 포매팅 오류를 방지한다.

 

권한 관리는 --dangerously-skip-permissions를 쓰지 않고, /permissions로 안전한 명령을 사전 허용하는 방식이다. 설정은 .claude/settings.json에 체크인해 팀과 공유한다.

---

5. 확장 활용: 코딩 너머의 Claude Code

2월 글에서 새롭게 추가된 영역이다. Boris는 Claude Code를 코딩 도구가 아니라 범용 작업 플랫폼으로 활용한다.

데이터 분석

bq CLI로 BigQuery에 즉석 쿼리를 실행하고 분석한다. BigQuery skill을 코드베이스에 체크인해두면 팀 전체가 Claude Code에서 직접 분석 쿼리를 돌릴 수 있다. Boris는 6개월 이상 SQL을 직접 작성하지 않았다고 말한다. CLI, MCP, API가 있는 모든 데이터베이스에 동일하게 적용 가능하다.

---

학습 도구

/config에서 “Explanatory” 또는 “Learning” 출력 스타일을 활성화하면 Claude가 변경 사항의 이유(why)를 설명한다. 익숙하지 않은 코드를 설명하는 시각적 HTML 프레젠테이션 생성을 요청하면 놀라울 정도로 좋은 슬라이드를 만든다. 새로운 프로토콜과 코드베이스 이해를 위해 ASCII 다이어그램을 그리게 하는 것도 효과적이다.

 

가장 흥미로운 활용은 간격 반복 학습(spaced-repetition) skill이다. 사용자가 자신이 이해한 내용을 설명하면, Claude가 빈틈을 채우는 추가 질문을 하고 그 결과를 저장한다. 코드를 이해하는 것이 품질의 전제라는 원칙을 도구 수준에서 구현한 것이다.

---

한 문장 요약

Boris의 워크플로우를 관통하는 단 하나의 원칙이 있다면 이것이다:

Claude에게 일을 시키기 전에 계획을 완벽하게 만들고, 일을 시킨 후에는 스스로 검증할 수 있는 수단을 반드시 제공하라.

Claude Code 창시자 Boris Cherny가 Claude Code를 사용하는 방법 | GeekNews

Claude Code 창시자가 공개한 실전 사용 팁 | GeekNews