분기별 AI 시스템 감사는 성과 검토가 아니다. 스코프 드리프트 점검이다.
스코프 드리프트는 조용하다. 시스템이 망가지지 않는다. 그저 설계된 적 없는 것들을 처리하기 시작할 뿐이다 — 폴백 경로, 누적된 프롬프트 패치, 정확도 검사 없이 커진 검색 세트를 통해서. 4개월 차가 되면 시스템은 1개월 차와 실질적으로 다른 일을 하고 있다. 아무도 계획하지 않았다. 아무도 문서화하지 않았다.
이 감사는 두 시간 이내에 끝난다. 매 분기 실행하라.
프로덕션에서 스코프 드리프트가 나타나는 방식
세 가지 패턴이 반복적으로 나타난다.
폴백 경로 누적. 쿼리가 시스템의 기본 라우팅 로직과 일치하지 않으면 기본 핸들러로 폴백된다. 간헐적인 엣지 케이스라면 괜찮다. 프로덕션 쿼리의 15%가 폴백에 도달하고 있다면 문제다 — 그 15%의 쿼리가 원래 스코프를 벗어났고 시스템이 즉흥적으로 처리하고 있다는 뜻이기 때문이다.
프롬프트 패치 누적. 특정 입력에서 프롬프트가 실패한다. 누군가 조건절을 추가해 수정한다. 그리고 또 하나. 그리고 또 하나. 6개월 후 프롬프트에는 조건절이 11개가 되고, 버전 히스토리는 없으며, 원래 로직이 무엇이었는지 아무도 설명하지 못한다. 각 패치는 합리적이었다. 전체 합산은 유지 불가능하다.
정확도 검사 없는 검색 세트 확장. 지식 베이스가 커진다 — 새 문서, 새 데이터 소스, 새 통합. 검색 커버리지는 향상된다. 검색 정밀도는 보통 그렇지 않다. 시스템은 더 많이 검색하지만, 일반적인 쿼리의 top-k 결과는 더 노이즈가 많아진다. 확장 후 정확도 샘플을 실행한 사람이 없다.
분기별 감사 체크리스트 5가지
1. 스코프 경계 검토
최근 30일간의 쿼리 로그를 가져온다. 각 쿼리를 인스코프, 엣지 케이스, 아웃오브스코프로 분류한다. 각 버킷의 비율을 계산한다. 이전 분기의 동일한 계산과 비교한다.
아웃오브스코프 쿼리가 5퍼센트포인트 이상 증가했다면 시스템의 스코프가 드리프트된 것이다. 정의된 스코프를 의도적으로 확장할지, 아니면 새로운 쿼리 유형에 대한 하드 거부 경로를 추가할지 결정하라.
소요 시간: 30분.
2. 검색 정확도 샘플
쿼리 20개를 선택한다 — 가장 일반적인 쿼리 클러스터에서 10개, 가장 높은 볼륨의 엣지 케이스 클러스터에서 10개. 각 쿼리를 현재 검색 시스템에 실행한다. 각 쿼리에 대해 상위 3개 검색 결과를 수동으로 검사하고 점수를 매긴다: 관련 있음, 부분적으로 관련 있음, 관련 없음.
목표: top-3 결과의 85%가 관련 있음 또는 부분적으로 관련 있음으로 점수를 받아야 한다. 해당 임계값 미만이면 다음 분기 전에 검색 세트를 정리하거나 재순위화해야 한다.
소요 시간: 30분.
3. 프롬프트 버전 비교
현재 프롬프트를 90일 전 프롬프트와 비교한다. 버전 히스토리가 없다면 그것이 첫 번째 발견 사항이다 — 다음 분기 전에 구현하라.
각 변경 사항에 대해 문서화하라: 어떤 입력이 변경을 유발했는지, 변경 내용이 무엇인지, 회귀 세트에 대해 테스트되었는지. 문서화된 트리거나 테스트 없이 이루어진 변경은 모두 리스크다.
소요 시간: 20분.
4. 승인 게이트 로그 분석
시스템에 승인 게이트 — 출력이 실행되기 전 사람이 검토하는 단계 — 가 있다면 해당 분기의 게이트 로그를 가져온다. 승인율, 거부율, 가장 흔한 거부 이유를 계산한다.
거부율 상승은 시스템 출력이 운영자가 허용 가능하다고 판단하는 것에서 벗어나고 있다는 신호다. 거부율 하락이 자동으로 좋은 것은 아니다 — 검토자들이 형식적으로 승인하고 있다는 의미일 수 있다. 두 추세 모두 조사가 필요하다.
소요 시간: 20분.
5. 기준선 대비 레이턴시 백분위수 비교
현재 분기의 p50, p90, p99 레이턴시를 가져온다. 시스템의 프로덕션 첫 달 기준선과 비교한다.
p99에서의 레이턴시 증가는 보통 시스템이 더 복잡한 쿼리를 처리하고 있거나, 인덱스 최적화 없이 검색 세트가 커졌거나, 패치 누적으로 프롬프트 길이가 증가했음을 의미한다. 각 원인마다 다른 해결책이 있다. 다음 분기 전에 어느 것이 해당하는지 파악하라.
소요 시간: 20분.
두 시간 이내에 다섯 가지 점검 모두 실행하기
툴링이 정교할 필요는 없다.
- 쿼리 로그: 기존 옵저버빌리티 스택(Datadog, Grafana, CloudWatch — 어느 것이든)에서 내보내기. 날짜 범위로 필터링. CSV로 내보내기.
- 검색 정확도: 프로덕션 엔드포인트에 쿼리를 수동으로 실행. 스프레드시트에서 결과 점수 매기기. 도메인을 알고 있다면 쿼리 20개에 약 25분 소요.
- 프롬프트 비교: 프롬프트를 버전 관리에 저장. 90일 전 태그와 HEAD 사이의
git diff로 충분하다. - 게이트 로그: 승인 워크플로를 관리하는 시스템에서 내보내기. 스프레드시트에서 비율 계산.
- 레이턴시: 기존 APM 툴에서 가져오기. p50/p90/p99는 모든 주요 옵저버빌리티 플랫폼의 표준 메트릭이다.
두 시간 목표는 로그에 접근 가능하고 감사를 실행하는 사람이 시스템을 알고 있다는 가정 하에 성립한다. 두 조건 중 하나라도 충족되지 않는다면 그것부터 먼저 해결하라.
결과로 무엇을 할 것인가
감사는 짧은 문서를 생성한다: 다섯 개 섹션, 섹션당 하나의 발견 사항, 발견 사항당 하나의 권장 조치. 그 문서는 시스템을 소유한 사람에게 전달된다. 리더십을 위한 보고서가 아니다 — 다음 스프린트를 위한 운영 입력이다.
동일한 발견 사항이 해결 없이 두 번 연속 분기별 감사에 나타난다면 더 이상 발견 사항이 아니다. 설계 결함이다. 그에 맞게 처리하라.
AI Brand Presence와 같은 시스템은 처음부터 이러한 운영 규율을 갖추고 구축된다 — 정의된 스코프 경계, 검색 정확도 기준선, 그리고 나중에 추가되는 것이 아니라 납품 프로세스에 내장된 프롬프트 버전 추적.
대부분의 팀은 눈에 띄게 망가진 것이 없다는 이유로 분기별 감사를 건너뛴다. 바로 그때가 스코프 드리프트를 발견하기 가장 어렵고 수정하기 가장 쉬운 시점이다.