dev.to

The 15-Line Test That Catches the #1 Killer of Operator Trust

운영자의 신뢰를 무너뜨리는 오탐을 잡는 15줄 테스트

AI 에이전트 이상 탐지기 43개를 정상 추적 데이터 하나에 함께 실행하고, 어떤 탐지기도 경고하지 않는지 검사하는 테스트를 소개합니다. 이전 프로젝트에서는 경고 56,869건 중 45,575건이 오탐이었으며, 글은 개별 탐지기 테스트만으로 놓치는 통합 문제를 설명합니다.

AI 요약

AI 에이전트 이상 탐지 시스템에서 오탐이 쌓이면 운영자는 경고를 믿지 않게 됩니다. 글은 이전 프로젝트의 추적 데이터 10만 건에서 이상 징후 56,869건이 나왔지만, 탐지기를 수정하고 나니 11,294건만 남았다고 설명합니다. 45,575건, 전체 경고의 약 80%가 오탐이었습니다. 문제는 탐지기를 더 추가하는 일이 아니라, 정상 상황에서도 너무 쉽게 작동하는 기존 탐지기를 제거하거나 기준을 조정하는 일이었습니다.

탐지기를 함께 실행해야 하는 이유

탐지기별 단위 테스트는 각각의 규칙을 따로 확인합니다. 하지만 운영 환경에서는 43개 탐지기가 같은 추적 데이터를 동시에 검사합니다. 개별 테스트에서는 보이지 않던 상호작용이 생길 수 있습니다. 예를 들어 일시적인 실패 한 건이 전체 호출의 3분의 1을 차지해 오류율 임계값을 넘거나, 정상적인 느린 API 호출이 30초 비활성 기준을 넘어 경고를 만들 수 있습니다. 검색 도구를 두 번 쓰는 평범한 작업도 반복 호출로 잡힐 수 있습니다.

글이 제안하는 테스트는 명백히 정상인 추적 데이터 하나를 만듭니다. 비용과 호출 수는 각 임계값보다 충분히 낮게 두고, 재시도와 개입은 없게 합니다. 도구 이름은 서로 다르게 설정하고, 성공 상태와 충분히 긴 출력을 사용합니다. 그런 다음 모든 탐지기를 차례로 실행해 결과가 하나도 나오지 않는지 검사합니다. 결과가 나오면 탐지기 이름과 심각도, 설명을 확인해 원인을 찾습니다. 정상 입력에서 모든 탐지기가 조용해야 한다는 불변 조건을 검사하는 방식입니다.

개별 테스트가 놓치는 오류

이 테스트는 임계값을 너무 낮게 설정한 경우, 성공 상태를 잘못 처리하는 논리 오류, 속성 파싱 문제를 찾는 데 도움이 됩니다. 모든 탐지기를 함께 돌리면 탐지기 간 연쇄 반응이나 이전 시나리오의 상태가 남는 문제도 드러날 수 있습니다. 글은 이 테스트를 개별 탐지기 테스트의 대체재가 아니라 보완재로 제시합니다. 개별 테스트는 규칙을 확인하고, 정상 추적 테스트는 통합 동작을 확인합니다.

이전 프로젝트의 수치에서는 premature_completion이 35,930건을 냈고, argument_loop는 5,768건을 냈습니다. 두 탐지기는 각각 정상 오류 상태와 인수가 없는 도구 호출을 잘못 처리해 제거했습니다. pattern_loop는 2,012건에서 67건으로, step_efficiency는 1,797건에서 184건으로 줄었습니다. 전체 오탐은 80% 감소했습니다. 글은 이 테스트가 agentwatch v0.1.0의 226개 시나리오 하네스에 포함됐으며, 43개 탐지기에서 경고 없이 통과한다고 설명합니다.

dev.to 반응

  • @innokentyb — 작은 테스트는 운영자가 확인할 수 있는 불변 조건을 지킨다는 점에서 가치가 있습니다. 다만 테스트의 판정 기준이 검사 대상 코드와 독립적인지도 확인해야 합니다. 읽기 쉬운 15줄 테스트라도 구현과 같은 잘못된 가정을 담을 수 있습니다. 순서, 식별자, 오래된 상태 처리를 일부러 깨뜨리는 변이 테스트를 추가하고, 운영자가 알아차릴 오류를 테스트가 실제로 잡는지 보여주는 방법이 있습니다.
  • @hayrullah — clean trace가 premature_completion과 argument_loop를 잡았다는 주장에 기대기 전에, 글의 _clean_trace를 확인해야 합니다. 재시도는 0회이고 모든 span 상태는 ok이며, 도구 호출 3개도 이름이 서로 다릅니다. 두 탐지기가 작동한 조건인 오류 상태와, 반복되는 누락 인수는 이 입력에 없습니다. 그러므로 두 탐지기를 코드에 그대로 둬도 테스트는 통과합니다. 임계값과 거리가 먼 추적 데이터는 잘못 뒤집힌 논리와 상태 누수를 잡는 데 가치가 있지만, 테스트에 없는 정상 상황에서 오탐을 내는 탐지기까지 잡지는 못합니다. 일시적인 오류 뒤 성공한 재시도, 정상적인 35초 대기, search_kb 연속 호출, 인수 없는 도구처럼 정상인 상황을 각각 추가해야 합니다. 이런 사례마다 경고가 없어야 합니다. 오탐이 생길 때마다 사례를 늘려야 수정 사항이 다시 깨지지 않습니다.
  • @kartik-nvjk — 단일 탐지기 premature_completion이 이전 데이터의 경고 56,869건 중 35,930건, 약 63%를 냈습니다. 탐지기별 경고 비중을 봤다면 clean-trace 테스트가 나오기 전에도 첫날에 문제를 찾았을 수 있습니다. 탐지기별 경고 표본을 매주 조금씩 검토해 정밀도도 추적해야 합니다. agentwatch 운영자는 이 두 수치를 현재 확인할 수 있나요?

원문: dev.to / 번역·요약: Trawling