3주 전, 제 팀의 주니어 엔지니어가 eQMS에서 가장 예측 가능한 질문을 던졌습니다. 바로 '제가 템플릿을 고쳤는데, 왜 변경 사항이 열린 기록에 나타나지 않나요?'라는 것이었습니다.
그녀는 디자인 히스토리 파일(design history file) 템플릿의 필드 레이블을 수정했습니다. 새로운 문구는 더 명확하고 검색하기 쉬웠으며, 다음 검토 시 그녀에게 20분을 절약해 줄 수 있을 정도였습니다. 그녀가 한 번 고치자, 모든 곳에 적용되기를 기대했습니다. 이것은 일반적인 기대입니다. 이미 열려 있던 기록들은 여전히 이전 레이블을 보여주고 있었습니다.
Greenlight Guru, MasterControl 등 제가 2011년 이후 접해온 모든 QMS에서 이 현상은 일관적이며, qmsWrapper도 마찬가지입니다.
당신의 '버그' 뒤에 숨겨진 설계 선택
제가 이해하는 데 시간이 걸렸던 것은 이것이 버그가 아니라는 점입니다. 시스템이 의도대로 작동하고 있다는 것입니다. 템플릿 버전 기준으로 기록을 생성할 때, 그 기록은 해당 버전에 바인딩됩니다. 템플릿은 수정될 수 있지만, 이미 존재하는 기록은 소급하여 다시 작성될 수 없습니다. ISO 13485 §7.5와 21 CFR 820.40 모두 이 영역에 존재합니다. 즉, 통제된 문서, 기록 무결성(record integrity), 변경 사항의 추적 가능성(traceability of changes)을 의미합니다.
qmsWrapper에서는 이것이 명확하게 구현되어 있습니다. Document 모듈은 기록별로 버전 히스토리(version history)를 유지합니다. 기존 DHF 항목, 위험 파일(risk files), CAPA 기록 등 모든 것은 생성될 때의 버전에 남아 있게 됩니다. 수정된 템플릿은 새로운 기록에 대해서는 올바르게 표시됩니다. 하지만 오래된 기록들은 감사할 수 있는 버전 스탬프와 함께 원래의 내용을 유지합니다.
이것이야말로 신고 기관(notified body) 감사를 받을 때 올바른 조치입니다. 템플릿 편집만으로 모든 것이 전파될 거라 생각했던 사람에게는 여전히 힘든 오후일 것입니다.
엔지니어가 실제로 필요로 하는 것
제가 지난 14년 동안 접한 '왜 전파되지 않았나요' 관련 티켓의 대부분은 다음 세 가지 중 하나에 기인합니다:
- 사용자는 '한 번 고치면 모든 곳을 고쳐야 한다'고 가정합니다. 그것은 스프레드시트 사고방식입니다. QMS 기록은 셀 수식이 아닙니다.
- 사용자는 검토되고 원래 승인된 감사 추적(audit trail)을 잃지 않으면서, 진행 중인(in-flight) 기록에 더 깔끔한 문구를 적용하기를 원합니다.
- 사용자는 어차피 해당 기록을 재발행하거나 마이그레이션할 예정이며, 구형 템플릿에서 가져와야 할지 신규 템플릿에서 가져와야 할지만 알고 싶어 합니다.
세 경우 모두 답은 같습니다. 기존 기록이 승인된 것입니다. 건드리지 마세요. 변경 사항이 중요(material)하다면 새로운 개정판을 만드세요. 미적인(cosmetic) 변화라면 그대로 두세요.
실제로 저에게 도움이 된 워크플로우
템플릿 변경이 진행 중인 작업에 영향을 줄 경우, 저는 지금 이렇게 합니다:
- 변경 사항 자체를 변경 관리 기록(change control record)에 표시합니다. 템플릿 개정 노트에는 무엇이 수정되었고 왜 수정되었는지가 담깁니다.
- 문서 모듈에서 여전히 구형 버전에 있는 기록을 빠르게 검색합니다. 템플릿 버전으로 필터링하면, 고대 유적 발굴 프로젝트가 아니라 2분짜리 작업이 됩니다.
- 각 진행 중인 기록에 대해 명시적으로 결정합니다:
- 초안(draft)인가요? 신규 템플릿으로 재발행할 수 있습니다.
- 승인은 되었지만 아직 유효하지 않은가요? 마찬가지입니다. 재발행하고 워크플로우를 통해 다시 경로 지정해야 합니다.
- 유효하며 사용 중인가요? 그대로 두세요. 생성된 템플릿 버전을 문서화합니다. 다음으로 넘어갑니다.
- 종료된 기록은 아무것도 하지 않습니다. 그것들은 역사적입니다. 끝난 것입니다.
마지막 단계가 바로 팀들이 건너뛰는 부분입니다. 종료된 기록은 감사 추적이 그날 실제로 일어났던 것과 일치하도록 존재합니다.
제가 여전히 이것에 대해 생각하는 이유
이 행동 방식은 방어 가능합니다. 저는 그것이 반드시 방어 가능해야 한다고 주장할 것입니다. 그렇지 않으면 신고 기관(notified body) 감사가 의존하는 기록 버전 무결성(version-of-record integrity) 자체가 깨지기 때문입니다. 제가 계속 곱씹는 부분은 사용자 경험 측면입니다.
주니어 엔지니어가 이 상황을 처음 접했을 때, 시스템은 아무런 안내도 제공하지 않습니다. '이 템플릿이 수정되었으니, 기존 기록들은 버전 X에 남아 있습니다'라는 배너도 없고, 주의가 필요한 기록으로 연결되는 링크도 없습니다. 관련 지식은 Document 모듈에서 찾아볼 수는 있지만, 그 정보를 찾는 마찰(friction)은 가장 먼저 불일치를 발견한 사람에게 전가됩니다.
저는 이 마찰이 슬랙 스레드로, 그다음 티켓으로, 그리고 결국 '템플릿 불일치'에 대한 CAPA 조사로 변하는 것을 지켜봤습니다. 하지만 이는 실제로는 불일치가 아니었습니다. 단지 팀이 시스템이 작동한다고 생각한 방식과 실제로 작동하는 방식 사이의 간극일 뿐이었습니다.
열린 질문 (Open question)
QMS(품질관리시스템)를 도입하고 있는 분들께 여쭙고 싶습니다. 엔지니어들이 이 상황을 뼈저리게 경험하기 전에, 그들에게 '템플릿 버전은 기록에 바인딩된다'는 모델을 어떻게 온보딩할 수 있을까요? 효과적이었다고 본 문서화 자료, 교육 과정, 또는 인앱(in-product) 안내가 있습니까? 아니면 이 불편한 오후의 경험 자체가 일종의 통과 의례(rite of passage)일 뿐일까요?
공개 고지: 저는 qmsWrapper에서 작업하고 있습니다.