리디북스 역기획 속, 애자일 엿보기
[코드스테이츠 PMB 10기] 프로젝트 개발 방법론
리디북스의 새로운 기능
그 속에 숨겨진 애자일 프로세스
1. 프로덕트 개발 방법론
PM은 지속적으로 What to build (기획)과 How to build (창출)을 통해 맡고 있는 서비스의 문제를 단기적 ·장기적으로 해결해나가야 한다. 즉, 함께 만들어야 할 것을 기획함으로써 사업가치와 고객가치를 창출하는데, 이 과정에서 발생할 수 있는 여러 문제점을 단기적으로 해결하고 장기적으로는 거시적 관점의 전략을 세워야 하는 것이다.
그럼 PM은 어떻게 기획과 창출을 할 수 있을까? 바로 '프로덕트 개발 프로세스'를 이용하는 것이다.
프로덕트 개발 프로세스는 총 5단계로, 기회 포착 및 계획 → 솔루션 디자인 → 솔루션 구축 → 솔루션 공유 → 솔루션 평가 순으로 이루어진다.
이 개발 프로세스를 잘 관리하면 좋은 제품을 제때 출시해낼 수 있다. 그리고 개발 기간을 맞추도록 관리하는 것 역시 PM의 역량이므로, PM은 프로덕트 개발 프로세스를 관리해주는 방법론들에 대해 잘 이해하고 있어야 한다. 그리고 이 방법론들에는 대표적으로 워터폴 (Waterfall)과 애자일 (Agile)이 있다.
워터폴 vs 애자일
그렇다면 워터폴과 애자일 각각의 방법론에 대해 하나씩 알아가보자.
워터폴 (Waterfall)은 프로덕트를 고객 테스트 없이 팀 내 혹은 기업 내 이해관계자들끼리의 결정만으로 개발한 후 시장에 내놓는 전략이다. 즉, 처음부터 고객 문제를 해결하는 솔루션을 정의하고 위에서부터 아래로 내려가는 탑-다운 방식으로 프로덕트를 개발하는 것이다.
주로 고객의 문제점을 명확히 인지하고 요구사항을 잘 이해하고 있을 때 사용되는 모델이다. 개발의 각 단계에 대한 기한을 정하여 일정을 정할 수 있으며, 프로덕트는 개발 프로세스 모델 단계를 하나씩 진행할 수 있기 때문에 관리가 용이하다는 장점을 가진다.
하지만 이전 단계로 돌아갈 수 없다는 전제가 있기 때문에 잘못되거나 누락된 부분이 있을 경우 수정이 쉽지 않다. 또한 테스트 단계 전까지는 형태를 갖춘 산출물을 확인하기 어렵기 때문에 개발 중에 고객의 피드백을 받기 쉽지 않다. 그런데 이에 더해 고객의 기대에 미치지 못한 결과물이 나왔다면? 기획부터 다시 해야하는 사태가 발생할 수 있는 것이다.
이처럼 즉흥적인 대응이 어렵기 때문에 지속적으로 요구사항이 변하는 요즘 IT 트렌드에는 맞지 않는 개발 방법론일 수 있다. 그래서 이와 같은 한계점을 보완하기 위해 애자일 (Agile)이라는 방법론이 등장했다.
애자일 (Agile) 은 워터폴에 비해 고객의 요구사항 변화에 유연하게 대응할 수 있도록, MVP (최소 기능 제품)을 출시하고 고객의 피드백을 받으면서 점진적으로 프로덕트를 완성해 나가는 개발 방식이다. 주기적마다 생성되는 결과물에 대해 고객의 평가와 요구를 적극 수용한다는 면에서, 이전 단계로 돌아갈 수 없는 워터폴과 대조적이라 할 수 있다.
이러한 애자일 프로세스가 탄생하게 된 배경으로는 1990년대 이후 SW 분야가 넓어지고 일반 대중들이 SW의 고객들이 되면서 시장에 대한 니즈가 다양해졌기 때문이다. 니즈가 다양화됨에 따라 비즈니스의 사이클은 짧아지고 사람들의 욕구와 트렌드도 빨리 바뀌게 되었다. 그 과정에서 워터폴은 빠르게 변화하는 고객들의 요구를 수용하지 못했고 이에 따라 고객들과의 소통이 주가 되는 방법론의 필요성이 대두되었다.
애자일은 실제로 어느 특정 개발 방법론이 일컫는 것이 아니라 좋은 프로덕트를 빠르고 낭비 없이 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭한다. 처음부터 완벽한 것을 만들기 보다는 고객의 요구를 확인하고 검증할 수 있는 MVP를 먼저 만들고 고객의 반응을 확인해 피드백을 하면서 프로덕트를 만드는 그 모든 방법론을 애자일 방법론이라 이르는 것이다.
애자일은 무조건 옳다?
위의 글까지 읽었을 때 애자일은 워터폴의 한계점을 보완한 것이므로 더 상위의 개념이고 더 우월하다고 생각할 수 있다. 하지만 '워터폴은 틀렸고 애자일은 정답이다' 라는 단정은 옳지 않다. 맡고 있는 비즈니스, 또는 서비스의 특성을 이해하지 않은 채로 오로지 애자일만 고집하는 것이 능사는 아니란 뜻이다.
앞서 설명했듯, 애자일은 하루가 다르게 가치가 변화하는 불확실성이 높은 시장에 적합한 프레임워크이다. 그런데 만약 고객의 요구사항의 유동성이 낮은 시장이라면? 또는, 첫 서비스의 인상부터 완전한 모습이 중요한 프로덕트라면은? 오히려 낮은 효율성을 자아낼 수 있다. 애자일은 어디까지나 워터폴의 한계를 보완하기 위한 개발 프로세스이지 어디에나 완벽히 적용될 수 있는, 그런 완전무결한 프로세스가 아닌 것이다.
그럼에도 애자일하게 일하고 싶은 기업들
이렇다 저렇다 이야기를 한다해도, 사실론적으로 애자일은 각광받고 있는 프로세스이다. 채용 JD만 봐도 어디서나 '애자일하게 일한 경험'을 요구하고 작게는 스타트업부터 크게는 대기업까지 애자일을 외치는 기업들은 늘고 있다. (참고)
그렇다면 애자일하게 일한다는 것은 무엇일까? 단순히 애자일 프로세스를 도입하면 모두 애자일하게 일한 것일까? 단도직입적으로 말하면, 애자일하게 일하기 위해서는 하나의 목표를 위해, 개개인의 자율을 바탕으로 협업하며 고객의 만족을 위해 달려나가야 한다.
그 과정에서 조직은 윗사람이 지시하면 아랫사람이 따르는 Top-down 방식이 아닌 구성원 개개인이 자율적으로 판단해 빠르게 실행하는 구조로 변화해야 하는 것이다. 고려대 경영대학 교수의 말에 따르면 애자일을 위한 수평적 자율 조직의 전제조건으로는 절차보다는 직원간의 연결, 소속감보다는 이루고자하는 비전을 같이 바라보는 것이라고 한다.
애자일하게 일하고 싶다면, 먼저 기업의 수평구조부터 함께 만들어 나가야 하는 것이 아닐까?
2. 리디북스의 꽃단장
'애자일'이 기획, 개발, 디자인 등 특정 분야에 속한 어떠한 특정 개념은 아니지만 애자일 조직이 이용한 프로덕트 개발 도구는 존재한다. 바로 스크럼, 칸반, 유저스토리이다.
이번 포스팅에서는 유저스토리를 이용하여 리디북스를 역기획해보고자 한다. 왜 리디북스를 선택했느냐 한다면 리디북스의 애자일함을 엿보았기 때문!
이전 W7D4 그룹 토론세션 때 리디북스의 앱 유형에 대해서 분석하며 리디북스가 [탐색, 결제] 웹 경험을 앱 내로 가져오는 로드맵을 설정하여 하이브리드앱으로서 도약하고 있다는 사실을 접했다. 리디북스가 이러한 변화를 추구한 이유로는 고객이 도서를 읽을 때는 앱을 사용하지만, 정작 결제를 하기 위해서는 웹으로 이동해야 한다는 불편성을 고민했기 때문이다.
그런데 바로 그저께! 앱을 들어가보니..? 어라라?
새로워진 리디를 만나보라는 말과 함께 웹툰/만화, 웹소설, 도서, 셀렉트 총 4분야로 실제 웹화면 뷰어와 결제를 할 수 있는 기능이 생겨났다! 처음 '새로워진 리디를 만나보세요'라는 말이 뜨자마자 너무 흥분해서 바로 캡처를 하고 말았다. (ㅋㅋ) 와 글감이 늘어났다! 하는 생각이 바로 들었기 때문이다.
그리고 위의 사진은 엄밀히 말하면 모든 개발이 완료된 후 고객들에게 보인 것이기 때문에 개발 방법론적으로는 워터폴이 맞다고 생각이 든다. 하지만 리디북스의 테크 블로그를 확인해보면 개발자들은 지속적으로 스크럼 미팅을 매일 아침마다 하고 매주마다 스프린트 회고를 진행한다고 한다. 그러므로 리디북스 내에서 해당 기능을 개발하기 위해서는 애자일 프로세스를 사용했을 것이다. (참고)
그렇다면 이것이 바로 오늘 학습했던 고객 피드백을 통해 개선할 점을 찾고 기업 내에서 애자일하게 문제를 해결한 사례가 아닐까 하여 리디가 어떤 식으로 유저스토리를 설정하였고 현재의 앱 화면을 기획하기 위해 어떤 백로그를 작성했을지를 글로 작성해보고자 한다.
유저 스토리 User Story
앞서 리디북스가 설정한 문제점으로는 고객이 리디북스 전체 서비스를 이용하려면 웹과 앱을 계속 오갈 수 밖에 없는 구조였다는 점이다. 그래서 리디북스는 앱 안에서도 완결성 있는 고객 경험을 주고자 탐색과 결제의 경험을 앱 내로 들고 오는 제품 로드맵을 세웠다.
이 부분에 초점을 맞춰 한번 유저스토리를 작성해보자. 그전에 유저스토리를 간략하게 설명하자면, 프로덕트의 사용자나 구매자에게 가치를 줄 수 있는 기능을 서술한 것으로 고객의 니즈가 반영된 형태의 할 일을 작성하는 것이기 때문에 니즈를 지속적으로 상기시킬 수 있다.
유저스토리는 위의 방정식을 주로 따른다. 한국어로 번역해보자면 [고객/사용자는 목적/목표를 위해 필요/욕구를 원한다] 이다. 이때 순서는 [Who/Why/What]이다. 이를 토대로 리디북스가 설정한 개선점에 대한 유저스토리는 다음과 같을 것이다.
WHO
리디북스 앱을 사용하는 유저는
WHY
앱 내에서도 웹소설 탐색을 하고 싶기 때문에
WHAT
웹의 기능인 웹소설 탐색 기능을 원한다.
(*이때 웹소설 탐색을 하고 싶은 유저를 대상으로 유저스토리를 작성해보았다.)
백로그 Backlog
백로그란 개발해야 할 기능 또는 프로덕트에서 요구하는 기능과 우선순위를 말한다. 이때 주의해야 할 점은 단순히 처리하지 못한 것들을 모아두는 게 아닌, 유저스토리를 기반으로 누가 어떠한 문제를 겪고 있는지, 우리가 문제를 어떻게 해결할 것인지, 만일 문제를 해결한다면 이를 통해 얻을 수 있는 또는 기대하는 결과가 무엇인지 명시해야 한다는 점이다.
그리고 이러한 백로그는 리소스의 투입 정도와 이를 통해 얻게 될 가치를 토대로 우선순위를 결정해야 한다. 우선순위를 결정할 때도 단순히 PO 또는 담당자의 독단적인 결단보다는 프로덕트 팀원, 이해관계자, PO간의 끊임없는 커뮤니케이션을 통해 결정하는 것이 훨씬 바람직하다.
그러면 리디북스는 기능개선 백로그를 어떤 식으로 작성하였을까?
위의 사진은 Coda.io를 이용해 작성한 task 뷰이다. Title에는 유저스토리를 기입하고 해당 유저스토리를 기반으로 필요할 것으로 보이는 기능들을 Task로 설정해놓았다. 개발해야할 기능적인 면에서 많이 부족할 테지만, 아마 Task는 저렇게 설정하고 누가 담당할 지, 그리고 현재 상태와 duedate를 설정했을 것이다. (duedate는 어느 정도가 적절할 지 몰라 일단 공백으로 두었다.)
Priority 경우에는 리디북스가 기다무나 연재되는 웹소설이 주 수입원이 될 것 같아 해당 기능을 먼저 개발하는 것으로 설정해두었다.
참고자료.
