Anthropic 코드의 90%는 Claude Code가 작성하고 있다——직원 80%가 매일 사용하는 「antfooding」을 전부 해부하다

Anthropic 사내에서는 엔지니어의 80% 이상이 매일 Claude Code를 사용하고 있다. 코드의 90%는 Claude Code가 작성하고 있다. 이는 공식 블로그와 Podcast에서 당사자들이 직접 언급한 수치다.

이 기사는 Claude Code를 3개월 이상 사용해 온 사람들을 위해 「만드는 당사자와, 그것을 매일 극한까지 활용하는 직원들」이 어떻게 운용하고 있는지를 8개 팀에 걸쳐 전부 정리했다.

다 읽고 나면 「내 사용법은 아직 L3 수준이구나」, 「내일부터 따라 할 수 있는 방법은 3가지구나」라는 것이 보일 것이다.

• Anthropic 사내의 Claude Code 채택 실측치 ("antfooding")

• 8개 팀별 구체적인 유스케이스 (Use Case)와 절감된 시간 수치

• Boris Cherny (Head of Claude Code)와 Cat Wu (PM)가 Podcast에서 밝힌 내부 테크닉 8가지

• 일반 사용자가 오늘부터 따라 할 수 있는 3가지 방법, 그리고 따라 하면 망하는 3가지 패턴

• Claude Code를 3개월 이상 사용하고 있으며, 다음에 어디를 목표로 해야 할지 모르는 사람

• 서브 에이전트 (Sub-agent), 스킬 (Skill), Hooks까지는 다뤄보았지만, 아직 업무 흐름 (Workflow)에 편입시키지 못한 사람

• 「Anthropic 직원과 같은 위치에 서고 싶다」고 생각하는 사람

• 1. 숫자로 보는 antfooding——80%가 매일, 코드의 90%
• 2. Claude Code team 자신——1개 기능에 20개 프로토타입을 2일 만에
• 3. Security Engineering——10~15분의 스캔이 3배 빨라짐
• 4. Data Infrastructure——K8s 다운을 20분 만에 복구한 실화
• 5. Inference / Growth Marketing——80% 감소 및 광고 생성의 hours $\rightarrow$ minutes
• 6. Boris와 Cat이 밝힌 내부 테크닉 8가지
• 7. 일반 사용자가 오늘 바로 따라 할 수 있는 3가지
• 8. 따라 하면 망하는 3가지 패턴
• 9. 요약——오늘부터 실행할 3가지 단계

이 섹션에서는 Anthropic 내부의 Claude Code 채택도를 숫자로 나타낸다.

「antfooding」은 Anthropic 직원(스스로를 "ants"라고 부른다)에 의한 도그푸딩 (dogfooding)의 애칭이다. 그들은 직접 만든 도구를 자신의 현장에서 매일 사용한다. Cat Wu (Claude Code PM)는 Podcast에서 "피드백 채널에 5분에 한 번씩 게시물이 올라온다"라고 말했다. 이는 규모감을 나타내는 상징적인 숫자다.

공개된 소스에서 확인할 수 있는 수치를 정리한다.

채택도:

지표	수치	출처
사내 엔지니어 이용률	80% 이상이 매일	Pragmatic Engineer
Anthropic 코드 작성 비중	90%가 Claude Code 제작	Boris Cherny
Day 1 이용률	20%	Every Podcast
Day 5 이용률	50%	Every Podcast

생산성:

지표	수치
내부 릴리스 수	1일 60~100개 (npm 패키지)
엔지니어 1인당 PR 수	1일 5개 (여름 피크 시)
1개 기능당 프로토타입 수	20개 이상을 2일 만에
엔지니어 배증 시 PR throughput	67% 향상 (통상적으로는 감소하나 반대 방향)

마지막 숫자가 가장 강력하다. 보통 엔지니어를 두 배로 늘리면 온보딩 (onboarding) 비용으로 인해 PR 수는 일시적으로 떨어진다. 하지만 Anthropic은 반대로 늘어났다. Claude Code 자체가 신입의 온보딩을 담당했기 때문이다.

💡 Tips: "엔지니어 배증 시 PR throughput이 67% 향상"되는 것은 타사 사례로서 따라 하기 어렵지만, "Claude Code 자체를 신입 온보딩 장치로 만든다"는 발상은 내일부터 바로 따라 할 수 있다. 뒷부분의 장에서 구체적으로 기술한다.

여기서부터 팀별 사용법을 살펴보겠다.

이 섹션에서는 Claude Code를 만들고 있는 당사자 팀의 사용법을 본다.

Boris Cherny (오리지널 프로토타입 제작자, Head of Claude Code)는 Podcast에서 자신의 워크플로우를 이야기했다. 요점은 다음과 같다.

# clean git state에서 시작하여 auto-accept로 실행
git status # 전부 깨끗한 상태라는 전제
claude --auto-accept "todo list의 프로토타입을 20가지 만들어줘"

auto-accept

로 Claude를 자율 주행시키고, 80% 완성된 시점에서 확인한다. 마음에 들지 않으면 Escape를 두 번 눌러 직전 상태로 되돌리고, 다른 각도에서 다시 시도한다. Boris의 말을 빌리자면 "가장 단순한 것을 구축하여 전체 시스템을 만져본다. 실패 지점을 확인하고, Escape로 되돌려 다시 한다"이다.

이로써 기능 1개당 20개 이상의 프로토타입을 2일 만에 만든다. todo list 기능을 내놓기까지 20개 이상의 시제품을 돌렸다고 공개했다.

이 부분이 정말 효과적인 사고방식이다.

"Claude 4.0으로 업그레이드했을 때, system prompt의 절반을 삭제했다" (Boris).

새 모델은 더 적은 지시로도 잘 작동한다. 따라서 이전 모델을 위한 "X를 할 때는 반드시 Y를 한 뒤 Z를 하라"와 같은 가드레일 (guardrail)은 제거할 수 있다. 코드를 더하는 것이 아니라, 코드를 빼는 것이 Claude Code 팀 자신의 릴리스 작업이다.

Claude Code 본체의 기술 선정은 Claude가 훈련 데이터에서 가장 많이 접한 영역에 맞추고 있다.

영역	채택 기술	이유
언어	TypeScript	Claude가 가장 잘함
...

이는 개인의 Claude Code 활용에도 적용되는 사상이다. 자신의 프로젝트 기술 스택이 Claude의 특기 분야에서 벗어날수록 생성 품질은 떨어진다.

이 섹션에서는 보안 팀의 실제 운영과 절감 수치를 살펴본다.

공식 블로그 "How Anthropic teams use Claude Code"에 따르면, 보안 팀의 워크플로우는 다음과 같다.

• design doc (설계 문서)를 작성한다
• Claude Code에게 pseudocode (의사 코드)를 작성하게 한다
• 거기서부터 test-driven development (TDD, 테스트 주도 개발)로 구현에 옮긴다
• 인시던트 (incident) 발생 시에는 stack trace (스택 트레이스)를 그대로 입력한다

정량적 데이터는 기사에 명시되어 있다:

"Problems that typically take 10-15 minutes of manual scanning now resolve 3x as quickly"

1015분의 수동 스캔 작업이 **3분의 1 (실질적으로 35분)**로 단축되었다.

직원들이 사용하는 플로우를 CLAUDE.md에 옮기면 다음과 같다.

# Security Engineering Workflow
## 구현 플로우
1. design doc 을 `docs/design/` 에 작성한다
...

이 CLAUDE.md를 작성하는 방식에 대해 Anthropic 직원들은 공통적으로 말한다: 문서화가 잘 되어 있는 팀일수록 Claude Code의 효과가 크다. 반대로 아무것도 적혀 있지 않으면, Claude는 모든 선택지를 탐색하기 시작하여 시간을 잡아먹는다.

Anthropic 직원들조차 문서화가 부족한 영역에서는 Claude Code의 정밀도가 떨어진다고 공식 블로그에 적혀 있다. "일단 두드리면 돌아가겠지"라고 생각하며 CLAUDE.md를 정비하지 않으면, 자신도 똑같은 함정에 빠지게 된다.

이 섹션에서는 운영 장애 대응 시 실제로 발생했던 구체적인 케이스를 살펴본다.

공식 블로그에 Data Infrastructure 팀의 K8s 클러스터 다운 사례가 실려 있다. 이것이 가장 리얼하다.

• 운영 환경의 Kubernetes 클러스터가 새로운 Pod를 스케줄링 (schedule)하지 않게 되었다

• 무엇이 원인인지 한눈에 알 수 없다

• 담당 엔지니어는 Google Cloud UI를 그렇게 깊게 다뤄본 적이 없다

• Google Cloud 대시보드의 스크린샷을 찍는다

• 그것을 그대로 Claude Code에 입력한다

• Claude가 "다음으로 이 메뉴를 여세요"라고 지시한다

• 메뉴를 연 화면의 스크린샷을 찍어 다시 입력한다

• 이를 반복하여 Pod IP 주소 고갈을 발견한다

• Claude가 GCP에서 새로운 IP 풀을 만들기 위한 **exact commands (정확한 명령어)**를 제공한다

결과: 본래 소요되었을 조사 시간에서 약 20분을 절약했다.

이는 "스크린샷 → 추론 → 다음 단계"의 루프를 Claude Code가 돌리고 있는 것이다. 페어 프로그래밍 (pair programming)에서 베테랑 SRE가 옆에 서 있는 것과 같다. 자신의 팀에서 재현한다면 다음과 같이 된다:

# 장애 시 스크린샷 입력 플로우
# 1. 장애 대시보드 스크린샷을 찍는다
screencapture -i /tmp/incident-1.png
...

💡 팁: 「Claude에게 스크린샷을 먹인다」는 것은 텍스트 기반의 대화로는 표현할 수 없는 정보를 단번에 전달하는 수단으로서 매우 효과적이다. 실제 장애 상황에서는 대시보드의 수치, 그래프의 기울기, UI의 상태가 한 번에 전달된다. 이는 놓치기 쉬운 부분이다.

이 섹션에서는 엔지니어가 아닌 영역을 포함한 활용법을 살펴본다.

Inference 팀(모델 추론 최적화를 담당하는 엔지니어)의 활용법은 문서 검색과 교차 언어 테스트다.

공식 블로그에서 직접 인용한 수치:

"What normally requires an hour of Google searching now takes 10-20 minutes"

1시간의 Google 검색이 10-20분으로 단축(80% 감소). CUDA, Triton, PyTorch 내부 구현 등의 문서를 횡단하며 읽어야 하는 유형의 업무는 Claude Code가 가장 효과를 발휘하는 영역이다.

이 부분이 개인적으로 가장 흥미롭다. 엔지니어가 아닌 팀이 서브 에이전트 (Sub-agent)를 병렬로 돌리고 있다.

워크플로우:

• 기존 광고 CSV를 입력 (수백 개, 퍼포먼스 지표 포함)
• 서브 에이전트 1: 성과가 저조한 (underperforming) 광고를 식별
• 서브 에이전트 2: 글자 수 제한을 준수한 새로운 변형(variation)을 생성
• 단 몇 분 만에 수백 개의 신규 광고가 완성됨

이를 실현하기 위한 subagent.

설정의 최소 예시는 다음과 같이 작성할 수 있다.

name: ad-analyzer
description: 기존 광고 CSV에서 underperforming을 식별한다
tools:
...

name: ad-generator
description: 저성과 광고로부터 새로운 변형을 생성한다
tools:
...

엔지니어가 없어도 돌아간다. Boris가 인터뷰에서 "데이터 사이언티스트(터미널 경험 없음)가 독자적으로 Claude Code를 습득했다"라고 말한 것이 바로 이 맥락이다.

이 섹션에서는 팟캐스트와 블로그 기사에서 수집한 구체적인 테크닉 8가지를 나열한다.

복잡한 태스크에서 계획 합의를 얻기 위한 Plan Mode이지만, Boris는 "Sonnet 4.5 이후로는 2000 토큰 분량의 플랜을 삭제할 수 있다"라고 말한다. 모델이 똑똑해질수록 Plan Mode의 필요성은 낮아진다.

Boris가 "여러 터미널 사이를 오가는 것이 번거로워 생각해냈다"라고 말한 기능. Claude Code 내에서 그대로 쉘 커맨드 (Shell Command)를 실행할 수 있다.

# Claude Code 세션 내에서
!ls -la
!git status
...

실패한 구현을 Escape 키를 두 번 눌러 직전 상태로 되돌린다. 이것이 있기 때문에 "auto-accept로 자율 주행을 시켜도 안심"할 수 있다.

커맨드	용도
/commit	커밋 메시지 자동화
/feature dev	사양 → 계획 → TODO화
/code review	모든 PR에 적용

/code review는 Anthropic 전사적으로 표준화되어 있다고 한다.

Cat Wu에 따르면, 대규모 마이그레이션 시에는 10개의 서브 에이전트를 동시에 기동하여 역할을 분담한다. 프론트엔드 담당, 백엔드 담당, 테스트 담당으로 나눈다. 핵심은 "uncorrelated context windows" —— 서로 다른 컨텍스트를 부여하여 다양한 관점을 얻는 것이다.

이것이 흥미롭다. 직원 Dan은 신용카드 월간 정산을 하기 위해 두 대의 에이전트를 세웠다:

• 감사역 에이전트: "이것이 정말 경비인가?"라며 의심함
• 개인 편향 에이전트: "이것은 경비라고 주장함"

두 에이전트가 토론하게 하여, 결론이 난 것만 실제 정산으로 진행한다. 코드 이외의 의사결정에서도 사용할 수 있는 발상이다.

매번 발생하는 권한 승인(permission) 프롬프트를 없애기 위해, 직원들은 settings.json을 정비하고 있다.

{
"permissions": {
"allow": [
...

Boris는 "매번 발생하는 권한 프롬프트를 회피하는 것이 중요하다"라고 강조한다. 이는 개인 개발에서도 즉시 따라 할 수 있다.

턴(turn) 완료 후에 실행되는 Stop Hook을 통해, 테스트가 실패(red)하면 자동으로 계속하게 한다.

{
"hooks": {
"Stop": [
...

"테스트가 통과(green)될 때까지 계속"하는 것을 **결정론적(deterministically)**으로 제어할 수 있다. 프롬프트로 "테스트 통과시켜줘"라고 부탁하는 것보다 Hook으로 강제하는 편이 더 안정적이다.

이 섹션에서는 직원들의 방식에서 「개인이 오늘 바로 따라 할 수 있는」 요소만을 뽑아낸다.

직원들이 공통적으로 말하는 것은 「문서화가 잘 되어 있는 팀일수록 Claude Code의 효과가 크다」는 것이다. 자신의 프로젝트용 CLAUDE.md를 「신입 엔지니어가 읽는다는 가정하에」 다시 작성하라.

작성해야 할 내용:

• 이 프로젝트에서 사용하는 기술 스택 (Tech Stack)
• 디렉토리 구성과 각 디렉토리의 책임
• 로컬 개발 실행 명령 (Startup Command)
• 테스트 실행 방법
• 배포 절차 (Deployment Procedure)
• 「절대로 해서는 안 되는 일」 리스트

직원들의 생산성이 높은 이유 중 하나는, 권한(permission) 프롬프트 때문에 매번 작업이 중단되지 않기 때문이다. 자주 사용하는 명령은 즉시 허용 목록(allow list)에 넣는다.

텍스트로 설명하기 어려운 상황(대시보드, 그래프, UI 상태)은 먼저 스크린샷을 찍어서 입력한다. Data Infrastructure 팀이 증명한 방법이다.

# 자주 사용하는 별칭(alias)으로 설정해둔다
alias incident="screencapture -i /tmp/incident-$(date +%H%M%S).png"

이 섹션에서는 직원들의 방식을 그대로 개인에게 적용했을 때 막히게 되는 사례도 다룬다. 이런 내용을 쓰지 않는 기사는 신뢰하지 않는 것이 좋다.

Anthropic 직원이 10개의 병렬 작업을 수행할 수 있는 이유는 코드베이스가 잘 정돈되어 있고 테스트 커버리지 (Test Coverage)가 높기 때문이다. 개인 프로젝트에서 테스트가 빈약한 상태로 10개를 병렬로 돌리면, 각각이 충돌하는 변경 사항을 추가하여 수습 불가능한 상태가 된다. 먼저 2~3개의 병렬 작업부터 시작하고, 테스트가 실패(Red)하면 멈추는 메커니즘을 도입한 뒤에 늘려가라.

「TypeScript + React + Bun이 가장 효과적이다」라는 이야기는 신규 프로젝트를 시작하려는 사람을 위한 것이다. 기존 프로젝트가 Python + Django라면, 그것을 버리고 TS로 전환하는 것은 수지가 맞지 않는다. 자신의 스택 내에서 CLAUDE.md를 두텁게 만드는 것이 더 현실적이다.

Boris가 「90%」라고 말한 것은 직원들이 상시로 리뷰하고 있다는 전제하의 숫자다. 모든 PR(Pull Request)에 /code review를 실행하고, 사람이 최종 승인한다. 자신의 운영 방식에서 /code review 없이 90% 자동 생성을 시도하면, 코드베이스는 2주 만에 파괴될 것이다.

「Anthropic 직원과 똑같은 방식」을 목표로 하는 것은 좋지만, 그들은 리뷰 문화, 테스트 문화, 문서화 문화가 모두 갖춰진 환경에서 작업하고 있다. 자신의 환경이 그렇지 않다면, 우선 환경을 정비하는 것이 먼저다.

• CLAUDE.md를 「신입 온보딩(Onboarding)용」으로 다시 작성한다 (기존 내용이 있더라도 덮어쓰기)
• ~/.claude/settings.json의 permissions.allow를 채운다
• alias incident="screencapture -i /tmp/incident-$(date +%H%M%S).png"를 ~/.zshrc에 추가한다
• 모든 PR에서 /code review를 실행하는 운영 방식을 도입한다
• 서브 에이전트(Sub-agent)를 2개 만들어 역할 분담을 시도한다 (Growth Marketing 패턴)
• Stop Hook을 통해 테스트 실패 시 자동 중단 기능을 넣는다
• auto-accept 모드로 「20개의 프로토타입을 2일 만에」 만드는 Claude Code 팀 방식을 한 번 시도해 본다
• 장애 대응 시 스크린샷을 입력하는 흐름을 구축한다
• 자신의 워크플로우를 직원 80%가 매일 사용하는 수준으로 끌어올린다

참고 소스:

• How Anthropic teams use Claude Code (공식 블로그)
• How Claude Code is built — Pragmatic Engineer
• How to Use Claude Code Like the People Who Built It — Every Podcast Transcript
• Inside Claude Code From the Engineers Who Built It — Apple Podcasts
• How Anthropic teams use Claude Code (공식 PDF)
• Best practices for Claude Code — Anthropic Engineering