AI는 이미 충분히 빠르다. 문제는 '내려놓을 수 없다'는 것
Anthopic의 2026 Agentic Coding Trends Report가 던진 수치는 불편하다. 개발자들은 이미 전체 업무의 약 60%에서 AI를 활용하고 있다. 그런데 '리뷰 없이 완전히 위임 가능한' 작업은 고작 0~20%에 불과하다. 40포인트짜리 간극. 이게 2026년 엔터프라이즈 AI의 실제 문제다.
속도 전쟁은 끝났다. AI가 이겼다. 팀들이 지금 막혀 있는 건 '더 빠른 생성'이 아니라 '믿고 손을 뗄 수 있는가'다. State of AI Agents 조사에서도 86%의 팀이 이미 프로덕션 코드에 에이전트를 투입하고 있다고 답했지만, 동시에 같은 응답자들이 반복하는 말이 있다. "에이전트 워크플로우에서 가장 어려운 건 지능이 아니라, 프로덕션 시스템에 대한 안전하고 신뢰할 수 있는 접근이다."
왜 못 맡기는가—모델이 멍청해서가 아니다
위임 격차가 생기는 이유를 모델 탓으로 돌리면 해결책을 영원히 찾지 못한다. dev.to의 한 엔지니어링 글은 이걸 정확하게 짚었다. AI가 버그를 고치면서 멀쩡하던 두 가지를 동시에 망가뜨리는 루프. 그 글의 저자가 내린 결론은 간결하다. "문제는 설정이지 모델이 아니다. 진짜 수정은 프롬프트가 아니라 하네스에 있다."
실제로 위임하기 두려운 40%는 공통점이 있다. 한 번 틀리면 심각한 인시던트가 되는 작업들이다. 정산과 연결된 금액 필드 수정, 라이브 시스템의 핵심 권한 모델 변경, 다수의 다운스트림이 의존하는 API 추가. AI는 이걸 빠르게, 그리고 그럴싸하게 쓸 수 있다. 문제는 그게 맞는지 아무도 보장할 수 없다는 것이다.
더 구체적으로 들여다보면 실패 패턴은 네 가지로 수렴된다. Blast radius 맹점—공유 함수나 타입을 바꿨는데 에이전트가 열지 않은 파일 세 개에서 터진다. Contract drift—함수 반환 형태가 바뀌었는데 이를 소비하는 쪽은 여전히 옛날 형태를 기대한다. Silent safeguard removal—에이전트가 테스트를 지우거나 가드를 제거하는데, 그 삭제가 오히려 더 깔끔한 diff로 보인다. Verification gap—diff가 맞다고 해서 동작이 살아있다는 증명이 아니다. 모든 기존 linter와 스캐너는 '없어진 좋은 코드'를 감지하지 못한다. 삭제된 테스트는 알람을 울리지 않는다.
두 가지 접근: 외부에서 통제하거나, 위험 구간을 아예 막거나
업계의 해법은 크게 두 갈래다. 하나는 에이전트를 외부에서 감싸는 방식이다. 데이터브릭스가 최근 공개한 오픈소스 플랫폼 옴니전트(Omnigent)가 대표적이다. Claude Code, Codex, Pi 같은 코딩 에이전트들을 하나의 메타 하네스 아래 래핑해서 조합·제어·협업을 가능하게 한다. 특히 프롬프트 기반이 아닌 상태 기반 정책이 흥미롭다. 특정 세션 비용이 100달러를 초과하면 자동 중단하거나, 에이전트가 새 npm 패키지를 설치한 뒤 push 전 반드시 사람 승인을 받도록 강제하는 식이다. 에이전트를 교체 가능한 구성 요소로 추상화하고, 그 위에 정책 레이어를 올리는 구조다.
다른 하나는 더 근본적인 접근이다. 위험 구간 자체를 AI의 손이 닿지 않는 곳에 용접해버리는 것. Oinone 같은 AI 네이티브 저코드 프레임워크가 시도하는 방향이다. AI가 코드 대신 메타데이터를 내뱉게 하고, 권한 모델·데이터 검증·트랜잭션 일관성은 프레임워크가 강제한다. AI가 내린 결정이 아니라 처음부터 AI가 결정할 수 없는 영역으로 분리하는 것이다. 리뷰 표면도 줄어든다. '수천 줄의 코드를 읽는 것'에서 '수십 줄의 메타데이터 diff를 스캔하는 것'으로.
팀 설계로 좁히는 법: 지금 당장 쓸 수 있는 세 가지 원칙
거창한 플랫폼 도입 없이도 위임 격차를 좁히는 실천이 있다. 첫째, 변경 전 기존 보호막을 먼저 감사하라. 새 도구를 쌓기 전에 이미 가진 테스트와 가드가 실패 패턴의 어디를 커버하는지 먼저 매핑한다. 대부분은 절반만 덮여 있다. 새로 추가하는 것보다 기존 것을 조이는 게 낫다.
둘째, diff가 아니라 동작으로 완료를 증명하라. 에이전트가 작업을 마쳤다고 선언해도, 변경된 영역에 닿는 테스트를 직접 돌려보기 전까지는 완료가 아니다. 자신감 있는 에이전트와 실제로 동작하는 코드는 다른 것이다.
셋째, 위임 가능 목록을 팀이 명시적으로 정의하라. 옴니전트의 상태 기반 정책처럼, '어디까지는 에이전트가 자율적으로 할 수 있고, 어디부터는 사람 검토가 필수다'를 암묵적 관행이 아니라 문서화된 설계 결정으로 만들어야 한다. 이 목록 자체가 팀의 위임 격차를 줄이는 가장 빠른 레버다.
전망: 하네스 엔지니어링이 다음 경쟁력이다
2026년의 AI-First 팀 경쟁력은 '어떤 모델을 쓰느냐'에서 '어떤 하네스를 설계했느냐'로 이동하고 있다. 옴니전트처럼 에이전트를 추상화하고 정책으로 통제하는 메타 레이어, Oinone처럼 위험 구간을 아키텍처로 봉인하는 접근, 그리고 blast radius와 verification gap을 팀 프로세스로 다루는 실천—이 세 가지가 수렴하는 방향은 하나다. AI가 할 수 있는 것과 AI에게 맡겨도 되는 것은 다른 문제이며, 그 경계를 설계하는 것이 팀의 역할이다. 위임 격차는 AI의 한계가 아니라 팀 설계의 빈칸이다.