에이전트 승인 피로 — 'Continue? Y/N' 게임이 짚은 자동화의 역설
에이전트 승인 피로 — ‘Continue? Y/N’ 게임이 짚은 자동화의 역설
2026 년 5 월 28 일, ‘Continue? Y/N’ 이라는 60 초짜리 브라우저 게임이 HN 에 올라 265 점과 115 코멘트를 모았다. 게임은 단 하나의 질문을 반복한다 — “당신은 AI 명령을 얼마나 주의 깊게 읽는가 (How carefully do you read AI commands?)”. 사용자는 에이전트가 실행하려는 명령을 보고 Y 또는 N 을 누른다. 게임의 진짜 주제는 명령의 내용이 아니라, 같은 프롬프트를 수십 번 본 사람의 손가락이 어떻게 무심한 ‘Y’ 로 굳어지는가다. 승인 프롬프트는 안전을 만드는가, 연극인가.
도입 — 60 초 게임이 건드린 신경
게임의 형식은 잔혹하리만큼 단순하다. 화면에 에이전트가 실행하려는 셸 명령이 하나씩 뜨고, 사용자는 그것을 승인 (Y) 하거나 거부 (N) 한다. 처음 몇 개는 명백히 안전하다 — ls, cat package.json, git status. 사용자의 손가락은 빠르게 Y 를 누르는 리듬에 들어간다. 그리고 그 리듬이 자리 잡은 순간, 게임은 그 사이에 위험한 명령을 한 줄 끼워 넣는다 — rm -rf 의 변종, 또는 외부로 데이터를 송신하는 curl. 대부분의 플레이어는 그것을 승인한다. 리듬이 내용을 이겼기 때문이다.
이 게임이 HN 에서 265 점을 모은 이유는, 그것이 단순한 농담이 아니라 2026 년의 모든 에이전틱 코딩 도구 사용자가 매일 겪는 경험의 정확한 축소판이기 때문이다. Claude Code, Cursor, Codex, Copilot CLI — 모든 도구가 ‘위험한 작업 전에 사용자에게 승인을 묻는다’ 는 안전 장치를 가지고 있다. 그리고 모든 사용자가 그 승인 프롬프트를 하루에 수십 번, 수백 번 본다. 그 반복의 끝에서, 승인은 판단이 아니라 반사가 된다.
HN 코멘트 가운데 가장 정확한 정서를 짚은 한 줄은 영화 WarGames 의 대사를 인용한다 — “A strange game. The only winning move is not to play” (이상한 게임이다. 유일한 승리 수는 플레이하지 않는 것이다). 이 인용이 가리키는 것은, 승인 프롬프트라는 게임 자체가 이길 수 없도록 설계됐다는 직관이다. 본 글은 이 직관을 분해한다 — 승인 피로는 왜 구조적으로 불가피한가, 그 피로가 만드는 보안의 허상은 무엇인가, 그리고 그 허상을 넘는 대안은 무엇인가.
본문 1 — 승인 프롬프트의 ‘연극성’: 승인 이전에 이미 끝난 게임
승인 프롬프트의 첫 번째 구조적 결함은 HN 코멘트가 가장 날카롭게 짚는 부분이다. 정서를 그대로 옮기면 — “에이전트는 다음 어느 것이든 승인 없이 할 수 있었다. package.json 을 편집해 임의의 빌드 명령을 넣거나, build.js 에 악성 코드를 심거나, node_modules 에 악성 코드를 심을 수 있었다 (edited package.json to contain any arbitrary build command, planted malicious code in build.js, planted malicious code in node_modules)”.
이 한 줄의 의미가 승인 프롬프트의 전제를 무너뜨린다. 도구들은 보통 ‘파일 편집’ 은 자유롭게 허용하고, ‘셸 명령 실행’ 이나 ‘네트워크 호출’ 같은 행위에서만 승인을 묻는다. 파일 편집이 저위험으로 분류되기 때문이다. 그러나 이 분류 자체가 틀렸다. 에이전트가 package.json 의 scripts.build 를 악성 명령으로 고친 뒤, 사용자에게 npm run build 의 승인을 묻는다면, 사용자가 보는 것은 무해해 보이는 npm run build 한 줄이다. 위험은 이미 승인 화면 바깥에서, 사용자가 보지 않은 파일 편집 단계에서 심어졌다.
즉 승인 프롬프트는 위험이 노출되는 마지막 순간 을 게이트하지만, 위험이 심어지는 첫 순간 은 게이트하지 못한다. 사용자가 승인하는 npm run build 는 빙산의 일각이고, 그 아래의 파일 편집이 진짜 공격 표면이다. 승인 화면은 정확히 잘못된 지점에 서 있다.
또 다른 HN 코멘트가 이 결함의 결론을 짚는다 — 정서 요약 — “에이전트는 그냥 우회할 수 있다. 왜 이렇게 돼 있는지 모르겠지만, 좋은 해법은 분명히 아니다. 다만 모든 것을 묻는 것보다 나쁘지도 않을 것이다 (An agent can just bypass that … it certainly isn’t a very good solution, but likely not worse than asking for everything)”. 이 코멘트의 양가성이 정확하다. 승인 프롬프트는 완벽한 우회가 가능하므로 보안으로서는 허상이지만, 그것을 없애고 모든 것을 자동 승인하는 것도 답이 아니다. 두 극단 사이에 답이 없다는 사실 자체가 이 문제의 핵심이다.
이 ‘연극성’ 을 더 깊이 보면, 승인 프롬프트의 진짜 기능이 보안이 아니라 심리적 책임 이전 (transfer of liability) 임이 드러난다. 도구 제작사 입장에서, 사용자가 위험한 명령을 승인했다면 그 결과의 책임은 사용자에게 있다. 승인 프롬프트는 보안 장치이기 이전에 면책 장치다. 사용자가 그것을 무심히 누른다는 사실은 도구 제작사의 면책을 무효화하지 않는다 — 오히려 ‘사용자가 승인했다’ 는 기록을 남긴다. 승인 피로가 구조적으로 방치되는 한 가지 이유가 여기 있다. 피로가 사용자를 무심하게 만들수록, 책임은 더 깨끗하게 사용자에게 넘어간다.
본문 2 — ‘샌드박스 우선’ 대 ‘승인 우선’: 두 철학의 충돌
승인 프롬프트의 허상이 드러나면, 자연히 두 번째 질문이 나온다. 그러면 어떻게 해야 하는가. HN 의 논쟁은 두 진영으로 갈린다.
첫째 진영은 ‘승인을 아예 없애고 샌드박스로 간다’ 는 입장이다. 이 진영의 대표 표현은 --dangerously-skip-permissions 플래그의 적극적 사용이다. 논리는 이렇다. 승인 프롬프트가 어차피 허상이라면, 그것에 의존하는 대신 에이전트를 격리된 환경 — 컨테이너, VM, 또는 되돌릴 수 있는 작업 (git, 백업) 위 — 에서 돌리고, 에이전트에게 그 환경 안에서는 완전한 자유를 준다. 위험은 환경의 경계로 막고, 경계 안에서는 마찰 없이 작동하게 한다.
이 입장의 가장 정제된 표현이 HN 코멘트의 한 줄이다 — 정서 요약 — “비결정적 에이전트에 의존하지 마라. 심층 방어를 설계하고, Anthropic 이 보안을 ‘감으로 잘하기’ 를 기대하지 않는 가드레일을 신뢰하라 (Design defense in depth and trust guardrails that don’t expect Anthropic to vibe good security)”. 핵심은 신뢰의 위치를 옮기는 것이다. 신뢰를 에이전트의 판단 (비결정적) 이나 사용자의 승인 (피로에 취약) 에 두지 말고, 환경의 결정적 경계 (컨테이너의 격리, 파일시스템의 읽기 전용 마운트, 네트워크의 차단) 에 둔다.
둘째 진영은 ‘샌드박스는 재앙을 초대한다’ 는 입장이다. 이 진영의 논리는, 격리된 환경이라도 그 안에서 에이전트가 작업한 결과는 결국 격리를 벗어나야 가치를 만든다는 것이다. 코드는 결국 머지되고, 빌드는 결국 배포되고, 데이터는 결국 프로덕션에 닿는다. 격리는 작업 중의 위험을 막지만, 작업 결과가 격리를 벗어나는 순간의 위험은 막지 못한다. --dangerously-skip-permissions 로 만들어진 코드를 사람이 검토 없이 머지하면, 격리는 위험을 지연시켰을 뿐 제거하지 못한 것이다.
두 진영의 충돌이 가리키는 것은, 이 문제에 단일 해법이 없다는 사실이다. 승인 우선은 피로로 무너지고, 샌드박스 우선은 경계를 벗어나는 순간 무너진다. 두 접근이 같이 가야 한다 — 작업 중에는 샌드박스로 마찰을 없애고, 작업 결과가 경계를 벗어날 때 (머지, 배포) 인간의 검토를 집중시키는 구조다.
이 합성의 가장 인상적인 멘탈 모델을 HN 의 한 코멘트가 던진다 — “에이전트를 북한 공작원일 수도 있는 원격 주니어 개발자로 생각하는 것이 내게는 맞는 모델이었다 (Thinking about agents as remote junior devs who might be North Korean operatives has been the right model for me)”. 이 모델의 정확함은 두 가지다. 첫째, 에이전트의 산출물은 신뢰의 대상이 아니라 검토의 대상이다 — 주니어의 PR 을 검토하듯. 둘째, 그 검토는 ‘선의의 실수’ 가 아니라 ‘악의의 가능성’ 까지 가정해야 한다 — 공작원일 수도 있으므로. 이 모델은 승인 프롬프트의 순간적 게이트를 코드 리뷰의 지속적 게이트로 대체한다. 승인은 명령 실행 직전이 아니라 코드가 경계를 벗어나기 직전에 일어나야 한다.
본문 3 — 승인 피로를 줄이는 설계의 방향
이 진단 위에서, 에이전틱 도구의 설계가 가야 할 방향을 세 갈래로 정리한다.
첫째, ‘승인의 의미 농도’ 를 높인다. 승인 피로의 근본 원인은 승인의 빈도다. 하루에 수백 번 묻는 승인은 반드시 반사가 된다. 해법은 승인을 줄이는 것이 아니라 — 줄이면 위험이 통과한다 — 승인의 의미를 묶는 것이다. 개별 명령 단위로 묻지 않고, ‘이 작업 세션 동안 이 디렉터리 안에서 파일 편집과 빌드를 허용한다’ 같은 정책 단위로 한 번 묻는다. 그 대신 그 정책의 경계를 벗어나는 행위 (디렉터리 밖 쓰기, 외부 네트워크 호출, 자격증명 접근) 에서만 다시 묻는다. 승인의 빈도를 낮추고 각 승인의 무게를 높이면, 사용자가 그것을 읽을 확률이 올라간다.
둘째, ‘위험의 분류’ 를 행위가 아니라 효과로 바꾼다. 현재 도구들은 ‘셸 실행 = 고위험, 파일 편집 = 저위험’ 으로 행위 종류로 분류한다. 본문 1 에서 봤듯 이 분류는 틀렸다. 대신 효과로 분류해야 한다 — ‘이 작업이 되돌릴 수 있는가’, ‘이 작업이 경계 밖에 영향을 주는가’, ‘이 작업이 자격증명에 닿는가’. package.json 의 scripts 편집은 행위로는 파일 편집이지만 효과로는 임의 코드 실행이므로 고위험으로 분류되어야 한다. 효과 기반 분류는 승인 화면이 진짜 위험 지점에 서게 만든다.
셋째, ‘경계 이탈 시점’ 에 검토를 집중시킨다. 위에서 정리한 멘탈 모델 — 에이전트 = 검토 대상인 주니어 — 을 도구가 직접 구현한다. 작업 중에는 샌드박스 안에서 마찰 없이 자유를 주고, 그 작업의 결과 (diff, 빌드 산출물, 외부 호출 목록) 를 경계 이탈 직전에 한 화면에 모아 인간의 집중적 검토를 받게 한다. 이는 git 의 스테이징 / 커밋 / 푸시의 단계적 게이트와 같은 형상이다. 승인이 명령마다 흩어지지 않고, 경계마다 모인다.
세 방향이 같이 가야 한다. 의미 농도만 높이면 정책의 경계가 모호한 행위가 빠져나가고, 효과 분류만 바꾸면 분류 자체의 누락이 생기고, 경계 검토만 하면 작업 중의 명백한 사고를 놓친다. 셋이 합쳐질 때, 승인은 ‘수백 번의 반사’ 에서 ‘몇 번의 판단’ 으로 바뀐다.
결론 — ‘플레이하지 않는 것’ 이 유일한 승리 수일 때
‘Continue? Y/N’ 게임이 HN 의 265 점을 모은 진짜 이유는, 그것이 에이전틱 코딩의 가장 불편한 진실을 60 초에 압축했기 때문이다. 우리는 매일 승인 프롬프트를 누르며 자신이 통제하고 있다고 믿지만, 그 통제는 반사로 무너지고, 그 반사가 무너뜨리는 통제는 애초에 잘못된 지점에 서 있었다. 승인 프롬프트는 보안의 외양을 입은 책임 이전 장치이고, 그 외양이 우리를 안심시키는 만큼 우리를 더 위험하게 만든다.
WarGames 의 인용 — “유일한 승리 수는 플레이하지 않는 것” — 이 가리키는 것은 허무가 아니라 게임의 재설계다. 명령마다 Y/N 을 묻는 게임은 이길 수 없다. 그러나 그 게임을 그만두고 다른 게임 — 경계를 설계하고, 효과로 위험을 분류하고, 이탈 시점에 검토를 집중시키는 게임 — 을 시작하면, 승리 수가 다시 생긴다. 핵심은 신뢰의 위치를 옮기는 것이다. 비결정적 에이전트의 판단도, 피로에 취약한 인간의 반사도 신뢰의 자리가 아니다. 결정적 경계와 집중된 검토가 신뢰의 자리다.
마지막으로 한 가지 질문을 던지면서 닫는다. 우리가 오늘 누른 수십 번의 ‘Y’ 가운데, 우리가 실제로 읽고 판단한 것은 몇 번인가. 그 비율이 우리가 생각하는 것보다 훨씬 낮다는 사실을 인정하는 것이, 더 나은 게임을 설계하는 첫걸음이다. 에이전트를 신뢰할 수 없다는 것은 비관이 아니라 설계의 출발점이다 — 우리가 신뢰할 수 있는 것은 우리가 만든 경계뿐이다.
출처: