위험 명령 3건 중 1건이 승인 UI를 통과했습니다.

이건 공격자가 뚫은 게 아닙니다. 승인 다이얼로그에 “확인”을 누른 사람들이 넘긴 겁니다. ZDNet이 2026년 8월 8일 보도한 실험 결과입니다. 연구팀이 에이전트에게 위험도가 명백히 높은 명령을 주고, 승인 UI를 통해 사용자에게 실행 허가를 요청했습니다. 결과: 3건 중 1건 통과.

승인 팝업이 있으면 통제가 된다고 생각했다면, 이 숫자가 불편하게 읽혀야 합니다.

왜 승인 UI는 거버넌스가 아닌가

승인 UI의 실패 원인은 UX 문제가 아닙니다. 구조 문제입니다.

사람은 맥락을 이해하기 전에 버튼을 누릅니다. 특히 에이전트가 “이 작업을 계속할까요?”라고 물을 때, 대부분의 사용자는 에이전트가 이미 판단을 내렸다고 전제하고 확인을 클릭합니다. 실험에서 드러난 것이 바로 이 패턴입니다. 경보가 울리지 않으면 사람들은 경계를 낮춥니다.

두 번째 문제는 피로입니다. 에이전트가 10단계 업무를 처리할 때 3번의 승인을 요청한다고 가정하면, 사용자는 셋째 팝업쯤엔 거의 자동으로 확인을 누릅니다. 이건 인지적 항복의 다른 얼굴입니다. AI가 똑똑해질수록, 혹은 AI가 요청을 많이 할수록, 사람의 검증 의지는 줄어듭니다.

세 번째 문제는 승인 UI가 사후 레이어라는 점입니다. 에이전트가 이미 계획을 수립하고, 도구를 선택하고, 실행 직전까지 간 상태에서 물어봅니다. 이 시점에 “아니오”를 누를 수 있는 사람은 많지 않습니다. 승인 UI는 통제의 도구가 아니라, 책임을 사용자에게 넘기는 장치에 가깝습니다.

진짜 거버넌스는 제약 설계에 있다

Gartner는 최근 기업의 50%가 중국산 AI에 의존하는 리스크를 경고했습니다. 미국은 에이전트 강제 중단 권한을 법제화하는 킬스위치 법안을 논의 중입니다. Databricks는 Unity AI Gateway를 통해 에이전트 배포에 거버넌스 레이어를 반드시 동반시키는 구조를 만들었습니다. 이 세 사례가 가리키는 방향은 같습니다.

거버넌스는 실행 전에 설계된 제약이지, 실행 직전에 묻는 팝업이 아닙니다.

제약 설계는 세 가지 축으로 구분됩니다.

첫째, 허용 목록(allowlist) 설계. 에이전트가 호출할 수 있는 도구, 접근할 수 있는 데이터 범위, 실행 가능한 작업의 종류를 명시적으로 열거합니다. “무엇이든 할 수 있되 위험한 것은 묻는다”가 아니라 “이것만 할 수 있다”가 출발점입니다. 파일 삭제를 허용 목록에 포함하지 않으면, 아무리 그럴듯한 승인 팝업이 떠도 에이전트는 그 작업을 실행하지 못합니다.

둘째, 역할 경계(role boundary) 설계. 에이전트가 어느 시스템에 무슨 권한으로 접근하는지를 사전 정의합니다. SpiceDB 같은 권한 분리 시스템은 이 역할 경계를 코드가 아닌 정책 레이어에서 관리합니다. 에이전트가 재무 시스템에 접근할 권한이 없으면, 아무리 정교한 프롬프트 인젝션 공격도 실행 경로를 열 수 없습니다.

셋째, 중단 권한(stop authority) 설계. 에이전트가 실행 중일 때 누가, 어떤 조건에서, 어떤 방식으로 중단할 수 있는지를 사전에 정의합니다. 이건 단순한 취소 버튼이 아닙니다. 감사 로그에 중단 이유가 기록되고, 재시작 시 상태가 복원되는 전체 흐름이 설계되어야 진짜 중단 권한입니다.

PM이 설계해야 할 세 가지 질문

에이전트에 승인 UI를 붙이는 건 쉽습니다. 제약 설계는 PM이 출시 전에 명확하게 결정해야 하는 사항들입니다.

“이 에이전트가 절대 할 수 없는 것은 무엇인가?” 허용 목록은 허용 항목보다 금지 항목을 먼저 정의할 때 더 안전해집니다. 금지 항목이 아키텍처 수준에서 막혀 있어야 합니다. 정책 문서에만 존재하는 금지는 금지가 아닙니다.

“실패했을 때 어떤 상태가 기록되는가?” 에이전트가 잘못된 작업을 했을 때, PM은 무엇이 잘못됐는지 알 수 있어야 합니다. 감사 가능성(auditability)은 에이전트를 다음 번에 더 안전하게 만드는 피드백 루프의 입력입니다. 로그 없이 운영되는 에이전트는 실수를 반복합니다.

“승인이 실제로 의미 있는 지점은 어디인가?” 모든 단계에 승인을 붙이는 것은 아무 단계에 승인이 없는 것만큼 위험합니다. 승인이 진짜 의미 있는 지점 — 외부 시스템에 돌이킬 수 없는 변경을 가하는 순간 — 에만 배치해야 합니다. 그 외의 단계는 제약 설계로 통제하는 게 맞습니다.

”거버넌스는 나중에”가 쌓이는 방식

에이전트 도입 초기에 가장 흔히 쓰이는 타협이 있습니다. “일단 승인 UI로 넘기고, 운영하면서 조여나가자.” 이 타협이 쌓이면 어떻게 됩니까.

승인 피로가 누적된 사용자들이 점점 빠르게 확인을 누릅니다. 에이전트는 점점 더 많은 권한을 요청하도록 설계됩니다. 어느 순간 승인 UI는 형식이 되고, 실질적인 통제는 사라집니다. 이 시점에서 제약 설계를 도입하려면, 이미 배포된 에이전트의 동작 범위를 처음부터 다시 정의해야 합니다. 사후 거버넌스는 사전 거버넌스보다 훨씬 비쌉니다.

Nate B Jones가 설명한 “에이전트 검증 루프 제품화”가 왜 지금 빅테크의 주요 투자 방향이 됐는지도 같은 맥락입니다. 에이전트가 거짓말하는지 아닌지를 확인하는 것은 UX 개선이 아니라 운영 인프라 문제입니다.

거버넌스는 런칭 후 추가하는 기능이 아닙니다.

제품이 어떤 작업을 하는지, 어떤 권한을 갖는지, 실패했을 때 누가 책임지는지 — 이 세 가지가 설계 단계에서 정의되어 있어야 에이전트는 운영 레벨에 올라갑니다. 승인 UI는 이 질문들에 대한 답이 아닙니다. 질문을 미루는 도구입니다.

당신의 에이전트에서 절대 실행되어선 안 되는 작업 목록이 지금 문서 어딘가에 있습니까? 아니면 팝업에 담겨 있습니까?