기능 요구사항에 ALCOA++?
무결성은 태생부터 만들어지는 겁니다.
‘ALCOA++는 나중에 고민하죠. 지금은 기능만 뽑아야 하니까요.’
이 말을 듣는 순간, 난 바로 URS 초안을 열어봤다. 아니나 다를까. 기능들은 줄줄이 써 있었지만, 그 기능이 어떻게 통제되고, 어떻게 기록되며, 무결성을 어떻게 보장하는지는 어디에도 없었다. 그냥 “로그인이 가능해야 한다”, “알람이 있어야 한다”, “백업 기능이 있어야 한다”… 기능의 존재만 나열된 수준. 그게 전부였다.
그 문서의 최종 검토자가 ‘QA’라는 사실이 내 머리를 멍하게 만들었다.
ALCOA++를 아는 사람은 많다. 하지만 URS에 반영하는 사람은 드물다.
왜일까? 단순하다. 기능 요구사항은 벤더가 써주고, QA는 서명만 한다는 구조에 익숙해졌기 때문이다. 그런데 말이다, 시스템의 ‘기능 정의’ 단계에서부터 무결성은 이미 시작되고 있다. ALCOA++는 감사 대응 문서에 붙이는 양념이 아니다. 기능이 설계될 때부터 그 기준이 들어가야만, 이후 검증이 가능해진다.
EU GMP Annex 11은 전자 기록의 ‘장기 보존성과 변경 통제’를 명시하고, PIC/S는 Data Lifecycle 전체를 관통하는 요구사항 설계를 강조한다. 그런데 정작 현장의 URS는? 아무리 찾아봐도 ‘로그’, ‘권한’, ‘보존 기간’이 없다.
이런 URS로는 밸리데이션 할 수 없다. 테스트 항목도 못 만든다.
예를 들어보자.
“사용자는 ID로 로그인할 수 있어야 한다.”
이 문장, 100번쯤 봤을 거다. 그런데 ALCOA++ 기준으로 보면?
로그인 이력은 기록되는가?
시간 정보가 남는가?
누가 시도했는지 명확한가?
로그는 변경 불가능한가?
5년 이상 보존 가능한가?
관리자 외 열람/수정은 차단되는가?
이 질문 하나하나가 빠졌다면, 그 문장은 이미 불합격이다.
GAMP5는 말한다.
“기능은 밸리데이션을 염두에 두고 설계되어야 한다.”
‘Design with Validation in Mind.’
그래서 난 이렇게 쓴다.
“로그인 시도 및 성공 여부는 시간정보와 함께 자동 기록되며, 해당 기록은 관리자 외에는 열람 불가해야 한다. 로그는 변경 불가능한 형태로 저장되고, 5년 이상 검색 가능한 상태로 보존되어야 한다.”
이 문장은 ‘기능 설명’이 아니라 ‘검증 가능한 구조’다.
여기에는 Attributable, Accurate, Contemporaneous, Enduring, Available… ALCOA++의 조건들이 고스란히 녹아 있다.
이게 URS다. 이게 품질이다.
대표님, 이건 그냥 소프트웨어 요구사항이 아닙니다.
우리가 서명하는 순간, 이 기능은 ‘규제기관 앞에 제출될 증언’이 됩니다.
그러니 이제,
그저 “무엇을 할 수 있다”는 문장은 그만 쓰자.
“어떻게 기록되고, 어떻게 통제되며, 어떻게 보존되는지”를 말하자.
그래야 실사에서 묻는다.
“이 기능은 어떤 방식으로 ALCOA++를 보장합니까?”
그때, 우리는 말할 수 있다.
“기능 정의에서부터 다 설계되어 있습니다.”
