By Ashwin Kumar, Erwin Gao, Matan Levi, Sheela Yadawad, Sherman Wong, Sneha Iyer, Vinodh Kumar Sunkara
서론
「AI로 코드를 작성하는 것」이 당연해진 2025~2026년. 본 기사에서는 Anthropic이 2025년 12월에 공개한 사내 연구 보고서[1](132명 설문 + 53명 인터뷰 + 20만 개의 Claude Code 세션 분석)를 중심으로, 최첨단 엔지니어들의 실태를 정리합니다.
1. 전체상 — 「코드를 작성하는 것」에서 「AI를 편성하는 것」으로
| 기업 | AI 생성 코드 비율 | 출처·비고 |
|---|
| Anthropic | 70~90%(Boris Cherny 개인은 100%) | Boris Cherny 발언 |
| 약 75%(신규 코드) | Pichai 발언 |
| Meta | 코드 변경의 55%를 Agent-Assisted로 달성하는 것이 목표 | 2025 Q4 목표 |
| Snap | 65% | — |
| Microsoft | 약 30% | Satya Nadella (2025년 4월 시점) |
(추측) 이 수치들에는 정의의 차이가 있습니다. "AI에게 작성하게 하고 인간이 일절 수정하지 않은 것"인지, "AI의 제안(Suggestion)을 수락한 행수"인지에 따라 의미가 달라집니다.
2. Anthropic의 내부 실태
사용률과 생산성
12개월 전 → 업무의 28%에서 Claude 사용, +20% 생산성 향상
현재 → 업무의 59%에서 Claude 사용, +50% 생산성 향상
Engineering 전체에 Claude Code를 도입했을 때, 1인당 머지된 PR(Pull Request) 수는 67% 증가했습니다. 일상 사용률 상위 항목은 디버깅(55%), 코드 이해(42%), 신기능 구현(37%)입니다.
또한, Claude 지원 업무의 27%는 Claude가 없었다면 착수되지 않았을 태스크(탐색적 작업, 문서화, 스케일링 등)였습니다.
반년 만에 일어난 변화
| 지표 | 6개월 전 | 현재 | 변화 |
|---|
| 평균 태스크 복잡도 (5단계) | 3.2 | 3.8 | +0.6 |
| ... | | | |
| 더 복잡한 일을, 더 적은 개입으로, 더 오래 AI에게 맡기고 있습니다 | | | |
— 이것이 반년 만에 일어난 변화입니다.
무엇을 맡기고, 무엇을 수중에 남길 것인가
맡기는 것: 자신의 컨텍스트(Context) 밖이면서 복잡도가 낮은 것, 검증 비용이 작은 것, 반복 작업, 일회성 코드.
수중에 남기는 것: 고수준의 전략적 사고, 조직의 컨텍스트나 "감각"을 요하는 설계 판단.
「감독의 패러독스(Paradox of Supervision)」
(추측) 주니어 엔지니어에게 이 문제는 더욱 심각합니다.
시니어는 "AI가 없던 시대에 쌓은 기초"로 감독할 수 있지만, 주니어는 그 기초를 쌓기 전에 의존하게 되는 유혹에 노출됩니다.
3. Boris Cherny의 구체적인 하루
Claude Code 책임자. 서적 Programming TypeScript의 저자.
병렬 10~15 세션 운용
로컬(iTerm2)에서 5개 탭, 브라우저에서 5~10개 세션을 병렬로 진행합니다.
각 세션은 독립된 git checkout을 사용합니다(충돌 방지를 위해).
단, 10~20%의 세션은 예상치 못한 상황으로 인해 폐기됩니다.
모델 선택 — 경량 모델보다 중량 모델
모든 작업에 Opus 4.5 with thinking을 사용합니다. Sonnet보다 느리지만 품질과 신뢰성이 높으며, 결과적으로 더 빠르다는 판단입니다. (추측) 빠른 모델로 많이 실패하고 재시도(Retry)하는 것보다, 느린 모델로 한 번에 맞히는 것이 총 시간이 더 짧다는 경험칙입니다.
CLAUDE.md를 「학습 리포지토리(Repository)」로
Claude가 실수할 때마다 CLAUDE.md에 추가하여 다음번 재발을 방지합니다. 현재 Anthropic 팀의 CLAUDE.md는 약 2.5k 토큰입니다.
4층 품질 보증 — 스위스 치즈 모델 (Swiss Cheese Model)
특히 Layer 3가 탁월합니다. 버그 리포트를 쓰는 것이 아니라, 재발 방지 메커니즘을 Claude가 작성하게 합니다.
계획 → 자동 편집 플로우
Plan 모드에서 Claude와 계획을 구체화하고, 합의가 이루어진 후에 auto-edit으로 전환한다. AI 시대이기 때문에 계획 단계의 질이 결과물의 질을 결정한다.
4. Claude Code 자체의 개발로부터 배울 수 있는 점
- 엔지니어 1인당 하루 5 PR (업계 표준은 1~2)
- Claude Code 자체 코드의 약 90%가 Claude Code로 작성됨
- todo 리스트 기능에서는 2일 만에 20개의 프로토타입을 시제품으로 제작
(추측) 완성품의 질적 차이는 최종 형태의 우열뿐만 아니라, 검토한 선택지의 폭에서 옵니다. "센스가 납득할 때까지 시도할 수 있다"는 점이 차원이 다르게 실현 가능해졌습니다.
아키텍처의 철학 — "모델에 길을 양보하기"
"새로운 모델이 출시될 때마다 코드를 깎아냅니다. 4.0 모델에서는 시스템 프롬프트(System Prompt)의 약 절반을 제거했습니다. 이제 더 이상 필요 없기 때문입니다."
기술 스택(TypeScript, React 등)은 Claude가 이미 잘 다루는 것을 의도적으로 선택했습니다. "가르칠 필요가 없는 스택을 선택했습니다."
REA (Ranking Engineer Agent)
광고 랭킹 ML 모델 최적화용 에이전트. 수일~수주간의 비동기 워크플로우(Asynchronous Workflow)를 통해 ML 라이프사이클 전체를 자율적으로 진행합니다.
성과: 정확도 2배(6개 모델 평균), 엔지니어 3명이 8개 모델 분량을 출하, 5배의 엔지니어링 아웃풋(Engineering Output).
Tribal Knowledge의 자동 컨텍스트화
독립적인 Critic 에이전트를 3라운드 실행하여 AI용 컨텍스트를 자동 생성합니다. 그 결과, 도구 호출(Tool Calling)과 토큰이 40% 감소했으며, 2일이 걸리던 워크플로우 가이드가 30분으로 단축되었습니다.
6. 공통점
| # | 패턴 | 구체적인 예시 |
|---|
| 1 | AI를 "사용"하는 것이 아니라 "통합"하기 | 자사 컨텍스트를 농축한 내재화된 에이전트 |
| ... | | |
7. 우리 팀으로의 이식
단기: CLAUDE.md를 작성하여 git으로 관리한다. Claude가 실수하면 규약(Convention) 측에 내용을 추가하는 문화를 만든다. 큰 변경 사항은 Plan 모드에서의 합의를 필수화한다.
중기: Layer 1(셀프 테스트)과 Layer 3(동적 린팅)부터 다층 품질 보증을 시작한다. Claude가 잘 다루는 스택을 의도적으로 선택한다.
장기: 우선 2~3개의 병렬 세션부터 시도하며 자신만의 한계를 탐색한다. 코드베이스로부터 AI용 컨텍스트를 정기적으로 재생성하는 파이프라인을 검토한다.
8. 불확실한 점
- "100% AI 생성"은 자기 신고 기반입니다. Anthropic 스스로도 "경험 있는 개발자는 AI에 의한 생산성 향상을 과대평가하기 쉽다"며 주의를 당부하고 있습니다.
- Google의 "75%"는 경영진의 발언으로 정의가 모호합니다. 사내의 모든 엔지니어가 그러한지는 불분명합니다.
- Boris의 병렬 10~15 세션은 최첨단 스타일이며, 모든 사람에게 적합한 방식은 아닙니다.
마치며
AI 코딩 도구의 보급을 한마디로 표현하자면 **"코드를 쓰는 시간 → AI를 편성하는 시간으로의 전환"**입니다. 하지만 이는 단순히 "편해졌다"는 이야기가 아니라, 감독의 역설(Supervision Paradox), 리뷰의 병목 현상, 조직의 기억 설계 등 새로운 과제들이 발생하고 있음을 의미합니다.
세계 최정상급 엔지니어들이 매일 하고 있는 일:
"AI가 같은 실수를 두 번 하지 않도록, 조직의 기억과 방어 기제를 계속해서 설계하고 있다."
참고 링크
-
How AI is transforming work at Anthropic
-
Building Claude Code with Boris Cherny
-
Ranking Engineer Agent (REA)
-
Your AI coding agents need a manager
-
How AI is transforming work at Anthropic (2025-12-02) ↩︎
Discussion
