현장이 저를 가르쳤습니다
| #1 Problem Definition First 정의부터 세운다 | #2 모집단 기반 사고 전체에서 시작한다 |
| #3 Task Decomposition 핵심 액션을 분해한다 | #4 5Why 근본원인 탐색 왜를 반복한다 |
| #5 탐색적 데이터 분석 데이터로 패턴을 찾는다 | #6 Analogical Transfer 본질을 꺼내 전용한다 |
| #7 Anchor Point 전환 기준을 바꾼다 | #8 Iterative Validation 반복하며 줄여간다 |
| #9 Pipeline Architecture 단계별로 표준화한다 | #10 Temporal Pattern Discovery 운영하며 발견한다 |
| #11 Empirical Standard Setting 반증으로 확정한다 | |
저는 방법론을 공부한 적 없습니다
AX(AI Transformation) 필드매니저로 일하고 있습니다. 검품센터 현장에서 문제를 가장 먼저 감지하고, 자동화와 프로세스 개선이 실제로 작동할 때까지 책임지는 역할입니다.
어느 날 업무 지시가 하달됐습니다.
단, 자동화 개발에 들어가기 전에 제가 먼저 업무 구조를 파악하고 1차로 자동화를 진행해야 했습니다. 개발자가 만들기 전에, 현장이 먼저 이해해야 한다는 원칙 때문입니다.
그렇게 문제 앞에 혼자 섰습니다. 그리고 그냥 풀었습니다.
나중에 돌아보니 방법론이 11개 들어가 있었습니다. 교과서에서 배운 게 아니라, 현장이 가르쳐준 것들이었습니다.
운송지연이 뭔지부터 물었습니다
매뉴얼을 펼쳤습니다. 처리 방법을 읽기 전에, 먼저 든 생각이 있었습니다.
지시를 받았다고 바로 처리에 들어가는 것이 아니라, 정의를 먼저 세웠습니다.
택배사·고객사·고객의 문제로 인해 상품이 센터로 들어오지 않아,
'주문접수' 상태에서 계속 머물러 있는 주문.
이 정의가 나오자 다음이 자연스럽게 보였습니다. '주문접수' 상태에 머물러 있다는 건, 아직 입고완료가 되지 않았다는 뜻입니다.
운송지연 필터를 바로 적용하는 대신, 전체 홈페이지 주문을 먼저 펼쳤습니다. 필터가 올바른지 검증하려면 전체를 봐야 하기 때문입니다.
"입고완료 이전 주문 = 운송지연 처리 대상"
입고완료부터는 우리 시스템에서 모두 추적이 가능합니다. 여기서부터 시작하면 됩니다.
2주 동안 900건을 직접 정리했습니다
매뉴얼을 읽으면서 처리 과정 전체를 가장 작은 단위로 분해했습니다.
"찾는다" 앞에서 멈추고 "왜"를 반복했습니다. 어떤 주문을 찾아야 하는지가 명확하지 않으면 나머지가 의미 없기 때문입니다.
|
Q
|
"어떤 주문을 찾아야 하는가?" |
|
Q
|
"운송지연 주문이란 무엇인가?" |
|
Q
|
"입고완료 이전 주문 = 추적 가능한 범위" |
|
!
|
시작점 확정. |
약 2주에 걸쳐 과거 주문 900건을 직접 정리했습니다. 2주가 지나자 세 가지 유형이 보이기 시작했습니다.
| 분류 | 설명 |
|---|---|
| 미회수 | 반품 요청은 됐지만 실제로 물건이 돌아오지 않은 주문. 가장 많은 비중. |
| 배송 문제 | 배송 과정에서 이슈가 발생한 주문. |
| OD (SSF) | 별도 카테고리로 분류되는 예외 주문. |
택배사 데이터를 기준으로 우리 정보를 변경하다 보니 차이가 계속 발생하고 있었습니다. 송장으로 찾으면 미회수인데, 정보에는 안 잡히는 상황이 반복됐습니다.
이 문제의 해결책이 보이기 전에, 예상치 못한 사건이 터졌습니다.
CJ 주문이 한진으로 재접수됐습니다
연동 문제로 CJ 택배로 접수되어야 할 주문들이 한진 택배로 재접수되면서 송장 정보가 전부 꼬여버렸습니다.
고민하던 중, 뇌리에 스친 것이 있었습니다. Phase 1에서 운영했던 난수송장 → 정상송장 교체 RPA.
기존 도구의 본질을 꺼내서, 전혀 다른 문제에 그대로 적용했습니다.
|
1
|
5600으로 시작하지만 원래부터 한진으로 오는 브랜드는 제외하도록 엑셀 데이터 가공 |
|
2
|
택배사 데이터를 해당 주문 기준 2주일~당일 기간으로 매칭 (택배 소요 시간 고려) |
|
3
|
가공된 엑셀 데이터 기준으로 RPA 실행 |
|
✓
|
아무 일 없이 마무리. |
"우리 주문이 기준이다"
두 번의 위기를 해결하면서 깨달은 것이 있었습니다. 문제의 원인이 단순한 오류가 아니라, 누구의 데이터를 기준으로 삼느냐에 있었습니다.
|
BEFORE — 택배사 데이터 기준
· 택배사 데이터를 그대로 기준으로 사용 · 우리 정보와 차이가 계속 발생 · 송장으로는 미회수인데 정보에는 안 잡힘 |
AFTER — 우리 주문 기준
· 우리 주문을 먼저 기준으로 정리 · 택배사 데이터를 우리에 맞춰 가공 · 예외 케이스가 명확하게 걸러짐 |
기준을 하나 바꿨을 뿐인데, 그동안 해결되지 않던 문제들이 정리되기 시작했습니다.
파이프라인이 완성됐습니다
반복적으로 검증하며 수정하는 과정에서 확인이 필요한 영역 자체가 줄어들었습니다. 그리고 마침내 파이프라인이 완성됐습니다.
① | TOTAL RPA 실행 — 전체 주문을 한 번에 처리 |
② | 결과 파일 출력 |
③ | 사람이 확인 필요 건만 1열로 정리 ← 유일한 인간 개입 구간 |
④ | 심플 RPA 실행 |
✓ | 완료. 주문이 깨끗해집니다. |
운영하면서 1주일이라는 기준이 생겼습니다
파이프라인이 완성된 후에도 매일 RPA를 돌리며 관찰했습니다. 그러다 설계 단계에서는 보이지 않던 패턴 하나를 발견했습니다.
운영해봐야만 보이는 패턴입니다. 이를 바탕으로 적용 타임을 조정하며 1주일이라는 기준이 도출됐습니다. 그리고 오늘, 직접 역검증해봤습니다.
| 조건 | 결과 |
|---|---|
| 6일로 줄였을 때 | ❌ 배송 중인 건들이 미회수로 잡힘 |
| 5일로 줄였을 때 | ❌ 배송 중인 건들이 미회수로 잡힘 |
| 1주일 유지 | ✅ 정확하게 미회수 건만 처리됨 |
이론으로 정한 숫자가 아닙니다. 운영하고, 관찰하고, 줄여보고, 틀렸다는 것을 확인한 뒤 확정한 기준입니다.
CJ(예약현황·기업고객_상품명상세·기업고객_반품_상세)와 한진(세부내역), 총 4개 파일을 다운로드한 후 엑셀 매크로 1클릭으로 등록파일이 자동 완성됩니다. 관리자는 검수와 등록만 하면 됩니다.
현장이 또 가르치는 중입니다.
| # | 방법론 | 이 프로젝트에서 한 일 |
|---|---|---|
| #1 | Problem Definition First | 운송지연이 무엇인지 정의부터 세움 |
| #2 | 모집단 기반 사고 | 전체 주문에서 시작해 범위를 좁힘 |
| #3 | Task Decomposition | 핵심 액션을 찾고 → 검색 → 연락/변경으로 분해 |
| #4 | 5Why 근본원인 탐색 | "어떤 주문?" 질문을 반복해 시작점 확정 |
| #5 | 탐색적 데이터 분석 | 900건 직접 정리 → 3가지 패턴 발견 |
| #6 | Analogical Transfer | 송장교체 RPA의 본질을 위기 상황에 전용 |
| #7 | Anchor Point 전환 | 택배사 데이터 기준 → 우리 주문 기준으로 전환 |
| #8 | Iterative Validation | 반복 수정하며 확인 영역을 줄여나감 |
| #9 | Pipeline Architecture | TOTAL RPA → 1열 정리 → 심플 RPA로 표준화 |
| #10 | Temporal Pattern Discovery | 매일 운영하다 시간 패턴 발견 → 기준값 도출 |
| #11 | Empirical Standard Setting | 6일·5일 역검증 후 1주일로 과학적 확정 |
방법론을 공부해서 적용한 게 아닙니다. 문제를 풀다 보니 방법론이 되어 있었습니다.
교과서에서 배운 사람은 비슷한 상황에서 써먹을 수 있습니다. 그러나 현장에서 스스로 같은 결론에 도달한 사람은, 전혀 다른 문제에서도 꺼낼 수 있습니다.
방법론이라는 것은 누군가 이름을 붙이기 전에, 문제를 잘 푸는 사람들이 자연스럽게 하던 것을 정리한 것입니다. 저는 그것을 현장에서 배웠습니다.
댓글이 닫혔습니다.