혼자만 10배, 조직은 그대로 — Claude Code 개발자가 제시한 "AI 도입 4단계"

Claude Code 개발자인 Boris Cherny가 흥미로운 포스트를 하나 올렸습니다.

I talk to engineers at other companies every day and hear the same thing: one person is 10x'ing their output with Claude but the rest of the org hasn't caught up.

Watching teams adopt AI, I keep seeing the same 4 steps.

I mapped them out here: Steps of AI Adoption…

— Boris Cherny (@bcherny) 2026년 7월 17일

(매일 다른 회사 엔지니어들과 이야기하는데 늘 같은 말을 듣습니다. 한 사람은 Claude로 산출량을 10배로 끌어올렸는데, 조직의 나머지는 아직 따라오지 못했다고요. 팀들이 AI를 도입하는 걸 지켜보면 늘 같은 4단계가 보입니다. 여기에 정리했습니다: Steps of AI Adoption…)

그는 매일 다양한 기업의 엔지니어와 이야기하는 중에 같은 이야기를 몇 번이고 듣는다고 해요.

한 엔지니어는 Claude를 써서 이전의 10배 가까운 산출을 내고 있다. 그런데 같은 조직의 다른 사람들은 아직 거기에 도달하지 못했다.

이 현상, 제 주변에서도 자주 봅니다.

AI를 쓰기 시작한 사람 중에는 몇 달 만에 일하는 방식이 완전히 바뀌는 사람이 있어요. 한편 같은 회사, 같은 툴, 같은 모델을 쓰면서도 기존 방식에서 거의 벗어나지 못하는 사람도 있어요.

다만 이건 단순히 "AI를 잘 쓰는 사람과 못 쓰는 사람의 차이"가 아닙니다.

Boris의 포스트를 읽어 보면, 개인의 역량보다 조직 쪽 구조의 문제가 크다는 걸 알 수 있어요.

AI를 나눠 준 것만으로는 도입한 게 아니다

그는 AI 도입을 스텝 0부터 스텝 4까지 단계로 나눕니다.

Cherny의 원문 자료 기준으로 각 단계의 명칭과 에이전트 규모는 다음과 같습니다 — 스텝 0: Gated(에이전트 0), 스텝 1: Assisted(1), 스텝 2: Parallel(약 10), 스텝 3: Supervised autonomy(약 100), 스텝 4: AI-native(1,000 이상, 의도로 조종). Anthropic은 스텝 3에서 4로 진행 중이고, Cherny 본인은 스텝 4에 도달했다고 밝혔습니다.

스텝 0은 애초에 AI를 충분히 못 쓰는 상태입니다. 이용 가능한 모델이 제한되어 있거나, 사내 승인을 통과하는 데만 시간이 걸리거나, 생성한 코드를 공개할 경로가 없거나, 외부 툴과의 연결 규칙이 정해져 있지 않은 상태입니다.

이 단계에서는 현장에 AI 사용법을 가르쳐도 별 의미가 없어요.

과제는 사용법이 아니라 이용 허가, 정보 관리, 권한, 비용, 공개 절차 같은 것들을 정비하는 일이기 때문입니다.

회사가 AI 이용료를 아낄 궁리만 하고, AI로 무엇을 만들어 낼지를 생각하지 않는 경우에도 여기서 앞으로 나아가기 어려워져요.

많은 기업은 "일대일" 단계에 있다

AI를 쓸 수 있게 되면, 다음은 사람 한 명과 AI 하나가 함께 작업하는 단계에 들어갑니다.

사람이 의뢰하고, AI가 구현하고, 사람이 변경 내용을 확인한다. 지금까지 반나절 걸리던 변경이 회의와 회의 사이에 끝납니다.

이 단계만 돼도 생산성은 꽤 올라갑니다.

하지만 사람은 AI의 작업을 옆에서 계속 지켜보고 있습니다. 무언가 바꿀 때마다 내용을 읽고, 허가를 내주고, 결과를 확인합니다.

즉 AI는 빨라졌지만, 사람은 그 자리를 떠나지 못합니다.

AI의 처리 속도가 아니라, 사람이 확인할 수 있는 양이 상한이 됩니다.

많은 기업은 이 상태를 "AI 도입이 진행됐다"고 여깁니다. 하지만 실제로는 사람의 작업을 AI로 대체했다기보다, 아주 빠른 작업자를 옆에 두고 사람이 곁에 붙어 감독하고 있는 상태입니다.

여러 AI를 돌리면, 이번에는 리뷰가 막힌다

다음 단계에서는 한 사람이 여러 AI를 동시에 돌립니다.

각각을 다른 작업 환경에서 돌리고, 구현뿐 아니라 테스트, 빌드, 타입 검사, 보안 검사까지 AI에게 실행시킵니다. 사람은 작업 과정을 전부 지켜보는 게 아니라 마지막에 나온 변경 내용을 확인합니다.

여기까지 오면 산출량이 크게 늘어납니다.

그런데 새로운 문제가 생깁니다.

사람이 쓰는 코드는 줄지만, 확인해야 하는 코드는 늘기 때문입니다.

Anthropic 자신도 엔지니어 1인당 코드 산출량이 늘어난 결과 코드 리뷰가 병목이 되었다고 설명하고 있습니다. 이 회사는 그 대책으로 여러 AI가 병렬로 버그를 찾고, 오탐을 걸러내고, 중요도를 판단하는 코드 리뷰 기능을 도입했습니다.

여기서 말하는 기능은 Anthropic이 2026년 3월 공개한 Claude Code의 "Code Review"(멀티 에이전트 PR 리뷰, Teams·Enterprise용 리서치 프리뷰)입니다. Anthropic 공식 발표에 따르면 사내 도입 후 실질적인 리뷰 코멘트가 달리는 PR 비율이 16%에서 54%로 올랐습니다.

공식 소개: https://claude.com/blog/code-review

여기서 알 수 있는 건, AI로 한 공정을 빠르게 만들면 그 뒤 공정이 막힌다는 사실입니다.

구현이 빨라지면 리뷰가 막힙니다. 리뷰를 빠르게 하면 승인과 공개가 막힙니다. 공개를 빠르게 하면 품질 관리와 고객 대응이 막힙니다.

AI 도입이란 단순히 생성 속도를 올리는 게 아닙니다. 빨라진 공정에 맞춰 일 전체의 흐름을 다시 짜는 것입니다.

자율화에 필요한 건 더 긴 지시문이 아니다

더 나아가면, AI는 사람에게서 한 건씩 지시받는 게 아니라 유지보수, 수정, 정리, 모니터링 같은 일을 스스로 시작하게 됩니다.

이 단계에 오면 사람이 던지는 질문이 바뀝니다.

"AI가 쓴 코드를 전부 읽었는가"가 아니라, "왜 AI는 이 판단을 틀렸는가", "어떤 컨텍스트가 부족했는가", "다음부터 같은 실패를 막으려면 무엇을 구조에 남겨야 하는가"를 생각하게 됩니다.

저 자신도 Claude Code를 쓰면서 프로젝트의 전제를 CLAUDE.md에 두고, 평가 기준을 Rules로 나누고, 전문적인 검사는 Skills로 들려 주고, 구현하는 AI와 평가하는 AI를 분리하게 됐습니다.

처음에는 AI에게 긴 지시를 쓰면 정확도가 올라갈 거라고 생각했어요.

하지만 실제로 필요했던 건 매번 지시를 잘 쓰는 게 아니었습니다.

내가 무엇을 옳다고 판단하는가. 무엇을 위험하다고 보는가. 어떤 상태를 완성으로 판단하는가. 그 기준을 AI가 반복해서 쓸 수 있는 형태로 저장하는 일이었습니다.

이건 AI 설정을 세밀하게 만드는 이야기가 아닙니다.

사람 안에 있던 판단을 조직의 자산으로 바꾸는 이야기입니다.

가드레일은 AI를 멈추기 위한 것이 아니다

AI를 자율적으로 돌리려고 하면 권한을 내주는 게 불안해집니다.

그래서 가드레일을 AI의 행동을 제한하는 장치라고 생각하기 쉬워요.

그런데 실제로는 반대예요.

테스트가 있으니까 AI에게 구현을 맡길 수 있습니다. 작업 환경이 분리되어 있으니까 여러 AI를 동시에 돌릴 수 있습니다. 자동 리뷰가 있으니까 사람이 전부를 처음부터 읽지 않아도 됩니다. 비용 상한이 있으니까 정기 처리를 자동화할 수 있습니다.

가드레일은 자율성의 반대가 아니라, 자율성을 성립시키는 조건이에요.

Anthropic의 보안 관련 실천에서도, 결함이나 취약점을 찾는 처리 자체는 병렬화하기 쉬운 반면 그 뒤의 검증, 정리, 우선순위 결정, 수정이 병목이 된다고 설명하고 있습니다. 그래서 먼저 위협 정의와 격리된 검증 환경을 준비하고, 그 위에서 발견, 검증, 정리, 수정을 반복하는 구성이 권장됩니다.

AI에게 일을 맡기려면 "자유롭게 움직여도 된다"고 전하는 것만으로는 부족합니다.

무엇을 확인하고, 어디까지 되면 완료이고, 실패했을 때 어디로 돌아가는지를 설계해야 합니다.

스텝 4를 전체 업무의 목표로 삼을 필요는 없다

Boris는 Anthropic이 스텝 3에서 4로 나아가고 있고, 자신은 스텝 4에 도달했다고 말합니다.

다만 모든 회사, 모든 일이 스텝 4를 노릴 필요는 없다고 봅니다.

자동 테스트 작성, 문서 정리, 정기적인 의존성 업데이트 같은 건 높은 자율성과 잘 맞을 겁니다.

한편 인증 기반 변경, 결제, 개인정보, 법무 판단 같은 건 같은 회사 안에서도 사람의 확인을 두껍게 남겨야 합니다.

따라서 회사 전체가 하나의 단계에 있다고 생각하기보다, 일의 종류마다 단계가 다르다고 보는 편이 정확합니다.

중요한 건 에이전트 수를 늘리는 게 아닙니다.

오류를 감지하기 쉽고, 실패해도 되돌릴 수 있는 일부터 자율화하는 것입니다.

AI의 효과를 사용 횟수로 재면 안 된다

포스트에서는 AI 도입 후의 효과 측정도 다룹니다.

이용자 수, 실행 횟수, 토큰 수 같은 건 들여다볼 가치가 있습니다. 하지만 그것들이 재는 건 활동량이지 성과가 아닙니다.

Boris는 "그 일을 AI가 없었어도 엔지니어가 했을까", "했다면 몇 시간 걸리고 얼마가 필요했을까"를 생각해야 한다고 말합니다.

이건 사용 횟수보다 꽤 나은 사고방식이에요.

다만 저는 하나 더 보태야 한다고 생각합니다.

AI의 가치는 기존 작업 시간을 줄인 것만이 아닙니다.

지금까지 비용이나 인력 문제로 손대지 못했던 유지보수, 정리, 조사, 검증, 개선을 실행할 수 있게 된 가치도 있습니다.

그래서 AI의 실질적인 리턴은 다음처럼 생각하는 편이 실상에 가깝다고 봅니다.

**AI의 실질적인 리턴 = 줄어든 사람의 작업 시간

• 이전에는 손대지 못했던 일의 가치 − AI 이용료 − 리뷰, 재작업, 장애 대응 비용**

AI로 인건비를 줄이기만 해서는 작은 개선에 그쳐요.

정말 큰 변화는 지금까지 대상 밖이던 일을 지속적으로 실행할 수 있게 됐을 때 일어납니다.

한 사람의 10배를 조직의 10배로 바꾼다

AI를 쓸 줄 아는 사람이 하나 나타나도 조직 전체가 바뀐다는 보장은 없습니다.

그 사람이 대량의 결과물을 만들어도 리뷰, 승인, 공개, 운영이 기존 그대로라면, 다른 자리에 일이 쌓일 뿐입니다.

한 사람의 10배를 조직의 성과로 바꾸려면 AI의 산출을 검증하고, 받아들이고, 공개하고, 실패에서 배우는 구조가 필요해요.

앞으로 중요해지는 건 누가 AI에게 지시를 제일 잘하느냐가 아닙니다.

조직의 판단 기준을 컨텍스트로 저장하고, 필요할 때 AI에게 건네고, 실행 결과를 자동으로 검증하고, 예외만 사람이 판단할 수 있는 상태를 만들어 낼 수 있느냐입니다.

AI를 쓸 줄 아는 사람을 늘리는 것만으로는 부족합니다.

AI에게 맡길 수 있는 일을, 검증 가능한 형태로 늘리는 것.

그게 진짜 AI 도입이라고 생각합니다.