[코드스테이츠 PMB 7기] 애자일(Agile)방식으로 개선해 보는 네이버쇼핑 라이브 1주 스프린트

 

생각을 시작하며...

  애자일(Agile)을 공부하면 공부할수록 매력적인 방식이란 생각이 든다. 애자일 하게 서비스를 개발한다면 빠르게 변화하는 시장과 고객을 보고 유연하게 대처할 수도 있다는 점과 정말 협업에 특화된 효율적인 방식이라는 생각이 든다. 하지만 애자일 조차도 하나의 방법론이기 때문에 어쩔 수 없이 장, 단점이 모두 존재한다고 할 수 있다.

  결국 절대적인 방법론은 없으며, 서비스에 맞게 취사선택하는 것이 좋은 것 같다. 다만 PMF(Product/Market Fit)를 찾지 못한 상태에서 빠르고 유연한 개발을 해야 한다면 애자일을, 그리고 PMF를 찾은 후에는 안정적인 모델의 관리, 변경, 기능 추가 등은 워터폴로 하는 것이 좋아 보인다. 

  몇 년 후에는 개발의 기술이 발전하고 데이터의 분석 능력에 따라서 새로운 방식이 나오거나 애자일과 워터폴의 장점만을 결합한 방법론이 나오지 않을까 생각이 된다.

많이들 하는 말처럼... '우리는 언제나 그렇듯 해답을 찾을 것이다.'

  오늘은 애자일 하게 네이버 쇼핑 라이브를 개선하는 스프린트를 계획해 보도록 하자.

---

(1) 고객의 문제

  요즘 새로운 쇼핑 플랫폼으로 라이브 커머스가 대두되고 있지만, 많은 회사들이 이 서비스를 확장시키기 위해서 힘든 노력을 하고 있다고 한다. (아래의 참고자료 1) 물론 이런 어려움의 가장 큰 문제는 라이브 커머스를 통해 판매하는 양질의 상품과, 방송을 진행하는 쇼 호스트의 양질에 있겠지만 UX 측면에서도 이 문제를 해결하기 위한 솔루션을 어느 정도 생각해 보아야 할 필요가 있다. 예를 들어 쇼호스트도 좋고, 판매하는 물건도 좋지만 UI/UX가 좋지 않다면 다 잡은 물고기를 내 던져 버리는 형국이 되어버릴 수 있기 때문이다.

  우선 네이버 라이브 쇼핑이 해결하고 싶은 고객의 문제를 살펴보면 아래와 같이 정의할 수 있을 것이다.

오프라인으로 물건을 구매하듯 온라인 상에서도 어떤 물건인지 판매자에게 직접 물어 정보를 알아낸 후에
구매하고 싶다.

  이전에 포스팅한 글에서 라이브 커머스라는 서비스를 페르소나 설정을 통해 고객의 문제, 혹은 서비스의 개선점을 살펴본 적이 있었기 때문에 이 글로 고객 문제의 정의를 대체한다. (이커머스의 공룡 라이브 커머스)

[코드스테이츠 PMB 7기] 이커머스의 진화판, 라이브커머스의 타겟 페르소나(Persona) 추적

 

(2) 유저 스토리

  이제는 이 서비스를 이용하는 고객의 입장에서 하나의 서비스 Task를 정해서 유저 스토리를 만들어 보도록 하자. 라이브쇼를 통한 판매와 구매로 라이브쇼의 플레이라는 하나의 Task로 국한하도록 한다. 이 유저 스토리를 작성하는 이유는 표준 유저 스토리를 작성해 전체적인 그림을 그리기 위해서 이다. 

  특히, 기능별, 혹은 이벤트별로 유저 스토리를 만들게 되면 카테고리화가 되지 않고 도식화가 되지 않아 백로그를 관리할 때 어려움을 겪게 되곤 한다. 이런 문제를 방지하기 위해서 페르소나와 전체적인 유저 스토리를 플로우에 맞춰 문제점을 하나하나 풀어가는 것이 좋다고 생각을 한다.

Epic	As a user	I want to	So that I can	User Stories
Epic 1 라이브쇼 (구매자)	라이브쇼를 사용하는 구매자로	라이브 쇼 방송을 통해 쉽고 편한 쇼핑을 하고 싶다.	그래서 좋은 상품을 값싼 가격에 살 수 있을 것이다.	User Story1: 쉬운 쇼핑	라이브쇼를 사용하는 구매자로서 라이브쇼에서 판매하는 상품을 간단한 방법으로 사고 싶다.
				User Story2: 라이브	라이브쇼를 사용하는 구매자로서 라이브쇼에서 진행하는 판매자에게 궁금한점을 바로 물어 대답을 듣고 고려하여 구매를 하고 싶다.
Epic 2 라이브쇼 (판매자)	라이브쇼를 사용하는 판매자로	라이브 쇼 방송을 통해 고객과의 소통을 하고 제품에 대한 고객의 간접경험을 제공하고 싶다.	그래서 상품을 새로운 판매 루트를 개척하고 수익을 낼 수 있을 것이다.	User Story1: 소통	라이브쇼를 진행하는 판매자로서 라이브쇼에서 고객들과의 대화를 원활히 하여, 상품의 정보를 효과적으로 전달하고 고객의 의문점을 해소하여 구매를 촉진하고 싶다.
				User Story2: 간접경험	라이브쇼를 진행하는 판매자로서 라이브쇼에서 고객들에게 제품을 실제로 경험하는 것 처럼 보여주고 상품의 실제 모습을 보여주면서 제품의 구매를 촉진하고 싶다.

 

(3) 유저 스토리에 따른 문제점에 따른 기능 개선

  이 유저 스토리와 함께 라이브쇼라는 Task를 보게 되면 약간의 문제점을 발견할 수 있다.

▶︎ 1) 구매 단계 개선

모바일에서 상품을 누를 시 PIP

  네이버 쇼핑 라이브의 경우 웹서비스와 모바일 서비스 모두 방송 진행 중 구매 단계에서 불편한 부분이 있다. 유저 플로우(User Flow)를 보면 사용자가 쇼핑 라이브를 보고 있는 중에 구매를 하기 위해서 상품을 누를 경우에 별도의 네이버 쇼핑 페이지가 열리게 된다. 모바일의 경우에는 PIP로 쇼핑 라이브 창이 바뀌고, 웹서비스 같은 경우에는 새로운 브라우저 탭에서 구매 페이지가 나오게 된다. 이 경우 구매자의 입장에서는 하나의 Depth가 더 생김으로 이탈이 생길 수 있는 우려가 있다. 특히, 이렇게 새로운 창에서 라이브 도중에만 적용할 수 있는 쿠폰을 적용하는데 또 별도의 시간이 걸려 가격에 매리트가 크게 있지 않는 이상 이 부분에서도 이탈이 일어날 수 있는 여지가 있다.

  이는 위에서 살펴본 '쉬운 쇼핑을 한다'는 유저 스토리로 봤을 때 사용자에게는 문제가 될 수 있는 부분이겠다.

  기능을 개선하기 위해서는 우선 쇼핑 라이브를 진행하는 동안에 구매를 하는 경우에 쇼핑 라이브 페이지에서 바로 장바구니 혹은 구매가 이루어지도록 먼저 구현해야 할 것이다. 이는 A/B 테스트를 통해 구매전환율(CVR)의 개선이 나타나는지를 파악하고 본격적인 도입을 결정하는 것이 좋을 듯하다.

 

문제 1. 라이브 화면을 보면서 빠르고 간편하게 구매까지 다 하고 싶다!

	솔루션	기능
개요	쇼핑 라이브 중 간편 구매 구현	1. 쇼핑 라이브 화면에서 제품과 쿠폰이 적용되어 바로 장바구니로 연결 가능하게 구현 2. 쇼핑 라이브 화면에서 제품과 쿠폰이 적용되어 바로 구매 페이지로 연결 가능하게 구현 3. 쇼핑 라이브 화면에서 원클릭 구매 가능하게 구현 (네이버 페이로 할 경우, 일반 결제 설정)

 

▶︎ 2) 간접 경험 (쇼핑 라이브에서 판매자와의 소통) 개선

왼쪽 3개의 그림은 모바일에서 채팅, 오른쪽 2개는 웹에서 채팅

  간접 경험이라는 요소는 라이브 커머스의 핵심임과 동시에 구매 전환이 될 수 있는 중요한 요소일 것이다. 이러한 간접 경험은 쇼호스트가 제품을 직접 사용, 시연, 시식을 통해서 얻을 수도 있지만 구매자가 판매자에게 직접 의문점을 이야기하면서 얻을 수도 있다. 그렇기 때문에 소통 기능은 간접 경험의 큰 축을 담당하고 있어 문제가 있다면 라이브 커머스의 중요한 요소를 잃어버릴 수 있는 것이다.

  위에서 살펴본 유저 스토리에서는 간접 경험을 하기 위해서 쇼핑 라이브 방송 중에 제품에 대하여 판매자에게 물어보게 될 것이다. 하지만 이렇게 질문을 하는 단계가 불편하다면 오히려 간접 경험이라는 큰 장점 귀찮음으로 전락할 수 있고 이는 구매 전환에 좋지 않은 영향을 줄 수도 있다.

  채팅으로 소통을 하기 위한 유저 플로우를 보면 쇼핑 라이브 도중 사용자는 판매자, 혹은 쇼 호스트에게 질문을 하기 위해서 바로 글을 쓰는 것이 아닌 옆에 있는 말풍선 버튼을 눌러 채팅창을 활성화해야 한다. 일반 채팅의 경우 바로 채팅창에 써서 대화를 시작할 수 있지만, 상품에 대한 질문의 경우 채팅창 오른쪽 끝에 있는 질문 버튼을 누르고 대화를 해야 한다. (물론 몇몇 쇼핑 라이브를 통해 사용자들의 행동을 보면 보통은 질문을 사용하지 않고 일반 채팅으로 물어보는 경우가 많았다.)

  이렇게 불필요해 보이는 단계들이 소통을 저해할 가능성이 있기 때문에 위의 페르소나에서 '간접 경험'에도 영향을 미칠 수 있어 개선할 필요가 보인다.

  첫 번째 문제점과 마찬가지로 채팅 기능 역시 핵심 기능이기 때문에 A/B 테스트를 통해 채팅의 증강률, 클릭률, 구매 전환율을 고려해 보고 변경을 하는 것이 좋을 듯하다.

문제 2. 호스트에게 더 직관적으로 물어보고 답을 받고 싶다!

	솔루션	기능
개요	쇼핑 라이브 중 채팅 기능 개선	1. 쇼핑 라이브 진입 시 채팅창 바로 활성    - 웹 서비스: 채팅 입력 바 활성화   - 모바일 서비스: 채팅 바는 보여지지만 채팅바 터치시 자판 팝업 2. 일반 채팅, 제품에 대한 질문 버튼 앞쪽으로 이동

 

(4) 스프린트 플래닝

  본격적으로 스프린트를 준비해보자. 위에서 찾아본 문제점들을 모두 해결하기 위해 일주일이라는 시간이 너무 짧다. 그렇기 때문에 스프린트 팀 구성원들의 의견과 서비스의 목적에 맞게 하나의 문제를 결정해야 할 것이다. 우선은 일주일 동안 구매에 대한 문제를 해결한다고 가정을 해보자.

  앞서 설정한 유저 스토리를 바탕으로 조금 더 자세한 유저 스토리를 작성한다면 

  쇼핑 라이브를 실시간으로 보면서 구매를 하고 싶은 사람으로서
여러 단계를 거치지 않고 제품을 고르고 빠르게 구매하고 싶다.

▶︎ 스프린트 목표

쇼핑 라이브 도중 구매자의 구매 단계를 줄여서 구매를 활성화시킨다.

▶︎ 스프린트 목표를 위한 지표

- 핵심 지표: 구매 전환율(CVR), 구매 시 이탈률(Bounce Rate)

- 보조 지표: 상품 클릭률, 쇼핑 라이브 참여율, 쇼핑 라이브 참여 후 구매까지 걸리는 평균 시간,  쇼핑 라이브 이탈률(Exit Rate)

▶︎ 프로덕트 백로그 작성

우선 위에서 살펴본 3가지 기능들을 중심으로 백로그 작성을 해보도록 하자.

	솔루션
1	쇼핑 라이브 화면에서 제품의 종류와 수량을 결정하고 쿠폰이 적용되어 장바구니로 연결 가능하게 구현	제품의 수량과 종류를 선택할 수 있는 기능
		제품을 선택하여 장바구니로 연결하는 기능
2	쇼핑 라이브 화면에서 제품의 종류와 수량을 결정하고 쿠폰이 적용되어 구매 페이지로 연결 가능하게 구현	제품의 수량과 종류를 선택할 수 있는 기능
		쿠폰 다운로드 페이지에서 적용여부를 묻는 기능
		제품과 쿠폰적용을 하여 구매 페이지로 연결하는 기능
3	쇼핑 라이브 화면에서 원클릭 구매 가능하게 구현	개인 페이지에서 원클릭 구매 설정 기능 (카드, 현금구매, 계좌, 영수증 등)
		제품의 수량과 종류를 선택할 수 있는 기능
		쇼핑 라이브에서 원클릭 구매 기능

   이렇게 3개의 위계를 나누어서 백로그를 작성하는 이유는 결국 원클릭 구매를 가능하게 하는 것이 궁극적이 목표이지만 한 번의 스프린트로는 기능 구현이 어렵기 때문이다. 그렇기 때문에 3개의 솔루션의 공통적을 들어가는 제품의 수량과 종류를 선택할 수 있는 기능, 쿠폰 다운로드 페이지에서 적용 여부를 묻는 기능 정도는 Bare minimun으로 잡고 앞으로의 기능 개선에 도움을 줄 수 있어야 할 것이다.

  위에서 본 유저 스토리를 기본으로 각각의 개선할 기능을 기획하였지만 개발자, UX/UI 디자이너, 마케터, QA 엔지니어들의 생각과 리뷰를 들어보고 수정할 부분이 있다면 수정을 해야 할 것이다. 그렇기 때문에 직접적인 스프린트를 시작하기 전에 기획 리뷰를 통해 기획을 점검하는 부분이 필요할 것이다. 특히 네이버의 쇼핑 라이브의 특징이 모바일에 특화가 되어있는 만큼 한 화면에 모든 구매, 장바구니, 제품 설정을 넣기 어려울 것이다. 고객의 입장에서는 물론 이런 간편 구매 기능이 좋다고 생각을 할 수 있으나 개발자와 디자이너들에게는 이러한 제품 구현이 어려울 가능성이 크기 때문에 논의를 통해 좋은 방법을 찾아 나가야 할 것이다.

  개발의 순서는 1~3으로 가는 것으로 잡고 가장 궁극적인 목표를 원클릭 기능으로 잡아 서비스가 발전하게 하는 것이 좋아 보인다. 

다음은 Jira에서 스프린트를 계획해 보았다.

https://madforge50.atlassian.net/jira/software/projects/LLFQ/boards/1

Agile Board - Jira

  참여자의 할당의 경우 프로덕트 팀의 구성원에 따라서 달라지는데 Jira의 경우 가상으로 만들었기 때문에 할당을 할 수가 없었다. 대부분의 작업은 시작이 UI의 디자인부터 시작을 해서 UI 디자이너의 시안을 본 후 프런트엔드 개발자들이 시각적으로 보이는 작업을 하게 될 것이다. 그리고 구매라는 기능이 들어가 있기 때문에 백엔드 개발자들에게도 구매 작업을 붙이는 작업을 하게 될 것이다.

  스프린트는 플래닝은 일주일간 진행이 되기 때문에 우선 네이버 쇼핑 라이브 개선이라는 프로젝트 안에 구매 간편화라는 에픽을 넣고 백로그를 작성하게 된다. 그리고 개선 사항을 개발 후 code review, QA를 거쳐 배포 단계에서 A/B test를 하게 될 것이다.

---

생각을 마무리하며...

  사실 이 스프린트를 계획하면서 좀 막막하다는 생각이 들었다. 왜냐하면 이 제품에 대하여 히스토리가 정확히 있는 것이 아니며, 가상의 상황을 설정해서 '맨땅에 헤딩하듯(?)' 계획을 만들어 봐야 했기 때문이다. 또한 이 작업을 아무런 정보와 사람들의 의견이 없이 혼자 하니 뽑아낸 인사이트가 확실히 여려 명이 했을 때 보다 양과 질적인 면에서 모두 부족하다는 생각이 들었다.

  하지만 진짜로 스프린트를 하는 것보다는 시간적인 측면이나 고려해야 할 측면이 적어서 쉽다고 생각이 들지도 모른다. 정말 그렇기 때문에 어서 진짜로 일을 해서 스프린트와 스크럼을 경험해 보고 PM으로서의 직무를 해보고 싶다는 생각이 들었다. 특히 협업이라는 측면에서 개인적으로는 여러 가지 상황을 고려해서 최적의 결과물을 만드는 것을 좋아하기 때문에 더욱 기대되는 것 같다.

---

참고자료:

1. 네,카,배 빼면 전멸... 쿠팡도 못 살리는 라이브 커머스 딜레마

네·카·배 빼면 전멸...쿠팡도 못살리는 라이브커머스 딜레마

 

제가 이해하고 있는 영어를 포스팅으로 남깁니다.
만일 오타나 오역, 영어 표현 실수 등을 댓글로 남겨주세요.
감사합니다