SAP QM 검사로트 일괄합격 일탈, CSV가 놓친 한 가지

 

3편에서 As-is 산출물의 결정 트리거를 정리했고, 4편에서 CBO 개발의 3단계 위계를 다뤘다. 그러나 자료를 결정으로 읽지 못하고 문서로 쌓아둔 결과가 어떻게 나타나는지는 별개의 이야기다. PCE 전환 프로젝트가 운영 개시 직후 2026년 1월 초에 마주한 품질재고 일괄 합격 일탈 사례를 본다. 사건은 GMP 사이트 9곳을 포함한 10개 플랜트에서 동시에 발생했고, 그 원인은 CSV 테스트 단계에서 놓친 한 가지에 있었다. 이 사례는 CSV의 절차의 중요성 만큼 테스트 설계의 내용이 중요하다는 교훈을 남겼다.

일탈의 모습 — 생산오더 빈값에서 시작된 일괄 합격

검사로트 한 건이 전체 플랜트의 검사대기 재고를 끌고 갔다.

LIMS(외부 품질관리 시스템)에서 SAP로 시험 결과를 보내면, SAP는 해당 검사로트를 합격으로 판정하고 재고 상태를 품질재고 → 가용재고로 전환한다. 정상은 해당 검사로트에 대해서만 판정이 적용되어야 한다. 그러나 운영 개시 직후 발생한 일탈은 3~4초 간격으로 동일 시점 검사대기 재고가 일괄 가용으로 전환되는 현상이었다.

원인의 출발점은 한 가지였다. 생산오더 값이 빈값(blank)으로 산출된 검사로트. PCE 마이그레이션 시 생산입고 검사유형(코드 04)의 검사로트는 생산오더와 함께 정상 이관되었다. 그러나 LIMS에서 판정 결과를 수신할 때, 검사로트와 생산오더를 매핑하는 마이그레이션 매핑 테이블 조회에서 일부 로트의 생산오더가 빈값으로 반환됐다. 이 빈값이 다음 단계의 SQL 조회 조건으로 들어가면서, 생산오더가 빈값인 모든 검사로트가 일괄 합격 처리 대상으로 포함됐다. 한 검사로트의 빈값이 플랜트와 무관하게 전사 검사대기 재고를 끌고 가는 구조가 그 짧은 순간에 작동한 것이다.

CSV 테스트가 놓친 한 가지 — 운영 환경 조건 미반영

테스트는 운영의 마이그레이션 상태를 그대로 재현하지 못했다.

PCE 전환의 CSV(Computer System Validation) 단계는 2차·3차 테스트로 구성된다. 이 단계의 핵심은 운영에서 발생할 모든 시나리오를 재현해서 검증하는 것이다. 본 사건의 원인 보고서는 이 지점을 명시한다. CSV 2차·3차 테스트 시 마이그레이션 매핑 테이블이 존재한 상태에서 테스트가 진행되어야 했으나, 해당 조건을 미반영한 채 테스트가 진행됐다.

매핑 테이블이 미반영된 상태로 테스트하면 어떤 일이 일어나는가. 테스트 데이터의 검사로트는 항상 정상 매핑된 상태로 들어오기 때문에, 빈값(blank) 분기는 코드 안에 있어도 호출되지 않는다. 그래서 빈값에서 발생하는 전체 검사로트 일괄 조회라는 잠재 결함이 테스트 통과로 처리된다. CSV 테스트의 본질은 코드 검증이 아니라 환경 조건 검증이라는 사실이 이 사건에서 드러난다. 운영 환경의 마이그레이션 상태가 정확히 복제되지 않으면, 코드는 통과해도 시스템은 깨진다. 이 잠재 결함은 Z로 시작하는 두 인터페이스 프로그램에 잠복해 있었다 첫째 프로그램은 생산오더 빈값 시 SQL 조건 약화, 둘째 프로그램은 오픈 검사데이터 처리 로직 누락.

검출과 보완, CAPA로 이어진 전수 CBO 검토

즉각 차단 → 원복 → 로직 보완 → 재현 시험 → 운영 반영의 5단계.

운영 개시 직후 수 시간 내에 일탈이 식별되었고, LIMS의 인터페이스 수신을 즉시 차단하는 비상 대응이 가동됐다. 영향 받은 검사로트는 재고 상태 원복(가용 → 품질) 처리되었고, MB51 전환 이력과 SXI_MONITOR 로그로 정상 처리 여부가 검증됐다. 로직 보완은 두 갈래였다 — 생산오더 빈값 시 SQL 미수행 분기를 추가하고, 오픈 검사데이터 처리 로직을 보강했다. 보완본은 DSQ(품질) 환경에서 재현 시험을 거쳐 운영에 반영됐다. 사건 자체는 데이터 무결성이 유지된 상태로 신속 원복됐고, 실물(재고)에 대한 추가 영향은 없는 것으로 검증됐다.

이 사건의 진짜 출구는 단순 로직 패치가 아니라 CAPA(Corrective and Preventive Action)다. 전사 영향이 가능한 Critical 로직임을 인식하고, PCE 전환 과정에서 개발·수정된 모든 CBO를 전수 검토하는 결정이 내려졌다. 우선 검토 대상은 시험 결과 처리, 재고 상태 전환, GxP 영향 가능성이 있는 기능이다. 이는 1·3·4편에서 본 CBO 분류 결정이 시작 단계에 끝나지 않았을 때의 후처리 비용이 무엇인지 보여주는 사례다.

한 줄로

테스트 통과는 운영 안전을 보장하지 않는다, 운영 환경의 조건이 테스트에 반영되어야 비로소 보장된다. 마이그레이션 매핑 테이블, Open Item 분기, 빈값 처리 이런 환경 조건은 코드 리뷰가 아니라 시나리오 설계에서 잡힌다. 본격 개발에 들어가기 전, As-is 분석 단계의 데이터 마이그레이션 조건 인벤토리가 시나리오 설계의 입력값으로 들어와야 하는 이유다. 이 사건을 겪고 나서, 테스트 시나리오를 설계할 때 가장 먼저 묻는 질문이 바뀌었다 — '이 코드가 맞는가'가 아니라 '이 환경 조건이 재현됐는가'