<div id="readability-page-1" class="page"><div><div><a rel="noopener follow" href="/@limsangjin12?source=post_page-----993938419cde--------------------------------"><div aria-hidden="false"><p><img alt="Sangjin Lim" src="https://miro.medium.com/v2/resize:fill:88:88/1*VQ4LM1-63Vllto56ghBdaw.jpeg" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a><a href="https://medium.com/musinsa-tech?source=post_page-----993938419cde--------------------------------" rel="noopener follow"><div aria-hidden="false"><p><img alt="MUSINSA tech" src="https://miro.medium.com/v2/resize:fill:48:48/1*Qs-0adxK8doDYyzZXMXkmg.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></p></div></a></div><h2 id="32bb">들어가며</h2><p id="adfc">안녕하세요, PBO(Platform Business Operation)에서 MUSINA WMS(이하 MWMS)를 개발하고 있는 백엔드 엔지니어 임상진입니다.</p><p id="3a06">무신사는 빠른 배송과 반품, 오프라인과 글로벌 시장 확대를 위해 물류 시스템 개선에 몰두하고 있습니다.<br>과거 2023년까지 총 4개 물류센터에서 2가지의 상이한 외주 솔루션을 사용해 운영되고 있었습니다.</p><figure><figcaption>그림1. 3D 소터(자동 분류 설비)</figcaption></figure><p id="f9e0">물류센터를 운영하기 위해서는 WMS라는 시스템이 필수적인데요. 우리가 사용하던 외주 솔루션은 내재화된 시스템이 아니었기 때문에 시시각각 변경되는 요구사항에 즉각 대응하거나 비즈니스를 확장하기에 매우 불리했습니다. 특히 일부 기능은 MUSINSA OMS(이하 MOMS)에 개발되어야만 했습니다.</p><blockquote><p id="9c40">잠깐, WMS와 OMS가 뭘까요?</p><p id="509d">WMS는 <strong>Warehouse Management System</strong>(창고 관리 시스템)의 약자로, 창고나 물류센터에서 재고 관리, 입출고, 작업 계획, 자동화 설비, 자재 배치 등을 효율적으로 관리하기 위해 사용하는 시스템입니다.</p><p id="7a77">OMS는 <strong>Order Management System</strong>(주문 관리 시스템)의 약자로, 주문을 관리하고 처리하는 시스템입니다. 주로 커머스나 물류, 유통 등에서 사용되며, 제품 주문의 수집부터 출하, 배송, 재고 관리까지 모든 단계를 추적하고 최적화하는 역할을 합니다.</p></blockquote><p id="91c6">따라서, 무신사는 빠르고 유연한 신규 비즈니스 확대를 목적으로 작년부터 MWMS 개발을 시작했고, 현재 무신사의 모든 first-mile 인프라를 MWMS로 전환했습니다.</p><h2 id="9ad3">MWMS 개발 배경</h2><figure><figcaption>그림2. MWMS 로고</figcaption></figure><p id="c4d8">MWMS 프로젝트는 구체적으로 아래 문제를 해결하기 위해 시작되었습니다.</p><p id="c0f2"><strong>하나, 빠른 비즈니스 확장 불가.</strong></p><ul><li id="d3bd">외주 솔루션은 필요한 기능을 적시에 지원하지 못하고, 성능 문제로 작업 효율이 매우 떨어졌습니다.</li><li id="1483">신규 비즈니스나 자동화 설비 도입 시 개발 및 일정 조정에 시간이 오래 걸리며, 데이터 분석 및 의사결정에 필요한 정보를 적시에 제공받지 못했습니다.</li></ul><p id="c19d"><strong>둘, 비용 절감.</strong></p><ul><li id="40cf">무신사의 자체 WMS가 없어 운영사를 중간에 거쳐야 했으나, 자체 시스템이 있다면 비용을 큰 폭으로 절감할 수 있습니다.</li></ul><h2 id="80ce">3개월의 남은 작업 일정</h2><p id="b3af">신규 WMS 개발 프로젝트가 기획된 이후, 수개월간 개발을 진행했으나 담당 개발자의 잦은 업무 변경과 불명확한 작업공수 산정 등의 이유로 개발 완료 일정이 여러 차례 지연되었습니다.</p><figure></figure><p id="037c">어떤 이유로든 시간은 우리를 기다려주지 않습니다. 기존 운영사의 계약 만료 시점이 벌써 임박했습니다. 이에 따라 개발 완료일정 또한 단 3개월 앞으로 다가왔으나, 진척도는 20% 수준이었습니다.<br>급한 대로 개발자 채용을 시작했지만, 당장 필요한 인원을 빠르게 모으기는 어려웠기에 TF를 구성했고 저 또한 이때 투입되었습니다.</p><p id="1f56">프로젝트의 성공을 위한 액션 아이템에 앞서, 팀에서 의지를 다지며 얘기했던 내용을 원칙으로 정리하면 아래와 같습니다.</p><blockquote><p id="b33d"><strong><em>1. 단기 목표 중심적으로 일하자.</em></strong></p><p id="1ef0"><strong><em>2. 할 수 있는 만큼 해내자.</em></strong></p><p id="054f"><strong><em>3. 오버 커뮤니케이션하자.</em></strong></p></blockquote><p id="1f36">그리고 실천한 액션.</p><p id="e9df">먼저 첫 번째 원칙에 따라 우리는 <strong>스프린트 방식을 도입</strong>하고, 매 <strong>스프린트 마지막 날에 데모를 진행</strong>했습니다. 이는 두 가지 이유가 있습니다.</p><p id="b1eb">첫 번째 이유, 일감의 크기 산정과 개발 속도를 더욱 정확하게 진단하고 우리가 프로젝트를 완수할 시점이 언제인지를 파악할 수 있습니다.</p><p id="b4e6">복잡한 프로젝트일수록 납기일을 정확하게 예상하는 것은 매우 어렵지만, MWMS의 경우는 (여러 이유로, 계약 관계 때문에) 이미 작업 완료 일정이 결정되었던 프로젝트로, 정말 우리가 프로젝트를 성공시킬 수 있을 것인지 반드시 가늠해야만 했습니다. 불가능하다면 하루라도 빨리 적색 신호등을 켜기 위해서요.<br>전체 일감의 크기를 재산정하고 두 번의 스프린트를 진행한 이후에는 모두가 할 수 있다는 자신감을 가질 수 있었습니다.</p><p id="406d">두 번째 이유, “동작 가능한 코드”를 보장하기 위해 스프린트 단위로 데모를 진행했습니다. 스프린트로 일감을 나누어 데모의 범위를 한정할 수 있었습니다.</p><p id="6a99">이로써 스프린트 데모는 우리의 0순위 목표가 되었습니다. 입고부터 출고까지 사용자의 사용 흐름에 따라 스프린트 작업 우선순위를 결정했기 때문에, 이전 데모를 성공적으로 마무리하지 못한다면 다음 개발은 없었습니다. 따라서, 단 한 가지 문제에 집중할 수 있었습니다.</p><figure></figure><p id="1bc5">두 번째 원칙에 따라 <strong>“무자비한 우선순위 정하기”</strong>를 실천했습니다.</p><p id="4bf8">저는 가장 중요한 프로젝트인 MWMS 외 다른 작업에 눈곱만큼도 관심을 두지 않았는데요. 업무 집중도를 높이기 위해 반드시 필요한 미팅만 참석하고, 이 프로젝트에 투입되기 전 8명의 조직을 이끌었던 저는 모든 의사결정과 책임을 팀원에게 위임했습니다. 결과적으로 제 빈자리는 동료들이 완벽하게 채워줬고, 저와 팀 모두 한 단계 성장하는 기회가 되었습니다. 이는 생각보다 큰 용기가 필요합니다. 조직이 흔들릴 것이라는 불안과 책임감을 떨쳐내야 합니다. 동료를 믿으세요.</p><p id="8782">마지막으로 세 번째 원칙을 위해 <strong>모든 논의를 하나의 프로젝트 채널에서 진행</strong>했습니다. 이로써 모든 진행 상황과 변경 사항은 단일 채널만으로 추적할 수 있게 되었습니다. 매일 각자의 작업 진행 상황을 공유하고, 요구사항에 대한 질문은 즉시 채널에 공유하고, 변경이 발생한 경우 인지가 필요한 멤버를 모두 멘션했습니다. 물류 도메인의 특성상 변경된 제약사항에 대해 모두가 인지해야만 전후 작업끼리 데이터 정합성이 흔들리지 않기 때문입니다. 상당한 비용이 따르는 업무 방식이었지만, 문제 해결에 집착하는 PM과 엔지니어들로 구성되었던 우리는 그야말로 완벽한 호흡을 보여줬습니다.</p><p id="4854">여담으로 저는 퇴근할 때마다 인사말 대신 <strong>“파이팅!”</strong>을 외치며 전의를 다졌습니다 🙂</p><h2 id="8326">너무나도 생소한 물류 도메인</h2><p id="a411">또 다른 난관은 생전 처음 보는 물류 용어들과 씨름하는 것이었습니다. 물류 는 팀 내 엔지니어 모두가 처음 경험하는 분야였습니다.<br>ASN, DO, Wave 등의 생소한 물류 용어와 더불어 물류센터에서는 입고부터 출고까지 수많은 단계(그림3 참고)를 거칩니다.<br>각 단계 전후에 생성되는 데이터는 강하게 결합되어 있기 때문에 특정한 하나의 단계만 이해하고 코드를 작성하기 어려웠습니다.</p><figure><figcaption>그림3. 입고, 출고 단계</figcaption></figure><p id="6547">특히 재고할당(그림4 참고)은 WMS 시스템에서 가장 비용이 큰 작업이며, 충분한 성능이 보장되지 않을 경우 현장에서 작업을 대기하는 불상사가 발생할 수 있기에 가장 고민이 많이 필요한 작업이었습니다.</p></div><div><p id="85a5">이처럼 복잡한 요구사항은 오로지 텍스트만으로 정확한 사용 사례를 이해하기 어려워, 개발팀 모두 센터에 방문(그림5 참고)해서 전체적인 입출고 흐름을 직접 경험하며 현장 작업자의 요구 사항을 파악했습니다.</p><figure><figcaption>그림5. 현장 방문 (패킹 작업)</figcaption></figure><p id="56fe">예를 들면, 바코드를 스캔하는 작업은 숙련자일수록 스캔 속도가 매우 빨랐는데, 단 수십 ms의 API 응답 지연이 발생하더라도 하루 수십, 수백만 건이 스캔되는 것을 가정하면 생산성이 크게 저하될 수 있음을 깨닫고 높은 응답 퍼포먼스를 보장하도록 구현했습니다.</p><h2 id="dd52">2주간의 통합테스트, 롤아웃, 그리고 성능 문제</h2><p id="8076">폭풍 같은 3개월간의 개발 후, 두 달 동안 총 800개 이상의 테스트 케이스에 대한 통합테스트를 진행했습니다.<br>무신사에서 가장 물동량이 많은 블랙프라이데이 기간의 실제 출고 데이터를 기반으로 대량 출고 스트레스 테스트까지 마쳤습니다.</p><p id="d6b3">통합테스트 기간 동안에는 최대한 작업 현장과 동일하게 테스트하기 위해 개발팀이 물류센터에 상주하면서 운영팀과 지속적으로 소통했습니다. 일부 PM과 엔지니어는 물류센터 근처에 숙소를 잡고 통근하면서 문제해결에 집중했습니다.</p><figure></figure><p id="7413">첫 센터 롤아웃 이후 바로 성능 문제가 대두되었습니다.<br>재고할당, 피킹지시와 같이 크고 굵직한 기능은 수많은 테스트를 거쳐 자신 있었던 반면에, 데이터 조회 영역에서 여러 성능 문제가 발견되었습니다.<br>통합테스트에서는 사용할 데이터에만 집중했지, 사용하지 않는 (혹은 soft-delete된) 데이터가 합쳐지니 스캔 범위가 기하급수적으로 늘어났습니다. 물류 흐름에 따라서 재고 테이블에만 매일 수백만 개의 레코드가 삽입되기 때문이기도 합니다.<br>그래서, 롤아웃 첫 주는 필요한 인덱스를 생성하고 N+1 쿼리를 줄이는 패치, 불필요한 데이터를 분리 보관하는 작업을 빠르게 진행했습니다. 이 과정에서 Datadog Trace를 적극 활용했습니다. 데이터 멍멍이 만세!</p><h2 id="2995">성과</h2><p id="b048">폭풍 같은 개발과 QA를 거쳐 엄청난 성과를 이뤄냈습니다.</p><ul><li id="897e">TF 구성 3개월 만에 WMS 개발을 완료했습니다.</li><li id="7a7f">가장 많은 물량을 점유하는 여주 1센터에 우선적으로 배포, 첫 사용 시 장애 한 번 없이 원활하게 런치했습니다. 이후 3개월 만에 나머지 3개 센터에 성공적으로 확장 배포했습니다.</li><li id="6620">작업지시 성능은 9배 향상, 피킹동선 최적화 알고리즘 적용으로 이동동선은 절반으로 단축했습니다.</li><li id="bda7">출력된 종이를 사용한 기존 수기피킹을 PDA 바코드 스캔으로 전환해 오류 발생을 최소화했습니다.</li><li id="91db">데이터 파이프라인을 구성해 Databricks, Amazon QuickSight 등의 BI 도구를 사용한 빠른 데이터 기반 의사결정이 가능해졌습니다.</li></ul><h2 id="fe4c">마치며</h2><p id="fb65">혼자 할 수 있는 일은 생각보다 많지 않습니다. 그래서 큰 목표를 실현하기 위해서는 항상 팀으로 고민해야 합니다. 우리는 주어진 목표를 달성하기 위해 달성할 수 있는 목표인지 빠르게 검증했고, 그 가능성을 보았을 때 원칙을 세우고 모두가 한 마음으로 문제를 해결하기 시작했습니다. 그리고 불가능해 보였던 목표를 달성했습니다.</p><p id="dcfc">현재의 MWMS는 물류 입출고를 위한 기본 기능만을 지원하고 있습니다. 우리는 앞으로도 생산성 향상을 위해서 끊임없이 함께 고민하고 개선할 것입니다.</p><figure></figure><p id="cdf3">화려하지 않아도 팀의 승리를 위해 물불 안 가리고 뛰어드는 모습은 언제나 아름답습니다.</p></div></div>

MUSINSA tech - Medium

들어가며
안녕하세요, PBO(Platform Business Operation)에서 MUSINA WMS(이하 MWMS)를 개발하고 있는 백엔드 엔지니어 임상진입니다.
무신사는 빠른 배송과 반품, 오프라인과 글로벌 시장 확대를 위해 물류 시스템 개선에 몰두하고 있습니다.
과거 2023년까지 총 4개 물류센터에서 2가지의 상이한 외주 솔루션을 사용해 운영되고 있었습니다.
물류센터를 운영하기 위해서는 WMS라는 시스템이 필수적인데요. 우리가 사용하던 외주 솔루션은 내재화된 시스템이 아니었기 때문에 시시각각 변경되는 요구사항에 즉각 대응하거나 비즈니스를 확장하기에 매우 불리했습니다. 특히 일부 기능은 MUSINSA OMS(이하 MOMS)에 개발되어야만 했습니다.
잠깐, WMS와 OMS가 뭘까요?
WMS는 Warehouse Management System(창고 관리 시스템)의 약자로, 창고나 물류센터에서 재고 관리, 입출고, 작업 계획, 자동화 설비, 자재 배치 등을 효율적으로 관리하기 위해 사용하는 시스템입니다.
OMS는 Order Management System(주문 관리 시스템)의 약자로, 주문을 관리하고 처리하는 시스템입니다. 주로 커머스나 물류, 유통 등에서 사용되며, 제품 주문의 수집부터 출하, 배송, 재고 관리까지 모든 단계를 추적하고 최적화하는 역할을 합니다.
따라서, 무신사는 빠르고 유연한 신규 비즈니스 확대를 목적으로 작년부터 MWMS 개발을 시작했고, 현재 무신사의 모든 first-mile 인프라를 MWMS로 전환했습니다.
MWMS 개발 배경
MWMS 프로젝트는 구체적으로 아래 문제를 해결하기 위해 시작되었습니다.
하나, 빠른 비즈니스 확장 불가.
외주 솔루션은 필요한 기능을 적시에 지원하지 못하고, 성능 문제로 작업 효율이 매우 떨어졌습니다.
신규 비즈니스나 자동화 설비 도입 시 개발 및 일정 조정에 시간이 오래 걸리며, 데이터 분석 및 의사결정에 필요한 정보를 적시에 제공받지 못했습니다.
둘, 비용 절감.
무신사의 자체 WMS가 없어 운영사를 중간에 거쳐야 했으나, 자체 시스템이 있다면 비용을 큰 폭으로 절감할 수 있습니다.
3개월의 남은 작업 일정
신규 WMS 개발 프로젝트가 기획된 이후, 수개월간 개발을 진행했으나 담당 개발자의 잦은 업무 변경과 불명확한 작업공수 산정 등의 이유로 개발 완료 일정이 여러 차례 지연되었습니다.
어떤 이유로든 시간은 우리를 기다려주지 않습니다. 기존 운영사의 계약 만료 시점이 벌써 임박했습니다. 이에 따라 개발 완료일정 또한 단 3개월 앞으로 다가왔으나, 진척도는 20% 수준이었습니다.
급한 대로 개발자 채용을 시작했지만, 당장 필요한 인원을 빠르게 모으기는 어려웠기에 TF를 구성했고 저 또한 이때 투입되었습니다.
프로젝트의 성공을 위한 액션 아이템에 앞서, 팀에서 의지를 다지며 얘기했던 내용을 원칙으로 정리하면 아래와 같습니다.
1. 단기 목표 중심적으로 일하자.
2. 할 수 있는 만큼 해내자.
3. 오버 커뮤니케이션하자.
그리고 실천한 액션.
먼저 첫 번째 원칙에 따라 우리는 스프린트 방식을 도입하고, 매 스프린트 마지막 날에 데모를 진행했습니다. 이는 두 가지 이유가 있습니다.
첫 번째 이유, 일감의 크기 산정과 개발 속도를 더욱 정확하게 진단하고 우리가 프로젝트를 완수할 시점이 언제인지를 파악할 수 있습니다.
복잡한 프로젝트일수록 납기일을 정확하게 예상하는 것은 매우 어렵지만, MWMS의 경우는 (여러 이유로, 계약 관계 때문에) 이미 작업 완료 일정이 결정되었던 프로젝트로, 정말 우리가 프로젝트를 성공시킬 수 있을 것인지 반드시 가늠해야만 했습니다. 불가능하다면 하루라도 빨리 적색 신호등을 켜기 위해서요.
전체 일감의 크기를 재산정하고 두 번의 스프린트를 진행한 이후에는 모두가 할 수 있다는 자신감을 가질 수 있었습니다.
두 번째 이유, “동작 가능한 코드”를 보장하기 위해 스프린트 단위로 데모를 진행했습니다. 스프린트로 일감을 나누어 데모의 범위를 한정할 수 있었습니다.
이로써 스프린트 데모는 우리의 0순위 목표가 되었습니다. 입고부터 출고까지 사용자의 사용 흐름에 따라 스프린트 작업 우선순위를 결정했기 때문에, 이전 데모를 성공적으로 마무리하지 못한다면 다음 개발은 없었습니다. 따라서, 단 한 가지 문제에 집중할 수 있었습니다.
두 번째 원칙에 따라 “무자비한 우선순위 정하기”를 실천했습니다.
저는 가장 중요한 프로젝트인 MWMS 외 다른 작업에 눈곱만큼도 관심을 두지 않았는데요. 업무 집중도를 높이기 위해 반드시 필요한 미팅만 참석하고, 이 프로젝트에 투입되기 전 8명의 조직을 이끌었던 저는 모든 의사결정과 책임을 팀원에게 위임했습니다. 결과적으로 제 빈자리는 동료들이 완벽하게 채워줬고, 저와 팀 모두 한 단계 성장하는 기회가 되었습니다. 이는 생각보다 큰 용기가 필요합니다. 조직이 흔들릴 것이라는 불안과 책임감을 떨쳐내야 합니다. 동료를 믿으세요.
마지막으로 세 번째 원칙을 위해 모든 논의를 하나의 프로젝트 채널에서 진행했습니다. 이로써 모든 진행 상황과 변경 사항은 단일 채널만으로 추적할 수 있게 되었습니다. 매일 각자의 작업 진행 상황을 공유하고, 요구사항에 대한 질문은 즉시 채널에 공유하고, 변경이 발생한 경우 인지가 필요한 멤버를 모두 멘션했습니다. 물류 도메인의 특성상 변경된 제약사항에 대해 모두가 인지해야만 전후 작업끼리 데이터 정합성이 흔들리지 않기 때문입니다. 상당한 비용이 따르는 업무 방식이었지만, 문제 해결에 집착하는 PM과 엔지니어들로 구성되었던 우리는 그야말로 완벽한 호흡을 보여줬습니다.
여담으로 저는 퇴근할 때마다 인사말 대신 “파이팅!”을 외치며 전의를 다졌습니다 🙂
너무나도 생소한 물류 도메인
또 다른 난관은 생전 처음 보는 물류 용어들과 씨름하는 것이었습니다. 물류 는 팀 내 엔지니어 모두가 처음 경험하는 분야였습니다.
ASN, DO, Wave 등의 생소한 물류 용어와 더불어 물류센터에서는 입고부터 출고까지 수많은 단계(그림3 참고)를 거칩니다.
각 단계 전후에 생성되는 데이터는 강하게 결합되어 있기 때문에 특정한 하나의 단계만 이해하고 코드를 작성하기 어려웠습니다.
특히 재고할당(그림4 참고)은 WMS 시스템에서 가장 비용이 큰 작업이며, 충분한 성능이 보장되지 않을 경우 현장에서 작업을 대기하는 불상사가 발생할 수 있기에 가장 고민이 많이 필요한 작업이었습니다.
이처럼 복잡한 요구사항은 오로지 텍스트만으로 정확한 사용 사례를 이해하기 어려워, 개발팀 모두 센터에 방문(그림5 참고)해서 전체적인 입출고 흐름을 직접 경험하며 현장 작업자의 요구 사항을 파악했습니다.
예를 들면, 바코드를 스캔하는 작업은 숙련자일수록 스캔 속도가 매우 빨랐는데, 단 수십 ms의 API 응답 지연이 발생하더라도 하루 수십, 수백만 건이 스캔되는 것을 가정하면 생산성이 크게 저하될 수 있음을 깨닫고 높은 응답 퍼포먼스를 보장하도록 구현했습니다.
2주간의 통합테스트, 롤아웃, 그리고 성능 문제
폭풍 같은 3개월간의 개발 후, 두 달 동안 총 800개 이상의 테스트 케이스에 대한 통합테스트를 진행했습니다.
무신사에서 가장 물동량이 많은 블랙프라이데이 기간의 실제 출고 데이터를 기반으로 대량 출고 스트레스 테스트까지 마쳤습니다.
통합테스트 기간 동안에는 최대한 작업 현장과 동일하게 테스트하기 위해 개발팀이 물류센터에 상주하면서 운영팀과 지속적으로 소통했습니다. 일부 PM과 엔지니어는 물류센터 근처에 숙소를 잡고 통근하면서 문제해결에 집중했습니다.
첫 센터 롤아웃 이후 바로 성능 문제가 대두되었습니다.
재고할당, 피킹지시와 같이 크고 굵직한 기능은 수많은 테스트를 거쳐 자신 있었던 반면에, 데이터 조회 영역에서 여러 성능 문제가 발견되었습니다.
통합테스트에서는 사용할 데이터에만 집중했지, 사용하지 않는 (혹은 soft-delete된) 데이터가 합쳐지니 스캔 범위가 기하급수적으로 늘어났습니다. 물류 흐름에 따라서 재고 테이블에만 매일 수백만 개의 레코드가 삽입되기 때문이기도 합니다.
그래서, 롤아웃 첫 주는 필요한 인덱스를 생성하고 N+1 쿼리를 줄이는 패치, 불필요한 데이터를 분리 보관하는 작업을 빠르게 진행했습니다. 이 과정에서 Datadog Trace를 적극 활용했습니다. 데이터 멍멍이 만세!
성과
폭풍 같은 개발과 QA를 거쳐 엄청난 성과를 이뤄냈습니다.
TF 구성 3개월 만에 WMS 개발을 완료했습니다.
가장 많은 물량을 점유하는 여주 1센터에 우선적으로 배포, 첫 사용 시 장애 한 번 없이 원활하게 런치했습니다. 이후 3개월 만에 나머지 3개 센터에 성공적으로 확장 배포했습니다.
작업지시 성능은 9배 향상, 피킹동선 최적화 알고리즘 적용으로 이동동선은 절반으로 단축했습니다.
출력된 종이를 사용한 기존 수기피킹을 PDA 바코드 스캔으로 전환해 오류 발생을 최소화했습니다.
데이터 파이프라인을 구성해 Databricks, Amazon QuickSight 등의 BI 도구를 사용한 빠른 데이터 기반 의사결정이 가능해졌습니다.
마치며
혼자 할 수 있는 일은 생각보다 많지 않습니다. 그래서 큰 목표를 실현하기 위해서는 항상 팀으로 고민해야 합니다. 우리는 주어진 목표를 달성하기 위해 달성할 수 있는 목표인지 빠르게 검증했고, 그 가능성을 보았을 때 원칙을 세우고 모두가 한 마음으로 문제를 해결하기 시작했습니다. 그리고 불가능해 보였던 목표를 달성했습니다.
현재의 MWMS는 물류 입출고를 위한 기본 기능만을 지원하고 있습니다. 우리는 앞으로도 생산성 향상을 위해서 끊임없이 함께 고민하고 개선할 것입니다.
화려하지 않아도 팀의 승리를 위해 물불 안 가리고 뛰어드는 모습은 언제나 아름답습니다.
Musinsa CAREER
무신사는 문제 해결에 집착하는 분들을 기다리고 있습니다.
함께할 동료를 찾습니다.
PBO(Platform Business Operation) 조직은 국내/외 물류 서비스, 재고관리, 매장 운영을 위한 제품을 구축하고 운영하는 물류 프로덕트와 다양한 오프라인 비즈니스 모델에서 고객경험을 향상시킬 수 있는 매장 관리 시스템을 개발하고 고도화합니다. 더불어 플러스 배송서비스를 비롯한 무신사의 차별화된 고객 경험을 브랜딩하고 더 많은 고객에게 제공될 수 있는 멤버쉽 구조를 설계합니다.
전국민이 사용하는 1위 패션 플랫폼 무신사에서 기술로 비즈니스를 성장시키는 경험을 함께하고 싶으시다면 아래 채용 페이지를 통해 지원해 주세요!
🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)
🚀 팀 무신사 테크 소식을 받아보는 링크드인
🚀 무신사 테크 블로그
🚀 29CM 테크 블로그
🚀 무신사 테크 유튜브 채널
채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!
어떻게 3개월 만에 MUSINSA WMS를 개발할 수 있었을까? was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

어떻게 3개월 만에 MUSINSA WMS를 개발할 수 있었을까?

댓글