클로드 코드 창시자의 클로드 코드 꿀팁 13가지

X에서 보기 https://x.com/bcherny/status/2007179836704600237

Claude Code의 창시자 Boris Cherny의 13가지 사용 꿀팁을 다뤄봅시다

아마 제 유료 플랜에서는 토큰이 금방 동나곘죠...? 개발하면서 무제한으로 토큰을 쓴다는 건 참 부럽네요 ㄷㄷ;

직접 프로젝트에 적용해보면서 해봅시다

---

1) 터미널에서 Claude 5개를 동시에 돌리기

터미널 탭을 1~5로 번호 붙여두고 Claude를 각각 실행합니다.

각 세션이 내 입력을 필요로 하면 시스템 알림으로 확인하고,
병렬로 작업을 밀어붙여 속도를 끌어올립니다.

https://code.claude.com/docs/ko/terminal-config#iterm-2-system-notifications

터미널 설정 최적화 - Claude Code Docs

 

일단은 iTerm2을 쓰는것을 권장하니까 이걸 쓰도록 합시다.

Shift+Enter 설정 (VS Code 또는 iTerm2):Claude Code 내에서 /terminal-setup을 실행하여 Shift+Enter를 자동으로 구성합니다.

줄바꿈은 평소에 shift + enter로 써서 이거로 할게요. 맥이랑 iTerm2에서 알림 설정을 키면 됩니다.

 

알림 뜨는지 테스트 해보기

echo -e "\033]9;작업 완료 테스트\007"
# 또는
printf '\033]9;작업 완료 테스트\007'

 

저는 cmd + D로 터미널 분할하고 커맨드 + alt + <- or -> 로 창을 이동합니다.

귀여운 클로드가 여러개 나오게 됩니다.

 

벌써 기대가 되는데 이렇게 병렬 에이전트 5개로 나누면 3가지 정도의 패턴이 있습니다.

A. 파이프라인 : 한 에이전트가 결과를 만들고 -> 다음 에이전트가 품질을 올립니다.

1. Planner: 요구사항/변경 범위/리스크/작업 순서 계획
2. Implementer: 코드 변경(기능 구현)
3. Code-simplifier: 리팩토링/중복 제거/가독성 개선
4. Formatter/Linter: 포맷/정적분석/CI 스타일 맞춤(훅으로도 처리)
5. Verifier: 테스트 실행, E2E 체크리스트, 실패 시 원인/수정 제안

Boris 글의 Plan mode → auto-accept edits → 후처리(포맷) → 검증 흐름이 이 패턴에 가깝습니다.

B. 병렬 탐색 : 같은 문제를 주되 서로 다른 제약/전략을 부여해 대안을 뽑는 방식입니다.

• Agent1: 최소 변경(Minimal diff)
• Agent2: 성능/복잡도 최적화
• Agent3: 안정성/에러 처리 강화
• Agent4: API/UX 일관성 중심
• Agent5: 테스트 우선(TDD) 접근

이후 사람이 한 안을 선택하거나, Coordinator가 통합합니다.

단, “동시에 같은 파일을 수정”하게 하면 충돌이 커지므로 계획/설계/대안 도출에 병렬을 주고, 구현은 1개가 하는 편이 안전합니다.

C. 검증 전용 다중화(같은 일을 검사) : 구현은 1개가 하고, 나머지는 리뷰/테스트/보안/엣지케이스만 전담합니다.

• Review agent: 코드리뷰(논리/구조/가독성)
• Security agent: 입력 검증/권한/민감정보/취약점
• Test agent: 누락된 테스트/케이스 추가
• Perf agent: 병목/쿼리/N+1/캐시 점검
• Release agent: 릴리즈 노트/마이그레이션/롤백 플랜

일을 시키는 방식은 또 여러가지가 있을 수 있겠죠?

 

하다보니 문득 멀티 프로세싱이랑 상당히 유사하다는 직관이 떠올랐는데요

 멀티 스레딩은 어디있을까요?

 

바로 /agents를 통한 서브에이전트 호출입니다.

 

agent들을 먼저 만들어야 합니다.

claude에서 /agents를 입력하면 

이런식으로 Create new agent를 만들수 있고 아래는 생성된 목록입니다.

저는 테스트 하는 에이전트를 만들었어요

이제 하나의 터미널에서 실행되는 하나의 프로세스가 병렬로 테스트도 진행하게 할 수 있게 됐습니다.

당연히 여러개 터미널에서 실행한다면 여러개의 프로세스가 실행이 되겠죠

2) 웹에서도 claude 5~10개 병렬로 돌리기

로컬 터미널 세션과 동시에 claude.ai/code 웹에서도 5~10개 세션을 병렬로 운영합니다.

그리고 작업 흐름은 이렇게 유연하게 운영한다고해요!

• 터미널에서 코딩하다가 로컬 세션을 웹으로 넘기거나
• 크롬에서 새 세션을 수동으로 띄우기도 하고
• 필요하면 로컬↔웹을 teleport 하면서 진행
• 또 매일 아침/중간중간 아이폰 Claude 앱에서 세션을 몇 개 시작해두고, 나중에 다시 들어가 확인

즉, “한 세션을 완벽하게 운영”이 아니라 여러 세션을 동시에 굴리는 운영에 가깝습니다.

이건 토큰이 많이 들기도 하고 무료 버전은 지원 안하네용

3) 모든 작업은 Opus 4.5 Thinking을 켠 상태로 수행

Boris는 Opus 4.5를 “지금까지 써본 코딩 모델 중 최고”라고 말합니다.
Sonnet보다 크고 느리지만, 개입이 적어도 되고 툴 사용이 뛰어나서
결국 전체 속도는 Opus가 더 빠르다는 논리예요.

+ 따로 설정을하지 않았다면 Opus가 기본 모델입니다. 아래와 같이 바꿀 수 있습니다.

# Opus로 시작
claude --model opus

# 세션 중에 Sonnet으로 전환
/model sonnet

4) 팀 단위로 하나의 md 파일을 공유하기

ALT

 

레포에 claude.md 파일을 하나 두고 이를 git에 커밋해서 팀이 함께 관리합니다.

• 팀 전체가 일주일에 여러 번 계속 업데이트
• Claude가 틀리게 하거나 원치 않는 행동을 하면 그 내용을 claude.md에 추가
• 다음부터 같은 실수를 반복하지 않도록 “팀 룰”을 축적

즉, 개인의 프롬프트가 아니라 팀의 규칙이 누적되는 구조를 만들어요.

5) 코드 리뷰할 때 @claude 태그하기

PR 리뷰를 할 때 @claude로 호출해, 해당 PR에서 나온 “배운 점/규칙”을 claude.md에 추가하도록 요청합니다.
이를 위해 Claude Code GitHub Action(/install-github-action)을 사용한다고 해요.

Boris는 이걸 Dan Shipper의 ‘Compounding Engineering(복리형 엔지니어링)’의 변형이라고 설명합니다.
코드 리뷰를 단순 퀄리티 체크가 아니라, 팀의 AI 운영 시스템을 강화하는 루틴으로 바꿔버리는 방식이네요.

6) 대부분의 세션은 Plan 모드로 시작하기

그는 “좋은 계획이 정말 중요하다”고 강조합니다.
목표가 PR 생성이라면 흐름은 이렇습니다.

1. Plan 모드에서 Claude와 계획을 계속 주고받아 만족스러운 플랜을 만든다
2. 그 다음 auto-accept edits 모드로 전환한다
3. 그러면 Claude가 대부분 한 번에(1-shot) 작업을 끝낸다

즉, 실행은 빠르게 대신 계획에서 시간을 쓰는 방식입니다.

 

shift + tab을 하면 plan mode로 실행이 됩니다.

---

7) ‘내부 루프(inner loop)’ 작업은 전부 슬래시 커맨드로 만들기

ALT

 

반복되는 프롬프트는 매번 치지 않고 슬래시 커맨드로 만들어 재사용합니다.

• 커맨드는 .claude/commands/에 저장
• git에 체크인해서 팀 공유
• 반복 작업을 워크플로우 단위로 “명령어화”

8) 서브에이전트 활용하기

ALT

 

정기적으로 쓰는 서브에이전트를 만들어 반복 워크플로를 자동화합니다.

예시:

• code-simplifier : Claude가 코딩 후 코드를 더 단순하게 정리
• verify-app : Claude Code E2E 테스트 지침 포함

슬래시 커맨드가 “명령어”라면 서브에이전트는 자주 쓰는 업무 패턴을 자동화한 역할에 가깝습니다.

9)PostToolUse hook 사용하기

“Claude가 코드 작성 → 훅이 자동 포맷 → CI 에러 방지”
Claude가 기본적으로도 포맷을 잘 맞추지만, 훅이 마지막 10%를 처리해줘서
나중에 CI에서 포맷팅 오류가 나는 걸 막을 수 있습니다.

---

9)위험한 Skip 권한은 지양하기

권한 확인을 통째로 건너뛰는 방식(--dangerously-skip-permissions)은 지양하고,
대신 /permissions로 자주 쓰는 안전한 bash 명령을 미리 허용합니다.

• 권한 확인 팝업으로 흐름이 끊기는 문제를 줄이고
• 설정을 .claude/settings.json에 체크인해 팀 단위로 공유·표준화

핵심은 편의성 때문에 보안을 생략하는 게 아니라,
반복 작업을 안전하게 자동화하는 구조를 만드는 것입니다.

11) MCP 적극 활용하기 (Claude가 도구를 “대신” 쓰게 만들기)

MCP를 활용해 Claude Code가 내 도구를 직접 쓰게 합니다.

• Slack 검색/메시지 포스팅
• bq CLI로 BigQuery 쿼리 실행 → 분석 질문 답변
• Sentry에서 에러 로그 수집

그리고 Slack MCP 설정은 .mcp.json에 체크인해 팀이 공유합니다.

---

12) 긴 작업의 경우 검증 루프를 붙여 품질 안정화시키기

오래 걸리는 작업일수록 결과 리스크가 크기 때문에, 검증 루프를 붙여 품질을 안정화합니다.

• (1) 작업 완료 후 백그라운드 에이전트로 검증
• (2) agent Stop hook으로 더 확실하게 자동 검증
• (3) ralph-wiggum 플러그인으로 반복 검증

필요하면 샌드박스에서 --permission-mode=dontAsk 또는 skip 옵션을 사용해
세션이 권한 요청으로 멈추지 않게 만들어 막힘 없는 진행을 확보합니다.

13) 모델이 스스로 검증하게하기

Claude는 “그럴듯한 답”을 잘 만들지만,
검증 루프가 붙는 순간 최종 결과 품질이 2~3배까지 올라간다고 해요.

예를 들어 Boris는 자신이 배포하는 변경사항마다 Claude가 브라우저를 열어 UI를 직접 테스트하고
코드가 제대로 동작하고 UX가 만족스러울 때까지 반복하게 합니다. (Claude Chrome extension 사용)
도메인에 따라 검증 방식은 달라질 수 있어요. 단순히 bash 명령 한 번 돌리는 수준일 수도 있고
테스트 스위트를 실행하거나, 브라우저/모바일 시뮬레이터로 실제 동작을 확인하는 형태일 수도 있습니다.

결국 핵심은 모델에게 더 좋은 프롬프트를 주는 것이 아니라
모델이 스스로 틀렸다는 걸 알아차릴 수 있는 환경을 제공하는 것입니다.

---

이런 것들을 하기 위해서는 운영체제와 관련하여 CS 지식이 좀 중요한 것 같다는 생각이 드는데요.

꾸준히 공부하면서 발전하는 것 또한 중요하겠네요 :)