제약회사 연구원의 블로그

– 성능보다 먼저 필요한 건 “이 결과를 누가 책임질 수 있는가”다1️⃣ LC-MS 분석은 ‘맞추는 기술’이 아니라 ‘설명해야 하는 기술’이다일반적인 AI 적용 사례에서는정확도가 어느 정도 높으면 실사용이 가능하다.하지만 LC-MS는 다르다.결과 하나가 임상 의사결정으로 이어지고규제 문서에 포함되며수년 뒤 audit에서 다시 꺼내진다즉 LC-MS 결과는 항상 이 질문을 동반한다.“왜 이렇게 나왔는가?”Explainable AI가 없으면이 질문에 답할 방법이 없다.👉 LC-MS 분석에서 설명 불가능한 결과는틀린 결과와 동일한 취급을 받는다.2️⃣ QA와 규제는 ‘모델’을 보지 않고 ‘판단 경로’를 본다현장에서 자주 벌어지는 장면이 있다.데이터 사이언티스트:“이 모델은 accuracy가 98%입니다”QA의..

모델은 맞았지만, 아무도 책임질 수 없었다1️⃣ PoC의 목표 자체가 잘못 설정된다대부분의 AI-LC-MS PoC는 이렇게 시작한다.“AI로 이거 할 수 있나요?”그래서 PoC의 성공 기준이:accuracy 몇 %anomaly detect 성공사람보다 잘 맞춤같은 기술 데모 수준에 머문다.하지만 운영 단계의 질문은 완전히 다르다.이 결과로 무엇을 결정할 것인가?이 판단의 책임자는 누구인가?이 결과가 틀렸을 때 어디까지 허용되는가?👉 PoC는 “가능한가?”에 답하지만,👉 운영은 “써도 되는가?”에 답해야 한다.이 간극을 처음부터 설계하지 않으면PoC는 성공해도 프로젝트는 멈춘다.2️⃣ AI가 ‘판단’을 대신하도록 설계된다PoC 단계에서 가장 흔한 설계 오류는 이거다.“AI가 batch 이상 여부를 판단..

코드를 설명하지 말고, “통제되고 있다”는 느낌을 만들어라1️⃣ QA가 R 자동화를 불신하는 이유부터 직시해야 한다QA가 R 자동화 결과를 처음 볼 때, 머릿속에는 거의 항상 이 질문들이 떠 있다.이 계산이 항상 같은 방식으로 수행된다는 걸 어떻게 보장하지?누가 언제 로직을 바꿀 수 있고, 바꾸면 어떻게 알지?이 결과가 틀렸을 때 추적 가능한 흔적이 남아 있나?이 자동화가 판단을 대신하지는 않나?중요한 사실은 이거다.👉 QA는 R을 싫어하지 않는다.👉 QA는 통제되지 않는 판단을 싫어한다.그래서 문서의 목적은“이 스크립트가 얼마나 똑똑한가”가 아니라👉 “이 자동화는 사람보다 더 예측 가능하다”는 걸 보여주는 데 있다.2️⃣ 실패하는 문서의 공통점: 코드 설명부터 시작한다QA 신뢰를 못 얻는 문서들은..

값을 비교하지 말고, “정상이라고 말할 수 있는 범위”를 비교하라1️⃣ Batch 비교 자동화가 실패하는 이유는 거의 하나다자동화를 시작할 때, 대부분 이렇게 묻는다.“이 batch가 이전 batch랑 얼마나 다른가요?”이 질문 자체가 이미 함정이다.왜냐하면:이전 batch는 기준이 아니고다르다는 말에는 방향도, 의미도 없기 때문이다.그래서 실패하는 자동화는:batch A vs batch B값 차이 %, fold changethreshold 초과 여부같은 숫자 비교에 머문다.👉 하지만 batch 비교의 목적은“다른지”가 아니라“정상 범위 안에 있는지”다.2️⃣ 비교 기준의 출발점은 ‘reference batch’가 아니다많은 조직이 이렇게 시작한다.“Golden batch랑 비교하자”“지난 run 평균..

“가장 잘 나온 batch”를 고르는 게 아니라, “판단의 기준”을 고정하는 일1️⃣ Golden batch가 실패하는 가장 흔한 출발점대부분 조직은 Golden batch를 이렇게 시작한다.“지금까지 데이터 중에서 제일 깔끔한 batch 하나를 골라두자.”그래서:QC 잘 나온 날deviation 없었던 runchromatogram 예쁜 batch를 하나 골라서👉 ‘Golden batch’라는 이름을 붙인다.하지만 이 접근은 거의 항상 실패한다.왜냐하면:그 batch가 왜 좋은지 설명되지 않고재현 가능한 조건이 정의되지 않으며시간이 지나면 “저건 옛날 장비/옛날 사람” 얘기가 되기 때문이다.👉 Golden batch는 결과물이 아니라, 기준의 집합이다.2️⃣ Golden batch를 ‘참조 데이터’로..

시스템이 아니라 ‘판단 구조’를 자동화하려 한 순간부터 무너진다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️⃣ ‘판단’을 코드 안에 숨긴다실패 조직의 두 번째 특징..

– “엑셀을 없앤 게 아니라, 엑셀이 할 수 없는 일을 분리했다”1️⃣ 전환의 출발점: “엑셀이 문제인가?”라는 질문부터 틀렸다처음엔 다들 이렇게 말한다.“엑셀이 문제야.”“사람마다 계산식이 달라.”“파일이 너무 많아.”하지만 실제 문제는 엑셀이 아니다.진짜 문제는 이것이었다데이터 흐름이 없음계산과 판단이 한 셀에 섞여 있음왜 accept했는지 설명할 구조가 없음엑셀은👉 툴일 뿐이지👉 프로세스가 아니다.그래서 전환은“엑셀을 없애자”가 아니라👉 엑셀이 담당하던 역할을 해체하는 작업에서 시작됐다.2️⃣ 기존 Excel-driven 구조의 실체를 먼저 해부했다전환 전, 팀의 실제 분석 흐름은 이랬다.LC-MS vendor software에서 결과 exportExcel에 복사개인 템플릿에 붙여넣기숨겨진 계..

자동화가 신뢰를 높일 때와, 무너뜨릴 때의 경계선R은 LC-MS 분석팀에게 엄청난 자유를 준다.수백 batch의 QC를 몇 초 만에 비교하고,사람이 놓치는 trend를 자동으로 잡아낸다.하지만 바로 그 자유 때문에R 자동화는 잘못 쓰이면 audit 리스크를 증폭시키는 도구가 된다.규제기관은 R을 싫어하지 않는다.그들이 싫어하는 것은 통제되지 않는 자동화다.1️⃣ Raw data 자체를 변형·대체하는 자동화❌ 가장 위험한 자동화raw data 파일을 R에서 직접 수정peak intensity를 외부 계산값으로 덮어쓰기vendor software 결과를 “정제된 값”으로 치환이 순간부터 R은analysis tool이 아니라 data integrity 리스크가 된다.LC-MS에서 raw data는👉 “측정된..