CSV란?

CSV(Computer System Validation)
: 컴퓨터화 된 시스템이 미리 정의된 규격에 따라서 일관되게
운영된다는 것을 높은 수준으로 증명하여 문서화된 증거를
확립하는 과정이다

개발자로써 몇차례 CSV를 겪어보면서 느낀 소회를 좀 적어볼까 합니다.
그래도 나름 큰 규모의 시스템을 직접 개발하면서 동시에 CSV를 같이 참여하게 되면서 피부로 느낀 경험들을 담아보고자 합니다.

CSV는 전반적인 과정을 GAMP 5 절차를 따릅니다.
약간의 개정은 지속적으로 있지만 전체적인 절차는 아래와 같습니다.

해당 절차에서 주목할 부분은 각 절차가 선형을 띄고 있다는 것인데요.
동시에 진행되는것이 아닌 Waterful한 구조를 가지고 있습니다.

우선 해당 GAMP 5의 절차는 내부 개발이 아닌 시스템 개발을 외주 맡기는 형태를 전제하고 있습니다. 한국의 SI 절차와 유사합니다. 문서내에서도 시스템 개발을 요청 하는 제약 회사를 고객(Customer)이라고 지칭을 하고 있고 시스템 개발사를 공급자(Supplier)로 통칭하고 있습니다.

상세 절차는 아래와 같습니다.
시스템을 만들 유저(Customer)는 URS를 적습니다.

User Requirments Specification (URS)
: 시스템 구성에 대한 고객측 상세 요구 사항

URS의 내용으로는 개발 되는 시스템의 하드웨어 스펙 부터 소프트웨어 구성
만들어질 시스템의 기능 등 폭넓은 요구 사항이 적혀집니다.

해당 URS를 바탕으로 개발사(Supplier)는 개발을 진행하게 됩니다.
개발사는 FS, HDS, SDS 를 적게됩니다.

Functional Specification (FS)
: 시스템의 기능들을 나열한 문서입니다.
Hardware Design Specification (HDS)
: 시스템에 구성되어지는 하드웨어의 구성을 나열한 문서입니다.
Software Design Specification (SDS)
: 시스템에 포함되어지는 소프트웨어 항목을 나열한 문서입니다.

각각의 문서를 조금 설명을 덧붙이면 FS의 경우에는 시스템의 상세한 기능들을 적습니다.
특정 버튼을 클릭하게 되면 발생하는 Event와 같이 상세한 기능들이 명시 됩니다.

HDS는 클라우드라면 클라우드 구성이 적히게 되며, On-premise라면 상세 서버 스펙 부터
이중화 구성, L4 구성 등 하드웨어의 구조적 구성이 적히게 됩니다.

SDS는 시스템에서 사용되어지는 프로그램들, 예를들어 백업 솔루션과 같은 사용되어지는 소프트웨어 프로그램들이 적히게 됩니다.

저희는 보통 이 상위 3개의 개발문서를 통칭하여 "FDDS" 로 지칭 합니다.
URS, FDDS는 CSV 전과정에서 가장 중요한 문서입니다.

단순히 SI처럼 요청사항과 그 요청사항에 대한 응답으로써 해당 문서가 의미가 있는게 아닙니다. 감사자는 URS와 FDDS를 바탕으로 해당 시스템이 Valid 한지를 평가하게 되고
URS/FDDS에 적히지 않은 기능이 있다던지, 공개되지 않은 하드웨어/소프트웨어 구성등이 있다면 이를 집요하게 물어보고 지적 받게 될 가능성이 있습니다.

하기 때문에 대부분의 기능을 URS/FDDS 명시하는 것이 감사대응에 효과적이며 문서화 된 기능들은 Valid하게 평가되어져서 사용하는데 크게 문제가 없게 됩니다. (감사 지적을 덜 받게 됩니다)

하지만 이는 양날의 검이여서 너무 자세한 URS/FDDS는 추후 기능을 검증하는 Validation 단계에서 많은 Task를 소모하게 됨으로

고객과 개발사는 이를 인지하고 문서화에 대한 정립을 시스템 개발전에 마치는 것이 좋습니다.