AI 에이전트의 마지막 보안 경계는 왜 인간 승인이 아닌가

Lead: AI 에이전트에 마지막으로 사람의 승인 버튼을 붙이면 안전해질 것처럼 보인다. 하지만 사람은 바쁘고, 긴 명령을 읽는 데 익숙하지 않으며, 승인 화면 안에 섞인 위협을 놓친다. 최근 자료가 가리키는 결론은 단순하다. 승인은 보안 경계가 아니라 검증 스택의 한 단계여야 한다.

TL;DR

인간 승인은 유용하지만, 혼자서는 에이전트의 위협을 안정적으로 잡지 못한다.
LLM 파이프라인은 생성기보다 검증기의 품질과 독립성이 중요하다.
좋은 에이전트 제품은 명령 생성 → 정책 검사 → 실행 전 시뮬레이션 → 사람 승인 → 실행 후 증거의 흐름을 보여준다.
작은 유틸리티라도 승인율이 아니라 검증 누락률과 재현 가능한 증거를 측정해야 한다.

왜 지금 중요한가

에이전트가 실제 파일을 수정하고, 외부 API를 호출하고, 돈이나 권한을 다루기 시작하면서 “사람이 마지막에 확인한다”는 운영 패턴이 빠르게 퍼지고 있다. 이 패턴은 자동 실행보다 낫지만, 승인 버튼 자체를 안전장치로 착각하게 만든다.

사람은 모든 승인 요청을 깊게 읽지 않는다. 익숙한 화면과 짧은 시간 제한 앞에서는 제목과 첫 문장만 보고 승인하기 쉽다. 특히 정상적인 작업 사이에 악성 지시나 과도한 권한 요청이 섞이면, 승인자는 위협을 발견하기보다 흐름을 통과시키는 역할을 하게 된다.

이번 inbox의 두 신호가 같은 문제를 보여준다.

GeekNews에는 인간이 AI 에이전트 명령 승인 과정에서 위협 3개 중 1개를 놓친다는 연구 신호가 들어왔다.
또 다른 글은 AI에게 시험을 내는 파이프라인에서 출제자 자체가 여러 번 틀렸고, 그래서 별도의 LLM 파이프라인 검증기가 필요하다는 사례를 다뤘다.

둘은 서로 다른 이야기처럼 보이지만 핵심은 같다. 검증 대상이 된 시스템의 출력이나 판단을, 그 시스템과 같은 방식으로 다시 믿어서는 안 된다.

핵심 흐름

flowchart LR
    A[Agent command] --> B[Policy check]
    B --> C[Threat and scope scan]
    C --> D[Dry-run evidence]
    D --> E[Human approval]
    E --> F[Execution]
    F --> G[Replayable result]
    G --> H[Post-run verifier]

승인은 이 흐름의 끝이 아니다. 승인 전후에 기계적이고 재현 가능한 검증이 있어야 한다.

1) 승인 화면은 판단을 대신하지 못한다

승인 UI는 결정을 요청할 뿐, 결정을 잘하게 만들지는 않는다. 다음 정보가 없으면 사람은 위험을 평가하기 어렵다.

에이전트가 실제로 바꾸려는 파일과 범위
평소 작업과 다른 권한 요청
외부로 전송되는 데이터와 목적지
실패했을 때 되돌릴 수 있는지
승인하지 않았을 때의 대안

따라서 “Approve” 버튼을 크게 만드는 것보다, 승인자가 확인해야 할 차이를 먼저 보여주는 편이 안전하다. 이번 명령이 지난번과 무엇이 다른지, 어떤 정책을 통과했고 어떤 검사가 실패했는지가 핵심이다.

2) 검증기도 검증해야 한다

LLM을 이용해 답을 만들고, 또 다른 LLM에게 답을 채점하게 하는 방식은 편리하다. 그러나 검증기가 같은 데이터 편향과 같은 착각을 공유할 수 있다.

검증기의 품질을 높이려면 최소한 세 가지를 분리해야 한다.

생성기: 계획이나 결과를 만든다.
검증기: 정책, 사실, 형식, 권한을 검사한다.
증거: 사람이든 다른 시스템이든 다시 확인할 수 있는 실행 기록이다.

검증기가 “괜찮아 보인다”고 말하는 것만으로는 부족하다. 어떤 규칙을 검사했고, 입력과 출력이 무엇이었으며, 어느 조건에서 실패했는지를 남겨야 한다.

3) 승인보다 앞에 범위와 위협을 고정하라

사람이 승인하기 전에 에이전트의 작업 범위를 고정하면 판단 부담이 줄어든다.

목표: 결제 버튼 문구 수정
허용 파일: src/content/blog/ko/*.mdx
허용 작업: 파일 수정, 로컬 테스트
금지 작업: 결제 API 호출, 환경변수 변경, main 외 브랜치 push
검증: content check + build + diff 범위 검사

이 계약과 실제 실행이 다르면 승인 요청을 만들지 않고 멈춰야 한다. 승인자는 전체 명령을 해석하는 사람이 아니라, 이미 검증된 좁은 선택지를 확인하는 사람이 되어야 한다.

실제 사례 / 원문에서 본 신호

인간 승인 연구가 주는 신호

인간은 AI 에이전트 명령 승인 과정에서 위협 3개 중 1개를 놓침이라는 제목은 승인 흐름이 보안의 종착점이 될 수 없음을 직관적으로 보여준다. 사람은 최종 방어선이지만, 반복되는 승인 요청과 복잡한 명령을 모두 깊게 분석하는 보안 분석기는 아니다.

제품으로 번역하면 다음 질문이 필요하다.

승인자는 위험한 부분을 한눈에 볼 수 있는가?
정상 작업과 다른 점이 강조되는가?
승인 전 자동 검사가 실패하면 요청 자체가 차단되는가?

LLM 파이프라인 검증기 사례가 주는 신호

AI한테 시험을 냈는데 출제자가 5번 틀렸다 - LLM 파이프라인 검증기는 생성 과정의 권위만으로 결과를 믿을 수 없다는 사례다. 시험을 만드는 쪽이 틀릴 수 있다면, 에이전트의 계획을 승인하는 쪽도 틀릴 수 있다.

그래서 시스템은 결과를 말하는 것보다 결과를 확인하는 장치를 제품 표면에 포함해야 한다. 실패한 검증 사례를 숨기지 않고, 어떤 수정 뒤 다시 통과했는지 기록하면 신뢰가 쌓인다.

작은 AI 유틸에 적용하는 검증 스택

거대한 보안 플랫폼을 만들 필요는 없다. 작은 글로벌 유틸리티도 아래 다섯 단계를 기본값으로 삼을 수 있다.

범위 고정: 입력, 허용 파일, 권한, 외부 호출을 명시한다.
정책 검사: 금지된 작업과 민감한 데이터 흐름을 자동으로 찾는다.
미리보기: 실제 실행 전 diff, 요청 payload, 예상 결과를 보여준다.
승인: 사람이 확인하되, 승인 이유와 승인 대상을 기록한다.
사후 검증: 결과, 테스트, 로그, 되돌리기 방법을 묶어 export한다.

이 구조는 보안 기능이면서 동시에 UX다. 사용자는 “안전합니다”라는 문장보다, 무엇이 검사됐고 어디서 멈출 수 있는지를 더 쉽게 이해한다.

바로 해볼 실험

이번 주에 에이전트 기능 하나를 골라 승인 버튼 앞뒤에 다음 이벤트를 기록해보자.

승인 요청의 범위와 정책 버전
자동 검사에서 발견한 위험 수
승인자가 실제로 펼쳐 본 증거의 비율
승인 후 실패·롤백 비율
실행 결과를 다시 재현할 수 있는지

첫 번째 목표는 승인율을 높이는 것이 아니다. 검증 없이 통과한 실행을 줄이는 것이다.

1주일 테스트 예시

기존 승인 화면에 “지난 실행과 달라진 점”을 추가한다.
권한 상승이나 외부 전송이 있으면 자동으로 별도 레인으로 보낸다.
실행 전 dry-run 결과를 저장한다.
실행 후 결과와 테스트 로그를 하나의 공유 링크로 묶는다.
사람이 놓친 위협 사례를 다음 검증 규칙의 fixture로 추가한다.

리스크 / 반론

검증을 늘리면 작업 속도가 느려질 수 있다. 모든 작업에 같은 수준의 검사를 적용하면 사소한 수정도 무거워진다.

그래서 위험 레인을 나누는 것이 중요하다.

읽기 전용·로컬 작업: 빠른 자동 검사
파일 변경·외부 API 호출: diff와 정책 검토
결제·권한·배포: 독립 검증과 명시적 승인

또한 검증기를 많이 붙인다고 자동으로 안전해지는 것도 아니다. 서로 같은 모델과 같은 데이터에 의존하면 실패가 복제될 뿐이다. 검증기의 독립성, 규칙 기반 검사, 실제 실행 증거를 함께 설계해야 한다.

결론

인간 승인은 여전히 필요하다. 하지만 승인을 마지막 보안 경계라고 부르는 순간 시스템은 사람의 집중력과 기억력에 과도하게 의존한다.

더 강한 설계는 승인을 검증 스택 안에 배치한다. 에이전트는 좁은 작업 계약 안에서 계획하고, 정책과 위협 검사를 통과하고, 실행 전 증거를 보여주고, 사람이 확인한 뒤 실행하며, 마지막에는 결과를 재현 가능한 형태로 남긴다.

AI 에이전트의 신뢰는 누가 승인했는지가 아니라, 승인 전후에 무엇이 검증되고 무엇이 증거로 남았는지에서 만들어진다.