데이터 무결성·CSV 실무 가이드 - ALCOA+를 시스템 요구사항으로

MES·LIMS·QMS를 도입하는 이유의 절반은 데이터 무결성입니다. 실사에서 지적되는 항목의 상당수가 "기록이 틀렸다"가 아니라 "기록을 믿을 수 있다는 근거가 없다"이기 때문입니다. 이 문서는 데이터 무결성 원칙(ALCOA+)을 시스템 요구사항으로 옮기는 방법, 감사추적과 권한 설계에서 실제로 걸리는 지점, CSV 범위 설정이 도입 기간에 미치는 영향을 도입기업 관점에서 정리합니다.

1. 왜 지금 데이터 무결성인가

종이 기록 시대의 무결성은 "고치면 두 줄 긋고 서명"으로 담보됐습니다. 전자 기록은 흔적 없이 고칠 수 있기 때문에, 규제기관은 전자 시스템에 종이보다 더 엄격한 증거 구조를 요구합니다. 미국 21 CFR Part 11, 유럽 EU GMP Annex 11, 한국 GMP의 전자기록 관련 조항이 모두 같은 방향입니다. 시스템을 도입했는데 감사추적이 꺼져 있거나 공용 계정을 쓰고 있으면, 종이 기록보다 나쁜 평가를 받을 수 있습니다.

2. ALCOA+를 시스템 요구사항으로 번역하기

ALCOA+는 원칙이지 기능 목록이 아닙니다. 시스템을 평가할 때는 각 원칙을 구체 기능으로 바꿔 물어야 합니다.

Attributable(귀속) - 모든 기록에 개인 계정이 붙는가. 공용 계정·자동 로그인은 여기서 탈락합니다. Legible(판독 가능) - 보존 기간 내내 사람이 읽을 수 있는 형태로 출력되는가. Contemporaneous(동시성) - 기록 시각을 시스템이 찍는가, 사용자가 고칠 수 있는가. Original(원본) - 최초 입력값이 수정 후에도 남는가. Accurate(정확) - 입력 검증(범위·형식)과 계산 로직이 검증됐는가. 여기에 Complete(완전) - 실패한 시험·취소된 기록도 남는가, Consistent(일관)- 시각 순서가 맞는가(서버 시간 동기화), Enduring(영속) - 백업·복구가 검증됐는가, Available(가용) - 실사 시 즉시 조회되는가가 더해집니다.

3. 감사추적 - 있다와 쓸 수 있다는 다르다

감사추적은 대부분의 시스템에 "있습니다". 문제는 세 가지입니다. 범위 - 데이터 수정만 기록하고 마스터 변경·권한 변경·설정 변경은 빠져 있는 경우가 많습니다. 규격을 바꾼 이력이 없으면 값이 정상 판정된 근거를 설명할 수 없습니다. 가독성 - DB 로그 테이블 형태로만 존재해 IT 담당자가 SQL로 뽑아야 한다면 실사 현장에서 쓸 수 없습니다.검토 절차 - 감사추적은 기록되는 것으로 끝나지 않고 주기적으로 검토됐다는 기록이 있어야 합니다. 시스템이 검토 화면과 검토 완료 서명을 지원하는지 확인하세요.

한 가지 더. 감사추적은 사용자가 끌 수 없어야 합니다. 관리자 권한으로도 비활성화가 가능한 구조라면, 그 사실 자체가 지적 사항이 됩니다.

4. 권한·계정·전자서명

계정

1인 1계정, 퇴사·전보 시 즉시 비활성화, 비밀번호 정책(길이·주기·재사용 금지), 일정 시간 무입력 시 자동 잠금. 현장 태블릿이나 라인 PC에서 "로그인이 번거롭다"는 이유로 공용 계정이 생기는 것이 가장 흔한 붕괴 지점입니다. 바코드·카드 로그인처럼 번거로움을 줄이는 수단을 시스템이 갖추고 있는지 보세요.

권한 분리

작성자와 검토자·승인자가 분리되어야 하고, 마스터 데이터 변경은 품질 부서 승인이 필요합니다. MES·LIMS·QMS가 별개 시스템이면 세 곳에서 따로 권한을 관리해야 하고, 그 불일치가 실사에서 드러납니다. 단일 권한 체계로 묶인 통합 시스템이 유리한 이유입니다.

전자서명

서명은 단순 클릭이 아니라 재인증(비밀번호 재입력 등)을 동반해야 하고, 서명자·시각·의미(작성/검토/ 승인)가 기록에 붙어야 합니다. 서명 후 기록이 수정되면 서명이 무효화되고 재서명이 요구되는지도 확인 항목입니다.

5. CSV - 범위를 정해야 기간이 정해진다

컴퓨터 시스템 밸리데이션(CSV)은 시스템이 의도한 대로 동작한다는 문서화된 증거입니다. 도입 기간을 늘리는 가장 큰 변수이며, 그 이유는 대개 범위가 정해지지 않은 채 시작하기 때문입니다. GAMP 5의 위험 기반 접근을 따르면 제품 품질과 환자 안전에 영향을 주는 기능에 검증 노력을 집중하고, 나머지는 공급업체 검증 결과를 활용합니다. 표준 패키지 소프트웨어의 기본 기능까지 처음부터 전부 다시 시험하는 것은 시간 낭비이자 품질에도 도움이 되지 않습니다.

실무적으로 도입 전에 정해야 할 것은 셋입니다. ① 검증 대상 기능 목록(위험 평가 기반) ② 공급업체가 제공하는 검증 문서 범위(IQ/OQ 표준 문서, 시험 기록) ③ 자사가 수행할 PQ 시나리오. 이 세 가지가 계약 전에 합의되면 CSV는 예측 가능한 일정이 됩니다.

6. 운영 단계에서 무너지는 지점

도입 시점에는 완벽했던 무결성이 운영 중에 무너지는 패턴이 있습니다. 변경 관리 누락- 패치·설정 변경이 변경통제 없이 적용됩니다. 백업 미검증 - 백업은 돌아가는데 복구 시험을 한 번도 안 해봤습니다. 시간 동기화 해제 - 서버·설비·클라이언트 시각이 어긋나 기록 순서가 뒤집힙니다. 주기적 검토 중단 - 감사추적 검토, 계정 검토가 첫 해 이후 사라집니다. 이 네 가지는 시스템이 아니라 운영 절차(SOP)의 문제이고, 도입 시 SOP까지 함께 만들어야 막힙니다.

7. 체크리스트