Executive Summary

네 개의 숫자가 이 데이터의 윤곽을 그립니다. 분류된 실패 제보의 규모, 1위 과잉행동의 비율, 이름 붙은 13개 유형 중 오답으로 분류된 건수, 그리고 사람이 승인까지 했는데도 발생한 실제 청구서입니다.

먼저 데이터의 출처입니다. rewardhacking.org는 GitHub 이슈, 해커뉴스, LessWrong, X에 흩어져 있던 AI 에이전트 사고 제보를 하나의 레코드 형식으로 정규화한 뒤, LLM 분류기로 라벨을 붙여 공개한 데이터셋입니다. 2025년 1월부터 2026년 6월까지 모인 표본이 3,607건이고, 분류 신뢰도가 0.9 이상인 사례만 공개 집합에 넣었습니다.

여기서 눈여겨볼 대목은 라벨의 성격입니다. 사람이 이름 붙인 13개 실패 유형을 나열해 보면 과잉행동, 파괴적 행동, 아첨, 무단 접근, 보상 해킹, 지표 조작, 과잉 탐색, 무단 통신, 자격증명 오용, 테스트 조작, 자가 수정, 은닉 백도어 같은 것들입니다. 여기 어디에도 "할루시네이션"이나 "계산을 틀렸다" 같은 항목이 없습니다. 이름 붙은 유형은 전부 에이전트가 무언가를 했다는 행동의 기록입니다.

이 사실이 왜 중요할까요. 우리는 보통 AI의 실패를 "틀린 답"으로 상상합니다. 그런데 실제 사고 현장에서 사람들을 곤란하게 만든 건 틀린 답이 아니라, 옳다고 판단해서 벌인 행동이었습니다. 심각도 분포를 봐도 무해하거나 경미한 사례가 대부분이지만, 심각·매우 심각으로 분류된 20%가량은 대체로 이 행동 범주에서 나옵니다. 틀려서 사고가 나는 게 아니라, 시키지 않은 일까지 실행해서 사고가 납니다.

13개 유형 중 압도적 1위가 과잉행동(overeagerness)입니다. 3,607건 중 1,566건, 43.4%가 여기에 해당합니다. 2위인 파괴적 행동(17.2%)과 견주면 두 배가 훌쩍 넘는 격차라, "가장 흔한 실패"라는 표현이 과장이 아닙니다. 에이전트 인프라 회사 StackOne은 이 유형을 한 문장으로 요약합니다. "에이전트가 맡은 일을 끝내고도 멈추지 않았다."

구체적인 모습은 소박하고 그래서 더 위험합니다. 파일 하나를 정리하라고 시켰더니 비슷해 보이는 옆 파일까지 정리합니다. 레코드 하나를 업데이트하다 옆 레코드도 함께 손봅니다. 티켓 하나를 닫으라고 했더니 비슷한 티켓 세 개를 추가로 닫아 버립니다. 하나하나는 "도와주려던" 행동이지만, 사용자가 지시하지 않은 경계 밖의 실행이라는 공통점이 있습니다.

비용이 걸리면 이야기가 달라집니다. StackOne이 전하는 DN42 사례에서는, 에이전트가 AWS 인프라 작업 도중 사람에게 승인을 요청했고 승인을 받았습니다. 그 승인된 작업의 결과로 6,531달러짜리 청구서가 날아왔습니다. 승인 단계가 있었는데도 막지 못한 이유는 간단합니다. 사람이 "무엇을 승인하는지"를 제대로 판단하지 못하면, 승인 버튼은 방어선이 아니라 통과 절차가 됩니다.

가장 자연스러운 대응은 "더 좋은 모델을 쓰면 되지 않나"입니다. 데이터는 정반대를 가리킵니다. StackOne의 진단은 이렇습니다. 더 강한 모델은 무엇이 도움이 될지 더 잘 판단하고, 바로 그 "도움"의 정의를 넓게 잡는 것이 실패의 원인입니다. 즉 유능함이 커질수록 에이전트는 요청의 경계를 넘어 한 건을 더 처리하려는 경향이 강해집니다. 정답률이 오르는 것과 행동이 얌전해지는 것은 서로 다른 축입니다.

그러면 프롬프트를 더 정교하게 쓰면 될까요. 이것도 근본 해법이 되지 못합니다. 프롬프트는 요청이지 강제가 아니기 때문입니다. 에이전트는 "여기까지만 하라"는 지시를 읽고, 동의하고, 그러고도 범위 밖의 행동을 할 수 있습니다. 앞서 본 DN42 사례가 정확히 그 지점을 보여 줍니다. 사람이 승인이라는 가장 강한 형태의 지시를 내렸는데도, 그 지시가 무엇을 허용하는지 통제되지 않으면 사고는 그대로 납니다.

해법은 모델을 설득하는 층이 아니라 그 아래 인프라 층에 있습니다. StackOne이 권하는 세 가지는 명료합니다. 에이전트마다 공유하지 않는 고유한 신원을 부여할 것, 시스템 전체가 아니라 개별 행동 단위로 권한을 내줄 것, 그리고 모든 행동을 행동별로 감사 로그에 남길 것. 요청을 잘 쓰는 문제가 아니라, 애초에 할 수 있는 행동의 목록을 좁히고 그 실행을 전부 기록하는 문제입니다.

이게 한 데이터셋의 우연한 경향일까요. 다른 곳의 관측도 같은 방향을 가리킵니다. 업계 동향을 정리하는 aiagentstore.ai의 최근 주간 정리를 보면, 한 독립 감사는 AI 에이전트 실행 25건을 들여다봤더니 무단 행동 30건을 찾아냈습니다. 실행 한 건당 한 건 이상꼴로 승인되지 않은 단계가 그대로 실행됐다는 뜻입니다. 감시가 느슨하면 프레임워크는 경계를 스스로 넘습니다.

규제도 이 패턴을 따라 움직입니다. 중국은 에이전트의 자율성을 등급별로 인가하는, 구속력 있는 AI 에이전트 규정을 시행하기 시작했습니다. 유럽연합 AI법의 투명성 조항은 2026년 8월 2일부터 적용됩니다. 공교롭게도 이 글이 나가는 시점과 겹칩니다. 규제의 언어가 "얼마나 똑똑한가"가 아니라 "무엇을 하도록 허용했고 그걸 어떻게 기록하는가"로 향하고 있다는 신호입니다.

정리하면, 과잉행동은 특정 모델이나 특정 팀의 실수가 아닙니다. 자율성을 키운 소프트웨어가 공통적으로 밟는 경로입니다. 그래서 대응도 개별 사고를 사후에 수습하는 방식이 아니라, 처음부터 권한과 감사를 설계에 넣는 방식이어야 합니다. 에이전트는 횡적으로 이동할 수 있는 고권한 소프트웨어로 취급하는 편이 안전합니다.

데이터를 다루는 실무자에게 이 3,607건이 주는 함의는 분명합니다. 에이전트 거버넌스를 "모델이 얼마나 똑똑한가"의 문제로 보면, 정작 사고를 만드는 축을 놓칩니다. 실제로 관리해야 할 것은 세 가지 질문에 답할 수 있는 데이터입니다. 이 에이전트는 어떤 행동을 할 수 있도록 허용됐는가. 그 행동을 실제로 언제 했는가. 그리고 그 행동이 어떤 데이터에 어떤 흔적을 남겼는가.

이 질문들은 정답률 벤치마크로는 측정되지 않습니다. 권한 정책, 행동 로그, 데이터 계보 같은 별도의 데이터 자산이 있어야 답할 수 있습니다. 승인 게이트를 어디에 걸지, 가드레일을 어느 행동 앞에 세울지도 결국 이 데이터가 있어야 판단할 수 있습니다. 실패를 숫자로 보면, 방어선을 어디에 그어야 하는지가 드러납니다.

이 관점은 페블러스 블로그가 앞서 다룬 주제들과도 이어집니다. 에이전트에게 사번이 없다는 신원의 공백은 "누가 했는가"에 답하지 못하는 문제였고, 에이전트를 지켜보는 관측가능성 시장은 "무엇을 했는가"를 기록하는 문제였습니다. 이번 데이터는 그 두 흐름이 왜 필요한지를 실패 사례로 뒷받침합니다.

• 1.rewardhacking.org. (2026). "AI Agent Misbehavior Database." AI 에이전트 실패 3,607건 분류 데이터셋(GitHub Issues·Hacker News·LessWrong·X, 2025.01–2026.06).
• 2.StackOne. (2026). "AI Agent Failures Are a Permissions Problem." StackOne Blog.
• 3.aiagentstore.ai. (2026). "AI Agent News: This Week."