Method validation 이후에 진짜 시작되는 ‘method maintenance’

 

1. Validation은 끝났는데, 분석은 왜 점점 어려워지는가

Method validation을 마치면
분석팀은 잠시 숨을 돌린다.

• accuracy OK
• precision OK
• matrix effect 평가 완료
• stability 문제 없음

보고서는 깔끔하고,
QA review도 통과한다.

하지만 이상하게도
그 이후부터 이런 말이 나오기 시작한다.

“예전만큼 결과가 안 예쁘네요.”
“이 method, 원래 이렇지 않았는데요…”

이 지점에서 처음 드러나는 사실은 이것이다.

Validation은 분석법의 ‘완성’이 아니라
‘출시’에 불과하다.

 

2. Validation이 보장하는 것과, 보장하지 않는 것

많은 사람들이
validation에 대해 오해한다.

Validation이 보장하는 것은 딱 이것이다.

“이 방법은
특정 조건과 특정 시점에서
규제 기준을 만족했다.”

반대로 validation이 보장하지 않는 것은 훨씬 많다.

• 시간이 지나도 유지될 것
• matrix가 바뀌어도 안정적일 것
• 장비 상태가 변해도 동일할 것

즉,

validation은 가능성의 증명이지
지속성의 보증이 아니다.

 

3. Method maintenance가 필요한 진짜 이유

LC-MS/MS method는
정적인 프로토콜이 아니다.

• 장비는 매일 조금씩 변하고
• column은 서서히 늙고
• source는 조용히 오염된다

그리고 sample은
validation 때보다 훨씬 다양해진다.

이 모든 변화는
validation report에는 등장하지 않는다.

그래서 method maintenance는
“문제가 생기면 대응하는 것”이 아니라,

문제가 생기기 전에
변화를 읽어내는 활동이다.

 

4. 첫 번째 붕괴 지점: calibration curve의 ‘익숙한 변화’

Method maintenance가 없을 때
가장 먼저 흔들리는 것은 calibration curve다.

• slope가 조금 달라짐
• intercept가 미묘하게 이동
• low end에서만 bias 발생

하지만 QC는 통과한다.

그래서 이런 말이 나온다.

“큰 문제는 아니에요.”

이 순간,
method는 이미 maintenance가 필요한 상태다.

5. 두 번째 붕괴 지점: IS는 정상인데 결과가 흔들릴 때

Validation 당시에는
IS가 analyte를 잘 따라갔다.

하지만 시간이 지나면
다음과 같은 현상이 나타난다.

• IS CV는 안정
• analyte CV만 증가
• 특정 matrix에서만 문제

이건 IS 실패가 아니다.

시스템 환경이 변했는데
method가 그 변화를 감지하지 못하고 있다는 신호다.

 

6. Maintenance 없는 method는 사람 기억에 의존한다

Method maintenance 체계가 없으면
분석은 이렇게 운영된다.

• “이건 예전에 이렇게 했었지”
• “그때는 그냥 넘어갔었어요”
• “이 method는 원래 좀 그래요”

이 말들이 쌓이면
method는 더 이상 문서가 아니라
사람 머릿속에만 존재하는 기술이 된다.

Audit에서 가장 위험한 상태다.

7. Method maintenance는 ‘수정’이 아니라 ‘관찰’이다

많은 분석가는
maintenance를 이렇게 생각한다.

• 조건 바꾸기
• 세척 강화
• 파라미터 조정

하지만 진짜 maintenance의 핵심은
수정 이전의 관찰이다.

• slope trend
• IS/analyte ratio drift
• low-end bias 변화
• batch 간 재현성

이 지표들을
“정기적으로 본다”는 것 자체가
이미 maintenance다.

8. SOP에서 maintenance가 빠지는 이유

대부분의 SOP는
validation까지만 상세하다.

그 이후에는 이런 문장으로 끝난다.

“본 분석법은 정기적으로 관리한다.”

이 문장은
아무것도 정의하지 않는다.

현실적인 SOP에는
이 질문들이 들어가야 한다.

• 무엇을 볼 것인가
• 얼마나 자주 볼 것인가
• 어느 수준에서 action을 취할 것인가

9. Method maintenance의 최소 구성 요소

아주 단순화하면
method maintenance는 이 네 가지로 시작할 수 있다.

1. Trend 관리
   – calibration slope, IS response
2. Boundary 관리
   – LLOQ 안정성, low-end bias
3. Event 기록
   – cleaning, column 교체, PM 이력
4. 판단 기준
   – “언제까지 OK인가”에 대한 내부 기준

이 네 가지가 없으면
method는 언젠가 반드시 무너진다.

10. R 기반 자동화는 maintenance를 ‘일상화’한다

R 기반 데이터 파이프라인을 도입한 조직에서
가장 크게 달라지는 점은 이것이다.

“문제를 찾아서 보는 게 아니라
문제가 눈에 먼저 보인다.”

• batch 간 slope 자동 비교
• QC 위치별 편차 시각화
• 시간에 따른 drift 트렌드

이건 고급 기술이 아니다.

method를 살아 있는 시스템으로 다루기 위한
최소한의 장치다.

 

11. QA 관점에서 method maintenance는 ‘통제 증거’다

Audit에서
QA가 정말로 보고 싶어 하는 것은 이것이다.

• 문제가 없었다는 주장 ❌
• 문제가 없도록 관리해 왔다는 증거 ⭕

Method maintenance 기록은
바로 그 증거다.

• “왜 이 batch를 accept했는가”
• “왜 이 조건을 유지하고 있는가”

이 질문에 답할 수 있는 유일한 근거가
maintenance다.

12. Method는 나이를 먹는다

이 문장은
현업에서는 너무나 사실이다.

Method는 시간이 지나면
validation 당시와 같은 상태를 유지할 수 없다.

문제는
그 변화를 인정하느냐,
아니면
모른 척하느냐의 차이다.

Method maintenance는
그 변화를 관리 가능한 영역으로 끌어온다.

13. Validation보다 maintenance가 더 어려운 이유

Validation은
정해진 범위 안에서 한다.

하지만 maintenance는
정답이 없다.

• 언제 action을 취할지
• 어디까지 허용할지
• 언제 re-validation으로 갈지

이 판단은
분석팀의 경험과 철학이 드러나는 지점이다.

그래서 maintenance가
진짜 실력이다.

14. 정리하며: Validation은 증명, maintenance는 책임이다

마지막으로 이 문장을 남기고 싶다.

Validation은
“이 방법이 가능하다”는 증명이고,
Method maintenance는
“이 방법을 계속 쓸 수 있다”는 책임이다.

보고서는 validation으로 끝나지만,
분석은 maintenance에서 완성된다.

 

Method validation 이후에 진짜 시작되는 ‘method maintenance’