“그냥 알람 기능만 있으면 됐잖아요?”
그 문장 하나로, 밸리데이션이 무너진다.
“시스템은 알람 기능을 제공해야 한다.”
문장 자체는 이상 없어 보인다.
하지만 이 한 줄이, 프로젝트 전체를 망가뜨릴 수도 있다.
왜냐고?
이건 기능이 아니라 ‘선언’이기 때문이다.
실제 현장에서 쓰이는 많은 URS는
‘요구사항’이 아닌 사양 나열 혹은 기술 설명 수준에 머문다.
“시스템은 HTML5 기반이어야 한다.”
“시스템은 백업 기능을 지원한다.”
“설정 변경은 로그로 기록된다.”
대체 누가, 언제, 어떤 조건으로, 어떤 기준 아래
그 기능을 수행하는지 아무도 모른다.
그게 문제다.
GMP 문서가 아닌, 기술 소개서처럼 보여버리는 순간,
그건 더 이상 품질 문서가 아니다.
규제기관은 ‘기능이 존재하느냐’가 아니라
‘그 기능이 어떤 품질 기준을 만족하느냐’를 묻는다.
EU GMP Annex 11, GAMP5, EMA DI 가이드라인
모두 공통적으로 요구하는 건 단 하나:
기능은 통제될 수 있어야 하고, 그 통제는 문서화돼 있어야 한다.
예를 들어
“백업은 자동으로 수행되어야 한다.”
라는 문장이 있다고 하자.
이건 누가 주기를 설정하고,
어디에 저장되고,
실패 시 어떤 조치를 하며,
그 로그는 어디 남는지를 아무도 모른다는 뜻이다.
이건 요구사항이 아니라,
“그냥 백업 알아서 되겠지”라는 희망사항이다.
GAMP5는 말한다.
기능 요구는 시험 가능하고(Testable),
추적 가능하며(Traceable),
명확해야 한다.
기술이 중요한 게 아니다.
품질 시스템 안에서 그 기술이 어떤 ‘통제 구조’로 작동하느냐가 중요하다.
그리고 그 구조는
책임 주체 / 설정 조건 / 결과 보존 방식
이 세 가지로 표현돼야 한다.
예를 들어
“사용자는 권한에 따라 기능을 사용할 수 있어야 한다”
는 말 대신,
→ “시스템은 관리자 권한으로 사용자 역할을 정의할 수 있어야 하며,
각 역할별 접근 가능한 기능은 사전 설정되고 변경은 기록되어야 한다.”
이렇게 써야 OQ 문서에서도 기준이 잡히고,
Audit에서 대응이 가능해진다.
더 큰 문제는 중요도 차이를 무시하고
모든 기능을 동일한 레벨로 써버리는 오류다.
“설정 변경 로그는 있어야 한다.”
모든 시스템이 로그를 똑같이 써야 할까?
어떤 시스템에선 설정 하나가
데이터 품질에 직접적 영향을 줄 수 있지만,
어떤 시스템에선 부수적인 기능일 수 있다.
그 중요도에 따라 요구 수준도 달라져야 한다.
요구사항 하나하나가, 결국은 품질 통제 전략이다.
그 한 줄이, 밸리데이션의 시작이고
테스트의 기준이고
감사인의 질문의 방향이 된다.
그러니 ‘그냥 써도 되겠지’라는 생각은 접자.
그 한 줄이, 시스템 전체를 뒤흔들 수 있다.
다음 편에선, 이 문장들을 실제로 어떻게 개선할 수 있을지 보여준다.
뻔한 문장을 바꾸는 순간,
문서가 ‘살아 있는 증거’로 바뀐다.
실전 문장 해체쇼, 기대하셔도 좋다.
