Business Development.. 모든 것이고 모든 것이 아니다
메이코더스는 해외바이어를 위한 화장품 브랜드 수출플랫폼인 SEOUL4PM, 해외바이어를 위한 화장품 제조플랫폼인 mayk 두 종의 플랫폼을 운영하고 있다. 작년까진 mayk의 앞단.. (제조가 시작되기 직전), 올해에는 SEOUL4PM의 뒷단.. (발주가 시작된 이후)을 주로 개발했다.
온라인 프로덕트로 이 업에서 플레이한다는 것의 차별점은 두 가지 핵심적인 상황에서 기인한다. 첫째, 바이어들은 상품/제품 데이터를 기반으로 온라인으로 유입된다, 둘째, 무역에서 다품종을 다루는 것은 너무 힘들고 고된일이다. 아마 기존 업계 사람이 핸들링한다면, 단일 제품을 수천개 오더하기를 바라고, 수작업으로 해 줄 것이다. 그러나 브랜드, 제조사와 고객간의 관계가 극도의 다대다 관계로 변화하고 있고, 롱테일조차도 한 때는 다 유명한 브랜드였던 지금, 고객은 다양한 상품을 한번에 가져가길 원하고, 다양한 상품을 한번에 소싱하는 것은 물리적으로 너무 힘든 일이다.
그래서 메이코더스는 데이터와 자동화로 위 부분에 대한 해자를 가지고 있다. 상품과 제품 데이터를 온라인에 깔아놓고, 검색을 통한 소싱의 온라인 문턱 역할을 한다. SEOUL4PM의 경우 이게 되려면, 다양한 상품 소싱이 가능한 뒷단이 서포트돼야한다. 프리오더 기반의 국내 유통 네트워크를 참여시키고, 자동화 요소를 도출했다. 다품종에 대한 소량 소싱, 사람이 한다면 힘들어서 곧 포기하고말 일을 기계의 도움을 받아 지속적으로 할 수 있는 기반을 마련했다.
그냥 내 느낌인데, 우리회사는 엄청 높은 장벽을 쌓고 있다. 집요하게 이렇게 비즈니스를 데이터 모델로 만들 수 있는 사람이 대한민국에 몇 되지 않을 것 같다. 이미 브랜드 투자, 사입으로 창고기반 매출을 집중적으로 내는 구조에 온라인 홈페이지 등으로 기반이 닦인 기존 업계는 당연히 더 많은 다양성을 핸들링하기 어렵고, 반대로 IT전문가 집단이 온다 하더라도, 뷰티무역업을 이렇게 장시간 모니터링 하면서 모델링하기는 쉽지 않다고 본다.
솔직히 말하면 본능적으로 했다고 밖에는 말을 못하겠다. 어떤 상황에는 이러이러한게 문제 같아서, 풀었고, 어떤 상황에는 이러이러한 것을 물어봐야 할 것 같아서 물었다. 답을 받고는 왠지 이런 의미인가? 라고 통찰했고, 프로덕트로 넘길 것은 넘기고, 고객과 소통하면서 해결해야할 것은 조금씩 개선했다. 아마 프로덕트랑 혼재된 형태로 작년 하반기까지 개발을 했던 것 같고, 새로운 PM이 조인하면서 SEOUL4PM의 비즈니스 개발만 몰입할 수 있었다. 2개월 정도는 프리오더 기반의 국내 유통네트워크를 직접 운용하면서 모델을 만들었다. 리드타임이 표준화되지 않은 제각각의 프로세스에 이름을 붙이고, 측정을 시작했다. 나머지 3개월 정도는 고객을 개발했다. 작아보였는데 컸던 고객, 딱 들어도 컸던 고객, 작고 많고 많은 고객과 수없이 이야기를 나누며 개발했던 것 같다. 왓츠앱, 이메일, 온라인미팅 등 채널을 가리지 않았다. 아직 갈 길은 멀지만, 그래서 stylekorea, umma랑 차별점은 뭔데?에 답할 수 있는 몇 가지 요소를 작동시켰다.
몇 개월간 함께 고생한 비즈데브 멤버들이 글로벌 고객개발을 하반기 목표로 설정했다. 이미 너무 훌륭하게 상반기 미션을 클리어한 멤버들이라, 내가 가이드를 할 수 있다고 말하기는 어렵지만 산더미 같은 문제에서 조금이라도 길이 될 수 있도록 본능적으로 했던 부분들을 생각하고 정리해본다.
문제가 무엇일까?(Qualification)
문제의 범주는 2가지다. 고객의 어려움, 상황의 어려움. 예를들어 고객이 특정 브랜드 소싱을 문의하는 것은 분명 고객이 구하기 어려운 물건을 구하고 있는, 문제에 직면하고 있기 때문이고, 해당 요구사항에 답변을 장기간 못하고 있는 것은 우리가 브랜드의 가격표를 얻어올 수 없는, 상황의 어려움에 직면하고 있기 때문이다.
고객의 어려움은 아이디어를 내서 해결한다. 프로덕트의 핵심 차별점인 'Selection'이 "정말로 고객의 문제를 해결하고 있는가?"에 대해서 되물어야 한다. 개별 고객이 3~4개 브랜드, 많게는 수십개의 브랜드를 소싱하고 있는 상황에서 우리는 아직 개별 오더당 브랜드 수라는 단일값을 통해 추상적으로 밖에 모른다. 그래서 물어봐야한다. 왜 그런식으로 샀는지, 왜 이러이러한 브랜드로 구성을 했는지, 왜 동일 카테고리에서 다양한 브랜드를 구비했는지, 왜 이것은 이만큼, 왜 이것은 저만큼 샀는지, 왜 다른 플랫폼이 아니라 여기에 와서 샀는지 말이다. 되도록 전체 고객군 모두에게 물어보는 것이 고객개발이라고 생각한다. 고객 세그멘트가 있다면 나누어 답변의 분포를 보는 것도 유의미할 것 같다. 브랜드 트렌드 정보가 있다면 시기별로 답변을 비교해보는 것도 유의미할 것 같다. 그런데 '고객만족도조사' 이런 느낌의 접근은 재미가 없을지도 모르겠다. 아이디어가 더 필요하다(린 고객개발에서는, 상당히 개인적으로, 서비스 초기 지지자들에게 질문하고 열성적인 답변을 받기를 권유한다)
상황의 어려움은 해결점이 자명해 보통 얼마나 구현이 빠르게 되느냐가 중요한 것 같다. 프로덕트의 핵심 차별점인, 'Selection', 국내 프리오더 네트워크를 가지고 들어와서 해결하고 있다. 브랜드사 벤더사가 들어와서 노는 구조를 지향하지만, 아직 완전히 구현되지 않았다. 가격표가 자꾸 outdate되는 문제, 우리 로드가 많아서 답변이 느려지는 문제와 같은 질적인 것은 고객에게는 서비스에 불만족하게 되는 크리티컬한 요소다. 우리가 플랫폼 구조를 지향한다면 이런 느려지는 문제를 참여로써 해결하고 싶어한다. 참여가 이 문제를 정확히 해결할 수 있도록 해야한다. 호의적이거나 호의적이지 않은 브랜드사와 벤더사를 찾고, 이들의 입점 요인을 명확하게 한다. 왜 입점하고 싶어하는지? 입점해서 하루종일 보고 있으려면 얼마나 리텐션이 발생해야하는지? 이들은 평소에 얼마나 일하고, 어떤 것을 어려워하는지? 이들은 브랜드 판권을 어떤 식으로 설정하는지? 들어와서 작동하도록 하고, 측정해야한다.
결국 Qualification은 'Selection'이 고객과 상황의 문제를 해결하고 있는 양질의 질문데이터셋을 구축하는 과정이라고 이해한다. 아마도 내가 기자출신이기 때문에 왠지 모르게 이런걸 물어봐야할 것 같은 직감을 가지고 있었다고 생각한다.
무엇을 데이터로 쌓을까?(Quantification)
고객, 상황과의 소통채널이 확정됐으면 데이터화를 한다. 데이터화를 할 때 기본으로 생각해야하는 개념은 바로 '추상화(Abstraction)'이다. 엄청 고급의 추상화 모델을 다루고자 하는 것은 아니고, 직관적인 선에서 일단 구글시트를 구성해본다.
보통 내가 구글시트를 구성하는 방법은 2장을 한 세트로 하는 것이었다. 첫장은 메타데이터(meta data), 두번째 장은 생데이터(raw data)를 담고 있다. 메타데이터는 데이터를 위한 데이터, 추상화된 데이터를 의미한다. 생데이터에 어떤 상세가 있는지 직관적으로 알게 하는 정보인 셈. 수백~수천 줄의 생데이터를 한 줄로 설명한다. 예를 들어 카카오톡을 생각해본다. 채팅의 리스트, 하나를 누르면 상세 채팅내용이 나온다. mp3 등의 음원파일을 생각해 본다. 음원은 재생하여 그 구성물들을 알 수 있지만, 음원 파일을 우클릭하여 볼 수 있는 메타데이터는 이 음원의 용량이 몇 MB인지, 누구에 의해 만들어졌는지, 재생시간이 얼마나 되는지를 설명한다.
먼저 생데이터를 정의한다. 쌓아야겠다 생각한 데이터는 앞의 Qualification에서 추출한 물음에서 컬럼명을 도출하고, 고객의 답변에서 컬럼의 속성값을 도출한다. 예를 들어 고객에게 selection을 탐구하고 싶으니, 고객에게 뭘 샀니를 물었고, 고객은 뭘 샀다고 답을 한다. 구매상품, 수량을 컬럼명으로 한다. 그리고 고객답변이 있으니 고객명을 컬럼명으로 한다. 특정 고객이 구매한 내역을 한 행 한 행 적는다. 생각해보니 며칠간 모아서 발주하기도 하니, 실제 오더 아이디, 오더생성일자도 컬럼명으로 추가한다.
단순히 생각하면 특정 구매내역은 특정 주문아이디로 묶인다. 하지만 우리는 Qualification을 통해 고객이 한 주문에 모든 상품을 묶어 놓지 않고, 동시점 혹은 며칠 이내의 주문에 여러 브랜드를 묶어 놓는 것을 알고 있다. 그리고 메타데이터 시트에, 특정 orderId와 매칭되는 생데이터의 정보를 count, sumif 등 짧은 함수로 취합도출해 현황을 알 수 있게 한다. orderId뿐 아니라 고객과 날짜 기준을 컬럼명으로 넣었으므로 취합하는 아이디어를 도출(고객으로 group, 날짜는 <->3일로 취합) 하고, 이 취합된 메타데이터에도 새로운 Id를 부여해본다.
이렇게 접근할 수도 있다. 고객에게 selection이 작동하는지 알고 싶으니, 고객이 산 상품이 타플레이어에게 정말 없는 것인지 탐구가 필요할수도 있다. 그렇다면 사이트에 들어가서, 있다 없다 여부, 해당 상품의 가격대를 데이터로 쌓을 필요가 있겠다. 이런 데이터셋을 구성하는 것은 개개인이 생각하는 문제 범주에 의해서, 그리고 운영에 의해서 점점 개선되고 고도화된다.
개인적으로는 이 데이터셋 초안까지는 나와야 디테일한 논의가 가능하다고 생각한다. 아이디어가 어느정도 구체화된 단계이고, 맞나 안맞나를 판단할 수 있는 기준이 명확해지기 때문이다.
Qualification & Quantification이 이뤄졌으면 사실 대부분의 일은 마친 것으로 본다. 왜냐면 이 업계는 이것이 핵심인 업계이기 때문이다. 고도의 AI분석이 필요한 시장이 아니다. 합리적으로 문제를 해결할 수 있는 시간과 공간이 필요하다. 이 다음에는 통찰한다, 반복하고 평가한다 두 가지 과정이 이뤄진다. 해당 내용에 대해서는 다음 포스트에서 다뤄보기로 한다.
이건 방법론도 아니고 그냥 직관적으로 했던 경험을 이야기하는 것이다. 그 기간동안 비즈니스 데이터모델에 대해서라면 프리오더, 이메일, 환전에 대해서 모델링을 했고 계속 쌓아야 하는 것과 그렇지 않은 것을 판단할 수 있었다. 쌓아야 하는 것은 프로덕트로 녹일 수 있는 기획 요소로 전환되고, 그렇지 않은 것은 사람의 행동을 패턴화함으로써 위임의 가능성을 열었다. 아마 여러가지 경영방법론 책들도 단어만 다르고 비슷한 얘기하지 않으려나ㅎ
다중 오퍼레이션을 x 다중으로 진행할 수 있는 똑똑한 한국인 플레이를 모델링하는 근본적인 이유는, 시스템과 참여자에 이 일들을 위임하기 위해서다. 똑똑해서 할 수 있는 플레이라면, 그 똑똑한 사람을 많이 많이 데려와도 사람수까지밖에 스케일업이 되지 않고, 그 똑똑한 사람이 나가면 다 떨어져나가 위태롭고 의존적인 구조가 될 수밖에 없다.
나의 강점을 이야기하자면, 아마 기획력과 실행력일 것이다. 기획력에 대해서라면, 공부해온 배경상, 콘텐츠적인 뾰족함과 동시에 데이터 모델과 맞아떨어지는 보편적임 그 어떤 사이에 있다. 비즈니스 개발을 데이터화하고 프로덕트로 녹이는데 효율적인 중개자 역할이다. 바꾸어 말하면 개별 콘텐츠를 만든다고 보면 재미없게 만드는 것일수도 있고, 또 데이터 모델을 만든다고 하면 추상화레벨이 좀 떨어지는 부족한 수준일 수도 있는거 같긴 하지만. 특정 업계로 한정하면 약간 독특하지만, 디지털 전환이 필요한 시장에서는 합리적인것 같다 ㅎㅎ
https://brunch.co.kr/@saemi32/26
https://brunch.co.kr/@saemi32/27