Boris Cherny는 Claude Code를 만드는 Anthropic 엔지니어입니다. 여러 회사의 엔지니어를 매일 만나면서 같은 이야기를 반복해서 듣습니다. 한 사람은 Claude로 생산성을 10배로 끌어올렸는데, 조직의 나머지는 따라오지 못한다는 말입니다.
Deep Dive: "10배"는 타자가 빨라져서가 아니라 일의 성격이 바뀌어서 나오는 숫자입니다. 예전에는 "내가 코드를 쓴다"가 일이었다면, 이제는 "무엇을 원하는지 설명하고 나온 결과를 검토한다"가 일입니다. 구현이라는 노동을 AI가 대신 맡으니 같은 시간에 훨씬 많이 끝냅니다. 정밀한 수치라기보다 "AI를 안 쓰는 동료보다 압도적으로 많이 낸다"는 뜻입니다.
그는 팀이 AI를 받아들이는 과정을 지켜보며 똑같은 단계가 반복된다는 걸 발견했습니다. 그 단계를 "Steps of AI Adoption(AI 도입의 단계)"이라는 그림 한 장으로 정리하고, X와 Threads에 스레드로 풀어서 설명했습니다. 트윗에서는 "4단계"라고 불렀지만, 그림은 0단계부터 4단계까지 다섯 개의 상태로 나뉩니다. 0단계라는 출발점에서 시작해 네 번 올라선다는 뜻입니다.
두 개의 축
이 지도는 두 축으로 이루어집니다.
- 가로축: 동시에 부리는 에이전트 수입니다. 0개에서 1,000개 이상까지 늘어납니다.
- 세로축: 나의 역할입니다. 내가 직접 다 하는 사람에서, 방향만 정해 주는 사람으로 바뀝니다.
핵심은 하나입니다. 토큰을 더 많이 쓴다고 다음 단계로 가지 않습니다. 단계마다 새로운 병목을 찾아 부수고, 새로운 안전장치를 세워야 넘어갑니다.
다섯 단계
0단계: 차단(Gated)
- 에이전트: 0개.
- 역할: AI를 아직 쓰지 못합니다.
- 병목: 낡은 보안 정책, 토큰 비용부터 따지는 사고방식, 쓸 수 있게 열어 주는 승인 경로가 없다는 점.
- 넘어가려면: SSO·SCIM, 역할별 접근 권한, 조직 단위 예산 상한, 데이터 관리 규정.
1단계: 보조(Assisted)
- 에이전트: 약 1개. 사람과 짝을 이룹니다.
- 역할: 에이전트와 함께 일하고, 거의 모든 변경을 직접 검토합니다.
- 열리는 것: 오후 내내 걸리던 일을 회의 사이 짬에 끝냅니다.
- 병목: 나의 주의력입니다. 모든 결과를 실시간으로 검토해야 합니다.
- 넘어가려면: Plan Mode, 지출 상한, 중앙에서 관리하는 정책, OpenTelemetry 내보내기, 규정 준수 API.
2단계: 병렬(Parallel)
- 에이전트: 약 10개. 내가 조율자가 됩니다.
- 역할: 여러 worktree를 동시에 돌리며 조율합니다.
- 열리는 것: 팀이 한 주 동안 처리할 밀린 일을 하루 오후에 끝냅니다.
- 병목: 여러 갈래로 쏟아지는 결과물을 검토하기, 프롬프트로 방향 잡기.
- 넘어가려면: 자동 모드, 에이전트 뷰, 코드·보안 자동 검토, worktree 격리, 원격 제어, Chrome·모바일 시뮬레이터 MCP.
3단계: 감독하의 자율(Supervised Autonomy)
- 에이전트: 약 100개. 조직처럼 트리 구조를 이룹니다.
- 역할: 관리자들을 관리하는 사람이 됩니다. 질문이 "코드를 읽는다"에서 "어떤 맥락이 빠졌나"로 바뀝니다.
- 열리는 것: 따로 신경 쓰지 않아도 유지보수가 알아서 계속 돌아갑니다.
- 병목: 루프를 믿을 수 있는가, 팀의 의사결정 속도, 규모가 커질 때의 토큰 효율.
- 넘어가려면: 서브에이전트, /loop·/batch·/goal, 루틴, 샌드박스, CLAUDE.md와 Skills, 모델 선택, 비용 모니터링, 자동 모드 조정.
검토 기준도 바뀝니다. 이 단계에서 던지는 질문을 Cherny는 이렇게 정리합니다. "엔지니어라면 이렇게 했을까?"
Deep Dive: 한 사람이 100개를 직접 다 보지는 못합니다. 그래서 트리로 위임합니다. 관리자 에이전트 몇 개를 두고, 그 에이전트들이 각자 작업 에이전트를 부리는 "관리자의 관리자" 구조입니다. 100개를 손으로 켜는 게 아니라, 목표 하나를 주면 맨 위 에이전트가 대상을 찾아 작업을 나누고 곱셈으로 퍼집니다. 동시에 같은 저장소를 고치면 서로 파일을 덮어쓰고 테스트가 엉키니, worktree 격리로 에이전트마다 독립된 작업 폴더를 줘서 안 밟게 합니다. 작업 순서는 의존성으로 걸고, 각 작업은 테스트가 통과할 때까지 /loop로 스스로 재시도합니다.
4단계: AI 네이티브(AI-Native)
- 에이전트: 1,000개 이상.
- 역할: VP처럼 의도만 지시하고, 예외 상황만 지켜봅니다.
- 열리는 것: 한 분기가 걸리던 마이그레이션을 시작만 시켜 놓고 지켜보기만 합니다.
- 병목: 대규모로 일을 자동화하기, 작업마다 안전장치를 강제하기.
- 넘어가려면: Claude Agent SDK, Slack의 Claude Tag, 워크플로별 비용 상한, 예외 기반 모니터링, 대량 작업과 최전선 작업을 나눠 쓰는 모델 선택.
단계를 어떻게 올리나
Cherny는 스레드에서 이렇게 말합니다. 정답 경로는 없습니다. 팀도 회사도 저마다 다릅니다. 병목을 부수고 안전장치를 세우는 일을 어떤 기능으로 하느냐가 관건입니다.
Claude가 자기 작업을 처음부터 끝까지 스스로 검증하게 해 줍니다. 권한은 자동 모드로 열고, 코드 검토와 보안 검토를 기본으로 자동화합니다. 여러 에이전트를 한 번에 관리하는 화면을 씁니다. CLI의 에이전트 뷰, 데스크톱 앱, iOS·안드로이드 앱, Tag가 그런 화면입니다.
더 높은 단계로 가려면 /loop, /batch, 동적 워크플로, 서브에이전트용 worktree 격리를 씁니다. 기능 하나가 핵심이 아닙니다. 맞는 기능을 맞는 안전장치와 함께 써서, Claude가 한 부류의 일 전체를 자동으로 처리하게 만드는 것이 핵심입니다.
지금 어디까지 왔나
Anthropic은 3단계에 있고 4단계로 밀어붙이는 중입니다. 그리고 Cherny 자신은 막 4단계에 올라섰다고 말합니다.
출처
- 원문 트윗: Boris Cherny(@bcherny), https://x.com/bcherny/status/2077929379661844559
- Threads 스레드: Boris Cherny(@boris_cherny), https://www.threads.com/@boris_cherny/post/Da4CkQnEea-. 스레드 본문(첫 글 뒤 이어지는 후속 글)은 여기서 가져왔습니다.
- 아티팩트 "Steps of AI Adoption"(Claude Artifact): https://claude.ai/code/artifact/bfdfaef9-bc62-4dfe-ba9e-c58a26c9accf
- 아티팩트는 로그인해야 열리는 Claude Code 아티팩트라 자동으로 내용을 읽어 오지 못했습니다. 다섯 단계의 세부 항목(각 단계의 병목과 안전장치)은 이 틀을 그대로 옮긴 공개 정리 글 여러 개를 교차 확인해 재구성했습니다.
Deep Dive
2026-07-18
검토 사다리: 코드에서 의도로
이 프레임워크를 관통하는 한 축은 "내가 무엇을 검토하는가"가 점점 위로 올라간다는 겁니다. 검토 대상을 사다리로 보면 아래에서 위로 코드, 계획, 의도 순입니다.
- 코드: 실제 구현. 가장 자세하고 검토가 느립니다.
- 계획: 어떻게 할지의 접근법. "어느 파일을 이렇게 바꾸겠다".
- 의도: 원하는 결과 그 자체. 무엇을, 왜. 방법은 정하지 않습니다.
위로 올라갈수록 일당 검토량이 줄어 더 많은 일을 감독할 수 있습니다. 대신 안 보는 아래층을 믿어야 하니 신뢰가 더 필요합니다. 그래서 단계가 오를 때마다 "검토를 위로 올리기"와 "안전장치 쌓기"가 늘 짝을 이룹니다. 안전장치(자기 검증, 코드·보안 자동 검토)가 안 보는 층을 대신 지켜줘야 위층에서 편히 있을 수 있습니다.
각 단계가 이 사다리의 한 칸입니다. 1단계 Plan Mode는 diff를 사후에 다 읽는 대신 실행 전에 계획을 검토합니다. 3단계는 코드를 안 읽고 "어떤 맥락이 빠졌나"를 봅니다. 4단계는 의도만 주고 예외만 봅니다.
의도와 계획은 헷갈리기 쉽습니다. "결제 실패 시 재시도 버튼을 단다"는 방법을 이미 정했으니 계획입니다. 의도는 "결제가 실패해도 사용자가 이탈하지 않고 다시 시도하게 한다"입니다. 버튼은 그 의도를 이루는 한 가지 수단일 뿐입니다.
4단계의 SDK는 어떻게 트리거되나
4단계의 "Claude Agent SDK로 일을 시스템에 심는다"가 실제로 어떻게 도는지 헷갈리기 쉽습니다. 핵심은 두 가지입니다.
첫째, 레포는 실행되고 있는 게 아니라 그냥 파일 뭉치입니다. SDK도 라이브러리라 혼자 대기하지 않습니다. 누군가 프로세스를 띄워 실행 함수(query)를 불러줘야 그때 돕니다.
둘째, 그래서 "외부가 내 레포의 SDK를 직접 호출한다"는 그림은 성립하지 않습니다. 이벤트가 실행기를 띄우고, 그 실행기가 레포 복사본을 들고 SDK를 돌립니다. GitHub Action이 대표적입니다. @claude 멘션이나 스케줄이 오면 GitHub이 새 임시 컴퓨터를 띄우고, 레포를 복제하고, 거기서 SDK를 돌린 뒤 컴퓨터를 버립니다.
정리하면 어떤 경우든 "실행기(상시 서버, 일회용 함수, CI 러너, 큐 워커, 내 노트북) 곱하기 트리거(웹훅, 큐, 스케줄, 파일 변경, 사람)"의 조합입니다. 3단계의 루틴과 4단계의 SDK는 같은 뿌리입니다. 사람이 아니라 이벤트가 에이전트를 굴린다는 점이 같고, SDK는 트리거를 아무 이벤트로 넓히고 에이전트를 시스템의 부품으로 심는 데까지 키운 것입니다. 규모가 커지면 큐에 작업을 쌓고 워커 여러 개가 병렬로 빼서 처리하는 쪽으로 갑니다.
Key Insight
AI 도입의 단계가 오른다는 것은 내가 검토하는 자리가 코드에서 계획으로, 다시 의도로 올라가는 것이다. 위로 갈수록 일은 덜 하고 더 많이 위임하지만, 안 보는 아래층을 대신 지켜줄 안전장치를 그만큼 더 쌓아야 한다. 사람이 아니라 이벤트가 에이전트를 굴리게 만드는 것(루틴에서 SDK로)이 그 위임의 실제 수단이다.