도구를 제대로 이해하는 가장 빠른 방법은 기능표를 읽는 게 아니라, 그 도구를 만든 사람이 자기 도구를 어떻게 쓰는지 보는 것이다. 2026년 1월 2일, Claude Code를 만들었다고 밝힌 Boris Cherny는 X 스레드에서 자신의 개인 설정을 공개했다. 흥미로운 건 그가 이 세팅을 “의외로 바닐라하다”고 표현했다는 점이다. 특별한 비밀 프롬프트보다, Claude Code를 여러 개 동시에 돌리고, 계획을 먼저 세우고, 팀의 기억을 축적하고, 반복 작업을 시스템으로 굳히는 방식이 핵심으로 보인다.
한 명의 AI가 아니라, 여러 명의 비동기 작업자로 쓴다
Boris가 공개한 첫 번째 습관은 의외로 단순하다. 그는 터미널에서 Claude 5개를 병렬로 돌리고, 여기에 더해 claude.ai/code에서도 5~10개 세션을 동시에 운영한다고 했다. 로컬 세션을 웹으로 넘기거나, 다시 터미널로 가져오고, 아침과 낮 사이에는 iOS 앱에서도 몇 개 세션을 새로 시작해 나중에 다시 확인한다고 설명했다.
Claude Code 공식 문서도 웹에서는 병렬 작업과 이동 중 작업 시작을 지원하고, iOS/Android 앱에서도 진행 중 작업을 모니터링하거나 새 작업을 시작할 수 있다고 안내한다. 즉 그가 Claude를 쓰는 방식은 “한 명의 짝 프로그래머”가 아니라, 여러 개의 작업을 동시에 맡기는 작은 작업자 풀에 가깝다.
이 장면이 중요한 이유는 생산성의 단위를 바꿔버리기 때문이다. 많은 사람은 AI 코딩 도구를 “내 옆에서 같이 코딩해주는 존재”처럼 쓰지만, Boris의 사용법은 훨씬 운영자에 가깝다. 그는 직접 모든 대화를 붙잡고 있는 대신, 작업을 여러 세션으로 분산하고, 필요할 때만 개입한다. Claude Code가 웹, 터미널, 모바일을 모두 지원하도록 설계된 이유도 결국 여기에 있다. 같은 에이전트를 여러 표면에서 계속 이어 쓰게 해 주는 것이다.
속도는 응답 속도가 아니라 “완성 속도”다
그 스레드에서 Boris는 모든 작업에 Opus 4.5 with thinking을 쓴다고 말했다. 더 크고 느리지만, 덜 많이 steer 해도 되고 도구 사용 능력이 좋아서, 결국은 작은 모델보다 더 빨리 끝나는 경우가 많다는 설명이었다. 이 말은 꽤 중요하다. AI 코딩에서 체감 속도는 토큰 생성 속도가 아니라, 내가 원하는 결과까지 도달하는 총 왕복 횟수에 더 가깝기 때문이다.
많은 사람이 비용이나 지연 시간 때문에 작은 모델부터 고르지만, 창시자의 선택은 반대였다. 그는 “더 강한 모델을 쓰면 덜 고쳐도 된다”는 쪽에 베팅한다. 이 관점은 Claude Code를 단순 챗봇이 아니라 도구를 쓰고 수정까지 반복하는 에이전트로 볼 때 더 설득력이 생긴다. 도구 사용이 중요한 환경일수록, 한 번에 방향을 잘 잡는 모델이 전체 시간을 줄일 수 있다.
프롬프트를 비밀 노하우로 두지 않고, 저장소의 기억으로 만든다
Boris가 공개한 세팅에서 가장 인상적인 부분 중 하나는 CLAUDE.md다. 그는 Claude Code 저장소에 대해 팀 전체가 공유하는 하나의 CLAUDE.md를 git에 체크인하고, Claude가 뭔가 잘못할 때마다 여기에 규칙을 추가한다고 했다. 즉 프롬프트 엔지니어링을 개인의 채팅창 안에 숨겨두는 대신, 팀이 함께 관리하는 운영 문서로 끌어올린 셈이다.
Claude Code 공식 문서도 이 방향을 거의 그대로 권장한다. CLAUDE.md는 모든 대화 시작 시 읽히는 특수 파일이고, 코드 스타일, Bash 명령, 테스트 선호, 워크플로 규칙처럼 코드만 읽어서는 알기 어려운 지속 컨텍스트를 담으라고 설명한다. 문서는 이 파일을 git에 체크인해 팀이 기여하게 만들고, 시간이 지나며 가치가 쌓이게 하라고 권한다. 결국 Boris의 방식은 “좋은 프롬프트를 잘 쓰는 법”이 아니라, 좋은 팀 메모리를 잘 축적하는 법에 가깝다.
대부분의 복잡한 작업은 Plan Mode에서 시작한다
그는 대부분의 세션을 Plan Mode에서 시작한다고 말했다. 목표가 Pull Request를 만드는 것이라면, 먼저 Claude와 계획을 여러 번 주고받다가 충분히 마음에 들면 그제야 auto-accept edits 모드로 전환하고, 그 상태에서는 Claude가 꽤 자주 한 번에 구현까지 끝낸다고 했다. 한마디로 먼저 설계하고, 나중에 편집한다는 뜻이다.
이건 공식 문서의 모범 사례와도 정확히 일치한다. Claude Code 문서는 Plan Mode를 읽기 전용 분석 모드로 설명하며, 여러 파일에 걸친 변경, 코드베이스 탐색, 복잡한 리팩터링 같은 작업에 적합하다고 말한다. 또한 구현 전에 탐색과 계획을 분리하라고 권장한다. Boris의 사용법은 결국 “AI가 코드를 잘 쓰게 만드는 법”이 아니라, AI가 잘못된 문제를 풀지 않게 만드는 법에 가깝다. 여기서 핵심은 더 많이 말하는 것이 아니라, 먼저 더 정확하게 문제를 정의하는 것이다.
반복되는 작업은 프롬프트로 하지 않고, 명령으로 굳힌다
Boris는 하루에도 여러 번 반복하는 “inner loop” 워크플로마다 슬래시 커맨드를 만든다고 했다. 예시로 든 것이 /commit-push-pr인데, git 상태 같은 정보를 미리 계산해 두어 모델과의 불필요한 왕복을 줄이고 실행을 빠르게 만든다고 설명했다. 이 커맨드들은 .claude/commands/에 들어가고 git에 함께 체크인된다고 한다.
Claude Code 문서에 따르면 기존 사용자 정의 명령어는 이제 skills로 통합되어 .claude/commands/나 .claude/skills/ 형태로 계속 사용할 수 있고, 관련이 있을 때 자동으로 로드되거나 직접 /skill-name으로 호출할 수 있다. 이 구조가 의미하는 건 명확하다. 반복 프롬프트는 장인의 손맛이 아니라 자동화 대상이라는 것이다. 잘 쓰는 사람일수록 자주 하는 작업을 채팅창에 다시 입력하지 않는다. 명령이나 skill로 박아 넣고, 사람은 더 상위의 판단만 한다.
하나의 Claude에게 다 시키지 않고, 역할을 나눈다
그는 자주 쓰는 subagent도 몇 개 소개했다. 예를 들어 code-simplifier는 작업이 끝난 뒤 코드를 단순화하고, verify-app은 Claude Code를 end-to-end로 검증하는 데 필요한 상세 지침을 갖고 있다고 했다. 공식 문서에서도 subagent는 고유한 목적, 도구 접근 권한, 시스템 프롬프트를 갖는 격리된 역할로 만들 수 있으며, 프로젝트별로 공유 가능하다고 설명한다. 즉 그는 Claude를 하나의 뭉뚱그린 “만능 비서”처럼 쓰는 게 아니라, 작업별로 역할을 분화한 팀처럼 쓰고 있다.
여기에 hooks도 붙인다. Boris는 PostToolUse hook으로 Claude가 수정한 코드를 포맷한다고 했고, 공식 문서는 hooks를 Claude Code 생명주기의 특정 지점에서 자동 실행되는 결정론적 동작이라고 설명한다. 이는 LLM이 “알아서 포맷할 거야”라고 기대하는 대신, 기계적으로 반드시 일어나야 하는 일은 hook으로 강제한다는 뜻이다. 잘 쓰는 방식이란 결국, 판단이 필요한 일과 기계적으로 처리해야 할 일을 구분하는 방식이기도 하다.
안전장치도 감으로 두지 않고 팀 설정으로 관리한다
흥미롭게도 Boris는 평소에는 --dangerously-skip-permissions를 쓰지 않는다고 했다. 대신 /permissions로 자신의 환경에서 안전하다고 아는 공통 Bash 명령을 미리 허용해 두고, 그중 많은 설정을 .claude/settings.json에 넣어 팀과 공유한다고 말했다. Claude Code 문서도 project scope가 팀이 공유하는 permissions, hooks, MCP servers를 표준화하기에 적합하다고 안내한다.
이 사용법이 좋은 이유는 단순하다. 권한은 그때그때 기분으로 누르는 버튼이 아니라 팀 차원에서 설계해야 하는 운영 규칙이기 때문이다. 물론 그는 아주 오래 걸리는 작업에서는 샌드박스 안에서 더 느슨한 permission mode를 써서 Claude가 막히지 않게 하기도 한다. 하지만 기본 방향은 분명하다. 멋있어 보인다고 안전장치를 끄는 게 아니라, 어디까지 허용할지 미리 구조화하는 것이 더 성숙한 사용법이다.
Claude를 “답변기”가 아니라 “도구 사용자”로 만든다
Boris는 Claude Code가 Slack MCP 서버를 통해 Slack을 검색하고 글을 올리며, bq CLI로 BigQuery 질의를 날리고, Sentry에서 에러 로그를 가져오는 식으로 자기 도구를 대신 써준다고 했다. 문서도 Claude에게 필요한 컨텍스트를 직접 설명하려 들기보다, Bash 명령이나 MCP, 파일 읽기, CLI 도구를 통해 Claude가 스스로 사실을 가져오게 하라고 권한다. 외부 서비스와의 상호작용에는 gh, aws, gcloud, sentry-cli 같은 CLI 도구가 문맥 효율이 좋다고도 설명한다.
이건 Claude Code를 잘 쓰는 방식의 핵심을 잘 보여준다. 좋은 사용자는 AI에게 더 긴 설명을 주지 않는다. 대신 현실 세계와 연결된 도구 접근권을 준다. 답을 “생성”하게 하는 대신, 로그를 읽고, 쿼리를 날리고, 브라우저를 열고, 실제 시스템 상태를 확인하게 만든다. 결국 에이전트의 품질은 모델의 지능만이 아니라, 얼마나 현실과 직접 연결돼 있는가에 달려 있다.
마지막 승부처는 언제나 검증 루프다
Boris가 남긴 마지막 팁은 오히려 가장 본질적이다. 그는 Claude에게 자기 작업을 검증할 방법을 반드시 줘야 한다고 말했고, 이런 피드백 루프가 있으면 결과 품질이 2~3배 좋아진다고 했다. 실제로 그는 claude.ai/code에 반영되는 모든 변경을 Claude in Chrome 확장으로 테스트하게 만들고, 브라우저를 열어 UI를 확인하고, 코드가 동작하고 UX가 좋아질 때까지 반복하게 한다고 적었다.
공식 문서도 같은 얘기를 한다. Chrome 통합은 웹 앱 테스트, 콘솔 로그 기반 디버깅, 브라우저 자동화에 쓰일 수 있고, 모범 사례 문서는 UI 변경은 브라우저 확장으로 검증할 수 있으며, 테스트 스위트·린터·Bash 체크 같은 확실한 검증 수단에 투자하라고 권장한다. 결국 Claude Code를 만든 사람이 Claude Code를 쓰는 핵심은 “좋은 프롬프트”가 아니라 좋은 검증 루프다. 코드 생성보다 더 중요한 건, 그 코드가 진짜로 맞는지 스스로 확인하게 만드는 구조다.
결론
Boris Cherny의 사용법을 한 문장으로 줄이면 이렇다.
Claude Code를 잘 쓰는 사람은 Claude를 똑똑한 타이핑 도구로 쓰지 않는다. 작은 엔지니어링 조직처럼 운영한다.
병렬 세션을 돌리고, 계획을 먼저 세우고, CLAUDE.md로 팀의 기억을 쌓고, 반복 작업은 명령과 skill로 굳히고, 역할은 subagent로 나누고, hook으로 기계적 품질을 강제하고, Slack·BigQuery·Sentry 같은 실제 도구에 연결하고, 마지막엔 반드시 검증시킨다. 그가 공개한 세팅의 핵심은 “숨겨진 비밀 프롬프트”가 아니라, 에이전트를 운영하는 시스템이었다.
