안녕하세요. 기업 데이터가 AI 업무에 실제로 활용될 수 있도록 돕는 큐빅(CUBIG)입니다.
AI를 실제 업무에 적용하면 예상과 다른 결과가 나왔을 때 그 원인을 설명할 수 있어야 합니다. 운영팀은 먼저 모델 버전과 프롬프트, 실행 로그를 살펴보고, 여기서 단서를 찾지 못하면 데이터 파이프라인과 입력 문서로 점검 범위를 넓히게 됩니다.
하지만 실행 시각과 오류 코드만 남아 있고 당시 사용한 데이터 범위와 버전, 처리 조건이 결과와 연결되어 있지 않다면 원인을 좁히기 어렵습니다. 예상한 결과가 나온 실행과 결과가 달라진 실행에 각각 어떤 데이터가 사용됐는지 비교할 수 없기 때문인데요.
결과가 달라진 이유를 설명하려면 모델 정보뿐 아니라 당시 사용한 데이터 범위와 처리 조건도 함께 남겨두는 편이 좋습니다. 런 바인딩(Run Binding)은 AI 또는 에이전트의 실행 결과를 당시 사용한 데이터 상태와 연결해 기록하는 방식입니다.
AI를 운영 환경에 적용할지 검토할 때는 AI·데이터팀뿐 아니라 데이터 거버넌스, 감사, 사고 대응 담당자도 같은 근거를 살펴볼 수 있어야 합니다. 실행 ID(Run ID)와 릴리즈 상태(Release State)를 연결하고 접근 주체, 중간 단계, 결과물, 재실행 이력까지 남기면 기술팀 밖에서도 결과가 만들어진 과정을 검토할 수 있습니다.
AI 결과와 데이터 상태를 연결해야 하는 이유
런 바인딩은 AI 결과를 해당 실행에 사용된 모델 설정 및 릴리즈 상태와 연결해 하나의 기록으로 남깁니다.
릴리즈 상태는 특정 시점에 사용된 데이터 범위와 스키마, 전처리 조건, 참조 정보를 하나로 묶어 고정하는데요. 런 바인딩은 AI 결과마다 어떤 릴리즈 상태가 사용됐는지 보여줍니다.
AI 결과와 데이터 상태를 연결해 두면 다음 항목을 바로 파악할 수 있습니다.
- 어떤 모델과 프롬프트가 사용됐나요?
- 입력에는 어떤 데이터와 문서가 포함됐나요?
- 당시 스키마와 전처리 조건은 무엇이었나요?
- 예상한 결과가 나온 실행과 결과가 달라진 실행 사이에서 무엇이 바뀌었나요?
- 과거 데이터 상태를 다시 구성해 결과를 재현할 수 있나요?
데이터 상태를 저장하는 것만으로는 충분하지 않습니다. 어떤 데이터 사본이 실제 AI 실행에 사용됐는지 알 수 없으면 결과가 나온 조건도 정확히 파악하기 어렵습니다. 런 바인딩은 실행 ID를 기준으로 AI 결과와 당시 사용한 데이터 상태를 연결합니다.
AI 결과와 데이터 상태를 연결하면 결과가 달라진 원인을 추적할 기준이 생깁니다. 이 기준을 실제 조사에 활용하려면 실행마다 어떤 정보를 함께 남길지도 정해두는 편이 좋습니다.
AI 실행과 함께 기록해야 할 정보
기록 항목의 수보다 중요한 것은 AI 결과와 모델·데이터 상태가 끊김 없이 연결되는지입니다. AI 결과 하나를 기준으로 당시 사용한 모델과 데이터 상태를 바로 추적할 수 있어야 합니다.
모델 버전 기록만으로 부족한 이유
MLflow Model Registry와 같은 모델 레지스트리는 모델 버전과 배포 상태, 관련 메타데이터를 관리합니다. 이를 통해 어떤 모델 버전이 운영에 사용됐는지 추적할 수 있습니다.
다만 같은 모델 버전도 서로 다른 데이터 상태에서 실행될 수 있습니다.
예를 들어 모델 v3.1이 한 달 동안 유지되는 동안 다음 항목은 계속 바뀔 수 있습니다.
- 거래 데이터의 조회 기간
- 규정 문서와 검색 인덱스
- 고객 상태 코드와 제품 분류
- 결측값 대체 방식
- 도구 호출 결과와 에이전트 접근 권한
하지만 모델 버전만 기록하면 한 달 동안 생성된 서로 다른 결과가 모두 v3.1로 표시돼, 각 결과가 어떤 데이터 상태에서 만들어졌는지 구분하기 어렵습니다. 런 바인딩은 AI 결과마다 해당 실행에 사용된 릴리즈 상태를 연결해 이러한 빈틈을 보완합니다.
결과가 달라진 원인을 추적하려면 모델 버전과 실행 당시의 데이터 상태를 함께 살펴봐야 합니다.
실행 로그만으로 데이터 상태를 알기 어려운 이유
실행 로그는 AI가 언제 실행됐고 시스템에서 어떤 일이 발생했는지 보여주는데요. 응답 시간과 오류 코드, 사용자 요청, 도구 호출 등을 확인할 수 있어 장애 원인을 조사할 때 유용합니다.
다만 데이터 쿼리나 문서 ID가 로그에 남아 있더라도 원본 데이터가 이후 수정됐다면, 실행 당시의 입력 내용을 그대로 파악하기 어렵습니다. 같은 쿼리를 다시 실행해도 조회되는 행이나 참조 문서가 달라질 수 있기 때문입니다.
런 바인딩은 실행 로그를 대체하지 않고, 로그만으로 확인하기 어려운 데이터 상태를 보완합니다. 해당 실행에 사용된 릴리즈 상태의 식별자를 로그와 연결하면 당시 입력 조건을 더 구체적으로 추적할 수 있게 됩니다.
여러 담당자가 하나의 AI 결과를 검토하는 업무에서는 데이터 상태를 실행과 연결한 기록이 더 중요합니다.
공공기관의 AI 판단 근거를 다시 확인하는 방법
공공기관에서 AI 기반 시스템이 민원을 분류하고 담당 부서를 추천하는 상황을 가정해 보겠습니다. 세 달 뒤 민원인이 분류 근거를 요청했지만, 그사이 업무 지침이 개정되고 부서 코드도 바뀌었습니다. 모델 버전과 결과 로그만 남아 있다면 당시 시스템이 어떤 지침과 코드를 참조했는지 파악하기 어렵습니다.
현재 지침과 부서 코드를 기준으로 과거 결과를 해석하면 당시와 다른 판단 조건을 적용할 수 있습니다. 반면 실행 ID가 당시의 릴리즈 상태와 연결돼 있으면 다음 순서로 근거를 추적할 수 있습니다.
- 해당 민원 처리의 실행 ID를 찾습니다.
- 연결된 데이터와 지침의 릴리즈 상태를 불러옵니다.
- 당시 시행 중인 문서와 부서 코드를 확인합니다.
- 동일 조건으로 결과를 다시 실행합니다.
- 현재 상태와 비교해 무엇이 바뀌었는지 설명합니다.
결과의 근거를 되짚으려면 모델 정보뿐 아니라 배포 이후 발생한 데이터 변경과 사고 대응 기록도 함께 관리해야 합니다. NIST AI RMF Playbook도 AI 시스템의 성능 변화와 데이터 수정, 사고 대응 과정을 문서화하도록 안내하고 있는데요. 런 바인딩은 이러한 기록을 보완해 각 AI 실행과 당시 사용한 데이터 상태를 함께 검토할 수 있도록 합니다.
에이전트 업무에서 더 많은 기록이 필요한 이유
일반적인 모델 실행은 입력을 받아 결과를 생성하는 한 번의 처리로 끝나는 경우가 많습니다. 반면 에이전트는 데이터를 읽고 도구를 호출한 뒤, 반환된 결과를 바탕으로 다음 판단과 작업을 이어갑니다.
에이전트 업무에서는 최종 응답뿐 아니라 판단에 영향을 준 중간 과정도 실행 기록과 연결해 두는 편이 좋습니다.
- 최초 요청과 검색된 문서
- 각 도구가 반환한 데이터
- 단계별 권한과 사용 조건
- 에이전트가 선택한 후속 작업
- 최종 산출물과 사람의 검토 여부
최종 응답만 남기면 어느 과정에서 데이터가 달라졌는지 파악하기 어렵습니다. 검색 결과와 도구 호출 결과, 권한 변경처럼 판단에 영향을 준 정보도 함께 연결해 두면 원인을 좁히기 쉽습니다.
런 바인딩으로 사고 조사 범위를 좁히는 방법
런 바인딩이 없으면 담당자는 모델과 프롬프트, 파이프라인, 데이터의 변경 이력을 여러 시스템에서 따로 찾아 연결해야 하는데요. 살펴볼 시스템이 늘어날수록 원인을 좁히는 데도 시간이 더 걸립니다.
런 바인딩이 있다면 결과가 달라졌을 때 모델부터 교체하지 않고, 비교 기준이 되는 실행과 결과가 달라진 실행에 연결된 데이터 상태를 먼저 대조할 수 있습니다.
- 마지막으로 기대한 범위의 결과를 낸 실행과 결과가 달라진 실행을 선택합니다.
- 두 실행에 연결된 릴리즈 상태를 확인합니다.
- 스키마와 데이터 분포, 전처리 조건, 참조 정보가 어떻게 달라졌는지 비교합니다.
- 결과에 영향을 미쳤을 가능성이 큰 원천 데이터와 전처리·변환 이력을 추적합니다.
- 필요한 경우 이전 실행에 사용된 데이터 상태를 다시 구성해 원인을 검증합니다.
이 과정을 거치면 모델을 다시 학습하기 전에 결과 변화가 데이터 상태에서 비롯됐는지 판단할 수 있습니다.
여기서 중요한 것은 기록의 양이 아니라 연결 관계입니다. 실행 로그가 많더라도 AI 결과와 당시 사용한 데이터 상태가 식별자로 연결돼 있지 않다면 런 바인딩으로 보기 어렵습니다. 기존 관리 기록과 런 바인딩의 역할을 구분해 필요한 정보를 빠짐없이 남겨야 합니다.
런 바인딩과 기존 데이터 관리 방식의 차이
데이터 카탈로그: 위치와 소유자 관리
데이터 카탈로그는 어떤 데이터가 어디에 있고 누가 관리하는지 보여줍니다. 반면 런 바인딩은 특정 AI 실행에 실제로 사용된 데이터 상태를 결과와 연결합니다.
백업: 복구용 데이터 보관
백업은 장애나 데이터 손실에 대비해 복구할 사본을 보관합니다. 런 바인딩은 사본 자체가 아니라 AI 결과와 당시 사용된 데이터 상태 사이의 관계를 기록합니다.
모니터링: 성능과 오류 변화 탐지
모니터링은 성능 저하나 오류 발생을 감지하는 데 초점을 둡니다. 런 바인딩은 결과가 달라진 실행에 어떤 데이터 상태가 사용됐는지 비교하고 변화 원인을 추적할 기준을 제공합니다.
데이터 복제: 환경에 따른 보존 범위 결정
모든 데이터를 무조건 복제할 필요는 없습니다. 데이터 환경과 운영 요건에 맞춰 AI가 실제로 사용한 데이터 상태를 식별하고, 필요할 때 당시 조건을 다시 구성할 수 있는 연결을 유지하는 것이 중요합니다.
AI 결과가 만들어진 과정을 확인하는 여섯 가지 질문
실제 AI 결과 하나를 골라 다음 질문에 답해 보세요.
- 해당 결과를 식별할 실행 ID가 남아 있나요?
- 실행에 사용된 모델과 프롬프트, 도구 설정을 확인할 수 있나요?
- 결과에 사용된 데이터와 문서의 당시 상태를 확인할 수 있나요?
- 현재 데이터가 달라졌더라도 당시 데이터 상태를 다시 구성할 수 있나요?
- 두 실행의 데이터 상태를 비교해 무엇이 달라졌는지 설명할 수 있나요?
- 다른 담당자나 팀도 같은 기록을 바탕으로 결과가 만들어진 과정을 확인할 수 있나요?
두 항목 이상 답하기 어렵다면 실행 로그가 남아 있더라도 AI 결과와 당시 데이터 상태를 연결하는 기록이 충분하지 않을 수 있습니다.
AI 운영 전 담당 조직별로 정할 사항
PoC에서 좋은 결과를 얻었더라도 같은 조건이 운영 환경에서 그대로 유지된다고 보기는 어렵습니다. 기술팀뿐 아니라 데이터 거버넌스, 보안, 인프라, 감사, 사업 담당자도 같은 실행 기록을 바탕으로 결과와 변경 사항을 검토할 수 있어야 합니다.
- AI·데이터팀: 실제 사용 사례와 목표 지표를 기준으로 데이터가 AI 업무에 적합한지 검증하고, 결과가 달라졌을 때 비교할 기준을 정합니다.
- 데이터 거버넌스·보안: 데이터의 사용 목적과 출처, 버전, 전처리·변환 과정, 접근 주체와 허용 범위를 기록합니다.
- 운영·감사·검수: 실행 ID와 릴리즈 상태 ID를 연결하고, 접근 주체와 중간 결과물, 재실행·재현 기록을 남깁니다. 결과 변화가 발생하면 두 실행의 데이터 상태와 처리 조건을 비교합니다.
- 인프라·조달: 기존 데이터 플랫폼과 MLOps의 연계 방식, 온프레미스·클라우드별 처리 위치, 데이터 보존 범위와 담당 조직을 배포·검수 문서에 명시합니다.
Syntitan은 AI 실행과 데이터 상태를 어떻게 연결할까요?
Syntitan은 기업 데이터가 AI 업무에 필요한 조건을 갖췄는지 진단하고, 부족한 항목을 개선한 뒤 실제 모델과 업무 지표를 기준으로 결과를 검증합니다. 검증을 마친 데이터 상태는 릴리즈 상태로 기록하고, 런 바인딩을 통해 AI 또는 에이전트 실행 결과와 연결합니다.
예상한 결과가 나온 실행과 결과가 달라진 실행에 연결된 데이터 상태를 비교하면 스키마와 전처리 조건, 참조 정보 가운데 무엇이 달라졌는지 파악할 수 있습니다. 필요한 경우 이전 실행에 사용된 데이터 상태를 다시 구성해 결과가 달라진 원인도 검증할 수 있습니다.
모델 버전은 어떤 모델이 실행됐는지를 보여줍니다. 런 바인딩은 해당 모델이 어떤 데이터 상태에서 결과를 만들었는지를 보여줍니다. 다만 런 바인딩은 결과가 만들어진 데이터 조건을 추적하는 기록으로, 정책 승인이나 컴플라이언스 판단을 대신하지는 않습니다.
