실무자가 꼭 알아야 할 ‘OQ 시험항목’ 설계 전략
단순히 테스트가 아니라, 설계 논리를 입증하는 싸움이다
1. OQ는 ‘시험’이 아니라 ‘입증’이다
많은 사람들이 Operational Qualification(OQ)을 단순히 “시스템이 작동하는지 확인하는 단계”라고 생각한다.
틀린 말은 아니지만, 이 정의만으로는 절반밖에 이해 못 한 것이다.
OQ의 진짜 목적은
이 시스템이 왜 이렇게 설계되었는지, 그 설계 논리를 시험으로 입증하는 것이다.
즉, OQ는 ‘설계도와 맞춰보는 시험’이 아니라
‘설계자가 품질 기준에 따라 시스템을 구성했음을 검증하는 문서’다.
그렇기에 시험 항목은 단순히 “이 기능이 동작하느냐”보다
“이 기능이 이 조건에서, 이 권한으로, 이 기록을 남기며 작동하는가?”를 묻는다.
2. OQ 시험 항목을 설계할 때 반드시 따져야 할 것
① 시험 목적이 명확한가?
예:
알람은 설정한 임계값 초과 시 자동 발생한다
알람 발생 내역은 삭제 불가한 로그로 기록된다
단순히 ‘알람이 울렸다’는 건 목적이 아니다.
왜 그 알람이 울려야 했는가, 그 상태는 어떻게 보존되는가를 확인해야 한다.
② 기능 조건이 구체적인가?
예:
로그인 실패 5회 → 계정 잠금
설정 변경 시 관리자 승인 필요
시험 조건이 모호하면, 누구나 다르게 해석한다.
시험 조건은 숫자와 상태로 구체화해야 한다.
③ 테스트 방법이 재현 가능한가?
예:
“온도 센서를 설정 온도 이상으로 가열한 후…”
“계정 A로 로그인 실패 5회를 유도한 후…”
실제 시험을 할 수 있어야 한다.
OQ는 문서가 아니라, 실제 수행 가능한 행위 지침이다.
④ 기록과 로그는 어떻게 남는가?
예:
“이벤트는 Audit Trail에 자동 기록됨”
“로그는 PDF로 출력 가능하며 수정 불가함”
데이터 무결성은 기능보다 기록에서 흔들린다.
기록이 없으면 아무 것도 증명할 수 없다.
3. 흔히 실패하는 OQ 항목 설계의 예
잘못된 예:
“트렌드가 잘 나오는지 확인한다”
이게 뭘 의미하는가?
트렌드가 뭔지도, ‘잘 나온다’는 게 어떤 상태인지 아무도 모른다.
바꿔 써야 할 문장:
“사용자가 2024년 9월 1일부터 9월 10일까지의 온도 데이터를 조회하면,
시스템은 해당 기간의 데이터를 시간 순으로 그래프로 표시해야 하며,
이 조회 내역은 Audit Trail에 자동 기록되어야 한다.”
OQ 항목은 구체적이지 않으면 테스트도, 기록도, 입증도 불가능하다.
4. OQ는 ‘CSV 핵심 기능’ 위주로 설계해야 한다
누가 OQ 항목을 정하는가?
OQ는 모든 기능을 다 시험하는 단계가 아니다.
CSV 관점에서 품질에 영향 주는 기능, 무결성 확보와 직결된 기능, 접근 통제, 알람, 기록 등 시스템 통제 기능을 중심으로 선별해야 한다.
주요 항목 예시:
사용자 권한 설정 및 기능 제한
Audit Trail 기록 및 변경 불가 여부
알람 발생 조건 및 해제 조건
설정 변경 시 로그 기록 여부
백업 수행 주기 및 실패 대응
이 항목들은 대부분 GAMP5, EU GMP Annex 11, HMA/EMA DI 가이드라인에서
‘시험을 통해 입증되어야 하는 주요 기능’으로 분류되고 있다.
5. 결론 – 문장이 아니라 구조를 보라
OQ 항목 하나하나는
그 시스템이 품질 기준을 만족시키는 논리 구조를 가지고 있음을 입증하는 문장이다.
그러니 단지
“이거 잘 되나요?”
를 묻는 게 아니라,
“이 기능이 왜 필요한가? 어떤 조건에서 작동하나? 기록은 어떻게 남나?”
를 묻는 방식으로 바꿔야 한다.
문장은 짧아도 논리는 길어야 한다.
OQ는 그 논리를 가장 정확하게 드러내는 ‘설계 검증의 무기’다.
