안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
지난달까지 같은 조건에서 일관된 결과를 내던 예측 모델이 이번 달부터 이전과 다른 결과를 내놓기 시작했습니다. 배포한 모델 버전과 가중치는 그대로였고, 데이터 파이프라인에서도 뚜렷한 오류는 발견되지 않았습니다.
이럴 때 모델 기록만 살펴보면 데이터 범위와 스키마, 전처리 조건, 참조 정보에서 생긴 변화를 놓치기 쉽습니다. 같은 모델도 입력 조건이 달라지면 다른 결과를 낼 수 있기 때문인데요.
AI 결과가 달라진 이유를 설명하려면 모델 버전과 함께 당시 사용한 데이터 상태와 처리 조건을 살펴봐야 합니다. 릴리즈 상태(Release State)는 AI 실행에 사용된 데이터 범위와 스키마, 전처리 조건, 참조 정보를 하나의 상태로 기록합니다. 모델 버전과 릴리즈 상태를 실행 ID로 연결해 두면 결과의 변화가 모델에서 시작됐는지, 데이터나 처리 조건에서 시작됐는지 구분하기 쉬워집니다.
모델 버전 관리로 확인할 수 있는 것
모델 버전 관리는 어떤 모델이 학습되고 배포됐는지 추적하는 기본 수단입니다. 일반적으로 다음 정보를 기록합니다.
- 모델 아키텍처와 가중치
- 학습 코드와 주요 파라미터
- 평가 지표와 실험 결과
- 배포 버전과 수명주기
- 모델을 만든 실험과 변경 이력
MLflow Model Registry와 같은 도구는 모델 버전과 배포 이력, 생성·변경 이력, 메타데이터를 관리합니다. 이를 통해 어떤 모델이 언제 등록·배포됐고 어떻게 변경됐는지 확인할 수 있습니다.
그러나 모델 레지스트리만으로는 개별 AI 결과에 어떤 데이터와 처리 조건이 사용됐는지 파악하기 어렵습니다. 같은 모델 버전이라도 입력 데이터의 범위와 스키마, 전처리 조건이 달라지면 결과도 달라질 수 있기 때문인데요.
이 빈틈을 줄이려면 모델과 데이터, 실행 사이의 관계를 별도로 기록해야 합니다. TensorFlow의 ML Metadata(MLMD)는 파이프라인 실행과 입력·출력 아티팩트의 관계를 기록해 데이터 계보를 추적할 수 있도록 지원합니다.
다만 실행과 아티팩트의 관계를 기록하는 것만으로 당시 데이터 상태를 그대로 재현할 수 있는 것은 아닙니다. 결과에 사용된 데이터 범위와 스키마, 전처리 조건, 참조 정보를 함께 남기고 해당 AI 실행과 연결해야 합니다.
같은 모델의 결과를 바꾸는 네 가지 데이터 변화
1. 조회한 데이터 기간과 범위가 달라졌을 때
지난달에는 최근 24개월의 거래를 사용했지만 이번 달에는 최근 12개월만 조회할 수 있습니다. 조회 쿼리가 같더라도 새로운 데이터가 쌓이고 오래된 행이 빠지면 계절성과 희귀 사례의 분포가 달라질 수 있습니다.
2. 데이터 구조나 필드의 의미가 바뀌었을 때
고객 상태 필드의 자료형이 숫자에서 문자열로 바뀌거나 기존 범주가 둘로 나뉠 수 있습니다. 데이터팀에는 정상적인 변경이어도 모델이 읽는 입력 규칙은 달라집니다. 필드 이름이 그대로라면 모델 버전 기록만으로는 업무상 의미가 바뀐 사실을 알아차리기 어렵습니다.
3. 전처리 규칙이 달라졌을 때
결측값을 평균으로 채우던 규칙이 0으로 바뀌거나 범주 인덱스를 새로 만들 수 있습니다. 원본 값이 같아도 전처리 방식이 달라지면 모델에 입력되는 숫자와 분포도 달라집니다.
4. 접근 권한과 기준 정보가 달라졌을 때
에이전트가 참조할 수 있는 문서 범위가 좁아지거나 업무 기준 정보가 갱신될 수 있습니다. 금융 상담 AI가 사용하는 가격표, 공공기관 RAG가 참조하는 지침, 기업 에이전트에 부여된 계약 권한이 바뀌면 같은 모델과 프롬프트도 다른 조건에서 실행됩니다.
모델 버전과 데이터 상태를 나란히 살펴봐야 결과가 달라진 지점을 구체적으로 좁힐 수 있습니다.
모델과 데이터 기록이 따로 관리될 때
AI·ML팀은 모델 레지스트리에 배포 버전과 학습 설정을 남기고, 데이터팀은 변경 관리 시스템에 스키마와 파이프라인 변경 이력을 기록합니다. 각 기록이 정확하더라도 서로 연결돼 있지 않으면 어떤 변화가 특정 AI 결과에 영향을 미쳤는지 파악하기 어렵습니다.
- AI·ML팀: 모델 버전과 학습·실행 설정을 관리합니다.
- 데이터팀: 스키마와 파이프라인, 전처리 규칙의 변경 이력을 관리합니다.
- 보안·거버넌스 조직: 접근 권한과 정책, 승인 이력을 관리합니다.
- 현업 부서: 업무 규칙과 참조 정보의 적용 시점을 관리합니다.
결과와 관련된 기록을 실행 ID를 기준으로 연결해 두면, 결과가 달라졌을 때 여러 시스템의 정보를 일일이 대조하지 않고 변경 원인을 더 빠르게 좁힐 수 있습니다.
재학습 전에 데이터 변화를 살펴봐야 하는 이유
결과가 달라졌다고 곧바로 모델을 재학습하면 데이터 변화가 원인이었는지 판단하기 어려워집니다. 잘못된 입력 상태에 맞춰 모델을 다시 학습하거나, 비교 기준인 모델까지 바뀌어 조사 범위가 더 넓어질 수 있습니다.
- 결과가 달라지기 전후의 두 실행에서 모델 버전을 비교합니다.
- 모델 버전이 같다면 두 실행에 사용된 데이터 상태를 살펴봅니다.
- 데이터 범위, 스키마, 전처리 규칙, 참조 정보와 권한의 변화를 파악합니다.
- 이전 실행에 사용된 데이터 상태를 다시 구성해 같은 모델로 결과를 검증합니다.
- 비교 결과를 바탕으로 데이터 수정과 모델 재학습 가운데 필요한 조치를 결정합니다.
데이터 변화의 영향을 먼저 확인하면 입력 조건을 바로잡아야 하는 문제인지, 모델을 재학습해야 하는 문제인지 구분할 수 있습니다.
모델 버전과 데이터 상태를 함께 기록하는 방법
릴리즈 상태(Release State)는 특정 시점에 사용된 데이터 범위와 스키마, 전처리 조건, 참조 정보를 하나의 상태로 고정합니다.
런 바인딩(Run Binding)은 AI 결과를 해당 실행에 사용된 모델 설정 및 릴리즈 상태와 연결해 하나의 기록으로 남깁니다. 두 기록을 함께 사용하면 다음 내용을 살펴볼 수 있습니다.
- 결과가 달라지기 전후의 데이터 상태
- 변경된 필드와 전처리 규칙
- 원천 데이터부터 전처리·변환까지 이어지는 변경 이력
- 이전 실행에 사용된 데이터와 처리 조건
모델 레지스트리는 어떤 모델 버전이 등록·배포됐는지를 보여줍니다. 그리고 릴리즈 상태와 런 바인딩은 해당 모델이 어떤 데이터와 처리 조건을 사용해 결과를 만들었는지 추적할 수 있게 합니다. 이 정보를 함께 살펴보면 결과가 달라진 원인이 모델에 있는지, 데이터나 처리 조건에 있는지 더 빠르게 파악할 수 있습니다.
공공기관 RAG에서는 모델 버전만으로 부족한 이유
기관 내부 지침을 검색하는 RAG 시스템을 예로 들어보겠습니다. 모델 버전과 프롬프트가 같더라도 검색 대상과 조건이 바뀌면 답변도 달라질 수 있는데요.
- 새로운 지침이 검색 인덱스에 추가됐습니다.
- 폐지된 문서가 검색 인덱스에 남아 있습니다.
- 문서를 검색 단위로 나누는 기준이 바뀌었습니다.
- 임베딩 모델이나 검색 필터가 변경됐습니다.
- 사용자의 문서 접근 권한이 달라졌습니다.
모델 버전만 기록하면 이런 변화를 놓치기 쉽습니다. 해당 답변이 어떤 문서와 검색 조건을 바탕으로 생성됐는지 연결해 두어야, 나중에 답변이 달라진 이유를 구체적으로 확인할 수 있습니다.
모델 레지스트리와 데이터 상태 기록의 역할
기존 모델 레지스트리를 다른 도구로 바꿀 필요는 없습니다. 모델 기록과 데이터 상태 기록을 같은 실행 ID로 연결하면 각각의 관리 체계를 유지하면서도 결과가 달라진 이유를 더 구체적으로 살펴볼 수 있습니다.
AI 결과가 달라진 이유를 살펴보는 다섯 가지 질문
실실제 AI 결과 하나를 선택한 뒤 다음 질문에 답해 보세요.
- 과거 결과를 당시와 같은 모델과 데이터 상태에서 다시 만들 수 있나요?
- 같은 모델에서 결과가 달라졌다면, 두 실행에 사용된 데이터의 차이를 비교할 수 있나요?
- 당시 사용한 스키마와 전처리 규칙, 참조 정보를 다시 구성할 수 있나요?
- 데이터 변경 이력을 해당 결과의 실행 ID를 기준으로 추적할 수 있나요?
- 담당자가 바뀌어도 다른 팀이 같은 기록을 바탕으로 결과를 검토할 수 있나요?
모델을 다시 불러올 수 있어도 당시 입력 데이터와 처리 조건을 찾기 어렵다면, 결과가 달라진 이유를 정확히 확인하기 어렵습니다.
PoC를 운영 환경에 적용할 때 확인할 사항
PoC에서 기대한 결과를 얻었더라도 같은 조건을 운영 환경에 그대로 적용할 수 있는 것은 아닙니다. 운영 단계에서는 데이터 범위와 접근 권한, 처리 위치, 담당 조직이 달라질 수 있기 때문인데요. PoC에서 사용한 모델과 데이터, 처리 조건을 실행 ID와 연결해 두어야 거버넌스·보안·인프라·감사 담당자도 같은 기록을 바탕으로 검토할 수 있습니다.
- AI·데이터팀: 사용 사례와 목표 지표를 기준으로 데이터와 모델이 실제 업무에 적합한지 검증하고, PoC와 운영 환경의 결과 차이를 비교합니다.
- 데이터 거버넌스·보안: 데이터의 사용 목적과 출처, 버전, 가공 과정, 접근 주체와 허용 범위를 확인합니다.
- 업무 운영·감사·검수: PoC와 운영 환경에 사용된 모델과 코드, 데이터, 전처리 조건을 비교해 결과가 달라진 원인을 살펴봅니다.
- 인프라·조달: 기존 데이터 플랫폼 및 MLOps와의 연계 방식, 데이터 처리 위치, 기록 보존 범위와 담당 조직을 배포·검수 문서에 명시합니다.
Syntitan이 모델과 데이터 상태를 함께 검증하는 방식
Syntitan은 기업 데이터가 AI에 실제로 활용될 수 있는지 진단하고, 부족한 부분을 개선한 뒤 실제 모델과 업무 지표를 기준으로 결과를 검증하는 AI-Ready 데이터 플랫폼입니다.
검증을 마친 데이터 상태는 릴리즈 상태로 기록하고, 해당 상태를 AI 또는 에이전트 실행과 연결합니다.
결과가 달라지면 변화 전후의 실행에 사용된 데이터 범위와 스키마, 전처리 조건, 참조 정보를 비교할 수 있습니다.
필요하면 이전 실행 당시의 데이터 상태를 다시 구성해 변화 원인을 검증할 수 있습니다.
모델 버전 관리는 여전히 필요합니다. 다만 AI 결과가 달라진 이유를 설명하려면 어떤 모델을 사용했는지만이 아니라, 해당 실행에 사용된 데이터와 처리 조건도 함께 남겨야 합니다.
