이커머스 도메인 지식이 왜 필요해요?
이 바닥은 '잘 아는 놈'이 이깁니다.
잘 아는 놈이 이긴다 : 이커머스 도메인 지식이 왜 필요해?
“다양한 서비스를 해보는 게 기획자에게 더 좋은 거 아니에요?”
“어떤 서비스를 가도 서비스기획이라는 게 똑같은게 아니에요?”
처음 취업을 준비할 때, ‘UX’라는 단어를 쫓아서 어디라도 취직이 하고 싶었다. 고객 경험을 설계하고 온라인 서비스를 만드는 일이 너무 멋있었다. 그래서 어떤 분야의 회사에서 일하는 게 좋을지에 대해서는 딱히 생각을 해보지 않았었다. 포털도 좋다고 생각했고, 온라인 쇼핑몰도 좋다고 생각했고, 사실 어디를 가도 하는 일에는 차이가 없을 거라고 생각했다.
지금도 그렇지만 온라인에는 엄청난 이력의 사람들이 넘쳐난다. 이력란에 열댓 개의 대기업 프로젝트에 참여했다는 XX에이전시의 대표인 기획자들, 그리고 N포털회사에서 일하다가 내일은 XX쇼핑몰에서 일하는 PO도 있다. 처음 그런 사람들을 보면서, 나 역시 그런 사람이 되어야 한다고 생각했다. ‘난 창의력이 높으니까 정말 잘 할 거야’ 라고 생각했다.
착각이었다.
“이커머스는 고려해야할 케이스가 왜 이렇게 많아요?”
온갖 기업명으로 가득한 이력을 보고 선정한 에이전시 기획자가 정책설명을 한참 듣더니, 한숨을 쉬었다.
“이커머스가 원래 복잡도가 높아요. 특히 이런 종합몰은 사업유형이 많아서 배송유형도 많고, 상품종류도 많고 돈이 관련된 거라서 법적으로 고려해야할 것도 많고요. 그치만 이런거 전부 다 고려해야해요”
정말 큰 프로젝트를 할 때는 내부의 수십명의 기획자만으로도 소화가 되지 않을 때가 있다. 그럴 때 에이전시를 통해서 단기 프로젝트를 진행할 외주 기획자를 뽑는데, 매번 뽑는 과정에서도 함께 일하는 과정에서도 전혀 수월하지가 않았다. 이유는 복잡도 때문이었다. 이력에 이커머스 경험이 없는 사람을 선뜻 뽑게 되지 않았고, 이커머스 경험이 있는 사람을 뽑아도 배송이나 클레임, 결제와 같은 복잡한 프로세스가 있는 부분은 생각보다 경력자를 찾기가 쉽지 않았다. 이커머스는 결국 인하우스 기획자를 계속 늘리는 이유도 알아야 할 것이 너무 많기 때문이다. 그런데 같은 이유로 신입을 채용하지 못한다. 당장 전력이 되기엔 외주기획자보다도 모르는 것이 너무 많기 때문이다.
이커머스라는 도메인이 기획자에게는 어렵다. ‘이게 뭐가 어려워?’라고 느껴진다면 사업적으로 이익이 될 만큼 복잡한 이커머스를 직접 구축해보지 않았기 때문이다. 직접 맨땅에서 구축하려면 정말 어렵고 복잡하다. 이 어려움이 물론 하루아침에 만들어진 것은 아니다. 처음 우리 나라에 이커머스가 만들어진 96년부터 지금까지 조금씩 그리고 천천히 쌓여왔다. 새로운 서비스가 나와서 시장을 엎치락 뒤치락하면서 생겨난 서비스들과 누군가가 대형사고를 치면서 생겨난 법적인 규제들, 그리고 더 잘해보고자 만들어놓은 편의 서비스들이 서로 얽히고 얽혀서 복잡해져왔다. 겉으로 보기에는 점점 더 편리하고 단순하게 보이도록 만들어져 왔지만, 소위 ‘뒷단’이라고 불리는 시스템의 정책과 설계된 시스템의 복잡도는 상상 초월이다.
10년차 기획자인 내가 똑똑해서 이런 내용들을 다 안다고 자랑하려는 것이 아니다. 내가 처음 입사하던 시절에 나도 하나도 몰랐다. 순진하게 고객의 입장에서 중요한 서비스가 눈에 잘 띄도록 설계해서 주문까지 구매결정을 잘 내려줄 수 있으면 된다고 생각했다. 고객의 입장을 생각하는 것은 당연하고도 당연하다. 하지만 그 마음만으로는 개선은 할 수 있어도 구축할 수가 없다. 이 차가운 진실을 깨닫은 것은, 우연찮게 이커머스 구축 프로젝트로 휩쓸려가게 되면서부터였다.
이 바닥은 ‘잘 아는 놈’이 이긴다.
이 프로젝트는 회사가 쇼핑몰을 신규로 구축해주는 프로젝트였다. 그 회사는 오랜 기간 오프라인에서 판매하던 유통계열사로, 온라인 쇼핑몰에 대해서 구축역량이 없었고 우리 회사는 계열사로서 이를 대신 구축에 참여하여 조언을 해주는 역할이었다. 10개월된 꼬꼬마 사원이었던 나는 원래 낄 수 없는 대형 프로젝트였다. 막판에 일정을 맞추기에 이 프로젝트가 난항을 겪고 있었고 사내에서 에이스 기획자들이 수습을 하러 파견됐다. 난 그 때 패키지처럼 그 프로젝트에 딸려갔다.
선배들은 날 두고 골치아파하고 있었다. 당시의 나는 입사하고 10개월간 꽤 일을 해봤다고 생각했는데, 사실 구축 프로젝트를 하려는 선배들 눈에는 짐덩이였다. 날 어디에 쓸 수 있을지 고심했고, 결국 고양이 손이라도 빌려야 하는 시기 아니냐며 서브 기획자로서 배송과 클레임을 담당하는 대리님의 후임으로 들어갔다. 내 위의 대리님은 ‘서비스 정책서’를 던져주며, 이 정책이 구현된 이커머스 시스템을 새로 개발해야하고, 나의 역할은 새로 만들어진 서비스가 이 정책을 제대로 반영하고 있는지 확인하고 뭔가 정책과 맞지 않는 부분은 찾아내서 고쳐야 한다고 했다. 서비스 정책서는 십여개의 문서로 되어 있었고, 각 서비스에서 다루는 어휘 정의부터 어떤 기준으로 처리되는지 쓰여있었다. 나는 그 문장의 한마디도 이해하지 못했다.
대리님의 말은 사실 이런 내용이었다. 예를 들어, 서비스정책서에 ‘취소는 판매자가 물건을 발송한 시점부터는 불가능하다.’라는 문장이 있다고 해보자. 그러면 취소를 처리할 수 있는 마이페이지의 주문조회에서 ‘취소’에 대한 처리의 정책이 된다. 즉, 판매자가 발송처리를 한 시점을 나타나는 주문상태값인 ‘발송완료’가 되었으면 취소가 불가능하기 때문에 버튼이 나타나지 않거나, 버튼을 눌렀을 때 ‘취소가 불가능합니다’라는 메시지가 나와야 한다는 뜻이다. 그리고 테스트할 때나 화면별 개발 로직이 정리된 문서에 이렇게 제대로 반영되지 않았다면 이것이 오류이거나 만약에 제대로 정의되지 않았다면 개발자와 상의해서 이 정책대로 시스템이 작동되도록 정의를 해나가야 한다는 것이었다.
그리고 이런 문장은 십여개의 문서안에 수천개의 문장으로 쌓여있었다. 그 문장들이 이해가 가지 않아서 몇 날 몇 일을 앉아서 읽고 또 읽었다. 머리 속에는 수십개의 ‘왜?’만 떠다녔다. 이유를 모른 채 바라본 정책들은 모두가 하나같이 불편하고, 또 이해가 되지 않았다.
“반품비는 그냥 다 무료 처리해주면 좋은 거 아닌가?”
“왜 반품접수한 후에 철회를 못하게 하는 거지? 자유롭게 해주면 안되나?”
이런 생각들만 가득했다. 나는 고객들에게 편리하고 좋은 서비스를 만드는 일을 하고 싶은데, 이런 재미없는 정책들이나 보고 있어야 하는 것인지 억울했다.
어영부영 쇼핑몰 오픈이 2개월 앞으로 다가왔고 전면적인 테스트 시기가 되었다. 나는 정책에 적힌 대로 시스템을 테스트하고 있었다. 뭔가 정책에 맞지 않는 항목들을 발견하고 오류신고 게시판에 오류로 등록을 했다. 개발자들 모인 곳에서 갑자기 웃음소리가 들려왔다. 이상한 기분이 들어서 내 결함 신고 항목이 ‘반려’가 되어져 있고, 개발자 의견에 ‘I don’t think so’라고 적혀 있었다. 답변이 기가 찼다. 씩씩대며 오류항목에 대한 정책을 들고 개발자를 찾아갔다.
“저, 이거 반려하신 개발자분 만나러 왔는데요.”
가장 앞좌석에 앉아 키득대던 개발자가 나를 아래위로 훑어봤다. 그러더니 이렇게 소리쳤다.
“야, XX야, 아가씨가 너 찾아왔다.”
이윽고 엄청 불량한 젊은 남자가 헤드폰을 벗으며 다가왔다. 나는 분노가 치밀었지만 꾹 눌러담으며 왜 나의 오류신고에 반려를 친 것인지 여기 쓰여있는 정책과 맞지 않다고 따지듯 말했다. 그런데 그 남자가 물었다.
“난 그 정책이 왜 그렇게 정해진 것인지 이해를 못하겠어요. 불편하지 않아요?”
말문이 막혔다. 왜냐면 나도 사실 나도 그 정책이 불편하다고 생각했기 때문이었다. 더 정확히 말하면 불편함에도 불구하도 왜 정책이 그렇게 세워졌는지에 대해서 나는 몰랐다. 결국 확인해보겠다며 뒤돌아섰고, 내 위의 대리님에게 도움을 청했다. 내 위의 대리님은 내 말을 듣고는 함께 와서 개발자에게 물류의 흐름과 물류센터의 업무방식, 그리고 법적인 제약사항들을 설명했다. 개발자는 고개를 끄덕였고, 다음날 코드는 수정되어 서비스에 정책대로 반영되었다.
이 이야기를 들으면 사람들은 그 개발자의 태도에 분노한다. 어린 여자 기획자를 하대하고 예의 없는 태도에 화를 낸다. 물론 나 역시 분해서 그 날 퇴근길에 지하철을 바로 못 타고 옆건물인 백화점 화장실에서 엉엉 소리 내어 울었다. 그런데 내가 열받는 것은 그 남자의 태도만은 아니었다. 나처럼 이커머스를 ‘잘 모르는 사람’이 무시받을 수밖에 없다는 사실이 나를 울게 만들었다.
그 날 ‘이커머스 판은 결국 잘 아는 놈이 이긴다’ 라는 명제를 가슴에 새겼다. 무시당하지 않으려면 그 어떤 협업자보다도 내가 일하는 이커머스의 구조와 고객, 실제 업무자들의 일하는 프로세스와 목표 등을 잘 알아야한다는 것을 깨달았다. 그게 바로 이커머스 도메인 지식이다.
현장을 알아야 이커머스 도메인을 알게 된다.
그 때부터 난 ‘save 모드’로 전환됐다. 무조건 닥치는 대로 머리 속에 집어넣었다. 정책서를 한문장씩 읽어가며 요구사항을 낸 현업 영업MD와 마케터, 법무팀, 재경팀에게 틈나는 대로 이유를 묻기 시작했다. 팀 내의 선배님들과 개발 관리를 해주시는 모든 개발PL들에게도 묻고 또 물었다. 알 수 있는 방법은 질문밖에 없었다.
테스트 막바지에는 개발자와 기획자 몇 명만 골방에 모여서 테스트를 했다. 상품을 등록하고, 주문을 해보고, 취소/교환/반품을 단계별로 해보면서 단계마다 데이터가 정상적으로 저장되었는지 체크했다. UI적으로 잘 움직여도 데이터가 제대로 들어가지 않는 오류도 있었고, 정책에서 미처 정의하지 못해서 오프라인의 실물 이동과 맞지 않아 생기는 문제도 있었다. 온라인 시스템은 눈에 보이는 것보다 보이지 않는 것이 훨씬 많았다.
이윽고 밤을 새워가며 오픈날짜에 맞춰 오픈을 하게 됐고. 나는 클레임의 서브 기획자였기 때문에, 고객센터에서 근무하는 상담사분의 오류신고 창구가 되었다. 그 분은 이커머스 업계에서 고객센터 근무만 십여년을 한 베테랑이었다. 그 분에게 실제 고객들이 원하는 클레임 처리 요청과 업무상 발행하는 여러가지 케이스를 많이 들을 수 있었다. 물건이 발송됐지만 그냥 안받고 반품하고 싶어하는 사람부터 교환을 접수했는데 판매자가 교환할 상품이 없다고 말해서 반품으로 바꿔야하는 경우 등등 단순하게 생각했던 커머스의 실제는 굉장히 복잡했고 돈이 얽혀 있어 예민한 문제가 많았다. 이런 것들이 모두 처리될 수 있는 시스템인지 확인하고 또 수정했다.
멋진 서비스 화면에 대한 니즈보다 알고 싶은 것들이 더더욱 많아졌고, 또 알게 된 것이 많아지기 시작하면서 ‘이커머스’라는 것만 공부해도 끝이 없다는 생각을 갖게 되었다. 내 목표는 자연히 여러가지 서비스를 많이 만들어보는 것에서 ‘이커머스를 잘 알고 똑바로 기획하는 기획자가 되는 것’이 되어 있었다.
흔히 서비스기획자의 업무를 설명할 때, 3가지를 이야기한다. IT, 비즈니스, UX다. 자사의 비즈니스가 작동하는 과정에서 고객들의 편의성과 목적을 해소할 수 있도록, IT적으로 구현가능한 서비스 프로덕트를 만드는 것이라고 설명한다. 이 바닥에서 ‘비즈니스’라는 것은 이커머스에 대한 도메인 지식 그 자체였다. 요즘 PO(Product owner)나 PM(Product manager)와 비교하며 서비스기획자의 일과 차이를 주장하는 글도 많다. 그런데 PO로 일을 하든, 서비스기획자로 일을 하든 이커머스 도메인 지식은 고객의 행동데이터나 지금 눈에 보이는 서비스나 ‘정책서’만 본다고 채워지는 것은 아니다. 어떤 타이틀을 하든 간에 비즈니스를 위한 모든 정책에 대한 이유는 모두 현장에 흩어져 있었고, 서비스 정책이란 그 수많은 제약조건 속에서 목표를 위해 선택된 것들의 조합이었다. 이런 것들을 모르면 제대로 작동하는 온라인 비즈니스를 만들어 낼 수 없다는 것이었다.
그렇게 10년간 나는 계속 배워왔다. 끝이 없다. 그래서 강력히 말할 수 있다. 어떤 새로운 방법론이 나타나든 현장을 제대로 모르면 기획할 수가 없다. 그리고 그 현장은 온오프라인에 시스템에 녹아져있다.
