QA는 어디까지 봐야 하는가: "필요 시 QA 검토"가 결국 "전부 QA 검토"가 되는 이유
SOP를 만들 때 이런 문구를 자주 씁니다. "GMP 영향이 있는 경우 QA 검토를 받는다", "필요 시 QA 검토를 진행한다." 문제는 이 조항이 시간이 지나면서 거의 예외 없이 같은 방향으로 흘러간다는 점입니다. 처음에는 일부 문서만 QA에게 가던 것이, 어느 순간 개발보고서 한 장까지도 QA 결재란이 붙어 있습니다. 개발자는 "QA 확인받았습니다"라는 말로 책임을 나누고 싶어 하고, 팀장은 "QA 한번 보고 가라"고 지시하고, QA 스스로도 안 보고 지나갔다가 나중에 문제가 되는 상황이 두렵습니다. 결과적으로 Need-based(필요 시)로 설계된 규칙이 Default(기본값)로 굳어지는 현상이 반복됩니다. 이 글에서는 왜 이런 일이 벌어지는지, 그리고 QA의 검토 범위를 실제로 어떻게 설계해야 하는지를 정리합니다.
"필요 시"라는 말이 무너지는 이유
"필요 시 QA 검토"라는 조항 자체는 합리적으로 보이지만, 실무에서는 거의 항상 같은 방향으로 왜곡됩니다. 그 이유는 네 가지로 정리할 수 있습니다.
- 나중에 문제가 생기는 것이 두렵다. QA를 거치지 않은 문서에서 나중에 이슈가 발생하면 "왜 QA 검토를 안 받았느냐"는 질문이 먼저 나옵니다.
- QA 스스로도 안 보면 불안하다. 검토 대상에서 빠진 문서가 나중에 GMP 문서의 근거로 쓰이면 QA가 책임을 나눠 지게 됩니다.
- 개발자는 면피가 필요하다. "QA 확인을 받았다"는 사실 자체가 개발자 입장에서는 일종의 보험이 됩니다.
- 팀장도 확인 한 번을 더 원한다. 팀장 입장에서도 QA가 한 번 더 봐준다면 자신의 승인 부담이 줄어듭니다.
이 네 가지가 겹치면 "필요한 경우"라는 조건은 사실상 아무 기능을 하지 못합니다. 모두가 "안 보는 것보다 보는 게 안전하다"고 판단하기 때문에, Need-based 규칙은 시간이 지날수록 Default로 수렴합니다. 이 흐름을 막으려면 "필요 시"라는 모호한 표현 자체를 없애고, 명확한 Trigger로 바꿔야 합니다.
모호한 기준 대신 명확한 Trigger를 설계한다
QA 검토 여부를 사람의 판단에 맡기는 순간 그 판단은 항상 안전한 쪽, 즉 "QA에게 보낸다"로 기웁니다. 이를 막는 방법은 판단이 아니라 규칙으로 자르는 것입니다. 가장 실무적인 두 가지 방식은 문서 종류 기준과 문서 용도 기준입니다.
방식 1. 문서 종류로 자른다
| 문서 | QA 검토 |
|---|---|
| 개발보고서(Research 목적) | X |
| Qualification Report | O |
| Validation Report | O |
| Tech Transfer Report | O |
| Stability Report | O |
| 허가 제출 문서 | O |
| SOP | O |
| GMP 영향 변경(Change Control) | O |
방식 2. 문서의 용도로 자른다
| 조건 | QA 검토 |
|---|---|
| GMP Batch 사용 | O |
| 허가자료 제출에 사용 | O |
| 규격(Specification) 설정의 근거 | O |
| 순수 연구 목적 | X |
| 내부 의사결정용 | X |
두 방식 모두 핵심은 같습니다. "검토자가 알아서 판단하라"가 아니라, "이 조건에 해당하면 무조건 QA를 거친다"는 규칙을 문서로 못 박아 두는 것입니다.
가장 애매한 문서: 개발보고서
실무에서 가장 판단이 갈리는 문서가 Method Development Report 같은 개발보고서입니다. 이 문서가 연구 끝나고 참고용으로만 남는다면 QA 검토는 필요 없습니다. 하지만 아래 세 가지 중 하나에 해당하면 이야기가 달라집니다.
- Validation Strategy 수립의 근거로 인용되는 경우
- 허가자료에서 Development History로 인용되는 경우
- PPQ(Process Performance Qualification)의 근거가 되는 경우
이 조건에 해당하는 순간 개발보고서는 사실상 GMP 문서와 같은 무게를 갖게 됩니다. 그래서 많은 조직이 "혹시 나중에 쓸 수도 있으니까 QA를 돌리자"는 방어적인 결정을 내립니다. 하지만 이렇게 되면 연구 단계의 모든 문서가 QA 병목에 걸리게 됩니다. 더 현실적인 해법은 검토 여부를 이분법으로 나누는 대신, QA가 무엇을, 어느 수준으로 보는지를 단계별로 다르게 설계하는 것입니다.
QA Review와 QA Consultation을 분리한다
연구 단계의 문서에는 QA를 아예 빼는 대신, "승인(Approval)"과 "자문(Consultation)"을 구분하는 방식이 효과적입니다.
연구 단계 (개발보고서 등)
- 작성자 작성
- SME(Peer) Review
- 팀장 승인
- QA Consultation (선택 — SOP 위반 여부 등 코멘트만 제공, 승인 아님)
- 발행
GMP/규제 단계 (Validation, Tech Transfer 등)
- 작성자 작성
- SME(Peer) Review
- 팀장 승인
- QA Approval (정식 승인 절차)
- 발행
이 차이가 실무에서는 매우 큽니다. QA Consultation 단계에서 QA는 "이 부분은 SOP와 맞지 않습니다"라는 코멘트는 줄 수 있지만, 문서를 승인하거나 반려할 권한은 갖지 않습니다. 이렇게 하면 연구 단계에서의 병목을 줄이면서도, 이후 그 문서가 GMP 문서로 전환될 때의 리스크는 미리 낮춰둘 수 있습니다.
QA가 봐야 할 것과 보지 말아야 할 것
QA 검토 대상이 되는 문서라 하더라도, QA가 모든 내용을 다 판단해야 하는 것은 아닙니다. QA의 역할은 과학적 판단이 아니라 품질 시스템(Quality System)이 제대로 작동했는지를 확인하는 것입니다. 이 원칙은 ICH Q10이 강조하는 QA의 정의와도 일치합니다.
| 구분 | QA 검토 | 작성자/SME 검토 |
|---|---|---|
| SOP 준수 여부 | ✔ | |
| GMP/Quality System 영향 | ✔ | |
| Data Integrity(ALCOA+) | ✔ | |
| Traceability(Raw Data 연결) | ✔ | |
| Change Control 필요 여부 | ✔ | |
| Deviation 발생 여부 | ✔ | |
| 규격(Specification) 준수 여부 | ✔ | |
| CQA 영향 여부 | ✔ (평가의 적절성) | ✔ (과학적 판단) |
| Validation 상태 확인 | ✔ | |
| 승인 절차 | ✔ | |
| 통계 방법 적절성 | ✔ | |
| 결과 해석 | ✔ | |
| 과학적 결론 | ✔ | |
| 시험법 타당성 | ✔ | |
| 그래프, 계산식 | ✔ | |
| 맞춤법/표현/문서 Format | ✔ |
여기서 CQA 영향 여부 항목을 눈여겨봐야 합니다. QA가 "이 Aggregate는 CQA가 아닙니다"라고 판단하는 것은 QA의 역할이 아닙니다. QA가 확인해야 하는 것은 "작성자가 CQA 영향을 평가했고, 그 근거가 문서화되어 있으며, 절차에 따라 승인되었는가"입니다. Specification도 마찬가지입니다. "이 규격이 타당하지 않습니다"가 아니라 "승인된 Specification을 벗어난 결과에 대해 적절한 평가와 조치가 이루어졌는가"를 보는 것이 QA의 자리입니다.
Audit에서 자주 지적되는 QA Check 항목
FDA나 EMA Audit에서 반복적으로 확인되는 항목들도 QA Checklist에 명시적으로 포함해두면 실사 대응력이 높아집니다.
| QA Check Item | 이유 |
|---|---|
| Reference Document 최신본 사용 여부 | 구버전 SOP 사용 방지 |
| Version Control | 문서 무결성 확보 |
| Data Traceability | Raw Data까지 추적 가능해야 함 |
| OOS/OOT 영향 검토 | 품질 영향 평가 누락 방지 |
| Change Control 연계 여부 | 변경 누락 방지 |
| CAPA 필요 여부 | 재발 방지 체계 확인 |
| Regulatory Impact 여부 | 허가자료 영향 확인 |
| Product Quality Impact 여부 | 제품 품질 영향 평가 |
| Patient Safety 영향 여부 | 가장 중요한 품질 요소 |
조직에 적용할 때의 실전 팁
- "필요 시"라는 표현을 SOP에서 지운다. 대신 문서 종류 또는 용도 기준의 Trigger 표를 SOP 부속서로 첨부합니다.
- QA Consultation과 QA Approval을 문서 양식에서부터 구분한다. 결재란 이름 자체를 다르게 두면 "확인했다"와 "승인했다"가 섞이지 않습니다.
- QA 인력 산정은 프로젝트 수가 아니라 문서 이벤트 수로 한다. 개발보고서, Qualification, Validation 등 문서 유형별 연간 발생 건수에 평균 소요시간을 곱해 필요 FTE를 계산하는 방식이 프로젝트 수 기반 산정보다 정확합니다.
- 검토 단계는 3단계 내외로 유지한다. 작성자 → Peer → 팀장(→ 필요 시 QA) 정도가 적당하며, 결재선이 길어질수록 "누군가 보겠지"라는 책임 분산(Diffusion of Responsibility)이 발생하기 쉽습니다.
- 플랫폼화 여부를 함께 점검한다. Platform Method·Platform SOP를 갖춘 조직은 프로젝트가 늘어나도 QA 업무량이 완만하게 증가하지만, 모달리티가 다양한 조직(항체, ADC, mRNA, 세포치료제 등)은 프로젝트 증가와 QA 업무량이 거의 비례합니다.
FAQ
Q1. QA Consultation 단계에서 QA가 낸 코멘트를 개발자가 반영하지 않으면 어떻게 되나요?
Consultation은 승인 절차가 아니므로 최종 발행 여부는 팀장(Accountable)의 결정입니다. 다만 QA가 SOP 위반 소지를 지적했다면, 그 코멘트를 반영하지 않기로 한 사유는 문서에 남겨두는 것이 이후 GMP 문서 전환 시 리스크를 줄이는 방법입니다.
Q2. 개발보고서가 나중에 허가자료에 인용될지는 작성 시점에 알기 어려운데, 어떻게 미리 구분하나요?
작성 시점에 확정이 어렵다면 QA Approval보다는 QA Consultation으로 시작하고, 실제로 Validation Strategy나 허가자료 근거로 채택되는 시점에 정식 QA Review를 소급 적용하는 방식이 현실적입니다. 이 전환 시점을 SOP에 명시해두면 판단 기준이 모호해지지 않습니다.
Q3. QA 검토 범위를 좁히면 품질 리스크가 커지지 않나요?
QA가 보는 항목 수를 줄이는 것이 아니라, QA가 판단해야 할 영역(품질 시스템·규정 준수)과 SME가 판단해야 할 영역(과학적 타당성)을 명확히 나누는 것이 핵심입니다. 오히려 QA가 과학적 판단까지 떠안으면 정작 품질 시스템 검토가 얕아질 위험이 있습니다.
Q4. QA 인력이 부족한 조직에서는 이 구조를 어떻게 시작하는 것이 좋나요?
전체 SOP를 한 번에 바꾸기보다, 가장 자주 QA 병목이 발생하는 문서 유형 한두 개(예: 개발보고서)부터 Trigger 기준과 Checklist를 시범 적용한 뒤, 효과를 확인하고 다른 문서 유형으로 확장하는 방식이 리스크가 적습니다.
결국 QA 검토 범위 논쟁의 핵심은 "QA를 얼마나 많이 참여시키는가"가 아니라 "QA가 무엇을 판단하는가"에 있습니다. 과학적 타당성은 SME와 팀장의 몫이고, 품질 시스템과 규정 준수는 QA의 몫이라는 경계가 문서로 명확히 남아 있을 때, 조직은 QA 인원을 늘리지 않고도 병목을 줄이고 품질 수준은 오히려 높일 수 있습니다.
참고문헌
- ICH Q10, "Pharmaceutical Quality System" — QA(품질보증)가 품질 시스템의 작동 여부를 확인하는 역할이며, 과학적·기술적 판단의 주체가 아니라는 원칙의 근거.
- ICH Q9, "Quality Risk Management" — 문서 및 변경 관리에서 위험 기반(Risk-based) 접근으로 검토 강도를 차등화하는 개념의 근거.
함께 읽으면 좋은 글
- RACI Matrix: 바이오·제약 CMC 조직에서 의사결정이 꼬이는 진짜 원인 — R(실무)·A(결정)·C(자문)·I(공유)의 경계를 다룬 글로, 이번 글에서 다룬 QA Review와 QA Approval의 구분은 RACI에서 C와 A를 나누는 논리와 같은 맥락입니다.
- CTD 작성, 같은 숫자를 다르게 말하면 생기는 일 — 유효숫자와 부등호 표기 체크리스트 — 문서 작성은 결국 허가용 문서를 어떻게 할지가 포인트입니다..
댓글
댓글 쓰기