엑셀 + 부분 ERP로 흩어져 있던 화물 운영을 풀스택 TMS 한 곳에 모았습니다. 화물접수 · 디스패치 · 실시간 추적 · POD · 청구까지 — 10개월간 설계·구현·운영을 모두 리드했습니다.
엑셀 + 부분 ERP 병행 운영으로 화물 추적 누락이 빈번했고, 운행기사 배정 비효율로 디스패치 자동화율 0%, 청구서 발급은 평균 9일이 걸려 현금 흐름에 부담이 컸습니다.
기술 트렌드가 아닌, 문제와 운영 조건에서 출발한 의사결정입니다.
복잡한 화물 상태머신(11단계 전이)을 명확히 표현하기 위함. Pinia 스토어로 도메인별 분리해 유지보수성 확보.
기존 사내 ERP가 MS-SQL 기반이라 데이터 마이그레이션 비용을 0에 가깝게 유지. Node.js는 비동기 IO 빈도가 높은 추적 API에 적합.
전국 동시 롤아웃 대신 거점 한 곳에서 10주간 안정화. 운영 데이터를 모은 후 타 허브 확장 시 위험을 최소화.
드라이버는 사무실 PC가 없습니다. 반응형 웹앱(PWA) + 카메라 API로 POD 사진 캡처 → 즉시 청구 트리거.
Vue 3 + TS, 7개 도메인 모듈, Pinia 스토어 + Vite 빌드. 화물 상태 11단계를 상태머신 패턴으로 명시.
Express 기반 REST API + JWT 인증 + Redis로 추적 조회 캐싱. ELD/HOS 규정 검증 미들웨어 내장.
AWS RDS MS-SQL. 화물 라이프사이클 14테이블 + 청구·정산 7테이블. 트랜잭션 격리수준 READ COMMITTED.
선사·운송사 API 11종 연동 + ELD(전자운행기록) 데이터 인입. 사내 ERP는 야간 배치로 동기화.
롤아웃 이후 12개월 평균치 vs 직전 12개월 비교. 모든 수치는 고객사 NDA 동의 범위 내에서 비율·범주값으로만 공개합니다.
잘된 점만 적으면 이력서. 어려웠던 점과 재시도 시 변경할 점까지 함께 기록합니다.
Vue 3 Composition API + Pinia 조합이 11단계 화물 상태머신을 명확하게 표현했습니다. 상태 전이 규칙을 별도 모듈로 추출해 비즈니스 룰 변경이 잦은 환경에서도 사이드이펙트가 거의 없었고, 신규 디스패처 교육 시간도 평균 3일 → 6시간으로 줄었습니다.
미국 ELD/HOS 운행시간 규정과 한국 운영팀 시간대 데이터의 더블 타임존 처리. UTC 저장을 원칙으로 하되 표시·정렬·검증 시점마다 변환이 필요했고, 초기에는 DST(서머타임) 전환 주간에 운행시간 계산 오차가 발생했습니다. 전용 TimezoneService 도입 후 안정화에 6주가 추가로 소요되었습니다.
초반부터 React Native 모바일 앱을 PWA와 병행 설계했을 것입니다. 드라이버는 결국 네이티브 앱을 선호했고, POD 적용률 96%에 도달하기까지 4개월이 걸렸습니다. 푸시 알림과 백그라운드 위치추적이 필요하다는 신호는 초반 인터뷰에서 이미 나왔는데 기술 선택을 보수적으로 한 것이 아쉬움으로 남습니다.