안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
AI를 실제 업무에 적용하다 보면, 어제까지 같은 유형의 요청을 문제없이 분류하던 모델이 오늘은 일부 요청을 놓치는 일이 생깁니다. 코드와 모델 버전, 프롬프트를 비교해도 달라진 점을 찾지 못할 때가 있습니다.
이럴 때 막연히 데이터가 달라졌다고 추정하는 것만으로는 원인을 좁히기 어렵습니다. 결과가 달라지기 전과 후를 비교해 어떤 필드가 바뀌었는지, 값의 분포는 얼마나 달라졌는지, 범주 매핑이나 결측값 처리 기준이 변경됐는지 살펴봐야 합니다.
이때 데이터 상태 Diff를 사용합니다. 데이터 상태 Diff는 모델이 정상적으로 작동했을 때와 결과가 달라졌을 때의 데이터 상태를 필드·구조·분포·변환 단위로 비교해, 결과에 영향을 줄 수 있는 변경점을 보여줍니다.
AI 결과에 문제가 생기면 담당자는 두 시점의 데이터 상태를 비교해 변화가 시작된 지점을 찾습니다. AI를 운영 환경에 적용하려면 데이터 엔지니어링·거버넌스·감사 담당자도 같은 기록을 바탕으로 변경 내용을 검토할 수 있어야 합니다.
이를 위해 비교 대상이 되는 릴리즈 상태(Release State)를 비롯해 스키마와 분포, 전처리·변환 과정의 변경 사항, 변경 승인과 영향 검토 기록을 함께 남겨야 합니다. 기술팀의 원인 분석에 그치지 않고 데이터 사용 기준부터 실제 AI 실행, 검수 결과까지 하나의 흐름으로 이어져야 합니다.
데이터 상태 Diff가 비교하는 것
코드 Diff는 소스 코드에서 변경된 부분을 비교하는데요. 데이터 상태 Diff는 두 AI 실행에 사용된 데이터 범위와 스키마, 값의 분포, 전처리 조건이 어떻게 달라졌는지 비교합니다.
Diff는 바뀐 셀을 모두 나열하는 데 목적이 있지 않습니다. 모델과 에이전트의 판단에 영향을 줄 수 있는 변화를 먼저 찾아야 합니다.
코드와 모델만 비교해서는 놓치는 데이터 변화
코드, 모델, 데이터 상태는 서로 다른 변화를 보여줍니다. 코드와 모델이 그대로여도 입력 데이터와 처리 조건이 달라지면 결과가 달라질 수 있습니다
모델 버전만으로 결과 차이를 설명하기 어려운 이유에서도 설명했듯이, 모델 밖의 입력 조건도 결과에 영향을 줄 수 있습니다. 코드와 모델에 변화가 없다면 결과가 달라지기 전후의 두 실행에 연결된 데이터 상태를 비교해 어떤 조건이 달라졌는지 살펴보는 편이 좋습니다.
고객 상태 필드가 바뀌면 모델 입력도 달라집니다
고객 이탈 예측 모델이 특정 위험 고객을 갑자기 놓치기 시작했다고 가정해 보겠습니다.
상위 CRM이 기존 customer_status 필드를 account_status와 service_status로 나눴습니다. 호환성을 위해 기존 컬럼은 남겼지만, 모든 행에 동일한 기본값이 입력됐습니다.
파이프라인은 정상적으로 실행됐고 기존 컬럼도 존재합니다. 모델 버전 역시 이전과 같습니다. 하지만 모델이 주요 신호로 사용하던 필드가 거의 하나의 값만 갖게 되면서 입력 데이터의 분포가 달라졌습니다.
비교 방식에 따라 드러나는 내용도 달라집니다.
- 코드 Diff: 변경 없음
- 모델 비교: 변경 없음
- 스키마 검사: 기존 컬럼이 있으므로 통과할 수 있음
- 데이터 상태 Diff: 신규 필드 두 개 추가, 기존 필드의 범주 분포 붕괴, 데이터 출처와 전처리·변환 이력 변경 확인
데이터 상태 Diff는 단순히 “드리프트가 발생했다”고 알리는 데 그치지 않습니다. customer_status가 분리되면서 기존 입력 신호가 사라졌다는 원인까지 보여주므로, 어떤 필드와 변환 과정을 먼저 살펴봐야 하는지 바로 판단할 수 있습니다.
데이터 상태 Diff의 비교 기준
‘지난주쯤의 데이터’처럼 시점만 어림잡은 자료를 비교하면 결과가 달라진 원인을 구체적으로 설명하기 어렵습니다. 두 AI 실행이 실제로 사용한 데이터 상태를 정확히 식별해야 비교 기준이 분명해집니다.
릴리즈 상태는 실행 당시의 데이터 범위와 스키마, 전처리 조건, 참조 정보를 하나의 상태로 고정합니다. 런 바인딩(Run Binding)은 각 AI 실행을 사용한 릴리즈 상태와 연결합니다.
두 기록이 연결되어 있으면 다음과 같이 비교할 수 있습니다.
- 예상한 결과를 낸 실행과 이전과 다른 결과가 나온 실행의 실행 ID(Run ID)를 찾습니다.
- 두 실행에 연결된 릴리즈 상태를 확인합니다.
- 데이터 출처와 전처리·변환 이력을 기준으로 같은 필드를 비교합니다.
- 스키마, 분포, 데이터 범위, 전처리 조건, 참조 정보에서 달라진 부분을 살펴봅니다.
- 결과에 미친 영향과 범위를 고려해 영향이 큰 변경부터 검토합니다.
- 데이터 출처와 전처리·변환 이력을 따라 변경이 발생한 지점을 추적합니다.
단순히 스냅샷 두 개를 수동으로 비교하는 것과 달리, 데이터 상태 Diff는 실제 AI 실행과 연결된 두 상태를 비교하는데요. 따라서 결과가 달라진 시점과 원인을 더 구체적으로 좁혀 볼 수 있습니다.
모든 데이터 변화가 같은 의미를 갖지는 않습니다
운영 데이터는 매일 바뀝니다. 신규 행이 추가되고 가격이나 규정이 갱신되는 일도 빈번하게 발생하는데요. 모든 변화를 같은 수준의 경고로 처리하면 실무자가 중요한 신호를 놓칠 수 있습니다.
데이터 상태 Diff는 변경량만 나열하지 않고, 다음 기준에 따라 영향도를 구분해야 합니다.
영향 범위
변경이 비핵심 필드 한 곳에 머무는지, 모델 입력 대부분에 영향을 주는지 살펴봅니다.
모델 의존도
모델이 거의 사용하지 않는 필드인지, 결과에 직접 영향을 주는 핵심 변수인지 비교합니다.
의미 변화
값이 비슷해 보여도 코드 정의, 단위, 범주가 바뀌었다면 데이터의 의미가 달라졌는지 검토합니다.
변경 출처와 이전 상태 복원
어느 데이터 출처와 처리 단계에서 변경이 발생했는지, 필요할 때 이전 상태를 다시 구성할 수 있는지 살펴봅니다.
따라서 Diff 결과는 변경량을 나열하는 보고서에 그치지 않고, 어떤 항목부터 조사할지 정하는 기준이 되어야 합니다.
공공기관 RAG에서 비교해야 할 데이터 변화
공공기관의 규정 검색 AI에서는 테이블보다 문서 상태의 변화가 중요할 수 있습니다.
- 새 지침이 추가됐나요?
- 폐지된 문서가 검색 대상에 남아 있나요?
- 문서의 시행일이나 적용 대상 메타데이터가 달라졌나요?
- 청크 크기와 분할 기준이 바뀌었나요?
- 임베딩이나 검색 필터가 수정됐나요?
- 사용자별로 접근할 수 있는 문서 범위가 달라졌나요?
답변이 달라졌을 때 모델만 비교하면 이 변화를 놓치게 됩니다. 두 실행이 참조한 문서 집합과 검색 조건을 데이터 상태 Diff로 비교해야 합니다.
산업별 데이터 상태 Diff 활용 예시
산업마다 데이터와 업무 지표는 다르지만, 결과 변화의 원인을 찾을 때 비교할 대상은 비슷합니다. 결과가 달라지기 전후의 두 실행을 연결하고, 입력 데이터와 처리 조건이 어떻게 달라졌는지 비교합니다.
데이터 상태 Diff를 살펴보는 다섯 가지 질문
- 두 실행이 각각 어떤 릴리즈 상태와 연결돼 있나요?
- 새로 추가되거나 사라진 필드와 문서는 무엇인가요?
- 핵심 변수의 분포와 범주 비율은 얼마나 달라졌나요?
- 전처리와 참조 정보가 바뀌면서 모델 입력에는 어떤 변화가 생겼나요?
- 영향이 큰 변경은 어떤 원천 데이터와 전처리·변환 과정에서 시작됐나요?
이 질문에 답할 수 있어야 데이터 상태 Diff를 단순한 변화 목록이 아니라 원인을 추적하는 기준으로 활용할 수 있습니다.
운영 단계에서 여러 조직이 함께 확인할 사항
PoC에서 기대한 결과를 얻었다고 곧바로 운영 환경에 적용할 수 있는 것은 아닙니다. 운영 단계에서는 기술팀뿐 아니라 데이터 거버넌스, 보안, 인프라, 감사, 사업관리 담당자도 같은 실행 ID와 관련 기록을 바탕으로 결과가 만들어진 조건을 살펴볼 수 있어야 합니다.
- AI·데이터팀: 실제 사용 사례와 목표 지표를 기준으로 데이터가 해당 AI 업무에 적합한지 검증하고, 결과가 달라진 원인을 분석합니다.
- 데이터 거버넌스·보안: 데이터의 사용 목적과 출처, 버전, 가공 과정, 접근 주체, 허용 범위를 점검합니다.
- 운영·감사·검수: 결과가 달라지기 전후의 두 실행에 연결된 릴리즈 상태를 비교합니다. 스키마와 분포, 전처리·변환 과정에서 생긴 차이와 변경 승인 기록을 바탕으로 당시 조건을 되짚습니다.
- 인프라·조달: 기존 데이터 플랫폼 및 MLOps와의 연계 방식, 내부망·온프레미스·클라우드에서의 처리 위치, 기록 보존 범위와 담당 조직을 배포·검수 문서에 명시합니다.
여러 조직이 같은 실행 ID와 관련 기록을 살펴볼 수 있어야 결과가 달라진 원인을 함께 검토할 수 있습니다. 다만 이러한 기록은 원인 조사를 돕는 자료이며, 정책 승인이나 컴플라이언스 판단을 대신하지는 않습니다.
Syntitan으로 실행 전후의 데이터 변화를 비교하는 방법
Syntitan은 기업 데이터의 AI-Readiness를 여섯 축으로 진단하고, 부족한 부분을 개선한 뒤 실제 모델과 업무 지표를 기준으로 데이터의 활용 가능성을 검증하는 AI-Ready Data Platform입니다.
검증을 마친 데이터 상태는 릴리즈 상태로 고정하고, 각 AI 실행을 당시 사용한 릴리즈 상태와 연결합니다. 결과가 달라졌을 때 데이터 상태 Diff를 사용하면 변화 전후 두 실행에서 스키마와 분포, 데이터 범위, 전처리 조건, 데이터 출처와 전처리·변환 이력이 어떻게 달라졌는지 비교할 수 있습니다.
필요한 경우 이전 실행에 사용된 데이터 상태를 다시 구성해, 발견한 변화가 결과에 어떤 영향을 미쳤는지도 살펴볼 수 있습니다. “데이터가 변했다”는 경고에서 그치지 않고, 무엇이 달라졌으며 해당 변화가 어느 AI 실행에 영향을 미쳤는지 파악하는 것이 핵심입니다.
