시스템 기능 정의 시 주의사항 - Part 2
“할 수 있어야 한다”는 문장, 실사장에서 제일 먼저 걸린다
“사용자는 백업 기능을 사용할 수 있어야 한다.”
이 문장을 보면 어떤 생각이 드는가?
잘 쓴 것처럼 보인다. 기술적이고, 말도 맞고.
하지만 실사장이면 얘기가 달라진다.
“사용자는 사용할 수 있어야 한다.”
이게 기능 정의인가?
기능이 존재할 수도 있다는 가능성을 말하고 있을 뿐,
시스템이 실제로 어떻게 동작해야 하는지는 아무것도 말하지 않는다.
이 문장이 위험한 진짜 이유
이런 문장은 감사인을 움직이게 만드는 지점이 전혀 없다.
GAMP5는 이를 “Not testable, not verifiable” 하다고 경고한다.
즉, 시험도 안 되고, 검증도 안 되며,
결국은 책임 소재도 없고 통제 기반도 없다는 뜻이다.
Annex 11, HMA/EMA Data Integrity 가이드라인에서도
모호한 요구사항은 Audit Trail, Access Control, Record Management
같은 핵심 통제 항목을 흐리게 만든다고 명시한다.
실사장에서 실제로 벌어지는 일
“여기 보니까 백업 기능을 사용할 수 있어야 한다고 쓰셨네요?”
“네, 맞습니다.”
“근데… 사용할 수 있는지 확인할 방법이 뭐죠?”
그 순간,
OQ 문서엔 아무 것도 연결된 게 없다.
시험 항목은 애매하고, 결과는 주관적이며,
검증 리포트엔 ‘수행’은 됐지만 ‘기준’은 없다.
실사인의 입장에서 보면,
이건 기능이 있는 게 아니라 ‘기능이 있다고 믿고 싶은 상황’에 불과하다.
그래서 어떻게 써야 하냐고?
“시스템은 실시간 데이터를 5분 주기로 자동 백업하며,
백업 파일은 외부 저장소에 저장되고,
백업 내역은 Audit Trail에 자동 기록되어야 한다.
백업 주기는 시스템 관리자만 설정할 수 있어야 한다.”
이렇게 쓰면 테스트가 가능하다.
누가, 언제, 어떻게, 어디로, 무엇을 통제하고 기록하는지 모두 드러난다.
그래야 시험이 가능하고, 검증이 가능하고,
QA로서 책임이 가능하다.
“가능해야 한다”는 말로는 품질을 설계할 수 없다.
가능성은 품질이 아니다.
검증은 모호한 기대가 아니라 구체적 실행을 기준으로 한다.
GAMP5가 말하길,
요구사항은 “testable, traceable, unambiguous” 해야 한다.
이 세 가지가 빠지면,
그 문장은 당신이 아닌 벤더를 위한 문장이 된다.
다음 편에선,
벤더 사양서에 기대 쓴 기능 정의가 왜 실사 때 폭탄이 되는지
그리고 왜 QA가 시스템 엔지니어보다 더 냉정해야 하는지
살펴보겠다.
