티스토리 뷰

728x90

– “엑셀을 없앤 게 아니라, 엑셀이 할 수 없는 일을 분리했다”

1️⃣ 전환의 출발점: “엑셀이 문제인가?”라는 질문부터 틀렸다

처음엔 다들 이렇게 말한다.

“엑셀이 문제야.”
“사람마다 계산식이 달라.”
“파일이 너무 많아.”

하지만 실제 문제는 엑셀이 아니다.

진짜 문제는 이것이었다

  • 데이터 흐름이 없음
  • 계산과 판단이 한 셀에 섞여 있음
  • 왜 accept했는지 설명할 구조가 없음

엑셀은
👉 툴일 뿐이지
👉 프로세스가 아니다.

그래서 전환은
“엑셀을 없애자”가 아니라
👉 엑셀이 담당하던 역할을 해체하는 작업에서 시작됐다.

2️⃣ 기존 Excel-driven 구조의 실체를 먼저 해부했다

전환 전, 팀의 실제 분석 흐름은 이랬다.

  1. LC-MS vendor software에서 결과 export
  2. Excel에 복사
  3. 개인 템플릿에 붙여넣기
  4. 숨겨진 계산식 자동 계산
  5. QC fail 시 → 행 삭제 or 수정
  6. 최종 결과만 PDF로 남김

문제는 이 모든 과정이:

  • SOP에는 한 줄
  • 실제론 사람 머릿속
  • 흔적은 남지 않음

👉 Audit 리스크는 엑셀이 아니라, “보이지 않는 판단”에 있었다.

3️⃣ 1단계 전환: “Excel을 계산기에서 로그북으로 격하시킨다”

첫 번째 전환 원칙은 단순했다.

엑셀은 계산하지 않는다.
엑셀은 보여주기만 한다.

그래서 가장 먼저 한 일은:

  • 모든 핵심 계산식 제거
  • slope, accuracy, precision 계산을 외부로 이동
  • Excel에는 결과만 read-only로 표시

이 단계에서 엑셀은:

  • 결과 확인용
  • reviewer comment 기록용
  • 설명 자료용

👉 판단의 흔적을 남기는 도구로 역할이 바뀌었다.

4️⃣ 2단계: R 기반 “중간 계층”을 만든다

이때 R이 들어왔다.
하지만 처음부터 “자동화 파이프라인”을 만든 건 아니다.

R의 첫 역할은 아주 제한적이었다

  • vendor export 파일 읽기
  • 계산 로직 표준화
  • 결과를 구조화된 table로 출력

중요한 원칙:

  • R은 결정하지 않는다
  • R은 계산만 한다
  • 판단은 여전히 사람

이렇게 만들어진 구조는:

 
Raw data (vendor)
Standardized export
R calculation layer
Result tables + flags
Excel / Report
 
 

👉 이때부터 “어디서 무엇이 바뀌었는지”가 설명 가능해졌다.

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부터 쓰려 한다.
이 팀은 반대로 했다.

  1. 실제로 굴러가는 구조를 먼저 만들고
  2. 문제가 없는지 몇 달 운영하고
  3. 그다음 SOP로 고정

그래서 SOP는:

  • “이상적인 절차”가 아니라
  • 이미 검증된 현실 프로세스의 설명서가 됐다.

Audit에서 SOP와 실제 데이터 흐름이
완전히 일치했다.

8️⃣ 전환 후 달라진 audit 질문의 결

이전 audit 질문:

  • “이 QC는 왜 제외했나요?”
  • “누가 이 계산식을 만들었나요?”
  • “이 파일의 이전 버전은 있나요?”

전환 후 audit 질문:

  • “자동 계산 로직은 어디에 정의돼 있나요?”
  • “Reviewer 판단은 어디에 기록되나요?”
  • “script 변경 시 어떻게 통제하나요?”

👉 질문의 수준이 달라졌고,
👉 방어가 아니라 설명이 가능해졌다.

9️⃣ 이 전환에서 얻은 가장 중요한 교훈

이 팀이 정리한 한 문장은 이거였다.

엑셀을 없앤 게 아니라,
엑셀이 해서는 안 되는 일을 빼냈다.

데이터 파이프라인 전환은
IT 프로젝트가 아니다.

그건
👉 판단과 계산을 분리하는 사고방식의 전환이다.

 

 

Excel-driven 분석팀을 데이터 파이프라인으로 전환한 실제 과정
Excel-driven 분석팀을 데이터 파이프라인으로 전환한 실제 과정

728x90