GMP 환경에서 LC-MS/MS 데이터 내 Traceability 구축 방법

 

GMP 환경에서 LC-MS/MS 데이터 내 Traceability 구축 방법

1. GMP에서 traceability는 왜 LC-MS/MS에서 가장 어려운가

GMP 환경에서 traceability는
이미 오래된 개념이다.

• 원료 → 공정 → 제품
• 시험 → 결과 → 판단

하지만 LC-MS/MS로 들어오면
이 개념이 갑자기 복잡해진다.

이유는 단순하다.
LC-MS/MS 데이터는 ‘숫자’가 아니라 ‘과정’의 산물이기 때문이다.

• 하나의 결과값 뒤에
• 수십 개의 parameter
• 여러 번의 processing
• 사람의 판단

이 겹겹이 쌓여 있다.

그런데 GMP 문서에서는 종종
이 복잡한 과정을
최종 결과 한 줄로 요약해 버린다.

바로 여기서
traceability가 끊어진다.

2. Traceability의 본질: “파일 추적”이 아니라 “판단 추적”

많은 조직이 traceability를 이렇게 이해한다.

• raw data 파일 있음
• 처리 결과 있음
• 보고서 있음

하지만 GMP 관점에서의 진짜 질문은 이것이다.

“이 결과값이 여기까지 오기까지
어떤 선택들이 있었는가?”

LC-MS/MS에서는 특히 다음 판단들이 중요하다.

• peak integration 방식 선택
• noise vs signal 구분
• outlier 처리
• 재분석 여부 결정

이 판단이 데이터와 분리되는 순간,
traceability는 붕괴된다.

3. LC-MS/MS 데이터 흐름을 ‘선형’으로 다시 그려야 한다

Traceability를 구축하려면
먼저 LC-MS/MS 데이터의 생애주기를
선형 스토리로 재정의해야 한다.

3.1 GMP 관점의 LC-MS/MS 데이터 lifecycle

1. 샘플 생성 및 채취
2. 샘플 수령 및 등록
3. 전처리 수행
4. 장비 분석 실행
5. Raw data 생성
6. Data processing
7. 결과 검토 및 승인
8. 보고 및 보관

문제는 대부분의 조직에서
이 단계들이 서로 다른 시스템과 사람에 의해 처리된다는 점이다.

Traceability의 목표는
이 단계를 하나의 끊기지 않는 chain으로 묶는 것이다.

4. Traceability 구축의 출발점: “ID 설계”

모든 traceability는
ID에서 시작해서 ID로 끝난다.

4.1 최소한 필요한 ID 계층

• Sample ID
• Preparation ID
• Injection ID
• Sequence ID
• Raw data ID
• Processed data version ID

이 ID들이
단순히 파일명에 들어가는 게 아니라,
시스템적으로 연결되어야 한다.

예를 들어,

이 결과값 → 이 processed data → 이 raw data →
이 injection → 이 preparation → 이 sample

이 역추적이
사람의 기억 없이 가능해야 GMP traceability다.

5. Raw data의 정의를 명확히 하라 (가장 많이 흔들리는 지점)

GMP audit에서
가장 자주 논쟁이 벌어지는 질문 중 하나는 이것이다.

“LC-MS/MS에서 raw data는 정확히 무엇인가?”

• vendor software 파일?
• instrument binary?
• export된 chromatogram?

조직마다 정의가 다르면
traceability는 무너진다.

현실적인 원칙은 이렇다.

• 장비가 최초로 생성한, 재현 가능한 형태의 데이터를 raw data로 정의
• 해당 데이터는 overwrite 불가
• 처리된 데이터는 항상 versioning

Raw와 processed의 경계를
명확히 문서화하지 않으면
어떤 traceability 시스템도 방어력이 약하다.

6. Data processing 단계에서 traceability가 가장 쉽게 깨진다

LC-MS/MS에서
traceability가 가장 자주 끊어지는 지점은
data processing이다.

6.1 자동 처리 vs 수동 조정

• 자동 integration 결과
• 수동 peak 수정

이 변경이 발생했을 때
다음 질문에 답할 수 있어야 한다.

• 누가 수정했는가
• 언제 수정했는가
• 왜 수정했는가
• 수정 전 결과는 무엇이었는가

이게 남지 않으면
그 순간 traceability는 사라진다.

6.2 Reprocessing과 재분석의 구분

GMP 환경에서는
이 두 개념이 자주 혼용된다.

• Reprocessing: 같은 raw data, 다른 처리
• Reanalysis: 새로운 injection 또는 run

이 구분이 명확히 기록되지 않으면
audit에서 즉시 질문이 나온다.

“왜 결과가 바뀌었는가?”

Traceability는
결과 변화의 이유를 설명하는 능력이다.

7. Traceability를 떠받치는 시스템 구조

7.1 CDS + CDMS + LIMS의 역할 분담

• CDS: 데이터 생성과 1차 처리
• CDMS: raw data 보존과 무결성
• LIMS: 샘플과 결과의 공식 기록

Traceability는
이 세 시스템이 역할을 침범하지 않고 연결될 때 가장 강해진다.

7.2 Audit trail은 “있음”이 아니라 “검토됨”이어야 한다

Audit trail이 존재해도
아무도 보지 않으면 의미가 없다.

GMP에서는
다음이 명확해야 한다.

• 누가 audit trail을 검토했는가
• 언제 검토했는가
• 이상 징후가 있었는가

Audit trail review 자체가
traceability의 일부다.

8. 사람의 판단을 traceability 안으로 끌어들이는 방법

많은 조직에서
traceability가 실패하는 이유는 이것이다.

“사람의 판단은 시스템 밖에서 이뤄진다.”

회의, 메신저, 구두 합의…
이 순간 판단은 사라진다.

해결책은 단순하지만 어렵다.

• 판단을 선택지 기반으로 구조화
• 자유 텍스트가 아니라 사유 코드 + 설명
• 결과 데이터에 직접 귀속

이렇게 해야
판단도 추적 가능한 객체가 된다.

9. Traceability는 문서가 아니라 ‘습관’이다

GMP 환경에서
traceability를 잘 구축한 조직들의 공통점은
시스템보다 문화다.

• “나중에 설명할 수 있을까?”를 먼저 생각한다
• 애매하면 기록한다
• 편한 길보다 방어 가능한 길을 선택한다

Traceability는
추가 업무가 아니라
일하는 방식의 변화다.

10. GMP LC-MS/MS traceability의 최종 질문

모든 시스템을 갖췄다고 해도
마지막으로 이 질문에 답해야 한다.

“6개월 후,
이 데이터 하나를 놓고
우리는 처음부터 끝까지 설명할 수 있는가?”

이 질문에
자신 있게 “예”라고 말할 수 있다면
그 조직의 LC-MS/MS 데이터는
이미 GMP traceability를 갖췄다.

마무리하며

LC-MS/MS는
GMP 환경에서 가장 강력한 도구이자
가장 위험한 도구다.

정확한 만큼,
설명하지 못하면 치명적이다.

Traceability는
데이터를 감시하는 장치가 아니라
과학을 보호하는 안전장치다.