티스토리 뷰

728x90

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

QC 자동화가 실패하는 조직의 공통 특징
QC 자동화가 실패하는 조직의 공통 특징

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 문으로 밀어 넣는 것이다.

예:

 
if (QC_fail <= 1) batch = "ACCEPT" else batch = "REJECT"

이 로직의 문제는 명확하다.

  • 왜 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 대응 방어 설명
728x90