올리브영에서 SCM 도메인 QA 엔지니어 겸민입니다. 이 글은 올리브영의 글로벌 WMS 시스템인 GMS(Global Warehouse Management System)의 구축부터 서비스 안정화에 이르기까지의 검증 여정을 담았습니다. 특히, 테스트 전략 수립, 시나리오 기반 통합 테스트 및 운영 환경 검증 등 실제 프로젝트 현장에서의 구체적인 경험과 노하우를 소개 드립니다.
왜 GMS 프로젝트 테스트는 특별해야 했을까?
물류 시스템을 새로 구축하는 프로젝트는 늘 복잡하지만, GMS 프로젝트는 특히 어려운 도전이었습니다. 기존 시스템을 단계적으로 전환하는 대신, ‘빅뱅 배포(Big Bang Deployment)’, 즉 모든 시스템을 한 번에 전환하는 방식을 선택했기 때문입니다. 이는 마치 기존 도로를 완전히 폐쇄하고 새로운 고속도로를 단숨에 개통하는 것과 같은 일이었습니다.
특히 백오피스, CBT(Cross-Border Trade), WCS(Warehouse Control System) 등 수많은 연계 시스템이 복잡하게 얽힌 환경에서는 단 하나의 오류라도 발생하면 시스템 전체가 마비되는 치명적인 리스크를 안고 있었습니다. 따라서 우리의 테스트 전략은 단순히 기능 검증을 넘어, 전환 직후의 안정성과 데이터 정합성까지 전방위적으로 점검해야 했습니다.
문제 해결의 시작: 리스크 식별과 전략 수립
처음 GMS 프로젝트 합류했을 당시, GMS 프로젝트는 전체 개발 진척도가 40% 정도 수준이었고, 2주간의 짧은 분석·설계 기간 후 곧바로 기능 단위 테스트(Feature Test)를 시작해야 했습니다. 다행히 PO와 개발자분들의 세심한 지원 덕분에 바쁜 일정 속에도 GMS의 핵심 구조와 흐름을 빠르게 파악할 수 있었고, 이 자리를 빌려 감사의 말씀을 전합니다.
도메인 구조를 파악한 후, QA 관점에서 시스템 안정성에 영향을 줄 수 있는 다양한 리스크를 선제적으로 식별했습니다. 이 리스크들을 "Risk Factor"로 정리해 테스트 전략 수립의 기초 자료로 활용하였습니다. Risk Factor를 도출하는 과정에서는 GMS와 연계된 시스템의 구조와 물류 데이터 흐름을 면밀히 분석하고 명확하게 정리하는 작업도 병행했습니다.
✅ Risk Factor란?
QA 입장에서 말하는 Risk Factor는 단순한 '버그 가능성'을 넘어서, 시스템 안정성에 영향을 줄 수 있는 모든 잠재 리스크를 의미합니다.GMS와 같이 여러 서비스가 유기적으로 연동되는 시스템의 경우 인터페이스 규격 불일치, 메시지 큐(이벤트) 지연·중복 등으로 발생하는 데이터 정합성 훼손 등은
모두 테스트 설계 초기부터 고려해야 할 주요 Risk Factor였습니다.
이를 토대로 상품 → 입고 → 출고 → 배송이라는 주요 카테고리를 기준으로 전체 워크플로우를 설계했습니다. 그 과정에서 개발 단계에서도 E2E(End-to-End) 통합 테스트가 반드시 필요하다는 점을 확인할 수 있었습니다.
그러나 현실적인 제약도 존재했습니다. 각 연계 시스템의 개발 환경 지원 수준이 달랐기 때문에, 먼저 E2E 테스트 가능 범위를 확인해야 했습니다. 예를 들어, 특송사 샌드박스는 응답이 불안정해 운송장 생성 단계에서 테스트가 제한되었고, WCS는 아예 개발 환경이 없어 출고 관련 E2E 테스트 자체가 불가능했습니다. 이러한 제약 속에서 저희는 협력 부서와 여러 차례 논의를 거듭하며 "개발 단계에서 검증 가능한 영역 vs. 불가능한 영역"을 명확히 구분했습니다. 이후 각 구간별로 테스트 전략을 분리·수립함으로써 한정된 환경에서도 유연하고 실효성 있는 테스트를 이어갈 수 있었습니다.
단계별 전략적 테스트: 견고한 시스템을 만드는 과정
GMS는 앞서 언급한 것처럼 백오피스, 글로벌몰, CBT, WCS 등의 다양한 외부 시스템과 연계되는 구조로 설계되어 있으며 데이터 Interface 방식 또한 API, MQ(MSK), BATCH 등 여러 방식을 활용하도록 구성되었습니다.
상품·입고·출고·배송이라는 4대 주요 카테고리를 중심으로 구성한 워크플로우를 시스템 관점에서 실제 연동 방식과 데이터 흐름 기준으로 재정의했습니다. 이 워크플로우를 시스템 연동 방식과 데이터 흐름에 따라 Interface Spec(인터페이스 명세)으로 세분화하였습니다. 정리된 11개의 Interface Spec은 시스템 간 인터페이스 검증 기준이자 E2E 테스트용 Test Suite의 기반이 되었습니다.
동시에 GMS의 기능 단위를 Feature 단위로 나누어 Feature List를 작성하여 이는 기능별 단위 테스트의 검증 기준으로 삼았습니다. 이처럼 정리된 Interface Spec과 Feature List를 기반으로 Test Case를 체계적으로 설계한 뒤, 기능별·단계별 테스트 일정을 마일스톤 기반으로 스케줄링하여 전체 테스트 플랜을 수립했습니다.
설계된 테스트 플랜을 바탕으로 테스트는 단계별로 세분화하여 진행하였으며, 각 단계에서는 단순 통과율보다는 '무엇을 검증해야 하는가'에 초점을 맞춘 전략적 접근을 적용했습니다.
✅ 기능 단위 테스트 (Feature Test): 결함 발견율에 집중하다
기능 단위 테스트는 개발 완료된 기능 모듈별로 진행했습니다. 이 단계에서는 테스트 종료 기준(Exit Criteria)을 단순한 결함 수정률이 아닌, 결함 발견율 자체에 두고 운영하였습니다. 테스트 목적은 ‘완성된 기능을 빠르게 통과시키는 것’이 아니라, 가능한 많은 취약 지점을 사전에 식별하는 것이었기 때문입니다.
이를 위해 기능 단위에서의 오류 처리와 필수 파라미터 누락, 예외 케이스 등을 고려한 Negative Test를 설계했습니다. 그 결과, 로직의 견고함과 에러 핸들링의 완성도를 높일 수 있었습니다.
특히 입고/출고와 같은 재고 처리 로직은 기능 단위 테스트에서 정상 동작이 확인되더라도, 실제 운영 환경에서는 여러 사용자가 동시에 요청을 보낼 수 있는 상황이 빈번하게 발생합니다. 따라서 정상 기능 검증과 별개로 동시성에 대한 안정성 검증이 반드시 병행될 필요가 있었습니다.
✅ 동시성 테스트 (Concurrency Test): 보이지 않는 충돌을 막아라
기능 단위 테스트가 기능 자체의 견고함을 검증하는 단계였다면, 동시성 테스트는 복잡한 운영 환경에서 발생할 수있는 충돌 가능성을 선제적으로 제거하기 위한 보완적 검증 단계였습니다. 특히 입고·출고와 같이 재고 수량을 처리하는 로직에서는 동일 데이터를 여러 요청이 동시에 접근·변경하는 상황이 자주 발생합니다. 이 경우 예기치 못한 Race Condition이나 데이터 충돌이 발생할 가능성이 높기 때문에, 기능 단위 테스트만으로는 안정성을 보장하기 어렵습니다.
이에 따라 저희는 동일 상품에 대해 복수의 입고 요청이 동시에 발생하는 시나리오를 구성했습니다. 그리고 GMS가 내부적으로 요청을 어떻게 직렬화하고 충돌 없이 처리하는지, 또 Lock 처리 메커니즘이 정상적으로 작동하는지를 집중적으로 검증했습니다.
동시성 테스트를 통해 다음과 같은 주요 리스크를 사전에 확인할 수 있었습니다.
-
동일 요청이 거의 동시에 발생했을 때 재고 데이터가 중복 처리되는 현상
-
Lock 처리 로직이 제대로 동작하지 않아 발생하는 Race Condition
-
비정상 상태에서의 Deadlock 또는 데이터 정합성 오염
이러한 리스크를 사전에 식별하고 검증함으로써 운영 단계에서 발생할 수 있는 데이터 충돌 이슈를 효과적으로 차단할 수 있었습니다. 또한 API 로직이 동시 요청 환경에서도 안정적으로 동작한다는 신뢰를 확보하여, QA 관점에서 시스템 안정성 보장의 핵심적인 검증 과정이 되었습니다.
✅ 통합 테스트 & E2E 시나리오 검증: 데이터 정합성까지 놓치지 않는 심화 검증
통합 테스트 단계에서는 기능 단위 테스트를 통해 검증된 기능들을 실제 운영 흐름과 동일한 방식으로 연결하여 E2E 시나리오 기반 테스트를 중점적으로 수행했습니다. 특히 GMS는 백오피스, 글로벌몰, CBT, WCS 등 다양한 외부 시스템과 연동되어 있었고, 이들 시스템 간 인터페이스는 대부분 Kafka 기반 MQ(MSK)로 이루어져 있었습니다. 따라서 메시지 기반 비동기 통신의 신뢰성과 데이터 정합성 검증이 핵심 테스트 포인트가 되었습니다. 이번 통합 테스트에서 가장 중점적으로 둔 전략적 포인트는 두 가지입니다.
🔹 1. Interface Spec 기반 E2E Test Suite 구성
초기에 정의한 총 11개의 Interface Spec을 기준으로, 실제 사용자 행위를 반영한 업무 중심의 시나리오(E2E Test Suite)를 설계했습니다. 각 테스트 케이스는 단순 기능 검증에 머물지 않고, 업무 단위(예: 출고 지시 → 재고 할당 → 출고 확정)의 연계를 검증하는 방향으로 구성했습니다. 이를 통해 시스템 간 메시지 흐름이 정상적으로 연계되는지, 전체 프로세스가 의도한 대로 작동하는지를 종합적으로 검증할 수 있었습니다.
🔹 2. Interface Contract Test – 데이터 정합성 및 스키마 호환성 검증
MQ 기반 인터페이스의 특성상, 메시지가 성공적으로 전송되었다고 해서 실제 데이터가 문제없이 반영된다고 보장할 수는 없습니다. 수신 시스템의 DB 스키마와 메시지 필드 간에 다음과 같은 사양 차이가 존재할 수 있기 때문입니다.
- 데이터 타입(Type)
- 컬럼 크기(Size)
- NULL 허용 여부
- ENUM/코드값 정의 여부
이 경우 데이터 유실, 오류, 또는 Silent Failure가 발생할 수 있습니다. 이를 방지하기 위해 시나리오 테스트와 함께 Interface Contract Test를 함께 수행했고, 주요 검증 항목은 다음과 같습니다.
- 메시지 필드 ↔ DB 컬럼 간 데이터 타입 불일치 여부
- VARCHAR 컬럼 크기 초과로 인한 값 절단 또는 예외 발생 여부
- NULL 제약 조건 위반 상황의 처리 여부
- ENUM/코드값 등의 미정의 값 처리 상태
예를 들어, 고객 이름(user_name)과 주소(address) 필드가 서비스간 전송될 때 암호화/복호화 과정을 거쳐 전달되는 시나리오를 가정해 보겠습니다.
- 글로벌몰 → GMS: user_name은 VARCHAR(20), address는 VARCHAR(100) 으로 정의
- GMS → 특송사: 복호화 후 전달되지만, 특송사 스키마에서는 user_name이 VARCHAR(10) 으로 설정
이처럼 글로벌몰에서 전달된 20자 이상의 이름 정보는 특송사에 저장되는 과정에서 Schema Mismatch가 발생해 데이터 저장 오류가 나거나, 오류 메시지 없이 값이 잘리는 Silent Failure이 발생할 수 있습니다. 이러한 Interface Contract Test는 서비스 간 사소한 스키마 불일치가 운영 환경에서 예기치 않은 데이터 정합성 문제로 이어지지 않도록 사전에 차단하는 핵심 검증 과정이 되었습니다.
운영 환경 최종 검증 : UAT의 진정한 의미
개발 환경에서의 기능 단위 테스트와 통합 테스트를 통해 GMS의 주요 기능 안정성은 충분히 검증되었습니다. 하지만 WCS(Warehouse Control System)와 실제 물류센터 운영 환경은 개발 환경에서 충분히 테스트가 불가능한 ‘그레이존’으로 남아 있었습니다. 특히 검수 확정 이후 출고 처리까지 이어지는 물류센터 내 프로세스와 시스템 간 연동은, 실제 운영 환경 검증 없이는 사전 리스크 파악이 어려운 영역이었습니다.
이러한 배경 속에서 우리는 실제 센터 환경에서 진행하는 UAT(User Acceptance Test)를 설계하게 되었습니다. 다만 UAT를 수행하는 동안 물류센터 작업이 일시중단되어야 했기 때문에, 단순 시나리오 테스트가 아닌 "반드시 검증해야 할 항목"만 담은 정제된 테스트 시나리오가 필요했습니다.
저희가 설계한 UAT 시나리오와 체크리스트는 다음 기준을 따랐습니다.
- 글로벌 매출 기준으로 상위 국가와 주요 특송사 조합을 선정
- 실제 센터 운영에서 발생 가능한 대표 케이스를 중심으로 구성
- 각 케이스를 E2E 통합 시나리오 흐름에 맞춰 체계화
- 단순 성공 여부가 아니라, WCS 동작 상태와 데이터 정합성까지 포함한 체크리스트 작성
UAT 제안 초기에는 센터 운영 중단에 대한 부담과 우려가 컸습니다. 그러나 GMS는 기존 시스템과 병행 운영이 불가능한 ‘빅뱅 배포(Big Bang Deployment)’ 방식이었고, 사전 검증 없이 오픈하는 것은 곧 운영 리스크로 직결된다는 의미였죠. QA는 이 부분을 꾸준히 설득했고, 결국 논의를 거쳐 2차에 걸친 UAT를 정식으로 진행하기로 결정했습니다.
그 결과, 실제 테스트 과정에서 예상치 못했던 여러 이슈들을 사전 탐지할 수 있었습니다.
- WCS 장비 환경 전환 시 발생하는 네트워크 오류
- 간헐적인 출고 검수 확정 실패
- 재고이동/재고보충 기능이 실제 운영 환경과 달랐던 부분 등
이러한 경험은 실제 운영 환경 기반 QA의 필요성을 명확히 보여주는 사례였고, 안정적인 GMS 오픈을 위한 핵심 기반이 되었습니다. 이처럼 UAT는 단순한 운영자 확인 절차를 넘어, 운영 중단이라는 리스크를 감수하고서라도 반드시 수행해야 하는 ‘운영 환경 최종 검증 단계’였고 그 중심에는 QA가 있었습니다.
오픈 이후의 QA: 조용한 실패까지 잡아내는 모니터링
UAT를 통해 실제 운영 환경에서의 기능 안정성은 검증했습니다. 하지만 오픈 이후에도 품질 확보는 멈추지 않습니다. 이 시점에서 QA 역할은 단순히 운영 중 발생한 이슈를 수정하는 것에 머무르지 않고, 대신 결함을 조기에 감지하고, 인시던트로 확대되기 전에 선제적으로 대응하는 체계를 만드는 데 있습니다. GMS는 여러 외부 시스템과 MQ 기반 인터페이스(Kafka/MSK)로 연동되므로, 서버 상태 모니터링만으로는 품질 리스크를 찾기 어렵습니다. 예를 들어 서버 Health Check API가 정상(200 OK) 반환해도, Kafka 프로듀서가 메시지를 발행하지 않는 경우(커넥션 단절, 전송 오류 등)도 발생합니다. 이러한 상황을 탐지하기 위해 저희는 Datadog 기반의 커스텀 모니터링 룰을 구축했습니다.
📌 실제 모니터링 적용 예시
출하 지시(Shipment Order)는 일정 주기마다 자동 배치로 내려가야 하는 구조였는데, 만약 Kafka 프로듀서가 침묵한 채 메시지를 전송하지 않는다면 센터의 작업 지시가 멈춰 물류가 중단되는 리스크가 발생합니다. 이를 방지하기 위해 Datadog에서 ‘배치 주기 내 출하지시 메시지 수가 0건일 경우 알림’이 발생하도록 설정했습니다. 덕분에 실제로 운영에서도 센터 작업이 완전히 멈추기 전에 사전 조치를 취할 수 있었습니다.
- 건수 기반 임계치 알림
- 메시지 지연 감지
이 외에도 입고 확정, 재고 동기화 등 주요 메시지 플로우에 대해 추가 모니터링하여, 기능 오류가 아닌 ‘조용한 실패(Silent Failure)’도 실시간으로 탐지할 수 있도록 구성했습니다.
Datadog 기반의 실시간 모니터링은 단순 대응을 넘어, ‘관측 가능한 QA’로의 전환을 이끈 핵심 전략이었습니다.
마치며: QA, 정답은 없지만 방향은 있다
이번 GMS 프로젝트는 저에게 WMS 시스템을 분석하고 설계부터 런칭까지 직접 경험한 두 번째 사례였지만, 같은 도메인이라고 해서 같은 방식으로 접근할 수는 없었습니다. 시스템 구조는 유사할 수 있어도, QA의 접근 방식은 매번 새로운 고민과 선택의 연속이었습니다. 프로젝트를 진행하며 다시 한 번 깨달은 것은, “이 시스템은 이렇게 검증하면 된다”는 절대적인 정답은 없다는 점입니다. 각 프로젝트는 도입 기술, 연동 환경, 조직의 역량, 팀의 속도 등 수많은 변수를 기반으로 움직이므로, QA는 이러한 요소를 고려해 최적의 테스트 전략을 매번 설계해야 합니다. 무엇이 효과적인 접근법인지 끊임없이 고민하고 방향을 조정하는 과정 자체가 QA가 지녀야 할 가장 본질적인 자세라는 것을 이번 경험을 통해 배웠습니다. 이 글이 새로운 시스템을 처음 검증해야 하는 QA 엔지니어분들께 실질적인 인사이트와 용기를 전하길 바랍니다.
읽어주셔서 감사합니다.
혹시 이 글을 읽고 올리브영 QA팀의 일이 흥미롭게 느껴지셨나요? 저희와 함께 새로운 품질 경험을 만들어 갈 분들을 기다리고 있습니다.
👉 QA Engineer (Back Office) 지원하러 가기
또한, 아래 글들도 함께 읽어보시면 GMS 프로젝트와 QA 업무 전반에 대해 더 깊이 이해하실 수 있습니다.
👉 제로베이스 WMS 구축기: Kafka 기반 분산 물류 시스템 설계와 Out-of-Order Events 해결
