혼돈 속의 리디 MVP 기획 7주차 위클리 | 코드스테이츠 PMB 13기

✏️ 내가 만든 리디 MVP에 대해서 에세이를 작성해봅시다

 

- 탐색 탭이라는 MVP는 어떤 프로덕트인가요? 핵심 기능은 무엇인가요?
- 앱 또는 웹 형태로 서비스하는 이유가 무엇인가요?
- 리디의 기술 스택은 현재 어떻게 되나요?
- 리디의 조직 구성원은 어떨 것으로 추정되나요?
- 리디는 스케일업하는 방법을 알고 있고, 또 그럴 역량을 가지고 있나요?
- 개발 스택이 스케일업에 있어서 중요한 요소인가요?

 

* 리액트 네이티브와 RN(React Native)을 혼용해서 표기했으니 참고 부탁드립니다.

 

---

 

 제안한 리디 MVP의 핵심기능 소개

      지난 몇 주 동안 틈틈이 구상해본 리디의 '탐색 탭' MVP는 사용자들의 작품 선택에 도움을 주고자 기획되었습니다. 제안한 MVP의 핵심 기능은 작품 리뷰와 키워드(ex. 드라마, 로판)를 기반으로 작품을 빠르고 간편하게 탐색할 수 있도록 도와주는 것입니다. 다른 사용자들의 리뷰를 활용해 작품에 대한 정보를 피드에 노출하자는 아이디어는 '사람들은 다른 사람들의 추천을 받으면 더 쉽게 작품 감상을 시작한다', '다른 사람들의 반응을 알 수 있을 때 더 재미있게 작품을 감상한다'는 가정을 바탕으로 구상해보았습니다. 리뷰 데이터는 리디가 가지고 있는 자원이었기 때문에 해당 데이터를 활용해 사용자들의 작품 유입률이 늘어나는 것을 확인한 뒤, 이후 MVP를 발전시키며 보다 다양화된 커뮤니티 기능(글 작성, 팔로잉 기능)을 도입하는 것이 좋을 것이라고 생각했습니다. 키워드 기반의 작품 추천은 '모든 사람들의 취향을 담는다'는 리디의 미션을 실현하기 위한 방법 중 하나라고 생각해 제안해보았습니다. 키워드를 기반으로 보다 적극적인 탐색 경험을 제공하면, 사용자는 보다 오랫동안 플랫폼에 체류하며 자신의 취향에 부합하는 작품들을 탐색할 수 있을 것이라고 생각했습니다. 

 

 

알면 알 수록 개발 우선순위에서 밀려나는 MVP 기획안

      하지만 야심 찬 초반 기획 의도와는 다르게 리디의 내부 상황에 대해 알게 될수록, 제가 생각해본 MVP는 현재의 상황과 앞으로의 로드맵에 비해서 개발 우선순위가 현저하게 떨어진다는 것을 깨닫게 되었습니다. 초짜의 기획이니 어쩌면 당연한 수순이었을지도 모릅니다.  제가 그렇게 생각하게 된 이유는 현재 비즈니스 팀과 개발팀 모두 일종의 터닝 포인트를 지나고 있기 때문이었습니다. 우선, 비즈니스의 측면에서 리디는 해외 시장 진출과 킬러 IP발굴 및 활용에 집중하고 있는 중입니다. 2020년 11월 만타를 출시한 후 계속해서 서비스를 다듬고 있습니다. 또한 IP 확보와 검증된 IP를 활용한 2차 IP사업(게임, 드라마 등)에 집중하고 있습니다. 개발 측면에서는 앱과 웹 모두 '더 나은 서비스'를 위해 지속적으로 수정되고 있었습니다. 웹의 경우 2008년부터 배포된 프로덕트이기 때문에 아주 오래된 고대의(?) 코드부터 최신 리액트 코드까지 모두 섞여 있는 상태였다고 합니다. 리디의 프론트엔드 팀은 현재 리소스의 40%를 투입해 이처럼 여러 코드가 섞여있는 상태를 정리하는 리팩토링 프로젝트를 진행하고 있습니다. 앱의 경우에는 생산성 및 유지보수 기능 향상을 위해 네이티브에서 리액트 네이티브로 전환하고 있습니다. 리디의 앱과 웹은 모두 리액트 기반으로 개발되었는데,  앱의 경우에는 한꺼번에 리엑트 네이티브(RN)로 전환하는 것에는 리스크가 커서 RN 위에 리액트 코드를 얹는 구조로 시작해 점진적으로 RN으로 전환하고 있다고 합니다.

 

 

      개발 비하인드를 알고나니 점차 강해지는 생각은.. 과연 나의 아이디어가 자원을 투입할 만큼 가치가 있는가? 라는 것이었습니다. 제가 제안한 MVP는 사실 '새로운' 것을 만들어내는 차원의 프로덕트는 아닙니다. 기존의 데이터(리뷰, 키워드)를 가져와 새로운 페이지 안에 재배치하는 느낌입니다. 이것이 얼마큼의 리소스를 요구할 것인지에 가늠하기 위해서는 조사가 필요할 것입니다. 필요한 데이터를 어디에서 받아오는지, 키워드와 리뷰 데이터로 작품 정보를 불러오는 API를 만들 수 있는지 등에 대해 알아봐야 할 것입니다. 그리고 무엇보다도 이 프로젝트를 추진하기 위해서는 리뷰 데이터와 관련해 제가 제시한 가설이 타당한지(효용이 있을지) 검증하는 과정이 필요하다고 생각합니다. 이를 위해 스크롤 깊이를 추적해 리뷰 콘텐츠 영역에까지 도달한 사용자가 최종적으로 작품 열람을 시작하는 비율을 확인해보면 도움이 될 것입니다. 하지만 최소한의 가능성 가설 검증 절차가 없는 상황에서 개발팀의 업무 및 리소스 할당 현황에 대해 알게 되니, 기존 업무량에 탐색 탭 페이지 개발이라는 프로젝트를 추가하자는 말을 패기 있게 할 수가 없었습니다. 아무리 실제 상황이 아니라고 할지라도요.

 

 

      그럼에도 불구하고 MVP 개발을 밀어붙이자면, 우선은 웹 상에서 시험해볼 수 있을 것이라고 생각합니다. 근거는 빈약하지만 2019년 리디에서 출원한 특허가 있습니다(클릭스트림 데이터를 사용하여 각각의 유저 유형별 웹사이트 사용 패턴이 반영된 각각의 유형별 퍼소나를 생성함으로써 특정 웹사이트의 유저들을 유형화하는 방법 및 장치). 아직 리디는 사용자별로 작품을 추천해주는 서비스는 제공하지 않습니다. 하지만 출원한 특허의 내용을 보니 사용자별 맞춤 서비스에도 관심이 있는 것으로 보입니다. 어떻게 돌아가는 기술인지는 모르지만, 제가 제안한 MVP를 구현하는데 도움이 되는 기술이라고 생각합니다. 그 밖에도 만타(Manta)에서 부분적으로 시도해볼 수도 있을 것이라고 생각합니다. 국내에서 서비스되는 리디 앱과는 다르게 해외에서 서비스 중인 만타는 처음부터 리액트 네이티브로 설계된 앱입니다. 리디의 코드를 가져가 쓰는 것인지, 공유하는 API가 있고 있다면 그게 문제가 되는지는 모르겠지만, 일단 리액트 네이티브 기반이기 때문에 CodePush를 통해 빠른 주기로 MVP를 시험해보고 업데이트할 수 있을 것이라고 생각합니다. 만타 앱에서 MVP를 시험하고 발전시킨 다음에 리디 앱에도 도입해보는 것도 좋은 방법이라고 생각합니다. 

 

 

개발 코멘터리 영상을 제작해둔 덕분에 저도 재미있게 지식을 얻을 수 있었습니다. 물론 90%는 못 알아들었지만요..^^ 한 마디 듣고 구글링하고, 한 마디 듣고 구글링 해가며 봤습니다.

 

 

리디의 기술 스택과 스케일업

      2021년 기준 리디의 기술 스택을 보면 PHP부터 스위프트, 자바, 코틀린, 자바스크립트, 파이썬 등을 사용하고 있는 것을 확인할 수 있습니다. PHP는 리디 웹페이지에서 발견되는 고대의 언어(..)인 것으로 추정됩니다. 현재 PHP, 예전 리액트 코드 등을 리팩토링 하는 과정에 있기 때문에 채용 공고를 보면 PHP를 읽을 줄 아는 사람을 우대하는 것도 볼 수 있습니다. 네이티브와 RN가 같이 사용되고 있기 때문에 스위프트와 코틀린, 자바가 함께 보입니다. 기술 스택에 대해서는 제가 문외한이기 때문에 여기서 더 적을 내용은 없습니다.

 

리디가 사용하는 언어 목록. 그 외에 리액트와 리엑트 네이티브, 플러터도 기술 스택에 포함됩니다. (백엔드, DB 등은 논외로 함)

 

      대신 인터뷰 영상을 떠올리며 개발팀 구성에 대해 추정해보도록 하겠습니다. 우선 처음에는 만타 개발팀과 리디 앱 개발팀 그리고 웹 개발팀이 나뉠 거라고 단순하게 생각해보았습니다. 하지만 생각해보니 리액트 네이티브를 사용하는 거라면 굳이 앱과 웹을 나눌 필요가 없을 것이라고 생각했고(자신 있는 근거는 아닙니다) 만타 개발팀과 기존 리디 개발팀으로 나뉠 것이라는 결론을 내리게 되었습니다. 만타는 기존 리디 앱과는 서비스 정책과 개발 환경이 다르기 때문에 별도의 팀으로 운영될 것 같았습니다. 그리고 기존 국내에서 서비스되던 리디 앱과 웹은 리액트 네이티브 도입을 기점으로 하나의 팀으로 운영될 것이라고 생각했습니다. 사실 이 부분에 대해서는 근거가 빈약합니다. 리액트 네이티브가 앱 플랫폼 간의 경계를 없애는데 도움을 준다는 것은 알지만 그게 앱과 웹의 경계에서도 적용되는지 잘 모르기 때문입니다. 하지만 분명한 점은 요즘 리디 개발팀은 네이티브에서 리액트 네이티브 앱으로 전환하는 과정에서 각 플랫폼 별 개발자에 대한 의존도가 줄었고, 인력풀이 상대적으로 큰 리액트 개발자를 영입하는데 주력하고 있을 것이라는 것입니다. 

 

 

      리액트 네이티브로 옮겨가는 흐름은 스타트업의 스케일업에 있어서 굉장히 좋은 변화라고 생각합니다.  리액트 네이티브는 개발과 비즈니스 양쪽 모두의 생산성을 높여주는 프레임워크입니다.  개발팀은 인력 수급에 부담이 적어지고 이중으로 코드를 작성할 필요가 없어서 생산성의 이점을 누립니다. 리디 PM의 말을 빌려 적어보자면, RN를 사용하면 빌드 타임이 소요되지 않아 AB테스트를 하기도 쉽고 결과도 바로 확인할 수 있어서 제품 개선 속도가 비약적으로 빨라집니다. (기존에는 빌드에 몇 분~몇 십분의 시간이 소요되고 그마저도 일부는 에러가 나서 다시 원점으로 돌아가야 했다고 합니다.) 그리고 CodePush를 통해 앱스토어/플레이스토어 심사를 거치지 않고도 배포하고 배포 후 수정 작업을 빠르게 진행할 수 있다는 점도 강점입니다. 비록 뷰어 기능은 그동안 고도화해온 네이티브 기술을 그대로 사용할 것이라고는 하지만 인터뷰 영상을 보면 각 페이지(기능) 별로 컴포넌트화해서 관리하는 것 같았습니다. 그래서 기능별로 네이티브를 사용할지 RN을 사용할지 결정할 수 있는 것으로 보입니다. 네이티브와 리액트 네이티브 간의 상태 관리 이슈 등 네이티브와 리액트 네이티브를 같이 가져가는 이상 관리 이슈가 지속적으로 발생할 것으로 보이지만, RN으로의 이전이 목표 수준만큼 도달하고 기술이 안정화되면 엄청난 경쟁력을 리디에게 가져다줄 것이라고 생각합니다. 

 

 

      온라인 서비스만 제공하는 리디에게 있어서 매끄러운 사용자 경험을 제공하는 앱은 필수입니다. 또한 리디 셀렉트(=도서), 리디, 만타, 라프텔 등 여러 종류의 콘텐츠를 여러 플랫폼을 통해 제공하기 때문에 코드의 효율도 굉장히 중요합니다. 하나의 기능을 여러 형태의 코드로 구현해 이리저리 배포하면 나중에는 걷잡을 수 없는 비효율을 초래할 수 있기 때문입니다. 그래서 현재 리디의 개발 로드맵은 장기적인 관점에서도 이상적이라고 생각합니다. 지금 하고 있는 작업들은 미래의 개발 팀원들이 일하기 좋은 환경을 구축하며 더 매끄러운 사용자 경험의 토대가 되어주기 때문입니다. 이미 구축된 환경에 안주하지 않고 과감하게 변화를 하는 모습도 인상적입니다. 인터뷰 영상을 보면서 개인적으로 '저런 마인드셋의 개발팀과 일하고 싶다'는 생각을 하게 되었습니다. 

 

 

---

 

정리하며

 

    사실 아직도 리액트와 리액트 네이티브의 차이가 무엇인지 분명하게 모르는 상태라 -대충 각각 라이브러리와 프레임워크라는 것은 알겠는데.. - 이 글을 쓰면서도 이게 맞나? 내가 정성 어린 🐕소리를 적고 있는 건가 싶었습니다. 하지만 과제를 수행하면서 다음번에 읽으면 그때야말로 제대로 이해할 수 있겠다는 자신감을 얻을 수 있었습니다. 저번 과제에서도 적었듯이 '아예 모르는 상태'에서 '뭐를 모르는지 모르는 상태'로 진화했기 때문입니다. 나중에 더 많은 지식을 습득한 이후에 이 글을 다시 읽어보면 민망하면서도 흥미로울 것 같습니다.