쿠팡맨의 로켓배송은 왜 문제의 중심에 놓이게 되었나?

개인적으로 쿠팡과 쿠팡맨이 잘되길 바랬고 내부 직원뿐만 아니라 외부에서도 응원해줘야 한다고 생각했다. 그러나 현실은 아래기사와 같이 여러가지 잡음만 늘어날 뿐이었다. (컨슈머 와이드 전XX기자는 쿠팡 저격수를 자처하는 듯 싶다.)

그래서?쿠팡의 퇴사자로서 이전에 써놓은 글 (https://tacogrammer.com/archives/126) 에 이어지는 분석 글을 작성해본다.

관련 기사들을 자세히 읽어보면 그 사이를 위메프가 치고 올라오고 있다는 언급이 있는데, 위메프는 어떻게 아무런 문제없이(아니면 없는 것처럼) 쿠팡이 하고 있는 빠른 배송을 할 수 있을까?

외주와 직접 배송을 다루는 차이일 것이다. 그렇다고 보면 쿠팡쪽이 잘되는 것이 택배업을 하는 사람들에게는 좋은 일이 될거라고 추정한다. 하지만 잘 되지 않았다. ?오히려 언론에 비춰지는 쿠팡맨들은 불만이 가득한 듯하다. 다른 외주업무를 하는 택배사들은 어떠한가? ?쿠팡맨보다 훨씬 나은 처우에서 일하고 있을까? 그들이라고 문제가 없는 것은 아닐것이다. 젊은 사람들이라 불만이 많다는 이야기로 처우하기에는 복잡한 문제이다. 내가 생각한 문제는 다음과 같다.

쿠팡맨을 제외하고는 물류 부분에서 혁신이 일어나지 못했다.

쿠팡은 내외부적으로 기술회사라고 주장한다. 물론 개발자 관점에서는 쿠팡만큼 메이커스들의 자율성에 의해 움직이는 조직은 찾기 힘들다고 이전 포스트에서 언급 했다. 하지만 현실은 쿠팡의 많은 사용자들은 쿠팡의 훌륭한 IT서비스가 아니라 쿠팡맨 때문에 사용하는 사람들이 대부분이다.

내 부적으로는 수많은 개발자들이 물류관련된 시스템을 개발하고 있지만 아마존 처럼 경제의 규모를 달성하지 못한 이상 그 진행 속도는 더딜 수 밖에 없다. 정말 이부분에서 무었인가 기존의 택배사와 다른 무었인가 일어났는가? ?결국 대규모의 쿠팡맨을 채용해 고객과의 접점에서의 쿠팡의 불씨가 일어났다면 더욱 물류쪽에서 다른 혁신이 일어났어야 한다.

개인적인 생각으로는 애자일 개발팀 처럼 쿠팡맨들에게도 자율성을 가진 팀을 만들어 일할 수 있게 하는 방법은 없었을까? MSA의 피자 한판 팀처럼 풀스택 물류센터 팀을 구성해 자율적으로 의견을 내고 아이디어를 데이터에 기반해 검증하고 최종 적용하는 그런 과정들을 도입할 수는 없었을까? 물론 나는 개발자이고 내가 본것은 매우 한정적이라 매일매일 정해진 물량을 처리해야 하는 물류센터의 사정을 잘 모르고 하는 말일 수 도 있다.

하지만 분명히 내가 본 대부분 쿠팡맨들은 물류와 관련해 좋은 의견들을 많이 가지고 있고 의욕도 충만한 젊은사람들 이었다. 하지만 그들의 그런 의지를 레버리지 삼기 보다는 외국인 임원을 고용해 아마존 식으로 물류센터를 운영한 것은 아닐까? ?다소 제한적인 의견이지만 물류센터 내에서 진정한 로켓을 발견할 수 없었던 것은 확실해 보인다.

쿠팡맨에 대한 과도한 선심성 보상 공약

사실 쿠팡맨 뿐만 아니라 다른 직원들에게도 해당되는 이야기지만 달변가인 김대표가 직원들에게 뿌려놓은 기대감의 씨앗이 열매를 맺지 못했기 때문에 이는 배신감이 되어 돌아온 것은 아닐까? 실제로 스탁옵션에 관한 처우는 실리콘 밸리 채용과 국내 채용의 비교에서도 볼 수 있듯이 많은 이들이 쿠팡을 사랑하면서도 떠나는 이유가 되었다. ?쿠팡맨의 경우에도 실제 그들의 삶은 김대표나 회사에서 이야기한 유토피아와는 차이가 날 수 밖에 없었고( 혁신 없는 쿠팡맨은 친절한 택배 기사에 지나지 않는다고 생각한다.) 이 때문에 그들이 일반 택배기사보다 나은 환경에 있다고 추정되는 상황에도 들고 일어날 수 밖에 없는 것이다.

정부나 사회의 지원 (그렇다 우리 사회의 잘못도 있다.)

만약 ?쿠팡정도의 회사가 미국에 존재했다면 시장에서 알아서 잘 키울 수 있었겠지만 한국의 경우에는 더 척박한 환경에서 스스로 살아남아야 한다. ?하지만 그 과정에서 정부와 사회의 도움은 없어도 될까? 그냥 방목형으로 보이지 않는 손이 ?우버나 넷플릭스같은 기업을 만들어내길 기다렸어야 하나?

사실 그런 지원은 둘째치고라도 AI가 일자리를 위협하는 상황에서 그 질은 제껴놓더라도 만명이 넘는 일자리를 만들어낸 쿠팡은 칭찬 받아야 마땅했다. 정부의 정책과 사회의 ?이런 기업들이 ?더 자리 잡을 수 있도록 적극 지지했어야 한다고 생각한다.

하지만 박근혜 정부의 편애는 최순실 측근에만 그쳤고 야망넘치는 기업가들과 그 직원들의 꿈에는 방관했을 뿐이다. 사회는 어떠한가? 소비자들은 쿠팡맨을 응원하면서도 정작 그 미소와 친절에는 돈을 내고 싶어하지 않는다. 정당한 서비스와 상품에 대해서 제값을 쳐주는 문화가 사회에 자리 잡아야 하는데, 아직까지 대부분의 국민들은 택배비가 어떻게 무료가 될 수 있는지에 대해서 깊게 생각하지 않으며 더 많은 물질적인 풍요를 원하며 근시안적으로 소비하고 있다. 실제로 그런 문화가 자리 잡지 않는 이상 질 좋은 일자리의 수는 줄어들 수 밖에 없다고 생각한다.

관련링크

http://www.etnews.com/20170523000161

http://www.consumerwide.com/news/articleView.html?idxno=14762

http://biz.chosun.com/site/data/html_dir/2017/06/21/2017062101266.html

HATEOAS가 이루고자 하는 이상과 현실의 차이가 존재한다. 개발과 의사결정 속도가 중요한 조직에서는 쓰지 않아도 좋다.

API 디자인을 시작하면서 뭔가 정말 제대로 REST 아키텍쳐를 만들고 싶어서 마틴 파울러가 쓴 REST성숙도 모델도 읽어보고 여러가지 자료 조사를해 보았다.

하나의 엔드포인트를 여러개의 리소스에 할당하기 보다 각 리소스를 그에 맞는 엔드포인트에 맵핑하고 API의 동작은 HTTP의 method를 동사로서 사용한다. 여기까지가 레벨2,대부분의 개발자들(백엔드,클라이언트모두 포함)이 이부분은 쉽게 이해하고 따라할 수 있지만 문제는 레벨 3부터 시작되었다.

하이퍼 미디어 컨트롤, 뭔가 멋진 단어들을 많이 모아 놓았지만 이 레벨은 HATEOAS가 적용되었냐 아니냐가 그 판단 기준이다.

REST API의 창시자인 로이필딩 (Roy Fielding)은 REST API는 반드시 하이퍼 미디어 드리븐이어야 하며 그렇지 않다면 그것은 REST가 아니라 RPC라고 주장한다. , 2008년의 글이지만 논문의 원저자이기 때문에 지금까지 미치는 파장이 적지 않은 것 같다.

HATEOAS의 장점

HATEOAS 를 적용하면 얻게 되는 장점이 무었일까, 당장 생각나는 것은 애플리케이션의 리소스가 상태머신(State Machine)으로서 해석될 수 있다는 것이다. 즉 상태머신이 가지는 장점을 API인터페이스에도 그대로 적용할 수 있다. 두번째는 API와 컨슈머의 결합이 느슨해진다는 점이다.

무슨 말이냐 하면 아래와 같은 응답이 있다고 가정하자. API응답을 봐도 상품 목록에서 이동할 수 있는 상태는 어떤것인지 짐작이 간다. 상품목록 API응답에서는 detail 과 order로 이동할 수 있다. 개발자의 입장에서도 API를 보면 다음 상태가 어떻게 변화할 수 있는지 예측이 가능하다.

두번째 느슨한 결합은, API 컨슈머 쪽에서 detail을 응답 받기위한 URL을 저장하지 않고 href 값을 얻어와 호출한다는 뜻이다. 그렇게 구현함으로서 컨슈머는 API 엔드포인트의 변화로부터 자유로워진다. (장점을 이렇게 적다보니 미래의 API에 적용하고 싶은 맘이 든다 위험하다. 하지만 이 포스트는 분명히 적용하지 않아도 좋다는 주장을 하기위함이다.)

</pre>
<pre>{
  "links": [
    {
      "rel": "detail",
      "href": "http://server/api/items/12345"
    },
    {
      "rel": "order",
      "method": "post",
      "href": "http://server/api/items/order"
    }
  ]
}</pre>
<pre>

하지만 그럼에도 불구하고 REST API의 사용 주체가 빠른 속도의 의사결정과 개발을 중시하는 웹 서비스 업체라면, 너무 아카데미컬한 주제에 파뭍혀 실제 문제를 해결하는데 집중하지 못한다는 비난을 들을 수도 있을 것 같다. 오히려 이런 문제들 때문에 GraphQL같은 대안들이 나오게 된것이 아닐까?

물론 이런 REST가 추구하는 이상은 소프트웨어 엔지니어로서 성취하고 싶은 것이나, 회사원으로서 서비스의 전개 속도도 빠트릴 수 없는 부분이다. 그래서 슬며서 이슈를 던져보고 대부분 사람들이 쉽게 이해하지 못한다면 HATEOAS는 적용하지 않는게 좋겠다는 결론을 얻었다.

Restful API를 문서화를 도와주는 swagger API같은 도구들도 오히려 HATEOAS의 도입을 저하시키는 이유가 된다. 개발자가 손쉽게 전체 API엔드 포인트를 파악할 수 있으니 어떤 가정을 가지고 API 를 탐색하게 되고 이것은 강한 결합으로 이루어진다. (예를들어 swagger 페이지를 보고 상품 목록은 GET /items, 상품 상세 정보는 GET /items/1 과 같은 유추가 가능하다. HATEOAS 개념을 이용하면 상품 목록 리소스에서 전환 가능한 변화들이 link에 나타나야 한다. ).

물론 swagger를 사용해도 HATEOAS정보인 link 를 참조하는 것이 가능하나, link 사용을 클라이언트에게 강조하는 것이 원천적으로 불가능하기 때문에, API 컨슈머가 특정 가정을 가지고 (= 결합) API를 사용해도 막을 방법이 없다.

로이필딩이 인정하지 않는 REST API 면 어떠한가, 실제 HATEOAS나 REST성숙도 레벨 3까지에 대한 이해가 존재하지 않는 조직이라면 원작자의 의도를 무시하고 RPC스타일로 사용할것이 확실하다.

쿠팡맨 로켓배송은 왜 문제의 중심에 놓이게 되었나?