데이터가 달라졌다고 AI 성능이 떨어진 것은 아니다

데이터 드리프트 경고는 입력 분포의 변화를 알려 주지만 성능 저하를 직접 입증하지는 않는다. Evidently의 공식 문서를 바탕으로 비교 집합, 결측값, 정답 확인의 경계를 살피고 경고 이후의 업무 판단을 설계한다.

GPT Image 2로 생성한 개념 이미지이며 실제 데이터나 실험 결과를 나타내지 않는다.

문의 분류 AI를 운영하는 가상의 팀을 생각해 보자. 새 제품을 출시한 뒤 설치 관련 문의가 늘고, 평소 적던 유입 채널의 비중도 커졌다. 모니터링 화면에 데이터 드리프트 경고가 나타난다. 담당자는 모델을 다시 학습시켜야 하는지 고민하지만, 아직 문의별 정답 분류는 모이지 않았다.

이때 확인된 것은 비교 대상으로 삼은 데이터와 최근 데이터가 달라졌다는 사실이다. 새 문의를 모델이 잘못 분류했는지는 별도로 확인해야 한다. 낯선 입력을 잘 처리할 수도 있고, 겉으로 비슷한 입력에서 업무 기준이 바뀌어 틀릴 수도 있다. 분포 변화와 성능 저하를 한 사건으로 취급하면 경고가 곧바로 재학습 지시로 바뀐다.

데이터 드리프트 검사는 운영 환경의 변화를 찾는 데 유용하다. 다만 검사 결과가 무엇을 비교한 값인지 알아야 다음 행동을 정할 수 있다. 이 글은 공개 평가 도구 Evidently의 문서를 사례로 삼는다. 아래의 문의 분류 상황과 팀 운영 절차는 필자의 제안이며, 실제 모델을 실행해 측정한 결과는 아니다.

비교 집합부터 확인한다

Evidently의 DataDriftPreset은 현재 데이터와 기준 데이터의 분포를 비교한다. 열별로 변화를 검사하고, 변화가 감지된 열의 비율을 집계한다. 정답이 없는 상황에서 입력이나 예측값의 드리프트를 살피는 용도도 있지만, 공식 문서는 이를 성능을 살피기 위한 간접 지표로 설명한다. Data Drift 공식 문서

따라서 경고를 읽기 전에 기준 집합이 어떤 운영 상황을 대표하는지 확인해야 한다. 지난달 전체 문의와 출시 직후의 주말 문의를 비교했다면 제품 변화, 요일, 유입 경로가 한꺼번에 달라졌을 수 있다. 이 비교가 틀렸다는 뜻은 아니다. 전체 서비스가 얼마나 달라졌는지 보는 질문에는 도움이 되지만, 모델의 잘못만 따로 설명해 주지는 않는다.

팀은 먼저 비교 기간, 포함한 채널, 제외한 기록, 검사한 열을 남길 수 있다. 전체 분포가 바뀌었으면 기존 채널 안에서도 변화가 생겼는지, 새 채널이 추가되어 비율만 달라졌는지 나누어 본다. 운영 환경의 변화와 수집 방식의 변화를 구별하기 위한 조사다. 상황을 잘게 나눌수록 각 묶음의 데이터가 적어진다는 점도 함께 고려해야 한다.

기준 집합을 최신 데이터로 교체하는 일에도 이유가 필요하다. 경고를 없애려고 기준을 바꾸면 무엇이 달라졌는지 추적하기 어려워진다. 정상적인 업무 변화로 받아들여 기준을 갱신했다면 이전 기준과 교체 사유를 보존한다. 경고가 사라졌다는 사실과 새 기준이 적절하다는 판단은 별도의 기록이다.

드리프트 점수는 정확도 점수가 아니다

Evidently는 열의 자료형과 관측 수 등에 따라 검사 방법을 선택한다. 통계검정의 확률값을 쓰는 경우와 분포 사이의 거리를 쓰는 경우가 있으므로, 숫자만 보고 같은 의미로 읽으면 안 된다. 비교에 사용한 열, 검사 방법, 임계값을 함께 확인해야 한다. 드리프트 검사 방법

전체 집계도 주의해서 읽어야 한다. 공식 문서의 기본 설정에서는 검사 대상 열의 50% 이상에서 드리프트가 감지되면 데이터셋 드리프트로 판정한다. 이것은 열에 대한 집계 규칙이다. 모델 정확도가 50% 떨어졌다거나, 데이터의 50%가 잘못됐다는 뜻이 아니다. 검사에 포함한 열을 바꾸면 이 집계의 분모도 달라진다. Data Drift의 전체 집계 규칙

결측값은 또 다른 경계다. 이 도구의 드리프트 검사는 null 값을 제외한 분포를 비교한다. 그래서 문의 채널 정보가 누락되는 비율이 늘어도, 남은 값의 분포만 비슷하면 그 문제를 같은 검사로 포착하지 못할 수 있다. 공식 문서도 결측값을 확인하는 데이터 품질 검사를 별도로 추가하도록 안내한다. 분포 검사를 통과했다는 기록으로 수집 데이터 전체가 정상이라고 판단해서는 안 된다. 결측값 처리와 데이터 품질 검사

이 표는 운영에서 확인할 질문을 정리한 것이다. 모든 도구가 같은 방식으로 결측값을 처리하거나 같은 기본 임계값을 사용한다는 뜻은 아니다. 도구를 바꾸거나 검사 설정을 갱신했다면 이전 경고와 직접 비교할 수 있는지도 살펴야 한다.

입력이 비슷해도 정답의 기준은 바뀔 수 있다

입력 분포가 크게 달라지지 않았다고 성능이 유지된다고 단정할 수도 없다. Evidently의 개념 드리프트 설명은 입력과 목표값 사이의 관계가 바뀌는 경우를 구분한다. 입력 자체의 분포 변화만 감시하면 이 관계의 변화를 놓칠 수 있다. Concept drift 설명

가상의 문의 분류 팀에서 업무 규정이 바뀌었다고 하자. 전에는 일반 문의로 보내던 요청을 이제는 전문 담당자에게 넘겨야 한다. 문의 문장과 유입 채널의 분포가 비슷해도, 같은 입력에 요구되는 올바른 분류는 달라졌다. 과거 규칙을 잘 재현하는 모델이 현재 업무에서는 틀릴 수 있다. 이 사례는 입력과 정답 관계의 변화를 설명하기 위한 예시다.

따라서 성능을 확인할 때는 정답이 언제, 어떤 기준으로 붙었는지도 확인해야 한다. 오래된 기준의 레이블을 새 기준의 출력과 비교하면 무엇이 틀렸는지 해석하기 어려워진다. 반대로 일부 처리 완료 건에만 정답이 붙었다면 그 결과가 아직 처리되지 않은 문의까지 대표한다고 볼 수는 없다.

정답 확인이 늦는 업무에서는 상태를 구분해 남길 수 있다. 입력 변화는 확인됐지만 성능 영향은 미확인인지, 일부 구간의 오류가 확인됐는지, 업무 기준 자체가 바뀌었는지를 적는다. 확인하지 못한 부분을 정상으로 채우지 않아야 다음 담당자가 필요한 검토를 이어갈 수 있다.

경고 이후의 행동을 증거에 맞춘다

드리프트 경고가 뜨면 먼저 데이터가 의도한 대로 수집됐는지 확인하는 절차를 제안한다. 필드 이름이 바뀌었거나 변환 과정에서 값이 누락됐다면, 잘못 들어온 데이터로 모델을 재학습하는 것은 해결이 되기 어렵다. 수집 문제를 고친 뒤 같은 비교를 다시 수행해야 환경 변화와 처리 오류를 구분할 수 있다.

수집에 문제가 없다면 달라진 구간을 골라 실제 결과와 정답을 살핀다. 이때 경고가 큰 열과 오류가 많은 사례가 일치하는지도 확인한다. 성능 저하가 확인되면 수정 대상이 모델인지, 업무 규칙인지, 사람이 검토하는 범위인지 정한다. 모델을 바꾸기로 했더라도 변경 후의 결과를 다시 평가해야 한다.

이 평가를 위한 대표 사례와 실패 기준의 구성은 작은 평가 사례집을 만드는 방법에 정리했다. 변경 전후 실행의 조건을 맞추는 문제는 같은 시드로도 AI 결과가 달라지는 이유와 연결된다. 이번 단계에서는 그 절차를 새로 만들기보다, 운영 중 발견한 변화가 기존 사례집과 비교 기록에 빠져 있는지 확인하면 된다.

팀이 경고에 붙일 기록은 짧아도 된다. 무엇과 무엇을 비교했는지, 실제로 달라진 것은 무엇인지, 성능에 관해 확인한 것과 남은 질문은 무엇인지, 누가 어떤 근거로 다음 조치를 정했는지를 남긴다. 재학습을 하지 않았어도 그 판단을 검토할 수 있고, 나중에 오류가 확인되면 어느 가정부터 다시 볼지 알 수 있다.

드리프트 경고는 조사를 시작할 이유를 제공한다. 그 뒤에는 실제 업무 결과를 확인하는 과정이 필요하다. 경고의 개수보다, 경고가 어떤 검토와 수정으로 이어졌는지를 남기는 쪽이 운영 판단에 도움이 된다.

---

공식 문서와 공개 저장소는 2026년 11월 6일에 확인했다. 검사 동작은 당시 공개 문서에 근거하며, 설치된 패키지를 실행해 검증한 결과는 아니다. 공개 프로젝트의 구성은 확인 당시 기본 브랜치의 고정 커밋 README로 대조했다. 본문의 가상 사례와 운영 절차는 필자의 제안이다.