<div id="readability-page-1" class="page"><div aria-label="Content">
 
 
 
 <ul id="markdown-toc">
 <li><a href="#1-현재를-모르면-미래도-없다-as-is-먼저-명확히-파악하기" id="markdown-toc-1-현재를-모르면-미래도-없다-as-is-먼저-명확히-파악하기">1. 현재를 모르면 미래도 없다: As-Is 먼저 명확히 파악하기</a></li>
 <li><a href="#2-데이터를-파악하며-도메인-지식을-넓히다-거미줄처럼-얽혀있는-데이터들" id="markdown-toc-2-데이터를-파악하며-도메인-지식을-넓히다-거미줄처럼-얽혀있는-데이터들">2. 데이터를 파악하며 도메인 지식을 넓히다: 거미줄처럼 얽혀있는 데이터들</a></li>
 <li><a href="#3-사용자고객-인터뷰-중-깨달음을-얻다-soms는-생산할-수-있는-주문의-양을-조절하네" id="markdown-toc-3-사용자고객-인터뷰-중-깨달음을-얻다-soms는-생산할-수-있는-주문의-양을-조절하네">3. 사용자(고객) 인터뷰 중 깨달음을 얻다: SOMS는 생산할 수 있는 주문의 “양”을 조절하네?</a></li>
 <li><a href="#4-바늘과-실-soms와-한-쌍인-시스템을-발견하다" id="markdown-toc-4-바늘과-실-soms와-한-쌍인-시스템을-발견하다">4. 바늘과 실: SOMS와 한 쌍인 시스템을 발견하다.</a></li>
 <li><a href="#5-컬리-oms만의-product-vision을-찾다-ureka" id="markdown-toc-5-컬리-oms만의-product-vision을-찾다-ureka">5. 컬리 OMS만의 Product Vision을 찾다. UREKA!</a></li>
 <li><a href="#6-tam과-oms의-통합-뗄레야-뗄-수-없는-사이" id="markdown-toc-6-tam과-oms의-통합-뗄레야-뗄-수-없는-사이">6. TAM과 OMS의 통합: 뗄레야 뗄 수 없는 사이</a></li>
 <li><a href="#7-10개의-메뉴가-1개로-현재-oms의-핵심-기능인-주문-분배-계획의-모습" id="markdown-toc-7-10개의-메뉴가-1개로-현재-oms의-핵심-기능인-주문-분배-계획의-모습">7. 10개의 메뉴가 1개로: 현재 OMS의 핵심 기능인 “주문 분배 계획”의 모습</a></li>
 <li><a href="#8-수기업무를-모두-제거하자---자동화를-향해" id="markdown-toc-8-수기업무를-모두-제거하자---자동화를-향해">8. 수기업무를 모두 제거하자 - 자동화를 향해</a></li>
 <li><a href="#9-oms의-엔드게임---capa-수립-자동화" id="markdown-toc-9-oms의-엔드게임---capa-수립-자동화">9. OMS의 엔드게임 - ”CAPA 수립 자동화”</a></li>
</ul>

안녕하세요.

컬리의 OMS (Order Management System)의 Product Manager로 일하고 있는 염태환입니다.

2022년 1월 OMS라는 팀이 컬리에서 처음으로 생기고, 제가 해당 도메인의 첫 PM 역할을 하면서 해당 시스템이 과거 어떤 모습으로 존재했고 현재까지 어떻게 진화해왔는지, 그리고 PM으로써 어떤 과정을 통해 OMS가 진화되었는지 자식처럼 아끼고 성장시켰던 PM의 관점에서 내용을 소개드리겠습니다.



<h2 id="1-현재를-모르면-미래도-없다-as-is-먼저-명확히-파악하기">1. 현재를 모르면 미래도 없다: As-Is 먼저 명확히 파악하기</h2>

2022년 1월 회사에 처음으로 OMS라는 팀이 생기고 제가 첫 OMS의 PM을 맡았을 때 OMS는 SOMS(Sales Order Management System)라고 불리우고 있었습니다.

당시 제가 받은 느낌은, 이 시스템이 불빛 하나 없는 안개 속에 혼자 서 있는 듯 했습니다.

이 시스템의 목적이 무엇인지, 현재 어떤 상태인지 명확히 정의한 문서를 거의 찾을 수 없기 때문이었죠.

특히 github에서 모든 코드를 다 읽고 분석할 수 없는 PM의 입장에서는, 이 안개를 걷어내기 위해서는 스스로 질문을 나열해야 했습니다.

그때 당시 제가 스스로 나열했던 질문은 아래와 같았습니다.

데이터 및 시스템 관점

<ul>
 <li>
 SOMS가 연동하고 있는 시스템은 어떤 것들이 있는가?

 <ul>
 <li>
 해당 시스템과 어떤 데이터를 주고 받고 있는가?
 </li>
 <li>
 주고 받는 데이터의 주기가 어떠한가?
 </li>
 </ul>
 </li>
 <li>
 SOMS가 직접 판단하고 생성하는 데이터는 어떤 것들이 있는가?

 <ul>
 <li>
 그 데이터가 운영과 사용자에 미치는 영향은 무엇인가?
 </li>
 <li>
 SOMS가 판단하고 생성하는 데이터라면 어떤 근거로 판단되고 있는가?
 </li>
 </ul>
 </li>
</ul>

사용자(고객) 관점

<ul>
 <li>
 SOMS가 현재 갖추고 있는 기능은 무엇인가?
 </li>
 <li>
 현재 SOMS를 누가 사용하고 있는가? (사용자 및 이해관계자 리스트업)
 </li>
 <li>
 해당 사용자가 어떤 업무를 위해 어떤 목적으로 어떤 기능들을 사용하고 있는가?
 </li>
</ul>

등 이었습니다.

위 질문에 명확히 답을 얻는 과정은 매우 중요했습니다.

현 상태를 그릴 수 없으면 앞으로 우리가 설정해야할 Product Vision도 설정할 수 없기 때문이었죠.



<h2 id="2-데이터를-파악하며-도메인-지식을-넓히다-거미줄처럼-얽혀있는-데이터들">2. 데이터를 파악하며 도메인 지식을 넓히다: 거미줄처럼 얽혀있는 데이터들</h2>

SOMS는 현재도 그렇지만, 당시에도 거미줄처럼 얽힌 시스템이 많았습니다.

커머스 주문시스템, 배송시스템(TMS), 권역관리시스템(TAM), 생산처리시스템(WMS), 배송대행시스템(TOMS)등 연동되고 있는 시스템만 5개가 넘었죠 (현재는 더 많습니다).

각 시스템의 이해관계를 파악하기 위해서라도 각 시스템들과 어떤 데이터를 어떤 방식으로 어떤 주기로 연동받는지 PM으로써 저도 파악하고 있어야했습니다.

아직도 기억에 남는 것이 여러 데이터 중 배송회차라는 데이터가 있었는데(현재도 있고), 고객의 주문이 “몇 배송회차로 배송되어야하는지” 판단하는 방식은 이러했습니다.

<blockquote>
 <ol>
 <li>배송시스템 (TMS) api를 호출하여 고객의 거주지(권역)가 몇 배송회차(1,2,3)까지 지원하는지 확인한다.</li>
 <li>TAM이 어드민 기능으로 제공하고 있는 배송회차별 주문마감시간 데이터를 kafka message를 수신하여 배송회차별 주문마감시간을 비동기로 수신받는다.</li>
 <li>1,2의 정보를 토대로 고객의 주문이 몇 배송회차로 WMS/TMS로 전송되어야하는지 OMS가 최종 판단한다.</li>
 </ol>
</blockquote>

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/11.png" alt="그 당시 도식화했었던 배송회차 FLOW DIAGRAM">
 <figcaption>그 당시 도식화했었던 배송회차 FLOW DIAGRAM (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



이러한 과정을 통해 물류 지식이 많지 않았던 제가 도메인 지식이 점점 넓어지는 것을 느꼈고, 다양한 데이터들의 의미를 알 수 있었습니다.

예를 들어, “배송회차”의 경우

<ul>
 <li>
 배송회차마다 주문마감시간과 출차마감시간이 정해져있다.
 </li>
 <li>
 출차시간이 달라지면 고객에게 배송되는 상품의 배송시간도 달라질 수 있다.
 </li>
 <li>
 배송 운영 상 지역별로 지원하는 배송회차의 갯수가 다르다.

 <ul>
 <li>이는 지역별 배송집적도와 연결된다.</li>
 </ul>
 </li>
</ul>

등 많은 내용을 연결해볼 수 있었습니다.



<h2 id="3-사용자고객-인터뷰-중-깨달음을-얻다-soms는-생산할-수-있는-주문의-양을-조절하네">3. 사용자(고객) 인터뷰 중 깨달음을 얻다: SOMS는 생산할 수 있는 주문의 “양”을 조절하네?</h2>

SOMS는 Sales Order Management System의 약칭이었는데, 이를 직역하면 “판매 주문 관리 시스템”입니다.

얼핏 보면 컬리의 고객 주문과 결제를 관리하는 시스템이라고 오해할 수 있지만, 그 역할은 이미 커머스 도메인의 주문결제 시스템이 담당을 하고 있었죠.

SOMS가 그 당시 했던 일은 고객이 결제완료한 주문을 정해진 스케줄마다 커머스 주문 시스템을 호출해 해당 주문을 수신받고, WMS/TMS로 정해진 시간마다 전송하는 일이었습니다.

SOMS가 제공했던 어드민 상 기능은 크게 2가지였는데 첫 번째는 주문을 조회하는 단순 조회 기능이었고, 두번째는 주문을 정해진 시간마다 전송할 수 있는 주문 전송 스케줄 기능이었습니다.

위 기능들이 어떤 목적으로 사용되고 있는지 파악하기 위해서는 SOMS를 둘러싼 이해관계자들, 즉 SOMS 어드민에 접속해서 사용하고 있는 사용자들을 리스트업하고, 그들의 업무를 파악해야했습니다.

그때 당시 SOMS에 들어와서 업무를 하고 있는 내부 사용자는 20명도 되지 않았는데 SOMS를 사용하는 이유가 매우 다양했습니다.

예를 들어, 배송고객서비스팀에서는 배송완료 사진을 보기 위해서였고, 물류운영표준화팀은 주문 스케쥴을 등록하기 위해서였죠.

운영 프로세스를 조사하고 빼곡히 사용자를 인터뷰하던 와중 큰 깨달음을 얻게 되는데, 바로 특정 물류운영팀이 WMS로 전송해야하는 “주문의 수”를 SOMS를 통해 수도꼭지처럼 조절하고 있다는 것이었습니다.

컬리 물류센터에서는 당일에 배송회차별로 주문을 처리할 수 있는 수용량, 즉 배송회차별 Capacity(생산CAPA와 배송CAPA)가 존재하는데, 컬리의 주문량이 매일매일 증가하다보니 익일 새벽까지 출고를 완료해야하는 컬리 물류센터 입장에서는 모든 주문을 소화할 수 없었기 때문이었습니다.

말 그대로 CAPA가 주문량보다 낮으면 고객의 주문을 받지 않고, CAPA가 남으면 주문을 계속받는 방식이었습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/21.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



<h2 id="4-바늘과-실-soms와-한-쌍인-시스템을-발견하다">4. 바늘과 실: SOMS와 한 쌍인 시스템을 발견하다.</h2>

해당 업무를 위해 그때 당시 물류운영팀은 여러 시스템의 기능들을 사용한다는 것을 발견하게 되었습니다.

그 대표적인 시스템이 바로 위에서도 한 차례 언급한 TAM(Transportation Area Management) 시스템이었습니다.

배송권역을 관리할 목적으로 딜리버리 도메인에서 만들었던 이 시스템에는 배송회차별로 주문을 몇시까지 받을 것인지 설정할 수 있는 기능과, 고객의 주문을 지역(권역)별로 차단할 수 있는 기능이 탑재되어 있었습니다.

위에 설명한 것과 같이, 고객의 주문이 처리할 수 있는 CAPA보다 많으면 주문의 수를 조절해야했기 때문에 물류 운영자분들은 예상보다 주문이 너무 많이 들어오면 배송회차별 주문마감시간을 앞당겨 배송CAPA에 부하가 가지 않도록 하고, 심지어 주문이 당일에 너무나도 많이 급증할 시 고객이 더 이상 주문을 하지 못하도록 주문을 차단하여 고객이 애초에 컬리몰에서 주문을 할 수 없도록 한 것이죠.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/31.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



<h2 id="5-컬리-oms만의-product-vision을-찾다-ureka">5. 컬리 OMS만의 Product Vision을 찾다. UREKA!</h2>

저희는 해당 운영 행위를 “주문 이행 계획을 수립하고 주문을 분배하는 행위”라고 정의했습니다.

OMS가 궁극적으로 달성해야할 Product Vision에 대한 핵심 문장을 정의했다고 볼 수 있었습니다.

저는 이 내용을 OMS Product Vision으로 삼고 아래와 같이 문장으로 정의하고 도식화하였습니다.

그때 당시 정의했던 Product Vision은 아래와 같습니다

<blockquote>
 “OMS는 기존 단순 주문 전송 시스템의 역할에서 벗어나, 주문 이행/분배 계획을 수립하는 시스템의 역할을 지향하며, 궁극적으로는 고객의 주문을 다양한 정보를 기반으로 분배하여 언제, 어느 물류센터에서 생산할지, 언제, 어떻게 배송될지 자동으로 판단하는 것을 목표로 합니다”
</blockquote>

<blockquote>
 “주문 전송 및 분배 계획 수립 업무 프로세스를 규격화 및 자동화하여 생산CAPA &amp; 배송CAPA에 맞춰 주문 분배를 계획하고 전송해야하는 운영자들의 휴먼 에러를 방지하고 업무 생산성을 향상 시키는 것을 목적으로 합니다”
</blockquote>

PM으로써는 가장 보람찼던 순간 중 하나였습니다.

결국 우리 팀과 우리가 맡은 프로덕트의 end goal이 무엇인지 긴 과정 끝에 명확히 발견했다고 볼 수 있었습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/41.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



<h2 id="6-tam과-oms의-통합-뗄레야-뗄-수-없는-사이">6. TAM과 OMS의 통합: 뗄레야 뗄 수 없는 사이</h2>

OMS가 궁극적인 “주문 이행 계획을 수립하고 주문을 분배하는 시스템”이라는 최종 목표를 달성하려면 TAM과 OMS가 나누어서 갖고 있던 기능을 통합하여야 했습니다. 통합하고자 하는 이유는 크게 2가지가 있었습니다.

첫 번째는 “주문 이행/분배 계획” 판단에 중요한 데이터들을 한 곳에서 하나의 도메인이 관리해야하는 것이었습니다.

해당 데이터에는 배송예정일, 배송회차, 생산센터, 배송사, 배송유형 등 주문 분배 핵심 로직에서 한번에 판단되어야 하는 다양한 데이터들이 있었습니다.

시스템이 통합되지 않으면 특정 데이터는 OMS팀이, 또 다른 데이터는 딜리버리팀이 관리해야하는 문제가 있었습니다. 이 모든 데이터는 현재 OMS가 커머스에 단일 api를 통해 한번에 응답하는 데이터들입니다.

개념적으로도, 로직적으로도 관계성이 명확한 데이터들이었기 때문에 두 팀이 나누어서 관리하면 오히려 복잡도만 증가할 뿐이었습니다.

두 번째는 “주문 분배 계획 관리”라는 단일 기능을 내부 운영자에게 제공함으로써 유사한 업무를 위해 여러 백오피스를 동시에 사용하고 있었던 사용성 문제를 개선하는 것이었습니다.

이는 곧 운영자들의 생산성, 즉 비용과 직결되는 문제이기도 했습니다.

이를 위해 당시 TAM을 관리하던 딜리버리팀과 TAM 인수인계 계획에 논의했고 저희 개발팀은 장기간 동안 타 팀이 만들어놓은 코드를 분석하며 이관을 하는데 성공하였습니다.

(이관 과정에 대해서는 기술적인 내용이 많아 생략하겠으며, 흥미진진한 이관 과정은 저희팀 개발자 이준환님께서 곧 블로그 글을 기고해주실 예정입니다)

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/51.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



<h2 id="7-10개의-메뉴가-1개로-현재-oms의-핵심-기능인-주문-분배-계획의-모습">7. 10개의 메뉴가 1개로: 현재 OMS의 핵심 기능인 “주문 분배 계획”의 모습</h2>

OMS는 Order Management System의 약칭이지만, 현재 컬리의 OMS는 “주문 이행 계획을 수립하고 주문을 분배하는 시스템”, 즉 Order Distribution and Fulfillment System의 모습에 더 가깝습니다.

실제 타사의 사례에서도 ODF라는 시스템과 조직이 별도로 존재하기도 합니다.

아래는 OMS에 탑재한 주문 분배 계획 관리라는 메뉴의 UX입니다.

기존에 사용자는 TAM과 OMS 등 여러 백오피스에 접속해 각각 10개가 넘는 메뉴에서 설정해야했던 기능들을 아래의 단일 메뉴로 통합하는데 성공했습니다.

사용자는 아래의 기능을 통해 권역별 또는 권역그룹별로 “고객의 주문이 언제 생산되어야하고 언제 배송”되어야하는지 즉시 설정할 수 있게 되었습니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/61.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>
<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/71.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



<h2 id="8-수기업무를-모두-제거하자---자동화를-향해">8. 수기업무를 모두 제거하자 - 자동화를 향해</h2>

위 기능을 완성 시키고 나서 저희 팀은 아직 해결해야하는 문제가 있었습니다.

바로 운영자가 주문을 오늘 더 이상 받을 수 없는 상태를 시간대로 지정하는 행위였는데, 이 행위는 휴먼오류를 야기할 수 있을 뿐만 아니라 운영자가 밤늦은 시간 주문이 얼마나 들어오는지 실시간으로 지켜보며 수동으로 주문을 마감해야한다는 것이 었습니다.

이는 곧 저희가 매번 고민했던 운영자의 생산성 저하와 직결되는 문제였습니다.

이 문제를 해결하기 위해 저희 팀은 당일의 최대 생산CAPA와 배송CAPA를 사용자가 입력하는 기능을 제공하고 OMS가 실시간으로 주문의 수를 카운팅하다가 CAPA에 도달하면 익일 주문으로 전환 하는 등 자동화할 수 있는 프로세스와 기능을 고민하기 시작했습니다.

그렇게 완성된 것이 캐파를 통한 자동화 기능입니다.

<figure>
 <img src="http://thefarmersfront.github.io/post-img/oms_pm/81.png" alt="">
 <figcaption> (그림: 컬리, © 2023. Kurly. All rights reserved.)</figcaption>
</figure>



<h2 id="9-oms의-엔드게임---capa-수립-자동화">9. OMS의 엔드게임 - ”CAPA 수립 자동화”</h2>

위에서 여러차례 언급한 CAPA라는 데이터는 “물류센터와 배송 현장에서의 인력과 해당 인력의 생산성”과 직결됩니다.

아직까지 CAPA 데이터를 만드는 방식은 다양한 물류 운영자들에 의해서 수기로 만들어지고 있지만,

이 부분 또한 타 시스템 (인력관리시스템 컬리로 및 딜리버리 시스템) 등의 연동을 통해 자동화하는 것을 최종 목표로 삼고 고민하고 있습니다.

이 부분도 완성되면 또 다른 블로그를 작성할 수 있도록 하겠습니다.

 </div></div>

물류의 물짜도 모르던 OMS PM의 OMS 구축기

댓글