제약회사 연구원의 블로그

코드를 설명하지 말고, “통제되고 있다”는 느낌을 만들어라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는👉 “측정된..

규정을 만족시키는 것이 아니라, 분석을 망치지 않는 구현LC-MS 분석실에서“Part 11 대응은 다 되어 있나요?”라는 질문이 나오면대부분 이렇게 답한다.“Vendor software에서 다 지원합니다.”그리고 audit에서 바로 다음 질문이 나온다.“그럼 실제로 어떻게 운영하고 있습니까?”이 두 질문 사이에 존재하는 간극이바로 Part 11 실패의 시작점이다.1️⃣ LC-MS에서 Part 11이 어려운 진짜 이유21 CFR Part 11의 요구사항은 문장만 보면 단순하다.electronic record의 신뢰성변경 불가성추적 가능성전자 서명의 진정성문제는 LC-MS 데이터가 가진 현실적인 특성이다.raw data 용량 큼재분석(reprocessing)이 빈번함integration 조정이 필수적임장비별..

잘 보이기 위한 점검이 아니라, 망가질 지점을 드러내는 연습많은 조직에서 mock inspection은 이렇게 진행된다.일정 공지준비 기간 부여정리된 문서 제출무난한 질문“큰 문제 없음” 결론그리고 실제 audit에서완전히 다른 질문을 맞는다.이유는 간단하다.그 mock inspection은 검증이 아니라 발표 연습이었기 때문이다.1️⃣ Mock inspection의 목적을 다시 정의해야 한다진짜 mock inspection의 목적은 이것이다.“우리 조직이 audit에서 실패할 지점을미리, 내부에서 터뜨리는 것”그래서 좋은 mock inspection은불편하고방어적 감정을 자극하고끝나고 나면 기분이 썩 좋지 않다.만약 mock inspection이 끝났는데모두 안심하고 있다면,그건 대부분 실패한 mock..