1만시간의 고민이 가져다주는 만족에 대하여
기획을 시작하기 전에, 생각해 볼 것들
우당탕탕 긴 글 주의
VVIP가 될 정도로 성실히 이용중이던 마켓컬리에 지난해 말 이상할 것 없는 입점방식과 함께 매우 이상한 주문결제 프로세스가 도입되었다.
판매자배송 (말 그대로 다른 쇼핑몰처럼 마켓컬리의 새벽배송을 거치지 않고 택배를 통해 판매자가 배송하는 시스템) 이라는 것이었는데, 흔하디 흔한 쇼핑몰 입점 방식이었지만 컬리의 '새벽배송'에 매료되어 서비스를 초창기부터 애용하던 충성고객 입장에서는 적잖이 실망스러운 변화였던 것 같다. 가전제품 조차도 주문 다음날 아침 문 앞에 도착해있는 신박한 서비스를 너무나 사랑했던 나는 판매하는 제품은 다양해졌지만 신선식품을 제외한 대부분의 상품이 판매자상품으로 분류되었고, 그 판매 방식에 치명적인 결함(?)이 있었던 상황이 너무나 맘에 들지 않았다.
어떤 결함이었냐 하면_
한 판매자에게서 여러개의 제품을 구매하면 장바구니에 묶음 배송 상품으로 분류되어 담기는게 일반적이다. 배송비를 줄이고, 단일 포장으로 추적 해야하는 송장번호도 줄이고, 과대한 포장으로 자원을 낭비하는 일이나 언박싱하는 수고도 줄이기 위함이다. 헌데 컬리는 일단 판매자배송 시스템을 도입하기 전에 그에 맞는 주문결제 프로세스 개선을 미리 적용하지 않았다.
1. 소비자가 쇼핑하면서 장바구니에 담아놓으면
2. 알아서 판매유형별/판매자별로 분류되고
3. 소비자는 담긴 녀석들을 확인하고 한꺼번에 주문-결제하고
4. 컬리와 판매자는 판매유형별-판매자별로 알아서 묶음배송
이게 우리가 아는 일반적인 쇼핑 프로세스인데,
마켓컬리는 한 판매자가 판매하는 다섯 개 상품을 주문하려면 하나씩 바로주문-결제하는 걸 5번 반복해야 했다. 5개 상품을 결제도 따로, 포장도 따로, 배송과 조회도 따로 해야하는 상황이라는 것이다. 그나마 인내심을 발휘해 5번의 주문-결제 과정을 다 거쳤어도, 다섯박스의 상자로 나뉘어 배송되는 상품들 덕에 경비실 앞 수많은 택배박스들 중에서도 압도적인 숫자의 우리집 택배를 골라 들고 올라가면서 생각없는 쇼핑중독 여인네를 쳐다보는 눈길을 인내해야 하는 일이 반복되자 문득 화가 났다.
결국 올 초부터 애먼 고객센터에 항의하고 말았다.
답변은 "아직은 시스템 변경 계획이 없다. 담당 부서에 전달하겠다"
그래. 고객센터 담당자가 뭘 할 수 있겠어.
다시 앱스토어의 마켓컬리 어플 후기로 상세한 내용을 남겼다.
개발자의 기나긴 답변이 달렸다.
요약하자면 "고객님 불편하시겠지만, 개선을 준비중이니 좀 기다리시지요.."
몇년 전엔가 위시리스트 기능이 없던 마켓컬리에 몇달동안 건의를 해서 찜 기능이 마침내 만들어졌을 때는 뿌듯한 마음으로 자주 쓰는 200개의 찜상품을 넣어두었던 적이 있었지만, 이번엔 얘기가 달랐다.
주문과 결제, 배송 핵심 프로세스가 엉망인 상태의 컬리는 더 이상 내게 이용의 가치가 없었고, 컬리에서 눈에 띈 제품들을 네이버쇼핑이나 자사몰에서 더 좋은 가격에 주문하는 일이 잦아졌다. 컬리가 대부분이던 내 온라인 쇼핑 결제 내역은 어느새 네이버쇼핑이 차지하게 되었고 그러면서 오히려 훨씬 더 다양한 상품군을 만날 수 있었다.
그러다가 올 8월 갑자기 변화가 찾아왔다. 그래! 쫌 아주 많이 느렸던 것 뿐이었어! 너무 느리긴 했어!
서비스를 바꾸기 전에 시스템을 완벽히 준비했어야지! 순서가 잘못 되었어!
이렇게 잘 만들 수 있으면서! 컬리다운 깔끔한 UI와 함께 채워진 내 장바구니와 주문내역 페이지 덕분에
난 이제 기쁜 마음으로 컬리를 다시 이용할 수 있게 되었다.
(그나저나 저 오도로끼 복숭아. 너무 맛있어서 중독될 지경_)
그런데 이 상황을 돌이키다 보니 난 좀처럼 만족을 모르는 사람인 것 같다는 생각이 들었다.
내 일에 있어서도 만족의 기준은 워낙 높은 편이고, 그래서 오히려 그에 도달하지 못한 상태에서 무언가 타협점을 찾아야 하는 상황이면 ‘만족’을 쫓기보다는 ‘포기’로 상태값을 변경하고 가능한 빨리 머리속에서 지워버리는 경우가 많다. 하지만 그런 상황 조차도 설득과 논의를 통해 타협점을 찾으려는 노력을 충분히 거친 뒤여야만 하고, 그 후에도 도저히 타협점이 보이지 않을 때, 타인과의 관계나 일의 성사를 위해 내 상태값을 변경하는게 그나마 가장 빠르고 쉬운 길이라는 결론에 이르른 때 쯤 이어야만 한다. 당연히 다른 사람보다 결론에 도달하는 과정이 항상 조금은 더 치열하기 마련이었다. 그래도 다행히 그렇게 긴 논의와 고민을 거친 나의 과정들은 비교적 많은 사람들에게 이해와 만족을 주는 편이고, 그로 인한 뿌듯함이 내 부족한 만족을 채우는 또 다른 만족의 요소가 된지 오래다.
물론 부작용이 없는 것은 아니다.
가끔은 무엇 하나 허투루, 대충 넘기지 못하는 나의 그런 성향을 과하게 생각하는 사람들도 있었으니까.
언젠가 Project Manager 로서 일에 투입되었을 때 꼼꼼하고 철두철미한 성격의 나라는 PM 덕에 괴로워하는 기획자, 디자이너, 개발자를 보고 현타가 온 적 있다.
촉박한 일정에 부족한 인원으로 모 기업의 사내 업무시스템 구축을 위해 고군분투하고 있을 때였다. 당시 나는 다른 프로젝트를 진행중이었지만, 중급 기획자들이 설계한 업무 프로세스가 좀 불안불안했던 부서장이 설계 피드백이나 가이드만 지원해달라는 요청을 해왔기에 설계가 끝난 부분을 훑어보고 있었는데 이미 개발 완료되어 테스트 단계에 있던 고객 설문조사 작성 로직에서 이상한 부분이 감지되었다.
설문조사 문항을 작성할때 선택 답변에 대해 특정 문항으로의 skip 로직과 다음 문항으로 이어지는 로직만 설계되어 있고 설문종료/제출 케이스가 누락되었다.
그 경우는 해당 사항이 없는 사용자가 더 이상 설문을 진행하지 않고 제출하는 로직이었다.
이런 설문 문항이 있다면 어드민페이지에서는 어떻게 설정할 것인가?
각 문항별로 답변을 먼저 설정하고 연결 문항을 선택해줘야 한다. 그런데, 종료 선택지가 없다면...?물론 해당 로직으로도 설정할 방법이 없는건 아니었다. 모든 문항을 다 작성한 뒤 다시 해당 문항으로 돌아가 해당사항 없는 답변자가 선택할 답변에 대한 설정을 end page로 skip하도록 하면 된다. 하지만 그런 문항이 중간중간 몇 번 있다면 관리자의 휴먼에러가 발생할 가능성이 높아진다. 그 문항 작성 시 간단하게 처리할 수 있게하고 각 문항에 대해 정확한 통계 수치를 집계하려면 ’응답종료 설문제출‘ 선택 로직이 있어야 했다.
그런데 이 얘기를 기획자에게 몇 번을 설명해도 그게 왜 필요하냐는 반문과 이해할 수 없다는 눈빛만 돌아왔다. 고객의 요청에 그런 케이스는 존재하지 않는다는 것이었다. 나는 고객이 누락한 경우일 수 있으니 확인이 필요하다, 담당자에게 문의해라 말했고 기획자는 자기가 이해가 안 가는데 어떻게 문의할지 모르겠다고 했다. 고객의 눈높이에서 설명하려면 적절한 예시를 들면 되지 않냐고 했지만 자신없어했고 결국 타 프로젝트였지만 고객사 담당자에게 직접 전화를 걸어야 했다.
“해당 사항이 없는 고객을 제외하고 진행하는 설문은 진행하지 않나요?”
“왜요. 하기도 하죠. 브랜드에 대한 선호도나 사용후기, 인지도 등을 조사할때 많이 쓰이기 때문에 설문 대상이 아닌 사람이 선택하는 답변도 있을 수 있어요.”
나는 설명을 이어갔다.
“예를 들어, 흡연자인 답변자에게 선호 브랜드와 흡연습관에 대해 묻고자 하는 총 30문항의 설문에 비흡연자가 유입되어 '당신은 흡연자입니까'라는 질문을 마주했을 때 ‘비흡연자입니다’를 선택하면 더이상 담배에 대한 질문을 이어가면 안되잖아요?
근데 현재 설계된 로직으로는 ‘비흡연자입니다’를 선택하고도 잘못된 로직에 의해 ‘흡연기간은 어떻게 되시나요?’인 2번 설문으로 자연스럽게 넘어갑니다. 설문 종료를 안내하고 바로 end page로 이동하는 로직이 누락되었기 때문이죠.
물론 이 경우 종료를 설정하는 방법이 없지는 않아요.
작성하시는 분이 다음 30개의 문항에 대한 질문과 답변, 이동 로직까지 다 입력한 후 다시 처음으로 돌아와 1번문항의 ‘비흡연자입니다’를 선택했을때 제일 마지막 end page로 skip 하도록 설정을 해줘야 합니다. 그런 문항이 하나만 있어도 불편한데, 중간 중간 있다면 관리자가 그 문항을 기억했다가 모든 설문을 작성하고 마지막에 한번 더 end page 번호로 skip하는 문항들을 설정해줘야합니다.
비슷한 경우는 우리 브랜드 제품을 사용해본 사람에게 후기 등을 묻는 설문에서도 발생할거구요. 우리 브랜드를 들어봤냐, 우리 브랜드에서 어떤 제품을 출시했다는것도 들어봤냐 같은걸 물어보는 인지도 조사용 설문에서도요.
즉, 특정 그룹을 대상으로 한 설문인 경우, 그 그룹이 아닌 대상(그 브랜드 모른다, 브랜드 제품을 사용해본 적이 없다, 관심 없다, 브랜드는 아는데 거기서 그 제품이 나온건 첨 들어봤다 등의 답변을 선택할..) 을 설문에서 제외시키기고 설문작성 담당자의 휴먼 에러를 줄이면서 문항에 대해 정확한 통계데이터를 쌓기 위해 설문종료 로직이 필요할 것 같아요."
결국 고객의 요청과 PM의 결정을 거쳐 설계는 수정되었고 테스트를 접고 다시 개발 단계로 돌아가야 했다.
가장 큰 문제는 이후였다.
테스트로 야근이 몇 주 이어지던 차였어서 다들 좀 지쳐있었는지 해당 프로젝트의 개발자가 짜증섞인 얼굴로 물었다.
“이거 고객사 요구사항에 있던 거에요?”
“…저는 모르죠... 설계 검토만 요청받았으니까...”
답을 할 수 없었다. 난 PM도 아니었고 요건은 내게서 시작된 것이었기 때문이었다.
난 그저 전체 플로우를 논리적으로 되짚어보고, 어색하거나 맞지 않는 부분들을 내 스스로 채워넣은 후 고객에게 제안해 설계가 수정되었으니까.
“결국 고객사도, 우리 기획자도 모두 고려해보지 않은 상황이라는 뜻이잖아요? 그건 어쩌면 사용 빈도가 떨어질 수 있는 케이스라는 걸 의미할 수도 있잖아요? 책임님은 왜 긁어부스럼을 만드나요?”
나는 당황스러움을 무마하려 개발자에게 되물었다.
“긁어부스럼이라뇨. 그럼 하나만 물어볼께요. 개발자로서 이 로직이 없어도 된다고 생각해요?”
“없어도 괜찮아요. 관리자가 불편하거나 답변자가 좀 황당하긴 하겠지만… 기획자가 이렇게 기획했고 고객이 OK했고 그래서 우린 그대로 개발을 완료하고 테스트중이었단 말입니다. 구축이 완료되고 운영계약 하자마자 고도화 요건으로 빼면 되지 않습니까”
“그래요. 없어도 설정 방법이 없진 않다는 건 저도 알아요.... 근데 하필 부서장님이 제게 이 시점에 설계 검토를 요청하셨네요? 그게 맞아요? 오픈 시점에 이미 잘못된 걸 알고 있는 기능을 수정하지 않는게?“
“....무슨 뜻인지 알겠습니다.…”
더이상 논의를 거부하고 등돌리는 개발자를 보고 무언가 잘못되었다는 생각이 들었다.
물론 생각해보면 그 화면을 보고 나와 같은 성향의 사용자는 분명 전산담당자에게 고쳐달라고 요청을 하겠지만, 한편으로는 그냥 ‘어, 이게 뭐야...AC 불편하네?’하고 아무렇지도 않게 넘어갈 관리자가 담당한 업무였을 수도 있다.
나의 “옮음”은 주어진 일정 내에 어떻게든 완성된 버전을 구현해내고 KPI를 달성해야 하는 그에게 전혀 옳지 않았고, 그래서 나의 “완벽”은 그에게 너무나도 과한 설정값이었던 것이다.
그렇다면 나는 프로 불편러인가? 디테랄러인가?
내가 가이드해야 할 젊은 친구들에게 종종 하는 말이 있다.
"그래가지고는 토스 안 나와요."
간혹 "뭐...꼭 토스처럼 해야하나요?"라고 도발하는 친구들도 있다.
그러면 나는 "헐, 그게 그런 의미가 아니잖아요!" 라고 웃어넘기긴 하지만 솔직히 말해 그런 리액션에 좀 짜증을 느끼는 것 같다.
늘 문제의식을 가지고, 좀 더 편하고 명쾌하고 직관적인 방향이 없는지 치열하게 고민해보라는 취지이지 않는가? 토스가 완벽하니 다 따라해야 한다는 뜻이 아니다. 요즘 토스 좀 짜증나기도 하니까. 그렇지만 토스가 처음 시장에 등장했을때 업계에 줬던 충격만큼은 아직도 분명히 기억한다.
무릎을 탁! 치게 만드는 개선도 결국은 작은 불편함을 느끼는데서 시작되고, 혁신은 그런 작은 개선에의 욕구들이 모여 폭발한 니즈가 가져다주는 결실이라 생각한다. 지금 그리고 있는 것에 중대한 허점이 있다 생각된다면, 왜 그 멀리서 다시 한 번 다른 길이 있는지 찾아보려는 노력을 하지 않느냐는 의미이다.
물론 아무리 고민을 해도 그럴싸한 답이 나오지 않을 수 있다. 생각할 수록 점점 더 디테일에 갇혀 집착하게 되고 큰 그림을 보지 못하게 될 수도 있다. 하지만 그렇더라도 반복하고, 범위를 넓히고, 리프레쉬를 하다보면 간혹 새롭고 올바른 길이 눈 앞에 나타나곤 한다. 1만시간의 법칙이라는게 있다잖은가?
작은 디테일 하나하나마다, 모든 업무 플로우마다 1만 시간을 들여 고민할 필요는 없지만, 어떤 부분, 중요한 고비마다에는 1만 시간 그 이상의 고민과 노력이 필요하다고 생각한다. 그 때 비로소 새롭고 혜자로워 보이는 토스가 모습을 드러낸다. 디자인, 신기술? 아니 적어도 서비스를 제공하는 플랫폼이라면 “사용자와 관리자의 경험과 효율을 위한 고민”에 가장 많은 시간을 들여야 가장 좋은 결과를 만들 수 있을 것이다.
