Claude Code 창시자 Boris Cherny가 Claude Code를 사용하는 방법
(x.com/bcherny)- 자신의 실제 작업 환경과 워크플로우를 공개, 터미널에서 5개의 Claude를 병렬 실행하고 웹에서 5~10개를 추가로 운영하는 방식 소개
- 모든 작업에 Opus 4.5 with thinking을 사용하며, 크고 느리지만 조정이 적게 필요하고 도구 활용 능력이 뛰어나 결과적으로 더 빠름
- 팀 전체가 하나의
CLAUDE.md파일을 공유하며, Claude가 잘못된 행동을 할 때마다 해당 내용을 추가해 학습 효과 축적 - 대부분의 세션을 Plan 모드로 시작해 계획을 충분히 다듬은 후, auto-accept 모드로 전환해 한 번에 완성하는 패턴 활용
- Claude가 스스로 작업을 검증할 수 있는 피드백 루프를 제공하는 것이 최종 결과물 품질을 2~3배 높이는 가장 중요한 요소
1/ 병렬 실행 환경 구성
- 터미널에서 5개의 Claude를 병렬 실행, 탭에 1~5 번호를 붙이고 시스템 알림 으로 입력이 필요한 시점 파악
2/ 웹과 로컬의 병렬 운영
- claude.ai/code 웹에서도 5~10개의 Claude를 추가로 병렬 실행, 로컬 Claude와 함께 운영
- 로컬 세션을 웹으로 핸드오프(
&사용)하거나, Chrome에서 직접 세션 시작, --teleport로 양방향 전환 - iOS 앱에서 매일 아침과 하루 중 여러 세션을 시작하고 나중에 확인하는 방식도 활용
3/ 모델 선택: Opus 4.5 with thinking
- 모든 작업에 Opus 4.5 with thinking 사용
- 지금까지 사용한 최고의 코딩 모델
- Sonnet보다 크고 느리지만, 조정(steering)이 적게 필요하고 도구 활용 능력이 뛰어남
- 결과적으로 작은 모델보다 거의 항상 더 빠른 최종 결과 도출
4/ CLAUDE.md를 통한 팀 단위 지식 축적
- Claude Code 저장소에 팀 전체가 공유하는 단일 CLAUDE.md 파일 유지
- git에 체크인하며, 팀 전체가 주 단위로 여러 번 기여
- Claude가 잘못된 행동을 할 때마다 CLAUDE.md에 추가해 다음에 같은 실수 방지
- 다른 팀들도 각자의 CLAUDE.md를 유지하며, 각 팀이 최신 상태 유지 책임
5/ 코드 리뷰 시 CLAUDE.md 업데이트
- 코드 리뷰 시 동료 PR에 @.claude를 태그해 PR의 일부로 CLAUDE.md에 내용 추가
- Claude Code GitHub Action(/install-github-action) 활용
- Dan Shipper의 Compounding Engineering 개념과 유사한 방식
6/ Plan 모드와 자동 수락 워크플로우
- 대부분의 세션을 Plan 모드(shift+tab 두 번)로 시작
- PR 작성이 목표일 경우 Plan 모드에서 Claude와 계획이 만족스러워질 때까지 반복 협의
- 계획 확정 후 auto-accept edits 모드로 전환하면 Claude가 보통 한 번에(1-shot) 완성
- 좋은 계획이 정말 중요함
7/ 슬래시 커맨드를 통한 반복 작업 자동화
- 하루에 여러 번 수행하는 "inner loop" 워크플로우마다 슬래시 커맨드 사용
- 반복 프롬프팅 절약, Claude도 이 워크플로우 활용 가능
- 커맨드는 git에 체크인되며 .claude/commands/ 디렉토리에 저장
- 예: /commit-push-pr 슬래시 커맨드를 매일 수십 번 사용
- 인라인 bash로 git status 등 정보를 미리 계산해 빠른 실행과 모델과의 불필요한 왕복 방지
8/ 서브에이전트 활용
- 여러 서브에이전트 를 정기적으로 사용
- code-simplifier: Claude 작업 완료 후 코드 단순화
- verify-app: Claude Code 엔드투엔드 테스트를 위한 상세 지침 포함
- 슬래시 커맨드와 유사하게, 대부분의 PR에서 수행하는 가장 일반적인 워크플로우 자동화 개념
9/ PostToolUse 훅을 통한 코드 포매팅
- PostToolUse 훅을 사용해 Claude의 코드 포매팅 처리
- Claude는 기본적으로 잘 포매팅된 코드를 생성하며, 훅이 나머지 10%를 처리해 나중에 CI에서 포매팅 오류 방지
10/ 권한 관리 방식
- --dangerously-skip-permissions 사용하지 않음
- 대신 /permissions를 사용해 환경에서 안전하다고 알려진 일반적인 bash 명령을 사전 허용
- 불필요한 권한 프롬프트 회피
- 대부분 .claude/settings.json에 체크인되어 팀과 공유
11/ Claude Code의 도구 통합 활용
- Claude Code가 모든 도구를 대신 사용
- Slack 검색 및 게시 (MCP 서버 활용)
- BigQuery 쿼리 실행 (bq CLI)으로 분석 질문 답변
- Sentry에서 에러 로그 가져오기
- Slack MCP 설정은 .mcp.json에 체크인되어 팀과 공유
12/ 장시간 작업 처리 방식
- 매우 긴 작업의 경우 세 가지 방법 중 선택:
- (a) 완료 시 백그라운드 에이전트로 작업 검증하도록 프롬프트
- (b) 에이전트 Stop 훅 을 사용해 더 결정론적으로 검증
- (c) Geoffrey Huntley가 고안한 ralph-wiggum 플러그인 사용
- 샌드박스에서 --permission-mode=dontAsk 또는 --dangerously-skip-permissions 사용해 권한 프롬프트 없이 Claude가 작업에 집중하도록 설정
13/ 가장 중요한 팁: 검증 피드백 루프 제공
- Claude Code에서 훌륭한 결과를 얻기 위한 가장 중요한 요소: Claude에게 작업을 검증할 방법 제공
- 이 피드백 루프가 있으면 최종 결과물 품질이 2~3배 향상
- Claude가 claude.ai/code에 랜딩하는 모든 변경 사항을 Claude Chrome 확장 프로그램 으로 테스트
- 브라우저를 열고 UI를 테스트하며, 코드가 작동하고 UX가 좋을 때까지 반복
-
검증 방식은 도메인마다 다름
- bash 명령 실행처럼 단순할 수도 있고
- 테스트 스위트 실행
- 브라우저나 폰 시뮬레이터에서 앱 테스트
- 이 검증 과정을 견고하게 구축하는 데 투자가 필요함
- 웹과 로컬의 병렬 운영
원글 이미지를 보니 로컬에서 5개, 웹에서 5개 띄워서 작업 하시는거 같더라고요. 굳이 로컬 10개, 웹 10개 이렇게 안하고 5개, 5개로 나눠서 하는 이유가 있으려나요?
웹에서는 아마도 간단한 체크 및 로컬의 작업과 동일한 git branch에서 간단한 작업용인거 같아요.
(이동중에도 일하려고??)
추측이지만 로컬에서 5개를 만들 때 용도별로 git branch를 다르게 해서 컨텍스트 관리를 하고
각각의 tab은 예를 들면
tab1은 DB 쿼리 생성 및 기획, tab2 백앤드, tab3 API개발, tab 4 프론트엔드, tab 5 코드리뷰 등 충돌이 최소화되는 범위로 병렬로 운영하지 않을까하는 추측입니다.
추측입니다만, 아마 이동중에 모바일기기로 접근하려면 웹세션이어야해서 그런 것 아닐까요. 10개 정도가 감당가능한 인지부하인 상황에서, 5개는 로컬에서 pc로 딥하게 작업하고, 나머지는 모바일로 빠르게 작업하는 식으로요.