Anthropic이 Workflows를 출시한 바로 그 주에 당신의 회사는 Claude Code를 금지했습니다.

이 타이밍은 기록할 가치가 있습니다. Microsoft의 Experiences and Devices 부서가 6월 30일 마감 기한을 두고 라이선스 취소 절차를 마무리하고 있던 동안, Anthropic은 단 한 명의 개발자가 터미널에서 1,000개의 에이전트를 병렬로 (in parallel) 오케스트레이션할 수 있는 기능을 발표했습니다. Claude는 자체적인 JavaScript harness를 작성합니다. 결과는 컨텍스트 윈도우 (context window)가 아닌 **스크립트 변수 (script variables)**에 담깁니다. 에이전트들이 백그라운드에서 작동하는 동안 세션은 **응답성 (responsive)**을 유지합니다. 이것이 2026년 6월 2일에 출시되었습니다.

요약 (TLDR): Uber는 4개월 만에 AI 예산 **34억 달러 ($3.4 billion)**를 소진했습니다. Microsoft는 6월 말 이전에 Claude Code 라이선스를 삭감하며 대응했습니다. 그 다음 주, Anthropic은 Workflows를 출시했습니다: 실행당 1,000개의 에이전트, 병렬 오케스트레이션, 응답형 세션. 비용 결정은 5월 데이터를 바탕으로 내려졌습니다. 6월에 변한 것은 계산식에 포함되지 않았습니다.

이 금지 조치는 비용 통제의 이야기로 읽힙니다. 심지어 합리적으로 보이기까지 합니다. 하지만 같은 주에 무엇이 출시되었는지를 보기 전까지는 말이죠.

인보이스(Invoice) 문제

Uber의 수치는 5월에 집계되었으며, 이는 처리하기 매우 힘든 수준입니다. 5,000명의 엔지니어. 2026년 4월까지 채택률은 **95%**로 상승했습니다. 엔지니어 1인당 API 비용은 월 500달러에서 2,000달러 사이였습니다. 회사는 2026년 AI 예산 전체인 34억 달러를 4개월 만에 다 써버렸습니다.

질문할 수 있는 양에 제한이 없는 5,000명의 엔지니어는 AI 채택 이야기라기보다는

그 결정은 5월의 데이터를 사용하여 6월 초에 최종 확정되었습니다. Anthropic이 6월 2일에 출시한 것은 그 누구의 예측 범위에도 없었습니다.

금지는 두더지 잡기 게임과 같다

무엇이 출시되었는지 논하기 전에, 보안 팀의 입장도 공정하게 살펴봅시다. Shadow AI (그림자 AI) 수치는 실재합니다.

CybSafe/NCA 연구에 따르면 직원의 38%가 허가 없이 AI 도구와 민감한 정보를 공유하는 것으로 나타났습니다. Harmonic Security는 IT 부서가 확인할 수 없는 개인 계정에서 민감한 데이터가 노출된 사례를 거의 100,000건 추적했습니다. ManageEngine의 설문 조사에서는 직원의 **93%**가 승인되지 않은 AI 도구에 회사 정보를 입력한 적이 있다고 답했습니다. 이는 실질적인 거버넌스 (Governance) 격차를 나타내며, 이를 메우려는 보안 팀이 위기를 조작하고 있는 것이 아닙니다.

하지만 이러한 수치는 위험 범주를 설명할 뿐, Microsoft가 방금 스스로 만들어낸 구체적인 문제는 설명하지 못합니다. Deloitte 2026 State of AI in the Enterprise 보고서에 따르면, 성숙한 AI 거버넌스 모델을 갖춘 기업은 5개 기업 중 1개에 불과했습니다. 나머지 4개 기업은 금지를 통해 아무것도 해결하지 못했습니다. 그들은 문제를 불투명하게 만들었을 뿐입니다. 로그는 깨끗해 보이지만, 프롬프트 (Prompt)는 멈추지 않았습니다.

LayerX의 2026 Enterprise Browser Extension Security 보고서는 이 점을 정확히 짚어냅니다. Microsoft 자체 기업용 브라우저 도구인 Agent 365는 개인 브라우저 계정에서 Claude로 제출된 프롬프트에 대해 가시성 (Visibility)이 전혀 없습니다. 금지 조치는 기업의 결제 항목만 제거했을 뿐입니다. 그 외의 모든 것(행동, 도구 접근, 접근 권한이 있는 개발자와 승인을 기다리는 개발자 사이의 벌어지는 격차)은 계속되었습니다.

Workflows 출시 이후 변하는 것은 개발자가 개인 계정을 사용할 때의 결제 주소만이 아닙니다. 활동의 범주 (Category of activity) 자체가 변합니다. Workflows 이전의 Shadow AI는 개발자가 로그를 남기지 않고 Claude에게 함수의 자동 완성 (Autocomplete)을 요청하는 것을 의미했습니다. Workflows 이후의 Shadow AI는 개발자가 회의에 참석하는 동안 코드베이스를 대상으로 1,000개의 병렬 에이전트 (Agent)를 실행하는 것을 의미합니다. 93%라는 통계치는 Shadow AI가 텍스트 제안 도구였던 세상에서 측정된 것입니다. 그 세상은 6월 2일에 끝났습니다.

당신은 도구를 금지했습니다. 하지만 그 격차를 금지한 것은 아닙니다.

당신이 보지 못하는 사이에 변한 것들

6월 2일 이전의 Claude Code는 강력한 코드 어시스턴트(code assistant)였습니다. 당신이 필요한 것을 설명하면 대부분의 경우 유용한 결과물을 만들어냈습니다. 빨랐고, 종종 당신이 직접 만든 결과물보다 형식이 잘 갖춰져 있었으며, 가끔은 중요한 부분에서 틀리기도 했습니다. (솔직히 인정하세요, 틀렸을 때 당신은 보통 스스로가 아니라 리뷰어를 통해 그 사실을 알게 되곤 했습니다.) 생산성에 대한 설명은 정직했습니다. 대부분의 작업에서 30%에서 40% 더 빠르다는 것이었습니다. 그 프레임워크는 정확했습니다.

2026년 6월 2일 연구 프리뷰(research preview)로 출시된 Workflows는 기존 모델의 업데이트가 아닙니다. 구체적인 변화는 다음과 같습니다: 이제 Claude Code는 당신의 작업 설명을 바탕으로 **런타임(runtime)에 자체적인 JavaScript 하네스(harness)**를 작성합니다. 이 하네스는 백그라운드에서 병렬로 실행되는 최대 **1,000개의 서브에이전트(subagents)**를 오케스트레이션하며, 어느 순간에도 최대 **16개의 에이전트가 동시(concurrent)**에 작동합니다.

저는 문서를 세 번이나 다시 읽었습니다. 1,000은 오타가 아닙니다. 마치 게임의 메타(meta)를 완전히 파괴해 버렸는데 밸런스 팀에게 아무도 알리지 않은 게임의 패치 노트처럼 읽힙니다.

결과는 컨텍스트 윈도우(context window) 외부의 **스크립트 변수(script variables)**에 축적되므로, 얼마나 많은 병렬 스레드(parallel threads)가 실행되든 상관없이 세션은 반응성을 유지합니다. 세션 중간에 실행을 재개할 수 있으며, 추가적인 컴퓨팅 자원(compute)을 주입할 수도 있습니다.

/deep-research 명령어는 이것이 실제로 어떻게 느껴지는지 확인할 수 있는 가장 명확한 방법입니다. 연구 질문을 설명하면, Claude는 여러 관점에 걸쳐 병렬 웹 검색을 시작하고, 소스들을 서로 교차 검증하며, 확인되지 않은 주장을 필터링한 뒤, 이미 공백(gaps)이 표시된 인용 보고서를 반환합니다. 평소라면 직접 조사하는 데 2시간을 소비했을 주제에 대해 이 명령어를 한 번 실행해 보세요. 결과물은 몇 분 만에 도착합니다. 소스들은 서로 교차 참조되며, 확인되지 않은 주장들은 이미 표시되어 있습니다. 이것은 기존 제품의 개선된 버전이 아니라, 완전히 다른 제품 카테고리입니다.

언급할 가치가 있는 두 번째 모드가 있습니다: ultracode는 최대의 추론 노력 (reasoning effort)을 오케스트레이션 계층 (orchestration layer)과 결합합니다. 표준 Workflows가 실행을 병렬화 (parallelize)하는 반면, ultracode는 그 위에 추론 단계 (reasoning pass)를 추가합니다. 만들고자 하는 것을 설명하면, ultracode는 먼저 아키텍처를 검토한 다음, 이를 구현하기 위해 에이전트 (agents)를 배치합니다. 두 모드 모두 리서치 프리뷰 (research preview) 상태이며, 터미널을 사용하는 엔지니어 1명과 유료 플랜이 필요합니다.

기능 목록보다 중요한 것은 개념적 도약이며, 이는 잠시 시간을 내어 깊이 생각해 볼 가치가 있습니다. 코드베이스를 감사 (audit)하기 위해 Workflows를 사용하는 개발자는 단순히 같은 일을 더 빠르게 하는 것이 아닙니다. 그들은 처음부터 문제를 다르게 분해 (decomposing)하고 있습니다. "어떤 파일을 먼저 봐야 할까" 대신, "병렬로 확인하고 싶은 40가지 관점은 무엇이며, 교차 검증 (cross-checks)을 어떻게 구조화할 것인가"가 질문이 됩니다. 복잡한 문제를 순차적인 단계가 아닌 병렬적인 워크스트림 (work-streams)으로 프레임화하는 이러한 분해 본능은, 매일 사용하며 수개월 동안 근육 기억 (muscle memory)으로 축적됩니다. 누군가에게 이 기능을 설명하는 데는 오후 한나절이면 충분합니다. 하지만 그 본능을 전수할 수는 없습니다. 그것은 연습을 통해 구축되며, 첫 실행부터 쌓이기 시작합니다.

만약 MCP 래퍼 (wrappers)보다 CLI 네이티브 에이전트 아키텍처가 우월하다는 논거를 눈여겨보고 있었다면, Workflows는 해당 모델의 자연스러운 확장으로서 등장합니다. 만약 GUI 우선의 사고 모델을 가지고 있다면, 이것은 아마 단순한 변경 로그 (changelog) 항목처럼 읽힐 것입니다. 이 두 부류의 독자들은 동일한 기능을 가지고 매우 다른 경험을 하게 될 것입니다.

2명의 개발자, 1개의 코드베이스

Dev A는 Workflows 권한을 가지고 있습니다. 기업용이든 개인용이든 이번 연습에서는 중요하지 않습니다. 그는 작업을 설명합니다: 코드베이스 내의 모든 API 엔드포인트(API endpoint)를 감사하여 처리되지 않은 예외 케이스(edge cases)가 있는지 확인하는 것입니다. Claude는 테스트 하네스(harness)를 작성하고, 40개의 병렬 에이전트(parallel agents)를 실행하며, 결과를 교차 검증하고, 충돌 사항을 드러냅니다. Dev A는 보고서를 검토합니다. 실행이 진행되는 동안 그는 다른 일을 하고 있었습니다. 아마도 주의를 기울였어야 했던 스탠드업(standup) 미팅이었을 수도 있습니다.

Dev B는 3주 전에 Claude Code 권한을 요청하는 Jira 티켓을 제출했습니다. 아직 검토 중입니다.

이러한 일상적인 격차가 6개월간 지속된다고 해서 단순히 30% 더 빠른 개발자가 만들어지는 것이 아닙니다. 이는 어떤 터미널(terminal)을 열기도 전 단계에서, 문제를 분해(decomposing)하는 반사 신경이 재구성된 개발자를 만들어냅니다. 6개월 후 두 개발자가 동일한 시스템 설계(system design) 세션에 앉아 있을 때 어떤 일이 벌어질지 생각해 보십시오. 팀이 코드베이스 전체 마이그레이션(migration)을 제안합니다. Dev B는 의존성(dependencies)을 매핑하기 시작하며, 머릿속으로 작업들을 순차적으로 대기열에 넣습니다. Dev A는 이미 12개의 병렬 감사 트랙을 스케치했으며, 교차 검증(cross-validation) 단계를 어떻게 구조화할지 고민하고 있습니다. 어느 개발자도 이를 발표하지 않습니다. 차이점은 그들이 처음에 어떤 질문을 던지는지, 그리고 어떤 질문은 아예 던질 생각조차 하지 않는지에서 드러납니다. 문제는 이미 Dev A의 머릿속에서 다른 형태로 형상화되어 도착하며, 그 형태는 문서를 읽어서가 아니라 6개월간의 일상적인 실행을 통해 만들어진 것입니다.

복잡한 작업을 분해하는 방식이 변합니다. 무엇이 병렬로 실행할 가치가 있는 것인지에 대한 임계값(threshold)이 이동합니다. 코드베이스 감사가 하나의 순차적인 경로가 아니라 40개의 동시적인 관점을 가지고 있다는 것을 식별하는 속도 또한 변합니다. 이 중 어느 것도 성과 검토(performance review)에는 나타나지 않습니다. 이 모든 것은 그들에게 복잡한 문제가 주어질 때마다 나타납니다. 이것은 자격증 과정으로 압축할 수 없으며, 8개월이 지나서야 마침내 Jira 티켓이 승인되었을 때 소급하여 설치할 수도 없습니다.

여기서는 거버넌스 (Governance) 관점이 중요합니다. Uber의 문제는 Claude Code가 아니었습니다. 그것은 5,000명의 엔지니어가 AI에게 무엇을 요청하고 있는지에 대한 구조의 부재였습니다. AI에게 요청하는 것을 단순한 바람이 아닌 하나의 계약 (Contract) 처럼 취급하는 것이, 기능을 금지하지 않으면서 비용을 제어할 수 있는 지렛대이며, 이는 기꺼이 노력을 기울일 의사가 있는 모든 엔지니어링 조직에서 활용 가능합니다. 저 또한 통제되지 않는 청구서를 충분히 겪은 후, 정확히 이 문제를 해결하기 위한 프롬프트 거버넌스 프레임워크를 구축했습니다. 금지의 대안은 이미 존재했습니다. 다만 그것은 단순한 메모에 서명하는 것보다 더 많은 노력을 요구했을 뿐입니다.

인재 시장은 메모를 건너뛰었다

18개월 후, Claude Code를 금지했던 기업들은 채용을 진행하게 될 것입니다.

2026년 6월부터 매일 Workflows를 사용해 온 개발자는 그 면접장에 이력서 어디에도 나타나지 않을 무언가를 지니고 나타납니다. 그것은 압박감이 심한 상황에서 복잡한 기술적 문제에 직면했을 때 나타나는 다른 기본값 (Different default) 입니다. 그들에게 시스템 디자인 (System design) 질문을 던지면 세션 도중에 그 차이가 드러납니다 (한 개발자는 순차적인 단계로 생각하는 반면, 다른 개발자는 본능적으로 구조화된 교차 검증 (Cross-validation)을 동반한 병렬 분해 (Parallel decomposition)를 시도합니다). 두 사람 모두에게 코드베이스 마이그레이션 (Codebase migration)에 소요되는 작업을 추정해 보라고 요청해 보십시오. 한 명은 숫자 하나를 제시합니다. 다른 한 명은 숫자를 제시한 뒤, 타임라인을 확정하기 전에 즉시 병렬화 (Parallelization) 기회에 대해 질문합니다. 서류상의 연차는 같습니다. 하지만 현장에서 느껴지는 본능은 다릅니다.

도구를 금지한 기업들은 의도치 않게, 금지하지 않은 기업들의 경쟁 우위에 자금을 대주고 있는 셈입니다. 접근이 제한된 매달은 귀사의 급여 명세서에는 기록되지 않는 본능 발달의 한 달이 됩니다. 청구서 항목에서 절약된 예산은 실재합니다. 하지만 인재 측면에서의 비용은 그 어떤 스프레드시트에도 나타나지 않습니다.

지난주 제 아이가 왜 제가 "진짜 일처럼 보이지 않는" 일들에 시간을 쓰는지 물었습니다. 저는 제가 가진 가장 유용한 직관 중 일부가 비즈니스 케이스(business case)는 없지만 단지 문제가 흥미롭다는 이유만으로 토이 프로젝트(toy projects)를 만들면서 생겨난 것이라고 설명하려 노력했습니다. 아이는 납득하지 못했습니다. 제가 청구 보고서(billing report)를 피하고 있다는 아이의 말이 아마 맞을 것입니다. 하지만 핵심은 변하지 않습니다. 일상적인 연습을 통한 **인지적 재배선 (cognitive rewiring)**은 예정된 결과물(deliverable)이 아니라 부수적인 효과라는 점입니다. 현재 Workflows를 사용하는 그 누구도 "더 나은 분해 직관 (decomposition instincts)을 개발하기 위해" 고군분투하고 있지 않습니다. 그들은 도구가 무언가를 출시(ship)하기 때문에 사용하고 있습니다. 직관은 그 부산물입니다.

결국 그 격차는 좁혀질 것이라고 생각합니다. 거버넌스 프레임워크(Governance frameworks)가 개선될 것이고, 더 많은 기업이 Microsoft보다 빠르게 움직일 것이며, Workflows에서 연구 프리뷰(research preview) 라벨이 제거될 것입니다. 어쩌면 인재 시장이 이를 18개월이 아닌 3년 안에 완만하게 만들어낼지도 모릅니다. 제가 타임라인을 잘못 읽고 있는 것일 수도 있습니다.

하지만 지금 이 창문은 열려 있습니다. 그리고 그 창문을 통해 걸어 들어가는 개발자들은 Jira 티켓이 닫히기를 기다리지 않습니다.

접근 정책이 더 엄격해지기 전에 Claude Code 사용법을 체계화하고 싶다면, Vibe Coding, For Real에서 망가진 데모에서 출시된 앱에 이르기까지의 방법론을 다룹니다. Kindle Unlimited에서 확인 가능합니다.