AI를 운영 환경에 적용한 뒤 결과가 달라졌다면? 스키마 변경부터 확인해야 하는 이유

안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.

운영 중인 AI가 갑자기 다른 결과를 내기 시작하면 가장 먼저 모델 버전을 확인합니다. 그러나 모델과 코드를 바꾸지 않아도 결과가 달라지는 경우가 있습니다.

데이터팀은 일상적인 유지보수 과정에서 고객 상태 컬럼의 이름을 바꾸거나 숫자 코드를 문자열로 변환하고, 새로운 범주를 추가하기도 합니다. 마이그레이션과 파이프라인이 오류 없이 끝나더라도 모델이 읽는 컬럼과 값의 형식, 범주, 단위가 달라지면 모델에 전달되는 입력 조건도 달라집니다.

스키마 변경 이후 AI 결과가 달라졌다면 모델을 수정하기 전에, 변경 전후의 데이터 상태가 실제 실행과 어떻게 연결됐는지부터 살펴봐야 합니다.

스키마 변경을 데이터베이스 작업으로만 남기면 AI팀은 결과가 달라진 뒤에야 영향을 알아차립니다. 원인을 빠르게 좁히려면 데이터팀과 AI팀, 상위 시스템 담당자, 운영·검수 담당자가 변경된 필드와 적용 시점, 영향을 받는 모델, 변경 전후 실행을 같은 기록에서 확인할 수 있어야 합니다.

스키마가 바뀌면 모델이 읽는 데이터도 달라집니다

모델은 컬럼 이름뿐 아니라 값의 형식과 범주, 단위, 필드 사이의 관계까지 함께 읽는데요. 데이터팀이 단순한 정리나 표준화로 받아들이는 변경도 모델에는 새로운 값과 규칙으로 전달됩니다.

스키마 형식이 유효한 것과 모델이 이전과 같은 의미의 입력을 받는 것은 별개의 문제입니다. 컬럼이 그대로 남아 있어도 값의 의미와 분포가 달라지면 AI 결과도 바뀝니다.

파이프라인은 정상인데 AI 결과가 달라지는 이유

스키마 변경이 AI 결과에 미치는 영향은 운영 환경에서 바로 드러나지 않을 때가 많습니다. 변경을 담당하는 조직과 모델을 운영하는 조직이 다르고, 기존 점검 방식은 데이터가 처리됐는지를 확인하는 데 초점이 맞춰져 있기 때문입니다.

스키마 변경이 AI팀에 공유되지 않습니다

스키마는 데이터팀이 관리하고 모델은 AI팀이 운영하며, 상위 시스템 변경은 애플리케이션팀이 맡기도 합니다. 어떤 모델이 어느 필드를 사용하는지 연결돼 있지 않으면 AI팀은 결과가 달라진 뒤에야 스키마 변경을 알게 됩니다.

형식 검사만으로는 의미와 분포 변화를 찾기 어렵습니다

기존 컬럼을 호환용으로 남기거나 기본값을 채우면 파이프라인은 오류 없이 끝나고 데이터 형식 검사도 통과할 수 있습니다. 그러나 모델이 구분하던 여러 상태가 하나의 값으로 합쳐졌다면 입력 신호는 이미 달라진 것입니다.

결과 변화가 일부 요청에서만 나타납니다

스키마 변경의 영향은 모든 요청에 한꺼번에 나타나지 않고, 특정 범주나 일부 고객에게서만 드러날 수 있습니다. 평균 지표의 변화가 크지 않으면 현업 문의가 쌓인 뒤에야 문제를 알아차리기도 합니다.

Google Research의 머신러닝 기술 부채 연구는 데이터 의존성과 외부 환경의 변화가 ML 시스템의 유지보수 부담을 키운다고 설명합니다. 스키마 변경을 모델 배포와 별개의 작업으로만 관리하면, 코드와 모델 밖에서 달라진 입력 조건을 놓치기 쉽다는 뜻입니다.

예시: 고객 상태 컬럼을 나눈 뒤 위험 신호가 사라진 경우

기존 customer_status에는 정상, 연체, 해지 검토와 같은 상태가 함께 기록돼 있었습니다. 이후 상위 CRM에서 이 필드를 account_status와 service_status로 나눴다고 가정해 보겠습니다.

기존 컬럼은 호환성을 위해 남았지만 모든 행에 ACTIVE라는 기본값이 들어갔습니다. 컬럼이 존재하기 때문에 스키마 검사는 통과하고 파이프라인도 오류 없이 끝납니다. 모델 버전 역시 바뀌지 않습니다.

• 변경 전: 고객 상태가 여러 값으로 나뉘어 위험 신호로 사용됨
• 변경 후: 기존 컬럼이 하나의 기본값으로 채워져 상태 차이가 사라짐
• 운영 결과: 모델이 고객별 위험을 구분하는 데 쓰던 신호가 약해짐

이 사례의 문제는 컬럼이 사라진 데 있지 않습니다. 컬럼은 그대로 남아 있지만 모든 행이 같은 기본값으로 채워지면서 고객 상태를 구분하던 정보가 사라졌습니다. 컬럼 안에 담긴 업무 의미와 값의 분포가 바뀐 것인데요. 모델은 같은 컬럼을 읽고도 이전에 활용하던 위험 신호를 얻지 못합니다. 컬럼의 존재 여부나 데이터 형식만 검사해서는 찾기 어려운 변화입니다.

스키마 변경이 AI 결과에 미치는 영향을 검증하는 5단계

1. 변경되는 필드를 사용하는 AI를 찾습니다

어떤 모델과 에이전트가 해당 컬럼과 문서 구조, 코드표를 사용하는지 연결합니다. 전체 스키마가 아니라 실제 AI가 의존하는 필드를 기준으로 영향 범위를 정해야 합니다.

2. 변경 전후의 데이터 상태를 남깁니다

마이그레이션 전후의 데이터와 스키마, 전처리 규칙, 참조 정보를 각각 식별할 수 있도록 기록합니다. 이후 비교와 복원에 사용할 기준이 됩니다.

3. 형식뿐 아니라 의미와 분포를 비교합니다

컬럼 이름과 자료형에 그치지 않고 범주 비율과 결측값, 단위, 조인 관계, 코드 정의가 어떻게 달라졌는지 Diff로 비교해야 합니다.

4. 실제 모델과 업무 지표로 검증합니다

변경된 스키마로 모델을 실행해 주요 지표와 업무 예외가 어떻게 달라지는지 확인합니다. 파이프라인이 성공했다고 해서 AI 결과까지 안정적인 것은 아니므로 두 기준을 나누어 검증해야 합니다.

5. 검증한 상태를 실제 실행과 연결합니다

검증을 마친 데이터 상태는 릴리즈 상태(Release State)로 관리하고, 이후 각 AI 실행이 어떤 릴리즈 상태를 사용했는지 기록합니다. 문제가 생기면 Reproduce 기능을 사용해 변경 전의 데이터 상태와 입력 조건을 다시 구성하고, 당시 결과가 다시 나타나는지 확인합니다.

한국지능정보사회진흥원의 인공지능 학습용 데이터 품질관리 가이드라인도 품질관리 체계와 절차, 산출물, 자가점검 및 품질검증 방법을 제시하는데요. 품질을 점검했다는 기록만으로는 어떤 변경이 어느 AI 실행에 영향을 미쳤는지 파악하기 어렵습니다. 운영 환경에서 스키마 변경의 영향까지 추적하려면 변경 전후의 품질관리 기록을 실제 실행에 사용된 데이터 상태와 연결해야 합니다. 그래야 결과가 달라졌을 때 어떤 스키마와 처리 조건이 사용됐는지 확인할 수 있습니다.

산업별 스키마 변경이 AI 업무에 미치는 영향

스키마 변경이 미치는 영향은 AI가 맡은 업무에 따라 달라집니다. 같은 코드나 필드 변경이라도 민원 분류, 금융 심사, 설비 예측처럼 다음 행동으로 이어지는 업무에서는 결과의 의미까지 함께 살펴봐야 합니다.

공공기관의 데이터베이스 표준화 지침은 구축·운영 단계의 표준 관리와 메타데이터, 점검·조치를 다룹니다. 공공 데이터를 AI가 검색하거나 분류하는 데 사용한다면 표준 코드와 메타데이터가 달라진 시점, 영향을 받는 업무, 변경 전후 실행도 함께 기록해야 합니다.

스키마 변경이 AI 실행 근거로 남아 있는지 확인하는 방법

다음 질문을 통해 스키마 변경과 AI 실행이 함께 기록되고 있는지 확인해 보세요.

• 변경된 필드를 사용하는 모델과 에이전트를 바로 찾을 수 있나요?
• 이름과 자료형뿐 아니라 단위와 업무 의미가 어떻게 바뀌었는지도 기록돼 있나요?
• 변경 전후의 데이터 상태를 같은 기준으로 Diff할 수 있나요?
• 변경된 상태를 실제 모델과 업무 지표로 검증했나요?
• 문제가 생기면 이전 상태를 Reproduce해 결과를 다시 확인할 수 있나요?

스키마 변경 기록이 남아 있어도 이 질문에 답하기 어렵다면, 데이터 변경 기록이 실제 AI 실행까지 이어지지 않고 있는 것입니다.

스키마 변경을 여러 조직이 함께 검토할 때

AI가 사용하는 스키마가 바뀌었다면 데이터 마이그레이션이 문제없이 끝났는지만 확인해서는 충분하지 않은데요. 데이터팀과 AI팀, 운영·검수 담당자가 같은 실행 ID와 변경 기록을 보며 언제 무엇이 바뀌었는지, 어떤 모델이 영향을 받았고 결과가 어떻게 달라졌는지 함께 검토해야 합니다.

• 데이터 플랫폼팀: 변경된 컬럼과 코드, 호환용 필드, 기본값, 적용 시점과 되돌리기 조건을 기록합니다.
• AI·데이터팀: 변경된 필드를 사용하는 모델과 에이전트를 찾고 입력 분포와 업무 지표의 변화를 검증합니다.
• 거버넌스·보안: 데이터의 사용 목적과 출처, 코드 정의, 접근 권한, 변경 승인 범위를 확인합니다.
• 운영·감사·검수: 변경 전후 실행 ID와 데이터 상태, 검증 결과를 비교하고 문제가 발생했을 때 이전 조건을 다시 구성할 수 있는지 살펴봅니다.
• 상위 시스템·인프라: 변경 내용이 하위 시스템에 반영되는 순서와 보존 범위, 담당 조직, 복구 절차를 배포·검수 문서에 남깁니다.

이 기록만으로 정책 승인이나 규제 준수 여부를 판단할 수는 없습니다. 다만 여러 조직이 같은 변경 사항과 실행 기록을 바탕으로 AI 결과가 달라진 원인을 함께 파악할 수 있습니다.

Syntitan으로 스키마 변경 전후의 데이터 상태를 비교하는 방법

Syntitan은 기업 데이터의 AI-Readiness를 여섯 축으로 진단하고, 부족한 부분을 개선한 뒤 실제 모델과 업무 지표를 기준으로 데이터의 활용 가능성을 검증하는 AI-Ready Data Platform입니다.

검증을 마친 데이터 상태는 릴리즈 상태로 관리하고, 각 AI 또는 에이전트 실행을 당시 사용한 릴리즈 상태와 연결합니다. 스키마가 바뀌면 변경 전후 상태를 Diff해 컬럼과 자료형, 범주, 분포, 전처리, 데이터 계보가 어떻게 달라졌는지 비교합니다.

필요한 경우 Reproduce로 이전 데이터 상태와 처리 조건을 다시 구성해, 확인된 변화가 AI 결과에 어떤 영향을 미쳤는지도 살펴볼 수 있습니다. 스키마 변경으로 AI 입력이 달라졌다면 데이터 변경 기록과 실제 AI 실행 기록도 함께 이어져야 합니다.