brunch

매거진 PM 성장 아카이브

라이킷 13 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 해원 Jul 05. 2022

마이리얼트립 카테고리 기능 개선, 애자일스럽게!

[코드스테이츠 PMB 11] Ep28. 프로덕트 개발 방법론

프로덕트 개발에 적합한 방법론을 선택하는 일은 프로젝트의 성공을 위한 첫걸음이다. 팀의 상황에 적합한 개발 방법론을 사용하는 것이 최선이겠지만, 각 조직이 당면한 문제와 업무 진행상황, 우선순위, 현재 이용 가능한 리소스 등이 모두 다르기 때문에 어떤 개발 방법론이 가장 적합한지 구별하기는 사실상 쉽지 않은 일이다.

제품 개발 방법론의 종류와 특징, 장단점은 무엇인지 파악하고 있어야 상황에 따라 적합한 방법론을 적용하여 성공적으로 프로젝트를 이끌 수 있기에 오늘은 제품 개발 방법론에 대해 알아보고자 한다.

1. 프로덕트 개발 방법론

제품 개발 방법론에는 워터폴(Waterfall)과 애자일(Agile)이 있다. 프로젝트의 유형, 팀 구조, 구성원의 역량, 프로젝트 기간 등 다양한 요인에 따라 적합한 방법론은 달라진다.

계획 기반의 제품 개발, 워터폴(Waterfall)

워터폴 방법론은 폭포수 방법론이라고도 불리며, 기획- 디자인 - 개발의 순서대로 차근차근 진행되는 순차적 개발 프로세스이다. 프로젝트의 시작부터 최종 결과물을 전달하기까지 특정 순서에 따라 이뤄지며 워터폴 기반 프로젝트 팀은 개발의 프로세스나 주기를 동일하고 정확한 순서로 실행하게 된다. 워터폴 방법론에서는 일반적으로 다음의 다섯 단계를 거쳐 제품이 출시된다.

1. 요구사항 수집과 분석
프로젝트 관리자가 클라이언트와 이해관계자의 요구사항을 수집하고, 해당 사항을 프로젝트의 구성 요소인 일정, 범위, 비용 등을 통해 작업 요소로 세분화한다.

2. 설계
UX Designer, 서비스 기획자, GUI Desginer 등의 서비스 설계자들이 실제로 서비스에 사용되는 시나리오나 UI 등의 설계를 진행한다.

3. 구현
소프트웨어 아키텍트와 개발자들이 설계를 바탕으로 실제로 개발을 진행하는 파트이다.
요구 사항과 설계 자료를 기반으로 프로그램을 실제로 코딩하고, 간단한 테스트도 진행한다.

4. 확인 및 테스트
범위, 품질 등이 기존의 요구사항에서 수립한 목표(Goal)와 부합하는지 확인하고, 테스트를 진행하여 제품의 품질을 검증한다.

5. 프로젝트 최종 결과물 전달(인도) / 유지 보수
클라이언트, 이해관계자에게 제품의 최종 결과물을 전달한다.
만약, 계약 내용에 명시된 유지 보수 외 추가적인 요구 사항이 발생할 경우, 프로젝트 관리자는 요구 사항 분석 후 (1) 추가 프로젝트 계약, (2) 일정 및 비용, 품질 조정 등으로 대응할 수 있다.

워터폴은 기획과 디자인, 개발에 대한 계획을 초기에 전부 세워 놓고, 철저하게 그 계획에 따라 팀원들이 협업해서 제품을 만들어내는 구조이다. 프로젝트를 시작하기 전 요구사항과 프로젝트의 범위, 비용, 일정에 대해 명확하게 정하기 때문에 전체적인 과정의 이해가 비교적 쉽고 새로운 팀이 새로운 프로젝트를 안정적으로 시작할 수 있다는 장점을 가진다.

반면, 초기에 결정된 계획이 중간에 변경되기가 매우 어렵다. 예를 들어서, 디자이너가 디자인을 전부 진행하고 개발자에게 넘겨 개발이 거의 완성되고 있는 상황인데, 디자인에 갑자기 수정 사항이 생겼다면 디자이너도 일을 해야 하고, 개발자도 이미 완성된 제품을 수정해야 하는 상황이 벌어지게 된다.

순차적으로 개발이 진행되다 보니 앞 단계가 완성되어야 다음 단계로 넘어갈 수 있다. 이로 인해 개발 속도가 느리며 유연성이 떨어진다는 단점이 있다.

이처럼 지속적으로 요구사항이 변경되는 등 예외적인 상황에서의 대응이 어렵다는 한계점을 보완하기 위해 애자일(Agile)이라는 방법론이 등장했다.

고객의 피드백을 빠르게 반영하는, 애자일(Agile)

스타트업이나 PM(Product Management) 직무에 관심이 있는 사람이라면, '애자일'이라는 용어를 한 번씩은 들어보았으리라 생각된다.

애자일(Agile)은 기민함, 민첩함을 뜻하는 단어인데, 소프트웨어 업계에서는 '제품을 시장에 출시하기 위해, 보다 유연하고 효율적인 방법으로 프로젝트를 관리하도록 만들어진 방식'을 뜻하는 용어로 사용된다.

애자일은 '스프린트'라 불리는, 2~4주간의 짧은 주기의 개발 사이클을 반복해 시장의 변화에 유연하게 대처하는 프레임워크이다. 각 사이클은 제품이나 서비스를 지속적으로 향상하는 데 초점이 맞춰져 있다.

고객의 요구사항을 최대한 반영한 MVP를 만들기 때문에 워터폴 방식보다 고객의 참여 범위가 비교적 넓은 편에 속하며 고객 가치를 효과적으로 전달할 수 있다는 큰 장점이 있다. 기술이나 시장 트렌드의 빠른 변화에 대응하기 쉬우며, 프로젝트 기간 동안 고객 및 외부 이해관계자, 팀원들과 원활히 협력하여 예상치 못했던 시너지 효과가 발생할 수 있다.

반면, 애자일은 순환이 빠른 만큼 단순 이벤트 페이지 등의 작업에서는 리스크가 적으나 새로운 서비스를 만드는 프로젝트인 경우 완벽한 프로세스를 밟을 수가 없기 때문에 버그가 발생할 가능성이 크다. 따라서 완성도가 중요한 프로젝트에서는 적용하기 어려운 방식이다.

애자일하게 일하려면?

효율적인 제품 개발을 위해 애자일을 실현하기 위해서는 스크럼과 유저 스토리, 칸반과 같은 프로세스 기법을 사용해야 한다.

스크럼이란 럭비에서 유래한 용어로 목적지에 도달하기 위해 하나로 뭉쳐 움직이는 형태를 의미한다. 애자일에서도 제품의 목적을 달성하기 위해 제품 팀원들이 스크럼처럼 하나로 뭉쳐 목적을 달성하는 방식으로 일하게 되는데 이 팀을 '스크럼 팀'이라고 지칭한다. 유저 스토리란 팀에서 해결해야 하는 고객의 문제를 제품 팀이 아닌 '고객'의 입장에서 서술한 것이다. 칸반은 이런 애자일 프로세스를 진행하는 업무 방식 중 하나로 작업 항목과 각 프로세스 단계를 표현하기 위해 칼럼을 사용해 다양한 단계의 프로세스의 일을 시각적으로 표현하는 방식이다.

출처: 위키백과

칸반은 백로그로부터 시작된다. 백로그란 이해관계자로부터 요구받은 유저 스토리의 목록을 의미한다. 그리고 백로그는 제품 개선 일정(우선순위)과 밀접한 연관을 가지게 된다. 팀은 해결할 수 있는 요구 사항의 수가 기간별로 정해져 있는데, 이를 무시한 채 계속 요구 사항만 받게 된다면 백로그가 쌓여만 가고 해결되지 못하기 때문이다. 그래서 다양한 기준으로 우선순위를 매겨 백로그에 올리지 않거나 제거할 수 있다.

애자일의 프로세스에서 빼놓을 수 없는 백로그, 그리고 유저 스토리는 실제 서비스에 문제가 발생했을 때 어떻게 표현될까? 유저 스토리와 백로그를 '마이리얼트립 카테고리 기능 개선'을 통해 좀 더 자세히 알아보자.

2. 마이리얼트립 카테고리 기능, 애자일 방식으로 개선하기

우리는 모든 경험을 연결하여 여행을 혁신합니다

지금껏 경험하지 못한 새로운 곳으로의 여행을 좋아하는 나는 평소 이용하던 여행 플랫폼들 중 하나를 분석해봐야겠다는 생각을 하고 있었다. 그중에서도 마이리얼트립이 애자일 방식을 잘 적용하고 있을 것이라는 생각이 들었다.

이전에 마이리얼트립 기술블로그에서 '데이터가 흐르는 조직:Season2를 준비하며'(참고) 라는 글을 읽은 적이 있다. 데이터가 흐르는 조직을 만들기 위한 마이리얼트립의 노력들을 알 수 있었는데, 사내 SQL 스터디를 기수제로 꾸준히 진행하며 Data_Driven 분위기를 만드는 데 기여하고 구성원들이 데이터와 친숙해지고 실제 업무에 SQL을 활용할 수 있도록 하고 있는 점이 인상적이었다.

또 한 가지는 각 사업부서에서 필요한 지표를 모아 놓은 대시보드를 데이터분석팀에 요청하지 않고 스스로 핵심지표를 정의해서 직접 대시보드를 만들도록 독려한다고 한다. 실제로 대시보드를 보면 데이터분석팀 외 멤버들이 만들어서 활용하고 있는 것들이 훨씬 많고, 주제도 엄청나게 다양한 것을 확인할 수 있다.

대시보드 / 출처: 마이리얼트립 기술블로그

이처럼 데이터에 기반해서 고객의 문제를 해결하고, 이를 서비스에 반영하기 위해 끊임없이 노력하고 있는 모습이 엿보였다. 데이터를 효과적으로 활용하고, 데이터 엔지니어와 데이터 분석가의 협업이 돋보이는 만큼 마이리얼트립은 애자일 조직이라고 할 수 있지 않을까?!

문제 정의

우리가 여행을 떠나려고 할 때 가장 먼저 고려하는 것은 무엇일까.

아마도 해외여행 갈까? 국내여행 갈까? 일 것이다. 엔데믹 시대로 접어들면서 드디어 해외여행도 고려사항에 포함할 수 있게 되었다. 그 이후에 어느 도시를 여행할지 정하게 된다.

마이리얼트립의 홈 화면을 보면 해외여행/국내여행 상품의 카테고리가 구분되어 있지 않다. 현재 홈 화면 상단 피드는 국내와 해외 여행지가 섞여서 뜨고 있고(제주도와 강원도 피드 사이 파리, 라스베가스 피드가 끼여있는 형태) 최상단 검색창을 선택하면 노출되는 인기 여행지에서도 국내/해외 지역을 구분하지 않고 동시에 보여주고 있다.

홈 화면 / 검색창 / 카테고리 분류

전체 여행지로 들어가 카테고리를 확인했을 때 '국내 여행은 왜 없지?'라는 생각이 들었다. 다시 찬찬히 살펴보니 아시아 > 국내 > 대한민국 > 도시명 순으로 찾아 들어가야 하는 형태로 되어 있어 유저들에게 혼란을 줄 소지가 있다는 문제가 있었다.

개선안

앞서 정의한 문제와 관련하여 개선안을 도출하기에 앞서, 다음과 같은 이슈들도 함께 고민해 보았다.

이슈 1. 유저에게 편리한 사용감을 제공하기 위해 어떤 방식으로 카테고리 분류를 해야 할까?

이슈 2. 전체 여행지의 카테고리의 정렬 기준은 어떻게 되어야 할까?

이를 고려하여, 전체 여행지 카테고리에서 '국내'를 아시아의 하위 속성으로 넣기보다는 왼쪽 메뉴 최상단 또는 최하단에 위치시키고자 한다. 사용자 입장에서 자칫 '국내 여행지는 없는 건가?'라는 생각이 들 수 있는 상황을 방지하여 혼란을 줄 여지가 줄어들 것이다.

국내 지역명을 선택하기까지 한 단계 Depth가 줄기 때문에 사용자의 피로도가 감소하고 긍정적인 사용 경험을 제공할 수 있다. 왼쪽 카테고리를 보면 유럽, 아시아, 아메리카 등 대륙별로 구분되어 있는 것으로 보아 중복 없이, 통일성을 주려고 한 의도가 아니었을까 짐작된다. 서비스를 이용하는 사용자 편의를 고려하였을 때 왼쪽 카테고리에서 바로 '국내'로 들어갈 수 있도록 하는 것이 더 만족감을 제공할 수 있다고 생각한다.

개선안에 대한 유저 스토리

유저 스토리는 사용자들에게 가치를 줄 수 있는 기능을 서술해야 하며, 고객 니즈가 반영된 형태의 할 일을 작성하는 것이다. 사용자의 경험을 위와 같은 형식으로 정리하면 고객이 무엇을 원하고, 정말 필요한 것이 무엇인지 발견하여 개선점을 찾도록 도와준다.

고객/사용자는

목적/목표를 위해서

필요/욕구를 원한다.

위 형식으로 작성한 카테고리 분류 기능 개선을 위한 유저 스토리는 아래와 같다.

마이리얼트립을 사용하는 유저는

쉽고 빠르게 여행할 도시를 선택하기 위해서

전체 여행지 카테고리에서 국내/해외 여행지 카테고리로 구분되길 원한다.

백로그 작성

백로그란 유저 스토리를 바탕으로 개발해야 할 기능 즉, 프로덕트에서 요구하는 기능과 우선순위를 말한다. 이때 주의해야 할 점은 단순히 처리하지 못한 것들을 모아주는 것이 아닌, 유저 스토리를 기반으로 누가 어떤 문제를 겪고 있는지, 문제를 어떻게 해결할 것인지, 만일 문제를 해결한다면 이를 통해 얻을 수 있는 결과가 무엇인지 명시해야 한다는 점이다.

백로그는 리소스의 투입 정도와 이를 통해 산출될 가치를 토대로 우선순위를 정해야 한다. 백로그의 우선순위를 정하기 위해 ICE 프레임워크를 이용하려고 한다. 실제 데이터 분석을 통해 가장 큰 Output을 가져다줄 수 있는 기능부터 구현하는 것이 좋겠지만 현재로서는 데이터를 알 수는 없기 때문에 ICE 스코어를 통해 우선순위를 파악하기로 했다.

ICE 프레임워크란

ICE Framework는 그로스 해킹의 아버지로 불리는 Sean Ellis가 사용하는 의사결정 Framework이다. ICE의 I는 Impact, C는 Confidence, E는 Ease를 뜻한다. 각 요소에 해당하는 핵심 질문을 Sean은 아래와 같이 설명하고 있다.

Impact는 “이 실험이 얼마나 영향력 있을까?” (회사의 핵심 KPI에 얼마나 많은 영향을 미칠지를 측정)

Confidence는 “이 실험이 성공할 확신을 얼마나 가지고 있는가?”

Ease는 “이 실험을 론칭하는데 시간이 얼마나 걸리는가?”

ICE 프레임워크를 활용하여 아래와 같이 백로그의 우선순위를 설정해 보았다. 우선순위는 High, Medium, Low로 구분하였다.

1) 여행지 카테고리에서 해외여행/국내여행지 카테고리 구분

기존 카테고리 분류에서 아시아 > 국내 > 대한민국 > 도시명으로 들어가야 확인할 수 있었던 것을 전체 여행지 카테고리에서 해외여행/국내여행을 구분하는 기능을 추가한다. 국내여행을 원하는 유저가 도시 목록을 보고 여행지를 선택하려고 할 때, 기존 카테고리에서는 국내 여행지 자체가 없다고 생각하여 혼란을 줄 수 있는 상황을 방지하고 한눈에 도시 정보를 제공한다.

2) 여행지 카테고리 정렬 기준 재설정

현재는 유럽/아시아/아메리카 등 대륙별 카테고리로 들어가면 각 도시명이 가나다순으로 정렬되어 있다. 하지만 이 정렬 방식이 유저들이 과연 원하는 정렬 방식인지, 사용자 편의를 증가시킬 수 있는 방식인지 생각해 볼 필요가 있다.

가령, 한국인이 많이 가는 해외여행지가 상단에 뜨도록 하거나 최근 인기 해외여행지 Best 10 순으로 먼저 보여주는 등의 정렬 방식을 적용할 수 있다.

3) 인기 여행지에서 해외여행/국내여행지 구분

인기 여행지로 노출되는 12~15개의 도시들을 해외/국내 도시로 구분하거나 카테고리화하지는 않더라도 국내도시들을 먼저 노출하고, 해외도시들을 노출하는 등 일관성 있게 순서를 재정리하여 가독성을 높인다.

4) 유저 맞춤형 여행 장소 추천태그 노출

고객 데이터를 분석하여 유저의 여행 스타일에 맞는 여행 장소 추천 태그를 노출시킨다. 유저가 여행지를 검색하기 전, 검색바 하단에 여행 장소 추천 태그를 노출한다.

예를 들어, '제주도 핫플레이스'라는 추천 태그를 선택하면 관련 상품이 리스트업되는 식이다. 사용자의 선호와 취향에 적합한 여행지 정보를 제공함으로써 장소 탐색 시간을 줄이고 만족스러운 서비스 이용 경험을 줄 수 있다.

제품 개발 방법론에 대하여 정리해보고, 마이리얼트립의 카테고리 기능 개선에 애자일 방식을 적용해 보았다. 애자일 프로세스는 유저 스토리를 통해 고객의 입장에서 문제를 발견하고, 그 문제를 해결하기 위한 다양한 요구사항들을 백로그로 정리하여 진행한다.

이전에 헤이조이스에서 '토스 PO가 말하는 프로덕트 성과를 극대화하는 방법'이라는 온라인 강의를 들은 적이 있는데, 강의를 해 주신 연사님이 제품의 방향성이 막연할 때 '백로그가 전부'라는 이야기를 하셨다. 백로그는 '뭘 해야 하지?'라는 고민에 '방향성'을 제시해주고, 현재 어디에 집중해야 하는지 한눈에 파악할 수 있게 해 준다는 것이다. 제품과 서비스를 개선하고 팀의 성과를 극대화하는 데 있어 백로그가 가장 중요한 역할을 하는 이유다.

참고자료

https://brunch.co.kr/@fc87114fbdc1481/2

https://brunch.co.kr/@dmsgud95/40

https://biz.chosun.com/it-science/ict/2022/01/01/3MAHKERPAVCGLC5RTYCQLAT6KM/

https://www.ajunews.com/view/20220321103203011

keyword