당신의 AI 에이전트가 어젯밤 드리프트(Drift)되었지만 당신은 알아채지 못했습니다

조용한 실패 모드 (The Silent Failure Mode)

당신의 에이전트는 CI(지속적 통합)의 모든 테스트를 통과했습니다. 스테이징(Staging) 환경에서도 잘 작동했습니다. 그러다 새벽 2시, 프로덕션(Production) 환경에서 미묘하게 틀린 답변을 조용히 내놓기 시작했고, 3일 후 고객이 불만을 제기할 때까지 아무도 이를 알아채지 못했습니다.

이것이 바로 **에이전트 드리프트 (Agent Drift)**입니다. 즉, 명확한 실패(Hard failure) 없이 에이전트 출력 품질이 점진적으로 저하되는 현상을 말합니다. 예외(Exception)가 발생하지도 않고, 스키마 위반(Schema violation)도 일어나지 않습니다. 그저 모니터링을 교묘히 빠져나가는, 서서히 악화되는 응답이 있을 뿐입니다.

저의 논지는 이렇습니다: 가장 까다로운 프로덕션 실패는 크래시(Crash)가 아니라, 평가 체크포인트(Eval checkpoints) 사이에서 발생하는 품질 저하입니다. 단순히 배포 전 테스트뿐만 아니라, 지속적인 런타임 탐지(Runtime detection)가 필요합니다.

세 가지 드리프트 벡터 (Three Drift Vectors)

프로덕션 에이전트를 24시간 7일 내내 운영해 본 결과, 세 가지 뚜렷한 드리프트 패턴을 식별했습니다.

1. 컨텍스트 노후화 (Context Staleness)

에이전트는 컨텍스트(Context)로서 문서, 지식 베이스(Knowledge bases) 또는 API 응답을 검색합니다. 이 컨텍스트는 노후화됩니다:

interface StalenessDetector {
  source: string;
  maxAgeMs: number;
...

교묘한 부분은 이렇습니다: 노후화된 컨텍스트는 에러를 일으키지 않습니다. 에이전트는 오래된 정보에 기반하여 자신 있게 답변을 생성합니다. 출력물은 멀쩡해 보이지만, 단지 틀렸을 뿐입니다.

2. 행동 드리프트 (Behavioral Drift)

에이전트의 응답 패턴이 시간이 지남에 따라 변합니다. 기반 모델(Underlying model)이 조용히 업데이트되었을 수도 있습니다. 프롬프트 인젝션(Prompt injection) 시도가 미묘하게 행동을 재형성하고 있을 수도 있습니다. 누적된 대화 컨텍스트로 인해 토큰 분포(Token distributions)가 이동하고 있을 수도 있습니다.

interface DriftBaseline {
  dimension: string;
  expectedDistribution: { mean: number; stddev: number };
...

핵심 통찰: 당신은 개별 출력을 평가하는 것이 아닙니다. 시간에 따른 출력의 *분포(Distribution)*를 평가하는 것입니다. 단일 긴 응답은 아무런 의미가 없습니다. 하지만 100번의 실행에 걸쳐 평균 응답 길이가 점진적으로 증가한다면? 그것은 신호(Signal)입니다.

3. 환각 잠입 (Hallucination Creep)

환각(Hallucination) 발생률은 일정하지 않습니다. 입력의 복잡성, 컨텍스트(Context)의 품질, 그리고 모델의 상태에 따라 달라집니다. 위험한 패턴은 다음과 같습니다: 환각 발생률이 일주일 동안 2%에서 8%로 서서히 상승하며, 단 한 번의 명확한 실패(Hard failure)도 일으키지 않은 채 당신의 허용 임계값(Threshold)을 넘어가는 것입니다.

interface HallucinationCanary {
  name: string;
  detect: (output: AgentOutput, groundTruth: GroundTruth) => HallucinationSignal;
...

런타임 모니터링 루프 (The Runtime Monitoring Loop)

탐지는 절반에 불과합니다. 나머지 절반은 탐지된 결과에 대해 무엇을 하느냐입니다. 제가 정착한 런타임 루프는 다음과 같습니다:

async function monitorAgentRun(run: AgentRun): Promise<MonitorResult> {
  // 1. 실행 전(Pre-execution): 컨텍스트 신선도(Freshness) 확인
  const stalenessResults = await checkStaleness(run.context);
...

계층 구조에 주목하세요. 신선도(Staleness) 확인은 실행 전(Pre-execution) 단계입니다(에이전트가 실행되기 전에 오래된 컨텍스트를 _수정_할 수 있습니다). 드리프트(Drift) 탐지는 실행 후(Post-execution) 단계이며 비용이 저렴합니다(모든 호출 시 실행됩니다). 환각 카나리(Hallucination canaries)는 비용이 많이 들며 샘플링 방식으로 수행됩니다.

내가 처음에 저질렀던 실수들

이 시스템을 구축하며 제가 저질렀던 세 가지 실수입니다:

1. 개별 이상치(Outliers)에 대해 알림을 보낸 것. 에이전트가 단 한 번 긴 응답을 생성했다고 해서 그것이 드리프트는 아닙니다. 저는 윈도우 기반 통계적 탐지(Windowed statistical detection) 방식으로 전환하기 전까지, 거짓 양성(False positives)을 쫓느라 몇 주를 허비했습니다.

2. 베이스라인(Baselines)의 버전을 관리하지 않은 것. 에이전트의 동작을 의도적으로 변경할 때(새로운 프롬프트, 새로운 모델), 베이스라인도 재설정되어야 합니다. 그렇지 않으면 모든 의도적인 개선 사항이 드리프트 알림을 발생시킵니다.

3. 환각을 이진법(Binary)으로 취급한 것. "에이전트가 환각을 일으켰다"라는 정보는 쓸모가 없습니다. 무엇을 환각했나요? 엔티티(Entities)? 숫자? URL? 카테고리에 따라 해결 방법이 결정됩니다.

프로덕션 체크리스트 (The Production Checklist)

만약 드리프트 모니터링 없이 프로덕션 환경에서 에이전트를 운영하고 있다면, 여기서부터 시작하세요:

최소 세 가지 차원을 추적하세요: 응답 길이(response length), 지연 시간(latency), 그리고 도구 호출 횟수(tool call count)입니다. 이들은 중대한 행동 변화를 포착할 수 있는 저렴한 대리 지표(proxies)입니다.
테스트 실행이 아닌, 지난 7일간의 프로덕션 데이터로부터 베이스라인(baselines)을 설정하세요. 테스트 분포는 프로덕션 환경과 일치하지 않습니다.
개별 이상치(outliers)가 아닌, 이동 창(rolling windows) 기준 2.5 시그마(sigma) 편차에 대해 알림을 설정하세요.
실행 후가 아니라, 실행 전에 컨텍스트 신선도(context freshness)를 확인하세요. 오래된 컨텍스트(stale context)는 탐지하기보다 예방할 수 있는 유일한 드리프트(drift) 유형입니다.
100% 커버리지가 필요한 특정 고위험 출력물이 있는 경우가 아니라면, 5-10% 비율로 환각(hallucination) 체크를 샘플링하세요.

불편한 진실

대부분의 팀은 고객의 불만을 통해 드리프트(drift)를 발견합니다. 사용자가 "당신의 AI가 잘못된 정보를 주었습니다"라고 말할 때쯤이면, 당신은 이미 며칠 또는 몇 주 동안 저하된 응답을 제공하고 있었을 가능성이 높습니다.

"내 에이전트가 작동한다"와 "내 에이전트가 신뢰할 수 있게 작동한다" 사이의 간극은 전적으로 당신의 평가 체크포인트(evaluation checkpoints) 사이에서 어떤 일이 일어나는지에 달려 있습니다. 지속적인 모니터링(continuous monitoring)은 선택 사항이 아닙니다. 그것은 데모를 실행하는 것과 제품을 운영하는 것의 차이입니다.

당신은 프로덕션 에이전트에서 드리프트(drift)를 어떻게 탐지하고 있나요? 아니면 여전히 사용자로부터 소식을 듣고 있나요? 어떤 신호(signals)가 조기 탐지에 가장 유용했는지 궁금합니다.