안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
지난달까지 문제없이 작동하던 심사 보조 모델이 이번 달 들어 같은 유형의 심사에서 이전과 다른 판단을 내놓기 시작했습니다. 모델과 프롬프트는 그대로였고, 데이터 파이프라인에서도 원인으로 볼 만한 오류는 발견되지 않았습니다.
그런데 기존 테이블만 확인해서는 원인을 찾기 어렵습니다. 지난달 실행에 사용된 데이터 범위와 스키마, 결측값 처리 기준, 당시 참조 정보가 이미 달라졌기 때문인데요.
여기서 필요한 것은 최신 데이터가 아니라 결과가 만들어진 당시의 데이터 상태입니다. 정상 실행과 문제 실행을 비교하려면 각 실행에 사용된 데이터와 처리 조건을 결과와 함께 기록해야 합니다.
릴리즈 상태(Release State)는 AI를 실행할 때 사용한 데이터 범위와 스키마, 전처리 조건, 참조 정보를 하나의 상태로 고정한 기록입니다. 해당 기록을 실행 결과와 연결해 두면 시간이 지난 뒤에도 결과가 만들어진 조건을 다시 확인할 수 있습니다.
결과를 다시 확인하려면 어떤 기록이 필요할까요?
현재 데이터만 살펴봐서는 지난달 실행에 어떤 데이터가 사용됐는지 알 수 없습니다. 당시 결과를 다시 조사하려면 실행에 사용된 데이터 범위와 스키마, 전처리 규칙, 참조 정보를 하나의 기록으로 고정해야 합니다.
데이터 사본만 저장해서는 충분하지 않습니다. 여러 사본 가운데 어떤 상태가 해당 실행에 사용됐는지 연결돼 있지 않으면 결과가 달라진 원인을 찾기 어렵기 때문인데요. 릴리즈 상태는 실행 당시의 데이터 상태를 고정하고, 런 바인딩(Run Binding)은 해당 상태를 개별 AI 실행과 연결합니다.

AI 결과의 원인을 추적하는 데 필요한 다섯 가지 기록
AI 결과를 다시 조사하려면 사용된 데이터만 저장해서는 충분하지 않습니다. 모델이 읽은 데이터의 범위와 구조, 적용한 전처리 방식, 참조 정보, 개별 실행을 구분할 식별자가 함께 남아 있어야 하는데요. 그래야 당시 모델에 어떤 데이터가 어떤 조건으로 입력됐는지 확인할 수 있습니다.
모델 버전 기록만으로 결과를 재현하기 어려운 이유
MLflow Model Registry와 같은 모델 레지스트리는 배포된 모델의 아티팩트와 버전을 관리합니다. 하지만 같은 모델을 사용해도 데이터 범위와 스키마, 전처리 규칙, 참조 정보가 달라지면 결과도 달라질 수 있습니다.
AI 결과를 나중에 다시 확인하려면 모델 버전과 실행 당시의 데이터 상태를 함께 기록해야 합니다. 모델 버전으로는 어떤 모델이 실행됐는지 확인하고, 릴리즈 상태로는 해당 모델이 어떤 데이터와 처리 조건을 사용했는지 확인할 수 있습니다.

실행 당시의 데이터 상태를 확인해야 하는 네 가지 상황
다음과 같은 상황에서는 모델 버전뿐 아니라 실행에 사용된 데이터 상태까지 확인해야 합니다.
- 결과가 이전과 달라졌을 때: 마지막 정상 실행과 문제 실행에 사용된 데이터 범위와 처리 조건을 비교합니다.
- 감사나 내부 검토를 진행할 때: 해당 판단에 사용된 데이터와 문서의 버전을 확인합니다.
- PoC를 실제 업무에 적용할 때: 샘플 데이터와 실제 업무 데이터의 스키마와 참조 정보가 어떻게 다른지 확인합니다.
- 여러 에이전트가 같은 데이터를 사용할 때: 에이전트별로 어떤 데이터 상태를 읽고 실행했는지 구분해 기록합니다.
업무에 따라 남겨야 할 기록
조직이 중점적으로 남겨야 할 기록은 업무 환경에 따라 달라집니다. 공공기관은 참조한 문서의 시행 시점과 적용 대상을, 금융기관은 판단 당시 사용한 데이터와 처리 조건을 기록해야 합니다. 일반 기업은 PoC와 실제 업무 환경에서 달라진 데이터 범위와 실행 조건을 확인할 수 있어야 합니다.
결과가 달라졌다면 데이터 상태부터 비교해야 합니다
AI 결과가 달라졌다고 해서 모델부터 교체할 필요는 없습니다. 마지막으로 정상적인 결과가 나온 실행과 문제가 발생한 실행을 먼저 비교해야 하는데요. 두 실행에 사용된 데이터 범위와 스키마, 전처리 조건, 참조 정보를 살펴보면 무엇이 달라졌는지 확인할 수 있습니다.
미국 국립표준기술연구소(NIST) AI RMF Playbook도 AI 시스템의 측정 결과와 관련 정보를 문서로 남기도록 안내합니다. 모델과 실행 로그뿐 아니라 당시 사용한 데이터 상태까지 함께 기록해야 결과가 달라진 원인을 구체적으로 조사할 수 있습니다.

- 실행 확인: 문제가 발생한 실행과 정상 실행을 식별합니다.
- 상태 비교: 두 실행에 연결된 데이터 범위와 처리 조건을 나란히 봅니다.
- 변경 추적: 스키마·값·참조 정보·전처리에서 달라진 지점을 찾습니다.
- 과거 상태 재현: 당시 조건을 다시 구성해 같은 결과가 나오는지 확인합니다.
데이터 스냅샷과 릴리즈 상태의 차이
데이터 스냅샷은 특정 시점의 데이터 사본을 저장합니다. 릴리즈 상태는 AI가 사용한 데이터 범위와 스키마, 전처리 규칙, 참조 정보를 하나의 상태로 고정합니다. 이후 런 바인딩이 해당 릴리즈 상태를 개별 AI 실행과 연결합니다.
스냅샷만 저장하면 여러 사본 가운데 어떤 데이터가 실제 결과에 사용됐는지 확인하기 어렵습니다. 이전 결과가 왜 달라졌는지 확인하려면 실행에 사용된 데이터뿐 아니라 당시 적용된 처리 조건과 해당 실행의 연결 기록까지 남아 있어야 합니다.
결과를 확인하는 데 필요한 다섯 가지 질문
아래 질문 가운데 답하기 어려운 항목이 있다면, 실행 당시의 데이터 상태나 처리 조건이 충분히 기록되지 않았을 수 있습니다.
- 결과에 사용된 정확한 데이터와 문서를 찾을 수 있나요?
- 실행 당시 스키마와 전처리 규칙을 확인할 수 있나요?
- 프롬프트와 임계값, 참조 정보의 버전을 확인할 수 있나요?
- 데이터 상태와 실행 결과가 하나의 식별자로 연결돼 있나요?
- 현재 데이터가 바뀌어도 당시 상태를 다시 구성할 수 있나요?
AI를 실제 업무에 적용하기 전에 정할 기록
AI를 실제 업무에 적용하기 전에는 실행마다 어떤 정보를 남길지 먼저 정해두는 편이 좋습니다. 데이터 범위와 스키마, 전처리 조건, 참조 정보를 기록하고, 각 데이터 상태를 실행 결과와 연결할 식별자도 함께 정해두면 결과가 달라졌을 때 비교 기준으로 활용할 수 있습니다.
모든 데이터를 별도의 사본으로 저장할 필요는 없습니다. 결과를 다시 확인하고 문제의 원인을 조사하는 데 필요한 정보를 선별해 보존하는 것이 중요합니다. 시간이 지난 뒤에도 해당 실행에 어떤 데이터와 처리 조건이 사용됐는지 확인할 수 있어야 합니다.
기록이 남아야 결과를 다시 확인할 수 있습니다
Syntitan은 검증을 마친 데이터 상태를 릴리즈 상태로 고정합니다. 런 바인딩은 해당 릴리즈 상태를 개별 AI 또는 에이전트 실행과 연결합니다. 결과가 달라지면 정상 실행과 문제 실행에 사용된 데이터 상태를 비교하고, 필요한 경우 과거 실행에 적용된 조건을 다시 확인할 수 있습니다.
실제 AI 결과 하나를 선택해 당시 사용한 데이터 범위와 처리 조건을 확인해 보세요. 관련 기록을 찾을 수 없다면 앞으로 무엇을 남겨야 하는지 분명해집니다.
