설계가 없으면, 검증도 없다
문서 양식은 완벽한데 감사관이 납득 못 하는 이유
IOQ 서류 다 완벽합니다.
서명도 다 있어요. 사진도 첨부했어요.
근데 실사관 표정이 안 풀립니다.
“설계 문서는 어디 있나요?”
“FDS는 작성하셨나요?”
아차.
“밸리데이션은 다 했는데, 설계 문서가 없어요…”
검증은 ‘설계 대비’라는 걸 잊지 마라
IOQ 문서에 시험 결과가 아무리 정확하게 기록되어 있어도
그게 무엇을 기준으로 작성되었는가를 설명 못 하면,
그 검증은 성립되지 않습니다.
테스트 항목이 왜 필요한지 설명할 수 없고
그 항목이 URS에서 어떻게 이어졌는지 보이지 않고
시스템이 왜 그렇게 동작해야 하는지 설계 근거가 없으면
감사관은 “그냥 테스트만 한 거네요?” 라고 합니다.
FDS 없는 시스템 = 이유 없는 테스트
FDS는 Function Design Specification, 즉 기능 설계 명세서입니다.
시스템이 어떤 동작을 하도록 설계되었고,
그 동작은 어떤 로직과 화면 구조로 구현되었는지를 설명하는 문서죠.
GAMP5에서도 URS → FDS → 테스트 라는 추적성 사슬(Traceability Chain) 을 강조합니다.
테스트가 존재하려면, 설계가 있어야 합니다.
설계가 있으려면, 요구사항이 있어야 합니다.
그럼 실제로 어떤 문제들이 발생할까?
OQ에서 ‘알람 발생 시험’을 했다 → 그런데 알람 설정값이 어디 기준인지 몰라요 (FDS 없음)
IOQ에서 ‘계정 접근 제한 시험’을 했다 → 근데 FDS에 권한구조 정의가 없어요 = 그 시험, 왜 했는지 모릅니다
Trend 기능을 시험했는데 → URS엔 ‘트렌드 제공’이라고만 써 있고, FDS에 그래프 사양이 없음
결과적으로 이 모든 테스트는 “설계 없는 시험”이 되고,
감사관이 보기엔 “신뢰할 수 없는 테스트”가 됩니다.
왜 이런 일이 생길까?
대부분 이런 흐름입니다.
URS를 벤더가 대신 작성
FDS는 생략하거나 단순 스크린샷 나열
IOQ는 벤더가 작성한 포맷 그대로 사용
QA는 서류 양식만 체크
모든 게 문서화는 됐지만
시스템의 ‘논리’가 전혀 보이지 않습니다.
서류가 아니라 ‘논리’를 검토하라
실사에서 중요한 건 ‘양식이 갖춰졌는가’가 아니라
‘그 시스템이 왜 그렇게 동작해야 했는지’를 설명할 수 있느냐입니다.
따라서,
URS에는 기능이 어떤 배경과 요구에서 나왔는지
FDS에는 그 기능이 어떻게 동작하도록 설계됐는지
IOQ에는 그 설계가 맞게 구현됐는지를 시험하는 구조가 보여야 합니다.
시스템 하나를 끝까지 설명할 수 있어야 한다
감사관은 종종 이런 식으로 묻습니다.
“이 Trend 기능은 어떤 요구사항에 따라 설계된 것이고,
어떤 설계를 바탕으로 구현되어, 어떤 시험으로 확인되었습니까?”
이 질문에 논리적으로 대답 못 하면,
그 기능은 검증되지 않은 기능입니다.
“테스트는 잘 했는데요…”
→ “무엇을 기준으로 테스트하셨나요?”
이 질문이 무섭다는 걸 아셔야 합니다.
정리하면
FDS 없는 시스템은 시험의 기준이 없는 시스템입니다
IOQ만 갖춘 시스템은 “시험만 한 시스템”일 뿐
밸리데이션은 “논리의 연결”이지, “서류의 양”이 아닙니다
설계 근거가 없으면 검증의 신뢰성은 사라지고, → 결국 감사에서는 “이건 CSV로 인정할 수 없습니다”
다음 편 예고
‘테스트’와 ‘시험’의 차이
– 그냥 눌러봤다고 밸리데이션이 되는 건 아니다.
