제약회사 연구원의 블로그

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

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

1. “Carryover가 좀 있었습니다”는 왜 항상 문제가 되는가Audit이나 내부 QA review에서분석팀이 가장 자주 하는 말 중 하나가 이것이다.“Carryover가 조금 있었습니다.”하지만 이 문장은QA 입장에서 아무 의미가 없다.왜냐하면 QA는‘조금’이라는 단어로는아무 판단도 할 수 없기 때문이다.QA가 듣고 싶은 질문은 이것이다.얼마나 있었는가언제 발생했는가결과에 영향을 주었는가어떻게 통제하고 있는가2. Carryover는 ‘현상’이 아니라 ‘리스크 시나리오’다분석팀은 carryover를주로 기술적 현상으로 본다.needle wash 부족tubing adsorptioncolumn memory effect하지만 QA 언어에서 carryover는데이터 무결성 리스크다.즉,“이전 시료의 정보가다..