R 기반 LC-MS 데이터 자동화 파이프라인

실제 조직 도입 사례 –코드를 들여온 게 아니라, 판단을 구조화했다”

1. 자동화는 늘 필요했지만, 아무도 시작하지 못했다

LC-MS 분석팀에서 “자동화”라는 단어는
항상 회의실 어딘가에 떠 있었지만,
실제로 손에 잡히는 형태로 내려온 적은 거의 없었다.

• 데이터는 늘 많았고
• 검토 시간은 늘 부족했고
• QC fail이 나면 항상 “사람”이 원인이었다

하지만 그걸 구조적으로 바꾸자는 논의는
언제나 이렇게 끝났다.

“일단 지금도 돌아가니까…”

이 사례의 시작도
대부분의 제약·CRO 조직과 다르지 않았다.

2. 배경: Multi-project, Multi-batch, Multi-analyst 환경

이 조직은 다음과 같은 특징을 갖고 있었다.

• PK / TDM / tox bioanalysis를 동시에 수행
• LC-MS/MS 장비 6대 이상
• 분석가 경력 분포가 매우 넓음 (신입 ~ 10년 이상)
• 프로젝트 수는 많지만, batch당 샘플 수는 상대적으로 적음

문제는 규모가 커질수록 재현성이 아니라 “일관성”이 무너진다는 점이었다.

• 같은 method인데 QC 해석이 다르고
• 같은 결과인데 batch comment가 달랐고
• audit 대응 시 설명이 사람마다 달랐다

3. 문제를 정의하는 데 6개월이 걸렸다

흥미로운 점은
이 조직이 처음부터 “R 자동화”를 목표로 하지 않았다는 것이다.

초기의 질문은 이것이었다.

“우리는 왜 같은 실수를 계속 반복하는가?”

이를 정리하면서
다음과 같은 패턴이 드러났다.

반복되는 문제 유형

1. QC는 pass인데, 결과가 찜찜한 batch
2. IS response가 애매한데, 기준이 없어 넘어간 케이스
3. 나중에 보면 drift였지만, 당시엔 몰랐던 변화
4. audit에서 “왜 이 판단을 했냐”는 질문에 말이 달라지는 상황

즉, 문제는
데이터 부족이 아니라, 판단의 기록과 구조가 없다는 것이었다.

4. “Raw data 자동화”를 포기한 결정

초기 논의에서 가장 먼저 나온 아이디어는 이것이었다.

“Raw data를 R로 읽어서 peak integration부터 자동화하자”

하지만 이 아이디어는
가장 먼저 폐기되었다.

이유는 명확했다.

• vendor software validation 문제
• 규제 리스크
• 결과 불일치 시 책임 소재 불분명

대신 조직은 이렇게 방향을 틀었다.

“우리가 매번 사람 손으로 반복하는 판단을 자동화하자”

이 순간부터
R은 “분석 도구”가 아니라
판단 구조화 도구가 되었다.

5. 자동화의 출발점: Excel을 버리지 않았다

많은 자동화 프로젝트가 실패하는 이유는
기존 workflow를 부정하기 때문이다.

이 조직은 반대로 접근했다.

• Vendor software 결과는 그대로 사용
• Excel export도 그대로 유지
• 단, Excel 이후 단계를 R로 연결

즉,

“지금 하는 일을 그대로 하되,
더 체계적으로 기록하고 비교하자”

이 접근이
현장 저항을 거의 없앴다.

6. 1단계 도입: Batch QC Summary 자동화

가장 먼저 자동화한 것은
QC summary였다.

이유는 단순하다.

• 모든 프로젝트에 공통
• 판단 요소가 반복적
• 사람마다 표현이 다름

기존 방식

• QC 결과 확인
• %Bias, %CV 확인
• 개인 경험에 따라 코멘트 작성

R 도입 이후

• QC level별 분포 자동 계산
• batch 간 QC trend 시각화
• 이전 batch 대비 변화량 자동 표시

중요한 변화는 이것이었다.

QC 결과를 “통과 여부”가 아니라
“위치와 방향”으로 보기 시작했다

7. 예상 밖의 효과: 신입과 시니어의 간극이 줄어들다

자동화의 가장 큰 수혜자는
의외로 신입 연구원이었다.

• “이 QC가 왜 불안정한지”
• “왜 이 batch가 찜찜한지”

이전에는
말로만 전해지던 판단 기준이
그래프와 수치로 보이기 시작했다.

시니어 연구원 입장에서도 변화가 있었다.

“설명해야 할 게 줄어든 게 아니라,
설명이 훨씬 쉬워졌다”

8. 2단계: IS response를 ‘보정 인자’가 아닌 ‘센서’로 사용

다음 단계는
IS (Internal Standard) 데이터였다.

기존에는

• calibration 보정용
• QC fail 원인 추정용

정도로만 사용되던 IS를
시스템 상태 지표로 재정의했다.

R 파이프라인에서 한 일

• IS response의 batch-to-batch 변화 추적
• 장비별 IS 분포 비교
• analyte별 IS 상관성 모니터링

이 과정에서
놀라운 사실이 하나 드러났다.

특정 장비는 QC fail 전에
항상 IS variability가 먼저 증가했다

즉,
문제가 생기기 전 신호가 이미 데이터에 있었던 것이다.

9. 조직 문화의 변화: “문제 발견”이 아니라 “문제 예방”

이 시점부터
분석팀 회의의 분위기가 달라졌다.

이전 회의 질문:

• “왜 QC fail이 났지?”

이후 회의 질문:

• “이 drift는 언제부터 시작됐지?”
• “다음 batch에서 문제가 될 가능성은?”

R 자동화는
분석팀을 사후 대응 조직에서 사전 관리 조직으로 바꿔 놓았다.

10. 3단계: Batch 비교 자동화와 ‘Golden pattern’

조직은 한 걸음 더 나아갔다.

• “잘 나왔던 batch”를 기준으로
• 이후 batch들을 자동 비교

이를 내부에서는
Golden batch / Golden pattern이라고 불렀다.

R은 각 batch에 대해

• QC 분포 유사도
• IS response 거리
• RT drift 정도

를 자동 계산했고,
이 결과는 batch review 회의에서
공통 언어가 되었다.

11. Audit 대응에서의 결정적 변화

이 파이프라인의 진짜 가치는
외부 audit에서 드러났다.

이전 audit:

• “이 판단은 왜 이렇게 했나요?”
• → 사람 설명 + 개인 경험

이후 audit:

• “이 판단은 왜 이렇게 했나요?”
• → 정의된 지표 + 자동 생성 리포트

감사관의 반응은 의외로 단순했다.

“이렇게 정리된 데이터를 보는 게 훨씬 낫네요”

12. 실패도 있었다: 처음부터 모든 걸 자동화하려 했던 시도

물론 실패한 시도도 있었다.

• anomaly detection을 너무 복잡하게 설계
• 머신러닝 모델을 먼저 도입하려던 시도
• 너무 많은 지표를 한 번에 보여주려던 대시보드

결국 조직이 배운 교훈은 이것이었다.

자동화는 똑똑해지는 것보다, 명확해지는 것이 먼저다.

13. 현재 상태: R은 “연구원이 안 보이는 도구”가 되었다

가장 성공적인 지점은 이것이다.

• 대부분의 연구원은 R 코드를 모른다
• 하지만 자동화 결과는 매일 본다
• 판단 기준은 자연스럽게 공유된다

즉, R은
전문가의 장난감이 아니라 조직의 인프라가 되었다.

14. 이 사례가 주는 현실적인 메시지

이 조직의 사례는
R을 잘 쓴 이야기가 아니다.

• 데이터를 새로 만들지 않았다
• workflow를 갈아엎지 않았다
• 사람을 배제하지 않았다

대신,

사람이 하던 판단을
데이터 흐름으로 고정했을 뿐이다

15. 정리하며: 자동화의 본질은 “속도”가 아니다

LC-MS 자동화를 이야기하면
속도와 효율을 먼저 떠올린다.

하지만 이 사례에서 자동화의 진짜 효과는 이것이었다.

• 판단의 일관성
• 설명 가능성
• 조직 기억의 축적
• 규제 대응력

그리고 이것들은
단기간 성과보다 훨씬 오래 남는다.

 

R 기반 LC-MS 데이터 자동화 파이프라인