12.3.2 데이터 의존성(Data Dependency) 문제 해결: 정적 데이터 덤프와 동적 시딩

‘실행 결과 비교(Execution Result Comparison) 오라클’ 생태계를 엔터프라이즈 MLOps에 안착시킬 때 직면하게 되는 가장 잔혹하고 까다로운 소프트웨어 공학적 장애물은, 평가의 기준점 자체가 소스 코드(Source Code)가 아닌 데이터베이스 내부의 **물리적인 레코드 값(State)**에 종속된다는, 이른바 데이터 의존성(Data Dependency) 딜레마이다.

아주 단순한 사고실험을 해보자. 만약 오늘 아침 골든 데이터셋에 명시된 “이번 달 최고 실적 사원의 이름“에 대한 정답 쿼리를 실시간 DB에 실행했을 때 반환된 결과 텐서가 [Alice]였다고 가정하자. 그런데 내일 아침, Sales 테이블에 새로운 실적 데이터가 업데이트되었고, LLM이 어제와 똑같은 완벽한 정답 코드를 짜서 제출했다면 어떤 일이 벌어질까? 내일의 데이터베이스는 [Bob]을 뱉어낼 것이고, 멍청한 오라클 비교 엔진은 Bob != Alice라는 데이터 상태의 변화를 코드의 결함으로 오판하여 이 불쌍하고 무고한 AI 모델에게 가차 없이 0점(False)을 매겨버릴 것이다.

따라서 최고 수준의 오라클 시스템은 시스템이 오늘 평가를 하든 10년 뒤에 평가를 하든 무한히 벤치마크를 돌리더라도 언제나, 영원히 똑같은 결과 텐서를 도출할 수 있도록 **결정론적인 데이터 상태(Deterministic Data State)**를 샌드박스(Sandbox) 내부에 극도의 멱등성(Idempotency) 구조로 고정시켜 버려야만 한다. 이를 달성하기 위해 주로 다음 두 가지 인프라 기법이 동원된다.

1. 정적 데이터 덤프 (Static Data Dumps)의 스냅샷 박제화

가장 고전적이고 무겁지만, 수학적으로 가장 확고한 무결성을 지니는 방법이다.
이 기법은 인간 도메인 전문가가 골든 데이터셋의 질문과 정답 쿼리(golden_sql) 쌍을 작성하여 Git에 커밋 파일로 굳히는 바로 그 밀리초(ms) 단위의 찰나에, 평가 대상이 되는 프로덕션 데이터베이스의 특정 스키마 레코드 전체 상태를 .sql 덤프(Dump) 파일 형태로 떠서 영구 스냅샷화(Snapshot)하여 냉동 박제시켜 버리는 것이다.

이후 CI/CD 파이프라인에서 벤치마크가 수행될 때, 도커 샌드박스 컨테이너는 라이브 DB를 쳐다보는 것이 아니라, 이 Git LFS(Large File Storage)에 저장된 수 기가바이트(GB)의 ’화석화된 데이터 덤프’를 인메모리에 마운트하여 기동된다. 따라서 5년 뒤에 동일한 쿼리를 던지더라도 반환되는 텐서는 영원히 시간의 흐름을 박탈당한 채 동일한 값으로 고정된다. 이는 BIRD-SQL이나 Spider 등 예일과 알리바바가 주도하는 글로벌 Text-to-SQL 벤치마크들이 모델을 절대 평가할 때 가장 표준적으로 채택하는 확정적 상태 고정 기법이다.

2. 동적 시딩 (Dynamic Seeding)과 고정 시드(Fixed Seed) 주입

하지만 기업 환경에서는 딜레마가 발생한다. 금융 기관이나 헬스케어 도메인처럼 PII(개인식별정보), HIPPA 규제로 인해 프로덕션 망의 라이브 DB 덤프를 함부로 사내 테스트(CI/CD) 망으로 꺼내올 수 없는 폐쇄망 환경이라면 어떻게 해야 할까? 이때는 오라클 파이프라인이 구동될 때마다 동적 시딩(Dynamic Seeding), 즉 ’가상의 더미 데이터(Mock Data) 파종’을 프로그래밍적으로 수행해야만 한다.

동적 시딩 파이프라인은 파이썬의 Faker 객체나 가우시안 난수 생성기를 통해 더미 데이터를 생성해 내되, 그 과정에서 가장 핵심적인 공학적 트릭인 **‘고정된 시드 값(Fixed Random Seed, 예: random.seed(42))’**을 철저히 상속받아야 한다.
이렇게 시스템을 래핑 해두면, 매번 샌드박스 컨테이너가 뜰 때마다 0.1초 만에 수만 건의 가짜 고객 정보와 결제 내역 텐서를 즉석에서 생성하여 주입하지만, 우주의 진리인 난수 시드 값(Seed)이 42로 영구 고정되어 있기 때문에 수천 번 컨테이너를 부수고 다시 파종하더라도 생성된 그 가짜 데이터들의 테이블 간 참조 결합(Foreign Key) 망과 숫자 값은 단 1비트의 어긋남도 없이 완벽하게 복제되어 투사된다.

위대한 오라클 아키텍트는 이 두 가지 데이터 의존성 격리 기법(정적 덤프 vs 동적 시딩)을 자사의 보안 규정과 운영 스키마 볼륨에 정밀하게 저울질하여 결합함으로써, 평가 엔진 내부의 시간과 데이터 상태를 영원토록 멈추어 세우는 조물주의 위치에 설 수 있게 된다.