ML 시스템을 출시하기 전에 감사하는 방법

대부분의 ML 실패는 모델 자체의 실패가 아닙니다. 그것은 설계 실패입니다. 그리고 이는 어디를 봐야 할지 아는 사람이라면 누구나 출시 전에 거의 항상 발견할 수 있습니다.

트레이닝-서빙 스큐(Training-serving skew) 같은 문제, 아무도 확인하지 않았습니다. 프로덕션 환경과 일치하지 않는 평가 데이터셋이 있습니다. 다음 재학습 실행을 조용히 오염시킬 피드백 루프가 존재합니다. 비용 및 지연 시간 예산은 아무도 기록하지 않았습니다. 저는 완벽하게 좋은 모델을 가진 시스템들을 이런 문제들 때문에 실패하는 것을 목격했습니다. 19년 이상의 소프트웨어 배포 경험과 AI 연구 검토를 거치면서, 이제 저는 모든 ML 설계가 출시되기 전에 동일한 다섯 가지 게이트 감사 과정을 거치도록 합니다. 여기 그 과정이 있습니다.

게이트 1: 데이터 — 출처(provenance), 누수(leakage), 드리프트(drift)

세 가지 질문을 던지세요. 모든 트레이닝 예제는 어디에서 왔으며, 그것을 증명할 수 있습니까? 미래의 정보나 테스트 세트의 정보가 트레이닝에 유출될 가능성은 없었습니까? 그리고 실제 세계가 당신의 트레이닝 분포에서 벗어나면 어떻게 됩니까?

여기서 전형적인 치명적인 문제는 평가 누수(eval leakage)입니다. 평가 데이터셋이 실수로 트레이닝 데이터에서 추출되었기 때문에, '99% 정확도'를 자랑하던 분류기가 첫 실제 날에 실패하는 경우입니다. 이는 사람들이 인정하는 것보다 더 자주 발생합니다. 원활한 추가 사항이 아닌, 필수적인 병합 요구사항으로 서면 데이터 출처 증명서와 누수 점검을 요구하세요.

게이트 2: 평가 — 지표가 임무에 부합하는가?

모델은 지표(metric)에서는 최고일지라도 실제 업무 수행에는 실패할 수 있습니다. 오프라인 정확도는 프로덕션 결정이 서로 다른 오류에 대해 다른 비용을 갖는다면 아무 의미가 없습니다. 사기가 드문 경우, 정확도에 최적화된 사기 탐지 모델은 모든 것을 승인하는 데 만족할 것입니다.

모든 모델에 대해 다음 사항을 기록하세요: 이 모델이 실제로 구동하는 결정은 무엇인지, 각 방향의 실수가 비용으로 얼마가 발생하는지, 그리고 우리의 평가 데이터셋이 프로덕션 트래픽과 유사한지?
만약 답변들이 모호하다면, 설계는 준비되지 않은 것입니다.

게이트 3: 운영 — 지연 시간(latency), 비용, 폴백(fallback)

게이트 3: 운영 — 지연 시간(latency), 비용, 폴백(fallback)

최초의 사용자 불만이 터지기 전까지는 아무도 지연 시간 예산(latency budget)을 기록하지 않습니다. 최초의 클라우드 청구서가 나오기 전까지는 아무도 예측 비용을 책정하지 않습니다. 각 모델에 대해 다음 사항을 기록하세요: p95 지연 시간 예산, 예상 트래픽량 대비 1,000개 예측당 비용, 그리고 모델이 다운되거나 너무 느릴 때 무슨 일이 발생하는지입니다. '페이지가 깨지는 것'은 폴백 전략이 아닙니다. 마지막으로 잘 작동했던 예측을 캐싱하거나, 더 단순한 모델로 성능을 저하시키거나(degrade), 명시적이고 크게 실패하는 방법(fail open)을 사용해야 합니다.

에이전트 시스템의 경우 이 게이트가 10배 더 중요합니다. 불필요한 도구 호출 하나하나가 토큰을 소모할 뿐만 아니라, 모든 하위 컨텍스트 창(context window)을 부풀립니다. 비용 규율은 호출 규율에서 시작됩니다.

게이트 4: 보안 — 적대적 입력 및 접근 제어

누가 이 모델에 입력을 제공할 수 있으며, 그들이 모델로 무엇을 하도록 만들 수 있을까요? 기본 사항들을 다루세요: 입력 유효성 검사(input validation), 속도 제한(rate limiting), 모델 엔드포인트와 훈련 데이터에 대한 접근 제어입니다. LLM 기반 시스템의 경우 프롬프트 주입(prompt-injection) 검토를 추가하세요. 에이전트가 호출할 수 있는 모든 도구를 권한으로 취급하고, 그에 맞게 범위를 제한해야 합니다. 저는 에이전트를 IAM 주체(principal)로 모델링합니다: 고유 식별자, 최소 권한 역할(least-privilege roles), 세션 범위 자격 증명(session-scoped credentials).

게이트 5: 책임 소재 — 누가 결정에 대한 책임을 지는가?

모델이 틀릴 때 — 그리고 그럴 것이 분명합니다 — 누가 책임을 지며, 어떤 복구 경로가 있습니까? 모든 프로덕션 ML 시스템은 이름을 가진 소유자(named owner), 롤백 계획(rollback plan), 그리고 존재한다고 알려진 실패 모드에 대한 서면 정책을 필요로 합니다. '모델이 결정했다'는 책임 소재 구조가 아닙니다.

한 페이지 감사 체크리스트

이 게이트들을 팀이 설계 검토 시 작성하는 단일 페이지로 만드세요:

1. 데이터: 출처(provenance) 문서화되었습니까? 누수 점검 통과했습니까? 드리프트 모니터링 계획 수립되었습니까?
2. 평가: 측정 지표가 임무와 일치합니까? 평가 세트가 프로덕션 대표성을 갖추었습니까?
3. 운영: 지연 시간 예산, 예측당 비용, 폴백 동작이 정의되었습니까?
4. 보안: 입력값 검증되었습니까? 접근 범위 제한되었습니까? 에이전트 도구는 최소 권한 원칙을 따릅니까?
5. 책임 소재: 지정된 소유자(named owner)가 있습니까? 롤백 계획이 있습니까? 알려진 실패 모드들이 문서화되어 있습니까?

어떤 빈칸이라도 배를 좌초시킵니다. 한 시간이 걸리며, 사후 분석(postmortem)에서 항상 '사후에 보니 당연했던' 것으로 묘사되는 실패들을 잡아냅니다.

Karmendra Pandey는 TEKsystems의 AI 및 ML 분야 실습 아키텍트입니다. 그는 AWS에서 프로덕션 에이전틱 AI 시스템을 구축하고 PREreview에서 AI 연구를 동료 검토합니다.