LLM 행동 모니터링: 드리프트, 재시도, 거부 패턴

전통 소프트웨어는 같은 입력에 같은 출력을 내지만, LLM은 매번 다르게 반응하는 확률적 시스템이다. 따라서 엔터프라이즈 AI를 배포하려면 감으로 확인하는 'vibe check'가 아니라 AI Evaluation Stack이 필요하다.

평가의 1층은 deterministic assertions다. JSON 스키마가 맞는지, 올바른 tool call을 했는지, GUID나 이메일 같은 필드를 정확히 채웠는지 규칙과 regex로 즉시 판정해 구조적 실패를 먼저 걸러낸다.

2층은 LLM-as-a-Judge 같은 모델 기반 평가다. 이 방식은 도움됨, 공손함, 실행 가능성처럼 코드로는 판정하기 어려운 품질을 평가할 때 쓰이며, production 모델보다 더 강한 추론 모델, 명확한 루브릭, 인간 검증 golden output이 필요하다. 판정 이유까지 남겨야 실패 원인을 디버깅할 수 있다.

오프라인 파이프라인은 배포 전 실패, drift, latency를 잡는 회귀 테스트다. pull request 단계의 blocking CI/CD gate로 두고 200~500개의 golden dataset을 기준으로 돌린다.

• happy path뿐 아니라 edge case, jailbreak, adversarial input을 포함한다.
• synthetic data를 쓰더라도 human-in-the-loop 검증이 필수다.
• deterministic 6점과 model-based 4점처럼 가중치를 둘 수 있지만, 구조가 깨지면 전체 테스트를 0/10으로 즉시 실패시키는 fail-fast가 원칙이다.
• 대규모 서비스는 **95%**를 기본선으로, 규제나 고위험 영역은 **99%+**를 목표로 삼는다.

배포 후에는 온라인 파이프라인이 drift를 감시한다.

• 명시적 신호: thumbs up/down과 verbatim feedback.
• 행동 신호: retry·regeneration, apology rate, refusal rate.
• 동기 검증: 모든 트래픽에 synchronous deterministic check를 적용한다.
• 비동기 검증: LLM-Judge는 critical path에 두지 않고 일일 세션의 5% 정도를 샘플링한다.

핵심은 production에서 잡힌 실패 신호를 다시 golden dataset에 반영해 평가 루프를 계속 갱신하는 것이다.