AI는 당신이 던져주는 거의 모든 소프트웨어 조각을 만들어낼 수 있을 만큼 똑똑합니다. 동시에 당신이 실제로 필요로 했던 것과 정반대의 것을 만들어낼 만큼 멍청하기도 합니다. 이 두 가지는 동시에 사실이며, 이 간극이야말로 현재의 모든 **프레임워크 논의 (framework conversation)**가 계속해서 간과하고 있는 부분입니다.

본격적으로 시작하기 전에 간단한 질문을 하나 드리겠습니다. **현재 당신의 AI 성숙도 (AI maturity level)**는 어느 정도인가요? 네, 맞습니다. 당신과 당신의 AI를 의미합니다. 당신이 원하든 원하지 않든, 이제 두 사람은 하나의 팀입니다 🤓.

Search Console 사고 사례

여러 사이트에 대한 여러 개의 **Search Console 속성 (Search Console properties)**을 관리하고 있으며, 그 어떤 규칙보다 중요한 단 하나의 규칙이 '그들의 흔적이 절대 서로 닿지 않아야 한다'는 설정 상황을 상상해 보세요. 속성 간에 크롤링 패턴, 사이트맵 제출 등 그 어떤 것도 교차해서는 안 됩니다. 이는 왜 존재하는지 이해하고 나면 너무나 당연하게 느껴지기 때문에, 굳이 어디에도 적어둘 필요가 없는 종류의 제약 조건입니다.

Claude Code는 그것이 왜 존재하는지 이해하지 못했습니다. 그저 완료해야 할 작업이 있었을 뿐입니다.

높은 자율성 모드 (high-autonomy mode)로 실행되던 Claude Code는 해당 작업을 해결하기 위한 더 효율적인 기술적 경로를 찾아냈습니다. 그 경로는 우연히 다른 계정을 거쳐가게 되었습니다. 순수하게 "작업이 완료되었는가"라는 관점에서 보면, 그것은 완벽하게 작동했습니다. 하지만 몇 달 동안 보호되어 온 격리 상태가 단 한 번의 커밋 (commit)으로 사라져 버렸습니다.

물론 에이전트 (agent)가 일반적인 의미에서 실수를 저지른 것은 아닙니다. 요청받은 일을 정확히 수행했으며, 어쩌면 주니어 개발자보다 더 잘 해냈을지도 모릅니다. 단지 그 격리가 애초에 왜 중요한지 알지 못했을 뿐입니다. 그리고 그 간극(작업을 올바르게 수행하는 것과 작업이 왜 존재하는지 이해하는 것 사이의 공간)이야말로 현재의 AI 도입 점수표 (AI adoption scorecards)가 측정하지 못하는 바로 그 지점입니다.

Boris Cherny의 5단계, 쉬운 설명으로

Claude Code를 만든 Boris Cherny는 2026년 7월 17일, 엔지니어링 팀 전반에서 관찰한 AI 도입의 5단계를 정리한 스레드를 게시했습니다. 이는 제가 본 가장 깔끔한 실행 사다리(execution ladder)이며, 아래의 모든 내용이 이 단계를 바탕으로 구축되기 때문에 살펴볼 가치가 있습니다.

Step 0, 제한됨 (Gated). AI가 중요한 것에는 전혀 손을 대지 않습니다. 아마도 자동 완성 (autocomplete) 기능이거나, 아무도 두 번씩 열어보지 않는 챗봇 탭 정도일 것입니다.

Step 1, 보조 (Assisted). 당신과 하나의 에이전트 (agent)가 나란히 협업합니다. 여전히 모든 결정은 당신이 내리며, 에이전트는 매우 빠른 인턴 역할을 합니다.

Step 2, 병렬 (Parallel). 이제 당신은 오케스트레이터 (orchestrator) 역할을 수행하며, 5개에서 10개 사이의 에이전트를 각각의 워크트리 (worktree)에서 동시에 실행합니다. 이 단계에서는 당신이 직접 구축한 CLI가 이전에 사용하던 그 어떤 GUI 대시보드보다 더 중요해지기 시작합니다 (직접 구축해야 하는 이유에 대한 전체 논거가 궁금하다면, 왜 CLI가 에이전트 오케스트레이션을 위해 MCP보다 우수한지에서 더 자세히 다루었습니다).

Step 3, 감독 하의 자율성 (Supervised autonomy). 당신은 매니저들의 매니저가 되었습니다. 에이전트들이 서로의 작업을 검토하고, 자동 모드 (auto mode)가 일상적인 머지 (merge)를 처리하며, 당신은 예외적인 상황에만 개입합니다.

Step 4, AI 네이티브 (AI-native). 당신은 작업 (task)이 아닌 의도 (intent)에 따라 조종하는 부사장 (VP)입니다. 1,000개 이상의 에이전트가 있으며, 당신은 더 이상 디프 (diff)를 읽지 않고 결과 (outcomes)를 읽습니다. 이 단계는 이 프레임워크의 **사각지대 (blind spot)**가 가장 빠르게 비용을 발생시키는 단계입니다. 의도에 따라 조종하는 부사장은 결코 눈길조차 주지 않을 디프 속에서 Search-Console 스타일의 실수를 발견할 수 없습니다.

명시적으로 언급할 가치가 있는 점은, 각 단계가 올라갈 때마다 단순히 문제에 더 많은 토큰 (tokens)을 투입하는 것이 아니라 **가드레일 (guardrails)**을 추가한다는 것입니다. 실제 제한 사항이 적용된 자동 모드, 단순한 린터 (linter) 수준을 넘어선 자동화된 코드 리뷰, 그리고 한 에이전트의 실수가 다른 에이전트에게 전이되지 않도록 하는 워크트리 격리 (worktree isolation) 등이 이에 해당합니다. Cherny의 프레임워크는 "더 많은 줄을 주라"는 것이 아닙니다. "더 많은 줄을 주되, 더 나은 레일(rails)을 함께 주라"는 것입니다.

이 프레임워크가 측정하지 못하는 것

여기서 정확히 짚고 넘어가고 싶습니다. 5단계 사다리를 보며 고개를 끄덕이다가, 그것이 실제로 무엇에 대한 사다리인지를 놓치기 쉽기 때문입니다.

Cherny의 모든 단계는 **실행 자율성 (execution autonomy)**을 측정합니다. 즉, 당신이 지켜보지 않고 얼마나 많은 에이전트가 실행되는지, 그리고 시스템이 망가지기 전까지 기술적 감독 (technical supervision)을 얼마나 제거할 수 있는지를 의미합니다. 이는 진정으로 유용한 축이며, 만약 당신이 다른 팀과 비교했을 때 현재 어느 위치에 있는지 파악하려 한다면 가장 먼저 확인해야 할 올바른 기준입니다.

하지만 이 단계가 전혀, 조금도 측정하지 못하는 것이 있는데, 바로 **판단 교정 (judgment calibration)**입니다. 즉, 에이전트가 단순히 작업을 완료하는 법뿐만 아니라, 왜 그 작업이 존재하는지를 이해하고 있는지에 대한 부분입니다. 공정하게 말하자면 Cherny가 그 반대의 주장을 한 적은 없으며, 이는 그의 글을 비판하는 것도 아닙니다. 다만 이 프레임워크가 설계될 때부터 다루지 않았던 두 번째 축일 뿐입니다. 5단계 사다리를 훑어보다 보면 이 점을 놓치기 쉬우며, 바로 이 지점에서 상황이 잘못되기 시작합니다.

자율주행 자동차와의 유사성

여기에는 자율주행 자동차에 사용되는 산업 등급 시스템인 **SAE 자율주행 단계 (SAE autonomy scale)**와 꽤 유사한 평행 이론이 존재합니다. 레벨 0(자동화 전혀 없음)부터 레벨 5(완전 자율주행, 인간 불필요)까지의 단계가 그것입니다. 산업 분야는 다르지만, 측정하는 방식은 정확히 동일합니다.

레벨 4 자동차는 완벽하게 브레이크를 밟고, 깔끔하게 차선을 변경하며, 금요일 퇴근길의 대부분의 인간보다 고속도로를 더 잘 주행할 수 있습니다. 하지만 훈련 데이터 세트(training set)에 없는 패턴으로 주황색 깃발을 흔드는 작업자가 있는 임시 공사 우회로에 놓이게 되면, 이 자동차는 훈련된 작업 이외의 세상에 대한 모델을 가지고 있지 않습니다. 자동차는 자신이 무엇을 모르는지조차 모릅니다. 잠시 멈춰서 할 수 없다고 말해주는 HAL 9000 같은 순간은 없습니다. 그저 자신이 하도록 만들어진 일을, 그 일이 잘못된 맥락임에도 불구하고 자신 있게 수행할 뿐이며, 두 번째 시도에서도 똑같이 자신 있게 수행할 것입니다. 왜냐하면 깔끔하게 컴파일되는 잘못된 답변에는 무언가 잘못되었다는 것을 알려주는 정보가 전혀 없기 때문입니다.

높은 실행 단계에 있는 코딩 에이전트도 마찬가지입니다. 단계가 높고 SAE 레벨이 높다는 것이, 해당 에이전트가 자신이 무엇을 왜 하고 있는지에 대해 더 많이 이해한다는 것을 의미하지는 않습니다. 단지 누군가 잘못되었다는 것을 알아차리기 전에, 더 많은 일을 더 빠르게 수행할 뿐입니다.

스스로 점수 매기기: 3가지 질문

좋습니다, 이론은 이쯤 하죠. 당신은 실제로 어느 위치에 있나요? 3가지 질문입니다. 솔직하게 답하세요. 판단은 하지 않겠습니다 (음, 약간의 판단은 하겠지만, 어쨌든 이건 기사니까요).

1. 평상시에 얼마나 많은 Claude Code 세션을 병렬로 실행하나요?

• 1개, 많아야 2개이며 두 세션 모두 면밀히 지켜보고 있다 → Step 1, 대략 SAE Level 2
• 5개에서 10개 사이이며, 각각 별도의 워크트리 (worktree)에서 실행하고 주기적으로 확인한다 → Step 2, 대략 SAE Level 3
• 10개 이상이며, 대부분 작업이 완료된 후에야 무언가 실행되었음을 알게 된다 → Step 3, 대략 SAE Level 4

2. 작업이 "완료"되었다고 간주되기 전에 실제로 어떤 일이 일어나나요?

• 병합 (merging) 하기 전에 모든 코드를 한 줄씩 읽는다 → Step 1
• 차이점 (diff)을 샘플 점검하고, 테스트를 실행하며, 신뢰하되 검증한다 → Step 2에서 Step 3
• 자동화된 체크를 통과하면 에이전트 (agent)가 스스로 병합하며, 나는 CI 알림을 통해 이를 알게 된다 → Step 3에서 Step 4

3. 권한 (permissions)을 어떻게 관리하나요?

• 기본적으로 거의 모든 것에 대해 수동 승인을 한다 → Step 0에서 Step 1
• 안전한 작업에는 자동 모드 (auto mode)를 사용하고, 프로덕션 (prod)이나 외부 계정에 영향을 주는 작업에는 수동 모드를 사용한다 → Step 2에서 Step 3
• 모든 곳에서 자동 모드를 사용하며, 내가 아닌 가드레일 (guardrails)이 필터링을 수행한다 → Step 3에서 Step 4

참고 삼아 제 위치를 말씀드리자면: Step 3, SAE Level 4입니다. 평상시에 5개에서 10개의 워크트리 (worktrees)를 사용하며, Claude는 대부분의 경우 제가 개입하지 않아도 스스로 작업 내용을 검증하고 병합합니다 (그리고 아직 완전히 파악하지 못한 이유로, Sonnet은 이 특정 패턴에서 Opus에 비해 진심으로 어려움을 겪습니다). 제가 명시적으로 제한을 걸어둔 몇 가지 작업을 제외하고는 거의 모든 곳에서 자동 모드가 실행됩니다. 실행 자율성 (execution autonomy)이 매우 높습니다. 그리고 앞서 언급한 Search Console 이야기처럼, 그 점수는 에이전트가 애초에 왜 그 제한(gate)이 존재했는지 이해했는지에 대해서는 아무것도 알려주지 않았습니다.

각 단계에서 무엇이 무너지는가

Step 0 또는 Step 1에서는 오류가 발생해도 시간만 낭비될 뿐입니다. 짜증은 나겠지만 비용은 저렴하며, 처음 10분 안에 잡아낼 수 있을 정도로 충분히 면밀히 지켜보고 있었기 때문에 점심시간쯤이면 이미 잊어버리게 됩니다.

2단계와 3단계에서는 양상이 완전히 달라집니다. 에이전트(Agent)는 기술적으로는 옳지만 전략적으로는 틀린 방향으로 최적화할 수 있으며, 출력된 결과물 중 그 어떤 것도 고장 난 것처럼 보이지 않습니다. 테스트는 통과하고, 코드는 컴파일되며, 실패 상태가 최소한 스스로를 정직하게 드러내는 게임에서처럼 "당신은 죽었습니다"라고 말하는 빨간 화면도 나타나지 않습니다. Search Console 격리 기능은 어떤 코드 리뷰어라도 눈 하나 깜짝하지 않고 승인했을 법한 깔끔하고 효율적인 커밋(Commit)에 의해 깨져버렸습니다.

이것과는 무관한 짧은 이야기지만, 제 실제 책상 설정은 모니터가 3대인데도 순전히 습관 때문에 결국 가장 작은 모니터에서 디버깅을 하게 됩니다. 어쨌든.

얼마 전 저는 이와 관련된 실패 모드(Failure mode)를 깊이 파고든 적이 있습니다. 근본적인 원인은 동일합니다. 즉, 실행 능력(Execution competence)은 높지만, 당면한 과제 너머로 "정확함"이 무엇을 의미하는지에 대한 모델(Model)이 전혀 없는 에이전트들이 해결해야 할 대상이 여전히 고장 난 상태임에도 성공했다고 보고하는 경우입니다. 만약 이 패턴이 익숙하게 들리기 시작한다면 읽어볼 가치가 있습니다.

진짜 지렛대는 더 많은 프레이밍(Framing)이다

만약 다른 사람이 쓴 글이었다면 저는 반박했을 것입니다. 높은 단계(High-step)의 위험을 해결하는 방법은 실행 자율성(Execution autonomy)을 늦추는 것이 아닙니다. 3단계에 도달할 자격을 갖춘 에이전트로부터 워크트리(Worktree)를 빼앗는다고 해서 에이전트가 당신의 비즈니스를 더 잘 이해하게 되는 것은 아닙니다. 그저 이해하지 못하는 속도만 느려질 뿐입니다.

진짜 지렛대는 에이전트가 실제로 읽을 수 있는 어딘가에 비즈니스 컨텍스트(Business context)를 명시적으로 만드는 것입니다. 암시적인 제약 조건 대신 명시된 제약 조건을, 공유된 지식으로 가정하는 대신 문서화된 목표를 제공하는 것입니다. 이것이 바로 CLAUDE.md가 실제로 존재하는 이유입니다. 아무도 읽지 않는 변경 로그(Changelog)가 아니라, 에이전트가 결코 포함될 리 없는 작업 설명(Task description)으로부터 "이유(Why)"를 재구성할 필요가 없도록 그 "이유"가 살아있는 장소 말입니다(작동 원리에 대해 더 깊이 알고 싶다면 CLAUDE.md를 README가 아닌 설정 파일(Config file)처럼 취급하는 것에 대해 작성한 글을 참고하세요).

제 생각에는, 그리고 아마 소규모 팀을 넘어 얼마나 확장될 수 있는지에 대해서는 제가 틀렸을 수도 있지만, 제약 사항을 명시적으로 프레임화(framing)했다면 Search Console 문제가 배포되기 전에 잡아낼 수 있었을 것입니다. 에이전트가 더 똑똑해졌기 때문이 아니라, 에이전트가 추측해야 하는 상황을 멈추게 했기 때문입니다.

기존의 엉망인 상태에 사후 적용하는 것이 아니라 처음부터 이를 구축하고 있다면, _Vibe Coding, For Real_의 Blueprint method는 에이전트에게 실제 자율성을 부여하기 전에 이러한 종류의 컨텍스트(context)가 정확히 어디에 위치해야 하는지를 단계별로 설명합니다.

여기서 한 가지 솔직한 주의 사항이 있습니다: 프레임화는 위험을 줄여주지만, 완전히 없애주지는 않습니다. 판단력 교정(judgment calibration)을 해결된 문제로 만들 만큼 완벽한 CLAUDE.md를 배포한 사람은 아무도 없습니다. 당신은 놀라운 상황을 '제로'로 만드는 것이 아니라, '더 적게' 겪게 되는 것입니다.

저는 제 Step 3 점수가 완전히 잘못된 것을 측정하고 있다는 사실을 깨닫기 전까지, 그 점수를 자랑스러워하며 너무 오랜 시간을 보냈습니다 😅

더 많은 프레임화 없이 실행(execution)만 늘리는 것은 그저 벽에 더 빨리 부딪히는 것을 의미할 뿐입니다.

출처

• Boris Cherny의 AI 도입 5단계에 관한 스레드, 2026년 7월 17일 게시

이 포스트에는 제휴 링크가 포함되어 있을 수 있습니다. 링크를 클릭하시면 저에게 소정의 수수료가 지급될 수 있습니다 (귀하에게 비용이 발생하지 않으며, 제가 매일 여러분의 즐거운 독서를 위해 양질의 기사를 계속 발행하는 데 도움이 됩니다).