김영감의 영감노트

[PMB 8기] 초기 당근마켓의 소비자들은 어떤 사람들이었을까?

기획자킴제이 — Thu, 30 Dec 2021 17:11:11 +0900

당근마켓 성장세

당근마켓은 올해 여름 1800억 투자를 유치하여 유니콘 반열에 올랐다. 빠른 성장의 결과로 최근 비즈프로필 서비스의 누적 이용자 수도 급격하게 상승하고 있다. (비즈 프로필은 동네 가게의 프로필로 지역 상점의 다양한 정보를 받아볼 수 있는 프로필이다.) 당근마켓에 따르면 올해 2월 비즈프로필 서비스 개시 이후 최근까지 이용자의 이용 횟수는 총 2억 건, 이용자 수는 1,300만에 달한다고 한다. 말 그대로 하이퍼로컬 슈퍼앱으로 진화 중인 당근마켓 초기에는 어떤 모습이었을까?

판교마켓에서 당신 근처의 중고마켓으로

당신의 근처에서 파는 중고마켓이라는 의미를 가지고 있는 당근마켓은 2015년 11월 시작한 서비스다. 카카오에 재직 중이던 김용현 대표는 처음엔 카카오 내에서 직원끼리 서로 필요한 물건을 사고파는 것을 보고 처음 사업 아이디어를 생각했다고 한다.

“서로 잘 아는 직장 내 직원끼리 서로 필요한 물건을 사고파니까 택배 포장도 필요 없이
가격이나 물건에 대한 신뢰는 물론 거래 예의까지 저절로 갖추게 되는 점이 좋았습니다."
- 김용현 대표

처음엔 직장인 앱인 '블라인드’처럼 판교 테크노밸리 회사원들만 쓰던 서비스였다. 판교 주변 기업 이메일로 가입을 하고 주변 거래만 진행하는 형식이었던 것이다. 이러한 방식은 중고거래의 신뢰의 문제를 적합하게 해결해냈고, 그에 따라 빠른 성장을 할 수 있다.

입소문이 나기 시작하면서 판교 주민들로부터 ‘우리도 쓰게 해 달라’는 문의가 많아졌다고 한다. 아마 당시의 김용현 대표는 고민이 많았을 것으로 보인다. 새로운 타겟을 설정하고 확장 전략을 만들어야 하기 때문이다.

만약 나라면 어떻게 했을까? PM을 준비하는 나로서는 재미있는 주제로 보인다. 그래서 오늘의 글에서는 당시의 당근마켓의 상황을 가정하고 타겟 고객과 확장 전략을 고민해보려고 한다.

타겟 고객

김용현 대표의 동아일보 인터뷰에 따르면 초기 서비스 확장을 요청했던 것은 판교장터를 이용하는 판교 직장인들의 와이프분들이었다. 이들이 서비스 확장을 요청했던 이유는 무엇일까?

첫 번째로는 판교장터에서 신뢰할 수 있는 거래가 가능했기 때문이다.

판교장터의 기업 이메일 기반 가입은 중고 거래의 고질적인 신뢰의 문제를 효과적으로 해결하고 있었기에 서비스를 써 보고 싶은 큰 요인을 만들었을 것이다. 게다가 근처 동네에서 쉽게 마주칠 수 있는 사람들에 한해 거래가 이루어진다는 점 또한 신뢰를 높이는 데 한몫을 했다.

두 번째로는 판매가 쉽다는 것이다.

회사 내에서 판매를 하는 것이기에 근처 동네에서 사는 사람들이 쉽게 거래를 할 수 있다. 택배거래, 포장과 같은 귀찮음이 거의 없다. 우리 가족은 중고거래를 잘 안 하는데 그 이유에 대해서 미니 인터뷰를 진행해보니, 상품을 올리고 포장하고 택배로 보내는 일이 귀찮아서였다. 생각보다 판매 방식의 불편함이 큰 진입장벽을 만든다는 점을 확인할 수 있었다.

신뢰와 판매의 문제를 해결하기 위해 판교 직장인들의 와이프분들이 선택한 대안재는 무엇이었을까? 답은 맘카페였다. 동탄, 성남, 판교 등 지역을 기반으로 다양한 정보의 교환과 중고 판매가 일어나는 유일한 수단이었기 때문이다.

이러한 내용을 종합하면 3040이면서 중고거래 시 신뢰와 판매의 불편함을 해결하고 싶어 주로 맘 카페를 활용하는 주부를 타겟 고객으로 볼 수 있다.

대표 페르소나

이름: 김 XX(여)
나이: 31
직업: 전업주무 (육아 중)

상황 & 배경
최근 육아에 전념하기 위해 다니던 직장을 그만두었다.
맞벌이 때보다 수입이 줄어들어, 생활비, 육아용품 구입비 등에 대한 고민이 많다.
합리적인 소비계획을 세우기 위해 노력하고 있고 그에 따라 중고거래를 적극적으로 이용한다.
주로 중고나라, 맘카페를 활용해 중고거래를 진행하고 있다.
중고나라나 맘카페는 사기가 많은 점, 직거래가 쉽지 않은 점 등의 문제가 있어 대안재를 찾고 있음.

니즈
신뢰할 수 있는 중고거래를 하고 싶음.
중고거래 판매 시 포장 단계, 거래 장소까지 이동 등이 매우 귀찮고 어려움

User Journey Map (고객 여정 지도)

위의 페르소나가 중고거래를 한다면 어떤 고객 여정을 거치게 될까? 앞서 설정한 페르소나는 중고나라와 맘카페를 통해 중고거래를 한 경험이 있다. 중고나라와 맘카페를 최대한 사용해보면서 페르소나의 관점을 고려하여 고객의 여정 단계와 각 단계별 경험을 작성해보았다.

(글 길이를 고려하여 구매자 관점에서 작성함.)

1. 상품 검색 & 비교

상품 검색
여러 상품을 비교하여 적정 가격 설정
판매자 검증 (더치트 조회)

2. 판매자와의 협상

판매자에게 연락
가격, 거래방법, 협상

3. 결제

(직거래 시) 만나서 계좌 송금, 현금결제
(택배거래 시) 계좌 송금

4. 물품 수령

(직거래 시) 물품 수령 장소로 이동
(직거래 시) 판매자와의 대면
(직거래 시) 직접 물품 확인 & 수령
(택배거래 시) 택배 수령 & 확인

5. 거래 완료 후

제품 하자 컴플레인
교환, 환불 문의

위의 고객 여정의 단계와 각 상세 경험들은 부정적인 감정을 느낄 수 있는 경험을 위주로 작성해보았다. 고객 여정 지도에서 긍정적인 경험을 파악하여 해당 부분을 부각하는 것도 중요하다. 하지만 일반적으로 부정적인 경험을 우선하여 개선할 필요가 있는 점, 뒤에서 CVC를 통해 고객 가치를 판단하는 점을 고려하여 부정적 경험에 초점을 맞추어 보았다.

Customer Value Chain(CVC)

Customer Value Chain은 고객의 경험을 가치 창출(+), 대가 지불(-), 가치 잠식(.)의 관점으로 분석하는 프레임워크이다.

고객 가치 창출(+): 고객을 위해 가치를 창출하는 활동 (ex. 스타벅스 아메리카노를 얻었다.)
고객 대가 지불(-): 창출된 가치에 대가를 부과하기 위해 추가하는 활동 (ex. 아메리카노 가격을 지불했다. )
고객 가치 잠식(-): 가치를 창출하지도, 창출된 가치에 대가를 부과하지도 않는 활동 (ex. 카페로 이동, 대기에 시간을 소모했다.)

모든 고객은 가치 창출은 최대화하려고 하고 대가 지불은 최소화하려고 하며, 가치가 잠식되는 활동은 피하려고 한다. 이러한 고객 특성을 기반으로 서비스를 고민한다면 기업이 가치를 제공할 수 있는 부분을 확대하거나 가치가 잠식되는 활동 등을 끊어내는 전략을 세워볼 수 있다.

위의 User Journey Map의 고객 경험을 CVC에 따라 분류해보고 현재의 당근마켓이 고객 가치 사슬을 기반으로 어떻게 서비스를 운영하고 있는지를 표로 정리해보았다.

당근마켓이 개선하면 좋을 단계와 솔루션 아이디어

기존 중고거래의 경험 중 대부분은 가치 잠식에 해당하였고 그중 많은 부분을 당근마켓이 잘 해결하고 있었다. 예를 들어 동네 중고 거래라는 핵심 서비스를 기반으로 해결하기 어려웠던 신뢰의 문제, 이동하는 거리의 귀찮음 문제 등을 효과적으로 해결하고 있었다. 또한 채팅 기능 통해 기존 카페형 중고거래에서 가치를 잠식했던 소통의 문제를 해결하고 있음을 확인할 수 있었다.

다만 가치를 잠식하거나 대가를 지불하는 경험 중 아직은 서비스에 반영되지 않은 부분도 있었다. 해당 부분들의 개선이 필요한 이유와 솔루션 아이디어를 아래와 같이 작성해보았다. (우선순위에 따라 1-3까지 작성)

1. 결제 단계 (Must have)

결제 단계는 고객 경험 중 대가를 지불하는 유일한 단계이기 때문에 가장 민감한 부분이 될 수 있다. 그렇기에 가장 우선적으로 개선할 필요가 있다.

직거래를 할 때는 은행 앱을 켜고, 인증하고, 계좌번호를 입력하는 불편함이 있다. 일반적으로 직거래는 지하철 입구 등 안정된 장소에서 일어나기 때문에 해당 단계의 불편함이 더 크게 느껴질 수 있다. 택배거래에 경우 당근마켓이 동네 거래를 통해 신뢰를 형성하였다고 하더라도, 일반적으로 선입금 형태의 중고거래에서는 걱정이 앞서기 마련이다.

당근마켓만의 페이를 도입하면 어떠할까? 단순 QR를 기반으로 직거래 시에 쉽게 계좌 송금을 할 수 있다면 좀 더 나은 직거래 경험을 만들 수 있을 것이다. 택배거래 시에도 페이의 도입은 안전거래, 에스크로 결제를 가능하게 한다. 그에 따라 선입금에 있어 걱정을 최소화할 수 있다.

2. 물품 수령 단계 (Sould have)

코시국이 지속되면서 대면 거래에 대한 불편함이 지속되고 있다. 직거래 시 판매자와의 대면은 이러한 시국에 따라 개선할 필요가 있다. 게다가 여성범죄에 대한 우려로 인해 대면거래에 대한 걱정이 커지고 있으며, 동네 기반의 거래가 근처 구까지 확대됨에 따라 신뢰를 적절하게 형성하고 있지 못하고 있다.

당근마켓은 지역 커뮤니티의 활성화를 비즈니스적 목표로 가져가고 있다. 지역 커뮤니티의 또 다른 이해관계자는 지역 상점이다. 지역 상점은 손님의 방문을 원한다. 만약 판매자와 구매자가 지역 상점에 물품과 거래 대금을 맡기고 수령해갈 수 있다면 어떠할까? 대면 거래의 불편함은 최소화하면서 지역 상점으로의 방문 또한 유도할 수 있다. 기존 다른 중고거래 플랫폼이 IOT 시설물을 설치하여 대면 거래를 최소화하는 방법에 비해 비용도 덜 들뿐더러, 당근마켓의 비즈니스적 목표인 지역경제 활성화에도 도움이 될 수 있을 것으로 보인다.

3. 여러 상품 비교 & 적정 가격 설정의 단계 (could have)

중고거래를 정해진 가격이 없다. 그렇기에 적합한 가격을 설정하기 위해 올라와있는 동일 상품의 가격, 기존 거래된 가격 등을 살펴볼 필요가 있다. 기존의 카페형 중고거래를 이전에 거래 완료된 상품 가격을 확인하기 어려운 점(소비자가 삭제), 동일 제품을 쉽게 분류하기 어려운 점 등이 있어 가치를 크게 잠식하고 있었다. 당근마켓에서는 기존 거래완료된 상품의 가격을 노출하여 쉽게 확인할 수 있다는 장점이 있었지만 그럼에도 불구하고 가격 설정을 위한 시간 소모가 크다.

만약 해당 상품의 최저 가격, 평균 가격, 최고 가격을 상품 정보에 자동으로 노출한다면 해당 가치 잠식을 끊어낼 수 있을 것이다.

Comment

고객 여정과 CVC를 통해 당근마켓을 역 기획해보았다. 경험 선정, 우선순위 설정 등이 대부분 데스크 리서치와 주변 미니 인터뷰를 통해 작성되어 있다. 해당 부분이 아쉽다. 기회가 된다면 좀 더 많은 이들의 의견을 담아 각 부분의 논리를 만들어 내어 다시 작성해보고 싶다.

[PMB 8기] Agile(애자일) = Jira(지라), 애자일이지라!

기획자킴제이 — Mon, 22 Nov 2021 23:57:22 +0900

Agile = Jira

지난 글에서 Agile(이하 애자일)의 자세한 개념에 대해서 알아보았다. 나 또한 그렇지만, 애자일 도입을 고민하는 많은 이들이 실제 적용 방법에 대해 감이 안 잡히는 경우가 많을 것이다. 실제 업무에서는 어떻게 애자일스러움을 만들어내고 있을까?

애자일한 업무 프로세스를 구축하기 위해 많은 기업에서 Tool의 도움을 받고 있다. 우리나라에서 대표적인 SW는 Jira, Trello, Asana 등이 있다. Datanyze라는 리서치 업체 자료에 따르면 Jira를 사용하여 프로덕트를 매니지먼트하는 회사가 가장 많은 것으로 나타났다. 그렇기에 오늘 글 제목처럼 애자일 하면 자연스럽게 Jira를 떠올리는 경우가 많다.

애자일을 공부하다 보면 Theme, Epic으로 업무 단위를 분절하는 개념을 쉽게 찾아볼 수 있다. 애자일에 관한 여러 아티클에서는 나타나지 않았던 개념이라 생소할 수 있다. 하지만 현업에서는 익숙하다는 반응이다. 그 이유는 이와 같은 개념이 Jira에서 출발하였기 때문이다. 현업에서 Jira가 많이 쓰이는 만큼 해당 개념도 널리 퍼져있는 것이다. 관련된 내용은 간단하게 아래 그림을 통해 이해할 수 있다.

그렇다면 Jira는 어떤 기능을 가지고 있길래 애자일스럽게 일할 수 있는 기반을 만들어 주는 것일까?

애자일의 12가지 원칙

Jira가 애자일 함을 어떻게 만들어내는지를 알기 전에 애자일스럽기 위한 원칙들을 먼저 살펴보자.

'애자일 하게 일한다' 란 이야기를 듣기 위해서는 위와 같은 12개의 원칙을 지킬 수 있어야 한다. 이를 한국어로 번역하면 다음과 같다.

예시와 각 원칙별 설명을 알고 싶은 분들에게는 다음 링크를 추천한다. (링크)

제 1 원칙: 초기부터 지속적으로 고객 만족
제 2 원칙: 요구사항 변경 수용
제 3 원칙: 짧은 배포 간격
제 4 원칙: 함께 일하기
제 5 원칙: 동기 부여된 팀원들로 프로젝트팀 만들기
제 6 원칙: 얼굴 보고 대화하기
제 7 원칙: 동작되는 소프트웨어로 진도 측정
제 8 원칙: 지속 가능한 개발 속도 유지
제 9 원칙: 좋은 기술, 설계에 관심
제 10 원칙: 단순성
제 11 원칙: 자기 조직화 팀
제 12 원칙: 정기적으로 효율성 제고

Jira에서 찾아볼 수 있는 애자일 원칙들

1. 함께 일하기

Jira에서 볼 수 있는 스크럼 보드(스프린트에서 쓰이는 Kanban)

'함께 일하기'를 위해서는 업무를 투명하게 공유하는 것이 가장 중요하다. Jira는 모든 팀원이 스프린트 상의 업무를 공유할 수 있도록 많은 기능을 제공하고 있다. 대표적인 기능은 위와 같은 스크럼 보드이다. 각 카드별로 이슈, 백로그, 진행사항, 담당자 등을 한눈에 확인할 수 있다. 그 외에도 Slack, Github과 같은 협업 툴과의 연동을 통해 함께 일하는 환경 구축을 위한 기능도 제공하고 있다.

2. 동작되는 소프트웨어로 진도 측정

애자일 원칙에서 제품의 동작 여부는 스프린트의 진도를 측정하기 위한 중요한 요소이다. 얼마큼의 시간이 들어갔는지, 얼마큼 코드를 작성했는지가 중요한 것이 아니라, 실제 기능 개발이 얼마나 이루어져 있는지가 중요하다. 그렇기에 애자일에서는 기능 개발 완료를 기준으로 스프린트의 전체 진도를 측정한다. Jira는 이러한 기준에 맞춰 번다운 차트, 출시 일정 차트, 로드맵 등 기능 개발을 기준으로 진도를 측정할 수 있는 다양한 차트를 제공하고 있다.

3. 지속 가능한 개발 속도 유지

지속 가능한 개발을 위해서 앞서 말한 스프린트의 진도를 측정하고 확인하는 것이 중요하다. 하지만 무엇보다 가장 중요한 것은 팀원 개개인의 업무 역량과 Capacity를 확인하고 적절한 스프린트 계획을 세우는 것이다. 만약 팀원의 역량을 초과할 정도의 강도 높은 스프린트가 진행될 경우 반복적인 스프린트는 절대 불가능하다. 이러한 부분을 관리하기 위해 Jira는 팀 역량 개개인의 역량을 측정하고 해당 부분을 쉽게 확인할 수 있는 기능도 제공하고 있다.

Comment

Jira를 자세하게 알아보면서 정말 좋은 기능이 많다는 것을 알 수 있었다. 하지만 많은 기능 때문에 자유자재로 사용하기 위해 Jira를 익히는 시간이 오래 걸릴 수 있다는 염려가 동시에 들었다. 분명 툴은 애자일 환경을 만드는 데에 큰 도움을 준다. 그러나 무엇보다 중요한 것은 애자일 사상을 이해하고 스크럼 팀의 환경과 개성에 맞춰 애자일을 도입하는 것이다. 만약 Jira에 익숙하지 않은 팀원들이 많은 경우에도 도입을 위해 애쓴다면 분명 비효율을 낳을 수 있다. 그렇기 때문에 원칙에 사로잡히기보단 유연한 사고로 애자일을 적용하는 역량이 필요할 것이다.

[PMB 8기] 애자일 스크럼에서의 PM의 역할과 스프린트 하는 법

기획자킴제이 — Thu, 18 Nov 2021 23:22:18 +0900

'애자일' 하게 일한다?

애자일하게 일한다는 것은 신속함을 바탕으로 짧은 기간동안 제품 개발 사이클을 반복적으로 실행하며 프로덕트를 만드는 방법이다. 이러한 애자일은 스크럼, 칸반, XP 등 여러 가지 Framework를 기반으로 실무에 적용된다. 이 중 가장 많이 쓰이는 프레임워크는 Scrum 프레임워크이다. 전체 Agile 적용 팀 중에 66%가 Scrum 방식을 채택해서 업무를 진행하고 있다.

source: Agile Survey

그렇다면 Scrum에서 중요하게 봐야 할 부분은 무엇일까? 필자가 PM으로서의 커리어를 꿈꾸고 있는 만큼 우선 PM의 역할에서 중요한 점을 먼저 알아보자.

Product Manager = Product Owner in Scrum

우선 Scrum에서 PM은 Product Owner(이하 PO)로 불린다. PO는 스크럼 팀의 결과물이라고 할 수 있는 프로덕트 가치를 극대화해야 하는 책임을 가지고 있다. 프로덕트를 총괄하는 입장이라고 생각하면 이해하기 쉽다.

PMB 초기 Product Manager는 고객과 비즈니스 양쪽의 관점을 모두 이해해야 한다는 점을 배운 적이 있다. PO도 마찬가지이다. 고객 문제의 정의, 비즈니스 이해관계자의 Align 등은 PO에게도 중요한 부분이다. Scrum에서 프로덕트 이해관계자의 여러 요구사항을 정립하고 종합한 것을 백로그라고 한다. 그래서 PO는 백로그를 효과적으로 설정하고 관리하는 데에도 책임이 있다.

프로덕트 백로그를 효과적으로 관리한다는 것은 어떠한 것일까? Scrum Guide 2020에서 해당 부분의 힌트를 찾을 수 있었다.

1. 프로덕트의 목표를 세우고 명쾌하게 소통하는 것.
2. 프로덕트 백로그 아이템을 생성하고 분명하게 소통하는 것.
3. 프로덕트 백로그 아이템을 우선순위에 따라 정렬.
4. 프로덕트 백로그를 반드시 투명하고 가시적이며 이해가 잘 되도록 만드는 것.

PO는 위와 같이 백로그를 정의하고, 우선순위를 설정하고, 이를 팀원과 함께 소통해야 하는 책임을 가지고 있다. 백로그는 Scrum에서 일의 출발지와 같다. 가장 기본이 되는 사항인 것이다. 그렇기에 PO는 단순히 개인적인 판단으로 백로그를 관리하는 것이 아니라 충분한 자료조사와 이해관계가의 인터뷰, 팀원과의 소통 등을 통해 백로그를 관리해야 한다. 이와 연관하여 Scrum의 전체 과정을 살펴보면 다음과 같다.

1. 프로덕트 오너는 복잡한 문제를 해결하기 위한 업무를 우선순위에 따라 프로덕트 백로그에 정렬한다.
2. 스크럼 팀은 선택한 업무를 스프린트 동안 개발하여 프로덕트에 새로운 가치를 만들어낸다.
3. 스크럼 팀과 이해관계자들은 결과물을 점검하고 다음 스프린트를 위하여 조정을 한다.
4. 반복한다.

이렇게 PO의 역할이 백로그의 관리부터 시작한다는 것을 알아보았고 전체적인 Scrum이 어떻게 진행되는 지를 살펴보았다. 그렇다면 Scrum 방법을 기반으로 실제 어떻게 일을 진행하면 되는 것일까? Scrum에서는 Sprint라는 방식으로 업무를 진행한다. 이는 Scrum에서 가장 중요한 부분 중 하나이며 꼭 숙지해야 할 필요가 있다. 이를 자세히 살펴보자.

Scrum의 심장, Sprint

위의 그림은 Sprint의 과정을 간략하게 표현한 것이다. Sprint(이하 스프린트)는 반복적으로 실행하는 것이 핵심이다. 이를 위해 1주에서 4주 사이의 고정된 길이로 진행해야 한다. 왜냐하면 짧은 길이의 스프린트를 반복해야 스프린트를 돌아보고 학습하며, 지속적으로 스프린트를 발전시킬 수 있기 때문이다. 또한 짧은 기간 동안 수행하는 비용과 노력을 기반으로 개발 실패에 대한 리스크를 한정시킬 수 있다.

스프린트 기간 동안에는 지켜야 할 것들이 있다. 이는 다음과 같다.

1. 스프린트 목표 달성을 저해하는 변경을 해서는 안 된다.
2. 품질을 떨어뜨려서는 안 된다.
3. 필요한 수준까지 프로덕트 백로그를 정제해야 한다.
4. 범위를 명확하게 하고 필요한 경우 프로덕트 오너와 다시 협상을 할 수 있다.

스프린트는 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고 등을 포함하고 있으며 스프린트의 목표를 달성하기 위해 이를 모두 수행하는 것이 좋다.

스프린트 계획 단계

스프린트를 시작하기 전 스프린트의 업무를 상세화 하는 단계이다. 이 단계에서는 팀 전체가 참여하여 계획을 진행한다.

먼저 '스프린트의 가치에 대한 논의'가 필요하다.

스프린트가 왜 중요하고 이 스프린트가 고객과 비즈니스 단의 유저 스토리와 어떻게 연관되어 있는지, 왜 그들에게 중요한 지를 팀원 모두가 공유한다. 또한 이를 기반으로 나탈 수 있는 긍정적인 결과를 생각해본다. 결론적으로 스프린트의 목표를 정한다.

두 번째로 스프린트의 완료(Done) 상태를 정의한다.

프로덕트 백로그란 이해관계자들의 유저 스토리에 따라 팀이 수행해야 할 할 일의 목록을 말한다. 앞서 말한 것처럼 PO는 이 프로덕트 백로그의 우선순위를 정하는데 이를 공유하면서 이번 스프린트에 포함할 프로덕트 백로그 아이템을 선정해야 한다. 이 과정에서 백로그를 더욱 정제할 수 있다.

수행할 백로그를 선택한다면 개발자, 디자이너 등의 팀원들과 함께 해당 백로그를 완료되었다고 판단할만한 기준을 세운다. 또한 각 백로그마다 들어가는 팀의 리소스를 팀원 개개인별의 과거 경험을 기반으로 판단할 필요가 있다.

세 번째로 선정한 백로그를 어떻게 완수할 수 있을지에 대해 논의한다.

앞서 말한 완료되었다고 판단할만한 기준을 기반으로 이를 성취하기 위한 세부적인 업무를 기획해야 한다. 이를 Task라고 말한다. 예를 들어 랜딩 페이지 만들기라는 백로그를 선정했다면 웹 UX 디자인, CTA 버튼 기획, 웹 페이지 구축 등이 Task라고 할 수 있다.

이렇게 선정한 스프린트 목표, 백로그 아이템들, 그리고 완료를 위해 수행해야 할 Task들을 모두 합쳐 스프린트 백로그라고 부른다.

데일리 스크럼 단계

데일리 스크럼이란 스프린트 기간 동안 매일 15분 정도로 진행하는 것으로, 스프린트의 목표 대비 진척을 점검하고 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정하기 위해 진행한다. 팀원들이 모두 참여하거나 개발 중심 기업에 경우, 개발자들만 참여하는 경우도 있다. 만약 PO가 스프린트 기간 내에 아이템 개발에 활발하게 참여한다면 PO도 데일리 스크럼에 참여할 수 있다.

진척을 예측하는 데에는 번 다운 Burn‐downs 차트, 번 업 Burn‐ups 차트, 누적 흐름도 Cumulative flows와 같은 다양한 방식이 있다. 가장 많이 쓰이는 방식은 번 다운 차트이다. 간혹 차트 작성에 집중하여 데일리 스크럼 시간을 차트 생성의 시간으로 쓰는 경우도 있다. 하지만 가장 중요한 것은 PO나 Scrum Master가 진척사항과 목표한 속도의 괴리가 있을 경우 이를 다양한 관점에서 분석하여 적절히 스프린트를 조정하는 것이다.

스프린트 리뷰

스프린트 리뷰의 목적은 스프린트의 결과물을 점검하고 향후에 반영할 사항들을 결정하는 것이다. 스프린트 리뷰 동안 스크럼 팀과 이해관계자는 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토한다. 이 정보에 기초하여 참여자들은 다음 스프린트에서 무엇을 할 것인지 협력하여 논의한다.

새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다. 어느 정도 팀원의 수행능력 등을 파악했다면 스프린트 기간을 조정할 수 도 있다. 스프린트 리뷰는 스프린트의 끝에서 두 번째로 하는 이벤트이다. 최대 시간이 정해진 이벤트로 1개월 기간의 스프린트인 경우 4시간이 넘지 않도록 한다고 Ken Schwaber & Jeff Sutherland의 Scrum Guide에서는 말하고 있다. 하지만 중요한 것은 기업의 상황, 스프린트의 결과 등에 맞춰 유연하게 적용하는 것이다.

스프린트 회고

스프린트 회고의 목적은 품질과 효율을 높이기 위한 방법들을 계획하는 것이다. 스크럼 팀은 팀원 개개인, 팀원 간의 대화와 상호작용, 프로세스, 툴, 완료의 정의에 대해 지난 스프린트가 어떻게 진행되었는지를 점검한다. 업무 영역 별로 점검하는 사항들은 차이가 날 수 있다. 예를 들어 협업 툴의 불편한 점에 대한 의견이 많았다면 협업 툴을 바꿔볼 수도 있으며, 분배된 업무량이 특정 팀원에게 버겁다는 점을 기반으로 다시 업무를 배분할 수도 있다.

스크럼 팀은 무엇이 잘 진행되었는지에 대해서도 공유해야 한다. 어떤 문제를 만났고 그 문제를 어떻게 풀었는지(또는 풀지 못했는지)에 대해 의견을 나눈다. 이러한 공유는 새로운 문제를 만났을 때 극복할 수 있는 방법을 알려줄 수 있다.

스프린트 회고를 마지막으로 스프린트가 종료된다. 최대 시간이 정해진 이벤트로 일 개월 기간의 스프린트인 경우 3 시간이 넘지 않도록 한다고 Ken Schwaber & Jeff Sutherland의 Scrum Guide에서는 말하고 있다. 앞서 말한 것처럼 이 또한 기업의 상황, 회고를 중요하게 생각하는 기업 문화 등에 따라 차이가 날 수 있으므로 유연하게 적용하는 것이 필요하다.

완벽한 Agile 방법을 찾는 이들에게 전하는 가장 중요한 것

Agile은 기존 Waterfall 방식의 리스크, 비용, 고객 중심적이지 못한 결과물 등의 문제를 보완하기 위해 나타난 방법론이다. 이 점을 가장 주목할 필요가 있다. 우리는 짧은 시간 내에 리스크를 최소화하며, 반복적으로 기능을 개발해야 한다. 이를 이해관계자들에게 테스트해봄으로써 이해관계자들의 니즈에 근접한 제품의 가치에 다가갈 수 있기 때문이다. 즉, 진정한 고객 가치를 만드는 방법에 대한 고민이 제일 중요하다.

필자는 이런 점을 간과하였다. 이론적인 이해를 완성하고 싶은 마음에 애자일 방법론의 근본적인 차이와 정석을 찾기 위해 노력했었다. 하지만 결론적으로 많은 공신력 있는 기관에서 제공하는 방법론조차 차이가 있으며 현업에서는 더욱 큰 차이가 발생하고 있었다. 애자일 사상에서도 각 업무상황이나 팀원에 따라 유연하게 적용하는 것이 중요하다는 점을 강조한다. 그렇기에 '방법론'에 집중하기보다는 '유연성'을 중심으로, Agile 한 제품 개발의 근본적인 목적을 기억해야 한다.

[PMB 8기] 네이버 쇼핑 리뷰 기능을 주제로 애자일 찍먹하기!

기획자킴제이 — Wed, 17 Nov 2021 23:51:28 +0900

네이버 쇼핑에서 겪은 불편함

최근 네이버에서 제품을 구입할 때, 리뷰를 확인하면서 너무 불편하다는 생각을 했다. 네이버 쇼핑의 상품 페이지 중 상당수가 한 개의 상품 페이지에서 여러 개의 제품 정보를 한 번에 제공하고 제품을 선택하는 방식으로 상품을 노출하고 있다. 너무 많은 종류의 제품이 한 페이지에 있을 경우 제품 정보와 제품 이름을 대조하며 제품을 선택하는 것도 불편하지만, 무엇보다 내가 선택하고자 하는 제품의 리뷰를 보는 것이 정말 불편하다. 이는 네이버 쇼핑의 리뷰에 경우 특정 제품의 리뷰를 필터링해서 볼 수가 없기 때문이다.

좌: 네이버 쇼핑의 리뷰 우: 해당 페이지에서 제공하는 상품의 선택지 수

위 사진의 상품 페이지는 약 25개의 상품의 정보를 한 번에 제공하고 있다. 각 제품에 대한 리뷰를 확인하는 데에 불편함이 크다. 리뷰를 확인하기 위해서는 약 4만 개 리뷰를 하나하나 넘겨가며, 각 리뷰 제목 하단 부분에 노출되어 있는 제품 상세 정보를 대조하면서 일일이 리뷰를 확인해야 한다.

좀 더 자세한 문제점을 파악하기 위해 간략한 인터뷰를 진행해보았다. 지인 1은 해당 불편함을 강하게 느낀다고 답을 했고, 그에 따라 상품 종류가 많고 한 번에 노출되는 상품페이지일 경우 해당 페이지에서 이탈하여 단일 상품 페이지를 참고한다고 한다. 지인 2는 그 불편함이 엄청 크지 않다고 답하였는데, 그 이유는 애초에 여러 제품이 노출되는 제품 페이지를 방문하지 않기 때문이라고 하였다.

이러한 점을 종합한다면 분명 해당 문제점이 분명한 것으로 보인다. 인터뷰에서도 간략하게나마 알 수 있듯이 여러 가지 상품 정보가 한 번에 제공되고 각각의 제품의 리뷰를 확인하기 힘들다면 이는 이탈로 이어진다. 고객 구매 여정에 있어 이탈을 만드는 요소인만큼 꼭 해결해야 할 문제라고 볼 수 있다.

애자일 찍먹! 유저 스토리와 태스크 설정해보기!

애자일의 의미와 방법론

※ 애자일(Agile)이란?
‘Agile = 기민한, 날렵한’ 이란 뜻이다. 단어의 뜻에서도 알 수 있듯이 짧은 제품 개발 사이클을 반복적으로 실행하면서 제품을 만들어가는 사상을 의미한다. 미리 정해진 단계에 따라 순서대로 이루어지는 워터폴 방식은 제품 개발의 주기가 길어지고 중간중간 소비자의 피드백을 받기 어렵다는 단점이 있다. 이러한 단점을 보완하는 것이 애자일 방식이며, 단계를 빠르게 반복하며 고객 중심의 제품을 만들 수 있는 것이 애자일의 가장 큰 장점이다.

위에서 설명한 애자일 사상은 칸반(kanban), 스크럼(Scrum), XP(eXtream Progrmming) 등의 방법론을 기반으로 실무에 적용되고 있다. 각각의 방법론은 애자일 사상에 따라 설계되었지만 다른 프로세스를 제시한다. 각각의 방법론을 제대로 이해하기 위해 많은 문서를 살펴보았다. 하지만 의외로 완벽한 비교 문서는 없었고, 많은 아티클이나 실무에서 칸반과 스크럼을 혼용해서 쓰는 것을 발견하였다. 실제로 스크럼 방식과 칸반 방식을 혼합한 Scrumban 방식 등의 사용률이 꽤나 높은 것을 아래 그림에서 알 수 있다.

전세계 애자일 방법론의 종류와 사용률. 출처: Agile Survey

우리가 흔히 이야기하는 User Story는 XP 방법론에서, 포스트잇으로 업무를 관리하는 방법은 Kanban에서 스프린트를 기준으로 업무 사이클을 만들고 백로그를 성정하는 것은 Scrum 방법론에서 제시한 개념들이다. 물론 각각의 방법론이 가지는 장점과 단점을 적절히 혼합하여 실무 환경에 최적화된 방법론으로 맞춤화하는 것이 애자일 사상의 중요한 포인트이다. 그럼에도 불구하고 각각의 명확한 정의와 개념을 아는 것은 향후 PM으로서 Agile 프로세스를 설계하는 데에 큰 도움이 될 수 있을 것이라 본다.

네이버 리뷰 기능 개선 사항을 User Story와 Task로 정리해보기

앞서 이야기한 네이버의 리뷰 기능에 문제점을 어떻게 해결해야 할까? 먼저 고객 관점에서 고객의 상황과 문제점 그리고 원하는 바를 User story로 정리해보면 다음과 같다.

AS: [네이버 쇼핑을 이용하는 소비자]는
I want : [여러 가지 상품 정보가 한 번에 제공될 경우 각 상품별 리뷰를 확인] 하기 위해서
So that: [각 상품 종류에 해당하는 리뷰를 골라볼 수 있는 기능]을 원한다.

이러한 유저 스토리를 기반으로 개발할 기능을 정의한다면 "상품 종류별 리뷰 필터링 기능"으로 정의할 수 있다. 그렇다면 이에 대한 Task들은 어떤 것들이 있을까?

1. 상품 별 필터 기준 추가 및 개발

네이버에서는 현재 랭킹 순, 최신순, 평점 높은 순, 평점 낮은 순으로 리뷰를 필터링할 수 있고, 전체보기, 포토/동영상, 스토어 Pick, 한 달 사용 리뷰에 따라 리뷰를 볼 수 있다. 그에 따라 새로운 필터 기준을 추가하는 일이 필요할 것으로 보인다. 또한 각 리뷰 별 구매한 상품의 항목이 리뷰에 노출되는 것을 볼 수 있는데, 이를 기반으로 추측하면 각 리뷰당 구매 항목의 데이터가 연결되어 있는 것으로 볼 수 있다. 그렇기에 특별한 데이터베이스 연동은 불필요할 것으로 볼 수 있다.

2. 제품별 필터 항목 선택 버튼 UI 제작

리뷰를 볼 수 있는 부분에서 보고 싶은 제품을 선택할 수 있는 버튼이 필요하다. 제품별이라는 필터의 제목과 세부 제품 항목을 선택할 수 있는 선택창이 필요할 것으로 보인다.

3. 버튼 인터렉션 구현

현재 리뷰 필터를 선택할 때 글자색이 굵어지고 필터마다 체크 표시가 추가되는 인터렉션이 있다. 상품 종류별 필터를 추가할 때도 해당 인터렉션의 구현이 필요할 것으로 보인다.

이외로 해당 기능의 테스트, QA 등의 Task가 있을 것이다.

스프린트 백로그와 연관 태스크

애자일 방법론 중 Scrum 방식에서는 Product Backlog와 Sprint Backlog라는 개념이 나온다. 전자에 경우 유저 스토리를 통해 도출한 해야 할 일들을 전체 비즈니스 관점에서 정리한 목록을 말한다. 후자는 Product Backlog 중 우선순위를 설정하여 Sprint(1주~1달 사이의 제품 개발 사이클)에서 수행할 Backlog을 선정한 목록이다. Sprint Backlog는 구체적으로 해야 할 일들로 세분화되는데 이를 Task라고 한다.

상품 종류별 리뷰 필터링 기능은 네이버 쇼핑 상품 페이지에서 개선해야 할 여러 가지 Product backlog 중 우선순위가 높다고 판단되고, 그에 따라 Sprint backlog로 설정할 수 있다. 이를 기반으로 Task와 역할까지 도출한 결과가 위의 표이다.

Comment

우선순위를 평가하는 방법을 적용해보고 싶었는데 Task 단에서의 우선순위를 정하기는 쉽지 않아 일단을 생략하였다. 프로덕트 백로그(유저 스토리)의 백로그에 대한 우선순위 설정 방법은 많은데 네이버 리뷰가 구매 결정에 굉장히 큰 결정을 한다는 점, 이미 리뷰 별 제품 정보가 라벨링 되어있다는 점 등을 고려한다면 프로덕트 백로그 중에서도 높은 우선순위를 가질 수 있을 것이란 추측을 해볼 수 있다.

W8D3 과제 추가

PO가 소통해야 할 이해관계자

앞서 설정한 백로그는 고객 관점의 유저 스토리를 기반으로 작성되어 있다. 고객 중에서도 End user의 니즈를 충족하는 데에 목적이 있다. 그렇다면 PO는 고객의 유저 스토리만을 기반으로 백로그를 관리하면 되는 것일까?

PO의 역할과 연관되어 있는 여러 이해관계자

스크럼 방법에서의 백로그는 개발할 과제들의 목록이다.(유저 스토리로 표현한다.) 이는 프로덕트와 연관되어 있는 이해관계자들의 니즈를 기반으로 도출한다. 여기서 이해관계자는 프로덕트에 관해 관심을 가지고 있거나, 영향을 미치는 누구나 될 수 있다. 예를 들어 고객들, 조직 내 중요 의사결정자, 투자자, 같이 일하는 다른 부서의 동료, 고객의 VOC를 수집하는 CX 팀, 법무팀 등 기업 내외부의 누구나 이해관계자로 볼 수 있다. 그중에서도 조직 내 관리자, 스크럼 팀, 스크럼 마스터, 고객 등이 중요 이해관계자라고 할 수 있다.

네이버 쇼핑 리뷰 기능에 연관된 이해관계자는?

네이버 쇼핑 리뷰 기능 연관된 이해관계자는 어떤 사람들일까? 물론 수많은 이해관계자들이 있을 수 있지만, 그중에서도 상품을 판매하는 셀러, 네이버 쇼핑 팀의 최종 의사결정자 등이 중요 이해관계자들일 것이다. 이들은 각자의 관점에 따라 다른 유저 스토리를 가지고 있을 수 있다. 예를 들어 네이버 쇼핑에서 상품을 판매하는 셀러는

AS: [네이버 쇼핑에서 상품을 판매하는 셀러]는
I want : [상품 페이지에 유입된 고객들을 구매로 전환시키기] 위해서
So that: [구매하기 버튼의 인터렉션 UI ]을 원한다.

라는 유저 스토리를 가지고 있을 수 있고, 네이버 쇼핑 팀의 최종 의사결정자는,

AS: [네이버 쇼핑 최종 의사결정자]는
I want : [쇼핑 라이브 서비스를 성장시키기 ] 위해서
So that: [쇼핑 라이브 기능 개선을 최우선으로 해결하는 것]을 원한다.

라는 유저 스토리를 가질 수 있다. 가상의 인물에 대한 유저 스토리만 보아도 각각의 이해관계자들이 원하는 바가 매우 다름을 알 수 있다.

Product Owner가 이해관계자들의 다양한 니즈에 대처하려면?

PO가 고려해야할 사항들

PO라면 수많은 이해관계자들의 의견을 듣고 각각의 유저 스토리를 백로그로 녹여내야 한다. 그러나 모든 이해관계자들의 유저 스토리를 무조건 백로그에 반영한다면 PO의 업무가 과다해지고 이는 스크럼 환경에서 비효율을 낳게 될 것이다. 그렇기 때문에 PO는 백로그의 선별, 관리, 우선순위 결정에 많은 공을 들여야 한다.

이러한 부분은 15년 차, 시니어 PO 들에게도 어려운 부분이라고 한다. 그럼에도 불구하고 주니어 PO에 시야에서 가장 중요하게 생각하는 방법 세 가지를 뽑아 보았다.

1. 거시적인 관점에서 유저 스토리를 바라보자.

PO는 고객, 비즈니스 방향성, 이해관계자, 스크럼 팀을 대변하는 단 한 명의 존재이다. 그렇기에 좁은 시야에서 유저 스토리를 바라봐선 안된다. 언제나 고객 가치를 만들기 위해 노력하되, 비즈니스 가치를 해치는 방향성을 잡아선 안된다. 많은 이해관계자들, 스크럼 팀의 니즈를 깊이 공감하고 이를 녹여내기 위해 노력해야 한다.

2. 근거와 설득

여러 이해관계자들의 니즈를 종합하고, 이들을 설득시키기 위해서는 언제나 근거를 기반으로 백로그를 만들 수 있어야 한다. 특히 데이터적인 근거를 적극적으로 활용하고, 필요하다면 유저 인터뷰를 통한 깊은 인사이트를 백로그에 녹일 수 있어야 한다. 이러한 과정이 있다면 백로그를 선별하고, 우선순위를 정하는 데에 있어 확실한 기준을 만들 수 있다. 만약 이해관계자들과의 마찰이 있더라고 명확한 근거가 있다면 설득이 쉬워질 수 있다.

3. 소통, 소통, 소통

Product Owner는 백로그의 선정과 관리, 그리고 스크럼 팀의 제품 개선 결과에 책임을 지는 역할이다. 그렇다고 해서 PO가 막강한 권한을 가지고 있다는 의미는 아니다. 물론 PO의 인사이트와 직관은 중요한 요소일 수 있지만 혼자서 모든 결정을 내렸을 경우, 자칫 잘못된 길로 빠질 가능성이 크다. 그렇기 때문에 언제나 이해관계자들과의 소통을 해야 한다. 소통을 통해 각 이해관계자들의 입장, 그리고 그들의 유저 스토리를 깊게 이해할 수 있고, 이해관계자들의 의견을 종합적으로 반영할 수 있는 기반을 만들 수 있다. 그리고 이를 바탕으로 PO는 백로그를 다듬고 관리할 수 있어야 한다.

위의 3가지 방법은 수많은 PM, PO의 채용공고를 보면서 느낀 점을 토대로 작성하였다. 많은 채용공고들이 비즈니스적 시야와 고객 중심의 시야를 모두 갖추고 있길 원하고, Data-driven 한 의사결정을 할 수 있는 사람을 원한다. 또한 원활한 커뮤니케이션 스킬을 필수적으로 요구하고 있다. 많은 기업들이 원하는 공통적인 역량이라는 점에서 보았을 때, 해당 역량이 여러 이해관계자들의 니즈에 대처하는 법의 기본이 아닐까란 생각으로 위의 대처방안을 작성해보았다.

[PMB 8기] 기획자의 우아한 형제들 기술 블로그 탐험 일기

기획자킴제이 — Mon, 15 Nov 2021 23:45:56 +0900

'글'은 더 이상 강력한 정보전달 도구가 아니다. 사진, 영상의 시대에서 세심하게 글을 읽는 이들도 사라지고 있다. 그럼에도 불구하고 '글'은 중요하다. 글을 쓰는 사람은 자신의 생각을 구조적으로 정리할 수 있고, 글을 읽는 사람은 이해를 위해 구조적 사고를 거쳐야 하기 때문이다.

내가 블로그에 글을 쓰는 이유 또한 내가 아는 것을 구조적으로 표현하기 위해, 그리고 나의 사고 흐름을 자세히 보여주기 위함이다. 이런 이유 때문인지, 브런치를 중심으로 우리나라를 이끌어가는 많은 IT 업계의 전문가들이 글을 활용하여 지식을 공유하고 있다.

많은 IT 전문가들이 그러한 것처럼, 여러 기업들도 기술 블로그를 만들어 기업 내부의 기술 관련 지식이나 프로젝트, 현황 등을 공유하고 있다. 네이버, 당근 마켓, 토스, 배달의 민족 등이 그러하다.

앞서 언급한 여러 기업들의 기술 블로그를 돌아본 결과 솔직한 이야기로 기획자가 이해하기에는 한계가 있었다. 그럼에도 불구하고 단편적이지만 개발자가 일하는 방식, 기술 스택 등을 알 수 있는 점은 굉장히 좋았다. 무엇보다 코드를 지속적으로 개선하는 과정에서 기능의 구현이 가능한가 아닌가만이 목적이 아니라, 깨끗하고 효율적인 코드를 쓰기 위해 여러 번의 코드 리뷰 등을 거친다는 것이 인상 깊었던 것 같다. PM으로서의 관점을 좀 더 확장할 수 있는 계기였다.

우아한 형제들 기술 블로그 글 탐험해보기

여러 기업들의 기술 블로그를 읽으면서 가장 흥미롭게 읽은 글을 소개해보려고 한다. 해당 글을 읽으면서 기획자의 관점에서 이해한 바에 따라 간략히 정리하고 간단한 설명을 달면서 글을 소개한다. 즉, 필자가 이해한 바를 최대한 표현하려고 한다. (그 이유는 글의 마지막에....) 해당 글은 아래 링크에서 볼 수 있다.

※ 주의: 전문지식 없이 제멋대로 리서치를 해보며 기술 블로그 내의 글을 해석해본 글이므로 틀린 점이 다수 있을 수 있음.

https://techblog.woowahan.com/2718/

검색을 위한 데이터 다루기 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 우아한형제들 검색개발팀 정철입니다. 배달의민족 검색시스템에서 검색에 사용되는 데이터를 적재하면서 경험했던 어려움과 해결했던 방법을 공유하고자 합니다. 검색

techblog.woowahan.com

탐험(?)해볼 글은 배달의 민족 검색시스템에서 근무하시고 계신 '정철'님의 글이다. 검색시스템의 주요 기능을 개발하는 과정 상, 생긴 문제를 해결하는 과정을 설명하고 있다. 검색시스템은 주문하고 싶은 가게나 메뉴를 빠르게 찾을 수 있는 기능들의 집합이라고 볼 수 있다. 우리가 흔히 볼 수 있는 검색 기능, 인기 검색어, 배달 빠른 순, 배달 팁 낮은 순과 같은 정렬이나 최소 주문금액과 같은 기준에 따른 필터링 기능 등이 있다.

source: 우아한 형제들 기술 블로그

소비자에 입장으로 너무도 쉽게 쓸 수 있었던 이 기능은 실시간으로 광고, 리뷰, 가게 상황, 주문자의 위치에 따른 가게별 거리, 평균 조리 시간 등 수많은 데이터를 실시간으로 동기화해야만 구현되는 복잡한 기능이었다. 초기 시스템 설계 시에는 수집할 데이터 양이 많지 않았기에 문제가 없었지만, 배달의 민족 앱이 슈퍼앱이 되어가면서 데이터량이 급격하게 늘어나는 데에 따른 몇 가지 병목 현상이 발생하게 되었다고 한다.

source: 우아한형제들 기술 블로그

가게나 리뷰 등에서 발생하는 이벤트(변경사항 정도로 이해할 수 있음)를 건 바이 건으로 수집하는 방법은, 데이터가 과도하게 몰리는 경우에 수많은 이벤트 수신으로 Elasticsearch Writer Thread Pool에 과부하를 만든다. 그에 따라 데이터를 추가하는 요청(Request)이 거절되거나 Disk I/O 문제로 CPU 수치가 급격하게 올라가는 문제가 발생했다고 한다.

Elasticserch : 오픈소스 분산 검색 엔진으로 검색 엔진을 구동하는 프로그램 정도로 이해할 수 있음.
Disk I/O : 물리적 HDD에 데이터가 Input(입력)/Output(출력) 되는 과정, 지표, 기기. 여기서는 과정으로 볼 수 있음.
Writer Thread Pool: Elasticsecrch의 주요 기능들을 thread pool의 형태로 생성하여 관리하는 것.
Thread: 프로그램에서 실행되는 흐름의 단위, 프로세스 내에서 작업을 수행하는 세부 기능을 지칭하는 말, 블로그 글쓰기 기능 안에는 글자 입력 스레드, 맞춤법 교정 스레드 등이 있을 수 있음.

이에 대한 원인은 Elasticserach의 정보처리 방식 때문이다.

source: 우아한형제들 기술 블로그

Elasticserch의 Index(정보를 쌓는 구조 정도로 이해)는 Lucene(검색을 위한 라이브러리)를 기반으로 여러 개의 하위 Segment(데이터의 단위 정도로 이해)로 이루어진다. 이 segment는 검색 요청을 빠르게 처리하기 위해 각 데이터마다 여러 개가 생성되어 해당 요청을 처리한다. 하지만 segment는 생성 후 그 상태를 바꿀 수 없는 특징이 있는데, 그에 따라 기존 정보를 업데이트(정보를 추가) 해야 할 시 기존 segment에 표시만 하고 계속해서 segment를 생성한다. 만약 수백만 개의 데이터가 업데이트되면 그에 준하는 양의 Segment가 생성되고, 이를 처리하기 위해 Disk I/O가 급격히 증가, 그 결과로 CPU가 과부하 되게 된다.

쉽게 말해 PPT를 만들 때 장표 하나하나마다 PPT 파일을 계속 생성하는 것과 비슷하다.

source: 우아한형제들 기술 블로그

Elasticsearch에서는 Writer thread pool이 한계상태가 되면 각 thread pool 별로 가지고 있는 queue(부가적인 데이터 처리 장소)에 요청을 넣어 해결하는데 이 마저 한계일 경우에는 업데이트 요청이 거절된다. 이는 앞서 말한 이벤트 데이터를 건 바이 건으로 수집하는 방법에 의해 발생한 문제이다.

source: 우아한형제들 기술 블로그

위의 나타나는 문제를 해결하기 위해 들어오는 이벤트를 묶어서(bulk) 처리하는 API를 사용했다고 한다. 데이터 변경 request를 모아 buffer(요청을 모아 놓는 임시 저장소 정도로 이해)에서 일정한 기준에 맞게 데이터를 처리하여 해당 문제를 해결하기 때문에 기존의 건 바이 건 request 보다 리소스를 덜 쓰면서 데이터를 처리할 수 있다.

source: 우아한형제들 기술 블로그

이러한 방법을 통해 위와 같은 성과를 낼 수 있었다는 점을 블로그 글에서 소개하고 있다.

탐험과정을 글로 써 본 이유

PM에게 기술에 대한 이해는 왜 필요한가? 무엇보다 모든 디자이너, 개발자들이 PM에게 가장 강조하는 커뮤니케이션 역량 때문이다. 기술에 대한 이해가 있을 때 커뮤니케이션의 기본을 갖출 수 있다. 그렇다면 내가 만약 배달의 민족의 PM으로 일을 한다면 아래와 같은 배달의 민족의 기술 스택을 모두 이해하여야 할까?

데이터베이스만 해도 이렇게 많은 기술 스택을 가지고 있다면, 겉핥기식으로 기술들을 이해한다고 해도 오랜 시간이 걸릴 것이다. 차라리 그 시간에 문제 정의를 위한 학습을 더 하는 것이 나을 수 있겠다는 생각도 든다.

개인적으로 내린 결론은 '빠르게 지식을 배울 수 있는 흡수력'과 '리서치 능력'으로 기술 스택을 공부하는 것을 대신해야겠다는 생각이다. 위처럼 글을 분석해본 것도 해당 부분을 연습해보고 싶어서였다. 만약 앞선 글과 같이 검색 시스템에서 생긴 문제에 대한 문서를 이해할 수 있다면 분명 개발자와의 커뮤니케이션도 원활하게 수행할 수 있다. 그렇기 때문에 관련 지식을 빠르게 리서치하여 해당 기술 지식을 빠르게 흡수할 수 있는 능력이 있다면, PM으로서 커뮤니케이션에 참여할 수 있는 기본은 쌓을 수 있을 것이라 생각된다.

오늘 커뮤니케이션 역량 강화를 위해 토론 세션에서 각자 pm, 개발자, 디자이너로 역할을 맡아 가상의 회의를 해보았다. 토론 세션에서 저번에 배운 API의 URI, URL 개념을 알고 있었기에 주어진 문제의 해결 실마리를 간략하게나마 제시할 수 있었다. 즉, '아는 것만큼 보인다.' 고 문제 해결의 결정적인 역할은 하지 못해도 실마리라도 던질 능력을 갖추기 위해서는 최대한 많이 아는 것이 중요하다. 모든 지식을 다 쌓을 순 없지만 리서치 능력, 지식을 빠르게 흡수하는 능력을 강화하여 PM으로 커뮤니케이션 역량을 향상할 수 있을 것이다.

[PMB 8기] IT알못이 정리해본 API 개념과 예시

기획자킴제이 — Fri, 12 Nov 2021 23:24:43 +0900

과거 앱 개발에 참여했던 적이 있다. 지도 기능을 구축하던 때로 기억이 난다. 그때 '네이버 지도 api는 앱 내에서 00 기능을 구현할 수 있게 지원하는데 카카오 지도 API는 안돼서 네이버 쪽 API를 사용하려고요'라는 말을 개발자로부터 들었었다. 당시에는 API를 개발을 편하게 만들어주는 서비스 정도로 이해했었다.

어제 글을 쓰면서 앱의 유형을 나누다 보니 '하드웨어 플랫폼 API'에 접근할 수 있느냐에 없느냐에 따라 앱 유형이 나누어진다는 사실을 알게 되었다. 이 과정에서 API의 역할이 생각보다 광범위하고 많이 쓰인다는 사실을 알 수 있었다. 이러한 사실을 알게 되니 API가 정확히 무엇인지 엄청 궁금해졌다. 그래서 오늘은 API의 개념과 예시를 통해 API를 이해하는 시간을 가져보려고 한다.

API... 멀리서 보면 비극이요, 가까이서 보면 희극이다.

원론적인 API의 의미

API를 잘 모를 때는 뭔가 알 수 없는 용어들의 집합이기에, 어렵다는 생각이 막연하게 든다. 하지만 생각보다 어려운 개념은 아니며 간단한 예시를 통해 쉽게 이해할 수 있다.

예시를 들기 전에 API의 용어를 뜯어보려고 한다. API는 Application Programming Interface의 약자이다. 여기서 'Interface'라는 단어에 집중하면 API의 개념에 대한 힌트를 얻을 수 있다. Interface 어디서 많이 들어본 말이지 않은가? 그렇다! UI (User Interface)에서 찾아볼 수 있는 Interface와 같은 개념이다.

Interface의 사전적 정의. source: Cambridge Dictionary

위 사진에도 나와있지만 간단히 정리해보면 Interface는 두 개 이상의 사물, 사람, 상황에서 서로의 상호작용을 돕기 위한 연결 정도로 이해할 수 있다. UI는 User가 컴퓨터와 잘 상호작용할 수 있도록 제공하는 디자인 결과물이며, 키보드나 마우스도 컴퓨터와 사용자 간의 상호작용을 만들어 주는 사물 형식의 Interface라고 할 수 있다.

Source: 위시캣 블로그

이를 기반으로 API를 생각해보면 애플리케이션 프로그래밍에 사용되는 Interface를 총칭하는 말로 이해할 수 있으며, IT의 관점에서 보면 프로그램과 프로그램 사이에서 상호 작용을 돕는 매개체 정도로 이해할 수 있다. 예를 들어 웹 브라우저와 애플리케이션의 상호작용을 만드는 웹 API, 애플 생태계 앱들을 위한 IOS 개발 API, 카카오 지도를 다른 서비스에서 사용할 수 있게 해주는 API 등이 있다.

API의 대중적인 의미와 역할

IT 업계에서 주로 쓰는 API의 의미는 클라이언트와 서버 사이에서의 API를 말한다. (위 사진의 두 개의 프로그램이 클라이언트와 서버로 바뀌었다고 생각하면 쉽다.) 앱, 웹 프런트 엔드(front-end)에는 주로 여러 가지 데이터의 조회나 수정, 저장, 삭제 등을 요청할 수 있는 클라이언트가 있고, 백 엔드(back-end)에는 데이터를 저장하는 데이터 베이스와 이를 가공하여 전송하는 역할을 하는 서버가 있다.

비유를 들어 설명해보면, 손님(클라이언트)이 어떤 음식(정보, 기능)을 요청하면 서버(식당)는 식당 내에 있는 음식 저장고(DB)에서 음식(정보, 기능)을 꺼내 제공하는 것이다.

그렇다면 이런 클라이언트와 서버 사이에서 API는 어떤 역할을 하는 것일까? 앞선 설명처럼 상호작용을 위한 매개체 정도로 퉁쳐서 설명할 수 있지만 좀 더 자세히 알아보기 위해 한 가지 상황을 가정해보자.

만약 한 대식가 손님(클라이언트 A)이 수많은 음식(정보 a, b, c, d, e...)을 일주일 내내 매일 100번씩 주문한다면?

이런 상황에서 아마 식당(서버)은 제대로 된 음식(정보 B, 기능 B)을 제공할 수 없을 것이다. 식당(서버)은 대 혼란에 빠지게 되고 결국 식당이 파산 해버 리거나 영업을 닫아버릴 수도 있다. 이와 같이 식당(서버)이 제 역할을 못하는 상황을, 흔히 '서버가 터졌다'라고 말한다.

source:https://brunch.co.kr/@businessinsight

이러한 문제를 해결하기 위해 도입된 것이 API이다. API는 클라이언트와 서버 사이에서 요청과 응답을 주고받는 있는 체계나 규칙 정도로 이해할 수 있다. 위 그림처럼 요청하는 방법을 정해놓고, 요청에 대응할 부분(부서)을 미리 준비한다고 보면 된다. 이를 앞선 예시와 이어서 설명하면, 식당은 주문 방법을 미리 정해놔 주문 속도를 높이고, 음식을 준비하는 요리사를 사전에 여러 명 배치하는 것이다. 이러한 API는 앞서 말한 문제를 예방할 수 있어 시간과 정보 양에 구애받지 않고 클라이언트와 서버 사이의 상호작용을 원활하게 유지할 수 있다.

REST API

만약 API가 나만 아는 언어로 되어 있으면 어떻게 될까?

A 식당에서 자장면을 주문하기 위해선 '주세요/ 자장면'라고 말해야 된다고 생각해보자. A식당에 처음 온 고객이 '주라/자장면'이라고 말한다면 이는 같은 의미인데도 불구하고 A 식당에서는 주문을 받을 수 없다.

이렇듯 서로 다른 규칙들을 많은 API들이 가지고 있다면 전 세계 개발자들에게는 매우 비효율적일 것이다. 그래서 이를 통일하자는 약속이 바로 REST API(Representational State Transfer API)이며 REST 규칙에 따라 설계된 API들을 RESTful API라고 부른다.

source:https://brunch.co.kr/@businessinsight

정보를 요청하는 상황은 크게 Create, Read, Update, Delete가 있다. Restful API는 이에 맞춰 위 그림과 같은 명령어로 요청을 표현하고 응답 또한 간략하게 만들어서 응답한다.(우리가 흔히 보는 404 에러가 위의 Resoponse 부분의 400에 따라 나타난다.) REST API는 메서드, 파라미터, URI에 관하여 몇 가지 약속 기준을 가지고 있고 해당 부분에 대해 더 자세한 내용은 링크를 참고하는 것을 추천한다.

이렇게 알아본 API는 기업 내부 환경에서만 쓰는 Private API, 누구나 사용할 수 있게 공개되어 있는 Open API로 나뉠 수 있다. 우리가 흔히 보는 카카오 로그인이나, 페이스북 로그인 같은 API가 Open API이며 앱 개발 시 해당 API 문서를 기반으로 자체 앱 내에 기능을 구현할 수 있다.

또한 어떤 정보를 주고받느냐에 따라 종류가 나뉘기도 한다. 기능 API는 앞서 말한 카카오 로그인 API와 같이 특정한 기능을 제공하는 API를 말한다. 데이터 API에 경우 기상청 날씨 데이터와 같은 수집된 빅데이터를 활용할 수 있도록 데이터를 제공하는 API를 말한다. 마지막으로 하드웨어 API는 하드웨어(스마트폰, PC 등)에서 Application을 개발할 때 하드웨어의 특정 기능을 사용을 용이하도록 돕는 API를 말한다. 스마트 폰의 여러 센서나 카메라를 활용하여 앱을 제작할 때 사용할 수 있는 API이다.

우리 생활에서 가까이 있었던 API

네이버 페이 API 사용하는 화면

개인적으로 가장 친숙한 API가 무엇일까를 고민해보았다. 생각해보니 필자는 네이버 페이 하드 유저로 거의 모든 결제를 네이버 페이로 한다. 그래서 평소 방문했던 사이트들을 뒤적여 보았다.

브랜드가 강한 이커머스 쇼핑몰(오늘의 집 같은 성숙도가 높은 비즈니스)에 경우에는 'N pay 구매 버튼'을 볼 수 없지만, 아직 성장 단계에 있는 많은 쇼핑몰에 경우 자체적인 구매하기 버튼 아래에 위 그림과 같은 N pay 버튼이 구현되어 있는 것을 볼 수 있다. 이렇게 버튼이 구현되어 있지는 않은 경우라도 많은 서비스들의 간편 결제에서 네이버 페이로 결제하기를 지원하고 있다.

이번 연도 상반기 네이버 페이 결제액은 17조 7000억 원으로 작년 동기 대비 약 40%가량 상승했다고 한다. 우리나라에서 가장 많이 쓰는 간편 결제의 위상을 톡톡히 보여주고 있다. 어쩌면 네이버 Pay의 결제 API는 우리에게 가장 친숙한 API가 아닐까란 생각이다.

그렇다면 네이버 페이의 API는 어떤 기능을 제공하고 있을까?

네이버 페이 API가 제공하는 주요 기능

네이버 페이는 PG(Payment Gateway, 전자지급결제대행) 사의 프로그램에서, 혹은 웹사이트 구매하기 페이지 내의 간편 결제를 통해, 간편 결제를 지원하는 서비스이다. 크게 결제창 호출 - 결제 승인 - 결제 완료로 이루어지는 과정으로 이루어진다.

현재 네이버 페이 API는 크게 간편 결제 플랫폼과 정기 결제 플랫폼의 두 가지 경우에 맞춰 API를 제공하고 있다. 이 중 간편 결제 과정을 좀 더 살펴보면 다음 그림과 같은 구조로 기능이 호출되고 작동한다.

위 그림을 살펴보면 결제 화면을 호출한 후 네이버 페이로부터 결제 번호를 부여받고 해당 결제 기반을 기반으로 승인 요청 API를 활용하여 결제를 진행하고 있다. 결제승인 요청 API가 어떻게 진행되는지 한번 알아보자.

결제승인 요청 API 단계의 API 살펴보기

(아래는 전문 지식을 기반으로 하지 않고 기획자의 관점에서 살펴본 API에 대한 글이니 참고 시 주의를 요망합니다. )

결제승인 요청을 위한 코드

위 그림에서 볼 수 있듯이 요청은 POST라는 메서드(Method)를 통해 진행된다. POST는 해당 URL에 요청하면 리소스를 생성해주는 역할을 한다. 여기서 리소스란 말 그래도 자원을 말하는 것이며, API 상에서의 자원은 주고받는 정보 정도로 이해할 수 있다. 이러한 리소스는 URI로 특정 지을 수 있다. 마치 이름을 붙이는 것처럼 말이다. URL은 인터넷 상에서 자원의 위치를 확인하기 위한 문자열이고 URI는 자원을 식별하기 위한 문자열이다.

결제요청/승인 단계의 파라미터 정의

요청 코드의 예시를 보면 맨 아래에 PaymentId를 볼 수 있는데 해당 부분이 파라미터로 설정되어 있다. 이는 변수를 뜻하며 지속해서 바뀌는 값을 이야기하고, 위 그림에서 요청하는 정보를 말한다.

결제요청에 대한 승인 화면 예시

'POST'는 다른 API 메서드와는 다르게 body를 활용해서 정보를 요청, 응답한다. 여기서 body란 소포 같은 느낌으로 보면 된다. 정보를 전달하는 데에 있어 안정성과 보안성을 위해 전달하는 정보를 패키징하여 보내는 것이다. 위 그림은 Response 화면에 일부이다. 앞서 말한 것처럼 "body" 부분이 응답된 것을 볼 수 있다. 또한 "body" 안에 위에서 요청했던 파라미터 값인 PaymentId가 담겨있는 것을 확인할 수 있다.

맨 윗부분을 보면 "200 OK"라는 것을 볼 수 있다. 이는 응답에 대한 요청의 상태를 말하는 것으로 위 그림에서 볼 수 있는 가이드처럼 200 코드는 요청이 성공한 경우를 말한다.

Comment

어렵게만 느껴졌던 API를 자세히 알아보니 어느 정도 감을 잡을 수 있었다. 그래서 호기롭게 더 깊게 파고들면서 문서의 세부적인 내용과 메서드 등의 실제 사용방법까지 알아보기 시작했는데, 그 부분은 확실히 기획자 베이스의 나에게 무리였다. 그러다 보니 글의 하단부의 API를 실제로 하나하나 분석해보는 부분이 약간 부실한 감이 있다.

글을 다 쓰고 나니 그렇다면 PM은 API에 대해 어디까지 알아야 하나? 에 대한 고심이 생겼다. PMB 세션에서도 다른 동기들이 이와 관련한 많은 질문을 했다는 점을 보면, 아마 많은 기획자들이 공감할만한 주제라고 생각한다. 세션에서는 주니어 PM에 단계에서는 어차피 CTO나 개발 책임자에 의해 사용할 API의 설정과 도입이 이루어지기에 굳이 다 알 필요는 없다는 말을 들었다.

이와 관련한 고심 끝에 개인적으로는 능력이 되는 한 개발자 수준까지도 알아야 한다고 결론을 내렸다. PM은 서비스의 전체 과정을 총괄한다. 그렇기에 아는 지식이 많을수록 개발 스케쥴링에서 발생하는 병목에 관여해야 할 수도 있다. 이런 경우 단순히 맞춰주세요라고 요청하기보다 같이 그 문제에 원인을 고민하고 찾아본다면 좀 더 PM의 업무 성과를 높일 수 있을 것이라 생각하기 때문이다.

과거 앱 개발에 참여했을 때, 앱 내 버튼 아이콘 이미지가 깨져 보이는 현상이 발견되었던 적이 있다. 당시 우리는 대학생 수준의 팀이었기에 이 문제가 해결되지 않고 계속되었다. 필자는 신경 쓸 것이 많은 개발자를 대신하여 자료조사를 해보았고 거기서 발견한 인사이트(SVG 이미지에 대한 내용)를 개발자에게 건네주었다. 개발자는 이 자료를 기반으로 문제 해결에 실마리를 찾을 수 있었고 1시간 만에 쉽게 문제를 해결했던 적이 있다.

이처럼 넓게 아는 PM이 된다면 생각지도 못한 부분에서 같이 일하는 디자이너, 개발자에게 해결의 실마리를 던져줄 수 있다. 이러한 점을 고려한다면, 역시 PM은 제너럴리스트가 되어야 하고 앞서 말한 것처럼 능력과 시간이 되는 한에서는 최대한 많이 알 필요가 있다고 생각한다.

배달의 민족 CX 팀에서 오퍼레이터로 일하셨던 '천세희'님의 일화를 살펴보면 문제를 해결하기 위해 자신의 업무 영역을 넘어 백엔드 개발까지 참여하셨다는 이야기를 볼 수 있다. 이러한 사례를 보았을 때 역시 PM이 알아야 할 영역은 넓으면 넓을수록, 문제 해결에 도움이 될 수 있다는 생각이 든다.

[PMB 8기] 앱을 만들기 전 반드시 알아야할 Mobile App 유형

기획자킴제이 — Thu, 11 Nov 2021 23:55:00 +0900

약 10년 전 아이폰의 출시와 함께 열린 스마트폰 시대로 인해, 앱은 생활과 떼려야 뗄 수 없는 관계가 되었다. 우리들은 하루에도 수 십 번씩 앱을 사용하고 있으며 앱이 없는 상황은 상상하기도 힘들다.

이렇게 친숙한 앱은 어떤 모습을 하고 있을까? 깊게 생각해본 적이 없는 문제였다. 하지만 PM으로서 앞으로 서비스를 만드는 입장이라면 반드시 앱의 유형을 알아놓을 필요가 있다. 각 앱 유형마다 장점과 단점이 있고 이를 상황에 맞춰 적절히 적용했을 때, 서비스에 적합한 앱을 효율적으로 구축할 수 있기 때문이다.

또한 개발 리소스를 적절히 분배하고 일정을 조율하는 역할이 PM의 중심 업무란 점을 고려한다면, 앱 유형의 이해는 매우 중요한 주제이다. 이는 개발자와의 커뮤니케이션의 관점에서도 마찬가지일 것이다.

이러한 관점에서 오늘은 모바일 앱의 다양한 유형과 특장점을 살펴보고, PM으로서 어떤 기준으로 앱 유형을 선택해야 하는지 고민해보려고 한다.

모바일 웹(Mobile Web)

앱의 형태를 이해하기 위해 모바일 웹에 대한 이해가 필요하다. 모바일 웹은 말 그대로 모바일 환경(화면)에 최적화된 웹을 말한다. 작은 스마트폰 화면에 PC에서 보이는 웹 사이트를 본 경험은 누구나 한 번쯤은 있을 것이다. PC 화면에 맞춘 웹을 스마트폰에서 그대로 볼 경우 굉장히 불편하다. 이러한 문제에 대응하기 위해 모바일 환경에 최적화시킨 웹을 모바일 웹(Mobile Web)이라고 한다.

모바일 웹은 크게 적응형, 반응형으로 나뉜다.

웹 브라우저의 크기에 따라 자동으로 웹의 구성 요소의 크기와 구조가 변경되는 형태를 반응형 웹이라고 한다. 반대로 접속한 기기를 인식해 웹 구성 요소의 크기와 구조를 바꾸어 보여주는 방법을 적응형 웹이라고 한다. 후자에 경우 각 기기(PC, 스마트폰, 패드 등)의 화면 사이즈에 맞춰 보일 화면을 개별적으로 제작하며 전자는 하나의 웹 페이지가 화면 사이즈에 따라 자동으로 변환된다. 일반적으로 모바일로 웹을 접속했을 때 보이는 페이지를 생각하면 된다.

모바일 웹앱(Mobile WebAPP)

위의 모바일 웹처럼 브라우저를 통해 웹에 접속했을 때, 웹 페이지를 앱처럼 구현시켜놓은 일종의 '유사 앱'을 말한다. 앱 설치 과정이 없으며 웹 메일, E-commerce, 인터넷 게시판 등을 웹앱으로 구현하는 경우가 많다. 웹 기술 스택인 HTML, CSS, JS를 사용해서 만들어지며 브라우저 주소창이 존재하는 것이 특징이다.

장점

기본적으로 웹 기술이기 때문에 다양한 언어로 개발이 가능하다.
어떤 기기에서든 설치 없이 브라우저만으로 사용할 수 있다.
비교적 쉽게 개발할 수 있고 개발에 들어가는 시간과 비용도 적은 편이다.

단점

모바일 기기의 접근할 수 있는 권한이 없어 센서, 카메라 등의 하드웨어 기능을 활용할 수 없다.
애초에 웹이기에 모바일 환경 최적화가 힘들어 속도가 느릴 수 있다.

네이티브 앱(Native APP)

일반적으로 앱 스토어에서 설치해 사용하는 앱을 말한다. IOS, AOS로 대표되는 모바일 플랫폼 API를 이용해 개발된다. IOS는 대표적으로 Swift로 개발하며 AOS는 Kotlin라는 언어로 개발한다. 앱에서 생각할 수 있는 거의 모든 것을 구현할 수 있을 정도로 가장 높은 퍼포먼스를 보여준다. 모바일 하드웨어 기능 대부분을 사용할 수 있어 다양한 기능을 구현할 수 있는 것도 높은 퍼포먼스를 만드는 하나의 이유이다. 그에 따라 속도도 빠르다고 할 수 있다. 일반적으로 비즈니스 성숙도가 높은 기업에서 개발한다.

장점

생각하는 모든 기능을 구현할 수 있고, 하드웨어 기능을 사용한 앱을 만드는데 자유롭다.(ex. 캘린더, 주소록)
앱의 품질이 매우 높고 구동 속도가 매우 빠르다.
Native 플랫폼의 UI를 따르기 때문에 기존 경험과 비슷하거나 통일된 UX를 제공하기에 유리하다.

단점

개발 자원이 매우 많이 들어간다. IOS, AOS 개발자가 모두 필요하다.
같은 기능이라도 두 개의 언어로 개발해야 되기 때문에 최소 2배의 시간이 소요된다.
앱스토어 심사과정으로 개발이 지연될 수 있고, 이로 인하여 잦은 업데이트에 제약이 있다.

하이브리드 앱(Hybrid APP)

네이티브 앱의 단점(개발에 소요되는 비용이 큰 점)을 보완한 것에서 출발하여 웹앱의 장점(개발 비용이 적고 빠른 개발이 가능)을 수용한 것이 하이브리드 앱이다. 비교적 개발이 편리한 웹앱을 네이티브 형태로 제작하는 것이라 보면 된다. 예를 들면, 콘텐츠 영역은 웹앱을 기반으로 개발하되, 네이티브 앱처럼 포장하는 것처럼 개발하는 것이다. 그에 따라 앱스토어에서 다운을 받을 수도 있고 하드웨어의 기능도 일부 사용이 가능하다. 이러한 하이브리드 앱을 만들기 위해 웹 화면을 보여주는 웹뷰 기능을 사용하는데 PhoneGap, Cordova, Ionic 등의 프레임워크를 사용하여 구현한다.

장점

웹 개발을 기반으로 제작할 수 있어 네이티브 앱보다 개발 자원이 덜 소요된다.
네이티브 앱보다 비교적 짧은 시간 안에 제작할 수 있다.
웹앱보다 다양한 하드웨어 기능을 활용할 수 있다.

단점

네이티브 앱보다 속도가 느리다. 각각의 구성요소를 웹에서 불러오기 때문이다.
하드웨어 기능 중에서도 모든 기능을 자유롭게 사용할 수 있는 것은 아니다. 기능 사용에 제약이 있다.
앱 스토어를 통해 제공되기에 업데이트에도 제약이 있다.

모바일 웹, 웹앱, 하이브리드 앱, 네이티브 앱의 예시

(좌) 모바일 웹, (중) 웹앱, (우) 하이브리드 앱 or 네이티브 앱

최근 웹앱의 정의는 보통 모바일 브라우저 환경에서 앱과 같은 기능을 구현한 것을 말한다. 하지만 전통적으로, 앱 개발이 어려웠을 과거에는 모바일 웹에서 '바탕화면에 추가하기'를 했을 때 모바일 브라우저 켜지는 것이 아니라 앱처럼 구동되는 것을 일컬었다. 바탕화면에 추가했을 경우 인스타그램은 중간 사진에서 볼 수 있듯이 앱처럼 구동되며 URL은 존재하나 주소창이 보이지 않는 것을 확인할 수 있다.

가장 오른쪽 사진은 인스타그램 앱의 화면이다. 가운데 버튼이 릴스 버튼으로 바뀐 점, 사진 추가나 찍기 기능이 바로 연결된다는 점에서 좌측의 모바일 웹, 웹앱과의 큰 차이를 보여준다. 또한 다크 모드가 설정되어 있는 디바이스의 설정을 자동으로 로드하는 것을 보아 하이브리드 앱이나 네이티브 앱으로 볼 수 있다. (하이브리드 앱이나 네이티브 앱 모두 디바이스 기능에 접근할 수 있기 때문에 두 가지를 구별하는 것은 쉽지 않다.)

하이브리드 앱과 네이티브 앱을 좀 더 구별하기 위해 더 많은 예시를 찾아보았다. 몇 가지 아티클을 읽어본 결과 하이브리드 앱은 기본적으로 '웹뷰' 형식을 사용하기 때문에 모바일 웹이나, 웹앱에서 보이는 페이지(화면)를 그대로 불러온다는 것을 알 수 있었다.

(좌) CGV, 모바일 앱과 하이브리드 앱 / (우) Naver, 모바일 웹과 네이티브 앱

CGV와 Naver의 모바일 웹과 앱 화면을 비교하면서 네이티브 앱과 하이브리드 앱의 차이를 추측해볼 수 있었다. 좌측의 CGV에 경우 모바일 웹, 혹은 웹앱에서 보이는 화면을 그대로 앱 화면에서 보여준다. 반면 Naver에 경우 모바일 웹, 혹은 웹앱에서 보이는 화면이 그대로 로드되지 않고 다른 화면과 기능이 노출되는 것을 확인할 수 있다.

인스타그램에 경우 해외 개발자들 사이에서도 네이티브 앱인지 하이브리드 앱인지에 대한 논쟁이 있다고 한다. 앱을 제대로 까 보지 않았기에 확실한 구별이 어렵지만 '웹뷰' 기능의 차이를 통해 위 사진처럼 하이브리드 앱과 네이티브 앱의 차이를 추측해볼 수 있다.

크로스 플랫폼 앱(Cross-Platform APP)

하나의 프로그래밍 언어로 IOS, AOS 두 운영체제에서 동시에 동작하는 앱을 개발한 것을 말한다. 페이스북에서 개발한 React Native, 구글에서 만든 Flutter 언어가 가장 대표적이다. 최근 하이브리드 앱의 대안으로 떠오르고 있으며, 네이티브 앱을 제작하기 버거운 스타트업에서 많이 사용한다. 이는 크로스 플랫폼 앱이 네이티브 앱보다 개발 비용이 적게 드는 반면에, 하이브리드 앱보다 하드웨어 기능 사용에 있어 용이하다는 장점 때문이다. 최근 많은 개발자들이 유입되어 React Native, Flutter 커뮤니티가 확장되는 등, 관심이 매우 커지고 있다.

위의 내용을 보았을 때는 정말 좋은 앱 형태로 보이지만, 비즈니스의 성숙도가 높은 서비스에 경우 크로스 플랫폼 앱의 사용을 점차적으로 줄이고 네이티브 앱으로 전환하는 경향을 보인다고 한다. 이는 완벽하게 네이티브 앱만큼의 퍼포먼스를 보여주기 어렵기 때문이다. 크로스 플랫폼 앱이 네이티브 앱에 거의 근접한다고 해도, 1%의 기능 적 차이가 수백만이 사용하는 앱에서는 치명적일 수 있다. 에어비앤비가 크로스 플랫폼으로 개발을 시도했다가 다시 네이티브 앱으로 돌아간 사례가 대표적이다. (참조링크)

장점

한 번에 두 플랫폼의 앱을 개발할 수 있어 네이티브 앱보다 자원적 소모가 적다.
하드웨어 기능을 사용하는 것에 있어 하이브리드 앱보다 제약이 적다.

단점

하드웨어 기능 사용에 제약이 거의 없지만 네이티브 앱만큼은 아니다.
네이티브 앱보다 퍼포먼스가 떨어진다. 거의 근접한 성능을 보여주지만 아무래도 완벽한 네이티브 앱의 룩앤필을 만들지 못한다.
한 가지 언어, 프레임워크에 종속되어 있기에 프레임워크 단의 오류가 나타나면 대처가 힘들다.

그렇다면 PM으로서 어떤 기준으로 앱의 형태를 결정해야 할까?

1. 서비스 개발에 있어서 소요되는 자원을 고려해야 한다.

앱을 만드는 상황과 환경에 있어 대부분의 경우 자원이 한정적이다. 가장 기본적으로 정해진 예산이 있을 것이고, 개발 시간, 소요되는 인력 등이 이러한 자원이라고 볼 수 있다. 만약 서비스를 구축하는 중인 스타트업에 경우 처음부터 네이티브 앱을 만들려고 한다면 제한된 자원이라는 '큰 벽'에 부딪치게 된다. IOS 개발자와 AOS 개발자를 모두 채용해야 하고, 매출이 없음에도 긴 시간 동안 앱 제작에 매달려야 한다. 만약 솔루션을 검증하는 단계라면 검증 사이클을 반복하는 것이 힘들 것이다.

2. 서비스, 솔루션의 단계에 따라 앱의 형태를 고려해야 한다.

앞서 말한 것과 같이 스타트업은 개발하는 솔루션을 검증해야 한다. 이러한 검증에서 가장 중요한 것은 빠른 반복이다. 가설을 기반으로 기능을 설계하고 소비자에게 배포하여 검증하는 과정을 여러 번 반복해야 하는 것이다. 이를 위해서는 빠른 개발 환경, 용이한 업데이트, 최소의 자원 등이 필수 불가결하다. 만약 스타트업이라면 상대적으로 가장 자원이 적게 드는 하이브리드 앱이나, 크로스 플랫폼 앱 등을 기반으로 앱을 개발하여야 한다.

3. 앱 서비스의 유형을 고려해야 한다.

Azar는 한국에서 만들어진 영상 채팅 기반 데이팅 앱이다. 실시간으로 서로의 모습을 보며 대화할 수 있는 특징이 있다.

(이 서비스는 2021년 2월 틴더를 운영 중인 매치 그룹에게 1조 9000억 원에 인수되었다.)

실시간으로 카메라의 기능을 활용해야 하고, 위치를 기반으로 상대가 매칭 되기 때문에 위치추적 기능이 계속 활성화되어야 한다. 이렇게 하드웨어적 기능이 돋보이는 앱에 경우 네이티브 앱이 아니라면 높은 퍼포먼스를 만들기 어렵다. 아자르에 사례처럼 하드웨어의 특정 기능을 중점적으로 활용하는 앱들은 반드시 네이티브 앱으로 개발하여야 한다.

4. 고객의 행동이나 퍼널 상의 특징을 고려해야 한다.

필자는 과거 스타트업에 일하면서 앱을 출시한 적이 있다. 당시 웹앱 형태로 앱을 제작했었는데, 푸시 알림 등 기능적인 제약이 있어 하이브리드 앱이나 네이티브 앱으로의 전환을 고려한 적이 있다. 하지만 우리는 결국 웹앱의 형태를 고수할 수밖에 없었다. 왜냐하면 앱 유입 고객의 90%가 SNS의 링크를 통해 유입되었기 때문이다.

만약 하이브리드 앱으로 전환하였다면 앱 다운로드 과정이 고개 여정 상에 추가되었을 것이고, 일반적으로 앱 설치에 까다로운 소비자들은 일부 이탈할 수밖에 없다. 당시에 유저 한 명 한 명의 유입이 소중했고, SNS를 통해 마케팅 방법을 바꿀 수 없었기에 웹앱 형태를 지속해야 했다. 이처럼 고객이 보이는 특정한 행동이나 퍼널 상의 데이터를 기반으로도 앱의 형태를 선택하는 기준을 만들 수 있다.

Comment

앱의 형태를 정리하면서 느낀 점은 결국 앱 유형이 다변화된 과정 또한 문제를 해결하는 과정이었다는 것이다. 웹 개발 언어인 HTML, CSS, JS가 각각의 한계를 넘어서기 위해 개발된 것처럼 웹앱, 하이브리드 앱, 크로스 플랫폼 앱 또한 네이티브 앱과 각각의 형태의 한계를 극복하기 위해 개발되었다는 것을 알 수 있었다.

오늘 가장 의문이었던 것은 '웹과 앱에서 실시간 정보를 동시에 보여준다면 네이티브 앱과 하이브리드 앱 중 어떤 것이 더 유용할 것인지'와 '크로스 플랫폼 앱은 하이브리드 앱인가?'이다. 해당 궁금증에 대한 답은 아직 찾지 못했지만 기회가 된다면 해당 주제로 꼭 포스팅을 진행하고 싶다.

[PMB 8기] HTML,CSS, JS 까지 with 쿠팡플레이의 랜딩페이지

기획자킴제이 — Wed, 10 Nov 2021 22:10:46 +0900

우리는 하루에도 수십 번 새로운 웹 페이지를 열어본다. 일상과 같은 당연해 보이는 이 페이지들은 사실 복잡한 언어들이 상호작용하며 만들어 낸 결과물이다. 그중 가장 대중적으로, 그리고 기본적으로 쓰이는 언어들이 HTML, CSS, JavaScript(이하 JS)이다.

위 그림에서 간략히 볼 수 있듯이 HTML은 웹 페이지의 뼈대 역할을 한다. CSS는 그 뼈대에 옷을 입히고, JS는 옷을 입힌 것에 더해 움직임을 만들어준다. 좀 더 자세하게 정의와 역할을 알아보면 다음과 같다.

HTML(Hyper Text Markup Language)

웹 문서를 만들기 위해 사용하는 가장 기본적인 웹 언어의 한 종류.
웹 페이지 내에서 제목, 이미지, 문단, 표 등 다양한 요소들의 자리를 결정하고 영역을 나누어 주는 역할.
즉, 웹의 구조 설계를 담당.

CSS(Cascading Style Sheets)

마크업 언어(앞서 언급한 HTML, XML 등)가 실제로 어떻게 표현될지를 결정.
색상, 레이아웃, 폰트, 이미지 크기 등을 지정하여 다양한 요소의 스타일을 입히는 역할.
즉, 웹 페이지의 시각적인 표현을 담당.

JS(JavaScript)

앞서 이야기한 HTML은 정적 언어로, 실시간으로 변화하는 것을 만들어내지 못하여 해당 문제를 해결하기 위해 등장한 언어.
페이지 내의 여러 요소들에게 동적인 움직임을 부여하여 페이지를 인터렉티브 하게 꾸며주는 역할.
즉, 웹의 동적 처리를 담당.

프론트엔드의 기본인 3개의 언어를 알아보면서 실제로 어떻게 적용되고 작성되었는지 궁금해졌다. 그래서 복잡한 웹 서비스 페이지가 아닌 간단한 랜딩 페이지에서 HTML, CSS, JS가 어떻게 적용되고 구현되는지 알아보려고 한다.

1. 쿠팡플레이 & 선정 이유

쿠팡 플레이는 쿠팡에서 최근 서비스하고 있는 OTT 서비스이다. 2020년 7월 싱가포르의 OTT 서비스인 훅(HOOQ)을 인수했다는 소식이 있었는데, 그 해 12월 24일 국내 OTT 서비스 중에는 후발주자로 서비스를 시작했다.

주요한 특징으로는 싱가포르 OTT 서비스를 기반으로 해서인지 해외 영화 콘텐츠가 많은 편이다. 또한 스포츠 생중계가 특징인데 유럽 프리미어 리그 중계, 미국 NFL 중계 등으로 소비자들의 호응을 얻고 있다. 무엇보다 월 2,900이면 가입할 수 있는 쿠팡 와우 회원이라면 누구나 사용할 수 있어 가성비가 매우 좋은 편이다. 최근에는 국내 유명 코미디 TV show인 SNL을 독점 방송하며 이슈가 되기도 하였다.

아직 부족한 콘텐츠라는 단점이 있지만 극강의 가성비 등으로 점차 시장 점유율을 높여갈 것으로 보인다.

HTML, CSS, JS를 기준으로 분석해볼 랜딩 페이지를 찾기 위해 여러 페이지들을 둘러보았다. 서비스를 시작한 지 얼마 안 된 스타트업이나 앱 환경에 집중된 서비스를 제공하는 경우, 랜딩 페이지의 코드가 너무 복잡하여 분석이 쉽지 않았다. 이러한 현상은 대기업일수록 적었는데, 서비스 규모가 큰 기업들의 랜딩 페이지는 대부분 간결하고 이해하기 쉬웠다. 쿠팡 플레이의 랜딩 페이지 또한 구조화가 잘 되어 있었다.

개발자 수준의 전문 지식이 없는 필자에게는 쿠팡 플레이를 통해 3가지 언어의 개념과 구현 과정을 살펴보는 것이 가장 나은 선택지라 생각되어 쿠팡 플레이의 랜딩페이지를 분석 주제로 선택하게 되었다. ~~(최근 쿠팡 와우를 구독한 것도 결정에 큰 영향을 미쳤다..)~~

2. 쿠팡 플레이 랜딩페이지의 HTML 구조

(좌)기본적인 HTML 문법구조, (우)Body 영역 안에서 주로 볼 수 있는 콘텐츠 구조

HTML를 활용한 일반적인 구조는 위 그림과 같다. 왼쪽 그림은 HTML의 기본적인 문법구조를 설명한 것이다. Body 영역이 실제 우리에게 보이는 영역이며 해당 영역을 자세히 설명하면 오른쪽 그림과 같다. < > 안에 있는 이름을 시멘틱 태그라고 하며 해당 태그를 사용해서 영역을 지정할 수 있다. 글의 목적성을 고려하여 더 자세한 문법과 태그 사용법은 다른 글에서 다뤄볼 예정이다.

그렇다면 쿠팡 플레이 랜딩 페이지에서 보이는 부분, 즉 Body의 구조는 어떻게 설정되었는지 확인해보자.

개발자 도구로 살펴본 쿠팡 플레이 랜딩페이지의 HTML

<body> 영역을 보면 <div>(각 콘텐츠를 분할하여 구조를 설정하는 용도)를 사용해서 각 콘텐츠를 나누고 있다. class(요소에 대한 이름 정하는 용도)로 콘텐츠 대부분을 'PreLogin_00000'로 정의하고 있으며 그 뒤에 각 부분의 이름을 headBackground, section 1, section 2, section 3... 등으로 보여주어 해당 부분의 용도를 짐작할 수 있다. 이를 바탕으로 body 영역은 전체를 감싸는 Container와 4개의 section 그리고 Footer로 이루어진 점을 알 수 있다. 이를 실제 랜딩페이지 화면에서 구분해보면 다음과 같다.

실제 랜딩페이지 영역을 구분해 본 결과

<footer> 영역이 상당히 크고 <header> 보이지 않는다는 특징이 있었다.

3. 쿠팡 플레이 랜딩 페이지의 중심 CSS 스타일

CSS은 보이는 영역의 디자인적 요소를 결정한다. 쿠팡 플레이 랜딩 페이지에서 가장 눈에 띄는 디자인 요소는 배경색과 폰트 그리고 이미지다. 배경색이 검은색으로 보이는데 어떤 Hex 색상 코드를 가지고 있는지, 폰트는 맑은 고딕인지 등 몇 가지 궁금점이 생겼다. 해당 궁금점에 대한 답을 찾아보면서 CSS를 파헤쳐보자.

1) 배경색은 실제 어떤 색일까? Hex 색상 코드 알아보기

배경색을 실제로 알아보기 위해 HTML 상 body 부분의 CSS를 살펴보았다. background 부분에서 배경색이 #000, 즉 검은색인 점을 확인할 수 있었다.

또한 위의 사진처럼 'font-family'라는 문법을 확인할 수 있었는데, 이는 페이지 내의 쓰이는 모든 폰트를 정해놓은 것이다. font-family 속성 값이 여러 개의 글꼴로 설정되어 있으면, 웹 브라우저는 맨 앞에서부터 순서대로 폰트를 읽는다. 예를 들어 사용자의 컴퓨터에 첫 번째로 읽어 들인 글꼴이 없으면 다음 글꼴을 확인하게 되는 것이다. 모든 폰트가 없을 경우를 대비해 마지막 폰트는 어떤 시스템에도 호환이 가능할 generic-font를 작성해야 한다. 이 'font-family' 부분을 통해 body에서 사용될 수 있는 모든 폰트를 확인할 수 있었다.

2) Section 1에 쓰인 폰트는??

section1 영역

각각의 폰트를 모두 찾아볼 순 없어 가장 메인 카피가 쓰인 section 1(위 사진) 영역의 폰트를 찾아보려고 한다.

'와우 회원이라면 모든 콘텐츠 무료!'라는 카피는 h1 태그에 들어있다. 해당 부분의 style을 찾아보았지만 폰트의 유형을 찾을 수 없었다. 자료 조사를 하다 보니 CSS는 상속이라는 개념이 있다는 것을 알 수 있었는데, (CSS의 원문인 Cascading이 상속, 흐름을 뜻하는 말이라고 한다.) 위 사진의 하단 부를 보면 Inherited from이 적혀있는 것을 볼 수 있다. 즉, '와우 회원이라면 모든 콘텐츠 무료!'가 속해 있는 h1 태그의 폰트는 은 h1이 속해있는 section.PreLogin_section 1 ~~ 에서 지정된 폰트가 상속되어 지정된다는 것을 알 수 있었다.

사실 더 쉬운 방법으로 '검색' 기능을 누르고 원하는 부분에 마우스 오버를 하면 해당 부분에 적용된 CSS 결과를 훨씬 쉽게 찾을 수 있다. 위의 사진은 실제로 코드가 어떻게 쓰였는지에 대한 호기심으로 찾아보았다.

4. 쿠팡 플레이 랜딩페이지에서 쓰인 JS

footer 부분에서 쓰인 JS

쿠팡 플레이 랜딩페이지에는 footer 부분의 '자주 묻는 질문'에서 유일하게 JS를 이용한 인터렉티브 디자인이 적용되었다. 해당 기능은 어떻게 구현되는 것일까? 이에 대한 답을 찾기 위해 개발자 도구를 열심 뒤적여보았지만, JS 코드는 HTML과 CSS 코드와는 다르게 찾기가 매우 어려웠다.

크롬 개발자도구에서 JS 코드를 찾는 과정

겨우 방법을 찾을 수 있었는데, 개발자들이 크롬 개발자 도구를 통해 디버깅하는 과정을 활용하여 JS 코드를 찾을 수 있었다.(위 영상 참고)

해당 과정을 서술하면 다음과 같다.

1. 먼저 JS 코드가 걸려있을 element를 선택한다. '자주 묻는 질문'에서 아래 화살표 아이콘뿐만 아니라 해당 박스를 선택해도 답변이 노출되는 것을 확인했기 때문에 header로 정의된 element를 선택하였다.

2. Style을 볼 수 있는 창 옆을 보면 Event Listener 탭을 확인할 수 있다. 해당 탭을 들어가 보니 Click이라는 이벤트가 있었고, '자주 묻는 질문'을 클릭했을 때 창이 생성되고 사라지는 것을 보아 해당 이벤트가 맞다고 추측할 수 있었다.

3. Click 이벤트를 열어 링크로 연결된 JS 문서를 열어 보았다.

4. 알아볼 수 없는 화면이 나오는데 하단 부분에 있는 {} 아이콘 (전송하기 쉽도록 단순화된 JS 코드를 원래대로 보여주는 기능)을 눌러 코드를 확인해볼 수 있었다.

코드를 직접 확인해보았지만 나의 개발 이해도로는 해석이 불가능했고, 디버깅 기능을 사용해보려 했지만 정상적으로 작동하지 않아 해당 JS 코드가 '자주 묻는 질문'의 인터렉티브를 만드는지는 검증하지 못했다. 아쉽지만 다음 기회에 개발 공부를 더해보고 해당 기능을 검증에 도전해볼 생각이다.

Comment

그나마 단순한 웹 페이지이었기에 과제를 완료할 수 있었다. 만약 네이버 메인과 같은 포털 사이트였다면 과제를 끝마치지 못했을 것이란 생각이 든다. 과제를 하면서 초기 서비스의 웹 페이지는 HTML 문서 안 내용이 체계 없이 뒤죽박죽인 점을 확인할 수 있었다. 개발자 친구에게 조언을 구하니 '모로 가도 서울로만 가면 된다'고 실제로 많은 곳에서 제멋대로인 코드로 기능을 구현한다고 한다. (또 어떻게 구현은 된다고...;;) 친구에 따르면 개발 체계가 확실한 기업일수록 정리된 코드가 작성된다고 하며 이러한 과정을 리팩토링이라고 부른다고 한다.

만약 내가 PM이 되어서 개발자와 소통한다고 하였을 때 코드를 따로 읽을 일은 없겠지만 그래도 기본적인 코드를 읽을 수 있다면 분명 개발자와의 소통이 훨씬 효율적일 것이다. 생각해보라. 만약 내가 HTML의 footer 개념도 모른다면 개발자는 앞이 깜깜할 것이다. 그나마 과제를 통해 내가 배워야 할 수준이 어느 정도이고 소통을 위해서 어떻게 학습해야 하는지 가닥을 잡을 수 있었기에 다행이다.

[PMB 8기] Kaggle Data로 알아본 Fitness Tracker 시장 인사이트

기획자킴제이 — Wed, 10 Nov 2021 01:29:57 +0900

Kaggle은 2010년 설립된 빅데이터 솔루션 대회 플랫폼이다. 다양한 주제에 대한 대회가 열리면 데이터 관련 전문가부터 학생까지 많은 사람들이 참여하여 솔루션을 제시하는 곳이다. 빅데이터의 관심이 높아지면서 폭발적으로 성장하였고 2017년에는 구글에 인수되었다.

Kaggle에서는 다양한 주제의 Dataset(데이터 원본)을 다운로드할 수 있는데, 수많은 Dataset 중에 피트니스 트래커에 대한 자료를 찾을 수 있었다. Dataset에 경우 방대한 양의 행과 열로 데이터가 정리되어 있다. 이를 쉽게 보기 위해서는 가설과 해석에 기반한 데이터 시각화가 중요하다. 오늘은 피트니스 트래커 관련 Dataset을 주제로 데이터 시각화에 도전해보려고 한다.

시장 현황에 기반한 가설 설정과 검증

최근 주위를 둘러보면 애플 워치를 차고 다니는 사람들을 쉽게 볼 수 있다. 몇 년 전만 해도 스마트 워치를 이용하는 사람들을 찾기 어려웠던 것에 비하면 놀라운 변화라고 할 수 있다. 스마트워치뿐만이 아니다. Fitness tracker(이하. 피트니스 트래커)의 확산도 놀랍다. 많은 운동인들이 샤오미, Fitbit, Garmin 등 다양한 피트니스 트래커들을 활용하고 있다.

피트니스 트래커만을 제공하는 기기도 있지만, 대부분의 스마트워치가 피트니스 트래킹을 지원하기 때문에, 현재 피트니스 트래커 시장은 스마트워치 시장과 혼재된 상황이다. 아래 그림에서 볼 수 있듯이 스마트 워치가 피트니스 트래커 기기 중 가장 많은 부분을 차지하고 있다.

피트니스 트래커 시장 현황

아래 그림에서 볼 수 있듯이 2021년을 기준으로 스마트 워치 시장은 애플이 압도적인 점유율을 자랑하고 있다. 시장의 점유율을 많이 가져간다는 것은 해당 브랜드 제품의 효용성이 뛰어나고 큰 만족감을 주기 때문이라고 볼 수 있다.

이러한 추측을 기반으로 한 가지 가설을 세워보았다.

가설 1: 애플 제품은 피트니스 트래커 시장 내 제품들 중 가장 높은 만족감을 보여줄 것이다.

피트니스 트래커 시장 관련 Dataset

실제 데이터 값을 통해 위 가설을 검증해보기 위해 Dataset을 열어보았다. 해당 Dataset은 아래 표와 같은 항목에 대한 내용을 보여준다.

브랜드 이름, 디바이스 유형, 모델 이름, 색, 판매 가격, 고유 가격, 디스플레이 유형, 평가, 스트랩 유형, 평균 배터리 시간, 리뷰 수

이 중 리뷰 수는 누락된 항목이 많고, 색에 경우 한 개의 셀에 여러 가지 중복 값이 있기에 삭제하여 분석의 편의성을 높였다. 만족도를 찾아보기 위해 Dataset을 살펴보니 위 그림처럼 브랜드 당 여러 모델의 값들이 모두 제공되고 있어 애플 브랜드만의 평가(Rating)를 확인하기 어려웠다. 그래서 피벗테이블과 그래프 시각화를 활용하여 애플 제품들을 기준으로 한 평가(Rating)의 중윗값을 구해보았다.

가설1을 검증하기 위한 데이터 시각화: 브랜드 별 평균 만족도 값

Dataset을 그래프로 시각화해보니 애플의 만족도가 가장 높은 것을 알 수 있다. 그러므로 가설 1은 검증된 사실로 볼 수 있으며, 애플 제품의 높은 만족도가 시장 점유율 확장에 중요한 요인임을 확인할 수 있다.

애플은 보통 높은 비싼 가격으로 인식된다. 그럼에도 불구하고 높은 만족도를 보여주고 있다. 여기서 한 가지 가설을 더 세워 볼 수 있었다. 가격이 높은 것이 만족도에 영향을 줄 수 있는가이다. 일반적으로는 낮은 가격과 높은 효용을 보여준다면 만족도가 높지만 피트니스 트래커 시장만의 특이점이 있는지 궁금해졌다. 해당 부분을 알 수 있다면 시장 Penetration 전략을 짜는 데에도 유용할 것이다. 이러한 점을 고려하여 가설을 설정하면 다음과 같다.

가설 2: 피트니스 트래커 시장에서 가격과 만족도는 비례한다.

해당 가설을 검증하기 위해 가설 1 검증과정에서 도출된 만족도가 높은 상위 10개 브랜드를 대상으로 가격 분포도를 다음과 같이 만들어 보았다.

가설2를 검증하기 위한 데이터 시각화: 제품 가격에 따른 만족도 분포

해당 분포도를 보면 우측으로 갈수록 분포 값이 많아지는 것을 확인할 수 있다. 완벽한 비례 관계는 아니지만 대략적으로 가격과 만족도는 비례함을 알 수 있다. 그렇기에 가설 2 또한 검증된 사실로 볼 수 있다.

가설 2를 검증하는 과정에서 가격이 높을수록 만족도 높아진다는 '상관관계'를 찾을 수 있었다. (분명 브랜드 이미지, 성능 등을 고려하지 않았기 때문에 적절한 분석인지는 다시 재고할 필요가 있다.) 그럼에도 불구하고 가설 2에 근거하여 피트니스 트래커 시장에 진입한다고 가정하였을 때 가격과 만족도는 비례한다는 점을 활용하여 Pricing 전략을 세울 수 있을 것이다. 가령 제품 가격의 중윗값을 찾고 이보다 높은 시장 가격을 설정하는 것이다.

그렇다면 만족도에 영향을 미칠 다른 요소는 없을까? 피트니스 트래커의 특성상 운동을 하면서 사용하기에 스트랩의 유형이 중요할 것으로 보인다. 운동 중 땀에 영향으로 스트랩이 상하거나, 불편함을 느낄 수 있기 때문이다. 그렇다면 어떤 스트랩이 가장 큰 만족도를 줄 수 있을까?

개인적인 경험에 기반했을 때 땀에는 Rubber, 즉 고무 재질의 스트랩이 가장 편했었다. 개인적인 경험을 기반으로 다음과 같은 가설을 세워보았다.

가설 3: Rubber(고무) 재질의 스트랩을 사용했을 때의 만족도가 가장 높을 것이다.

가설을 검증하기 위해 스트랩 종류를 기반으로 만족도의 중윗값을 도출해보았다. 이에 대한 결과는 다음과 같다.

가설3을 검증하기 위한 데이터 시각화 : 스트랩 유형에 따른 만족도 평균값

가설 3에서 생각했던 것과는 다르게 Rubber(고무) 재질의 스트랩은 가장 낮은 만족도 평균값을 보여준다. 예상과는 전혀 다른 결과다. 해당 이유에 대한 근거를 찾아보기 위해 뉴스 자료 등을 찾아보았으나 아쉽게도 찾지 못했다.

시각화 과정을 되짚어보며 결과에 대한 이유를 추적해보았다. 앞서 만족도가 가장 높았던 애플 브랜드 제품의 대부분의 Strap 유형이 알루미늄이라는 점을 알 수 있었는데, 이에 따라 알루미늄의 만족도가 높게 나온 것이었다. 이러한 검증 오류를 방지하기 위해서 같은 브랜드 제품 내에서 Strap 유형에 따른 만족도를 측정할 필요가 있어 보인다.

즉, 만족도라는 값에 영향을 미치는 다른 요인들은 제거한 상태에서 데이터 분석이 필요한 것이다.

아쉽게도 애플 제품의 데이터는 4종류의 스트랩만을 보여주고 있다. 일반적으로 Stainless Steel의 가격이 가장 비싸지만 현재 Dataset은 피트니스 트래커 시장의 데이터이기에, 즉 운동 중 사용경험에 초점이 맞춰져 있기에 Silicone 재질의 Strap에 대한 만족도가 높다는 것을 알 수 있었다.

가설을 설정하고 검증해본 결과 가설 1, 2는 검증할 수 있었고 가설 3은 검증에 실패하였다. 결론적으로 피트니스 트래커 시장에서는 제품 가격이 높을수록 만족도가 높은 '경향성'을 보이고 애플 제품의 만족도가 가장 높다. 특히 Silicone 재질의 Strap이 만족도를 높이는 데에 연관이 있을 수 있다로 정리할 수 있다.

Commnet

Dataset을 기반으로 데이터 시각화를 연습해보면서 가장 어려웠던 것은 가설의 설정과 검증이었다. 단순한 대조만으로 인사이트를 얻을 수 있을 것이란 생각과 다르게, 위에 검증한 가설들 대부분은 '상관관계'만을 보여줄 뿐, 인과관계를 나타내지 않았다.

지난 세션에서 A/B test를 학습하며 변인의 통제가 매우 중요함을 배웠다. 데이터 분석도 마찬가지로 통제된 변인을 활용하는 것이 중요할 것으로 보이며, 단순 상관관계를 인과관계까지 이끌어 낼 수 있는 조건을 설정하는 것이 매우 중요하다고 생각한다.

[PMB 8기] '린 분석'의 관점에서 본 'Peaches'

기획자킴제이 — Mon, 8 Nov 2021 09:39:28 +0900

Supreme라는 단어를 아는가?

'최고의(ultimate), 최상의(greatest)'라는 의미를 지니고 있는 이 단어는 세계 최고의 스트릿 패션 브랜드의 이름이다. 1994년 영국계 미국인 제임스 제비아가 미국 뉴욕에서 만든 이 브랜드는 스케이팅 문화를 기반으로 만들어졌다. 세계 최고라는 이름에 걸맞게 최근에는 루이비통, 나이키 등의 세계 유명 브랜드와 협업을 지속하고 있고 수많은 래퍼, 셀러브리티들의 워너비 아이템으로 여겨지고 있다.

초기 슈프림은 모델 '케이트 모스'가 찍은 켈빈클라인 광고에 '슈프림 박스 로고 스티커'를 붙이는 일 하나로 젊은 스케이트 보더들에게 강한 인상을 주며 시작했다. 모든 판매되는 제품들은 한정판이기에 소수만 살 수 있었다. 반항적인 모습 때문이었을까? 한정판만 판매하는 모습 때문이었을까? 인스타그램도 페이스북도 없었던 당시에 수많은 스케이트 보더들에게 알려지게 되었고 광적인 호응을 얻는 브랜드로 성장하게 된다. 당시에 스케이트 보더를 기반으로 한 스트릿 씬의 래퍼, 힙스터들에게는 종교급의 브랜드가 된 것이다.

스티커, 한정판 등 슈프림과 비슷한 행보를 걸으며 점차 종교급의 브랜드로 성장하고 있는 토종 한국 브랜드가 있다면 믿겠는가? 오늘 이야기할 주제이기도 한 이 브랜드가 바로 Peaches이다.

피치스 로고

Peaches는 '자동차 튜닝 문화'에 기반을 둔 패션 브랜드이다. 슈프림이 스케이트 보딩 문화를 대변한다면 Peaches는 자동차 튜닝 문화를 대변하는 브랜드이다. Peaches는 자동차의 뒤태를 의미하는 속어인데, 복숭아가 예쁜 엉덩이를 의미하는 것처럼 Peaches도 이러한 의미를 담고 있다.

우리나라보단 미국이 자동차 튜닝 문화가 더 활발한 편이다. 그래서 Peaches도 자동차와 스트리트 문화의 본거지인 LA에서 시작했다. 슈프림처럼 스티커를 배포하며 시작한 Peaches는, 단기간 내에 해외 팬들의 호응을 얻어냈고 폭발적인 성장을 하고 있다. 이러한 성장은 세계 유수의 기업들 과의 컬래버레이션으로도 알 수 있다. 2018년 나이키는 Peaches를 ‘주목해야 할 브랜드’로 선정했고, 지난 수년간 포르셰, BMW M, 메르세데스 AMG, 현대차, 한국타이어, 삼성 갤럭시, AOMG 등과 협업을 이루어 냈다. 최근에는 성수동에서 오프라인 콘셉트 샵 도원(D8NE)을 운영하고 있는데, 하루 1500명이 다녀갈 정도의 유명 명소가 되었다.

Peaches의 이러한 성공은 어떻게 가능했을까? 이를 알아보기 위해 린 분석의 서비스 유형과, 사업 단계에 맞춰 Peaches의 행보를 알아보려 한다.

린 분석에서는 전자상거래, SaaS, 무료 모바일 앱, 미디어 사이트, 유저 콘텐츠 서비스, 마켓 플레이스 등으로 사업의 유형을 분류하고 있다. 현재 피치스는 린 분석에서 정확하게 맞는 서비스 유형을 찾기 어렵다. 그러나 의류, 스티커, 자동차 관련 용품을 웹 사이트를 기반으로 판매하고 있기 때문에 그나마 E-commerce 유형과 비슷하다고 할 수 있다.

이러한 다양한 서비스들은 공감 → 흡인력 → 바이럴 → 매출 → 확장으로 발전 단계를 거친다. 현재의 Peaches의 활동은 앞서 말한 오프라인 콘셉트 샵인 도원(D8NE)에 집중되어 있는 편이다. 피치스의 여인택 CEO의 인터뷰에 따르면 피치스가 생각하는 비전, 앞으로 나아가야 할 방향을 자연스럽게 보여주면서 피치스 문화의 실체를 만드는 공간이 필요해 도원(D8NE)을 만들게 되었다고 한다.

즉, 고객의 확장을 위해 수입의 일부를 재투자하여 브랜드 아이덴티티를 견고히 하는 과정에 있다고 볼 수 있다. 린 분석에서 매출 단계에서는 '최적의 가격 체계를 제시해 사용자들이 지불하도록 설득한 다음 수입의 일부를 고객 확보에 재투자'하는 단계라고 설명한다. 이러한 면을 비춰보았을 때 피치스는 바이럴 단계에서 매출 단계로 확장하는 단계를 지나고 있는 것으로 보인다.

그렇다면 공감, 흡인력, 바이럴 단계에서 어떤 활동을 하여 현재의 피치스로 성장하였고 매출 단계의 활동으로 넘어갈 수 있었을까?

사실 피치스의 활동을 살펴보면 린 분석에서 제시한 단계를 따르지 않고 성장했다고 볼 수 있다. 공감 단계는 피치스를 만든 여인택 대표가 수입차 브랜드 동호회에서 사람들과 자동차 문화에 대한 아쉬움을 자주 이야기하다 출발했기에 여러 번의 문제를 정의하는 과정을 거쳤을 것이라 예상할 수 있다.

흡인력 단계와 바이럴 단계는 거의 동시에 진행이 되었다. Peaches는 처음 시작하며 Peaches가 적힌 스티커를 배포하기 시작하였다. 많은 사람들이 자동차 튜닝 문화를 대표하는 브랜드를 간절히 원했던 결과였을까? 이 스티커는 곧바로 인스타그램에서 확산되기 시작한다.

Peaches의 대표 아이템인 데칼 스티커

이렇게 스티커가 확산되면서 반응이 생겨나자 같은 해 도쿄에서 열린 포르셰 전문 튜닝업체 RWB의 행사의 영상을 만들게 된다. 해당 영상은 강력한 비트와 감각적인 영상미를 가지고 있다. 자동차를 정말 멋지게 보여준다. 하지만 이 영상의 가장 특별한 점은 자동차 문화를 좋아해야만 공감할 수 있는 점이 많다는 것이다. 자동차 튜닝 문화를 좋아하는 사람이라면 꼭 한번 봤을 이니셜 D를 연상시키는 장면, 8090 전 세계 자동차 튜닝 문화에 중심지였던 일본의 느낌을 잘 담은 점 등은 자동차 팬들을 열광시키기에 충분했다. 그 결과 해당 영상은 200만 회에 가까운 조회수를 기록할 정도로 확산되게 된다.

Peaches를 있게 한 RWB행사 영상

Peaches는 영상과 스티커를 브랜드 성장의 기반을 쌓았다. 이를 통해 피치스를 사랑할 수밖에 없는 흡인력을 만들었고, 이에 더해 바이럴 효과까지 만들어냈다. 이는 매출 단계를 고민할 수 있는 원동력을 만들었으며 현재의 Peaches를 만들어 냈다. 슈프림과 비슷한 행보를 보이며 빠르게 성장하고 있는 Peaches, 앞으로의 성장이 더욱 기대된다.

Comment

린 분석에 맞춰 Peaches를 분석해보니, 린 분석은 IT 서비스에 좀 더 특화되어 있다는 생각을 하게 된다. 서비스 유형과 사업의 단계들이 브랜드의 성장 과정에 완전히 Fit하지는 않았기 때문이다. 린 분석에서 알 수 있는 분석 가이드를 활용은 하되 Peaches와 같은 브랜드에 적용할 때는 상황에 맞춰 활용할 필요가 있어 보인다.

김영감의 영감노트

[PMB 8기] 초기 당근마켓의 소비자들은 어떤 사람들이었을까?

당근마켓 성장세

판교마켓에서 당신 근처의 중고마켓으로

타겟 고객

대표 페르소나

User Journey Map (고객 여정 지도)

Customer Value Chain(CVC)

당근마켓이 개선하면 좋을 단계와 솔루션 아이디어

1. 결제 단계 (Must have)

2. 물품 수령 단계 (Sould have)

3. 여러 상품 비교 & 적정 가격 설정의 단계 (could have)

Comment

[PMB 8기] Agile(애자일) = Jira(지라), 애자일이지라!

Agile = Jira

애자일의 12가지 원칙

Jira에서 찾아볼 수 있는 애자일 원칙들

Comment

[PMB 8기] 애자일 스크럼에서의 PM의 역할과 스프린트 하는 법

Product Manager = Product Owner in Scrum

Scrum의 심장, Sprint

스프린트 계획 단계

데일리 스크럼 단계

스프린트 리뷰

스프린트 회고

완벽한 Agile 방법을 찾는 이들에게 전하는 가장 중요한 것

[PMB 8기] 네이버 쇼핑 리뷰 기능을 주제로 애자일 찍먹하기!

네이버 쇼핑에서 겪은 불편함

애자일 찍먹! 유저 스토리와 태스크 설정해보기!

애자일의 의미와 방법론

네이버 리뷰 기능 개선 사항을 User Story와 Task로 정리해보기

AS: [네이버 쇼핑을 이용하는 소비자]는 I want : [여러 가지 상품 정보가 한 번에 제공될 경우 각 상품별 리뷰를 확인] 하기 위해서So that: [각 상품 종류에 해당하는 리뷰를 골라볼 수 있는 기능]을 원한다.

Comment

PO가 소통해야 할 이해관계자

네이버 쇼핑 리뷰 기능에 연관된 이해관계자는?

AS: [네이버 쇼핑에서 상품을 판매하는 셀러]는 I want : [상품 페이지에 유입된 고객들을 구매로 전환시키기] 위해서So that: [구매하기 버튼의 인터렉션 UI ]을 원한다.

AS: [네이버 쇼핑 최종 의사결정자]는 I want : [쇼핑 라이브 서비스를 성장시키기 ] 위해서So that: [쇼핑 라이브 기능 개선을 최우선으로 해결하는 것]을 원한다.

Product Owner가 이해관계자들의 다양한 니즈에 대처하려면?

[PMB 8기] 기획자의 우아한 형제들 기술 블로그 탐험 일기

우아한 형제들 기술 블로그 글 탐험해보기

탐험과정을 글로 써 본 이유

[PMB 8기] IT알못이 정리해본 API 개념과 예시

API... 멀리서 보면 비극이요, 가까이서 보면 희극이다.

우리 생활에서 가까이 있었던 API

Comment

[PMB 8기] 앱을 만들기 전 반드시 알아야할 Mobile App 유형

모바일 웹(Mobile Web)

모바일 웹앱(Mobile WebAPP)

장점

단점

장점

단점

하이브리드 앱(Hybrid APP)

장점

단점

모바일 웹, 웹앱, 하이브리드 앱, 네이티브 앱의 예시

크로스 플랫폼 앱(Cross-Platform APP)

장점

단점

1. 서비스 개발에 있어서 소요되는 자원을 고려해야 한다.

2. 서비스, 솔루션의 단계에 따라 앱의 형태를 고려해야 한다.

3. 앱 서비스의 유형을 고려해야 한다.

4. 고객의 행동이나 퍼널 상의 특징을 고려해야 한다.

Comment

[PMB 8기] HTML,CSS, JS 까지 with 쿠팡플레이의 랜딩페이지

1. 쿠팡플레이 & 선정 이유

2. 쿠팡 플레이 랜딩페이지의 HTML 구조

3. 쿠팡 플레이 랜딩 페이지의 중심 CSS 스타일

4. 쿠팡 플레이 랜딩페이지에서 쓰인 JS

[PMB 8기] Kaggle Data로 알아본 Fitness Tracker 시장 인사이트

시장 현황에 기반한 가설 설정과 검증

Commnet

[PMB 8기] '린 분석'의 관점에서 본 'Peaches'

AS: [네이버 쇼핑을 이용하는 소비자]는
I want : [여러 가지 상품 정보가 한 번에 제공될 경우 각 상품별 리뷰를 확인] 하기 위해서
So that: [각 상품 종류에 해당하는 리뷰를 골라볼 수 있는 기능]을 원한다.

AS: [네이버 쇼핑에서 상품을 판매하는 셀러]는
I want : [상품 페이지에 유입된 고객들을 구매로 전환시키기] 위해서
So that: [구매하기 버튼의 인터렉션 UI ]을 원한다.

AS: [네이버 쇼핑 최종 의사결정자]는
I want : [쇼핑 라이브 서비스를 성장시키기 ] 위해서
So that: [쇼핑 라이브 기능 개선을 최우선으로 해결하는 것]을 원한다.