AI 재현성(Reproducibility)이란? 잘못된 결과의 원인을 찾는 6단계

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

AI가 예상과 다른 답변이나 판단을 내렸다면 같은 모델을 다시 실행하는 것만으로는 원인을 바로 확인할 수 없습니다. 모델과 코드는 그대로여도 당시 사용한 데이터는 이미 갱신됐을 수 있고, 검색 인덱스나 참조 정보도 달라졌을 수 있습니다. 그렇기 때문에 현재 데이터로 다시 실행해 기대한 결과가 나오더라도 문제가 발생한 이유를 찾았다고 보기는 어려운데요.

이때 필요한 것이 AI 재현성(Reproducibility)입니다. AI 재현성은 문제가 발생한 실행의 데이터 상태와 실행 조건을 다시 구성해 당시 결과가 다시 나타나는지 살펴보고, 예상대로 처리된 실행과 비교해 결과에 영향을 준 차이를 좁혀 가는 과정입니다.

AI 결과의 원인을 찾으려면 현재 데이터로 다시 실행하는 데서 그치지 않고, 문제가 발생했을 당시의 데이터 상태와 실행 조건을 재현해야 합니다.

원인을 정확히 파악하려면 기술팀뿐 아니라 데이터 플랫폼, 정보보안, 감사, 리스크 담당자도 함께 살펴봐야 합니다. 실행 ID(Run ID)를 기준으로 당시의 데이터 상태와 권한 조건, 도구 호출 기록을 연결하면 문제 전후에 무엇이 달라졌는지 확인할 수 있는데요. 여기에 조치 내용과 이후 결과까지 남겨 두면 각 조직이 같은 근거를 바탕으로 원인과 대응 효과를 판단할 수 있습니다.

현재 데이터 재실행과 당시 조건 재현의 차이 현재 데이터로 같은 모델을 실행하면 현재 조건의 결과를 살펴볼 수 있습니다. 문제가 발생한 당시의 데이터 상태와 실행 조건을 다시 구성해 같은 모델을 실행하면 당시 결과가 다시 나타나는지 살펴볼 수 있습니다.

현재 데이터로 다시 실행

현재 조건에서 어떤 결과가 나오는지 살펴봅니다.

현재 데이터

같은 모델

현재 결과

당시 조건을 재현해 다시 실행

당시 결과가 다시 나타나는지 살펴봅니다.

당시 데이터 상태

같은 모델

!

당시 결과 재현

같은 모델을 다시 실행해도 이전 결과가 재현되지 않는 이유

운영 환경의 AI는 라이브 테이블과 피처 파이프라인, 검색 인덱스, 참조 정보, 외부 도구를 연결해 사용하는데요. 이러한 요소는 운영 중에도 계속 바뀝니다. 따라서 문제를 확인할 때는 실행 당시의 데이터 상태가 이미 달라져 있을 수 있습니다.

당시 상태를 복원하려면 다음 사항을 확인해야 합니다.

• 새로운 행과 문서가 추가됐는지
• 상위 시스템의 컬럼과 코드가 바뀌었는지
• 전처리와 피처 생성 작업이 다시 실행됐는지
• 벡터 인덱스가 재생성됐는지
• 규정과 기준 정보가 갱신됐는지
• 사용자와 에이전트의 접근 권한이 수정됐는지

이러한 변화는 실제 ML 운영에서도 주요한 데이터 문제로 다뤄집니다. Google Research의 데이터 검증 연구는 예상하지 못한 데이터 패턴과 불완전한 스키마, 학습·서빙 데이터의 차이를 운영 단계에서 지속적으로 검증해야 할 항목으로 제시합니다.

다만 운영 데이터를 계속 검증하고 코드와 모델의 버전을 남겨도, 모델이 실제로 읽은 데이터와 참조 정보, 권한 조건까지 자동으로 보존되는 것은 아닌데요. 같은 모델을 현재 데이터로 다시 실행해도 이전 결과가 그대로 나타나지 않는 이유입니다.

AI 사고 데이터베이스(AI Incident Database)는 실제 환경에서 AI 시스템이 일으킨 문제를 수집해 연구자와 개발자가 비슷한 실패를 반복하지 않도록 돕는 공개 저장소입니다. 이러한 사례의 원인을 사후에 검토하려면 모델과 코드뿐 아니라 문제가 발생한 실행의 데이터 상태와 실행 조건도 함께 추적할 수 있어야 합니다.

재실행과 재현의 차이

현재 데이터로 다시 실행하면 지금의 조건에서 AI가 어떤 결과를 내는지는 확인할 수 있습니다. 하지만 데이터와 권한, 참조 정보가 당시와 달라졌다면 이전에 발생한 문제가 다시 나타나지 않을 수 있어, 현재 조건으로 다시 실행하는 것만으로는 결과가 달라진 이유를 알기 어렵습니다. 원인을 좁히려면 문제가 발생한 당시의 데이터 상태와 실행 조건을 다시 구성해 같은 결과가 나타나는지 확인해야 하는데요. 그런 다음 예상대로 처리된 실행과 비교해 어떤 차이가 결과에 영향을 미쳤는지 찾아야 합니다.

AI 결과를 재현해 원인을 확인하는 6단계

문제가 발생한 실행을 재현하는 여섯 단계 데이터와 로그를 보존하고 문제가 발생한 실행을 찾은 뒤 당시 데이터 상태를 복원합니다. 같은 모델로 다시 실행한 결과를 문제가 없었던 실행과 비교하고, 조치 후 결과를 검증합니다.

1. 1

   기록 보존

   데이터와 로그를 그대로 보존

2. 2

   문제 실행 찾기

   실행 ID로 대상을 특정

3. 3

   당시 상태 복원

   데이터·권한·참조 정보 복원

4. 4

   같은 모델로 재실행

   당시 결과가 나타나는지 확인

5. 5

   이전 결과와 비교

   문제가 없던 실행과 대조

6. 6

   조치 결과 검증

   같은 문제가 사라졌는지 확인

1단계. 조사에 필요한 기록부터 보존합니다

문제가 확인되면 조사에 필요한 데이터와 로그부터 보존합니다. 시스템은 조사를 시작한 뒤에도 계속 바뀌므로 당시 상태를 먼저 남겨야 합니다.

• 문제가 된 결과와 사용자 요청
• 실행 ID와 실행 시각
• 사용한 모델과 프롬프트, 도구 설정
• 데이터와 문서, 검색 상태
• 관련 로그와 이후 수행된 작업

조사하는 동안 데이터나 설정이 바뀌면 전후 차이를 정확히 비교하기 어렵습니다. 모든 기록을 한 번에 확보하기 어렵다면 현재 상태를 먼저 저장하고 이후 변경 사항을 빠짐없이 남깁니다.

2단계. 문제가 발생한 실행을 정확히 찾습니다

원인을 재현하려면 ‘어제 오후에 발생한 오류’처럼 범위를 넓게 잡지 말고, 잘못된 결과를 만든 실행 하나를 정확히 찾아야 합니다

다음 항목을 확인합니다.

• 고유 실행 ID
• 요청과 응답 또는 판단 결과
• 실행한 사용자 또는 에이전트
• 모델 버전과 실행 설정
• 연결된 릴리스 상태(Release State)

런 바인딩(Run Binding)이 없다면 여러 시스템의 타임스탬프와 로그를 대조해 해당 실행을 찾아야 합니다. 이 과정에서 실행과 데이터 상태를 잘못 연결하면 이후의 재현 결과도 부정확해집니다. 실행과 데이터 상태를 연결하는 방법은 런 바인딩이란 무엇인가에서 자세히 확인할 수 있습니다.

3단계. 당시 데이터 상태를 복원합니다

문제가 발생한 실행에 연결된 릴리스 상태를 기준으로 다음 항목을 다시 구성합니다.

• 모델이 실제로 읽은 행과 문서
• 스키마와 자료형
• 결측값 처리, 인코딩, 파생 변수 생성 방식
• 검색에 사용된 청크와 임베딩, 필터
• 코드표와 규정, 가격표 등 참조 정보
• 당시의 접근 권한과 실행 환경

원본 데이터만 되돌려서는 당시 조건을 재현할 수 없습니다. 모델에 입력되기까지 거친 변환 과정과 실행 조건도 함께 복원해야 합니다.

4단계. 같은 모델로 다시 실행합니다

복원한 데이터 상태와 실행 조건을 사고 당시의 모델에 적용해 다시 실행합니다.

같은 잘못된 결과가 나타나면 사고 조건이 재현된 것입니다. 결과가 달라진다면 아직 복원하지 못한 조건이 있는지 확인해야 하는데요. 비결정적 모델이나 외부 서비스가 포함된 실행은 같은 조건에서도 결과가 조금씩 달라질 수 있습니다. 이때는 결과의 완전한 일치보다 같은 실패 패턴과 판단 경로가 반복되는지를 확인해야 합니다.

5단계. 문제가 없었던 실행과 비교합니다

비교 대상으로는 문제가 발생하기 전에 정상적으로 끝난 실행이나 조건이 가장 비슷한 사례를 선택하는데요. 두 실행에 연결된 릴리스 상태를 데이터 상태 비교(State Diff)로 비교하면 다음 항목이 어떻게 달라졌는지 확인할 수 있습니다.

• 사라지거나 새로 추가된 필드와 문서
• 분포와 범주 비율 변화
• 전처리 방식과 스케일러, 토크나이저
• 갱신되지 않은 참조 정보
• 접근 권한과 도구의 반환 범위

상태 비교는 원인을 바로 확정하는 작업이 아니라 조사 범위를 좁혀 먼저 확인할 변경점을 찾는 과정입니다. 실제 비교 순서는 데이터 상태 Diff란 무엇인가에서 확인할 수 있습니다.

6단계. 수정 후 결과를 다시 검증합니다

원인으로 의심되는 항목을 수정한 뒤 사고 당시 조건과 현재 운영 조건에서 각각 다시 실행합니다.

1. 사고 당시 조건에 수정안을 적용했을 때 같은 실패가 사라졌나요?
2. 현재 운영 환경에서도 정상 결과가 유지되나요??
3. 기존 정상 사례에서 새로운 문제가 생기지는 않았나요?

사고 원인을 찾았다고 해서 조사가 끝나는 것은 아닙니다. 같은 입력과 조건에서 실패가 다시 나타나지 않는다는 결과까지 남겨야 수정 효과를 입증할 수 있습니다.

AI 실행을 재현할 때 필요한 기록

문제가 발생한 실행을 재현하려면 모델과 코드뿐 아니라 당시 사용된 데이터와 처리 조건까지 기록돼 있어야 합니다.

문제 발생 경위만 보고서에 정리해 두어서는 당시 실행을 재현하기 어렵습니다. 다른 담당자도 실행 ID(Run ID)를 기준으로 당시 사용된 데이터와 권한, 참조 정보, 모델·도구 설정을 찾아 같은 조건을 다시 구성할 수 있어야 합니다. 조치 후에는 해당 조건에서 다시 실행해 문제가 사라졌는지 확인한 결과까지 남겨야 합니다. NIST AI RMF Playbook의 Measure도 테스트 데이터와 평가 도구, 측정 절차를 문서화하는 것이 반복 가능한 검증과 일관된 판단의 기반이 된다고 설명합니다.

예시: 민원 분류 에이전트가 잘못된 부서를 추천한 경우

민원 분류 에이전트가 특정 민원을 담당하지 않는 부서로 추천했다고 가정해 보겠습니다. 원인을 확인하려면 다음 순서로 실행을 재현합니다.

1. 관련 기록을 보존합니다

민원 내용과 추천 결과, 단계별 도구 호출 기록, 이후 실제로 배정된 부서를 함께 보존합니다.

2. 문제가 발생한 실행을 찾습니다

해당 민원의 실행 ID(Run ID)를 확인하고, 실행에 연결된 릴리즈 상태를 찾습니다.

3. 당시 상태를 복원합니다

실행 당시 적용된 부서 코드와 업무 분장, 시행 중이던 지침, 검색 대상 문서, 사용자 권한을 다시 구성합니다.

4. 같은 모델로 다시 실행합니다

당시 사용한 모델과 프롬프트, 데이터 상태를 적용해 같은 부서가 다시 추천되는지 확인합니다.

5. 이전 결과와 비교합니다

같은 유형의 민원을 올바른 부서로 추천한 실행과 비교합니다. 폐지된 업무 분장 문서가 검색됐는지, 오래된 부서 코드가 적용됐는지 등 결과에 영향을 준 차이를 찾습니다.

6. 조치 결과를 검증합니다

확인된 원인에 따라 폐지된 문서를 검색 대상에서 제외하거나 부서 코드를 최신 정보로 바꾼 뒤 같은 민원을 다시 실행합니다. 올바른 부서가 추천되는지, 기존에 제대로 처리되던 유사 민원의 결과에는 영향이 없는지 함께 검증합니다.

이 과정을 거치면 단순히 ‘모델이 틀렸다’고 결론 내리는 데서 그치지 않고, 어떤 데이터와 조건이 잘못된 추천에 영향을 미쳤으며 조치 후 문제가 해결됐는지 구체적으로 설명할 수 있습니다.

에이전트 실행은 중간 단계까지 재현해야 합니다

에이전트는 문서를 검색하고 판단한 뒤 도구를 호출하는 과정을 여러 차례 반복하는데요. 최종 결과만 남겨두면 오류가 어느 단계에서 시작됐는지 찾기 어렵습니다.

따라서 다음 기록을 실행 순서대로 연결해 두어야 합니다.

• 검색에 사용된 문서와 데이터
• 도구별 반환값
• 에이전트가 선택한 다음 행동
• 권한 및 정책 판단 결과
• 최종 결과와 담당자의 검토 내용

문제의 시작점은 최초 입력이 아니라 세 번째 도구 호출에서 받은 오래된 값일 수도 있습니다. 런 바인딩도 최초 입력과 최종 결과만 연결하는 데 그치지 않고 중간 검색 결과와 도구 호출까지 추적할 수 있어야 합니다.

문제가 발생한 AI 실행을 재현할 수 있는지 확인하는 방법

다음 질문으로 현재의 재현 준비 상태를 확인해 보세요.

1. 과거 특정 결과에 사용된 데이터 상태와 실행 조건을 바로 찾을 수 있나요?
2. 데이터가 갱신된 뒤에도 해당 결과가 만들어진 당시의 상태를 복원할 수 있나요?
3. 예상대로 처리된 실행과 문제가 발생한 실행의 차이를 데이터 필드와 문서, 전처리 규칙 단위로 비교할 수 있나요?
4. 같은 모델과 데이터 상태, 실행 조건을 적용했을 때 당시 결과가 다시 나타나나요?
5. 조치 후 같은 조건으로 다시 실행해 문제가 사라지고 기존 결과에는 영향이 없는지 검증할 수 있나요?

이 질문에 명확히 답하기 어렵다면 과거 실행에 사용된 데이터와 조건이 충분히 연결돼 있지 않으며, 원인 조사도 담당자의 기억과 추정에 의존할 가능성이 큽니다.

문제가 발생한 AI 실행을 조직별로 검토할 때 확인할 항목

문제가 발생한 실행을 재현했다고 검토가 끝나는 것은 아닙니다. 원인과 조치 효과를 판단하려면 기술팀뿐 아니라 데이터 거버넌스, 보안, 인프라, 감사, 사업관리 담당자도 같은 실행 ID(Run ID)와 관련 기록을 확인할 수 있어야 합니다.

• AI·데이터팀: 실제 사용 사례와 기대한 결과를 기준으로 비교할 실행을 정하고, 모델과 프롬프트, 데이터 상태의 차이를 분석합니다.
• 데이터 거버넌스·보안: 실행에 사용된 데이터의 목적과 출처, 버전, 가공 과정, 접근 주체, 당시 적용된 권한을 확인합니다.
• 운영·감사·검수: 문제가 발생한 실행에 연결된 릴리즈 상태와 도구 호출 기록을 추적하고, 비교 실행과 달라진 조건 및 조치 이후의 결과를 검토합니다.
• 인프라·조달: 기존 데이터 플랫폼 및 MLOps와의 연계 방식, 내부망·온프레미스·클라우드에서의 처리 위치, 기록 보존 범위와 담당 조직을 배포·검수 문서에 명시합니다.

여러 조직이 같은 실행 ID와 기록을 바탕으로 검토해야 원인과 조치 결과를 함께 판단할 수 있습니다. 다만 이러한 기록은 원인 조사를 위한 근거이며, 정책 승인이나 규제 준수 판단을 대신하지는 않습니다.

Syntitan으로 문제 발생 당시의 데이터 상태를 재현하는 방법

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

검증을 마친 데이터 상태는 릴리즈 상태로 관리하고, 각 AI 또는 에이전트 실행과 연결합니다. 문제가 발생하면 실행 ID(Run ID)에 연결된 릴리즈 상태를 불러와, 당시 사용된 데이터와 스키마, 전처리, 참조 정보, 권한 조건을 Reproduce로 다시 구성할 수 있습니다.

당시 결과가 다시 나타나는지 확인한 뒤에는 예상대로 처리된 실행의 릴리즈 상태와 Diff합니다. 두 실행에서 무엇이 달라졌는지 비교하면 결과에 영향을 준 조건을 좁히고, 조치 이후 같은 문제가 사라졌는지도 검증할 수 있습니다.

AI 실행을 재현하려면 결과와 데이터 상태가 미리 연결돼 있어야 합니다. 그래야 문제가 생긴 뒤 당시 조건을 다시 구성하고 원인과 조치 효과를 같은 근거로 확인할 수 있습니다.