안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
원본 데이터와 모델 버전은 그대로인데 AI 결과가 달라지는 경우가 있습니다. 모델팀은 배포된 모델에 변화가 없다고 하고, 데이터팀도 원본 테이블과 문서에는 이상이 없다고 합니다. 두 설명이 모두 맞다면 원본과 모델 사이의 과정을 살펴봐야 하는데요.
원본 데이터는 모델에 전달되기 전에 결측값 처리, 스케일링, 범주 인코딩, 토큰화 같은 전처리를 거칩니다. 이때 적용되는 규칙이나 도구가 바뀌면 같은 원본도 모델에는 다른 숫자와 토큰으로 전달됩니다.
이처럼 원본은 같아도 전처리 과정이 바뀌면서 모델이 실제로 받는 데이터가 달라지는 현상을 전처리 드리프트(Preprocessing Drift)라고 하는데요. 원본 데이터와 모델이 그대로인데 AI 결과가 달라졌다면, 모델을 재학습하기 전에 전처리 버전과 변환 결과부터 비교해야 합니다.
전처리 변경은 데이터 파이프라인 안에서 이뤄지지만 문제는 모델 결과에서 드러납니다. ML 데이터 파이프라인을 관리하는 팀과 AI 운영, 데이터 품질, 모델 리스크 담당자가 같은 실행 ID를 기준으로 전처리 코드와 설정, 적용 순서, 변환 전후의 분포를 함께 살펴봐야 하는 이유입니다. 변경 전 상태를 다시 구성하는 절차까지 마련해 두면 모델을 손봐야 하는지, 전처리를 되돌려야 하는지 더 빠르게 판단할 수 있습니다.
- 원본 고정같은 데이터
- 전처리 변경규칙·설정 변화
- 같은 모델버전 유지
- 결과 변화입력·결과가 달라짐
같은 원본도 전처리에 따라 다른 입력이 됩니다
모델은 원본 테이블과 문서를 그대로 읽기보다, 결측값 처리와 스케일링, 인코딩, 문서 분할을 거쳐 만들어진 피처와 벡터, 토큰을 입력으로 사용하는데요. 이 과정에 적용되는 규칙이나 도구가 달라지면 원본이 같아도 모델에 전달되는 값은 달라집니다.
겉으로는 코드 한 줄을 수정하거나 라이브러리를 업데이트한 정도로 보일 수 있습니다. 하지만 바뀐 변환 규칙은 모든 입력에 반복 적용되므로 데이터 분포와 값의 의미까지 달라질 수 있는데요. 변경 범위만 보고 AI 결과에 미치는 영향도 작다고 판단해서는 안 됩니다.
데이터 드리프트와 전처리 드리프트의 차이
두 현상은 모두 AI 결과의 변화로 드러나지만, 원인이 발생한 지점은 다릅니다. 데이터 드리프트(Data Drift)는 모델로 들어오는 원본 데이터의 구성이나 분포가 달라진 경우입니다. 반면 전처리 드리프트는 원본은 그대로인데, 이를 모델 입력값으로 바꾸는 규칙이나 도구가 달라진 경우를 말합니다.
원인이 생긴 지점이 다른 만큼 대응 방법도 달라집니다. 데이터 드리프트라면 달라진 데이터에서도 기존 모델이 적합한지 살펴본 뒤 재학습 여부를 결정해야 하고, 전처리 드리프트가 원인이라면 이전 전처리 상태를 복원해 변환 결과부터 비교해야 합니다.
두 현상을 구분하지 않고 모델부터 손보면 전처리 과정에서 달라진 입력이 계속 전달될 수 있습니다. AI 결과가 달라졌을 때 원본 데이터와 전처리 결과를 따로 비교해야 하는 이유인데요. 변화가 시작된 지점을 알아야 데이터와 모델 중 무엇을 먼저 조정할지도 판단할 수 있습니다..
데이터 드리프트
원본 데이터가 달라집니다
- 원본 변화분포·구성 변화
- 같은 전처리규칙 유지
- 입력 변화모델에 다른 값 전달
전처리 드리프트
변환 과정이 달라집니다
- 같은 원본데이터 유지
- 전처리 변화규칙·설정 변경
- 입력 변화모델에 다른 값 전달
전처리 과정에서 모델 입력이 달라지는 네 가지 경우
1. 결측값 처리
금융 데이터의 빈칸이 ‘미확인’, ‘해당 없음’, ‘수집 실패’처럼 서로 다른 업무 상태를 나타낼 수 있습니다. 기존 파이프라인은 빈칸이 생긴 이유를 구분해 두었지만, 새 파이프라인이 모든 빈칸을 평균값으로 채웠다고 가정해 보겠습니다. 작업은 오류 없이 끝나도 모델은 서로 다른 상태를 하나의 값으로 읽게 됩니다.
2. 스케일러와 정규화
지난 분기의 최소·최대값으로 맞춘 스케일러를 최신 데이터에 맞춰 다시 설정하면 같은 거래 금액이 이전과 다른 숫자로 변환됩니다. 모델이 학습한 입력 범위와 실제 업무에서 들어오는 입력 범위가 어긋날 수 있으므로, 스케일러의 버전뿐 아니라 어떤 데이터에 맞춰졌는지도 함께 남겨야 합니다.
3. 범주 인코딩
제품 범주가 새로 추가되면서 인코딩 순서가 바뀌면 기존 숫자의 의미도 달라질 수 있습니다. 학습 당시에는 2=기업고객이었지만 실제 실행에서는 2=공공기관으로 처리되는 식입니다. 범주 이름만 볼 것이 아니라 숫자와 범주를 연결한 매핑 테이블의 버전까지 비교해야 합니다.
4. 텍스트·문서 전처리
토크나이저와 OCR 버전, 문서 청크와 임베딩 방식이 달라지면 RAG의 검색 결과도 바뀝니다. 예를 들어 공공기관의 규정 문서를 더 작은 단위로 나누는 과정에서 적용 대상과 예외 조항이 서로 다른 청크로 분리되면, 문서 원본과 LLM이 그대로여도 모델이 읽는 문맥은 달라질 수 있습니다.
전처리 문제를 놓치기 쉬운 이유
모델 레지스트리에 변경 기록이 없고 원본 테이블의 스키마와 값도 이전과 같다면, 모니터링 화면에서 확인되는 것은 달라진 결과 지표뿐입니다. 이런 상황에서는 결과가 달라진 원인을 모델에서 먼저 찾게 되는데요.
모델을 재학습하거나 이전 버전으로 되돌려도 같은 전처리 파이프라인을 계속 사용하면 달라진 입력이 그대로 전달됩니다. 모델을 바꿔도 원인이 남아 있어 같은 문제가 반복될 수 있는 것이죠.
Google Research의 머신러닝 기술 부채 연구는 데이터 의존성과 외부 시스템의 변화가 ML 시스템의 유지보수 부담을 키운다고 설명합니다. 전처리를 모델 배포와 별개의 작업으로 관리하면 모델과 코드 밖에서 달라진 입력 조건을 놓치기 쉽습니다.
원인을 찾으려면 다음 세 가지를 나누어 비교해야 합니다.
- 원본 데이터의 상태
- 전처리 규칙과 스케일러·인코더 등 변환 도구의 상태
- 모델에 최종적으로 전달된 입력값
원본 데이터가 같다고 해서 모델에 전달된 입력까지 같은 것은 아닙니다. 전처리 과정에 사용된 규칙과 도구를 비교해야 입력이 어느 단계에서 달라졌는지 알 수 있습니다.
릴리즈 상태에 전처리 정보가 필요한 이유
릴리즈 상태(Release State)는 AI 실행에 사용된 데이터뿐 아니라, 데이터를 모델 입력으로 바꾼 전처리 규칙과 설정까지 하나의 상태로 관리합니다. 원본 데이터만 남아 있으면 당시 어떤 결측값 처리와 스케일링, 인코딩이 적용됐는지 알기 어렵기 때문입니다.
각 AI 실행은 런 바인딩(Run Binding)을 통해 당시 사용한 릴리즈 상태와 연결됩니다. 이 연결이 있어야 특정 결과에 어떤 전처리 버전과 설정이 적용됐는지 실행 단위로 추적할 수 있습니다.
- 어떤 결측값 처리 규칙이 적용됐나요?
- 스케일러는 어느 데이터에 맞춰 설정됐나요?
- 범주 매핑과 토크나이저는 어떤 버전이었나요?
- RAG 문서는 어떤 기준으로 나누고 검색했나요?
- 결과가 예상대로 나온 실행과 달라진 실행의 변환 결과는 어떻게 달랐나요?
결과가 달라졌을 때 두 실행에 연결된 릴리즈 상태를 Diff하면 결측값 처리와 스케일러, 범주 매핑, 문서 처리 방식의 차이를 비교할 수 있습니다. 필요하면 변경 전 상태를 Reproduce해 같은 원본이 당시와 같은 모델 입력으로 변환되는지도 살펴봅니다. 전처리 변경이 결과에 미친 영향을 실행 기록을 근거로 검증하는 과정입니다.
전처리 변경 전후의 AI 결과를 확인하는 5단계
1. AI가 사용하는 전처리 항목을 파악합니다
코드뿐 아니라 스케일러와 인코더, 토크나이저, 코드표, 문서 청크 기준, 피처 정의처럼 모델 입력을 만드는 항목을 함께 정리합니다. 각 항목을 사용하는 모델과 에이전트도 연결해 둡니다.
2. 변경 전후의 원본과 변환 결과를 함께 기록합니다
같은 원본 데이터가 변경 전후에 어떤 모델 입력으로 바뀌는지 비교합니다. 원본은 같아도 변환된 값이나 토큰, 검색 문맥이 달라졌다면 그 차이를 기록해야 합니다.
3. 라이브러리와 전처리 설정의 변경 이력을 남깁니다
라이브러리를 업데이트하거나 스케일러·인코더를 최신 데이터에 맞춰 다시 설정하는 작업도 모델 결과에 영향을 줄 수 있습니다. 적용 시점과 대상, 이전 상태로 되돌리는 조건을 함께 남깁니다.
4. 실제 모델과 업무 지표로 영향을 검증합니다
전처리 작업이 오류 없이 끝났다고 해서 모델 결과까지 이전과 같다는 뜻은 아닙니다. 변경 전후의 입력을 같은 모델에 각각 적용해 주요 지표와 예외 사례가 어떻게 달라졌는지 비교합니다.
5. 검증한 전처리 상태를 실제 실행과 연결합니다
검증을 마친 전처리 상태는 릴리즈 상태에 포함하고, 각 AI 실행이 사용한 전처리 버전과 변환 도구를 런 바인딩으로 연결합니다. 이후 결과가 달라졌을 때 변경 전후를 비교하는 기준이 됩니다.
한국지능정보사회진흥원의 인공지능 학습용 데이터 품질관리 가이드라인은 품질관리 체계와 절차, 산출물, 자가점검 및 품질검증 방법을 함께 제시합니다. 운영 환경에서 전처리 변경이 AI 결과에 미친 영향까지 추적하려면 이러한 품질관리 기록을 실제 모델 입력과 AI 실행 기록에 연결해야 합니다. 그래야 어떤 변화가 어느 결과에 영향을 미쳤는지 다시 확인할 수 있습니다.
전처리 변경이 AI 실행과 연결돼 있는지 확인하는 방법
다음 질문으로 전처리 변경 내역과 실제 AI 실행이 함께 기록되고 있는지 점검해 보세요.
- 전처리 코드와 스케일러·인코더 등 변환 도구를 모델과 함께 버전별로 관리하고 있나요?
- 스케일러와 인코더를 어떤 데이터에 맞춰 다시 설정했는지 알 수 있나요?
- 라이브러리와 토크나이저가 업데이트된 시점과 해당 버전을 사용한 실행이 기록돼 있나요?
- Reproduce 기능으로 과거 결과에 사용된 전처리 상태와 모델 입력을 다시 구성할 수 있나요?
- 결과가 달라졌을 때 모델과 원본 데이터, 전처리 가운데 무엇이 바뀌었는지 구분할 수 있나요?
두 가지 이상의 질문에 답하기 어렵다면 전처리 변경 내역은 남아 있어도 실제 AI 실행에 어떤 상태가 사용됐는지는 추적하기 어려운 상황입니다.
전처리 변경을 여러 조직이 함께 검토할 때
전처리 작업이 오류 없이 끝났다고 해서 AI 결과까지 이전과 같다고 볼 수는 없는데요. 데이터 플랫폼팀과 AI·데이터팀, 거버넌스·보안, 운영·감사·검수, 상위 시스템·인프라 담당자가 같은 실행 ID와 변경 기록을 바탕으로 언제 무엇이 바뀌었고 어떤 결과가 달라졌는지 함께 살펴봐야 합니다.
- 데이터 플랫폼: 변경된 코드와 설정, 스케일러·인코더 등 변환 도구, 적용 시점과 이전 상태로 되돌리는 조건을 기록합니다.
- AI·데이터팀: 변경된 전처리를 사용하는 모델과 에이전트를 찾고, 변경 전후의 입력 분포와 주요 업무 지표를 비교합니다.
- 거버넌스·보안: 데이터의 사용 목적과 출처, 코드표·참조 정보, 접근 권한, 변경 승인 범위를 확인합니다.
- 운영·감사·검수: 결과가 예상대로 나온 실행과 달라진 실행에 연결된 전처리 상태를 비교하고, 필요할 때 변경 전 상태를 다시 구성할 수 있는지 살펴봅니다.
- 상위 시스템·인프라: 상위 시스템의 변경이 전처리 파이프라인에 반영되는 순서와 처리 위치, 기록 보존 범위, 복구 절차를 배포·검수 문서에 명시합니다.
이 기록만으로 정책 승인이나 규제 준수 여부를 판단할 수는 없습니다. 다만 여러 조직이 같은 전처리 변경과 실행 기록을 바탕으로 AI 결과가 달라진 원인을 함께 파악할 수 있습니다.
Syntitan으로 전처리 변경 전후의 입력을 비교하는 방법
Syntitan은 기업 데이터의 AI-Readiness를 여섯 축으로 진단하고, 부족한 부분을 개선한 뒤 실제 모델과 업무 지표를 기준으로 데이터의 활용 가능성을 검증하는 AI-Ready Data Platform입니다.
검증을 마친 데이터와 전처리 조건은 하나의 릴리즈 상태로 관리하고, 각 AI 또는 에이전트 실행을 당시 사용한 릴리즈 상태와 연결합니다. 결과가 달라졌다면 두 실행의 릴리즈 상태를 Diff해 결측값 처리와 스케일러, 범주 인코딩, 문서 처리 방식이 어떻게 달라졌는지 비교할 수 있습니다.
필요하면 Reproduce 기능을 사용해 변경 전의 데이터 상태와 전처리 조건을 다시 구성하고, 당시 결과가 다시 나타나는지도 확인합니다. 전처리 드리프트의 원인을 찾으려면 원본 데이터와 모델 버전뿐 아니라 각 실행에 사용된 전처리 규칙과 변환 결과까지 함께 비교해야 합니다.
