코파일럿에서 동료로: AI가 자율적으로 작동한다는 것의 의미

제안 엔진에서 자율적 동료로의 전환을 연구에 기반해 들여다본다. 왜 지금 이 일이 벌어지고 있는지, 전환 과정에서 무엇이 무너지고 있는지, 그리고 왕국의 열쇠를 통째로 넘기지 않으면서 어떻게 배치할 것인지.

코파일럿 시대는 정체되고 있다

2026년 4월 15일, Sam Altman은 X에 OpenAI가 "이번 주에 팀과 대기업을 겨냥한 Codex 업데이트"를 출시한다고 게시했다.

그 답글들은 많은 것을 드러냈다. 로드맵을 묻는 개발자 한 명마다, 더 까다로운 질문을 던지는 또 다른 사람이 있었다. 왜 Codex는 아직도 내가 옆에서 돌봐줘야 하는가? 그보다 6개월 앞서, BeyondTrust 연구진은 특수하게 조작된 Git 브랜치 이름으로 Codex를 속여 사용자의 GitHub 토큰을 빼낼 수 있다는 개념 증명을 발표한 바 있다. 브랜치 이름 하나로 토큰을 흘리도록 속여넘길 수 있는 코파일럿은 동료가 아니다. 안전장치가 걸린 장전된 무기다.

그 긴장은 2026년의 모든 엔터프라이즈 AI 논의 밑바닥에 깔려 있다. 코파일럿은 천장에 부딪혔고, 숫자가 그것을 말해준다.

MIT의 NANDA 이니셔티브는 2025년에 생성형 AI 파일럿의 95%가 측정 가능한 비즈니스 가치를 전달하는 데 실패한다고 보고했다.
2026년 초 Reddit의 r/ArtificialIntelligence 전반에서 반복 인용된 RAND 연구는 AI 에이전트 프로젝트의 80~90%가 프로덕션 환경에서 실패한다는 점을 발견했다.
GitHub Copilot에 대한 개발자 수용률은 35~40% 부근에서 평탄해졌고, Cursor는 42~45%, Claude Code는 2026년 AI 코딩 설문에서 46%의 "가장 사랑받는" 평가를 받았다. 2025년 5월에야 출시된 도구로서는 놀라운 반전이다.
Satya Nadella는 2025년 말 Microsoft의 사내 Copilot 도입을 "거의 사용 불가능"하다고 평한 것으로 전해졌고, 회사는 경영진이 내부적으로 "고위험 리셋"이라 부른 제품 개편을 발표했다.
2025년 말 발표된 arXiv 연구는 Copilot 방식의 자동완성이 오히려 숙련된 개발자들의 좌절감을 증가시켰다는 점을 발견했다. 그럴듯하지만 미묘하게 틀린 제안으로 흐름을 끊었기 때문이다.

이 정체는 기반 모델의 실패가 아니다. 상호작용 패턴의 실패다. 코파일럿은 개별 키 입력이나 질문 수준에서 작동한다. 동료는 워크플로 수준에서 작동한다. Bits&Chips는 2026년 4월 에세이 "From copilot to colleague"에서 이를 잘 정리했다. "코파일럿은 개별 상호작용 수준에서 작동하는 반면, 에이전트는 워크플로 수준에서 작동한다. 이것이 중요한 이유는, 대부분의 조직에서 병목은 개별 작업이 아니기 때문이다. 작업과 작업 사이의 조율이 병목이다."

그것이 지금 기업들이 만들어내려 애쓰고 있는 전환이다. 고르지 않게, 불완전하게, 그러나 의미 있는 규모로.

자율성 스펙트럼

"에이전트"는 마케팅 용어가 되어버렸으니, 구체적으로 짚어보자. AI 자율성에는 네 개의 뚜렷한 단계가 있고, 2025년과 2026년의 실망 대부분은 하나를 다른 하나로 혼동한 데서 비롯됐다.

1단계: 코파일럿

제안한다. 허락을 구한다. 당신의 화면 안에 머문다. GitHub Copilot의 자동완성이 원형이다. 가치는 절약된 키 입력으로 측정된다.

2단계: 어시스턴트

요청에 따라 질문에 답하고 결과물을 작성한다. ChatGPT, 브라우저 속 Claude, Microsoft 365 Copilot의 채팅 패널. 가치는 초안 품질과 맥락 종합으로 측정된다.

3단계: 에이전트

목표를 받아들이고, 일련의 단계를 계획하고, 도구를 가로질러 실행하고, 결과를 보고한다. 저장소를 스캔하고 PR을 여는 Claude Code. 20분간 검색을 돌려 인용이 달린 보고서를 반환하는 ChatGPT의 Deep Research. Anthropic은 Claude 인스턴스가 Rakuten을 위해 7시간짜리 자율 엔지니어링 작업을 완수한 사례를 문서화했다. 가치는 투입된 인간 시간당 완료된 워크플로로 측정된다.

4단계: 동료

기존 권한 모델 안에서 작동하고, 팀의 커뮤니케이션 채널에 참여하며, 며칠과 몇 주에 걸쳐 맥락을 유지하고, 인간 직원과 동일한 감사 추적에 대해 책임을 지는 에이전트. 이것이 최전선이다.

Reddit의 r/ChatGPT 커뮤니티는 이 단계들을 구분하기 위한 실용적인 테스트를 끌어냈는데, 풀어 쓰면 이렇다. 그 대상은 먼저 나서는가, 아니면 모든 지시를 기다리는가? 예상치 못한 상황을 처리하는가, 아니면 멈춰버려서 당신이 다시 프롬프트를 입력하게 만드는가? 여러 단계로 이어진 작업에서 맥락을 기억하는가, 아니면 당신이 같은 말을 반복해야 하는가? 2025년에 "AI 에이전트"로 마케팅된 제품 대부분은 이 질문들을 하나도 통과하지 못했다. 통과한 것들이 바로 사람들이 지금 "동료"라고 말할 때 뜻하는 것이다.

컴퓨터 사용 vs 스킬: 배관이 중요한 이유

동료 수준의 AI는 세상 속에서 행동해야 한다. 거기에는 두 가지 아키텍처 접근법이 있고, 둘은 매우 다른 위험 프로필을 갖는다.

컴퓨터 사용

AI가 시뮬레이션된 마우스와 키보드를 조작한다. 말 그대로 화면을 보고 버튼을 클릭한다. Anthropic은 2024년 말 Computer Use를 출시했고, OpenAI의 Operator가 뒤따랐다. 매력은 보편성이다. GUI를 가진 모든 소프트웨어가 다룰 수 있는 대상이 된다.

대가는 폭발 반경이다. 컴퓨터를 사용하는 에이전트는 로그인한 사용자가 가진 모든 권한을 물려받는다. 2025년 10월, BeyondTrust 보안팀은 OpenAI의 Codex 에이전트가 셸 명령이 심어진 악성 Git 브랜치 이름을 통해 속아 사용자의 GITHUB_TOKEN을 읽고 빼내도록 유도될 수 있음을 시연했다. 에이전트는 인간 개발자가 할 법한 일(브랜치 체크아웃)을 정확히 하고 있었지만, 브랜치 이름 자체가 적대적 입력이라는 직관은 전혀 없었다. 그 사건에서 권한 모델은 전부 아니면 전무였다. 그것이 컴퓨터 사용의 기본 실패 양상이다.

스킬

AI가 개별 스킬을 호출한다. 각 스킬은 좁은 계약을 가진 명시적이고 타입이 지정된 함수다. "q에 일치하는 메시지를 Slack에서 검색", "title과 body로 Linear 이슈 생성", "이 GitHub 파일 읽기". 컴퓨터 사용과 달리, 스킬은 사전 승인된 형태를 갖는다. 에이전트는 계약에 맞는 매개변수로만 그것을 호출할 수 있고, 플랫폼은 그 호출이 샌드박스를 떠나기 전에 허용하거나 거부하거나 확인을 요청할 수 있다.

보안 관점에서 그 차이는 **최소 권한 원칙(Principle of Least Privilege)**으로 귀결된다. 이는 정보 보안의 기초 개념으로, 하나의 프로세스는 자신의 기능을 수행하는 데 필요한 자원에만 접근할 수 있어야 하며 그 이상은 안 된다는 것이다. 스킬은 호출 단위로 최소 권한을 강제할 수 있게 해준다. 컴퓨터 사용은 그렇지 못하다.

동료 수준의 배치는 구조화된 동작(CRM에 쓰기, 티켓 열기)에는 스킬을 사용하고, API 노출을 거부하는 좁은 꼬리쪽 애플리케이션에 한해 컴퓨터 사용을 남겨둔다. 그 비율이 중요하다. 에이전트 배치의 모든 동작이 시뮬레이션된 마우스를 거쳐 간다면, 당신이 가진 것은 프로덕션 시스템이 아니라 생산성 데모다.

기업이 실제로 필요로 하는 신뢰 아키텍처

코파일럿에서 동료로의 전환은 모델 업그레이드가 아니다. 인프라 업그레이드다. 세 가지 요소가 배치 가능한 동료를 책임 부담거리와 갈라놓는다.

1. 권한 격리

각 에이전트는 자신의 권한 경계 안에서 작동하며, 에이전트 스스로가 샌드박스 밖으로 빼낼 수 없는 자격 증명을 사용한다. Andrej Karpathy가 2026년 3월에 화제가 된 autoresearch 실험에서 에이전트가 이틀에 걸쳐 700개의 학습 실험을 무인으로 돌리게 한 일은, 그것이 하지 않은 일 때문에 시사적이다. Karpathy 본인의 저장소는 사용자에게 자율 모드에서 "모든 권한을 비활성화하라"고 지시한다. 개인 연구용 노트북에서는 괜찮다. 규제받는 기업 내부에서는 해고감이다.

반대 사례는 2026년 1월 말 150만 개의 자율 에이전트로 잠깐 화제가 된 AI 전용 소셜 네트워크 Moltbook이다. Karpathy는 이를 "최근 본 것 중 가장 놀라운, 공상과학적 도약에 가까운 것"이라며 칭찬했다. 그러다 Wiz의 보안 연구진이 프런트엔드에 노출된 데이터베이스 API 키를 발견했는데, 이는 150만 개 에이전트 전체의 인증 토큰을 포함해 전체 프로덕션 데이터베이스에 대한 완전한 읽기/쓰기 접근 권한을 부여하는 것이었다. Karpathy는 24시간 안에 입장을 뒤집었다. "쓰레기장 화재다. 사람들이 이런 걸 자기 컴퓨터에서 돌리는 건 절대 권하지 않는다." 교훈은 "에이전트는 위험하다"가 아니다. 교훈은, 신원별 권한 격리 없이 배치된 에이전트들은 하나의 공유된 폭발 반경으로 무너져 내린다는 것이다.

2. 감사 추적

모든 동작이 기록되고, 모든 결정이 추적 가능하다. 2026년 1월 다보스에서 공개된 싱가포르 IMDA 프레임워크는 에이전트의 동작 공간(읽기 vs 쓰기, 가역 vs 비가역)을 그 자율성(얼마나 독립적으로 결정하는가)에 대비시키는 2축 위험 매트릭스로 이를 성문화한다. 어느 축이든 높아질수록 감사 요건은 더 풍부해진다. 이 프레임워크는 거버넌스를 추상적 원칙에서 운용 가능한 보정 도구로 옮긴 최초의 사례 중 하나이기에, 유럽과 미국 규제당국이 면밀히 연구하고 있다.

Simon Willison은 이와 나란히 **통합 로깅(unified logging)**을 주장해왔는데, 에이전트가 자신의 작동을 스스로 모니터링하고 오류로부터 복구할 수 있도록 하기 위해서다. "전체 시스템 접근 권한을 가진 에이전트는 강력하면서 위험하다." 실용적 요점은 이렇다. 당신의 에이전트 배치에 컴플라이언스 담당자가 순서대로 읽을 수 있는 통합 로그가 없다면, 당신은 배치할 특권을 잃기까지 정확히 한 번의 사고만큼 떨어져 있다.

3. 범위가 지정된 스킬 접근

"이메일에 대한 접근"이 아니다. search inbox where from:@customer.com AND within last 7 days에 대한 접근이다. 현대의 에이전트 플랫폼은 매개변수화된 범위로 이동하고 있는데, 여기서 에이전트가 스킬을 호출할 권한은 인간이 사용할 무딘 OAuth 범위가 아니라 관리자가 사전 승인하는 인자에 의해 한정된다.

이 세 조각을 한데 모으면, 지금 모든 CISO가 던지고 있는 질문에 답할 수 있다. 이 에이전트가 잘못했을 때 무슨 일을 하며, 나는 그것을 어떻게 알게 되는가? 2026년 McKinsey State of AI 설문은 엔터프라이즈 응답자의 72%가 생성형 AI의 우려 사항으로 사이버보안을 꼽았다는 점을 발견했고, 보안은 응답자 약 3분의 2에 의해 에이전트형 워크플로 확장의 #1 장벽으로 지목됐다. 권한 격리, 감사 추적, 범위가 지정된 스킬 접근은 컴플라이언스 연극이 아니다. 그것들이 관문이 되는 인프라다.

왜 지금 이것이 중요한가: 수렴하는 세 가지 힘

2026년 코파일럿에서 동료로의 전환은 단 하나의 돌파구가 이끄는 것이 아니다. 세 개의 곡선이 교차한 결과다.

힘 1: 통합이 더 이상 주문제작이 아니다

2024년에는 에이전트를 기업 SaaS 스택에 연결한다는 것이 도구마다 맞춤형 커넥터를 작성한다는 뜻이었다. 2026년 초에 이르러, 타입이 지정된 스킬 계약과 사전 패키징된 커넥터가 그 작업을 압축해버렸다. 2024년에 6주의 통합이 필요했던 에이전트가 2026년에는 한나절이면 된다. 전형적인 중견 기업의 표면적(Slack, GitHub, Gmail, Linear, Notion, HubSpot, CRM, 캘린더)은 이제 타입이 지정된 권한이 내장된 채 출시되는 성숙한 오픈소스 커넥터 라이브러리로 덮인다.

힘 2: 멀티 에이전트가 현실이 되다

Gartner는 멀티 에이전트 시스템을 2026년 최상위 전략 기술 트렌드로 선정했다. 저명한 VP 분석가 Gene Alvarez는 이제 모든 엔터프라이즈 AI 슬라이드에서 반복되는 비유를 내놓았다. "포뮬러 1 피트 크루를 생각해보라. 각 구성원은 전문화된 역할(타이어 교체, 급유, 잭 조작)을 맡지만, 하나의 목표를 중심으로 안무처럼 짜여 있다. 그것이 2026년 엔터프라이즈 에이전트 배치의 형태다." 단일 에이전트 시스템은 장기 작업에서 추론의 천장에 부딪힌다. 전문화된 역할과 명시적 인계를 갖춘 멀티 에이전트 시스템이, 오늘날 팀들이 그 천장을 돌아가는 방식이다.

힘 3: 기업 예산이 풀리다

G2는 2026년 State of Software 리서치에서 57%의 기업이 AI 에이전트를 프로덕션에 두고 있다(1년 전 약 20%에서 상승)고 보고했다.
McKinsey는 23%의 기업이 에이전트형 AI를 적극적으로 확장 중이며, 62%가 실험 단계에 있음을 발견했다. 이는 대기업 중 약 15%만이 아직 관망하고 있음을 남긴다.
Deloitte의 2026년 3,235명 엔터프라이즈 리더 설문은 금융 서비스를 선도 채택자로 지목했고, 이전에는 분석가 3명이 필요했던 거래 파이프라인 전반에서 AI 에이전트가 회의 결과를 포착하고 그에 따라 행동한 사례 연구를 문서화했다.
2026년 초 발표된 Stanford의 Enterprise AI Playbook은 51개의 프로덕션 배치를 목록화했으며, 핀테크 ETL 마이그레이션 사례가 규제 산업 팀들을 위한 레퍼런스 구현이 됐다.
보고된 엔터프라이즈 AI 인프라 투자는 2025년 사이클에 6,000억 달러를 넘어섰다.
Anthropic의 Dario Amodei는 Code with Claude 컨퍼런스에서, 에이전트 인력으로 구동되는 최초의 1인 10억 달러 기업이 2026년에 등장할 확률을 **70~80%**로 제시했다.

돈이 거기 있고, 프로토콜이 거기 있고, 아키텍처가 거기 있다. 지금 모든 이사회에서 협상되고 있는 것은 얼마나 많은 자율성을, 어떤 거버넌스 아래, 어떤 워크플로에 줄 것인가이다.

회의론자의 주장: Reddit, arXiv, 그리고 사고 보고서가 말하는 것

이 전환을 책임감 있게 들여다보려면, 이 모든 것이 과대 포장됐다고 보는 사람들과 진지하게 마주해야 한다.

Reddit에서 r/LocalLLaMA, r/ClaudeCode, r/ChatGPT 전반의 합의는 실용적이다. 코딩 에이전트는 도착했고 유용하다. 다른 대부분의 "에이전트"는 챗봇 의상을 입은 자동화 워크플로다. 2026년 수십 개 스레드에서 인용된 문장, *"제안을 원할 때는 Copilot을 써라. 실제로 뭔가를 해내길 원할 때는 Claude Code나 Cursor를 써라"*가 그 생산적인 구분을 잘 포착한다. 그 같은 커뮤니티들은 벤치마크에 대해서는 가차 없다. 최고의 에이전트조차 Terminal-Bench에서 전체 약 60%를 기록하고 어려운 작업에서는 16%로 떨어진다. Claude Opus 4.5는 SWE-bench를 80.9%로 선도하지만, 이는 여전히 다섯 작업 중 하나는 실패한다는 뜻이다.

학계의 회의론은 떨쳐내기 더 어렵다. Vishal Sikka(전 SAP CTO, John McCarthy의 제자)와 그의 공동 저자는 Hallucination Stations: On Some Basic Limitations of Transformer-Based Language Models를 발표하며, 트랜스포머 LLM이 일정 복잡도 천장을 넘어서는 계산적·에이전트적 작업을 수행하는 능력에서 근본적으로 제한된다는 점을 수학적으로 논증했다. 고도로 중요한 운영에 대해 *"그것들이 신뢰할 수 있을 방법은 없다"*는 Sikka의 결론은 지금 모든 CISO Slack에서 돌고 있다. 그 논문은 에이전트가 무용하다고 주장하지 않는다. 모델이 아무리 좋아져도 인간을 루프 밖으로 빼낼 수 없는 부류의 문제가 존재한다고 주장한다.

실제 사고들이 그 회의론을 뒷받침한다. Yellow.ai의 2026년 설문에서 인용된 한 리테일 CX 리더는 이렇게 말했다. "우리는 단 2주 만에 AI 지원을 철회해야 했다. 약 1.35%의 티켓에서 잘못된 반품 정책을 인용하고 존재하지 않는 할인 제안을 지어내기 시작했기 때문이다. 그 실수를 이행하는 비용이 우리가 절약하길 바랐던 것보다 훨씬 컸다." 규모가 커지면 2% 미만의 오류율조차 빠르게 비싸진다.

종합하면 이렇다. 동료 수준의 AI는 코딩, 리서치, 구조화된 운영, 그리고 좁은 지원 워크플로에서는 현실이다. 인간 검토자 없는 개방형 고객 대면 상호작용에서는 아직 현실이 아니다. 2026년에 가치를 얻고 있는 기업들은 어떤 워크플로가 어느 범주에 속하는지에 대해 솔직한 곳들이다.

실무적 함의: 배치 전 다섯 가지 질문

당신의 팀이 (사내에서 구축했든 서드파티든) AI 동료를 평가하고 있다면, 이것들이 프로덕션 배치와 아슬아슬한 실패를 갈라놓는 질문이다.

이 에이전트가 취할 수 있는 최악의 단일 동작의 폭발 반경은 무엇인가? 말 그대로 지도를 그려보라. 최악의 경우가 "엉성한 이메일을 엉뚱한 사람에게 보낸다"라면, 거버넌스 기준은 낮다. "프로덕션 데이터를 수정한다"거나 "송금 지시를 보낸다"라면, 기준은 한 자릿수 차원 더 높다. 첫 사고 이후가 아니라 배치 전에 지도를 그려라.
에이전트는 자격 증명을 어떻게 얻으며, 원본 토큰을 읽을 수 있는 적이 한 번이라도 있는가? 세 가지 답이 있고, 안전한 것은 하나뿐이다. 에이전트의 환경에 사용자의 OAuth 토큰 사본이 있다면, 당신은 사실상 LLM에게 지갑을 내준 것이다. 별도의 서비스 계정 OAuth를 통해 에이전트가 "자신의" 신원을 갖는다면, 당신은 그것을 실제 주체로서 추적하고 회수해야 한다. 세 번째 답이 당신이 실제로 원하는 것이다. 토큰이 에이전트에 절대 도달하지 않는 것. 토큰은 플랫폼에 암호화되어 머물고, 정책 검사를 통과한 호출에 한해, 호출이 반환될 때까지만, 적시에 네트워크 프록시 계층에서 주입된다.
모든 동작이 컴플라이언스 담당자가 순서대로 읽을 수 있는 어딘가에 기록되는가? 통합되고, 질의 가능하며, 변조가 드러나야 한다. 답이 "CloudWatch 어딘가에 로그가 좀 있다"라면, 당신은 준비되지 않았다.
이 워크플로가 필요로 하는 구체적인 매개변수로 스킬 접근의 범위를 지정할 수 있는가? 통합 단위가 아니라 호출 단위로. 읽기 vs 쓰기. 리소스 ID별로. 시간 창별로. 에이전트의 권한은 창고 전체가 아니라 그 일을 빈틈없이 둘러싼 직사각형이어야 한다.
무언가 잘못됐을 때 롤백 시나리오는 무엇인가? 동작을 어떻게 되돌리는가? 얼마나 빨리? 누구에게 호출이 가는가? 비가역적 동작(송금, 고객 대면 이메일, 프로덕션 배포)에는 확인 단계나 지연 창이 필요하다. 가역적인 것들은 자율적으로 돌아갈 수 있다.

이 다섯 가지를 검토하라. 전부 답할 수 있다면, 당신은 이미 코파일럿 시대를 지나, 팀이 출시하는 방식을 실제로 바꾸는 영역에 들어선 것이다. 두세 개를 답할 수 있다면, 거기가 다음에 집중할 곳이지 기다릴 이유가 아니다. 당신의 로드맵이 손을 뻗고 있는 동료 수준의 팀원은 오늘 어딘가에서 이미 프로덕션에 돌아가고 있다. 당신과 그것 사이의 간극은 인프라 간극이지, 최전선 AI의 간극이 아니다. 그리고 인프라 간극은 빠르게 닫힌다.

다음 모델 출시를 기다릴 필요가 없다. 이 다섯 가지에 이미 답해주는 플랫폼을 고르고, 당신의 에이전트에게 진짜 일을 주기 시작하면 된다.

자주 묻는 질문

코파일럿과 AI 동료의 진짜 차이는 무엇인가?

코파일럿은 제안하고, 허락을 구하며, 단일 도구 안에 산다. 동료는 목표를 받아들이고, 시스템을 가로질러 계획하고, 범위가 지정된 권한으로 실행하며, 인간과 동일한 감사 추적에 대해 책임을 진다. Bits&Chips는 깔끔하게 정리했다. 코파일럿은 상호작용 수준에서, 동료는 워크플로 수준에서 작동한다.

에이전트는 사용자 자격 증명을 어떻게 다뤄야 하는가?

명백해 보이는 두 선택지 모두 옳지 않다. 사용자의 OAuth 토큰을 에이전트 환경에 복사하는 것은 살아 있는 자격 증명을 LLM의 맥락 안에 넣는 일이다. 에이전트마다 별도의 신원을 발급하는 것은 모든 에이전트를 당신이 인간처럼 추적하고, 회수하고, 감사해야 하는 주체로 바꾼다. 실무에서 통하는 패턴은 중개 접근(brokered access)이다. 토큰은 플랫폼에 암호화되어 머물고, 샌드박스의 아웃바운드 네트워크 프록시가 요청 시점에 플랫폼으로 다시 호출하면, 플랫폼은 토큰을 복호화하고 정책 검사를 통과한 호출에 대해 해석된 인증 헤더만 반환하며, 에이전트 자체는 원본 토큰을 절대 읽거나, 기록하거나, 그에 대해 확인을 묻지 않는다.

컴퓨터 사용인가 스킬인가, 어느 쪽을 골라야 하는가?

API가 있는 모든 것에는 기본적으로 스킬이다. 컴퓨터 사용은 대상 시스템에 프로그래밍 가능한 인터페이스가 없을 때만. BeyondTrust Codex 사건이 경고담이다. 컴퓨터 사용은 사용자의 전체 권한을 물려받고, 에이전트의 시야 어딘가에 있는 악성 입력은 익스플로잇이 될 수 있다.

에이전트를 실제로 얼마나 자율적으로 돌려야 하는가?

싱가포르 IMDA의 2축 틀을 사용하라. 동작 공간 × 자율성. 좁은 동작 공간(읽기 전용, 가역적)은 높은 자율성을 견딘다. 넓은 동작 공간(쓰기, 비가역적, 고객 대면)은 인간의 확인, 또는 개입할 수 있는 시간 지연 창을 요구한다. 최악의 구성은 감사 추적 없이 고위험 동작에 높은 자율성을 부여하는 것이다.

ROI는 어떻게 측정하는가?

절약된 키 입력 측정을 그만둬라. 투입된 인간 시간당 완료된 워크플로, 운영 사고의 해결 시간, 그리고 이탈률(에이전트가 인간에게 되돌려준 작업)을 측정하라. Deloitte의 2026년 결과는 선도 채택자들이 세 가지 지표를 추적하고 있음을 시사한다. 워크플로 완료율, 오류율, 인간 개입률, 그리고 그것들 사이의 비율을 최적화하는 것.

95% 파일럿 실패율에 대해 무엇을 해야 하는가?

MIT NANDA의 분석을 꼼꼼히 읽어라. 실패한 파일럿들은 대부분 "멍청한 RAG"(모든 것을 맥락에 쏟아붓기), "취약한 커넥터"(망가진 API 통합), 그리고 이벤트 기반 아키텍처 부재 위에서 돌아갔다. 성공한 파일럿들은 LLM을 둘러싼 운영 계층을 갖추고 있었다. 메모리, I/O, 그리고 권한. LLM 커널은 병목이 아니다. 그것을 둘러싼 인프라가 병목이다.

VM0가 들어맞는 지점

우리는 하나의 아키텍처적 베팅을 중심으로 Zero를 만들었다. 에이전트는 자격 증명을 결코 보유해서는 안 된다. 환경에도, 프롬프트에도, 메모리에도. 토큰은 플랫폼에 머문다. 에이전트가 하는 모든 아웃바운드 호출은, 호출 단위로 인증 헤더를 주입할지 요청을 차단할지를 결정하는 네트워크 프록시를 통해 중개된다.

그것은 흔치 않은 선택이다. 2026년의 일반적인 패턴은 에이전트에게 자신의 OAuth 신원을 주거나(이제 당신은 감사하고 회수해야 할 두 번째 주체를 갖게 된다), env 변수에 사용자 토큰 사본을 쥐여주는 것이다(이제 LLM이 당신의 지갑을 읽을 수 있다). 우리는 둘 다 하지 않는다. 실제로 어떻게 작동하는지 보자.

토큰은 에이전트에 결코 도달하지 않는다. 당신이 Zero에 커넥터(GitHub, Slack, Gmail, Linear, Notion, HubSpot 등)를 연결하면, OAuth 토큰은 플랫폼에 암호화되어 저장된다. 리프레시 토큰은 데이터베이스에 머물며 결코 그곳을 떠나지 않는다. 샌드박스 안에는 읽을 GITHUB_TOKEN 환경 변수도, 열 비밀 파일도, 토큰을 반환하는 도구도 없다.

네트워크 프록시가 모든 호출을 중개한다. 샌드박스를 떠나는 모든 HTTP 요청은 mitmproxy 기반 애드온을 거친다. 프록시는 요청의 호스트명에서 커넥터를 식별하고, 그 에이전트에 대한 방화벽 정책을 조회하며, 메서드와 경로가 허용되는지 확인한다. 허용된다면, 프록시는 플랫폼의 웹훅으로 다시 호출한다. 플랫폼은 토큰을 복호화하고, 만료됐으면 갱신하고, 헤더 템플릿을 해석하며(${{ secrets.GITHUB_TOKEN }}이 실제 값이 된다), 해석된 인증 헤더만 프록시에 반환한다. 프록시는 그 헤더를 나가는 요청에 주입한다. 호출이 완료되면, 헤더는 프록시 메모리에서 사라진다. 에이전트는 그것을 본 적이 없다.

권한은 에이전트별, 커넥터별이며, 엔드포인트 수준에서 타입이 지정된다. 각 에이전트는 각 커넥터를 이름이 붙은 권한 그룹 집합에 매핑하는 정책 객체를 갖는다. github:repo-read는 모호한 범위가 아니다. 구체적인 메서드와 경로 규칙의 묶음이다. 예를 들어 GET /repos/{owner}/{repo}/pulls. GitHub 접근을 부여한다고 GitHub를 통째로 부여하는 것이 아니다. 그것은 GitHub 안의 의도의 형태를 부여한다.

두 가지가 아니라 세 가지 정책 상태. 모든 권한은 allow, deny, 또는 ask로 해석된다. 마지막 것은 동작이 발생하기 전에 인간에게 확인을 요청한다. 방화벽이 명시적으로 일치시키지 못하는 것은 무엇이든 커넥터별 unknownPolicy로 떨어지고, 그 기본값은 deny다. 최소 권한이 기본값이지, 선택 항목이 아니다.

실행당 하나의 샌드박스. 모든 에이전트 실행은 격리된 네트워크 네임스페이스를 갖는 자신의 Firecracker 마이크로VM 안에서 돌아간다. 실행이 끝나면, 네임스페이스는 해체된다. 같은 에이전트의 두 실행은 두 개의 별도 감사 추적을 갖는 두 개의 별도 샌드박스다.

요청별 감사 추적. allow/deny를 결정하는 같은 프록시가, 모든 요청에 방화벽 메타데이터를 붙인 실행별 JSONL 로그도 작성한다. 커넥터, 일치한 권한 그룹, 일치한 구체적 규칙, 결정, 타임스탬프. 그 로그들은 플랫폼으로 다시 보내진다. CISO가 4월 14일 오후 3시에서 5시(CST) 사이에 에이전트가 무엇을 했는지 알아야 한다면, 그것은 한 번의 질의다.

자신의 거부를 설명하는 CLI. 권한이 호출을 차단하면, 에이전트(또는 그 옆에 앉은 인간)는 zero doctor permission-deny <connector> --method <M> --path <P>를 실행해 요청을 차단한 정확한 권한 그룹과 함께 해결 링크를 돌려받을 수 있다. zero doctor permission-change는 관리자가 권한을 직접 토글하게 하거나, 구성원이 (500자로 제한되어 그 논거가 실제로 읽히는) 서면 요청을 제출해 관리자에게 라우팅되게 한다. slack:chat:write나 gmail.send 같은 고위험 권한은 더 안전한 봇 범위의 대안을 가리키는 추가 경고를 띄운다.

두 역할, 하나의 승인 흐름. 소유자와 관리자는 권한을 직접 변경한다. 구성원은 이유와 함께 요청을 제출하고, 그것은 관리자에게 라우팅된다. "어중간한 관리자"라는 세 번째 등급은 없다. 그 흐름은 사람들이 실제로 사용할 만큼 작은데, 그것이 핵심의 전부다.

우리는 API 노출을 거부하는 좁은 레거시 시스템 집합에 한해 컴퓨터 사용을 남겨둔다. 그 외 모든 것은 스킬을 거친다. 모든 동작은 정책 검사를 받는다. 모든 자격 증명은 플랫폼에 머문다. 모든 결정은 기록된다.

"또 하나의 AI 자동완성"을 지나, 당신의 보안팀이 승인할 AI 팀원을 시도해보고 싶다면, Zero가 예약된 워크플로를 어떻게 처리하는지 보거나, 프로덕션 사고를 분류하거나, 아침 제품 브리핑을 돌려보라.

코파일럿 시대는 끝나지 않는다. 더 큰 무언가 속으로 흡수되고 있다. 다음 사이클을 이길 팀은 그 차이를 이해하는 팀이다.