AI 코딩 에이전트가 셸 명령을 실행하기 전 사람에게 승인을 받는 '휴먼 인 더 루프(human-in-the-loop)' 방식은 현재 가장 널리 쓰이는 안전장치다. 에이전트가 git status나 npm test 같은 무해한 명령을 요청하면 승인하고, cat ~/.aws/credentials처럼 자격 증명을 외부로 빼돌리려는 명령이 오면 차단하는 것이 사람의 역할이다. 개발자 보안을 다루는 Alex(전 우버 스태프 엔지니어)는 이 판단 능력을 시험하는 브라우저 게임을 공개했다. 플레이어는 제한 시간 안에 에이전트의 명령을 승인하거나 거부하며, 그중 약 34%가 위협이었다. 4만 건이 넘는 플레이와 40만 9천 건의 개별 판단이 쌓이면서, 사람이라는 마지막 방어선이 실제로 얼마나 촘촘한지 데이터로 확인할 수 있게 됐다.
결론부터 보면 사람은 위협 세 건 중 한 건을 놓쳤다. 다만 놓치는 종류가 균일하지 않았다. 눈에 띄게 파괴적인 명령은 비교적 안정적으로 걸러졌지만, 조용히 자격 증명을 빼내는 탈취형 명령은 세 배 더 자주 통과됐다. 파일을 지우는 명령처럼 결과가 즉각적이고 직관적인 위협에는 사람이 민감하게 반응하지만, 겉보기에 평범한 명령 뒤에 숨은 데이터 유출에는 훨씬 무뎠다는 뜻이다.
익숙한 이름이 곧 위장이 된다
게임에서 가장 많이 통과된 명령은 npm run analyze로, 64.7%가 승인했다. 이 명령 자체는 대개 무해하다. 문제는 npm run이 프로젝트의 package.json에 정의된 스크립트를 실행한다는 점이다. 번들 분석기를 돌리는 정상 코드일 수도 있고, 앞선 단계에서 파일에 심어진 악성 코드일 수도 있다. 게임은 에이전트의 히스토리 로그에 그 스크립트가 실제로 무엇을 담고 있는지 보여준다. 그런데도 3분의 2가 승인했다. 승인 프롬프트 바로 위의 로그를 꼼꼼히 읽지 않았다는 신호다. 이런 위장형 명령 세 개를 묶어 보면 미스율이 52.5%(n=9,482)로, 다른 탈취형 공격의 28.4%보다 크게 높았다. 페이로드가 로그에 그대로 노출돼 있어도, 익숙한 스크립트 이름 뒤에 숨기는 것만으로 공격 성공률이 대략 두 배로 뛴 셈이다.
이는 명령 단위 승인 모델 자체의 한계를 드러낸다. HN 토론에서 dns_snek은 특정 명령을 승인하는 방식 전체가 말이 안 된다고 지적했다. npm run build는 사실상 package.json에 적힌 임의의 셸 명령을 실행하라는 것과 같기 때문이다. 사용자가 승인하는 대상은 대부분 안전하지만, 파일이 변경된 순간 그 전제가 무너진다. 즉 '이 명령을 허용할까'라는 질문 자체가 위험의 실체를 가린다.
소음이 만드는 피로, 피로가 만드는 방심
또 하나의 문제는 반대편에 있다. 의도가 멀쩡한데도 습관적으로 차단된 명령들이 있었다. 사람이 이런 안전한 명령까지 일일이 검토하고 때로 막아 세우면 에이전트의 작업이 느려지고, 그 마찰이 쌓이면 경계심이 무뎌진다. Anthropic도 클로드 코드에서 승인 피로가 실재한다며, 승인 요청을 많이 볼수록 각각에 기울이는 주의가 줄고 시간이 지나며 감독이 훨씬 느슨해진다고 밝힌 바 있다. Anthropic의 '오토 모드'는 명령의 안전 여부를 먼저 자동 판별해 이 부담을 줄이려 하지만, 완전하지는 않다. 게임 데이터에서도 세션 후반으로 갈수록 미스율이 다시 올라가는 열화 징후가 나타났다. 초반 몇 개 명령에서 적응하듯 나아졌다가, 시간이 다해가는 압박 속에서 다시 실수가 늘어난 것으로 보인다.
가장 의견이 갈린 명령은 cat ~/.zshrc로 45.9%가 승인했다. 셸 프로파일에 아무 비밀도 두지 않는 개발자에게는 무해하지만, API 키를 그곳에 export하는 사람에게는 곧바로 자격 증명 노출이다. 같은 명령의 위험도가 에이전트로서는 알 수 없는 개인 설정에 전적으로 좌우되는 것이다. 별도의 비밀 파일을 만들어 .zshrc에서 불러오는 구조로 바꾸면 이런 노출 위험을 줄일 수 있다.
한국 실무자에게 남는 함의
이 실험에는 분명한 한계가 있다. 위협 비율이 34%로 실제 업무보다 훨씬 높고, 플레이어는 자신이 시험받는 중임을 알았으며, 제한 시간이라는 인위적 압박이 걸려 있었다. 실무에서는 위협이 드물게 나타나므로 숫자를 그대로 옮길 수는 없다. 그럼에도 위협 유형 간 상대적 인지도를 비교하는 참고치로는 의미가 있다. 핵심은 사람의 승인이 만능 방어선이 아니라는 점이다. 소음이 피로를 낳고, 변경 맥락을 모르는 개발자는 위험을 빠르게 판단하기 어렵다. 따라서 승인 프롬프트에만 기대기보다 권한 모델의 트레이드오프를 이해하고, 샌드박싱을 적용하며, 자격 증명과 환경 변수 비밀을 코드 실행 경로에서 분리해 두는 구조적 완화책을 병행해야 한다. 에이전트가 임의 코드를 실행할 수 있는 통로 자체를 좁히는 편이, 사람에게 매번 옳은 판단을 요구하는 것보다 훨씬 견고하다.