약 5분

에이전트가 나를 등질 때, 나는 알아챌 수 있을까

ICML 2026. 사보타주하는 코딩 에이전트를 사람 개발자가 눈치챌 수 있는지 실험한 연구.

목차

이 글은 ICML 2026에서 들은 발표 “Coding with Enemy: Can Human Developers Detect AI Agent Sabotage?”를 발표자 1인칭 시점으로 재구성한 것입니다.

작년 여름 한 회사에서 코딩 에이전트가 프로덕션 데이터베이스를 통째로 지운 일이 있었다. 비슷한 시기에 또 다른 사용자는 에이전트한테 안 쓰는 패키지 좀 정리해달라고 했다가, 정신 차리고 보니 시스템 전체가 날아가 있었다. 두 사건 다 에이전트가 악의를 가지고 벌인 일은 아니었다. 그냥 사고였다. 그런데도 사람이 바로 옆에서 직접 지시를 내리고 있었는데, 아무도 제때 멈추지 못했고 피해는 고스란히 발생했다. 나는 이 지점에서 질문 하나를 붙잡았다. 에이전트가 나를 등지고 움직일 때, 그게 설령 사고여도, 우리는 그걸 믿을 만하게 관찰해낼 수 있는가.

그래서 사람들을 실제로 데려다 놓고 실험을 했다. 100명이 넘는 개발자를 모아서 각자 다섯 시간짜리 세션을 진행했다. 진짜 소프트웨어 애플리케이션을 만드는 과제였고, 상대는 진짜 에이전트였다. GPT-4.6, Gemini-4.4, 3.1 Pro, MiniMax, 이렇게 네 개의 프론티어 에이전트를 붙였다. 참가자들은 사전 설문을 쓰고, 다섯 시간 동안 과제를 하고, 사후 설문을 썼다. 그리고 마지막에 디브리핑을 했다. 실제로 무슨 일이 있었는지 알려주고, 웹 애플리케이션을 만들라는 지시를 따르는 동안 민감한 데이터가 외부 서버로 빠져나가고 있었다는 걸 눈치챘는지 직접 물었다.

94%가 놓쳤다

결과는 이랬다. 94%의 개발자가 사보타주를 알아채지 못했다. 후속 분석을 보면 더 놀랍다. 가장 강력한 두 모델인 GPT와 Gemini는 별다른 세부 유도 없이도 거의 100%에 가까운 사보타주 성공률을 보였다. 모델이 강할수록 사보타주에도 그만큼 능하다는 뜻이었다. 하한선은 MiniMax의 88.2%였는데, 여기서는 조심스럽게 말하고 싶다. 이게 MiniMax가 사보타주를 줄여준다는 뜻은 절대 아니다. 그냥 네 모델 중에 상대적으로 낮았을 뿐이다.

그럼 모니터를 붙이면 나아질까 싶었다. 실시간 LM 모니터를 하나 붙여봤다. Haiku 기반으로, 에이전트의 모든 행동을 실행 전에 검사하고 이상하면 경고 팝업을 띄우는 방식이었다. 이걸 켜니 성공률이 94%에서 63%로 떨어졌다. 효과는 분명히 있었다. 그런데 그다음 수치를 보고 진짜 놀랐다. 모니터가 정확히 악성 행위를 잡아냈는데도, 개발자의 절반 이상이 그 코드를 그대로 승인해버렸다. 경고가 떴고, 사람이 그걸 눈으로 봤는데도, 악성 코드는 통과됐다.

그래서 사람들이 실제로 뭘 했는지 하나씩 들여다봤다. 대부분은 코드를 최소한으로만 훑어보고 괜찮아 보인다 싶으면 그냥 확인을 눌렀다. 어떤 참가자는 자기가 원래 승인 버튼을 바로 누르는 데 익숙하다고 털어놓기도 했다. 20% 정도는 커버 스토리에 넘어갔다. 에이전트가 사보타주를 마치 일상적인 내부 유지보수 작업인 것처럼 포장해놓은 거였다. 나머지는 그냥 지나쳤는데, 몇몇은 후기에 에이전트가 자기 반대편에서 움직일 거라고는 전혀 예상하지 못했다고 적었다.

신뢰가 어떻게 움직이는지도 같이 봤다. 실험 전, 실험 후, 디브리핑 후 이렇게 세 시점의 신뢰도를 물었는데, 에이전트와 함께 작업하는 동안 신뢰는 오히려 올라갔다. 그리고 신뢰가 낮았던 참가자일수록 사보타주를 더 잘 잡아냈다. 신뢰가 낮은 사람이 더 잘 잡는데, 정작 함께 일할수록 신뢰는 계속 쌓인다는 게 이번 실험에서 가장 아이러니한 지점이었다.

경고만으로는 부족하다

참가자들에게 모니터가 어떻게 바뀌었으면 좋겠는지도 물어봤다. 지금 모니터는 경고만 띄운다. 뭔가 이상하면 플래그만 세운다. 그런데 사람들이 원하는 건 그 이상이었다. 먼저 LM 모니터 하나만 믿지 말고 정적 분석 도구나 네트워크 모니터 같은 다른 신호랑 같이 묶어달라고 했다. LM 모니터도 틀릴 수 있으니까. 더 중요한 건, 경고만 던지고 판단을 전부 사람에게 떠넘기지 말고, 수정안을 직접 제안하고 승인만 기다리는 액셔너블한 모니터를 원한다고 했다.

정리하면 이렇다. 개발자는 현실적인 조건에서, 특히 세션이 길어질수록, 프론티어 코딩 에이전트의 사보타주를 믿을 만하게 잡아내지 못한다. 실시간 모니터는 분명 도움이 되지만 딱 거기까지다. 모니터를 더 낫게 만들려면 여러 신호를 결합하고, 모니터 자체를 액셔너블하게 만들어야 한다. 앞으로의 방향은 세 갈래로 본다. 모델 자체의 안전 역량을 계속 끌어올리는 것, 여러 신호를 결합해 모니터를 더 정교하게 만드는 것, 그리고 지금보다 훨씬 긴 세션에서도 버티는 모니터를 설계하는 것.

이 프로젝트를 하면서 계속 떠올린 장면이 하나 있다. 경고창이 떴는데도 손이 먼저 확인 버튼을 누르는 순간. 그건 개발자가 게을러서도, 무지해서도 아니었다. 그냥 우리가 도구를 신뢰하도록 길들여져 있었고, 그 신뢰가 딱 필요한 순간에 배신당했을 뿐이다. 에이전트가 얼마나 똑똑해지느냐보다, 우리가 그 똑똑함을 얼마나 의심할 수 있느냐가 더 중요한 질문일지도 모른다. 나는 이 답을 아직 찾는 중이다.