티스토리 뷰
– “엑셀을 없앤 게 아니라, 엑셀이 할 수 없는 일을 분리했다”
1️⃣ 전환의 출발점: “엑셀이 문제인가?”라는 질문부터 틀렸다
처음엔 다들 이렇게 말한다.
“엑셀이 문제야.”
“사람마다 계산식이 달라.”
“파일이 너무 많아.”
하지만 실제 문제는 엑셀이 아니다.
진짜 문제는 이것이었다
- 데이터 흐름이 없음
- 계산과 판단이 한 셀에 섞여 있음
- 왜 accept했는지 설명할 구조가 없음
엑셀은
👉 툴일 뿐이지
👉 프로세스가 아니다.
그래서 전환은
“엑셀을 없애자”가 아니라
👉 엑셀이 담당하던 역할을 해체하는 작업에서 시작됐다.
2️⃣ 기존 Excel-driven 구조의 실체를 먼저 해부했다
전환 전, 팀의 실제 분석 흐름은 이랬다.
- LC-MS vendor software에서 결과 export
- Excel에 복사
- 개인 템플릿에 붙여넣기
- 숨겨진 계산식 자동 계산
- QC fail 시 → 행 삭제 or 수정
- 최종 결과만 PDF로 남김
문제는 이 모든 과정이:
- SOP에는 한 줄
- 실제론 사람 머릿속
- 흔적은 남지 않음
👉 Audit 리스크는 엑셀이 아니라, “보이지 않는 판단”에 있었다.
3️⃣ 1단계 전환: “Excel을 계산기에서 로그북으로 격하시킨다”
첫 번째 전환 원칙은 단순했다.
엑셀은 계산하지 않는다.
엑셀은 보여주기만 한다.
그래서 가장 먼저 한 일은:
- 모든 핵심 계산식 제거
- slope, accuracy, precision 계산을 외부로 이동
- Excel에는 결과만 read-only로 표시
이 단계에서 엑셀은:
- 결과 확인용
- reviewer comment 기록용
- 설명 자료용
👉 판단의 흔적을 남기는 도구로 역할이 바뀌었다.
4️⃣ 2단계: R 기반 “중간 계층”을 만든다
이때 R이 들어왔다.
하지만 처음부터 “자동화 파이프라인”을 만든 건 아니다.
R의 첫 역할은 아주 제한적이었다
- vendor export 파일 읽기
- 계산 로직 표준화
- 결과를 구조화된 table로 출력
중요한 원칙:
- R은 결정하지 않는다
- R은 계산만 한다
- 판단은 여전히 사람
이렇게 만들어진 구조는:
👉 이때부터 “어디서 무엇이 바뀌었는지”가 설명 가능해졌다.
5️⃣ 가장 힘들었던 지점: 사람의 저항
기술보다 어려웠던 건 사람이다.
- “엑셀이 더 빠르다”
- “이상한 케이스는 내가 알아서 처리해야 한다”
- “R은 너무 딱딱하다”
그래서 전환팀은 한 가지를 포기했다.
👉 모든 예외를 자동화하지 않겠다.
대신:
- R은 모든 exception을 드러내기만
- 판단은 analyst가
- 판단 근거는 comment로 남김
이게 오히려
현장 수용성을 높였다.
6️⃣ 전환의 핵심 분기점: “batch accept 로직”을 분리한 순간
이 팀이 진짜 달라진 건
batch accept 구조를 바꾼 순간이다.
이전:
- 엑셀 안에서 QC fail 삭제
- 평균 재계산
- 최종 값만 남음
이후:
- QC fail은 절대 삭제되지 않음
- accept / reject는 별도 column
- 이유는 반드시 text로 기록
R은:
- 계산 결과
- QC status
- trend 정보만 제공
👉 “왜 이 batch를 accept했는가?”가 데이터 구조 안에 들어왔다.
7️⃣ SOP는 마지막에 썼다 (의외로 중요)
많은 조직이 SOP부터 쓰려 한다.
이 팀은 반대로 했다.
- 실제로 굴러가는 구조를 먼저 만들고
- 문제가 없는지 몇 달 운영하고
- 그다음 SOP로 고정
그래서 SOP는:
- “이상적인 절차”가 아니라
- 이미 검증된 현실 프로세스의 설명서가 됐다.
Audit에서 SOP와 실제 데이터 흐름이
완전히 일치했다.
8️⃣ 전환 후 달라진 audit 질문의 결
이전 audit 질문:
- “이 QC는 왜 제외했나요?”
- “누가 이 계산식을 만들었나요?”
- “이 파일의 이전 버전은 있나요?”
전환 후 audit 질문:
- “자동 계산 로직은 어디에 정의돼 있나요?”
- “Reviewer 판단은 어디에 기록되나요?”
- “script 변경 시 어떻게 통제하나요?”
👉 질문의 수준이 달라졌고,
👉 방어가 아니라 설명이 가능해졌다.
9️⃣ 이 전환에서 얻은 가장 중요한 교훈
이 팀이 정리한 한 문장은 이거였다.
엑셀을 없앤 게 아니라,
엑셀이 해서는 안 되는 일을 빼냈다.
데이터 파이프라인 전환은
IT 프로젝트가 아니다.
그건
👉 판단과 계산을 분리하는 사고방식의 전환이다.

'제약산업' 카테고리의 다른 글
| R 기반 LC-MS 자동화에서 절대 건드리면 안 되는 영역 (0) | 2026.02.16 |
|---|---|
| 21 CFR Part 11을 LC-MS 환경에서 현실적으로 구현하는 방법 (0) | 2026.02.15 |
| Bioanalytical audit 대비용 내부 mock inspection 운영 전략 (0) | 2026.02.14 |
| “왜 이 batch를 accept했는가?”를 설명하는 데이터 구조 (0) | 2026.02.13 |
| Audit에서 가장 자주 공격받는 bioanalysis 코멘트 문장들 (0) | 2026.02.12 |
| ICH M10 이후, ‘Acceptable’의 의미는 어떻게 바뀌었는가 (0) | 2026.02.11 |
| FDA Warning Letter에 반복 등장하는 LC-MS/MS 데이터 무결성 실패 패턴 (0) | 2026.02.10 |
| Method validation 이후에 진짜 시작되는 ‘method maintenance’ (0) | 2026.02.09 |
- Total
- Today
- Yesterday
- 제약산업
- 대사체 분석
- 신약개발
- Multi-omics
- lc-ms/ms
- 분석팀
- 분석
- 제약
- ich m10
- audit
- 시스템
- 약물분석
- Targeted Metabolomics
- 치료제
- 데이터
- 임상시험
- AI
- bioanalysis
- 정밀의료
- Spatial metabolomics
- 미래산업
- 약물개발
- 정량분석
- metabolomics
- 디지털헬스케어
- matrix effect
- LC-MS
- 머신러닝
- 바이오마커
- 신약 개발
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
