5.7 ML 재현성과 감사 시점
지난달 모델 평가 결과를 다시 설명하려면 당시 사용한 데이터를 식별해야 합니다. 현재 테이블에서 같은 쿼리를 실행했다는 사실만으로 입력이 같다고 판단하기는 어렵습니다. 감사 조사에서도 보고서 생성 당시의 데이터를 확인하는 요구를 구분해야 합니다. 조사자가 데이터를 수정하며 가설을 시험하는 요구와 나누어야 합니다. 이 장에서는 데이터 기준점을 고정한 뒤 실험과 조사에 제공하는 절차를 다룹니다.
재현 기록과 감사 증적은 보존 목적이 다릅니다. 실험 기록에는 어떤 입력과 실행 조건에서 결과를 얻었는지가 필요합니다. 감사 증적에는 데이터 출처, 보존 책임, 접근과 변경 이력까지 요구됩니다. 아래 절차는 운영 정책 제안입니다. 특정 규제 요건을 충족한다는 판정으로 사용하지 않습니다. 규제 요건 충족을 입증한 고객 사례는 이번 조사에서 미확인입니다.
적용 계층과 제품
Turbine은 2021년 검증과 전환을 거쳐 Dolt를 production에 사용한 사례입니다. 여러 팀이 branch, diff, 머지를 사용해 시뮬레이션 데이터를 관리합니다. 특정 commit을 기준으로 시뮬레이션과 모델 학습을 실행합니다. 사례 신뢰도는 보통입니다. 구체적인 사용 흐름을 설명한 공급사 자료입니다. 독립적인 재현성 감사 결과로 해석하지 않습니다. Turbine 사례가 공개 도입의 근거입니다.
Dolt의 branch와 commit은 역할을 구분합니다. 이 장의 운영 제안에서는 작업을 이어 갈 이름으로 branch를 사용합니다. 특정 학습 입력을 식별하는 값으로는 commit 식별자를 기록합니다. 여러 팀이 데이터를 수정하는 동안에도 실험이 참조한 기준점을 명시하기 위한 구분입니다. branch를 만드는 절차와 diff 및 머지 실습은 Dolt와 Doltgres에 연결합니다.
Dolt의 Prolly tree는 변경하지 않은 구조를 공유해 데이터 버전 관리를 구현합니다. 구조를 공유해도 학습 쿼리의 compute 비용을 보장하지는 않습니다. 모든 모델 결과의 동일성도 보장 범위에 포함되지 않습니다. 이 장에서는 데이터 버전의 고정이라는 역할에 한정합니다. 코드, 전처리와 모델 설정을 기록하는 절차는 이 기능에 더한 운영 정책 제안입니다.
Snowflake는 테이블, schema와 database의 clone을 제공합니다. 과거 시점 clone도 제공합니다. 과거 시점 선택에는 Time Travel 보존 조건이 적용됩니다. 조사 시점에 원하는 과거 상태가 남아 있는지부터 확인해야 합니다. Fast Clone 설명과 객체별 clone 조건을 함께 참고합니다. 조회 대상의 기준 시점과 clone을 생성한 시각도 구분해 기록합니다.
Snowflake clone을 환경 전체의 동일한 사본으로 간주하지 않습니다. database와 schema의 하위 객체 권한 및 container 권한은 규칙이 다릅니다. 외부 객체 참조가 남는 경우도 있습니다. 따라서 감사 조회를 준비할 때 데이터 객체 목록과 접근 역할을 별도로 확인합니다. 원본과 같은 범위를 조회했는지 판정하려면 clone의 이름 외에 이 조건도 확인해야 합니다.
운영 DB에 주는 부하
ML 입력을 고정해도 학습 데이터 읽기는 실행 자원을 사용합니다. Turbine 사례에서도 특정 commit의 데이터를 읽는 시뮬레이션 작업을 설명합니다. 운영 평가에서는 학습 작업의 동시 수와 추출 쿼리 시간을 기록합니다. DB CPU와 저장소 읽기도 기록합니다. commit 생성이나 branch 생성의 시간만으로 학습 플랫폼 전체의 수용량을 계산하지 않습니다.
Dolt를 production 데이터 저장소와 학습 입력 저장소로 함께 쓰는 구성도 있습니다. 이 구성이라면 대표 학습 쿼리를 운영 트래픽과 겹쳐 시험하도록 제안합니다. 여러 모델이 동일한 데이터를 반복해서 읽는 경우를 관찰합니다. 서로 다른 데이터 버전을 읽는 경우와 나누어 관찰합니다. 기준 데이터의 공유 구조와 실행 자원의 공유 범위를 별도로 기록합니다. 모델 실행 대기열의 동시 수는 측정 결과에 맞춰 조정합니다.
데이터 버전 보존 비용도 실행 비용과 나누어 관리합니다. PostgreSQL의 WAL 보존 기간을 Dolt commit 보존 정책으로 그대로 옮기지 않습니다. 보존할 commit과 해당 데이터를 계속 제공하는 저장소의 운영 책임을 정합니다. 재현 검증에는 과거 실험의 식별자와 함께 데이터를 다시 조회할 수 있는지 확인하는 절차가 필요합니다.
Snowflake의 clone은 초기 데이터 참조를 공유합니다. 원본과 clone의 변경 및 과거 데이터 보존에 따른 저장 비용은 남습니다. 저장 공간 문서에 근거해 초기 복사량과 장기 유지량을 구분합니다. 조사용 clone의 warehouse 실행과 저장량을 함께 관찰합니다. 쿼리 실행을 중단한 상태와 데이터 보존을 종료한 상태도 구분합니다.
장기 조사에서는 원본의 갱신량이 큰 기간을 비용 시험에 포함합니다. 조사 clone이 쓰기를 하지 않아도 추가 유지량이 없다고 보고 예산을 정하지 않습니다. 월말 대조 작업처럼 큰 범위를 반복해서 읽는 일정도 실행 비용에 포함합니다. 비용 보고에는 활성 실험, 결과 재검토용 데이터와 감사 보존 데이터를 나누어 표시합니다. 각 범주의 종료 조건도 연결합니다.
흔한 실패
ML 실험의 첫 실패 가설은 움직이는 branch 이름만 저장하는 경우입니다. 실험을 시작할 때 기준 commit 식별자를 확정합니다. 실행이 그 값을 사용했는지도 검증합니다. 모델 실행 중간에 최신 데이터로 재연결하는 경로도 검사합니다. 학습 입력 일부를 외부 파일에서 읽는다면 그 파일의 버전과 추출 시각을 함께 기록합니다. Dolt의 데이터 버전이 외부 파일까지 자동으로 고정한다고 가정하지 않습니다.
두 번째는 데이터가 같으면 학습 결과도 같다고 판정하는 경우입니다. 이 장에서는 재현성의 합격 조건을 운영자가 먼저 정의하도록 제안합니다. 입력 행 집합의 일치, 전처리 결과의 일치, 평가 지표의 허용 차이를 각각 구분합니다. 코드 버전, 모델 설정, 라이브러리 환경과 난수 설정을 기록합니다. 필요한 재실행에서 이 기록을 대조합니다. 공급사의 고객 사례에 나타난 재현성 표현을 모든 학습 환경에 대한 보장으로 확대하지 않습니다.
감사 용도에서는 쓰기 가능한 clone을 변경 불가능한 증적으로 간주하는 실패를 경계합니다. 조사자가 보조 테이블을 만들거나 행을 수정하는 환경을 구분합니다. 최초 확보 데이터를 보존하는 환경과 분리하도록 제안합니다. 이름에 audit가 들어갔다는 사실은 변경 방지의 근거가 아닙니다. 쓰기 권한, 권한 변경 권한, 삭제 권한과 접근 기록의 상태를 확인해야 합니다.
증적 보존 절차에는 읽기 전용 계정 제공 외의 조치도 필요합니다. 상위 관리자가 권한을 변경하거나 데이터를 삭제할 때의 처리 방법도 정합니다. 별도 증적 저장소에는 확보한 자료, 데이터 출처와 검증 결과를 묶어 보존합니다. 조사 DB의 변경과 구분해 추적합니다. 이 설계의 적합성은 조직의 감사 목적에 맞춰 검토합니다. 제품 기능 하나로 규정 준수를 선언하지 않습니다.
기준 시점을 너무 늦게 확보하는 상황도 시험해야 합니다. Snowflake의 과거 clone은 보존 조건을 따릅니다. 조사 요청 시점에 필요한 이력이 남아 있는지 확인합니다. 운영 정책에서는 정기 보존 대상과 사건 발생 후 보존 대상을 나눕니다. 요청 접수부터 확보까지의 담당자와 처리 시간도 정합니다. 보존 기간이 지난 데이터의 복구 가능성은 별도 근거 없이 약속하지 않습니다.
운영 정책 제안
ML 환경은 ml-실험번호로 식별하도록 제안합니다. 감사 조회 환경은 audit-사건번호-기준시점으로 식별하도록 제안합니다. 공통 기록에는 데이터 출처, 기준 commit 또는 시점, 생성 시각을 넣습니다. 소유자, 접근 역할과 만료 시각도 넣습니다. 시각에는 시간대도 명시합니다. 실험과 감사의 식별자가 같더라도 권한과 삭제 정책은 구분해야 합니다. 같은 값으로 자동 설정하지 않도록 관리 양식을 구분합니다.
실험 실행 기록에는 코드 commit과 데이터 commit을 함께 남기도록 제안합니다. 전처리 쿼리의 버전, 입력 범위와 모델 설정도 함께 남기도록 제안합니다. 실행 결과에는 평가 지표와 로그의 저장 위치를 연결합니다. 실행 재시도에는 새 시도 번호를 부여하고 이전 결과를 보존합니다. 데이터가 달라진 재실행을 같은 입력의 재현 성공으로 계산하지 않도록 비교 기준도 기록합니다.
재현 점검은 다른 담당자가 저장한 기록만으로 입력을 준비하고 실행을 시작하는 절차로 설계합니다. 필요한 데이터가 남아 있는지 확인합니다. 접속 권한을 다시 발급할 담당자가 있는지, 외부 파일이 식별 가능한지도 확인합니다. 학습을 전부 반복할지 작은 범위의 입력 검증으로 충분한지는 실험 중요도에 따라 정합니다. 점검 실패 시에는 빠진 항목과 복구 예정일을 남겨 추적하도록 제안합니다.
감사 보존에서는 조사자가 수정하는 작업 사본과 보존 담당자가 관리하는 최초 자료를 분리합니다. 확보 시점, 대상 객체 목록, 추출 조건, 검증 값과 접근 기록을 연결하도록 제안합니다. 조회 쿼리 자체를 보존하면 어떤 조건으로 결과를 얻었는지 대조하는 데 도움이 됩니다. 보고서의 숫자와 함께 결과를 생성한 데이터 기준점과 쿼리 버전을 보존합니다.
삭제 정책은 실험 종료와 감사 종료를 별도 사건으로 취급하도록 제안합니다. 임시 실험 compute는 실행 종료 후 정리합니다. 재현에 필요한 데이터 버전은 합의한 기간 동안 보존합니다. 감사 보존 대상은 담당자의 해제 승인 이후 삭제 단계로 넘깁니다. 무기한 보존을 기본값으로 삼지 않고, 종료일과 연장 사유를 주기적으로 검토합니다. 보존 연장은 데이터 내용에 대한 접근 권한 확대와 분리합니다.
민감 데이터 삭제 요청과 실험 재현 요구가 충돌하면 보존 책임자에게 판단을 넘기도록 제안합니다. 이를 위한 절차를 마련합니다. 승인된 삭제 이후 재현 범위가 달라지면 해당 실험 기록에도 표시합니다. 예전 결과를 그대로 다시 계산한다고 약속하지 않습니다. 삭제 작업에는 작업 DB, 추출 파일, 별도 증적과 보존 이력의 처리 범위를 명시합니다. 남은 항목이 있으면 사유와 책임자를 기록합니다.
도식
아래는 데이터 기준점에서 실험과 감사를 분리하는 정책 제안입니다. Dolt commit과 Snowflake 시점 clone은 저장 형식을 구분해 표현합니다. 두 경로에서 공통으로 요구하는 것은 기준점의 식별과 보존 책임의 기록입니다. 감사 작업 사본에는 분석을 위한 쓰기를 허용하더라도 별도 증적의 변경 권한은 부여하지 않습니다. 아래 도식은 이 구성을 보여 줍니다.
운영 도입 시에는 이 그림의 보존 검토 단계에서 삭제 대상 목록을 만드는지 확인합니다. 실험 번호나 사건 번호만으로 관련 자원을 찾지 못한다면 식별 관계를 보완합니다. 추출 파일과 작업 사본까지 추적하도록 보완합니다. 종료 보고에는 삭제 완료 항목을 남깁니다. 승인에 따라 남긴 항목의 다음 검토 날짜도 함께 남깁니다.