당신의 AI 관측성 스택(AI Observability Stack)에서 가장 중요한 지표를 놓치고 있는 이유

저는 지난주에 왜 우리의 AI 기반 고객 지원 봇이 점점 더 이상한 답변을 내놓는지 디버깅하며 시간을 보냈습니다. 모델은 바뀌지 않았습니다. 프롬프트(Prompts)도 동일했습니다. 인프라(Infrastructure)도 안정적이었습니다.

그렇다면 무엇이 달랐을까요?

로그를 확인했습니다. 임베딩(Embeddings)을 확인했습니다. 심지어 평가 스위트(Evaluation suite)를 다시 실행해 보았지만 — 모든 것이 통과되었습니다. 하지만 실제 사용자들은 환각(Hallucinated) 현상이 나타나는 제품 추천에 대해 불만을 제기하고 있었습니다.

돌파구는 제가 모델을 보는 것을 멈추고, 아무도 측정하지 않는 무언가를 보기 시작했을 때 찾아왔습니다: 바로 컨텍스트 드리프트 (Context drift) 입니다.

아무도 추적하지 않는 지표

제가 사용해 본 모든 AI 관측성(AI observability) 도구들은 동일한 세 가지 요소에 집중합니다:

1. 지연 시간 (Latency) (p50, p95, p99)
2. 토큰 사용량 및 비용 (Token usage and cost)
3. 에러율 및 타임아웃 (Error rates and timeouts)

이것들은 모두 인프라 지표입니다. 이 지표들은 시스템이 _작동하고 있는지_를 알려줄 뿐, _좋은 출력(Good outputs)_을 생성하고 있는지는 알려주지 않습니다.

우리 봇은 에러 없이 800ms 내에 응답하고 200개의 토큰을 사용하고 있었습니다. 중요한 모든 지표 측면에서 볼 때, 봇은 완벽하게 작동하고 있었습니다.

하지만 봇은 서서히 쓸모없어지고 있었습니다.

내가 발견한 것

저는 간단한 것을 추적하기 시작했습니다: 현재 프롬프트와 학습 코퍼스(Training corpus) 사이의 의미론적 유사성(Semantic similarity)입니다. 3주 동안 평균 유사도는 0.87에서 0.62로 떨어졌습니다.

사용자들은 우리가 출시한 제품, 우리가 추가한 기능, 그리고 우리가 전혀 예상하지 못했던 예외 사례(Edge cases)에 대해 질문하고 있었습니다. 모델은 최선을 다하고 있었지만, 그 최선은 다른 세상을 기준으로 조정(Calibrated)되어 있었습니다.

관측성 스택(Observability stack)은 아무런 이상 징후를 발견하지 못했습니다. 왜냐하면 아무것도 고장 나지 않았기 때문입니다. 시스템은 설계된 대로 정확하게 작동하고 있었습니다. 단지 움직이는 목표를 향해 설계되었을 뿐입니다.

내가 구축한 패턴

저는 세 가지 새로운 신호를 추적하는 간단한 모니터링 레이어를 만들었습니다:

시간에 따른 출력 분산 (Output variance over time). 단일 요청 내의 분산이 아니라, 날짜에 따른 분산입니다. 만약 모델의 출력 분포가 크게 변한다면 (임베딩 거리(Embedding distance)로 측정), 그것이 바로 조기 경보입니다.

프롬프트 임베딩 드리프트 (Prompt-embedding drift). 모든 입력 프롬프트는 임베딩 (embedding)되어 과거 프롬프트의 이동 평균 윈도우 (rolling window)와 비교됩니다. 평균 거리가 임계값 (threshold)을 넘어서면, 사용자 기반이 변화하고 있음을 알 수 있습니다.

피드백 신호 지연 (Feedback signal lag). 대부분의 시스템은 사용자 피드백 (좋아요/싫어요, 수정 사항 등)을 수집합니다. 하지만 해당 피드백은 문제가 발생한 출력 이후 몇 시간 또는 며칠이 지나서 도착합니다. 저는 피드백 신호와 프롬프트 드리프트 (prompt-drift) 지표를 상관 분석하는 파이프라인을 구축했는데, 그 결과 드리프트가 평균 4일 먼저 발생한 후 나쁜 피드백이 뒤따라온다는 사실을 발견했습니다.

이것이 귀하의 스택에 의미하는 바

만약 귀하가 2026년에 AI 애플리케이션을 구축하고 있다면, 관측성 (observability) 스택에 다음 사항들을 추가할 것을 권장합니다:

• 임베딩 기반 출력 모니터링 (Embedding-based output monitoring): 매일 출력의 1%를 샘플링하여 임베딩하고, 분포 변화 (distribution shifts)를 추적하세요. 시간에 따른 단순한 PCA 투영 (PCA projection)을 통해 모델의 "성격"이 언제 드리프트되고 있는지 확인할 수 있습니다.
• 프롬프트 유사도 윈도우 (Prompt similarity windows): 최근 10,000개의 프롬프트를 유지하는 이동 버퍼 (rolling buffer)를 관리하세요. 새로운 프롬프트를 이 버퍼와 비교하고, 유사도가 임계값 미만으로 떨어지면 경고를 보냅니다.
• 상관관계 대시보드 (Correlation dashboards): 드리프트 지표를 비즈니스 지표 (전환율, 유지율, CSAT)와 함께 도식화하세요. 모델 품질 저하가 에러율 (error rates)에 나타나기 _전_에 비즈니스 수치에서 먼저 나타나는 경우가 많다는 것을 발견하게 될 것입니다.
• 자동 재보정 트리거 (Automated re-calibration triggers): 드리프트가 임계값을 초과하면, 자동으로 프롬프트 재평가를 실행하고 필요 시 파인튜닝 (fine-tuning) 사이클을 트리거하세요.

불편한 진실

대부분의 AI 관측성 도구들은 잘못된 문제를 해결하고 있습니다. 그 도구들은 모델이 충돌 (crash)할 때를 감지하는 데 도움을 줄 뿐, 모델이 점진적으로 나빠질 때를 감지하지는 못합니다.

점진적인 성능 저하 (incremental degradation)는 경고를 발생시키지 않기 때문에 감지하기가 더 어렵습니다. 에러로 나타나지도 않습니다. 이는 올바른 지표를 측정할 때만 드러나는 서서히 진행되는 출혈과 같습니다.

저는 여전히 이 접근 방식을 반복 개선하고 있습니다. 다음 단계는 드리프트 패턴을 감지하고 어떤 프롬프트를 업데이트해야 하는지 제안하는 자동화 시스템을 구축하는 것입니다.

다른 사람들은 추적하지 않지만 당신은 추적하고 있는 지표는 무엇인가요? 여러분이 발견한 것들에 대해 듣고 싶습니다.