AI 에이전트 승인 버튼, 사람은 위험의 3분의 1을 그냥 통과시킵니다

터미널에서 AI 에이전트를 돌려보셨다면 익숙한 화면일 겁니다. “이 명령을 실행할까요? (y/N)”. 대부분 y를 누릅니다. 그것도 아주 빠르게요. 그 순간이 AI 에이전트 보안 설계 전체가 기대고 있는 마지막 방어선입니다. 그런데 이 방어선, 생각보다 훨씬 허술합니다.

사람이 최종 승인자라는 말

지금 나온 코딩 에이전트는 거의 다 같은 구조를 씁니다. 에이전트가 명령을 제안하고, 사람이 승인하면 실행됩니다. 파일 삭제, 패키지 설치, 네트워크 요청, 셸 명령 전부 마찬가지입니다.

이걸 업계에서는 휴먼 인 더 루프라고 부릅니다. AI가 실수해도 사람이 걸러낸다는 논리죠. 규제 문서에도, 기업 보안 정책에도 이 표현이 들어갑니다. 감사 대응할 때 꺼내는 카드이기도 하고요.

여기엔 검증된 적 없는 전제가 하나 깔려 있습니다. 사람이 위험한 명령을 실제로 알아본다는 전제입니다. 못 알아보면 승인 절차는 방어선이 아니라 책임 전가 장치가 됩니다. 사고가 나면 “사용자가 승인했다"고 말할 수 있으니까요.

3분의 1을 놓칩니다

최근 이 전제를 정면으로 겨냥한 실험이 화제입니다. 게임 형태로 만든 승인 시뮬레이션을 4만 회 가까이 돌려, 사람들이 AI 에이전트가 제안한 명령 중 위험한 것을 얼마나 잡아내는지 쟀습니다.

결과는 3개 중 1개를 놓쳤습니다. 실패율 33퍼센트짜리 방화벽인 셈입니다.

숫자보다 눈여겨볼 건 실패의 성격입니다. 사람들이 못 잡은 건 어려운 문제가 아니었습니다. rm -rf / 같은 노골적인 명령은 다들 걸러냅니다. 문제는 평범해 보이는 명령입니다. 환경변수를 읽어서 외부 URL로 보내는 curl 한 줄, 설정 파일에 조용히 한 줄 추가하는 명령, 익숙한 패키지 이름에서 글자 하나가 다른 설치 명령 같은 것들이요.

이런 건 화면에 뜬 3초 안에 가릴 수 있는 게 아닙니다. 그런데 승인 UI가 요구하는 건 딱 3초짜리 판단입니다.

승인 피로: 왜 우리는 y를 누르는가

보안 업계에는 알림 피로라는 오래된 개념이 있습니다. 경보가 너무 자주 울리면 사람은 경보를 무시합니다. 병원 모니터링 알람, 보안 관제 센터의 SIEM 경보에서 수십 년간 반복 관찰된 현상입니다.

AI 에이전트의 승인 프롬프트는 이 함정에 정확히 들어맞습니다.

일단 빈도. 에이전트 하나 돌리면 세션당 수십 번씩 승인창이 뜹니다. 하루에 수백 번 누르는 사람도 있고요. 999번이 안전했으면 1000번째도 안전하다고 뇌가 알아서 결론을 냅니다.

맥락 붕괴도 있습니다. 승인창은 명령 한 줄만 보여줍니다. 그 명령이 왜 나왔는지, 어떤 파일을 읽고 나온 판단인지는 안 보입니다. 판단에 필요한 정보는 빼놓고 판단만 요구하는 셈이죠.

마지막은 기회비용입니다. 사람들이 에이전트를 쓰는 이유는 빨라서입니다. 승인창을 하나하나 꼼꼼히 읽으면 직접 하는 것보다 느려집니다. 그래서 안 읽습니다. 도구를 쓰는 이유가 도구의 안전장치를 무너뜨립니다.

프롬프트 인젝션이 이 구멍을 노립니다

이게 이론적 걱정으로 끝나지 않는 이유가 있습니다. 공격자 입장에서 33퍼센트 통과율은 아주 매력적인 숫자거든요.

프롬프트 인젝션 공격은 이미 방식이 정형화됐습니다. 에이전트가 읽을 만한 곳(GitHub 이슈, README, 웹페이지, 의존성 패키지 설명)에 지시문을 심어둡니다. 에이전트가 그걸 읽고 공격자가 원하는 명령을 제안합니다. 그리고 사용자가 승인합니다.

핵심은 마지막 단계입니다. 공격자는 사용자를 속일 필요가 없습니다. 사용자가 안 읽게만 만들면 됩니다. 명령을 길게 늘이거나, 앞부분에 멀쩡한 작업을 붙여두거나, 승인 요청을 연속으로 몰아넣으면 됩니다. 사람의 주의력은 유한한 자원이고, 그걸 바닥내는 데 대단한 기술이 필요하지도 않습니다.

실제 사례도 이미 나왔습니다. 에이전트가 악성 이슈를 읽고 자격증명을 외부로 유출하는 명령을 제안한 케이스, 의존성에 심어진 지시문으로 코드베이스 내용을 빼내려 한 케이스가 보고됐습니다. 공통점은 하나입니다. 전부 사용자가 승인했습니다.

그럼 어떻게 해야 하나

승인 절차를 없애자는 얘기가 아닙니다. 승인 절차만 믿지 말자는 얘기입니다.

먼저 승인 횟수를 줄이는 것. 역설적으로 들리지만 물어보는 횟수가 적을수록 사람이 제대로 읽습니다. 안전한 명령은 자동으로 허용하고, 정말 위험한 것만 물어봐야 합니다. 요즘 도구들이 허용 목록과 권한 모드를 강화하는 것도 그래서입니다.

다음은 승인창에 판단 재료를 넣는 것. 명령만 던져놓지 말고 이 명령이 어떤 입력에서 나왔는지, 외부에서 읽은 내용이 끼어들었는지를 보여줘야 합니다. 신뢰할 수 없는 데이터를 읽은 직후에 나온 명령은 따로 표시하는 식으로요.

제일 중요한 건 승인을 실패해도 되는 것으로 만드는 것입니다. 컨테이너, 격리된 워크스페이스, 네트워크 차단, 자격증명 분리 같은 것 말입니다. 사람이 33퍼센트를 놓친다고 전제하고 시스템을 짜면, 놓친 33퍼센트가 치명상까지 가지는 않습니다.

그 작은 승인창

AI 에이전트 보안 논의는 그동안 모델 쪽에 쏠려 있었습니다. 모델을 어떻게 정렬할지, 위험한 요청을 어떻게 거부하게 만들지. 정작 사고는 모델과 사람 사이의 그 작은 승인창에서 납니다.

오늘 y를 몇 번 누르셨나요. 그중 몇 개를 실제로 읽으셨나요. 자신 있게 답할 수 없다면 그건 개인의 부주의가 아니라 설계의 문제입니다. 사람의 주의력을 마지막 방어선으로 세운 시스템은 결국 그 주의력이 바닥나는 지점에서 뚫리게 마련이니까요.