안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
PoC에서는 기대한 성능을 보였지만 운영 환경에 적용한 뒤 결과가 달라지는 경우가 있습니다. 이러한 AI 운영 실패의 원인은 모델 자체에만 있지 않습니다. 배포 후 달라진 데이터 상태도 함께 살펴봐야 합니다. 처음에는 예상대로 작동하던 모델도 몇 주가 지나면 같은 유형의 요청에 다른 결과를 내거나 성능 지표가 흔들릴 수 있습니다.
모델팀이 버전을 바꾸지 않았고 데이터팀도 파이프라인에 문제가 없다고 확인했어도 AI 결과는 달라질 수 있는데요. 운영이 시작된 뒤 데이터 범위, 상위 시스템의 컬럼, 결측값 처리 방식, 참조 정보가 바뀌면서 모델에 전달되는 데이터와 처리 조건도 PoC 때와 달라지기 때문입니다.
배포 후 AI 성능이 달라졌다면 모델을 수정하기 전에 결과가 예상대로 나온 실행과 문제가 생긴 실행에 사용된 데이터 상태부터 비교해야 합니다.
PoC를 운영 환경으로 전환할 때는 모델 성능뿐 아니라 실제 업무에서 사용될 데이터 조건도 함께 살펴봐야 하는데요. 이를 위해 데이터 플랫폼, 정보보안, 인프라, 사업관리, 검수 담당자는 PoC와 운영 환경에서 데이터 범위와 전처리 방식, 권한 조건이 어떻게 달라지는지 같은 기록을 기준으로 함께 살펴봐야 합니다. 운영 기준과 문제 발생 시 재현 절차도 미리 정해 두면, 결과가 달라졌을 때 원인을 더 빠르게 좁힐 수 있습니다.
PoC의 데이터 조건은 운영 환경에서 달라집니다
PoC는 통제된 환경에서 모델이 목표 성능을 낼 수 있는지 확인하는 단계입니다. 정확한 평가를 위해 다음과 같이 조건을 일정하게 유지합니다.
- 평가 기간에는 데이터셋을 고정합니다.
- 스키마와 전처리 기준을 동일하게 유지합니다.
- 프로젝트팀이 평가에 필요한 데이터에 접근할 수 있도록 합니다.
- 코드와 필드 정의를 한 팀에서 조율합니다.
- 예외 사례는 사람이 직접 확인하고 보완합니다.
이처럼 조건을 통제해야 모델의 가능성을 정확하게 평가할 수 있습니다. 그러나 실제 운영 환경에서는 데이터와 시스템, 업무 조건이 계속 달라집니다.
따라서 PoC 점수는 정해진 조건에서 모델이 목표 성능을 냈다는 증거입니다. 데이터 상태가 계속 달라지는 운영 환경에서도 같은 결과를 낸다는 의미는 아닙니다. Google Research의 언더스펙 연구에서도 같은 테스트 성능을 보인 모델이 배포 환경에서는 서로 다른 결과를 낼 수 있다고 설명합니다.
배포 후 놓치기 쉬운 네 가지 변화
1. 데이터 범위가 계속 이동합니다
최근 12개월의 데이터를 사용하는 모델은 매일 조금씩 다른 데이터를 읽습니다. 새로운 고객과 거래가 추가되는 동안 오래된 사례는 분석 범위에서 빠집니다. 계절이나 지역, 고객 구성의 변화도 입력 데이터에 반영됩니다.
따라서 쿼리와 모델이 같아도 입력 데이터의 분포는 달라질 수 있습니다.
2. 스키마가 바뀝니다
컬럼의 이름이 바뀌거나 하나의 컬럼이 여러 개로 나뉘고, 자료형과 단위가 수정되기도 합니다. 데이터팀에는 일상적인 마이그레이션이지만 모델의 관점에서는 입력 규칙이 달라진 것입니다.
기존 컬럼에 기본값을 남겨두면 파이프라인은 오류 없이 작동할 수 있습니다. 이 경우 결과가 달라진 뒤에야 스키마 변경의 영향을 발견하기도 합니다.
3. 전처리 방식이 바뀝니다
결측값 처리 방식이나 스케일링, 범주형 데이터의 인코딩 기준이 달라질 수 있습니다. RAG에서는 토크나이저와 문서 청크 기준의 변경도 입력에 영향을 줍니다.
원본 데이터가 같아도 모델이 실제로 읽는 값과 맥락은 달라질 수 있습니다.
4. 권한과 참조 정보가 바뀝니다
사용자의 역할과 권한에 따라 접근할 수 있는 문서가 달라집니다. 규정과 가격표, 코드표 같은 참조 정보도 계속 갱신됩니다.
같은 질문이라도 실행 시점과 사용자에 따라 모델이 읽는 근거가 달라질 수 있습니다.
이러한 변화는 모델 버전만 살펴봐서는 알기 어렵습니다. 모델은 그대로여도 AI가 작동하는 데이터와 실행 조건은 이미 달라진 것입니다.
AI 결과가 달라지면 모델부터 의심하는 이유
문제가 발생하면 팀은 먼저 운영 화면에서 이상 징후를 찾습니다. 그런데 이 화면에서 바로 확인할 수 있는 정보는 대부분 모델과 관련된 지표입니다. 모델 버전과 응답 시간, 오류율, 출력 지표는 한곳에서 볼 수 있지만 실행 당시의 데이터 상태는 여러 시스템에 흩어져 있습니다. 결국 눈에 보이는 모델부터 원인을 찾게 됩니다.
관리 주체가 여러 조직에 나뉘어 있는 것도 이유입니다. 모델은 AI팀, 스키마와 파이프라인은 데이터팀, 접근 권한은 보안 조직, 업무 기준은 현업이 관리합니다. 각 조직의 기록이 정확하더라도 실제 AI 실행과 연결돼 있지 않으면, 원인을 찾기 위해 여러 시스템의 기록을 일일이 대조해야 합니다. AI 결과를 재현하기 위해 모델 버전 외에 무엇을 기록해야 하는지는 모델 버전 관리의 한계에서 더 자세히 확인할 수 있습니다.
같은 결과에 영향을 주는 변화라도 관리 방식은 다릅니다. 모델을 바꾸면 ‘배포’로 관리하지만 스키마 정리와 코드표 갱신, 전처리 수정은 일상적인 운영 업무로 처리합니다. AI 결과를 바꿀 수 있는 변화인데도 별도의 릴리스로 검토하거나 기록하지 않는 경우가 많습니다.
RAND의 2024년 연구는 숙련된 데이터 과학자와 엔지니어 65명을 인터뷰해 AI 프로젝트가 실패하는 원인을 분석했습니다. 연구에서는 필요한 데이터의 부족과 데이터 관리 인프라 문제를 주요 원인으로 꼽았는데요. 연구가 인용한 80% 이상의 실패율은 일부 추정치로, 모든 AI 프로젝트에 그대로 적용할 수 있는 확정적인 수치는 아닙니다. 다만 AI 프로젝트가 모델 자체가 아닌 데이터와 이를 관리하는 환경의 문제로도 멈출 수 있다는 점은 분명합니다.
AI 결과가 달라졌다면 원인을 어떻게 찾을까요?
AI 결과가 달라졌다면 모델을 수정하기 전에 다음 순서로 원인을 살펴보세요.
- 문제가 발생한 실행을 찾습니다. 실행 ID(Run ID)와 실행 시각, 요청 내용, 결과를 기록합니다.
- 문제가 없었던 가장 최근 실행을 찾습니다. 업무와 사용자 조건이 가장 비슷한 실행을 비교 대상으로 정합니다.
- 모델과 프롬프트를 비교합니다. 버전과 구성 변경 여부를 확인합니다.
- 데이터 상태를 비교합니다. 데이터 상태 Diff를 사용해 데이터 범위와 스키마, 전처리, 참조 정보, 권한 조건이 어떻게 달라졌는지 확인합니다.
- 문제가 발생했을 당시의 상태를 다시 구성합니다. 같은 모델과 실행 조건에서 동일한 결과가 나타나는지 확인합니다.
- 원인을 확인한 뒤 필요한 부분만 수정합니다. 데이터와 모델, 업무 규칙 가운데 결과에 영향을 준 항목을 찾아 조정합니다.
이 과정은 처음부터 모델이나 데이터를 원인으로 단정하지 않습니다. 모델과 데이터의 변화를 하나씩 나누어 살펴보면서 실제 원인을 찾는 것이 핵심입니다.
운영 단계에서 살펴볼 세 가지 기준
배포 후 문제를 일으킨 데이터도 사용 가능 여부와 무결성을 확인하는 검사는 통과했을 수 있습니다. 모델이 데이터를 정상적으로 읽고 값과 형식에도 문제가 없어 보이지만, 운영에서는 결과가 달라질 수 있습니다.
이때는 특히 다음 세 가지를 확인해야 합니다.
- 일관성: 실행이 달라져도 스키마와 전처리 방식, 데이터 범위를 같은 기준으로 관리하고 있나요?
- 재현성(Reproducibility): 과거 결과가 만들어졌을 당시의 데이터 상태와 실행 조건을 다시 구성할 수 있나요?
- 추적성: 각 실행에 사용된 데이터 상태를 찾고, 원천 데이터와 변경 이력까지 추적할 수 있나요?
공공기관의 RAG 시스템이라면 문서의 맥락도 함께 살펴봐야 합니다. 최신 문서를 검색했더라도 시행일이나 적용 대상이 빠져 있으면 해당 내용을 잘못 적용할 수 있습니다..
업무 분야별로 살펴보는 PoC 이후의 변화
분야마다 사용하는 데이터는 다르지만 공통점은 같습니다. 운영 중 데이터와 실행 조건이 달라졌는데도 그 변화가 실제 AI 실행과 연결해 기록되지 않으면, 결과가 달라진 원인을 찾기 어렵습니다.
PoC를 운영으로 전환하기 전에 살펴볼 여섯 가지 질문
- PoC에서 검증한 데이터 범위와 스키마, 전처리 조건이 기록돼 있나요?
- 각 운영 실행에 사용된 데이터 상태를 런 바인딩으로 찾을 수 있나요?
- 스키마나 전처리 방식이 바뀌면 해당 변경이 AI 결과에 미치는 영향을 검토하나요?
- 참조 정보와 권한 조건의 버전이 실행 기록에 함께 남아 있나요?
- 결과가 예상대로 나온 실행과 문제가 생긴 실행의 데이터 상태를 Diff로 비교할 수 있나요?
- 담당자의 기억에 의존하지 않고 Reproduce로 과거 실행 조건을 다시 구성할 수 있나요?
PoC에서 모델 성능이 기준을 충족했더라도 이 질문에 답할 수 없다면, 운영 중 결과가 달라졌을 때 어떤 데이터와 처리 조건이 영향을 미쳤는지 파악하기 어렵습니다.
운영 전환 전 조직별로 확인할 사항
PoC에서 기대한 결과가 나왔다고 바로 운영 적용을 결정할 수 있는 것은 아닙니다. 기술팀이 확인한 모델 성능과 데이터 조건을 거버넌스·보안·인프라·감사·사업관리 담당자도 같은 실행 ID와 관련 기록을 바탕으로 살펴볼 수 있어야 합니다.
- AI·데이터팀: PoC와 운영 단계에서 모델과 프롬프트, 데이터 상태가 어떻게 달라졌는지 비교하고 어떤 변화가 결과에 영향을 미쳤는지 분석합니다.
- 데이터 거버넌스·보안: 데이터의 사용 목적과 출처, 버전, 가공 과정은 물론 누가 어떤 범위까지 접근할 수 있는지 점검합니다.
- 운영·감사·검수: PoC와 운영 실행에 연결된 릴리즈 상태를 비교합니다. 데이터 범위와 스키마, 전처리 방식, 참조 정보, 권한 조건의 차이와 변경 승인 기록을 바탕으로 결과가 만들어진 당시의 조건을 살펴봅니다.
- 인프라·조달: 기존 데이터 플랫폼 및 MLOps와의 연계 방식, 내부망·온프레미스·클라우드에서 데이터가 처리되는 위치, 기록 보존 범위와 담당 조직을 배포·검수 문서에 명시합니다.
여러 조직이 같은 실행 ID와 관련 기록을 살펴볼 수 있어야 무엇이 결과 변화의 원인인지 함께 판단할 수 있습니다. 다만 이러한 기록은 원인 조사와 검수를 위한 자료이며, 정책 승인이나 규제 준수 여부에 대한 판단을 대신하지는 않습니다.
Syntitan으로 PoC와 운영의 데이터 상태를 비교하는 방법
Syntitan은 기업 데이터의 AI-Readiness를 여섯 축으로 진단하고, 부족한 부분을 개선한 뒤 실제 모델과 업무 지표를 기준으로 데이터의 활용 가능성을 검증하는 AI-Ready Data Platform입니다.
검증을 마친 데이터 상태는 릴리즈 상태로 관리하고, 각 AI 또는 에이전트 실행을 당시 사용한 릴리즈 상태와 연결합니다. PoC와 운영에서 결과가 달라졌다면 두 실행에 연결된 데이터 상태를 Diff해 데이터 범위와 스키마, 전처리, 참조 정보, 권한 조건이 어떻게 달라졌는지 비교할 수 있습니다.
필요한 경우 Reproduce 기능을 사용해 이전 실행의 데이터 상태와 처리 조건을 다시 구성하고, 확인된 변화가 결과에 어떤 영향을 미쳤는지 살펴볼 수 있습니다. PoC와 운영의 차이를 설명하려면 같은 모델을 사용했는지만 볼 것이 아니라, 각 실행에 어떤 데이터와 처리 조건이 연결됐는지 확인해야 합니다.
