Boris Cherny의 Claude Code 실전 사용법 완전 가이드

게시 2026/01/03 업데이트 2026/01/31

By BLUEBUG

60 분읽는 시간

서론: Claude Code 창시자가 직접 공개한 실제 업무 방식

Boris Cherny는 Claude Code의 창시자이자 Anthropic의 Head of Claude Code로서, 2025년 다수의 인터뷰와 공식 블로그를 통해 실전 사용법과 베스트 프랙티스를 공개했습니다. 많은 사람들이 Claude Code를 어떻게 활용해야 할지 궁금해하는 가운데, 그는 자신의 설정이 “놀랍도록 평범할 수 있다”고 전제하면서도, 그 안에는 수년간의 AI 기반 개발 경험이 녹아있는 깊이 있는 통찰이 담겨 있습니다.

Boris는 Claude Code가 기본 설정만으로도 충분히 강력하게 작동하도록 설계되었기 때문에 자신은 크게 커스터마이징하지 않는다고 말합니다. 하지만 그가 강조하는 것은 “정답은 없다”는 점입니다. Claude Code 팀의 각 구성원조차도 모두 다른 방식으로 사용하고 있으며, 이는 의도적인 설계 철학입니다. 도구를 사용하고, 커스터마이징하고, 해킹하는 방식은 각자의 워크플로우에 맞게 자유롭게 선택할 수 있도록 만들어졌습니다.

그럼에도 불구하고 Boris의 사용법은 Claude Code의 잠재력을 최대한 끌어내는 방법에 대한 실질적인 로드맵을 제공합니다. 특히 팀 전체가 CLAUDE.md를 통해 집단 지성을 구축하는 방식, Opus 4.5 모델을 전략적으로 활용하는 접근법, 그리고 검증 중심의 개발 철학은 현대 AI 기반 개발의 핵심 원칙을 보여줍니다.

대규모 병렬 실행: 생산성의 새로운 차원

Boris의 첫 번째 특징은 놀라울 정도로 많은 수의 Claude 인스턴스를 동시에 실행한다는 점입니다. 그는 터미널에서 5개의 Claude를 병렬로 실행하며, 각 탭에 1번부터 5번까지 번호를 매겨 관리합니다. 단순히 여러 개를 띄워놓는 것이 아니라, iTerm2의 시스템 알림 기능을 활용하여 각 Claude가 사용자 입력을 필요로 할 때 자동으로 알림을 받습니다. 이는 공식 문서 Terminal Configuration에 상세히 설명되어 있는 기능입니다.

터미널에서의 5개 인스턴스에 더해, Boris는 claude.ai/code 웹 인터페이스에서 추가로 5에서 10개의 Claude를 동시에 실행합니다. 즉, 총 10에서 15개의 Claude가 동시에 서로 다른 작업을 수행하고 있는 셈입니다. 이는 일반적인 개발자의 상상을 뛰어넘는 규모이지만, Boris는 이것이 자연스러운 워크플로우라고 설명합니다.

웹에서 작업하다가 로컬 터미널로 세션을 가져오고 싶을 때는 --teleport 명령어를 사용합니다. 웹 인터페이스의 “Open in CLI” 버튼을 클릭하면 나타나는 명령어를 로컬에서 실행하여 채팅 기록과 작업 컨텍스트를 그대로 이어받을 수 있습니다. 현재는 웹→로컬 방향만 공식 지원되며, 로컬→웹 전환은 향후 기능으로 논의되고 있습니다.

더 흥미로운 점은 모바일 활용입니다. Boris는 매일 아침과 하루 중 틈틈이 iPhone의 Claude iOS 앱에서 여러 세션을 시작합니다. 이렇게 시작된 세션들은 모바일에서 진행되며, 그는 나중에 데스크톱 웹 인터페이스에서 동일한 세션들을 열어 작업을 계속하거나 결과를 검토합니다. 이는 “항상 켜져 있는(always-on)” 개발 환경을 구현한 것으로, 이동 중이나 회의 중에도 AI가 지속적으로 작업을 진행할 수 있게 합니다.

이러한 병렬 실행 전략의 핵심은 단순히 많은 작업을 동시에 처리하는 것이 아닙니다. 각 Claude 인스턴스는 서로 다른 문제를 독립적으로 해결하면서, 개발자는 전체 흐름을 오케스트레이션하는 역할을 합니다. 이는 전통적인 “한 번에 하나의 작업” 방식에서 “여러 작업을 동시에 관리”하는 패러다임으로의 전환을 의미합니다.

Opus 4.5 전략: 크고 느린 것이 결과적으로 더 빠르다

Boris의 두 번째 핵심 전략은 모든 작업에 Opus 4.5 with thinking을 사용한다는 점입니다. 이는 언뜻 비효율적으로 보일 수 있습니다. Opus 4.5는 Sonnet보다 훨씬 크고 느린 모델입니다. 응답을 생성하는 데 더 많은 시간이 걸리고, API 비용도 더 많이 듭니다. 일반적인 생각으로는 간단한 작업에는 Sonnet을, 복잡한 작업에만 Opus를 사용하는 것이 합리적으로 보입니다.

하지만 Boris는 정반대의 접근을 취합니다. 그는 Opus 4.5를 “지금까지 사용해본 최고의 코딩 모델”이라고 평가하며, 모든 작업에 이 모델을 사용합니다. 그 이유는 역설적이지만 명확합니다. Opus는 한 번에 정확하게 작업을 수행하기 때문에, 개발자가 모델을 조정하거나 재시도하는 빈도가 현저히 낮습니다. 또한 tool use(도구 사용) 능력이 뛰어나 복잡한 작업을 더 효율적으로 처리합니다.

작은 모델을 사용하면 초기 응답은 빠를 수 있지만, 종종 여러 번의 수정과 재시도가 필요합니다. “코드를 다시 작성해줘”, “이 부분이 잘못되었어, 수정해줘”, “다른 접근 방식으로 시도해봐”와 같은 반복적인 프롬프팅이 발생합니다. 이러한 왕복 과정을 모두 합산하면, 결과적으로 Opus를 사용하는 것보다 더 많은 시간이 소요됩니다.

Boris의 이러한 전략은 “총 소유 비용(Total Cost of Ownership)” 관점에서 AI 모델을 평가해야 함을 시사합니다. 단순히 응답 속도나 토큰당 비용만 보는 것이 아니라, 작업 완료까지의 전체 시간, 개발자의 개입 빈도, 최종 코드의 품질 등을 종합적으로 고려해야 합니다. Opus 4.5의 “thinking” 기능은 모델이 응답 전에 내부적으로 추론 과정을 거치게 하여, 더욱 신중하고 정확한 결과를 생성합니다.

이는 또한 AI 기반 개발에서 “최적화”의 의미가 달라지고 있음을 보여줍니다. 과거에는 코드 실행 속도나 메모리 사용량을 최적화했다면, 이제는 개발자와 AI 간의 상호작용 효율성을 최적화해야 합니다. 한 번의 정확한 실행이 여러 번의 빠른 시도보다 낫습니다.

팀 학습 시스템: CLAUDE.md를 통한 집단 지성 구축

Boris의 사용법 중 가장 혁신적이고 영향력 있는 부분은 바로 팀 전체가 공유하는 CLAUDE.md 파일 관리 방식입니다. 이것은 단순한 설정 파일이 아니라, 팀의 집단 지성을 AI에게 전달하는 살아있는 문서입니다.

Claude Code 팀은 전체가 하나의 CLAUDE.md 파일을 공유하며, 이 파일은 Git 저장소에 체크인되어 버전 관리됩니다. 팀원들은 일주일에 여러 번 이 파일에 기여하는데, 그 방식이 특히 주목할 만합니다. Claude가 무언가를 잘못 수행할 때마다, 즉시 CLAUDE.md에 해당 내용을 추가합니다. “다음번에는 이렇게 하지 마”라는 명시적인 가이드라인을 남기는 것입니다.

예를 들어, Claude가 특정 패턴의 코드를 생성할 때 팀의 코딩 컨벤션을 위반했다면, 그 즉시 CLAUDE.md에 “우리 팀은 이런 경우 저런 패턴을 사용한다”는 규칙을 추가합니다. Claude가 테스트를 작성할 때 중요한 엣지 케이스를 놓쳤다면, “테스트 작성 시 반드시 이러한 케이스를 포함할 것”이라는 지침을 추가합니다. 이는 일종의 “실시간 학습 루프”입니다.

더 인상적인 것은 코드 리뷰 프로세스와의 통합입니다. Boris는 동료들의 Pull Request를 검토할 때, GitHub에서 @.claude를 태깅하여 CLAUDE.md에 무언가를 추가하도록 요청합니다. 이는 Claude Code의 GitHub Action(/install-github-action)을 활용한 것으로, PR의 일부로 CLAUDE.md를 업데이트할 수 있습니다.

이 접근법은 Dan Shipper가 제안한 “Compounding Engineering” 개념의 실제 구현입니다. Compounding Engineering이란 개발 과정에서 얻은 인사이트와 패턴을 지속적으로 축적하여, 시간이 지날수록 개발 효율성이 복리처럼 증가하는 것을 의미합니다. 전통적인 개발에서는 각 개발자가 개인적으로 경험을 축적하지만, CLAUDE.md 방식에서는 팀 전체의 경험이 하나의 문서에 집약되고, 이것이 모든 팀원의 Claude에게 즉시 반영됩니다.

Anthropic의 다른 팀들도 각자의 CLAUDE.md를 유지 관리합니다. 각 팀은 자신들의 도메인 지식과 코딩 스타일, 특수한 요구사항을 CLAUDE.md에 담아냅니다. 이는 조직 전체의 지식이 분산되면서도 각 팀의 자율성이 보장되는 구조입니다.

이 시스템의 진정한 가치는 “실수로부터 배우는 문화”를 기술적으로 구현했다는 점입니다. 실수는 더 이상 부끄러운 것이 아니라, 팀 전체가 발전할 수 있는 기회가 됩니다. 누군가 Claude와 작업하다가 문제를 발견하면, 그것을 CLAUDE.md에 추가함으로써 같은 실수가 반복되지 않도록 합니다. 이는 버그 트래킹 시스템과 유사하지만, 훨씬 더 즉각적이고 맥락적입니다.

또한 이는 온보딩 프로세스를 혁신적으로 개선합니다. 새로운 팀원이 합류하면, 그들의 Claude는 이미 팀의 수년간 축적된 지식을 갖고 있습니다. 신입 개발자가 시니어 개발자처럼 코드를 작성할 수 있는 이유는, Claude가 시니어들의 집단 지성을 학습했기 때문입니다.

계획 중심 워크플로우: Plan Mode의 전략적 활용

Boris의 네 번째 핵심 원칙은 대부분의 세션을 Plan Mode로 시작한다는 것입니다. Plan Mode는 Shift+Tab을 두 번 눌러 활성화할 수 있으며, Claude가 코드를 직접 작성하기 전에 먼저 상세한 계획을 수립하도록 합니다.

이 접근법의 철학은 명확합니다. “좋은 계획이 정말 중요하다(A good plan is really important!)”는 Boris의 강조는 소프트웨어 엔지니어링의 오래된 진리를 AI 시대에 재적용한 것입니다. 전통적인 개발에서도 설계가 구현보다 선행해야 하듯이, AI 기반 개발에서도 마찬가지입니다.

Boris의 전형적인 워크플로우는 다음과 같이 진행됩니다. Pull Request를 작성해야 할 때, Plan Mode를 활성화하고 Claude와 계획에 대해 논의합니다. “이 기능을 구현하려면 어떤 파일들을 수정해야 하는가?”, “각 단계의 순서는 어떻게 되어야 하는가?”, “어떤 엣지 케이스를 고려해야 하는가?” 등을 Claude와 왕복하며 다듬습니다.

계획이 만족스러운 수준에 도달하면, 그때 auto-accept edits mode로 전환합니다. 이 모드에서는 Claude가 제안하는 모든 편집을 자동으로 수락하므로, 개발자의 개입 없이 계획을 빠르게 실행할 수 있습니다. Boris는 이렇게 하면 Claude가 대부분의 경우 “one-shot”으로 작업을 완료할 수 있다고 말합니다. 즉, 한 번의 실행으로 올바른 결과를 얻습니다.

이것이 가능한 이유는 계획 단계에서 모호함과 불확실성을 제거했기 때문입니다. Claude는 정확히 무엇을 해야 하는지, 어떤 순서로 해야 하는지, 어떤 제약 조건을 고려해야 하는지 명확히 알고 있습니다. 따라서 실행 단계에서는 기계적으로 계획을 코드로 변환하기만 하면 됩니다.

이는 “측정 두 번, 자르기 한 번(measure twice, cut once)”이라는 목수의 격언과 유사합니다. 계획 단계에서 충분한 시간을 투자하면, 실행 단계는 훨씬 빠르고 정확해집니다. 반대로 계획 없이 바로 코딩을 시작하면, 여러 번의 수정과 재작업이 필요하게 됩니다.

Plan Mode의 또 다른 이점은 개발자가 고수준의 사고에 집중할 수 있다는 점입니다. 세부적인 구문이나 API 사용법 대신, 전체 아키텍처와 로직 흐름에 대해 생각할 수 있습니다. 이는 개발자의 역할이 “코드 작성자”에서 “소프트웨어 설계자”로 변화하고 있음을 보여줍니다.

워크플로우 자동화: Slash Commands와 Subagents

Boris는 반복적으로 수행하는 모든 내부 루프 워크플로우를 slash commands로 만들어 사용합니다. 이는 단순히 타이핑을 줄이는 것 이상의 의미를 갖습니다. 프롬프팅의 일관성을 보장하고, Claude 자신도 이러한 워크플로우를 사용할 수 있게 합니다.

Commands는 Git 저장소의 .claude/commands/ 디렉토리에 체크인되어 팀 전체가 공유합니다. 예를 들어, Boris와 그의 팀은 /commit-push-pr이라는 slash command를 매일 사용합니다. 이 명령어는 커밋 메시지를 생성하고, 코드를 푸시하고, Pull Request를 생성하는 전체 프로세스를 자동화합니다.

특히 주목할 만한 기법은 inline bash의 활용입니다. 공식 문서 Slash Commands에 설명된 대로, slash command 내에서 bash 명령을 사전 실행하여 필요한 정보를 미리 계산할 수 있습니다. 예를 들어, git status를 미리 실행하여 변경된 파일 목록을 확인하고, 이 정보를 프롬프트에 포함시킵니다. 이렇게 하면 Claude가 정보를 얻기 위해 별도의 도구 호출을 하지 않아도 되므로, 전체 실행 속도가 크게 향상됩니다.

Subagents는 또 다른 수준의 자동화를 제공합니다. Boris는 정기적으로 사용하는 여러 subagents를 유지하는데, 예를 들어 code-simplifier는 Claude가 작업을 완료한 후 코드를 단순화하고, verify-app은 Claude Code를 end-to-end로 테스트하는 상세한 지침을 포함합니다.

Subagents는 slash commands와 유사하지만, 더 복잡하고 자율적인 작업을 수행할 수 있습니다. Boris는 이것들을 “대부분의 Pull Request에서 수행하는 가장 일반적인 워크플로우를 자동화하는 것”으로 생각합니다. 공식 문서 Sub-agents에 따르면, subagents는 독립적인 Claude 인스턴스로서 특정 작업에 특화된 컨텍스트와 지침을 가질 수 있습니다.

이러한 자동화 계층의 핵심은 개발자가 반복적인 작업에 시간을 낭비하지 않도록 하는 것입니다. 한 번 워크플로우를 정의하고 나면, 그 다음부터는 단순히 명령어를 호출하기만 하면 됩니다. 더 중요한 것은, 이러한 자동화가 팀 전체에 공유되므로, 한 사람이 만든 효율성 개선이 모든 팀원에게 즉시 혜택을 줍니다.

코드 품질 유지: PostToolUse Hook과 Formatting

Boris는 PostToolUse hook을 사용하여 Claude가 생성한 코드를 자동으로 포맷팅합니다. 이는 코드 품질 관리의 자동화를 보여주는 좋은 예시입니다.

Claude는 대부분의 경우 이미 잘 포맷팅된 코드를 생성합니다. 하지만 “마지막 10%”를 처리하기 위해 hook을 사용합니다. 예를 들어, 들여쓰기가 미묘하게 잘못되었거나, 줄 길이가 팀의 스타일 가이드를 초과하는 경우가 있을 수 있습니다. PostToolUse hook은 Claude가 파일을 수정한 직후에 자동으로 실행되어, Prettier, Black, gofmt 등의 포맷터를 적용합니다.

이 접근법의 이점은 나중에 CI(Continuous Integration)에서 포맷팅 오류로 빌드가 실패하는 것을 방지한다는 점입니다. 전통적인 개발에서는 개발자가 코드를 작성하고, 커밋하고, 푸시한 후에야 CI에서 포맷팅 오류를 발견하고, 다시 로컬로 돌아와 수정하는 과정을 거쳐야 했습니다. Hook을 사용하면 이러한 왕복이 완전히 제거됩니다.

또한 이는 “신뢰하되 검증하라(trust but verify)”는 원칙을 구현합니다. Claude를 신뢰하여 자율적으로 코드를 작성하게 하되, 자동화된 검증 단계를 통해 품질을 보장합니다. 이는 인간 개발자 간의 협업에서도 사용되는 패턴입니다. 시니어 개발자가 주니어 개발자의 코드를 신뢰하되, 코드 리뷰를 통해 품질을 확인하는 것과 유사합니다.

권한 관리의 균형: Permission Mode 전략

Boris는 --dangerously-skip-permissions 플래그를 사용하지 않습니다. 대신 /permissions 명령어를 사용하여 자신의 환경에서 안전하다고 판단되는 일반적인 bash 명령들을 사전에 허용합니다.

이는 보안과 효율성 사이의 균형을 보여줍니다. --dangerously-skip-permissions를 사용하면 모든 권한 프롬프트를 건너뛸 수 있어 편리하지만, 위험한 명령이 실수로 실행될 수 있습니다. 반면 모든 명령에 대해 매번 승인을 요청하면 안전하지만, 작업 흐름이 계속 중단되어 비효율적입니다.

Boris의 접근법은 중간 지점을 찾는 것입니다. 예를 들어 git status, npm install, pytest 등 자주 사용되고 안전한 명령들을 사전 허용 목록에 추가합니다. 이러한 설정은 .claude/settings.json에 체크인되어 팀 전체가 공유합니다. 따라서 팀원들은 각자 권한 설정을 구성할 필요 없이, 저장소를 클론하면 바로 최적화된 권한 설정을 사용할 수 있습니다.

그러나 Boris도 특정 상황에서는 --permission-mode=dontAsk 또는 --dangerously-skip-permissions를 사용합니다. 이는 매우 긴 작업을 샌드박스 환경에서 실행할 때입니다. 예를 들어, 밤새 실행될 테스트 스위트나 대규모 리팩토링 작업의 경우, 중간에 권한 프롬프트 때문에 Claude가 멈춰있는 것을 방지하기 위해 모든 권한을 허용합니다. 단, 이는 격리된 환경에서만 수행하여 위험을 최소화합니다.

통합 생태계: MCP와 외부 도구 활용

Boris의 Claude Code는 단순히 코드를 작성하는 도구가 아니라, 그의 전체 개발 생태계와 통합되어 있습니다. Claude Code는 그를 위해 모든 도구를 사용합니다.

MCP(Model Context Protocol) 서버를 통해 Slack을 검색하고 메시지를 게시합니다. 팀원에게 질문이 있거나, 특정 논의를 찾아야 할 때, Claude에게 “지난주 #engineering 채널에서 데이터베이스 마이그레이션에 대한 논의를 찾아줘”라고 요청할 수 있습니다. Claude는 Slack MCP를 사용하여 검색하고, 관련 메시지를 요약합니다.

BigQuery CLI(bq)를 사용하여 분석 쿼리를 실행합니다. “지난 달 API 호출 수의 추세를 보여줘”라고 요청하면, Claude가 직접 BigQuery에 접속하여 SQL 쿼리를 작성하고 실행한 후 결과를 분석합니다. 개발자는 SQL 문법이나 BigQuery의 특정 함수를 기억할 필요가 없습니다.

Sentry에서 에러 로그를 가져옵니다. “production 환경에서 오늘 발생한 500 에러를 분석해줘”라고 하면, Claude가 Sentry API를 통해 에러를 가져오고, 공통 패턴을 찾아내고, 근본 원인을 제안합니다.

중요한 점은 Slack MCP 설정이 .mcp.json에 체크인되어 팀 전체가 공유한다는 것입니다. 새로운 팀원의 Claude는 이미 팀의 Slack workspace에 연결되어 있고, 필요한 모든 권한을 갖고 있습니다. 이는 도구 설정의 표준화를 통해 팀 전체의 생산성을 향상시킵니다.

이러한 통합은 Claude Code를 단순한 코딩 도우미에서 “디지털 동료”로 변화시킵니다. 실제 동료 개발자가 Slack을 확인하고, 데이터베이스를 쿼리하고, 에러 로그를 조사하듯이, Claude도 동일한 작업을 수행할 수 있습니다. 차이점은 Claude가 이러한 작업을 훨씬 빠르게, 그리고 지칠 줄 모르고 수행한다는 것입니다.

장시간 작업 관리: Background Agents와 Plugins

매우 긴 작업의 경우, Boris는 여러 전략을 조합하여 사용합니다. 첫 번째는 Claude에게 작업 완료 후 백그라운드 에이전트로 자신의 작업을 검증하도록 프롬프트하는 것입니다. “이 리팩토링을 완료한 후, 모든 테스트를 실행하고 결과를 보고해줘”와 같은 지시를 미리 포함시킵니다.

두 번째는 Agent Stop hook을 사용하여 더 결정적으로 검증을 수행하는 것입니다. Hook은 Claude가 작업을 “완료”했다고 판단하는 시점에 자동으로 실행되는 스크립트입니다. 예를 들어, Stop hook에서 전체 테스트 스위트를 실행하고, 코드 커버리지를 확인하고, linter를 돌리는 등의 검증 단계를 수행할 수 있습니다.

세 번째는 ralph-wiggum 플러그인입니다. 이는 Anthropic의 공식 플러그인 저장소 Ralph Wiggum Plugin에서 제공되는 도구로, 장시간 실행되는 작업의 모니터링과 관리를 돕습니다.

이러한 전략들이 필요한 이유는 장시간 작업의 특성 때문입니다. 밤새 실행되는 대규모 데이터 마이그레이션이나, 수천 개의 파일을 리팩토링하는 작업의 경우, 중간에 개발자의 입력을 기다리며 멈춰있을 수 없습니다. 따라서 샌드박스 환경에서 --permission-mode=dontAsk를 사용하여 Claude가 자율적으로 작업을 계속할 수 있게 합니다.

Boris의 접근법은 “자율성과 안전성의 계층화”입니다. 일상적인 작업에서는 적절한 권한 관리와 승인 프로세스를 유지하지만, 격리된 환경에서 긴 작업을 수행할 때는 더 많은 자율성을 부여합니다. 대신 작업 완료 후 자동화된 검증 단계를 통해 결과를 확인합니다.

검증 중심 철학: 피드백 루프의 중요성

Boris의 마지막이자 가장 중요한 팁은 “Claude에게 작업을 검증할 방법을 제공하라”는 것입니다. 그는 이것이 최종 결과의 품질을 2~3배 향상시킨다고 강조합니다.

Claude가 claude.ai/code에 배포할 모든 변경사항을 Chrome extension을 사용하여 테스트합니다. Claude는 브라우저를 열고, 실제 UI를 조작하고, 변경사항이 올바르게 작동하는지 확인합니다. 만약 문제가 발견되면, 코드를 수정하고 다시 테스트하는 과정을 반복합니다. 이 피드백 루프는 코드가 실제로 작동할 때까지 계속됩니다.

공식 문서 Chrome Extension에 따르면, Chrome extension 통합은 Claude가 웹 애플리케이션을 엔드투엔드로 테스트할 수 있게 합니다. 이는 단위 테스트나 통합 테스트를 넘어, 실제 사용자 경험을 검증하는 수준입니다.

이 원칙의 핵심은 “폐쇄 루프 시스템(closed-loop system)”을 만드는 것입니다. 전통적인 개발에서는 개발자가 코드를 작성하고, 실행하고, 결과를 보고, 필요시 수정하는 피드백 루프를 직접 운영합니다. AI 기반 개발에서도 동일한 루프가 필요하지만, 이제는 AI가 자체적으로 이 루프를 운영할 수 있습니다.

검증 방법은 다양할 수 있습니다. 단위 테스트를 실행하고 결과를 확인하는 것, 통합 테스트로 전체 시스템의 동작을 검증하는 것, 실제 브라우저에서 UI를 테스트하는 것, 프로덕션과 유사한 환경에서 부하 테스트를 수행하는 것 등이 모두 해당됩니다. 중요한 것은 Claude가 자신의 작업이 올바른지 독립적으로 판단할 수 있는 메커니즘을 갖추는 것입니다.

이는 또한 개발자의 역할 변화를 시사합니다. 개발자는 더 이상 모든 코드를 직접 검증할 필요가 없습니다. 대신 검증 프로세스 자체를 설계하고, Claude가 그것을 실행하게 합니다. “어떻게 코드를 작성할 것인가”보다 “어떻게 코드가 올바른지 확인할 것인가”가 더 중요한 질문이 됩니다.

API 기반 무제한 사용: 비용 대비 가치의 재계산

Boris가 언급한 중요한 세부 사항 중 하나는 팀이 API 빌링을 사용하여 무제한 토큰을 사용한다는 점입니다. 이는 Claude Code 사용에 대한 경제성 분석이 필요함을 시사합니다.

일반적인 claude.ai 구독은 사용량 제한이 있지만, Anthropic API는 사용한 만큼 지불하는 종량제 모델입니다. 대신 티어 시스템이 있어 사용량이 많을수록 더 높은 쿼터를 받습니다. Boris의 팀처럼 하루에 10-15개의 Claude 인스턴스를 병렬로 실행하고, Opus 4.5를 모든 작업에 사용하는 경우, API 비용이 상당할 수 있습니다.

하지만 이를 개발자의 시간 절약과 비교하면 ROI는 압도적입니다. 시니어 소프트웨어 엔지니어의 시간당 비용이 수백 달러인 것을 고려하면, AI가 하루에 몇 시간이라도 절약해준다면 API 비용은 쉽게 정당화됩니다. 더구나 품질 향상, 버그 감소, 빠른 배포 주기 등의 간접적 이점까지 고려하면 가치는 더욱 명확해집니다.

Boris의 조언 “먼저 시도해보고 결과를 보고하라”는 실용주의를 강조합니다. 이론적인 비용 분석보다 실제 사용해보고 생산성 향상을 측정하는 것이 중요합니다. /init 명령으로 시작하여, CLAUDE.md를 업데이트하면서 Claude가 실수로부터 학습하게 하는 과정을 통해, 점진적으로 시스템을 개선해나갈 수 있습니다.

도메인 간 적용: Engineering, Design, Product의 융합

Boris는 한 질문에 대한 답변에서 흥미로운 통찰을 제공했습니다. “엔지니어링, 디자인, 제품이 하나로 융합되기 시작하고 있으며, 팁들은 사실상 모두 동일하다”고 말합니다. 이는 AI 도구가 전통적인 역할 구분을 흐리게 만들고 있음을 보여줍니다.

과거에는 엔지니어가 코드를 작성하고, 디자이너가 UI를 설계하고, 프로덕트 매니저가 요구사항을 정의하는 명확한 분업이 있었습니다. 하지만 Claude Code와 같은 도구는 이러한 경계를 넘나듭니다. 엔지니어가 Figma MCP를 사용하여 디자인을 직접 구현할 수 있고, 디자이너가 Claude에게 프로토타입 코드를 작성하게 할 수 있으며, 프로덕트 매니저가 데이터 분석을 직접 수행할 수 있습니다.

Boris가 Figma MCP가 “awesome”하다고 특별히 언급한 것은 이러한 통합의 구체적인 예시입니다. Figma MCP를 사용하면 Claude가 Figma 디자인을 읽고, 그것을 실제 동작하는 React 컴포넌트로 변환할 수 있습니다. 디자인과 구현 사이의 간극이 사라지는 것입니다.

이는 “T자형 인재(T-shaped people)”의 개념을 확장합니다. 과거에는 한 분야의 깊은 전문성과 여러 분야의 넓은 이해를 가진 사람을 의미했지만, 이제는 AI의 도움으로 실제로 여러 분야에서 생산적인 작업을 수행할 수 있게 되었습니다. 엔지니어가 훌륭한 디자이너가 될 필요는 없지만, Claude와 Figma MCP를 활용하여 디자이너 수준의 결과물을 만들어낼 수 있습니다.

실전 적용 가이드: 귀하의 조직에서 시작하기

Boris의 사용법을 자신의 환경에 적용하려면 단계적 접근이 필요합니다. 처음부터 15개의 Claude 인스턴스를 병렬로 실행할 필요는 없습니다. 대신 다음과 같은 점진적 경로를 추천합니다.

1단계: 기본 설정과 CLAUDE.md 시작 /init 명령으로 프로젝트를 초기화하고, 간단한 CLAUDE.md를 만듭니다. 처음에는 팀의 코딩 컨벤션, 선호하는 라이브러리, 피해야 할 패턴 등 기본적인 내용만 포함합니다. Git에 체크인하여 팀원들과 공유합니다.

2단계: 실수 학습 루프 구축 Claude와 작업하면서 잘못된 결과가 나올 때마다 CLAUDE.md에 추가합니다. “Claude가 X를 했는데 Y를 해야 했다”는 패턴을 찾아내고 문서화합니다. 일주일 정도만 지나도 상당한 양의 팀 지식이 축적됩니다.

3단계: 워크플로우 자동화 반복적으로 수행하는 작업을 식별하고, slash commands로 만듭니다. 커밋-푸시-PR, 테스트 실행, 코드 리뷰 준비 등이 좋은 후보입니다. 처음에는 간단한 것부터 시작하여 점진적으로 복잡한 워크플로우로 확장합니다.

4단계: 검증 메커니즘 추가 PostToolUse hook으로 자동 포맷팅을 추가하고, Agent Stop hook으로 테스트 실행을 자동화합니다. Claude가 자체적으로 작업을 검증할 수 있는 환경을 만듭니다.

5단계: 외부 도구 통합 MCP 서버를 통해 Slack, Jira, GitHub 등 팀이 사용하는 도구들을 연결합니다. .mcp.json을 Git에 체크인하여 팀원들이 동일한 통합 환경을 갖도록 합니다.

6단계: 규모 확장 여러 Claude 인스턴스를 병렬로 실행하고, API 빌링으로 전환하여 사용량 제한을 제거합니다. 이 단계에서는 이미 충분한 생산성 향상을 경험했을 것이므로, ROI 계산이 명확해집니다.

중요한 것은 각 단계에서 측정 가능한 결과를 추적하는 것입니다. PR 생성 시간, 버그 발견율, 코드 리뷰 시간 등의 메트릭을 통해 개선을 정량화합니다. Boris가 강조했듯이 “시도해보고 결과를 보고하라”는 실험적 접근이 핵심입니다.

조직적 영향: 개발 문화의 변화

Boris의 접근법은 단순히 개인의 생산성을 높이는 것을 넘어, 조직의 개발 문화를 변화시킵니다. CLAUDE.md를 중심으로 한 집단 학습 시스템은 지식 공유를 자연스럽게 만듭니다. 과거에는 시니어 개발자의 노하우가 코드 리뷰나 멘토링을 통해 천천히 전파되었다면, 이제는 CLAUDE.md에 한 번 추가하면 모든 팀원의 Claude가 즉시 학습합니다.

이는 온보딩 시간을 극적으로 단축시킵니다. 신입 개발자가 팀의 코딩 스타일을 익히고, 프로젝트의 아키텍처를 이해하고, 모범 사례를 내재화하는 데 보통 몇 달이 걸립니다. 하지만 그들의 Claude는 첫날부터 팀의 집단 지성을 갖고 있습니다. 따라서 신입 개발자가 훨씬 빠르게 생산적인 기여를 시작할 수 있습니다.

또한 이는 코드 품질의 일관성을 향상시킵니다. 모든 팀원이 동일한 CLAUDE.md를 공유하므로, 각자의 코드가 팀의 표준을 자동으로 따릅니다. 코드 리뷰에서 스타일 가이드 위반을 지적하는 시간이 줄어들고, 더 중요한 아키텍처나 로직 논의에 집중할 수 있습니다.

실수로부터 배우는 문화도 강화됩니다. 누군가 Claude와 작업하다가 문제를 발견하면, 그것을 CLAUDE.md에 추가함으로써 팀 전체에게 즉시 혜택을 줍니다. 이는 실수를 숨기거나 부끄러워하는 것이 아니라, 성장의 기회로 보는 건강한 문화를 촉진합니다.

미래 전망: AI 네이티브 개발 조직

Boris의 사용법은 “AI 네이티브” 개발 조직이 어떤 모습일지 보여줍니다. 이러한 조직에서는:

개발자의 역할이 코드 작성에서 시스템 설계와 검증으로 이동합니다. 세부적인 구현은 AI에게 맡기고, 개발자는 전체 아키텍처와 품질 기준에 집중합니다.
지식 관리가 문서나 위키에서 실행 가능한 컨텍스트(CLAUDE.md, slash commands, subagents)로 전환됩니다. 지식은 단순히 읽는 것이 아니라, AI의 행동을 직접 형성합니다.
협업 모델이 변화합니다. 사람-사람 협업뿐만 아니라 사람-AI, AI-AI 협업이 일상화됩니다. 여러 Claude 인스턴스가 서로 다른 작업을 병렬로 수행하고, 필요시 서로 협력합니다.
생산성 메트릭이 재정의됩니다. 작성한 코드 줄 수가 아니라, 설계한 시스템의 복잡도, 자동화한 워크플로우의 수, 구축한 피드백 루프의 효율성 등이 중요해집니다.
학습 곡선이 변화합니다. 새로운 기술이나 프레임워크를 배우는 것보다, AI를 효과적으로 활용하는 방법을 배우는 것이 더 중요해집니다. “좋은 프롬프트를 작성하는 능력”이 “좋은 코드를 작성하는 능력”만큼 중요합니다.

비판적 고찰: 한계와 고려사항

Boris의 접근법은 인상적이지만, 모든 상황에 완벽하게 적합한 것은 아닙니다. 몇 가지 고려할 점이 있습니다.

비용 문제: API 기반 무제한 사용은 상당한 비용을 수반합니다. Opus 4.5를 모든 작업에 사용하고, 10-15개의 인스턴스를 병렬로 실행하면 월 수천 달러의 비용이 발생할 수 있습니다. 이는 대기업이나 잘 자금을 받은 스타트업에게는 문제가 되지 않지만, 소규모 팀이나 개인 개발자에게는 부담이 될 수 있습니다.

학습 곡선: CLAUDE.md, slash commands, subagents, hooks, MCP 등의 개념을 모두 이해하고 효과적으로 활용하려면 상당한 시간 투자가 필요합니다. 특히 AI 도구에 익숙하지 않은 팀원들은 처음에 압도될 수 있습니다.

과도한 의존: AI에 너무 의존하면 기본적인 코딩 능력이 퇴화할 수 있다는 우려가 있습니다. 특히 주니어 개발자들이 AI 없이는 문제를 해결하지 못하게 될 위험이 있습니다. 균형을 유지하는 것이 중요합니다.

보안과 프라이버시: 코드베이스 전체를 외부 API(Anthropic)로 전송하는 것은 보안 위험을 수반할 수 있습니다. 민감한 정보나 독점 알고리즘을 다루는 조직은 추가적인 보안 조치가 필요합니다.

검증의 한계: Claude가 자체 검증을 수행하더라도, 인간의 최종 검토는 여전히 필요합니다. 특히 보안, 개인정보 보호, 비즈니스 로직 등의 중요한 영역에서는 더욱 그렇습니다.

결론: 새로운 개발 패러다임의 시작

Boris Cherny의 Claude Code 사용법은 단순한 “팁과 트릭”을 넘어, 소프트웨어 개발의 미래를 엿보게 합니다. AI는 더 이상 보조 도구가 아니라, 개발 프로세스의 중심에 자리잡고 있습니다. 개발자의 역할은 변화하고 있으며, 이는 위협이 아니라 기회입니다.

코드를 한 줄 한 줄 타이핑하는 것에서 벗어나, 개발자는 이제 더 높은 수준의 추상화에서 작업할 수 있습니다. 시스템 아키텍처를 설계하고, 품질 기준을 정의하고, 워크플로우를 자동화하고, 피드백 루프를 구축하는 것이 새로운 핵심 역량입니다.

Boris의 가장 중요한 교훈은 아마도 “실수로부터 학습하는 시스템을 구축하라”는 것일 것입니다. CLAUDE.md를 중심으로 한 집단 학습 메커니즘은 팀의 지식을 복리처럼 축적시킵니다. 오늘 해결한 문제는 내일 자동으로 처리되며, 이것이 주, 월, 년 단위로 누적되면 엄청난 생산성 향상을 가져옵니다.

그의 접근법을 완전히 복제할 필요는 없습니다. 오히려 자신의 팀, 프로젝트, 작업 스타일에 맞게 조정하는 것이 중요합니다. 핵심 원칙 - 계획 중심 워크플로우, 검증 가능한 피드백 루프, 지속적인 학습과 개선, 적절한 자동화 - 을 이해하고, 자신만의 방식으로 구현하는 것이 성공의 열쇠입니다.

AI 기반 개발은 이제 선택이 아니라 필수입니다. Boris Cherny의 사례는 이것이 단지 가능할 뿐만 아니라, 이미 실무에서 성공적으로 작동하고 있음을 보여줍니다. 남은 질문은 “AI를 사용할 것인가”가 아니라 “얼마나 효과적으로 사용할 것인가”입니다. Boris의 경험은 그 질문에 대한 실질적이고 영감을 주는 답변입니다.

참고 자료

문서 작성: 2026-01-03
작성자: AI 개발 도구 전문가
대상 독자: Claude Code를 실무에 도입하려는 개발팀, AI 기반 개발 워크플로우에 관심 있는 엔지니어
문서 버전: 1.0

AI, Claude Code

AI BorisCherny claude-code vibe-coding Developer Guide Claude.write