안녕하세요. 풀필먼트 백엔드 개발을 담당하고 있는 시나브로우입니다.

이번 글에서는 올리브영만의 최초 물류 시스템, GMS(Global Warehouse Management System)를 소개드리고자 합니다.

GMS, 최초의 서막

2024년 10월, 올리브영은 글로벌 사업 확장과 자체 물류 인프라 강화를 목표로 GMS(Global Warehouse Management System) 구축 프로젝트를 본격적으로 시작했습니다. 기존의 외부 WMS(Warehouse Management System) 솔루션에 의존하던 방식에서 벗어나, 올리브영만의 독자적인 물류 시스템을 새롭게 설계하고 개발하는 첫 시도인데요.

안성 물류센터는 사업별 특성에 맞춰 글로벌몰 센터와 자체 브랜드 센터로 이원화하여 운영 중입니다. GMS가 도입된 글로벌몰 전용 센터는 해외 배송에 특화된 시스템으로 설계되었습니다. 국가별로 DHL, LX Pantos, FDX 등의 특송사를 통해서 해외 배송 서비스를 제공하고 있죠. 프로젝트 초기에는 프론트엔드 개발자 1명, 백엔드 개발자 1명, PO 3명, UX/UI 디자이너 1명으로 구성된 소규모 스쿼드로 시작했습니다.

첫 플래닝부터 정신없는 일정이 이어졌고 혼란스럽게 시작했지만 모두가 힘을 합쳐 최고의 물류 시스템을 만들겠다는 공동의 목표를 달성하기 위해 열심히 달리기 시작했습니다.

저희 풀필먼트 스쿼드는 글로벌 사업의 성장에 발맞춰 사용자 니즈를 반영하고, 신규 프로세스를 수용할 수 있는 유연함, 그리고 고가용성과 안정성을 갖춘 물류 시스템 구축을 목표로 삼았습니다.

WMS 내재화를 위한 여정은 말 그대로 제로베이스에서 출발했습니다.

WMS에 대한 배경 지식이나 경험이 전무한 상태였기에, 실무 개발과 함께 WMS 도메인 학습을 병행해야 했습니다.

‘입고’, ‘적치’, ‘할당’, ‘피킹’, ‘검수’, ‘출고’, ‘재고보충’, ‘기준정보’ 등 전반적인 WMS 비즈니스 로직을 빠르게 이해하고 직접 설계/구현하며,

DB 설계부터 서버 인프라 구축까지 모든 과정을 종횡무진으로 수행해 나갔습니다.

그 결과, 2025년 2월 중순부터 본격적인 QA를 시작할 수 있었고,

개발과 테스트, 버그 수정이 동시에 돌아가는 ‘전쟁 같은’ 일정을 보내며 시스템의 완성도를 높여갔습니다.

2~4월 동안 진행된 체계적이고 전문적인 QA 과정을 통해,

GMS는 단순한 WMS를 넘어 올리브영 물류의 중심축이 될 준비를 마칠 수 있었습니다.

QA total 이슈가 409건이 있었지만, 저희 WMS 전문 시니어 QA 님이 이 정도는 적은 편이라고 하셨습니다. 👍

GMS 오픈을 앞두고, 안성 물류센터에 War Room을 구축하고 밤낮없이 오픈 준비에 매진했습니다.

수많은 시련과 인내의 시간을 거쳐 마침내, 2025년 5월 8일, GMS를 Grand Open 할 수 있었습니다.

떨리는 그 순간, 올리브영은 사상 처음으로 자사 개발 WMS 시스템을 성공적으로 런칭하게 되었습니다.

---

GMS Architecture

GMS 시스템은 WMS 핵심 비즈니스 기능을 유연하고 효율적으로 처리할 수 있도록 최적화되어 있으며,

외부 시스템과의 안정적인 연동 구조와 실시간 대량 데이터를 처리할 수 있는 분산 처리 아키텍처를 갖추고 있는 것이 특징입니다.

유기적 시스템 통합을 위한 API & Kafka Message Event 중심 설계

GMS 는 오프라인 코어 백오피스 시스템, 글로벌몰 시스템, CBT(Cross Border Trade) 시스템, WCS(Warehouse Control System) 등 다양한 외부 시스템과의 상호 운용성을 확보하고, 실시간 데이터 연계에 최적화된 통합 아키텍처를 기반으로 설계되었습니다.

외부 시스템과의 연동 방식은 사용 목적에 따라 구분하였습니다.

응답(Response)이 필요한 API 기반 연동이나 레거시 시스템과의 통합은 REST API 중심으로 구축했으며,

그 외 대부분의 시스템 간 데이터 흐름은 Kafka(MSK) 를 활용한 비동기 Pub/Sub 메시징 방식으로 설계하여 확장성과 실시간성을 모두 확보했습니다.

Kafka 메시지 중복 및 유실 방지 설정을 적용하여 물류 데이터의 신뢰성을 확보했습니다.

자세한 설정 방법은 이전 블로그 글에서도 다뤘으니 참고하시면 도움이 될 것입니다.

👉 Kafka 메시지 중복 및 유실 케이스별 해결 방법

---

Out-of-Order Events Trouble Shooting

Kafka(MSK)를 기반으로 한 비동기 Pub/Sub 메시징 구조를 통해 여러 시스템 간 유기적인 데이터 연계가 가능해졌으며,

대량의 데이터를 효과적으로 처리하고 분산 처리 체계를 구현했지만,

이러한 비동기 메시징 구조가 순기능한 것은 아니었습니다.

Message Queue 방식의 고질적인 문제인 이벤트 순서를 보장하지 못하는 이슈가 있습니다.

Queue 의 순서를 엄격하게 지정하더라도 이벤트를 생성하는 서비스 처리 과정에서 지연이 발생하는 경우 'Out-of-Order Events' 가 발생하게 됩니다.

GMS 시스템에서도 처리 지연과 네트워크 지연으로 인해 메시지 순서가 뒤바뀌는 문제가 발생했으며, 이에 대한 해결 과정을 소개드리겠습니다.

출고 프로세스는 GMS, WCS, Global Mall System, CBT(Cross Border Trade) System, 특송사 시스템 등 여러 시스템이 연계된 구조로, 네트워크 경로가 복잡하게 구성되어 있습니다.

시스템마다 AWS 계정이 서로 다르고, 각각의 MSK도 독립적으로 운영되고 있습니다. 특히, Global 시스템은 AWS Virginia 리전(us-east-1) 에 위치하고, GMS는 Seoul 리전(ap-northeast-2) 에 위치해 있어 리전 간 네트워크 지연 또한 발생할 수 있습니다.

이처럼 복잡한 네트워크 구간과 시스템 간 통신의 비동기성으로 인해, 각 구간에서 메시지 순서가 어긋날 가능성이 존재했습니다.

아래는 GMS 출고 프로세스의 구조를 도식화 한 것입니다.

검수와 패킹이 완료된 후, 운송장 채번 요청이 이루어지면 실물이 물류 설비를 통해 이동하게 됩니다.

이후 과정부터는 외부 시스템과의 연동이 서로 독립적으로 진행됩니다.

CBT(Cross Border Trade) 시스템은 특송사를 통해 운송장을 채번한 뒤, Virginia 리전에 위치한 OYG MSK 로 운송장 정보를 발행(Produce) 합니다.

이후 GMS External Consumer가 해당 데이터를 수신하여, 타 리전의 운송장을 Seoul 리전의 GMS MSK로 전달(Forwarding) 합니다.

WCS(Warehouse Control System) 는 출고 요청 데이터를 수신한 후, 물류 설비를 통해 특송사별 출고 라인으로 소팅하고, 배송 상자에 운송장 라벨링 작업을 수행합니다.

이후 WCS 출고 확정 정보를 API를 통해 GMS External API로 전송합니다.

최종 단계에서는 GMS External API가 주문 상태를 변경하고, 출고 확정 정보를 GMS MSK의 stockout-internal(가칭) 토픽으로 다시 발행(Produce)합니다.

GMS Internal Consumer 는 GMS MSK의 stockout-complete 토픽을 소비(Consume) 하여 출고 수량을 확정하고 재고 이력을 기록함으로써, GMS 출고 프로세스를 마무리합니다.

출고 완료 결과는 다시 stockout-complete(가칭) 토픽으로 발행되며, Global Mall 시스템이 해당 데이터를 수신하여 주문 상태를 '배송 중'으로 변경하고, 정산 용 데이터로 활용하게 됩니다.

서술한 순서대로 진행되면 문제 없이 출고 완료 데이터를 Global Mall 에 전송할 수 있겠지만,

한 구간이라도 지연되면, 'Out-of-Order Events' 가 발생하여, 운송장 번호가 누락된 상태로 출고확정 정보가 Global Mall 에 전송되는 문제가 발생합니다.

이러한 지연이 주로 발생하는 구간을 설명하기 위해, 위 그림에 번호를 부여해 대표적인 지연 구간들을 정리하면 다음과 같습니다.

결국, 각 서비스가 독립된 환경에서 상호배타적으로 비동기 처리되기 때문에, 다양한 원인으로 인해 운송장 번호가 수신 순서가 가장 마지막이 되는 경우가 발생하게 되는 것입니다.

https://medium.com/@prabhu.seshadri/handling-out-of-order-events-in-a-event-driven-systems-93349bd20c26

물론 네트워크 구간을 줄이고, 복잡한 메시징 구조를 피하는 것이 가장 좋은 방법입니다만,

저희 GMS 시스템은 여러 외부 시스템과 연동되어 있고, 서버 자원을 각자 관리하고, 각 시스템이 서버 자원을 독립적으로 운영하기 때문에 'Out-of-Order Events' 를 방지할 수 없는 구조입니다.

이를 해결하기 위해 메시지의 순서 및 정합성을 보장하기 위해 'Delayed Queue' 패턴을 적용하여, 지연 메시징과 지연 재처리 아키텍처를 구축하게 되었습니다.

지연 메시징과 지연 재처리 아키텍처는 Kafka Streams 를 활용해서 구축하였습니다.

지연 재처리 위한 Streams Topology 구성하기 위해,

기존의 운송장 수신 토픽 (tracking-number-internal topic) 외에도

유효하지 않은 출고를 저장할 토픽 (stockout-invalidated topic) 과 출고 재처리를 위한 토픽 (stockout-retry topic) 을 추가 생성하였습니다.

운송장 수신 토픽 (tracking-number-internal topic) 수신이 지연된 경우에는,

출고 확정 토픽(stockout-complete) 으로 발행(Produce) 을 막고,

대신 유효하지 않은 출고 토픽 (stockout-invalidated topic) 으로 메시지를 발행(Produce) 하여 Kafka Streams 을 처리할 수 있게 합니다.

이후 지연된 운송장을 운송장 수신 토픽 (tracking-number-internal topic) 을 통해 수신되면,

Kafka Streams 는 이를 감지하고 출고 재처리를 위한 토픽 (stockout-retry topic) 으로 메시지를 생성하여,

출고 확정 정보를 자동으로 재연동합니다.

지연 재처리 아키텍처를 통해서 재처리된 출고 데이터 프로세스 정보는 Slack 으로 단계별로 전송됩니다.

자동으로 재처리 된 출고 데이터를 Slack 을 통해 실시간으로 간편하게 확인할 수 있어서, 개발자의 수동 확인 및 재처리 작업을 크게 줄일 수 있었습니다.

참고로, 주문 단위로 메시지를 단건 전송하는 방식이 아니라, 'Batching' 방식으로 일정 시간 동안 메시지를 모은 뒤 Slack에 묶어서 전송되도록 구현되어 있습니다. 이는 Slack 알림의 과도한 빈도로 인한 피로도를 줄이고, 동일한 이슈에 대한 메시지를 한눈에 파악할 수 있도록 하기 위한 목적입니다.

---

GMS 핵심 업무와 기술 기반 개선 사례

OliveYoung GMS (Global WMS) 시스템의 입고는 양지센터에서 출고되는 상품을 매입 처리하는 방식으로 진행됩니다.

입고 경로는 양지센터 외에도 다양하지만, 전체 입고 물량의 약 85%가 양지센터로부터 공급되고 있습니다.

양지에서 출고된 데이터는 본사 DB에 저장된 후, GMS DB로 연동되며,

GMS 에서 입고 확정 처리가 완료되면, 해당 데이터를 기반으로 매입 확정 정보를 실시간 반영하는 것이 핵심 업무입니다.

매입 정보를 실시간으로 반영해야 했지만, 본사 코어 백오피스 시스템과의 MSK 기반 통신이 불가능한 상황이었습니다. 이에 따라 차선책으로 본사 DB와 GMS DB 간의 연동을 Two-Phase Commit 방식으로 구현해, 매입 정보를 실시간으로 반영할 수 있도록 했습니다.

본사 DB와 GMS DB는 배타적으로 접근이 제어되며, 각 트랜잭션은 서로 분리된 상태로 처리됩니다.

GMS 입고 확정은 PDA 와 PC 를 통해 실시간으로 이루어지며,

이때 Spring의 ApplicationEventPublisher를 활용해 이벤트를 발행하고, TransactionalEventListener 를 통해서 본사 DB 에 입고 확정 정보를 반영합니다.

또한 '적치', '재고 이동', '재고 보충', '할당', '피킹지시' 등 주요 물류 프로세스에서 다수의 PC 와 PDA 작업할 경우 동시성 문제를 효과적으로 해소하기 위해,

Redis 분산 락을 도입해서 다수의 PDA 및 PC 사용자가 동시에 작업을 수행하더라도 재고 데이터의 충돌을 방지하고, 데이터의 일관성과 시스템의 신뢰성을 확보할 수 있도록 설계했습니다.

다음으로 OliveYoung GMS(Global WMS) 시스템의 출고 프로세스를 소개해드리겠습니다.

이 중에서도, WMS 내재화 이후 가장 눈에 띄게 변화한 영역은 바로 ‘할당 및 피킹 지시’ 파트입니다.

출고량을 극대화하기 위해 출고 프로세스를 중점적으로 개선 하였으며,

GMS 오픈 이전까지는 외부 WMS 솔루션을 사용해왔지만,

자체 GMS를 통해 성능을 개선하고, 기존 외부 솔루션 대비 더 높은 출고 효율을 달성하는 것을 목표로 삼았습니다.

할당로직에서 과할당 없이 정확한 재고 할당을 보장하면서 성능까지 개선하는 작업은 결코 쉽지 않았습니다.

우리는 차수 내에서 동일 Transaction 을 유지하여, 중복 할당 없이 'Concurrency-safe' 한 처리를 보장하도록 개선 하였고,

할당 결과는 Bulk Commit 방식으로 처리하여 성능을 최적화하였습니다.

또한, 할당 시 재고가 부족한 경우에는 Kafka 기반의 비동기 분산 처리 구조를 통해,

할당 Transaction 과 분리된 보충 지시 프로세스가 자동으로 실행되도록 구성하였습니다.

피킹 지시 단계에서는 피킹 동선에 따라 그룹을 분리하고, 이를 병렬 비동기(Parallel Async) 방식으로 처리하여 대량의 피킹 지시를 빠르게 수행할 수 있도록 최적화하였습니다.

스쿼드원들의 적극적인 개선 시도 덕분에, 우리는 할당부터 피킹 지시까지의 소요 시간을 기존 대비 81% 단축할 수 있었습니다.

주문 1,000건 기준으로 AS-IS 외부 솔루션과 GMS의 성능을 비교한 결과, 주문 할당은 280초 → 40초, 피킹리스트 생성은 40초 → 12초, 피킹라벨 출력은 40초 → 14초로 전반적인 출고 퍼포먼스가 개선되었습니다.

이러한 성과로 3월 올영세일 대비 6월 올영세일의 출고 처리량(CAPA)을 50% 확대하는 데 기여를 할 수 있었습니다! 👏🏻👏🏻👏🏻

---

GMS 모니터링 소개

GMS(Global WMS) 대시보드는 올리브영 표준 모니터링 도구인 DataDog 기반으로 구축되었습니다.

서버 자원, API, Kafka(MSK) 모니터링뿐만 아니라, WMS 전반에서 발생하는 주요 이벤트들을 가능한 한 시각화하여 반영했습니다.

입고부터 출고까지의 처리량 및 실패 건수 등 주요 지표를 시각화하여, WMS 핵심 업무의 진행 상황을 한눈에 파악할 수 있도록 구성했습니다. GMS 뿐만 아니라 CBT(Cross Border Trade), WCS, Global Mall 등과의 연동 흐름도 함께 시각화하여 통합 대시보드로 제공하고 있습니다. 이처럼 WMS 주요 업무를 직관적이고 실시간으로 모니터링할 수 있도록 구성함으로써, 세일 기간과 같은 트래픽 집중 상황에서도 안정적으로 운영할 수 있었습니다.

대시보드에서 수집한 Custom Metric 지표와 로그는 Slack 알림과 연동하여 자원 상태 및 에러 상황을 빠르게 감지할 수 있습니다. GMS의 안정적 운영에 크게 기여하고 있지요.

---

끝으로

지금까지 올리브영 GMS(Global WMS)의 오픈 과정과 핵심 업무, 기술 개선 사례, 그리고 모니터링 방식에 대해 소개드렸습니다.

이번 글은 올리브영 최초의 WMS 내재화 프로젝트인 GMS를 소개하기 위해 작성되었습니다. GMS 는 올리브영 WMS의 시작점이며, 앞으로도 지속적으로 고도화되어 나갈 예정입니다.

올리브영 WMS와 풀필먼트가 성장할 수 있도록 많은 관심부탁드립니다.

이전 글도 많은 관심부탁드립니다.

👉 Kafka 메시지 중복 및 유실 케이스별 해결 방법

👉 AWS MSK Connect 효과적으로 운영하기

지금까지 올리브영 풀필먼트 스쿼드의 시나브로우였습니다.

감사합니다.