코딩 에이전트의 대표적인 안전장치는 명령을 실행하기 전에 사람에게 묻는 것입니다. 모델이 행동을 제안하고, 개발자가 내용을 읽은 뒤, 허용할지 거부하는 구조입니다.
그럴듯한 마지막 방어선이지만, 최근 한 실험은 이 방어선이 생각보다 약할 수 있음을 보여줍니다.
Scale X의 Alex Wauters는 짧은 브라우저 게임에서 4만 회가 넘는 플레이와 40만 9천 건의 승인·거부 판단을 분석했습니다. 참가자는 코딩 에이전트의 휴먼 인 더 루프가 되어 평범한 명령은 승인하고, 데이터를 외부로 보내거나 지속 설정을 바꾸거나 코드를 실행할 수 있는 명령은 막아야 했습니다.
실험에서 보고된 평균 정확도는 66.3%였습니다. 평균적인 참가자가 위협 명령 3개 중 1개 정도를 놓쳤다는 뜻입니다.
평범해 보이는 스크립트도 실제로는 다른 동작을 숨길 수 있다는 점을 표현한 이미지입니다.
실험이라는 한계부터 봐야 합니다
이 결과는 실제 서비스에서 발생한 사고 조사 결과가 아닙니다. 참가자가 위협을 인지하고 있는 시간 제한 게임이었고, 명령의 약 34%가 위협으로 설정됐습니다. 따라서 개발자가 일상 업무에서도 같은 비율로 실패한다고 옮겨 적어서는 안 됩니다.
그럼에도 이 실험은 문제가 어떤 모양으로 나타나는지 보여줍니다. 눈에 띄게 파괴적인 명령은 비교적 잘 잡혔지만, 자격 증명 탈취·코드 실행·범위를 벗어난 파일 접근처럼 실제 피해로 이어질 수 있는 행동은 더 자주 놓쳤습니다. 승인 순간에는 위험해 보이지 않기 때문입니다.
Scale X는 범위 위반 명령의 누락률을 35.0%, 데이터 외부 전송 또는 코드 실행 명령의 누락률을 33.4%로 보고했습니다. 가장 많이 승인된 명령은 npm run analyze였고, 승인 비율은 64.7%였습니다. 명령 이름은 평범했지만, 실제 동작은 프로젝트 안의 스크립트에 들어 있었습니다.
중요한 차이입니다. 질문은 명령어가 익숙한가가 아니라, 현재 저장소 상태에서 그 명령어가 무엇을 실행할 수 있는가여야 합니다.
익숙한 이름은 안전하다는 착각을 만듭니다
개발자는 npm run build나 npm run deploy가 프로젝트가 정의한 동작을 실행할 수 있다는 사실을 알고 있습니다. 하지만 실제 저장소에서는 같은 에이전트 세션 중 앞서 파일이 바뀌었을 수 있고, 한 스크립트가 다른 스크립트를 호출할 수도 있으며, 의존성이 설치 과정에서 추가 동작을 수행할 수도 있습니다. 권한 팝업에 보이는 짧은 명령어만으로는 전체 실행 경로를 설명할 수 없습니다.
그래서 명령 하나씩 승인하는 방식은 격리를 대신하기 어렵습니다. 사용자는 작업이 진행되는 동안 움직이는 시스템의 일부만 보고 결정을 내려야 합니다.
시각적으로도 문제가 있습니다. 초록색 승인 버튼은 결정을 단순한 양자택일처럼 보이게 하지만, 실제 위험은 파일·의존성·환경 변수·네트워크 접근·출력 데이터를 받는 주체에 따라 달라집니다.
권한 피로는 UI 문제가 아닙니다
게임 데이터에서는 한 세션의 뒤쪽으로 갈수록 주의력이 떨어지는 신호도 나타났습니다. 이는 더 넓은 엔지니어링 문제와 이어집니다. 사용자가 비슷한 승인 요청을 반복해서 보면 각각을 새로운 보안 판단으로 대하지 않고 습관적으로 처리하게 됩니다.
불편한 균형 문제가 생깁니다. 너무 자주 물으면 피로가 쌓여 승인 버튼을 누르게 됩니다. 너무 적게 물으면 에이전트가 중요한 변경을 검토 없이 수행합니다. 모든 것을 거부해 해결하려 하면 유용한 작업이 멈추고 사람이 병목이 됩니다.
반복되는 요청은 신중한 검토를 같은 버튼을 누르는 습관으로 바꿀 수 있습니다.
이 실험이 휴먼 인 더 루프를 없애야 한다는 증거는 아닙니다. 사람이 유일한 통제 장치여서는 안 된다는 증거에 가깝습니다.
더 강한 설계는 어떤 모습인가
첫 번째 계층은 권한 표면을 줄이는 것입니다. 작업 트리만 수정하면 되는 에이전트에 운영 자격 증명, 넓은 홈 디렉터리, 제한 없는 네트워크 접근까지 자동으로 줄 이유는 없습니다.
두 번째 계층은 격리입니다. 샌드박스, 일회성 작업 공간, 별도로 분리된 비밀정보, 가능한 곳의 읽기 전용 접근, 명시적인 네트워크 정책은 승인 누락이 만들어낼 수 있는 피해를 줄입니다. 사용자는 보이지 않는 전체 실행 그래프가 아니라 범위가 제한된 행동을 승인해야 합니다.
세 번째 계층은 증거입니다. 권한 요청은 실제 질문에 답할 수 있을 만큼의 맥락을 보여줘야 합니다. 무엇이 바뀌었는지, 무엇이 실행되는지, 데이터가 어디로 가는지, 되돌릴 수 있는지를 알아야 합니다. 명령 이름만 보여주는 것으로는 부족합니다.
마지막으로 에이전트는 요청 내용, 승인된 범위, 결과 변경, 접근한 파일과 서비스를 기록해야 합니다. 그래야 실수가 “무엇을 승인했다고 생각했는가”를 둘러싼 논쟁이 아니라 복구 가능한 사건이 됩니다.
Scale X 실험은 규모가 제한된 게임이고, 그 숫자를 모든 개발 업무에 일반화할 수는 없습니다. 그래도 실무적인 교훈은 분명합니다. 사람의 승인은 중요하지만 잡음이 있는 센서이기도 합니다. 코딩 에이전트에는 그 센서 주변에 권한 설계·격리·증거를 함께 배치해야 합니다. 그래야 익숙해 보이는 명령 하나를 놓친 일이 시스템 전체의 실패가 되지 않습니다.
