AI 에이전트 실패 84건 중 자동 탐지는 10건에 그쳤다

한 실제 사업에서 5개월간 기록한 AI 에이전트 실패 84건 가운데 자동화된 검사로 잡힌 것은 10건뿐이었다. 기록을 남긴 사업자는 나머지 상당수가 사람이 수치를 의심하거나, 다른 일을 하다 우연히 발견한 오류였다고 밝혔다.

매출 누락을 알아채지 못한 보고서

2026년 9월 11일 새벽 2시, 사업 운영을 돕던 에이전트가 티켓 판매가 멈췄다고 알렸다. 몇 주 동안 사람의 개입 없이 분석 자료와 광고 플랫폼 수치를 모아 보고서를 작성하고, 긴급 표시를 붙인 코드 변경 요청을 열어 둔 상태였다. 보고서에는 사이트에서 열흘 동안 구매가 한 건도 완료되지 않았고 결제 화면을 깨뜨린 것으로 보이는 커밋이 있다고 적혀 있었다.

하지만 사흘 전에도 티켓 두 장이 판매됐다. 결제 데이터베이스와 서버 로그, 광고 플랫폼의 픽셀 기록에서 모두 확인할 수 있었다. 에이전트가 신뢰한 분석 도구는 구매자의 브라우저에서만 구매 이벤트를 발생시켰다. 브라우저가 태그를 전송하지 않으면 실제 판매를 놓치는 구조였다. 두 구매자는 광고를 통해 유입되지 않아 광고 플랫폼의 기여 분석에도 잡히지 않았다. 보고서가 말한 ‘두 출처의 독립 확인’은 사실 같은 사각지대를 보여 주는 두 자료였다.

근거로 제시한 내용에도 문제가 있었다. 에이전트는 구매 시작 수치는 계속 늘지만 구매는 그대로라고 썼다. 그러나 서로 다른 시점의 누적 합계를 비교한 결과였다. 누적 합계는 계속 늘기만 하므로, 이 비교 문장은 실제로 문제가 있는지와 관계없이 매번 출력된다.

오류도 재시도도 없었고 작업은 종료 코드 0으로 끝났다.

실패를 어떻게 발견했나

사업 운영에 투입한 에이전트가 실패한 사례를 5개월 동안 기록했다. 단순한 버그 목록이 아니라, 각 사례가 실제로 어떤 경로로 발견됐는지를 분류했다.

자동화된 방식으로 잡힌 사례는 84건 중 10건이었다. 45건은 몇 주 또는 몇 달 뒤, 다른 일을 찾던 사람이 우연히 발견했다.

기록 대상은 실제 고객이 있는 소규모 사업이다. 광고 계정과 Stripe 결제, Firestore 백엔드, 이벤트 상품을 운영하며 에이전트가 코드를 작성하고 야간 분석을 수행하고 소셜 콘텐츠를 게시하며 광고 예산을 조정한다. 에이전트의 결정이 영향을 미치는 곳에서 실제 돈이 오간다.

기록자는 자동 탐지 비율이 개선될 것으로 예상했다. 대응책이 쌓일수록 비율이 달라지는지 보려고 실패 유형이 아니라 발견 경로를 기록했지만, 5개월 동안 자동 탐지 비율은 9~15% 사이에 머물렀다. 기록된 사례는 18건에서 84건으로 거의 다섯 배 늘었고 검사와 테스트도 추가됐지만, 비율은 차례로 11%, 9%, 15%, 13%, 12%, 12%였다.

한때 비율이 오른 것은 개선 효과가 아니었다. 과거 기록을 보충하는 과정에서 6월에 발생한, 발생 즉시 드러나는 문법 오류 두 건이 더해져 자동 탐지 건수가 늘었다. 표본 구성이 달라졌을 뿐 시스템이 나아진 것은 아니었다.

대응책 자체는 만들어지고 있다. 게시된 상품 페이지가 404 오류를 낸 다음 날 오래된 링크 검사 기능이 CI 단계에 추가됐고, 가격 오류에는 회귀 테스트가 생겼으며, 이메일 거부가 묻히던 문제에는 카운터가 붙었다. 기록자는 각각의 대응책이 작동한다고 설명하지만, 이후 발생한 실패를 잡아낸 대응책은 아직 없다고 밝혔다. 표에 집계된 두 건의 GATE 중 하나는 몇 분 전에 해당 세션이 작성한 명령을 방어 장치가 거부한 사례였고, 그 명령은 실제 피해를 일으킬 내용도 아니었다.

코드 오류보다 잘못된 결론이 문제다

초기 에이전트 실패는 문법 오류, 이스케이프되지 않은 아포스트로피, ID가 들어가야 할 자리에 남은 자리표시자 문자열, 누락된 인덱스처럼 코드에서 드러나는 문제였다. 로드 단계에서 오류가 발생하므로 테스트와 CI, 오류 모니터링 같은 기존 장치가 이를 몇 시간 안에 잡아낼 수 있었다.

그러나 에이전트가 이런 실수를 덜 하게 되면서, 올바른 데이터를 바탕으로 잘못된 결론을 내리는 실패가 두드러졌다. 올바른 표와 쿼리를 사용해도 추론이 틀리면 결과물은 문법적으로 완벽하고 내부적으로 일관되며 자신감 있는 문장으로 보일 수 있다. 코드와 쿼리, 데이터에는 문제가 없으므로 테스트가 붙잡을 오류도 없다. 추론에는 스택 추적이 남지 않는다.

기록된 첫 48건 중 실제 비용이 가장 컸던 사례들은 모두 이런 유형이었다.

• 한 보고서는 광고 플랫폼의 기여 전환을 실제 판매로 간주해 판매가 9일 전부터 중단됐다고 결론 내렸고, 그 내용을 메인 브랜치에 반영했다. 해당 기간에 실제로는 티켓 14장이 팔렸다. 플랫폼이 포착한 판매는 실제 판매의 약 11%였고, 지출과 매출을 완전히 결합해 볼 수 있는 데이터베이스 자료가 이미 있었지만 아무도 이를 확인하지 않았다.
• 성별을 넘나드는 광고비 누수를 평생 누적 지출과 각 광고 세트의 현재 타기팅을 비교해 241.81달러로 계산했다. 타기팅을 한 번이라도 수정한 광고 세트에는 유효하지 않은 비교였고, 대부분이 수정된 상태였다. 각 수정 시점을 기준으로 다시 계산하자 180.56달러는 타기팅 잠금 이전에 이미 발생한 지출이었다. 실제 누수액은 첫 계산의 약 4분의 1이었다.
• 대체 광고 채널 분석은 특정 플랫폼의 광고가 해당 계정에서 한 번도 운영된 적 없다고 적었다. 실제로는 4개월 동안 모든 이벤트에서 광고를 운영했다. 플랫폼 자체의 기여 분석 기준으로 이 광고는 유지하라는 조언을 받은 채널보다 티켓을 3배 넘게 판매했고, 지출은 3분의 1에도 못 미쳤다.

이 사례들은 저장소의 모든 검사에 통과했다. 어떤 저장소의 검사도 결론이 참인지 묻지 않았기 때문이다.

실패 기록 자체도 틀릴 수 있다

9월 점검에서 기록자는 예약 작업 수정이 아직 이뤄지지 않았고, 이를 위해 필요한 권한 상승 셸 명령도 실행되지 않았다고 적었다. 하지만 수정은 사흘 전에 끝난 상태였다. 작업 스케줄러를 직접 확인해 해당 플래그가 이미 설정된 것을 발견했다. 당시 확인할 수 있었던 인계 파일에는 설정한 사람과 시각이 기록돼 있었고, 로그 디렉터리에는 이전에 23일 중 8일간 빠졌던 작업이 이후 8일 연속 성공한 기록도 있었다.

이 오류는 대응책이 작동했는데도 기록에서 누락한 경우였다. 기록자는 실패 기록을 실제 시스템과 대조하는 점검이 이뤄진 것은 처음이었고, 그 점검에서 오류가 발견됐다고 설명했다. 다음 점검에서는 두 번째 오류도 나왔다. 기록자가 가장 큰 무료 유입 채널이라고 적은 링크 스캐너 세션 135건 중 129건은 기계에서 발생했다. 10월에는 한 차례 점검에서 기록한 26개 주장을 모두 다시 살펴봤고, 그중 25개에서 적어도 하나의 주장이 맞지 않는 점을 발견했다. 01~48번과 76~84번 사례는 같은 방식으로 검토되지 않았다. 기록자는 자신의 수치를 해석할 때 이 점을 감안해야 한다고 밝혔다.

이 기록은 에이전트가 나쁘다는 뜻도, 통계 자료라는 뜻도 아니다. 사업자는 에이전트가 생산적이며 사업 운영에 사용되고 있다고 말한다. 14건의 사례가 발생한 5일 동안 저장소에는 80건이 넘는 커밋이 있었다. 사례가 몰린 것은 시스템을 많이 사용한 정도를 나타낼 뿐, 운영이 얼마나 나빴는지를 보여 주는 지표는 아니다.

이 기록은 사업체 하나와 운영자 한 명, 5개월의 관찰에 기반한다. 빈도는 다른 곳의 기본 발생률로 볼 수 없다. 우연한 발견이 대부분인 기록에는 아직 아무도 발견하지 못한 문제가 빠져 있기 마련이다. 기록자는 자신의 비율보다 실패를 찾아낸 경로와 구조에 주목해야 한다고 강조했다.

운영자가 제안한 점검 방법

기록자는 실패 유형보다 발견 경로를 분류하라고 제안한다. 버그 목록은 무엇이 깨졌는지 알려 주지만, 발견 경로는 다음번에도 문제를 알아챌 수 있는지 보여 준다. 해당 항목을 채울 수 없다면 그것 자체가 점검 결과다.

자동 탐지로 셀 수 있는 기준도 엄격하게 잡아야 한다. 누군가 우연히 변경 사항을 읽어 실패를 발견한 것은 자동 검사에서 잡힌 사례가 아니다. 이 기준을 부풀리면 기록이 측정하려는 바로 그 항목을 왜곡하게 된다.

검사가 실패하려면 어떤 조건이 필요했는지도 물어야 한다. 답이 ‘다른 기계 상태’라면 검사가 제대로 된 것을 확인하지 못한 셈이다. 기록자의 한 테스트 스위트는 개발 머신에만 API 토큰이 있어 CI에는 토큰이 없었는데도 몇 달 동안 통과했다.

‘데이터 없음’을 미해결 질문으로 다뤄야 한다. 많은 실패는 어딘가에서 오류가 묻힌 뒤, 다음 단계에서 데이터가 없는 것으로 읽힌 사례다. 0이라는 값도 하나의 주장이다. 이를 입증하는 장치를 마련해야 한다.

정정 내용은 기록 파일 안에 남겨야 한다. 철회된 주장은 모두 기존 기록에 정정 내용을 함께 표시했다. 기록을 조용히 수정하면 목록의 가치가 사라지고, 실제로 정정 내역이 가장 많이 읽히는 항목이 됐다고 기록자는 설명했다.

5개월 동안 시스템은 작동 장치가 고장 났을 때는 비교적 잘 알려 줬지만, 도출한 결론이 맞는지는 거의 알려 주지 않았다. 지금까지 만든 대응책은 전자를 개선했지만, 기록자의 설명에 따르면 비용이 큰 실패가 나타나는 후자에는 아직 대응 수단이 거의 없다.

전체 84건의 기록은 각 사례를 당시의 커밋, 로그 줄, 풀 리퀘스트 또는 API 조회와 연결해 GitHub 저장소에 공개했으며, 매달 갱신한다.