탭조이(Tapjoy) 오퍼월 개선하기

Rails, jQuery 그리고 React

오퍼월(Offerwall)

오퍼월은 한 화면에 다양한 광고들을 보여주고 선택적으로 보상을 받을 수 있는, 어플리케이션에 탑재하는 모바일 광고의 전통적 제품의 한 형태이다.

Tapjoy Offerwall (기존 제품)

탭조이도 모바일 광고업에 진출한 이래로 해당 제품을 운영해왔으며, 매출 역시 안정적으로 발생하여 당사의 주력 제품 중 하나라고 할 수 있다.

문제점…

하지만 초창기부터 운영되어온 만큼 개발 생산성 측면과 UX 측면 모두에서 최적의 상태라고 할 수 없었다. 내외부적으로 해당 제품에 대한 문제점을 인식하고 있었으며 크게 아래와 같이 분류할 수 있다.

1. 다년간 변하지 않은 낡은 느낌의 디자인 (UX 측면)
2. 페이지를 이동할 때마다 화면을 새로받아 체감 속도가 느림 (UX 측면)
3. 뷰를 담당하는 로직이 규모가 큰 서버에 담겨있어 기능 추가와 유지 보수가 어려움 (개발 측면)

사내에서는 이러한 문제의식을 기반으로 기존의 오퍼월 제품을 개선하는 프로젝트를 진행하였고, 그 중 프론트엔드 부분에 해당하는 내용을 이번 포스팅에서 공유하도록 하겠다.

*실제로는 뷰를 담당하는 부분 뿐만 아니라 모든 로직이 거대한 메인 서버에 위치하고 있어 개발 효율성을 크게 저하시키고 있었다. 백엔드 로직을 분리하는 작업 또한 사내에서 진행되고 있으며, 기회가 된다면 해당 내용도 추후에 다뤄보도록 하겠다.

기존 제품과 그 구조

아래는 기존의 당사 오퍼월 제품을 유저가 실제 사용할 때의 모습이다.

올드한 스피너와 느린 체감속도

1. 탭조이 SDK가 탑재된 앱에서 당사의 비즈니스 로직이 담겨있는 서버에 오퍼월 제품의 렌더링을 요청하면,
2. 루비 온 레일즈로 만들어진 서버에서는 렌더링에 필요한 데이터를 통합한 후,
3. 템플릿에 구성요소들을 그려서 유저에게 돌려주고,
4. 그려진 오퍼월의 여러 광고들 중 하나를 선택할 경우,
5. 다시 서버에 요청을 보내 새로운 페이지를 그려서 유저에게 반환한다.

이처럼 기존 오퍼월은 SDK의 웹뷰 위에 루비 온 레일즈를 통해서 화면을 그려주는 전통적인 웹앱의 구조를 가지고 있었으며, 기능 추가와 같은 변화들은 있었으나 이런 구조 자체는 몇년째 개선없이 사용되고 있었다.

이 제품을 개선하고자 해도 기타 당사의 비즈니스 로직을 상당부분 담고 있는 거대한 서버에서 작업을 해야하는 문제가 있어, 개발 생산성이 몹시 떨어지는 상태였다. 테스트와 배포에도 상당한 시간이 소요되며, 행여나 다른 부분에 영향을 줄 수 있다는 문제점은 개발 측면에서 큰 부담이었다.

프론트엔드 분리와 SPA 구현

이번 프로젝트에서 진행된 프론트엔드 부분의 가장 큰 변화는 뷰 관련 로직을 메인 서버에서 분리한 것이었다. 기존의 구현이 매 요청마다 서버에서 새로운 페이지를 그려주는 기존의 레일즈 스타일이었다면, 새로운 구현은 최초 요청 이후에는 SPA(Single Page Application)의 형태로 화면을 그려주게 된 것이다.

좌측: 기존 구조 / 우측: 새로운 구조

새로운 구조는 아래와 같은 순서를 가지게 된다.

1. 유저가 최초의 요청을 서버로 보낸다.
2. 화면을 그려주는데 필요한 HTML 템플릿을 AWS S3로부터 받아 필요한 정보를 삽입하여 HTML로 유저에게 돌려주면,
3. 해당 HTML에 삽입되어 있는 AWS S3 위치를 기반으로 JS/CSS를 내려받아 화면을 그린다.
4. 그 후의 데이터 요청은 화면 새로고침을 수반하지 않는 Ajax call로 진행

새로운 구조는 페이지를 이동할 때마다 화면을 새로받아 체감 속도가 느리다는 UX 측면의 문제점을 해결하였을 뿐만 아니라, 뷰를 담당하는 로직이 규모가 큰 서버에 담겨있어 기능 추가와 유지 보수가 어렵다는 문제도 해결해주었다.

별개의 저장소로 관리

개발 생산성과 관련된 개선은 뷰(View)를 담당하는 로직을 별개의 프로젝트(Github 저장소)로 분리하여 관리할 수 있게 된 점을 들 수 있다. 기존에는 거대한 메인 서버에 직접 변화를 가해야했으나, 이제는 굉장히 가벼운 프론트엔드 관련 프로젝트만 수정하고 AWS S3로 배포하면 바로 프로덕션에 적용할 수 있게 되었다.

뿐만 아니라 새로운 버젼을 배포하기에 앞서 빌드된 HTML/JS/CSS만 간단하게 교체해가며 테스트 해볼 수 있도록 세팅하여 테스트 용이성도 크게 개선되었다.

첫 번째 SPA (jQuery)

그리고 위와 같은 구조적인 변화에 수반되어야할 작업은 자바스크립트로 SPA를 구현하는 것이었다. 이 프로젝트를 진행할 당시에도 팀이 담당하는 제품에 React를 사용하고 있었으나, 빠른 프로토타이핑을 위해서 jQuery로 어플리케이션을 만들기로 결정하였다.

전형적인 jQuery를 활용한 SPA

jQuery로 만든 SPA는 ES2015의 클래스 문법을 활용하여 화면을 구성하는 요소별로 클래스를 선언하여 만들어졌다. 추후에 좀 더 구조화 된 라이브러리로 다시 구현하더라도 초반의 구현 속도를 위해 jQuery를 선택한 셈인데, 쉽게 예상할 수 있다시피 오래 지나지않아 문제에 봉착하게 되었다.

자체적으로 구조를 잡고 규칙에 맞춰서 컴포넌트를 작성하였으나, 기능이 많아지고 요소간에 주고받는 데이터의 양과 복잡도가 높아짐에 따라서 1)규칙 예외 상황이 늘어나고 부득이하게 2)글로벌 스코프를 오염시키는 빈도가 늘어나게 되었다. 또한 무분별하게 사용된 jQuery 이벤트로 인해서 오작동이 발생하거나 메모리 누수로 인한 3)성능 저하가 발생하곤 하였다.

결국 React로

jQuery로 구현한 SPA에서 발생한 여러 문제점을 해결하기 위해서 결국 React로 다시 한번 포팅하기로 결정하였다. 이 과정에서 React 뿐만 아니라 Vue.js와 Preact 등 여러 렌더링 라이브러리가 후보에 올랐으나, 기존 프로젝트에서 이미 상당기간 사용한 React가 최종 선정되었다.

새로운 오퍼월 플러스

새롭게 쓰여진 SPA은 React와 Redux 그리고 Redux-Saga의 조합으로 작성되었으며, jQuery로 만들어진 앱에서 발견되었던 여러 문제점들을 보완할 수 있었다.

*다만 구현해야 하는 기능의 복잡도에 비해서 라이브러리의 용량이 크고 초기 가동시간이 다소 걱정이 되었는데 이 문제는 포팅 후에 실제로 나타났으며, 그것을 팀에서 어떻게 해결했는지도 따로 포스팅 할 예정이다.

프로젝트를 마치고

탭조이의 주력 상품 중 하나인 오퍼월을 개선하는 작업은 제품의 매출 비중만큼이나 부담감이 컸고, 개발 생산성 측면 뿐만 아니라 유저의 경험까지 개선해야 하는 두가지 목표가 있었다.

결과적으로 해당 제품 로직의 대부분을 별개의 프로젝트로 분리하고 새로운 구조로 다시 작성함으로써 개발 생산성을 크게 개선시킬 수 있었고, 유저에게도 쾌적한 사용감과 리뉴얼 된 디자인을 제공할 수 있었다.

이런 노력들 덕분인지 실제로 파트너사(탭조이 SDK를 탑재한 앱을 개발하는 개발사)로부터 좋은 반응을 꾸준히 받고 있으며, 실제로 황혼기에 접어든 오퍼월이라는 제품을 다시 한번 끌어올리는데 성공하였다.

Tapjoy + 5Rocks : 네이버 블로그

개선 작업과 새로운 제품에 대해서 세세하게 다루지 못한 부분이 남아있지만, 그런 내용들은 추후에 기회가 되면 다른 포스팅으로 정리할 계획이다.