새로운 불량 검출 모델이 시험 데이터에서 기존 모델보다 정확도가 높았습니다. 그렇다면 다음 날 바로 생산라인 판정기를 교체해도 될까요? 현장에서는 답이 쉽지 않습니다. 조명과 품목, 설비 속도, 카메라 오염, 신규 결함 유형이 시험 환경과 다를 수 있기 때문입니다. 특히 모델 출력이 자동 배출 장치나 작업 중단으로 이어진다면 작은 오판도 폐기 비용과 생산 지연을 만듭니다. 섀도 테스트는 이 간극을 줄이기 위한 운영 실험입니다.
섀도 모드는 무엇을 하는가
현재 운영 중인 모델이 평소대로 요청을 처리하고, 같은 입력의 복사본을 후보 모델에도 보냅니다. 실제 사용자 또는 설비에는 기존 모델의 결과만 반영합니다. 후보 모델의 출력은 따로 기록해 비교합니다. 즉 후보가 실전 분포의 데이터를 보지만 의사결정 권한은 아직 갖지 않는 구조입니다. AWS의 섀도 테스트 문서도 생산 요청을 복제하고 후보 응답을 사용자에게 반환하지 않는 패턴을 설명합니다. 이 방식은 특정 클라우드 제품을 써야만 가능한 것은 아닙니다.
산업 현장에서는 입력 복제가 특히 중요합니다. 두 모델이 서로 다른 시간대의 제품을 봤다면 불량 비율의 차이가 모델 개선 때문인지 원자재 배치 차이 때문인지 구분하기 어렵습니다. 프레임 ID, 설비 ID, 품목, 촬영 시각, 모델 버전, 전처리 버전을 묶어 기록하세요. 민감한 원본 영상은 필요한 범위만 보존하고 접근 권한과 보존 기간을 정합니다. 라인의 지연을 늘리지 않도록 후보 추론은 비동기 경로로 분리하고, 그림자 경로가 실패해도 운영 판정에는 영향을 주지 않아야 합니다.
정확도 하나로는 승격할 수 없다
비교 지표는 현장 비용 구조에 맞춰 정합니다. 정상 제품을 불량으로 잘못 버리는 오검출, 불량을 놓치는 미검출, 검토가 필요한 애매한 결과, 추론 시간의 꼬리값, GPU·엣지 장비 사용량을 함께 봅니다. 전체 평균이 좋아도 특정 품목·교대조·카메라에서 나빠지면 위험합니다. 결과를 품목과 설비별로 분해해 봐야 합니다. 양성 사례가 적은 공정에서는 몇 건의 차이로 백분율이 크게 움직이므로 표본 수와 신뢰 구간도 함께 제시해야 합니다.
기존 모델과 후보 모델의 판단이 갈리는 사례를 우선 사람에게 보여 주는 방식이 효율적입니다. 다만 사람 검토 결과를 곧바로 절대 정답으로 취급해서도 안 됩니다. 판정 기준이 모호한 사례는 복수 검토와 판정 가이드를 거치고, 사후에 확인된 실제 불량 여부가 있다면 그 결과를 연결합니다. 섀도 테스트는 온라인 A/B 실험과 달리 후보 모델이 실제 조치의 결과를 만들지 않으므로, 현장 행동 변화까지 검증했다고 주장할 수 없습니다.
승격 조건을 테스트 전에 정한다
예를 들어 “핵심 불량 유형의 미검출이 기존보다 늘지 않을 것, 정상 제품 오배출이 허용 비용 이하일 것, p95 추론 시간이 설비 택트타임을 넘지 않을 것, 특정 품목에서 성능 저하가 없을 것”처럼 조건을 문서화합니다. 관찰 기간도 수량만이 아니라 여러 교대조와 제품 변경을 포함하도록 설계합니다. 이 기준을 결과를 본 뒤 바꾸면 모델에 유리한 해석만 남기 쉽습니다.
섀도 평가를 통과한 뒤에는 자동 제어를 한꺼번에 넘기기보다 제한된 설비·품목·시간대에서 카나리 적용을 고려합니다. 운영 모델로 되돌릴 수 있는 스위치, 버전 고정, 알람, 담당자 승인 절차를 준비합니다. 더 중요한 것은 롤백 후 데이터 해석입니다. 후보가 이미 내린 판정과 기존 모델의 판정이 섞일 수 있으므로, 이벤트마다 어느 모델이 실제 결정을 했는지 기록해야 사후 원인을 설명할 수 있습니다.
현장에서 시작하는 최소 구성
첫 단계는 모델 두 개보다 결정 로그의 품질입니다. 입력 식별자와 운영·후보 결과를 안전하게 연결할 수 없다면 비교 자체가 불가능합니다. 그 다음 실패 격리, 샘플 검토 화면, 품목별 지표, 승격 회의의 네 부분을 붙입니다. 작은 파일럿부터 시작해 한 카메라·한 품목에서 결과를 보세요. 모델 배포를 ‘파일 교체’가 아니라 ‘검증 가능한 운영 결정’으로 다루는 것이 산업 AI를 오래 쓰게 만드는 출발점입니다.
