티스토리 뷰
시스템이 아니라 ‘판단 구조’를 자동화하려 한 순간부터 무너진다

1️⃣ QC를 ‘계산 문제’로 착각한다
QC 자동화 실패 조직의 첫 번째 공통점은 이거다.
“QC는 기준만 정해두면 자동으로 판별된다.”
그래서 이 조직들은:
- accuracy ±15%
- precision CV ≤15%
- LLOQ ±20%
같은 숫자 조건만 코드로 옮기면 끝이라고 생각한다.
하지만 실제 QC는:
- 숫자 + 맥락
- 기준 + 배경
- 계산 + 해석
예를 들어:
- 동일한 CV 14%라도
- intra-run 초반 drift인지
- batch 후반 matrix build-up인지
- single point outlier인지
의미가 완전히 다르다.
👉 숫자만 자동화한 조직은 QC를 자동화한 게 아니라, QC를 단순화해 버린 것이다.
2️⃣ ‘판단’을 코드 안에 숨긴다
실패 조직의 두 번째 특징은
사람이 하던 판단을 코드 속 if 문으로 밀어 넣는 것이다.
예:
이 로직의 문제는 명확하다.
- 왜 1개까지 허용인가?
- 어느 QC가 실패했는가?
- 반복 발생 여부는?
- 과거 batch와의 연속성은?
이 모든 질문에
코드는 대답하지 못한다.
👉 판단을 자동화하면 audit에서 설명할 언어를 잃는다.
3️⃣ QC failure를 ‘숨겨야 할 이벤트’로 취급한다
QC 자동화 실패 조직에서는
QC fail이 여전히 부정적 사건이다.
그래서 시스템 설계가 이렇게 된다.
- QC fail → 자동 재계산
- QC fail → 제외 후 평균
- QC fail → 로그에는 남지만 화면엔 안 보임
이 구조의 치명적인 문제는:
- QC fail의 발생 패턴이 사라진다
- drift, contamination, carryover 신호를 놓친다
성공 조직은 반대다.
👉 QC fail을 데이터의 핵심 신호로 취급한다.
- fail 자체는 절대 삭제되지 않음
- fail 빈도와 위치를 추적
- batch 판단과 분리해서 기록
4️⃣ ‘왜 accept했는가’를 자동화하려 한다
QC 자동화 실패 조직에서 가장 위험한 시도는 이거다.
“batch accept도 자동으로 결정하자”
이 순간부터 문제가 생긴다.
왜냐하면:
- batch accept는 과학적 판단 + 규제 해석 + 경험적 맥락의 결합이기 때문이다.
자동화된 accept 로직은:
- audit 질문에 취약하다
- edge case에서 무너진다
- 책임 주체가 불분명해진다
👉 Accept / Reject는 자동화 대상이 아니라, 기록 대상이다.
5️⃣ QC 자동화 결과를 ‘최종 결과’로 취급한다
실패 조직은 QC 자동화 결과를 이렇게 다룬다.
- QC status = PASS
- → 바로 report 반영
- → reviewer는 형식적으로 확인
이 구조에선:
- reviewer의 역할이 사라지고
- 책임이 시스템으로 이동하며
- audit에서 “누가 판단했는가?”가 불분명해진다
성공 조직은 다르다.
- QC 자동화 결과 = decision support
- 최종 판단 = 사람
- 판단 근거 = 명시적 기록
6️⃣ QC 자동화 로직의 변경 이력이 관리되지 않는다
QC 자동화 실패 조직은
로직을 이렇게 취급한다.
- “기준은 SOP에 있어”
- “코드는 그냥 구현한 거야”
- “약간 수정했지만 결과는 같아”
이건 audit에서 가장 위험한 상태다.
왜냐하면:
- QC 로직은 데이터 처리 규칙
- 데이터 처리 규칙은 GxP 통제 대상
하지만 실패 조직에서는:
- script version 관리 없음
- 변경 사유 기록 없음
- 영향 평가 없음
👉 QC 자동화 로직은 분석 장비와 같은 수준으로 관리돼야 한다.
7️⃣ QC 자동화 이전에 QC 정의가 합의되지 않았다
이건 의외로 매우 흔하다.
- 팀 A: QC = 기준 충족 여부
- 팀 B: QC = 데이터 신뢰성 판단
- QA: QC = 문서 적합성
이 상태에서 자동화를 하면:
- 모두가 다른 걸 기대한다
- 결과를 두고 계속 싸운다
- 자동화가 오히려 불신을 키운다
성공 조직은:
- QC의 역할부터 합의
- QC 자동화는 그 정의의 구현일 뿐
8️⃣ 자동화 이후 ‘사람의 언어’가 사라진다
QC 자동화 실패 조직의 마지막 공통점은 이거다.
데이터는 남아 있는데, 설명이 없다.
- PASS/FAIL은 있지만 이유가 없다
- 수치는 있지만 판단 맥락이 없다
- 로그는 있지만 narrative가 없다
Audit은 숫자를 보지 않는다.
👉 설명을 본다.
자동화는:
- 숫자를 빠르게 만들 수 있지만
- 설명을 대신해주지는 않는다
9️⃣ 실패 조직과 성공 조직의 결정적 차이
| 구분 | 실패 조직 | 성공 조직 |
| QC 자동화 대상 | 판단 | 계산 |
| QC fail 처리 | 숨김 | 신호로 활용 |
| Accept 결정 | 자동 | 사람 |
| 자동화 결과 | 최종 결론 | 참고 정보 |
| Audit 대응 | 방어 | 설명 |
'제약산업' 카테고리의 다른 글
| Excel-driven 분석팀을 데이터 파이프라인으로 전환한 실제 과정 (0) | 2026.02.17 |
|---|---|
| R 기반 LC-MS 자동화에서 절대 건드리면 안 되는 영역 (0) | 2026.02.16 |
| 21 CFR Part 11을 LC-MS 환경에서 현실적으로 구현하는 방법 (0) | 2026.02.15 |
| Bioanalytical audit 대비용 내부 mock inspection 운영 전략 (0) | 2026.02.14 |
| “왜 이 batch를 accept했는가?”를 설명하는 데이터 구조 (0) | 2026.02.13 |
| Audit에서 가장 자주 공격받는 bioanalysis 코멘트 문장들 (0) | 2026.02.12 |
| ICH M10 이후, ‘Acceptable’의 의미는 어떻게 바뀌었는가 (0) | 2026.02.11 |
| FDA Warning Letter에 반복 등장하는 LC-MS/MS 데이터 무결성 실패 패턴 (0) | 2026.02.10 |
- Total
- Today
- Yesterday
- Multi-omics
- 미래산업
- matrix effect
- Spatial metabolomics
- 신약 개발
- lc-ms/ms
- 신약개발
- 머신러닝
- 대사체 분석
- metabolomics
- bioanalysis
- 바이오마커
- ich m10
- LC-MS
- 분석팀
- 임상시험
- 약물분석
- Targeted Metabolomics
- 디지털헬스케어
- 제약
- 제약산업
- 데이터
- 정량분석
- 약물개발
- 분석
- audit
- AI
- 치료제
- 시스템
- 정밀의료
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
