Claude Code 창시자의 vanilla 설정에 숨은 7가지 시스템

Vanilla(바닐라) 는 소프트웨어 분야에서 "기본값(default)" 또는 "추가 커스터마이징 없는 순수한 상태"를 의미한다. 원래 바닐라는 순수하고 담백한 맛을 뜻하는 데에서 유래했다.

Boris Cherny는 일하는 동안 터미널 5개를 동시에 열어둔다. 거기에 웹 세션 5~10개를 더 띄우고, 출근길에는 모바일 앱으로 작업을 트리거한다. 합치면 평균 10~15개의 Claude가 동시에 돌아간다. 그렇게 그는 하루에 PR을 10~30개씩 보낸다.

흥미로운 건 본인이 X에 올린 첫 문장이다. “내 설정은 놀랍게도 vanilla(기본)에 가깝다.” 850만 뷰를 모은 이 스레드를 한 줄로 요약하면 그렇다. 그런데 트윗 13개를 끝까지 읽고 나면 정반대 결론에 도달한다. 이건 vanilla가 아니다. 7개의 패턴이 서로 맞물려 작동하는, 꽤 정교한 시스템이다.

Claude Code는 어쩌다 GitHub 커밋의 4%가 됐을까

Claude Code의 성장 속도는 이상할 정도로 빠르다. 출시 1년 만에 GitHub 공개 커밋의 약 4%(2026년 3월 기준 일일 13.5만 건 이상)를 차지한다. run-rate 수익은 $1B를 찍은 뒤 $2.5B로 올라섰다. Anthropic 내부 엔지니어 생산성은 약 70% 늘었고, 그 와중에 인력은 3배가 됐다.

이미지 출처: https://newsletter.semianalysis.com/p/claude-code-is-the-inflection-point

도구 자체가 좋아서 그런가. 부분적으로는 맞다. 하지만 도구가 좋다고 사용자가 자동으로 잘 쓰는 건 아니다. Boris의 트윗이 850만 뷰를 모은 진짜 이유는, 그가 도구를 어떻게 쓰는지를 공개했기 때문이다. 같은 Claude Code를 깔아놓고도 결과 차이가 큰 이유가 거기에 있다.

Menlo Ventures의 2025 State of GenAI 리포트에 따르면 Claude Code는 AI 코딩 시장의 50% 이상을 점유한다. Netflix·Uber·Spotify·Shopify·Ramp·Snowflake가 이미 채택했다(Lenny’s Newsletter). 이 정도면 단순 도구 보급이 아니라 엔지니어링 운영 방식 자체가 바뀌고 있다고 봐야 한다.

패턴 1·2·3 — 병렬 세션, 그리고 멘탈 모델의 전환

가장 먼저 눈에 띄는 건 숫자다. 터미널 5개에 번호를 매기고, 시스템 알림으로 어느 Claude가 입력을 기다리는지 파악한다. Boris의 X 원문 그대로다.

Boris 의 X 트윗 스크린샷

처음 들으면 무리수 같다. 5개 터미널을 어떻게 동시에 보지. 그런데 이 패턴의 핵심은 ‘동시에 보는 것’이 아니라 ‘필요할 때만 보는 것’이다. 알림이 울리지 않는 동안 그 세션은 알아서 일하고 있다.

환경용도비고
로컬 터미널 5개PR 작성 등 중요 작업각 세션이 자체 git checkout 사용
웹 세션 5~10개짧은 변경, 빠른 작업약 10~20%가 예기치 않게 중단됨
모바일 앱출근길 트리거30~60분 압축 활용

각 세션이 자체 git checkout을 쓴다는 게 중요하다. 같은 폴더에서 여러 Claude가 동시에 파일을 건드리면 충돌이 난다. 분리된 worktree에서 돌리면 PR 작성 충돌이 사라진다. InfoQ는 원격 세션의 약 10~20%가 예상치 못한 상황으로 중단된다고 보고한다. 그래서 중요한 작업은 로컬 우선이다.

여기서 멘탈 모델의 전환이 일어난다. DEV Community의 분석이 정곡을 찌른다. AI를 ‘도구’가 아니라 ‘스케줄링 가능한 용량(schedulable capacity)’으로 본다는 점이다. 이 모델에서 병목은 모델의 처리 속도가 아니라 사람의 주의 배분이다.

극단적인 사례도 있다. Anthropic 엔지니어 Daisy는 주말에 Claude 20개를 동시에 오케스트레이션해 플러그인을 빌드했다고 한다. 수동 코딩에서 에이전트 오케스트레이션으로 일의 본질이 바뀐 셈이다.

물론 모든 사람이 처음부터 10개를 굴려야 하는 건 아니다. XDA Developers는 Boris의 설정을 직접 따라 해보고 “3~4개 병렬 세션만으로도 생산성이 놀라운 수준으로 올랐다”고 보고한다. 1개에서 시작해 자기 한계를 보면서 늘리는 게 현실적이다.

세 번째 패턴은 의외로 사소해 보이지만 효과가 크다. 일과를 책상 앞이 아니라 모바일에서 시작한다는 점이다. 출근 전에 모바일 앱으로 여러 에이전트를 시작해두고, 사무실에 도착하면 상태 확인부터 한다. 30~60분의 출근 시간이 작업 시간으로 변환된다.

패턴 4·5 — Opus 4.5 with thinking, 그리고 Plan Mode

Boris의 모델 선택 철학은 직관에 반한다. 모든 작업에 Opus 4.5 with thinking을 쓴다. 더 작고 빠른 Sonnet이 있는데도 그렇다.

이유가 흥미롭다. “Opus가 더 크고 느리지만, 덜 손봐도 되고 도구 사용에 능숙하기 때문에 결국 더 빠르다”는 거다. 단일 응답 속도가 아니라 전체 반복 비용을 최적화하는 관점이다.

이 차이가 왜 중요한가. 작은 모델로 빠른 답을 받았는데 그게 틀린 답이라면, 다시 묻고 고치고 검증하는 사이클이 돈다. 한 번에 정확한 답이 끝까지 가는 비용보다 그 사이클이 더 비싸다. Substack의 Product with Attitude는 이를 “느린 정확한 답이 빠른 잘못된 답보다 전체 비용이 낮다”로 정리한다.

다섯 번째 패턴은 가장 자주 인용되는 부분이다. 대부분의 세션은 Plan mode(Shift+Tab 두 번)로 시작한다. PR을 쓰는 게 목표라면 Plan mode에서 Claude와 계획을 주고받다가, 마음에 들면 auto-accept edits로 전환한다(Shift+Tab 한 번). 그러면 보통 한 번에 끝낸다. 좋은 계획이 정말로 중요하다.

모드진입 방법동작
Plan modeShift+Tab × 2읽기 전용. 계획 검토 후 수동 승인
Auto-accept editsShift+Tab × 1권한 프롬프트 없이 파일 편집
기본 모드(기본)매 작업마다 권한 확인

여기서 의미 있는 건 단축키 자체가 아니라, 두 모드를 의식적으로 오가는 습관이다. 계획을 명확히 하지 않고 auto-accept로 들어가면 의도하지 않은 변경 40개가 한꺼번에 일어날 수 있다. 반대로 Plan mode에만 머물면 진척이 안 난다.

심화 패턴 하나를 덧붙일 수 있다. ‘이중 Claude 검토’다. 한 Claude가 계획 초안을 짜고, 다른 Claude가 시니어 엔지니어 시각으로 결함을 지적한다. 단일 LLM이 자기 글을 비평하기 어려운 한계를, 다른 세션을 띄워 우회하는 방식이다.

패턴 6 — CLAUDE.md, AI에게 만들어주는 외부 메모리

이 글에서 가장 강조하고 싶은 부분이다. Boris의 표현을 그대로 옮긴다. “Claude Code 팀은 전체 저장소에 대해 단일 CLAUDE.md를 공유한다. git에 체크인되어 있고, 팀 전체가 일주일에 여러 번 기여한다. 핵심 관행은 이거다 — Claude가 뭔가 잘못하는 걸 볼 때마다 CLAUDE.md에 추가해서, 다음번에는 그러지 않게 만든다.“

이 패턴의 위력은 AI의 본질적 약점인 ‘망각성’을 외부 메모리로 우회한다는 데 있다. Claude는 매 세션마다 백지 상태로 시작한다. 어제 알려준 규칙이 오늘은 사라져 있다. 그런데 CLAUDE.md는 다르다. 이 파일은 매 세션 시작에 자동으로 읽힌다. 즉, 파일 시스템이 모델의 영구 기억 역할을 한다.

비유하자면 이렇다. 매일 출근하는 신입 사원이 있는데, 매일 아침마다 기억을 다 잃는다고 가정하자. 평범한 회사라면 망한다. 하지만 모든 규칙과 어제의 실수를 적어둔 매뉴얼이 책상 위에 있고, 신입은 출근하자마자 그걸 다 외운 다음 일을 시작한다면 어떨까. 매일 다른 사람이 와도 같은 품질이 유지된다. CLAUDE.md가 정확히 그 매뉴얼이다.

운영 메트릭도 구체적이다. InfoQ에 따르면 Boris의 실제 CLAUDE.md는 약 2,500 토큰 수준이다. 무한정 비대해지지 않는다는 게 중요하다. 핵심 규칙만 압축적으로 유지한다.

복리 효과는 시간이 갈수록 커진다. Mindwired AI는 “CLAUDE.md 축적으로 6개월 후에는 초기 팀보다 오류율이 현저히 낮아진다”고 분석한다. 한 번 정리해두면 그 규칙은 모든 세션, 모든 팀원, 모든 미래 시점에 적용된다. 프롬프트를 매번 새로 짜는 것과는 비교가 안 된다.

GitHub Action 통합은 한 발 더 나간다. 코드 리뷰 중 PR에서 @.claude를 태그하면 그 리뷰 내용이 CLAUDE.md에 자동으로 추가된다. 코드 리뷰가 단순 버그 잡기에서 ‘프로세스 개선 메타 작업’으로 격상된다. 같은 실수를 반복할 일이 없어진다는 뜻이다.

패턴 7 — 자동화 4종 세트

Boris 워크플로우에서 가장 구체적이고 따라 하기 쉬운 부분이다. 슬래시 명령, 서브에이전트, 훅, 권한 — 네 가지가 서로 보완하며 작동한다.

슬래시 명령 — 매일 반복하는 동작을 한 줄로

하루에 여러 번 반복하는 워크플로우는 모두 슬래시 명령으로 만든다. 명령은 git에 체크인되어 .claude/commands/에 있다. Boris와 Claude는 /commit-push-pr 명령을 하루에 수십 번 사용한다.

GitHub 0xquinto/bcherny-claude 저장소에 정리된 그의 실제 명령은 다음과 같다(GitHub).

명령용도
/commit-push-pr커밋 + 푸시 + PR 오픈 (가장 자주)
/quick-commit빠른 커밋
/test-and-fix테스트 실행 후 자동 수정
/review-changes변경사항 검토
/worktree병렬 세션용 git worktree 생성
/grill대립적(adversarial) 코드 검토
/techdebt중복·미사용 코드 정리

명령에 인라인 bash를 포함시켜 컨텍스트를 미리 계산하는 게 팁이다. 예컨대 git status를 명령 안에서 미리 실행해두면 Claude가 매번 상태를 다시 묻지 않는다. 왕복이 줄어든다.

서브에이전트 — 코딩을 파이프라인으로 분해

서브에이전트는 슬래시 명령과 비슷하지만 한 단계 위다. PR 작성에 필요한 가장 흔한 워크플로우들을 자동화한다고 보면 된다. Boris가 자주 쓰는 서브에이전트는 6종이다.

서브에이전트역할
code-simplifierClaude 작업 완료 후 코드 단순화
code-architect아키텍처 설계 검토
verify-app애플리케이션 엔드투엔드 테스트
build-validator빌드 검증
oncall-guide프로덕션 이슈 진단
staff-reviewer회의론적 검토자 역할

DEV Community의 정리가 깔끔하다. 코딩을 파이프라인으로 본다는 거다. 명세 → 초안 → 단순화 → 검증, 각 단계마다 다른 에이전트가 붙는다. 단순 병렬화가 아니라 전문화된 역할 분업이다.

PostToolUse 훅 — 마지막 10%를 자동으로 메우는 장치

Boris는 PostToolUse 훅으로 Claude가 쓴 코드를 자동 포매팅한다. 이유는 솔직하다. “Claude가 보통은 잘 포매팅된 코드를 뽑지만, 마지막 10%에서 포매팅 오류가 나서 CI에서 깨지는 걸 막기 위해서”다.

paddo.dev에 정리된 실제 훅 명령은 한 줄이다. bun run format || true. 매처는 Write|Edit로 설정해서, 파일을 쓰거나 편집할 때마다 자동으로 포매터가 돈다. 단순하지만 효과가 크다.

권한 — 위험한 우회 대신 명시적 사전 허용

권한에 대한 Boris의 입장은 단호하다. --dangerously-skip-permissions은 쓰지 않는다. 대신 /permissions로 안전하다고 판단한 bash 명령을 미리 허용한다. 그렇게 하면 불필요한 권한 프롬프트가 사라지면서도 안전 경계가 유지된다.

핵심은 이 설정이 .claude/settings.json에 들어가서 git에 체크인되고 팀과 공유된다는 점이다. AI 에이전트의 자율성을 확장하면서도 명시적 안전 경계를 팀 단위로 거버넌스한다. 이건 단순한 개인 워크플로우 팁이 아니라 조직적 보안 모델이다.

여기에 MCP(Model Context Protocol) 통합이 더해진다. Claude Code가 Slack에 검색·게시하고, BigQuery 쿼리를 돌리고, Sentry에서 에러 로그를 가져온다. .mcp.json도 git에 체크인되어 팀 전체가 같은 통합을 공유한다. ‘내 환경에서는 되는데 네 환경에서는 안 된다’는 문제가 구조적으로 사라진다.

가장 중요한 한 가지 — 검증 피드백 루프

Boris는 트윗 마지막에 가장 강한 진술을 남긴다. 옮기면 이렇다. “Claude Code에서 좋은 결과를 얻기 위한 단 하나의 가장 중요한 것은, Claude에게 자기 작업을 검증할 방법을 주는 것이다. 이런 피드백 루프를 주면 최종 결과 품질이 2~3배 향상된다.”

2~3배. 이 숫자가 핵심이다. 검증 인프라가 없으면 AI 결과는 ‘그럴듯하지만 신뢰 불가’한 카테고리에 머문다. 있으면 사람이 손대지 않아도 되는 결과가 나온다. 도메인별 검증 방법은 다음과 같이 정리된다.

도메인검증 방법
코드테스트 스위트 + 빌드 명령 (npm test, cargo test)
웹앱브라우저 테스팅 (Claude Chrome 확장으로 UI 자동 테스트)
모바일휴대폰 시뮬레이터
데이터/분석BigQuery 쿼리 결과 검증

verify-app 서브에이전트의 핵심 동작은 단순하다. 검증을 통과하기 전에는 작업을 완료로 표시하지 않는다. 게이트키퍼다. 이 패턴이 있어야 자율성이 신뢰로 바뀐다.

DEV Community는 결국 AI 신뢰성의 기초를 다섯 요소로 정리한다. 전문화 도구, 외부 메모리, 사전 계획, 책임 있는 팀 통합, 검증 루프. 다섯 중 하나라도 빠지면 시스템이 허약해진다는 뜻이다.

그래서, 오늘 뭘 시작할까

Boris의 워크플로우 전체를 한 번에 따라잡으려고 하면 압도된다. 시작점은 단순해야 한다. Mindwired AI가 정리한 ‘즉시 시작 3단계’가 현실적이다.

Step 1 — CLAUDE.md 생성 (15분이면 된다). 프로젝트 루트에서 /init을 실행해 초기 파일을 만든다. 첫 5개 규칙부터 시작한다. 이후 Claude가 실수할 때마다 한 줄씩 추가한다.

Step 2 — Plan Mode 습관화. 매 세션 시작 때 Shift+Tab을 두 번 누른다. 계획에 동의한 후 한 번 더 눌러 auto-accept edits로 전환한다.

Step 3 — 첫 슬래시 명령 만들기. 하루 3회 이상 반복하는 작업을 .claude/commands/에 저장한다. /commit-push-pr이 출발점으로 좋다.

Step 4 (1주일 후) — 병렬 세션 점진 확장. 1개에서 3~5개로 늘린다. XDA Developers 사례처럼 3~4개만 돼도 체감 차이가 크다.

Step 5 (1개월 후) — 검증 루프 표준화. 최소 1개의 자동 테스트 명령을 CLAUDE.md에 명시한다. 예: “PR 작성 후 반드시 npm test 실행 후 통과 확인.”

회피해야 할 함정도 명확하다. --dangerously-skip-permissions는 절대 쓰지 않는다. /permissions로 안전한 명령을 사전 허용하는 방식이 표준이다. 터미널은 Boris와 팀이 권장하는 Ghostty가 좋다 — 빠른 렌더링이 강점이다.

이 글에 동의하지 않을 수 있는 부분도 있다. ‘코딩이 해결되었다’는 명제는 Spotify 사례 한 건으로 일반화하기엔 위험하다. 보안·금융·의료처럼 규제가 강한 도메인에서는 검증 인프라를 더 두껍게 깔아야 한다. 모든 도메인이 동일한 자율성을 누릴 수 있는 건 아니다.

마무리

Boris의 ‘vanilla’ 설정은 사실 시스템 사고의 결과다. 커스터마이징을 적게 하면서도 정교한 시스템을 만든다는 게 모순처럼 들리지만, 7개 패턴이 서로 강화하면 추가 커스터마이징이 필요 없어진다.

기억할 한 줄을 고르라면 이거다. CLAUDE.md 파일 하나 제대로 쓰는 게 프롬프트 10개 짜는 것보다 낫다. AI 도입의 핵심 KPI는 ‘도입률’이 아니라 ‘검증 인프라 성숙도’여야 한다는 게 Boris 주장의 본질이다.

마지막으로 Boris 본인의 첫 문장을 옮긴다. “Claude Code를 쓰는 단 하나의 옳은 방법은 없다. 우리는 의도적으로, 사용자가 원하는 대로 쓰고 커스터마이징하고 해킹할 수 있게 만들었다.” 자기만의 시스템을 실험하고 축적하는 것이 본질이다.

비슷한 워크플로우를 시도해본 적이 있다면 어떤 패턴이 가장 효과적이었는지 궁금하다. 7개 중 하나만 골라야 한다면, 어디서 시작할 것 같은가.

참고 자료

태그

관련 게시물