스키마 드리프트(schema drift)는 조용히 찾아옵니다. 원천 시스템 팀이 새 제품군을 위한 컬럼을 추가하거나, status를 account_status로 이름을 바꾸거나, 숫자 코드를 문자열로 바꿉니다. 변경이 일어난 날에는 파이프라인에서 아무것도 실패하지 않습니다. 문제는 나중에 드러납니다. 조인 결과의 행 수가 줄거나, 피처가 null로 채워지거나, 모델이 처음 보는 코드를 읽게 됩니다.
원인은 대개 평범합니다.
- 애플리케이션 릴리스가 자기 소유 테이블을 변경함
- 외부 업체 API가 필드를 추가하거나 폐기함
- 스프레드시트 내보내기가 컬럼 순서나 이름을 바꿈
- 마이그레이션이 식별자나 날짜의 타입을 바꿈
팀은 수집 단계의 스키마 검사와 테이블 생산자·소비자 간 계약으로 대부분을 잡아냅니다. AI 업무에서 더 까다로운 경우는 스키마는 유효하게 유지되면서 필드의 의미가 바뀌는 변경입니다.
스키마 드리프트는 데이터 드리프트와 어떻게 다른가요?
- 스키마 드리프트는 구조가 바뀌는 것입니다. 어떤 컬럼이 있는지, 이름과 타입이 무엇인지가 달라집니다. 데이터 드리프트는 구조는 그대로인 채 그 안의 값이 바뀌는 것입니다. 분포, 범위, 빈도가 달라집니다.
- 스키마 드리프트는 보통 적재 시점에 검증기가 알아챌 수 있습니다. 데이터 드리프트는 기준 기간과 통계를 비교해야 드러납니다.
- 두 경우 모두 AI 결과에서 같은 문제가 생깁니다. 모델이 평가받던 때와 의미가 달라진 입력을 읽게 됩니다.
AI 업무에서 스키마 드리프트는 어디서 문제를 일으키나요?
이탈 예측 모델이 account_status를 읽습니다. 그런데 결제팀이 지난 분기에 이 값을 status와 sub_status로 나눴습니다. 기존 컬럼은 여전히 존재하고 검증도 통과하지만, 이제 모델이 학습한 코드 9개 중 4개만 담고 있습니다. 예측은 계속 나오고 모든 행이 스키마 검사를 통과하지만, 모델은 아무도 모르게 일시 정지된 계정을 보지 못하게 됩니다.
이런 변경은 모델이 평가받을 때의 필드 프로파일과 새 추출본의 프로파일을 비교해야 잡힙니다. 고유값, null 비율, 담당자가 확인한 의미를 봅니다. Syntitan에서는 준비 결과가 프로젝트 Version과 함께 기록됩니다. 새 추출본은 Ready for Raw Data에서 6개 축으로 진단하고, Ready for Model에서 같은 평가 세트로 전후 비교를 다시 실행할 수 있습니다. 이전 점검 결과를 다음 추출본으로 이어 가는 기능은 개발 중입니다. 프로파일 자체는 데이터 프로파일링에서, 이름이 바뀐 필드를 다시 연결하는 방법은 필드 매핑에서 다룹니다.