Claude Code 창시자가 그린 AI 도입 5단계 지도, 조직이 다음 단계로 못 가는 병목과 해법

Claude Code를 만든 Boris Cherny가 2026년 7월 16일 X에 표 하나를 공개했습니다. 제목은 'Steps of AI Adoption', AI 도입 단계 지도입니다.¹ Cherny는 매일 다른 회사 엔지니어들을 만나며 같은 이야기를 듣는다고 합니다. "한 명은 Claude로 산출량을 10배 끌어올렸는데 조직의 나머지는 아직 따라오지 못했다"는 이야기입니다. Cherny는 팀들이 AI를 도입하는 과정을 지켜보며 매번 같은 단계가 반복된다는 점을 파악했습니다. 그리고 그 단계를 0부터 4까지 다섯 줄짜리 지도로 정리했습니다. 이 글은 그 표와 포스트를 한국어로 옮기고 모던웹연구소의 진단 관점을 덧붙입니다.

단계를 가르는 세 가지 축

Cherny의 지도는 단계마다 세 가지가 달라집니다. 동시에 돌리는 에이전트 수(1 → 10 → 100 → 1,000+), 엔지니어의 역할(페어 프로그래머 → 오케스트레이터 → 매니저의 매니저 → 의도로 조종하는 VP), 그리고 병목의 위치입니다.

핵심 주장은 이렇습니다. '토큰 지원만으로는 다음 단계로 갈 수 없다'는 것입니다. 사용량 예산을 늘린다고 팀이 저절로 다음 단계로 올라가지는 않습니다. 출력을 사람 눈으로만 검증하는 팀은 토큰이 10배 있어도 에이전트 하나를 돌릴 때와 같은 속도로 일합니다. 다음 단계로 가려면 다음 병목을 찾아 없애고, 다음 가드레일을 세워야 합니다. 실무 언어로 풀면 Claude가 자기 작업을 끝까지 스스로 검증할 수단을 주고, 권한은 auto 모드를 켜고, 자동 코드 리뷰·보안 리뷰를 기본값으로 두고, 여러 에이전트를 한 번에 관리하는 인터페이스를 쓰는 일입니다. 더 높은 단계에선 그 역할을 다른 도구가 맡습니다. 같은 작업을 주기적으로 반복하는 /loop, 수많은 항목에 같은 작업을 흩뿌리는 /batch, 서브에이전트 수십~수백 개를 스크립트로 지휘하는 동적 워크플로우가 '사람이 일일이 시작시켜야 한다'는 병목을 없앱니다. 병렬 에이전트마다 저장소의 격리된 사본을 주는 워크트리(worktree) 격리는 늘어난 병렬 실행이 서로 충돌하지 않게 막는 가드레일입니다. 기능 하나가 아니라, 올바른 기능과 올바른 가드레일이 조합되어야 '결과를 신뢰할 수 있는 자동화'가 가능하다는 것이 요지입니다.

0단계 차단(Gated), 아직 시작하지 못한 조직

구형이나 가볍고 빠른 모델만 쓸 수 있고, AI 게이트웨이와 커스텀 인증 때문에 지연이 겹겹이 쌓인 상태입니다. MCP 거버넌스는 없고 사내 AI 도구 접근은 막혀 있거나 절차가 무겁습니다. Claude가 만든 코드나 산출물을 호스팅할 IT 인프라·승인 경로가 없어 산출물이 로컬에만 존재합니다.

이 단계의 병목은 기술이 아닙니다. 레거시 보안·승인 프로세스, 성과 대신 '토큰당 비용 억제'에 집중하는 관점, 의사결정 테이블에 진짜 기술 전문가가 앉아있지 않다는 점입니다.

이 단계에 도움이 되는 것

• Claude.ai 챗

가드레일

• SSO/SCIM과 역할 기반 접근 제어

• 조직 단위 예산 상한

• 기존 승인 절차·IAM 안에서의 배포

• 데이터 거버넌스 패키지

0단계에서 1단계로 가는 길은 경영진·구매 결정권자의 합의와 병목이 되는 요인들을 경영진에게 전달할 수 있는 에스컬레이션 통로, 그리고 Claude를 안전하게 도입하기 위한 프레임워크 확보입니다. 조직도 위쪽에서 풀어야 하는 문제라는 뜻입니다.

1단계 보조(Assisted), 엔지니어와 에이전트가 짝을 이루다

엔지니어 한 명에 에이전트 하나가 붙어서 AI는 감독하에 움직이는 빠른 페어 프로그래머처럼 동작하는 단계입니다. 엔지니어는 세션을 한 번에 하나만 돌리고 머지 전에 거의 모든 변경을 직접 검토합니다.

이 단계가 되면 시간을 벌 수 있습니다. 오후를 통째로 써야만 가능하던 작업이 회의를 마치고 돌아오면 끝나 있습니다.

병목은 사람의 주의력입니다. 모델 출력에 대한 신뢰가 낮고 자기 검증 장치가 없으니 응답과 수정된 코드 하나하나를 전부 읽어야 한다 생각하고, 그래서 화면에서 눈을 떼지 못합니다. 작업이 동기식이라는 점도 문제입니다. AI에게 일을 맡긴 후, 결과를 기다리지 않고 다음 작업으로 넘어가야 하는데 Claude가 일하는 동안 앉아서 지켜봅니다.

이 단계에 도움이 되는 것

• Claude Code(데스크톱·CLI·IDE)

• Claude Cowork, Claude Design

• Anthropic API·Bedrock·Vertex·Microsoft Foundry를 사용한 작업

• Claude Code 분석 대시보드와 Analytics API

• Claude Enterprise용 Compliance API

• 수정 전에 의도를 검토하는 Plan 모드

가드레일

• 개인별 지출 상한(조직 단위 예산 상한과 다름)

• 중앙에서 관리하는 모델·추론 노력 설정과 정책

• 기존 SIEM·관측 스택에 OpenTelemetry 통합하기

1단계에서 2단계로 가려면 네 가지가 필요합니다. 에이전트를 한 번에 둘 이상 돌리는 것, 신뢰할 수 있는 자기 검증 루프(테스트·빌드·린트에 실제 개발 환경을 사용한 e2e 테스트까지), 권한 프롬프트에 막히지 않도록 auto 모드를 켜는 것, 그리고 코드 리뷰 자동화입니다.

2단계 병렬(Parallel), 오케스트레이터가 되다

엔지니어 한 명이 에이전트 5~10개를 동시에 굴립니다. 에이전트마다 자기 워크트리나 별도로 클론한 저장소 사본을 갖고, 엔지니어는 그 사이를 오갑니다. Claude는 테스트·빌드·린트·보안 스캔으로 자기 작업을 먼저 검사한 뒤에야 사람에게 보여줍니다. auto 모드는 항상 켜져 있고 자동 코드 리뷰·보안 리뷰가 기본값입니다. 엔지니어의 산출량은 배가되고, 키 입력이 아니라 최종 diff를 검토하게 되고, 유지보수 백로그가 줄어들기 시작합니다. 코드 대부분을 Claude가 작성합니다.

이 단계가 열어주는 것은 규모입니다. 팀이 몇 주를 써서 작업해야 했던 백로그가 엔지니어 한 명의 오케스트레이션 하에 오후 반나절의 작업으로 해결됩니다.

병목은 출력 검토로 이동합니다. 직접 쓰는 코드는 줄었는데 다양한 갈래에서 흘러오는 코드 스트림을 검사하느라 시간이 더 듭니다. 세션 여러 개를 오가며 모델을 프롬프트하고 조종하는 일 자체가 부담이 됩니다.

이 단계에 도움이 되는 것

• Auto 모드, Agent view

• Claude Code Review, Claude Security Review

• 모바일 Claude Code와 데스크톱의 클라우드 실행(세션을 로컬 머신 대신 클라우드에서 돌려 노트북을 덮어도 작업이 계속됨)

• Claude Teams·Claude Enterprise 사용

• Claude Tag(단일 작업 위임)

• CLI·데스크톱의 워크트리 격리

• 폰에서 에이전트를 모니터링하는 원격 제어

가드레일

• 팀 사용량을 모니터링하는 분석 도구

• 자동 코드 품질 강제(린트·자동 테스트·타입 체크)

• Claude 기반 엔드 투 엔드 검증(Claude Chrome 확장이나 iOS·Android 시뮬레이터 MCP 활용)

• 수동 코드 리뷰·머지·보안 리뷰. 사람 코드와 에이전트 코드에 같은 품질 기준 적용

• settings.json에 안전한 bash·MCP 명령을 미리 승인

2단계에서 3단계로 가려면 Claude에게 코드를 비롯한 위키문서, 회사 내 논의 과정을 볼 수 있게 허락해서 스스로 컨텍스트를 끌어올 수 있게 해야 합니다. 백그라운드에서 유지보수가 자동으로 되게 하려면 다른 팀이 소유한 코드까지 자연스럽게 건드리게 되므로, 에이전트에게 팀 경계 밖에서 행동할 재량을 열어주고 크로스팀 코드 리뷰가 에이전트의 산출 속도를 따라가게 만들어야 합니다. 작업을 루프와 루틴으로 쪼개고, Claude가 Claude를 실행하도록 허용하는 것까지 되어야 합니다.

3단계 감독형 자율(Supervised autonomy), 매니저의 매니저가 되다

Claude가 코드 전부 또는 거의 전부를 작성합니다. 엔지니어의 질문은 "코드 읽어봤어?"에서 "모델에 어떤 컨텍스트가 빠졌고, 다음번엔 그걸 어떻게 해결하지?"로 바뀝니다. 품질 관리의 단위가 코드 검토에서 컨텍스트 공급 체계로 이동하는 지점입니다.

이 단계가 되면 Claude가 먼저 움직입니다. 예전 같으면 엔지니어가 직접 시작시켜야 했을 일을 Claude가 알아서 합니다. 누군가 짬을 내야 처리가 가능했던 유지보수성 작업과 정리 작업이 백그라운드에서 상시로 돕니다.

병목은 루프에 대한 신뢰와 팀의 의사결정 처리량입니다. 3단계가 되면 에이전트 트리가 너무 깊어 엔지니어가 에이전트 전체를 일일이 돌볼 수 없습니다. 이때 함정은 루프가 충분한 신뢰를 얻기 전에 에이전트 수부터 늘리는 것입니다. 사용량이 늘수록 토큰이 효율적으로 쓰이는지도 챙겨야 합니다. OpenTelemetry나 Analytics로 모니터링하고, 실험 단계에선 토큰 낭비를 감수하고 시도를 장려하되, 어떤 내부 자동화가 검증되어 팀 전체가 의존하는 단계(사내의 제품·시장 적합성, PMF)에 이르면 그때부터 그 유스케이스의 비용을 최적화하는 문화가 안착되어야 합니다. 에이전트가 벌이는 작업이 토큰을 쓸 가치가 있는지 가르는 기준으로 Cherny는 이 질문을 제안합니다. "사람 엔지니어였다면 어차피 시간을 들여서 했을 일인가?" 그렇다는 답이 나오는 작업이라면 토큰은 엔지니어의 시간을 대체하고 있는 것이고, 아니라면 에이전트가 벌인 잡무에 토큰을 쓰고 있는 것입니다.

이 단계에 도움이 되는 것

• 워크트리 격리를 적용한 서브에이전트(병렬 에이전트끼리 충돌하지 않도록)

• 반복 작업을 줄이는 루틴과 /loop·/batch·/goal

• 동적 워크플로우

• Claude Tag(채널·데이터 소스를 모니터링하다가 Claude가 알아서 작업을 시작)

가드레일

• 자동 코드 리뷰, 자동 보안 리뷰

• 에이전트 샌드박싱

• CLAUDE.md와 Skills로 팀 표준을 문서화

• 팀 사용 패턴에 맞춘 auto 모드 분류기 튜닝

• 모델 선택·어드바이저 툴·LSP 활용

  • 어드바이저 툴: 작은 모델이 실행하다 어려운 판단만 큰 모델에 묻는 기능

  • LSP: Language Server Protocol로 정의·참조를 정확히 찾아 파일을 통째로 읽는 토큰 낭비를 줄여주는 코드 인텔리전스

• CLAUDE.md를 Skills로 분리해 토큰 사용 관리

  • 지침 예산 가이드 참고

3단계에서 4단계로 가는 조건은 도메인 특화 유스케이스의 대규모 자동화입니다. 사람이 그때그때 작업을 정의해 맡기는 범용 활용에서 나아가, 코드 마이그레이션, 퍼징(무작위 입력으로 결함을 찾는 테스트), 기능 개발, 피드백 처리 같은 조직에서 반복되는 작업 유형을 골라 검증과 가드레일까지 내장한 전용 파이프라인으로 만들어야 합니다.

4단계 AI 네이티브(AI-native), 의도로 조종하는 VP가 되다

루프가 완전히 닫혀 에이전트 대부분이 Claude를 통해 실행됩니다. 수백에서 수천 개의 에이전트가 도는 동안 사람은 작업을 하나하나 지시하는 대신 목표와 방향만 정하고(steer by intent), 정상 진행되는 작업은 들여다보지 않은 채 기준을 벗어난 예외만 보고받습니다(monitor by exception).

이 단계가 열어주는 것은 시간 단위의 전환입니다. 한 분기를 통째로 써야 했던 마이그레이션 작업이 '실행해두고 들여다보는 워크플로우'가 됩니다.

병목은 대규모로 자동화할 작업을 식별하는 일, 그리고 작업 유형마다 올바른 가드레일을 강제하는 일입니다. 도움이 되는 도구로는 에이전트를 프로그래밍으로 만들고 스케줄링하는 Claude Agent SDK, Slack에서 게시물에 자동 응답하는 Claude Tag가 있습니다. 자동화에 쓰는 비용과 모델 선택이 가드레일이 됩니다.

한 장으로 보는 다섯 단계

도입 효과는 무엇으로 측정하는가

팀이 단계를 올라가기 시작했다면 효과는 어떻게 추적해야 할까요. Cherny는 사용량 대시보드도 지켜볼 가치는 있지만 사용량은 '활동'을 측정할 뿐 '수익'을 측정하지 못한다고 선을 긋습니다. 더 나은 질문은 이것입니다. "어차피 엔지니어링 리소스를 썼을 일인가? 그렇다면 수작업으로는 몇 시간이 들었고 비용은 얼마였을까?" 그 차이가 AI 도입의 수익입니다.

더 큰 보상은 그다음에 옵니다. 수정과 유지보수가 백그라운드에서 돌아가고 팀은 만드는 일에 집중하게 될 때, 예전에는 상상하지 못했던 작업을 시도하게 됩니다. Cherny에 따르면 Anthropic은 조직으로서 3단계에 있고 4단계를 향해 가는 중이며, 본인은 막 4단계에 도달했다고 합니다.¹

모던웹연구소의 관점, 지도는 진단 도구로 쓸 때 가치가 있다

모던웹연구소가 만나는 조직 일부는 0단계와 2단계 사이에 있습니다. 반도체·자동차·방산·금융처럼 규제가 엄격한 도메인의 조직을 만나고 그 의사결정권자들을 교육하는 일이 많기 때문입니다. 이런 산업에서 0단계는 조직이 게을러서 머무는 자리가 아닙니다. 규제와 산업 전반의 기술 제약 때문에 최신 모델 승인이 막히고 보안 검토가 길어질 수밖에 없는, 구조적으로 강제된 출발점입니다.

모던웹연구소는 그런 경우에도 제약 안에서 시작할 수 있는 경로를 설계해 제시합니다. 기존 승인 절차와 IAM 안에서의 배포, 데이터 거버넌스 정비, 조직 단위 예산 상한처럼 0단계 행에 정리된 도구들이 그 출발점입니다. 물론 팀 단위로 2·3·4단계의 일부를 실천하는 조직도 있습니다. 에이전트 여러 개를 병렬로 돌리거나 자동 코드 리뷰를 기본값으로 두는 식입니다.

다만 그런 조직도 지도 전체를 놓고 보면 일부 요소를 앞서 실천할 뿐, 조직 차원에서 해당 단계에 안착했다고 보기는 어렵습니다. 0단계의 병목 서술이 낯설지 않다면 먼저 해야 할 일은 도구 교육이 아니라 경영진 정렬과 승인 프레임워크 정비입니다. 이미 1단계에 안착한 팀이라면 다음 투자처는 더 좋은 프롬프트가 아니라 자기 검증 루프(테스트·빌드·린트·e2e)와 자동 코드 리뷰입니다. 신뢰할 수 있는 검증 체계가 갖춰져야 '전부 읽어야 한다'는 부담이 풀리고 병렬화가 시작되기 때문입니다.

모던웹연구소는 1단계에 안착한 팀이 이 전환을 실습으로 익히도록 돕는 교육도 운영합니다. 자기 검증 루프를 만드는 테스트 주도 개발, 에이전트 팀 위임, Skills·CLAUDE.md 팀 표준화처럼 2단계와 3단계로 올라가는 데 필요한 기술을 직접 다룹니다. 2단계까지 온 팀이라면 남은 병목은 도구가 아니라 신뢰입니다. 루프가 신뢰를 얻기 전에 에이전트 수부터 늘리지 않는 것이 3단계로 가는 지름길입니다.

이 지도의 미덕은 단계마다 '다음에 무엇을 풀어야 하는가'를 특정해준다는 점입니다. 우리 팀이 몇 단계인지, 다음 단계를 막는 병목이 프로세스인지 신뢰인지 도구인지부터 진단해보세요. 3단계 도구가 궁금하다면 모던웹연구소가 정리한 루프 엔지니어링 가이드와 동적 워크플로우 정리가 출발점이 될 것입니다. 3단계의 가드레일인 토큰 비용 관리에 대한 고민은 Claude Code를 만든 엔지니어의 캐싱 설계를 통해 조직 스스로 답을 찾을 수 있습니다.

1. Boris Cherny(@bcherny), I talk to engineers at other companies every day…, X, 2026-07-16. 표 원문은 Steps of AI Adoption.

   ↩