AI 에이전트는 인간이 현실적으로 제때 실수를 잡아낼 수 있고, 그 행동이 중단을 감수할 만큼 충분히 중대한 결과(consequential)를 초래할 때 인간의 승인을 요청해야 합니다. 이것이 핵심 테스트입니다. 대부분의 팀은 "인간이 이것을 검토해야 하는가?"라는 잘못된 질문에서 시작합니다. 왜냐하면 실제로 평가하거나 중단할 수 없는 행동 앞에 놓인 인간은 어차피 승인을 내릴 것이기 때문입니다. 만약 사람이 보여지는 정보만으로 오류를 감지할 수 없거나, 피해가 발생하기 전에 개입할 수 없다면, AI 에이전트의 승인 프롬프트는 형식적인 절차(rubber stamp)에 불과합니다. 그런 경우에는 클릭을 요청하기보다 설계 단계에서부터 나쁜 결과가 발생하지 않도록 방지해야 합니다. 유용한 질문의 형태는 더 좁아야 합니다: "이 인간이 이 시간적 범위(window) 내에 이 실수를 잡아낼 수 있는가?"

이 글은 에이전트가 수행할 수 있는 모든 행동에 대해 이에 답할 수 있는 구체적인 방법을 제시합니다. 이 방법은 인간 참여형(human-in-the-loop) 감독을 위한 무료의 실무자 중심 프레임워크인 LoopRails를 사용하며, 그 방식은 Grade · Guard · Show · Prove입니다 (프레임워크 참조).

먼저 행동을 등급화(Grade) 하세요: 가역성, 영향 범위, 이해관계

AI 에이전트가 승인을 요청해야 하는지 결정하려면 해당 행동의 가치를 먼저 알아야 합니다. LoopRails는 에이전트가 취할 수 있는 모든 행동을 세 가지 축으로 등급을 매기며, 가장 높은 축이 최종 등급을 결정합니다:

• 가역성 (Reversibility). 취소할 수 있는가, 그리고 얼마나 빠른가?
• 영향 범위 (Blast radius). 얼마나 많은 사람, 시스템 또는 레코드를 건드리는가?
• 이해관계 (Stakes). 얼마나 많은 돈, 신뢰 또는 안전이 걸려 있는가?

이를 통해 네 가지 등급이 생성되며, 각 등급에는 기본 대응 방식이 있습니다:

• G0 (trivial, 사소함). 완전히 되돌릴 수 있고, 영향 범위가 국한되며, 이해관계(stakes)가 거의 제로에 가깝습니다. 실행 후 로그만 남기며, 프롬프트(prompt)를 전혀 띄우지 않습니다. 댓글 형식 변경, 읽기 전용 쿼리(read-only query) 실행, 파일 목록 나열 등이 이에 해당합니다. 여기서 승인을 요청하는 것은 사람들이 내용을 확인하지 않고 클릭하도록 훈련시키는 것과 같습니다.
• G1 (low, 낮음). 약간의 노력으로 되돌릴 수 있으며, 영향 범위(blast radius)가 제한적입니다. 실행 후 알림을 보내고, 클릭 한 번으로 실행 취소(undo)가 가능하게 합니다. 초안 PR(draft PR) 생성, 파일 전체에서 로컬 변수 이름 변경, 이슈(issue)에 라벨 추가 등이 해당합니다. 안전성은 프롬프트가 아니라 실행 취소 기능에서 옵니다. G1 가이드를 참조하세요.
• G2 (high, 높음). 되돌리기 어렵거나, 영향 범위가 공유되거나, 실제 비용과 신뢰가 걸려 있지만, 재앙적인 수준은 아닙니다. 실행하기 전에 미리보기(preview)를 제공하고 승인을 받습니다. 고객에게 이메일 발송, main 브랜치로 머지(merge), 스테이징(staging) 환경 배포, 200달러 예산 중 40달러 지출 등이 해당합니다. 잘 설계된 승인 게이트(approval gates)가 제 역할을 하는 지점입니다. G2 가이드를 참조하세요.
• G3 (critical, 치명적). 되돌릴 수 없거나 외부적인 영향을 미치며, 혹은 심각한 수준입니다. 설계 단계에서 방지하거나, 제작자-검토자(maker-checker) 구조로 중단 후 질문하거나, 거부하고 에스컬레이션(escalate)해야 합니다. 운영 데이터(production data) 삭제, 계좌 이체, 공유 브랜치에 강제 푸시(force-push), 모든 고객에게 대량 이메일 발송 등이 해당합니다. 여기서는 단 한 번의 승인 클릭만으로는 충분하지 않습니다. G3 가이드를 참조하세요.

등급 분류(Grading)는 대부분의 팀이 건너뛰는 부분이며, 이 때문에 프롬프트가 사방에 깔려 있거나(피로도 유발) 혹은 아예 없어서(사고 발생) 문제가 됩니다. 에이전트의 작업 몇 가지를 세 가지 축을 통해 검토해 보면 "이 작업이 승인을 요청해야 하는가?"에 대한 답이 자연스럽게 도출됩니다. 대화형 등급 분류기나 한 페이지짜리 치트 시트(cheat sheet)를 사용하여 직접 등급을 매겨보세요.

왜 대부분의 AI 에이전트 승인 프롬프트는 실패하는가

등급 분류는 어떤 작업이 감독(oversight)을 필요로 하는지 알려줍니다. 하지만 그 감독이 효과가 있을지에 대해서는 아무것도 말해주지 않습니다. 이 둘은 서로 다른 두 개의 축이며, 이 둘을 혼동하는 것이 AI 에이전트 승인 설계에서 가장 흔히 발생하는 실수입니다.

두 가지 실패 모드가 잘 문서화되어 있습니다.

인식 병목 현상(The recognition bottleneck). AI 코딩 에이전트 관련 연구(LoopRails의 codex 참조)에 따르면, 에이전트가 행동하기 전에 계획 승인을 받도록 요구했을 때 문제성 있는 행동 비율을 약 90%에서 6074%로 낮추는 것으로 나타났습니다. 이는 개선된 것처럼 들리며, 실제로도 부분적으로 맞습니다. 왜냐하면 이 게이트(gate)가 나쁜 행동을 줄였기 때문입니다. 하지만 일단 인간 앞에 문제가 드러나면, 모든 감독 전략 테스트에서 개입 성공률은 여전히 926%에 불과했습니다. 인간은 문제를 보고도 어쨌든 승인해 버립니다. 실패는 부주의함이 아니었습니다. 그것은 합리화(rationalization)였습니다. 사람들은 스스로 에이전트의 답변을 납득시켜버린 것입니다.

자동화 편향(Automation bias). 사람들은 시스템 제안을 과신하고, 특히 시간 압박 하에서 면밀한 검토 없이 승인합니다. 한 리뷰어는

실제 차이점(diff)을 보여주고 요약하지 마세요. 인간이 오류를 포착할지 여부를 예측하는 가장 큰 지표는 그들이 검증 가능한 무언가를 보는지 여부입니다.

승인을 서버에 결합하세요 (Bind the approval to the server). 클라이언트에서만 존재하는 승인은 위조될 수 있습니다. 만약 "approved: true"가 에이전트가 재현(replay)하는 메시지 기록의 단순한 필드일 뿐이라면, 공격자나 혼란에 빠진 재시도 루프(retry loop)가 이를 조작하거나 재현할 수 있습니다. 승인은 위조되거나 재현될 수 없도록 암호학적으로 서버에 결합되어야 합니다. 즉, 서버가 특정 작업에 연결된 서명된 일회용 토큰(single-use token)을 발행하고, 해당 토큰 없이는 실행을 거부해야 합니다. 서버에 결합되지 않은 게이트는 UX적 편의(affordance)일 뿐, 보안 제어(security control)가 아닙니다.

가능한 한 게이트(gating)보다 예방(prevention)을 우선시하세요. 가장 좋은 승인 게이트는 종종 필요하지 않은 게이트입니다. 대신 작업을 안전하게 만들었기 때문입니다. 예를 들어, main 브랜치로 직접 푸시하는 대신 PR(Pull Request) 뒤의 기능 브랜치(feature branch)로 푸시하는 방식으로 G2 작업을 클릭 한 번으로 되돌릴 수 있게 만든다면, 이는 G1 단계로 낮아지며 승인에 대한 문제 자체가 사라집니다. 가역성(Reversibility, rail-reversible)은 차선책이 아닌, 최우선적인 안전 조치입니다.

모든 실제 게이트는 또한 RAIL 원칙을 충족해야 합니다: 작업은 가능한 경우 Reversible(가역적)이어야 하고, 행위자는 이에 대해 Authorized(권한 부여됨) 되어야 하며(rail-authorized), 작업은 Interruptible(중단 가능)해야 하며, 결정 사항은 Logged(기록됨) 되어야 합니다. 이 네 가지를 확인할 수 없다면, 당신은 게이트를 가진 것이 아닙니다. 그저 희망을 품고 있을 뿐입니다.

하지 말아야 할 것

차단 목록 연극 (Denylist theater). "위험한" 명령어의 차단 목록(blocklist)을 유지하고 이를 보안으로 취급하는 것은 가장 흔한 실수 중 하나입니다. 명령어 문자열로 구성된 차단 목록은 매우 쉽게 우회됩니다: base64 인코딩, 서브쉘(subshells), 인용구 트릭(quoting tricks), 또는 에이전트가 차단 목록에 걸리지 않는 스크립트를 생성하여 실행하는 방식 등이 있습니다. 에이전트의 명령어를 패턴 매칭하는 것은 샌드박스(sandbox)가 아닙니다. 에이전트가 할 수 있는 일을 제한해야 한다면, 명령어 문자열이 아니라 환경(네트워크 차단, 범위가 제한된 자격 증명, 휘발성 머신 등)을 제한해야 합니다.

위조 가능한 클라이언트 측 승인 (Forgeable client-side approvals). 위에서 언급했듯이, 승인이 서버에 결합되어 있지 않다면 그것은 장식에 불과합니다. 메시지 기록이 편집되거나 재전송(replay)될 수 있다고 가정하고, 결합되지 않은 "예"가 공격자에게 아무런 이득도 주지 않도록 설계하십시오.

승인 도장 그 자체 (The rubber stamp itself). 자체 지표를 주의 깊게 살펴보십시오. 승인율이 일관되게 100%에 가깝다면, 이는 게이트웨이가 아무것도 잡아내지 못하고 대신 책임을 세탁하고 있다는 의미입니다. 승인량(approval volume)이 아니라 개입의 성공 여부(인간이 실제로 결과를 얼마나 자주 바꾸는지)를 측정하십시오. 결코 거절하지 않는 게이트는 감독(oversight)이 아닙니다.

승인을 요청하는 대신 차단해야 할 때

이것이 진정한 감독과 보여주기식 행위(theater)를 구분하는 움직임입니다. 어떤 행동의 결과가 중대하지만, 검토할 내용이 너무 많거나, 반응할 시간이 없거나, 혹은 결과가 발생한 후에야 실패를 인지할 수 있는 등 인간이 현실적으로 오류를 잡아낼 수 없는 상황이라면, 승인을 요청하지 마십시오. 대신 나쁜 결과가 발생하지 않도록 차단하십시오:

• 결과(consequence)를 축소하십시오. 최악의 상황에서도 생존할 수 있도록 실행을 되돌릴 수 있게 만들거나, 영향 범위(blast radius, 최대 지출액, 최대 수신자, 최대 행 수 등)를 제한하십시오.
• 샌드박스화(Sandbox it) 하십시오. 안전 경계(safety boundary)를 개별 동작에 대한 프롬프트가 아닌 환경(environment) 단계로 옮기십시오.
• 실질적인 결정을 강제하십시오. 인간을 반드시 참여시켜야 하는 경우, 인간이 에이전트의 권장 사항을 단순히 따르기만 하지 않도록 권장 사항을 보기 전에 먼저 참여하게 만드십시오.
• 거부하고 에스컬레이션(escalate) 하십시오. 위의 방법들이 모두 불가능하다면, 에이전트는 해당 동작을 수행해서는 안 됩니다. 문맥이 풍부한 요약본과 함께 인간 의사결정권자에게 전달하십시오.

공유 브랜치에 대한 강제 푸시(force-push)는 '행동 전 확인(confirm-before-acting)'을 요구하는 G2 단계의 프롬프트가 되어서는 안 됩니다. 인간이 방금 승인한 이력을 되돌려 파괴를 되돌릴 수 없기 때문입니다. 이는 G3 단계, 즉 설계에 의한 차단(prevent by design), 제작자-검토자(maker-checker) 구조, 또는 거부(refuse)에 해당합니다. 테스트 기준은 변하지 않습니다: 인간이 제때 이것을 잡아낼 수 있는가? 만약 정직한 답변이 '아니오'라면, 승인 프롬프트는 잘못된 도구입니다.

핵심 요약 (Key takeaways)

• 올바른 질문은 "인간이 이것을 검토해야 하는가?"가 아니라 **"인간이 현실적으로 이 실수를 제때 잡아낼 수 있는가?"**입니다. 만약 그렇지 않다면, 승인 게이트(gate)를 만들기보다 예방(prevent)해야 합니다.
• 가역성(reversibility), 영향 범위(blast radius), 그리고 위험도(stakes)를 기준으로 모든 행동을 G0에서 G3까지 등급화하고, 그에 맞는 대응 방식을 매칭하세요: 실행+로그 기록 (G0), 실행 후 취소 기능과 함께 알림 (G1), 미리보기+승인 (G2), 예방/제작자-검토자(maker-checker)/거부 (G3).
• 승인 게이트(approval gates)는 잘못된 행동을 줄여주지만, 인간이 이를 잡아내는 능력을 개선하는 데는 거의 도움이 되지 않습니다. 자동화 편향(Automation bias)과 인지 병목 현상(recognition bottleneck)은 실재하며 잘 문서화되어 있는 문제입니다.
• 효과적인 게이트를 구축하세요: 실제 차이점(real diffs) 확인, 되돌릴 수 없는 행동에 대한 제작자-검토자(maker-checker) 방식, 가치 조건부 임계값(value-conditional thresholds), 서버 기반 승인, 그리고 게이트를 통한 통제보다 예방(prevention) 우선.
• **차단 목록 연극(denylist theater)**과 **위조 가능한 클라이언트 측 승인(forgeable client-side approvals)**을 피하세요. 둘 다 보안 경계(security boundary)가 될 수 없습니다.
• 승인율이 아니라 개입의 성공 여부를 측정하세요. 한 번도 거절하지 않는 게이트는 형식적인 승인(rubber stamp)에 불과합니다.

다음 단계 (Where to go next)

대화형 등급 판정기 (interactive grader)를 사용하여 에이전트의 행동을 등급화한 다음, 플레이북 (playbook)을 통해 각 등급을 구체적인 감독 설계로 전환하세요. 전체 방법론과 모든 주장의 근거를 확인하려면 프레임워크 (framework)와 코덱스 (codex)를 읽어보시기 바랍니다.

원문은 looprails.dev/article-ai-agent-approval.html에 게시되었습니다. LoopRails는 AI 에이전트에 대한 인간 참여형(human-in-the-loop) 감독을 설계하기 위한 무료 오픈 소스 프레임워크입니다.