저는 Claude Code의 창시자 보리스 체르니(Boris Cherny)가 필수라고 말한 30가지 운영 팁을 직접 정리했습니다. 정말 전설적인 글입니다.
솔직히 말해서, 이 팁들을 알면 모르면 Claude Code 경험이 하늘과 땅 차이로 달라집니다. 같은 지시를 반복하거나 재작업에 시간을 낭비하던 모든 순간이 완전히 불필요했다는 것을 깨닫게 될 것입니다.
그런데 Claude Code를 사용할 때 이런 문제를 겪어본 적이 없나요?
- 매번 같은 지시를 내리는 것 같아서 알아서 학습해줬으면 좋겠다고 생각한 적이 있다.
- 대규모 변경을 하면 계속 재작업이 발생해서 직접 수정하는 게 더 빠르겠다고 느낀 적이 있다.
- 기능이 너무 많아서 어디서부터 시작해야 할지 모르겠다.
- 대화가 길어지고 산만해져서 "잠깐, 방금 그거 말했잖아?" 하는 순간이 있다.
Claude Code의 경험은 컨텍스트 설정, 검증, 권한, 병렬 설계, 자동화를 제대로 설정했을 때 극적으로 달라집니다.
이 글은 ClaudeCodeStudio가 독립적으로 조사하고 작성했으며, 2026년 4월 23일 기준으로 보리스 체르니의 X 게시물, Anthropic 공식 문서, 공식 GitHub 저장소/액션 등 1차 정보를 우선시했습니다!
보리스가 "내가 Claude Code를 만들었다"고 명시적으로 밝혔기 때문에, 그의 운영 조언을 현장의 목소리로 우선시하고 CLI 옵션 및 설정은 공식 문서와 교차 검증했습니다! 😆
Claude Code를 사용한다면, 이 글은 반드시 읽어야 합니다!!!
저장은 필수입니다!!!!
생산성이 현실적으로 10배는 바뀔 것입니다! 자, 시작해볼까요! 👇
■ 먼저 이해해야 할 세 가지 원칙
Claude Code를 실전에서 강력하게 만드는 가장 큰 요소는 단 세 가지로 요약됩니다.
Plan Mode에서 "조사"와 "구현"을 분리하는 것. Claude가 스스로 작업을 검증하도록 하는 것. 그리고 병렬 세션을 염두에 두고 작업하는 것입니다.
보리스는 반복해서 말합니다: "거의 항상 Plan mode를 사용하고", "Claude에게 출력을 검증할 방법을 제공하고", "3-5개의 git worktrees를 사용하라"고.
■ "단일 정답은 없다"는 철학
보리스의 게시물을 읽어보면, Claude Code를 사용하는 단일 정답은 없으며, 대신 highly customizable한 운영 도구로 사용해야 한다는 입장이 반복해서 나옵니다. 그 자신도 "Claude Code를 사용하는 올바른 방법은 하나뿐이 아니다"라고 반복합니다.
이러한 전제를 바탕으로, 그가 제안하는 가장 효과적인 워크플로우는 다음과 같습니다 👇
Plan Mode에서 조사/계획
↓ 구현 세션
↓ 테스트, 스크린샷, CLI를 통한 자체 검증
↓ PR 생성
↓ 코드 리뷰 / Ultrareview
↓ 학습 내용을 CLAUDE.md, Hooks, Skills에 피드백
이 흐름을 염두에 두고, 30가지 구체적인 팁을 살펴보겠습니다.
■ 30가지 운영 팁
현장에서의 효과 순으로 나열했습니다. 보리스의 X 게시물에서 파생된 팁은 방향성에 초점을 맞추고, 설정 및 제약 조건에 대한 세부 사항은 공식 Docs와 GitHub를 통해 보강했습니다. 연구 미리보기 기능은 명확하게 표시했습니다.
■ 팁 1: 대규모 변경은 먼저 Plan Mode에서 격리하라
조사, 계획, 구현을 단순히 분리하는 것만으로도 잘못된 구현과 재작업이 획기적으로 줄어듭니다. 간단하지만, 이것이 바로 보리스가 "거의 항상 Plan mode를 사용하라"고 말하는 이유입니다.
예시: "Plan Mode에서 src/auth와 secrets를 읽어보세요. Google OAuth에 대한 영향받는 파일, 데이터 흐름, 테스트 관점을 구현 시작 전에 정리하세요."
Plan Mode 없이 대규모 변경에 뛰어들면 컨텍스트를 잃거나 중간에 방향을 수정해야 하는 경우가 많습니다. 먼저 전체 그림을 파악하도록 하면 구현 정확성이 정말로 달라집니다.
■ 팁 2: Claude가 스스로 검증하도록 하라
보리스는 이것을 "단일 최고 레버리지 요소"라고 부릅니다. Claude가 테스트를 실행하고, 스크린샷을 확인하고, CLI 출력을 스스로 검증하도록 하세요.
"수정 후, npm test를 실행하고 모든 테스트가 통과해야만 완료된 것으로 간주합니다."
이것만으로도 Claude는 사람이 검토하기 전에 문제를 찾아서 수정할 수 있습니다. 검증 명령이 너무 무겁다면 최소한의 smoke test부터 시작하세요.
■ 팁 3: 3-5개의 Git Worktrees를 병렬로 실행하라
보리스는 병렬 worktree 운영을 "가장 중요한 생산성 향상"이라고 부릅니다.
git worktree add ../repo-auth -b feat/auth와 같이 여러 worktree를 추가하고 각각에서 Claude를 시작하면 대기 시간이 0으로 줄어들고, 독립적인 작업을 동시에 진행할 수 있습니다.
최적의 개수는 환경에 따라 다릅니다. 3-5개가 가이드라인이지만, 리뷰 대역폭, CPU, 그리고 자신의 컨텍스트 전환 비용에 따라 2개가 적합한 사람도 있고, 6개를 처리할 수 있는 사람도 있습니다.
■ 팁 4: CLAUDE.md를 과감하게 편집하라
CLAUDE.md는 프로젝트의 구체적인 규칙집입니다. 방치하면 구식이 되어 Claude가 잘못된 전제 하에 움직이기 시작합니다.
보리스의 방침은 간단합니다: "시간이 지남에 따라 CLAUDE.md를 과감하게 편집하라" 그리고 "Claude가 같은 실수를 두 번째로 하면 추가하라."
반대로, 더 이상 필요하지 않은 규칙은 삭제하세요. 너무 비대해지면 컨텍스트를 소모하므로 주기적인 정리가 중요합니다.
■ 팁 5: 매일 반복되는 작업을 Skills로 만들어 Git에 커밋하라
매번 대화에서 반복적인 절차를 설명하는 것은 시간 낭비입니다. .claude/skills/deploy/SKILL.md를 만들고 /deploy staging으로 호출하세요.
보리스는 "하루에 한 번 이상 하는 일이 있다면 skill이나 command로 만들어라"고 말하며, "필요할 때까지 비용이 거의 들지 않는다"고 덧붙입니다.
하지만 Skill이 너무 비대해지면 트리거가 모호해질 수 있으므로, 긴 참고 자료는 분할하세요.
■ 팁 6: 팀 설정을 settings.json에 넣고 Git으로 관리하라
프로젝트별 설정을 버전 관리하면 전체 팀이 동일한 Claude Code 경험을 할 수 있습니다. 온보딩 속도를 높이고 설정이 특정 개인에게 의존하는 것을 방지합니다.
당연히 개인 API 키나 토큰은 절대 커밋하지 마세요. .gitignore를 확인하는 것을 잊지 마세요.
■ 팁 7: 안전한 권한은 사전 승인하고, 위험한 영역은 거부하라
매번 "이 작업을 허용하시겠습니까?"라는 질문을 받는 것이 스트레스가 아닌가요? allow/ask/deny를 사용하면 이 대화 피로도를 없앨 수 있습니다.
"allow": ["Bash(npm test *)"], "ask": ["Bash(git push *)"], "deny": ["Read(./.env)", "Read(./secrets/**)"]
보리스는 "일반적인 권한은 사전 승인하라"고 말하며, 공식 Docs는 "규칙은 deny... ask... allow 순서로 평가된다"고 명시합니다. .env나 secrets는 명시적으로 거부하여 지나치게 광범위한 와일드카드를 피하는 것이 원칙입니다.
■ 팁 8: --add-dir을 사용하여 여러 폴더/저장소에 걸쳐 작업하라
모노레포 외부의 문서나 라이브러리를 보여주고 싶은 경우가 많습니다.
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../docs --add-dir ../shared-libs
이렇게 하면 외부 문서를 참조하면서 코딩할 수 있습니다. 추가된 디렉토리의 CLAUDE.md를 읽으려면 환경 변수를 활성화해야 합니다.
■ 팁 9: Subagent와 역할 분담을 가정하라
조사, 리뷰, 디버깅을 모두 메인 컨텍스트에 집어넣으면 대화가 산만해집니다. 보리스는 "몇몇 subagent를 정기적으로 사용한다"고 말하며, 각 subagent는 자체 전용 컨텍스트 창에서 실행됩니다.
code-reviewer, debugger, data-scientist와 같은 subagent를 준비하고, 명확한 설명을 작성하세요.
■ 팁 10: PostToolUse Hooks로 포맷팅/검사를 자동화하라
Claude가 파일을 편집할 때마다 formatter나 linter를 자동으로 실행하세요.
Claude에게 물어보세요: "모든 파일 편집 후 prettier --write를 실행하는 hook을 작성해줘."
Hook 생성부터 .claude/settings.json에 통합까지 모든 것을 처리합니다. 이렇게 하면 코드 스타일 일관성이 자동화되고 리뷰에서 스타일 관련 코멘트가 사라집니다.
■ 팁 11: PR 댓글을 통해 CLAUDE.md를 업데이트하라
PR에서 코드와 함께 "미래의 규칙"을 변경하세요. 보리스는 "동료의 PR에 @.claude를 태그하여 CLAUDE.md에 무언가를 추가하라"고 말합니다.
예를 들어, 댓글: "@claude 이 학습 내용을 CLAUDE.md에 추가해줘. src/billing의 변경은 항상 Plan Mode에서 시작해." 이렇게 하면 향후 반복적인 피드백이 줄어듭니다.
■ 팁 12: 상태 표시줄로 항상 현재 상태를 파악하라
화면 하단에 표시되는 정보는 "어떤 브랜치에서 무엇을 하고 있는지, 컨텍스트를 얼마나 사용했는지, 비용이 얼마인지"를 한눈에 보여줍니다.
/statusline show model name, git branch, context percentage, cost
브랜치, 컨텍스트%, 비용으로 시작하는 것이 일반적으로 컨텍스트 소진이나 브랜치 오류를 조기에 발견하기에 충분합니다.
■ 팁 13: Chrome 확장 프로그램으로 프론트엔드 작업을 가속화하라
보리스는 "프론트엔드 작업에는 Chrome 확장 프로그램을 사용하라"고 권장합니다. 브라우저 로그인 상태를 공유할 수 있으므로 UI 검증을 위해 Claude에게 스크린샷 비교를 보여줄 수 있습니다.
Claude가 코드에서 보이지 않는 UI 손상을 감지하는 것은 큰 장점입니다. 하지만 스크린샷으로 접근성이나 체감 속도를 측정할 수는 없으므로 필요에 따라 Lighthouse나 e2e 테스트를 사용하세요.
■ 팁 14: Claude가 CLI를 통해 분석 작업을 처리하도록 하라
Claude가 SQL이나 CLI를 사용하도록 하면 개발, 분석, 전략을 동일한 작업 공간으로 가져올 수 있습니다.
"bq CLI를 사용하여 지난 7일간 채널별 전환 지표를 가져오고, 이상 징후를 요약하고, 가설을 제안해줘."
보리스가 "데이터 분석에 Claude를 사용하라"고 말한 것처럼, 이 팁은 개발자뿐만 아니라 제품 관리자에게도 효과적입니다.
■ 팁 15: 사양이 모호하면 Claude가 인터뷰하도록 하라
공식 Docs에는 "Claude가 인터뷰하도록 하라"는 섹션이 있습니다. 구현에 뛰어드는 대신, Claude가 질문을 통해 요구 사항을 도출하도록 하세요.
구현 전에 사양의 공백을 메우면 재작업이 획기적으로 줄어듭니다. 특히 "무엇을 만들지"가 모호할 때 더욱 그렇습니다.
■ 팁 16: CLAUDE.md와 Auto Memory의 역할을 분리하라
사람은 CLAUDE.md에 규칙을 작성합니다. Claude는 발견된 선호도와 습관을 auto memory에 기억합니다. 이 구분을 유지하면 설정이 지저분해지는 것을 방지할 수 있습니다.
■ 팁 17: 경로별 규칙과 압축을 염두에 두고 설계하라
모노레포에서는 "전역 규칙"과 "지역 규칙"을 분리하세요. 전역 규칙은 루트 CLAUDE.md에, 지역 규칙은 src/billing 등에 넣으세요.
■ 팁 18: 컨텍스트를 적극적으로 관리하라
공식 Docs는 "컨텍스트를 적극적으로 관리하라"고 명시합니다. 중요한 운영 지식은 CLAUDE.md나 skills로 승격시키고, /compact를 사용하여 컨텍스트 창을 정기적으로 정리하세요.
■ 팁 19: "무서운 변경"은 /rewind와 Checkpoints로 시도하라
Claude Code의 모든 작업은 checkpoint입니다. Esc를 두 번 누르거나 /rewind를 사용하여 코드만, 대화만, 또는 둘 다를 통해 메시지 checkpoint로 돌아갈 수 있습니다.
■ 팁 20: MCP 서버를 통해 외부 도구에 연결하라
Claude Code에서 Slack, Jira, 데이터베이스 또는 내부 API를 직접 조작하면 도구 전환 비용이 획기적으로 줄어듭니다.
■ 팁 21: 비대화형 모드 (claude -p)로 스크립트/CI에 통합하라
비대화형 모드는 Claude Code 자동화의 진입점입니다.
claude -p "모든 API 엔드포인트 나열" --output-format json
■ 팁 22: 파일별로 claude -p를 사용하여 대규모 마이그레이션을 분산하라
하나의 세션에서 대규모 마이그레이션을 처리하는 것은 불가능합니다. 수평으로 분산하는 것이 더 좋습니다.
■ 팁 23: 이슈 관리 도구에서 직접 구현하라
Claude가 GitHub Issues나 Linear 티켓을 읽고 바로 구현에 들어가도록 하세요.
■ 팁 24: Hooks로 규칙을 강제하라
CLAUDE.md는 "조언"이고, hooks는 "실행"입니다. 둘을 혼동하지 마세요. "예외 없음"이 필요한 작업에는 hooks를 사용하여 실행을 보장하세요.
■ 팁 25: /simplify를 사용하여 병렬 코드 리뷰를 수행하라
세 명의 리뷰 에이전트가 중복성, 품질, 효율성을 동시에 검사하고 수정까지 수행합니다.
■ 팁 26: GitHub Actions에서 @claude 멘션을 사용하라
공식 claude-code-action을 사용하면 PR이나 Issue에서 @claude를 멘션하는 것만으로 코드 변경을 구현하거나 답변을 얻을 수 있습니다.
■ 팁 27: 코드 리뷰와 Ultrareview를 구분하라
일상적인 리뷰와 심층 리뷰는 다릅니다. Code Review는 매일 사용하고, 머지 전에는 /ultrareview를 사용하여 심층 분석을 수행하세요.
■ 팁 28: 반복 작업을 Routines로 전환하라
주간 유지보수나 PR 연결 작업을 클라우드로 옮기세요. "노트북을 닫아도 계속 작업합니다."
■ 팁 29: 무거운 계획은 클라우드의 Ultraplan에 맡기라
터미널에서 기다리는 대신, 브라우저에서 계획을 챕터별로 검토하세요.
■ 팁 30: Remote Control로 클라우드 세션을 제어하라
로컬 머신에서 클라우드의 Claude Code 세션을 제어하는 기능입니다.
■ 해결되지 않은 운영 포인트
Chrome 확장 프로그램과 e2e 테스트의 조합, 또는 Stop hooks를 사용한 장기 "며칠 단위" 운영과 같이 방향성은 명확하지만 모범 사례가 확립되지 않은 영역에 대해서도 솔직하게 다루겠습니다.
■ 어디서부터 시작해야 할까
개발자라면 팁 1, 2, 4, 7, 9, 18부터 시작하세요. 제품 관리자라면 팁 14, 15, 23, 27, 28이 가장 효과적입니다.
■ 주간 체크리스트
- 같은 실수를 두 번 지적하고 있나요? → CLAUDE.md에 추가하세요.
- Skills/Hooks로 만들 반복 작업이 있나요? → 자동화하세요.
- 컨텍스트 사용량이 너무 높나요? →
/compact습관을 점검하세요. - Worktree 개수가 적절한가요? → 대역폭에 따라 조정하세요.
■ 결론
Claude Code를 마스터하는 핵심은 Plan → Verify → Persist → Automate 순서로 운영 구성 요소를 확고히 하는 것입니다. 모든 것을 한 번에 시작할 필요는 없습니다. 팁 1, 2, 4만으로도 개발 경험이 근본적으로 바뀔 것입니다.
또한, 오픈 채팅을 시작했습니다!
여기서 참여하실 수 있습니다 👇
유용한 정보를 공유하고 무료 세미나를 진행할 예정이니 꼭 참여해주세요! 😆
𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗦𝘁𝘂𝗱𝗶𝗼 @ 𝗝𝗮𝗽𝗮𝗻 (@ClaudeCode_love)은 세 명의 Claude Code enthusiast가 운영합니다. 실용적인 CLI 사용법과 자동화에 관한 정보를 매일 게시합니다. 실제 제품 개발 사례와 최신 글로벌 정보를 팔로우하세요! 👀
