PlayHub 초기 구축부터 앱·웹 참여 확장까지
PlayHub 초기 허브의 핵심 프론트엔드를 구축하고 앱·웹 반복 참여로 확장했습니다. 같은 서버 상태에서 다음 행동을 정하되 완료를 확인하는 방법은 환경별로 나눠 두 금융 파트너 앱 출시까지 연결했습니다.
PlayHub는 파트너 앱에서 광고·콘텐츠·미션에 참여하고 리워드를 받는 서비스입니다. 사용자가 참여를 마치고 돌아왔을 때는 방금 얻은 결과와 다음에 할 일을 모두 알려줘야 합니다. 저는 초기 허브의 핵심 프론트엔드를 구축했고, 같은 참여 경험을 앱 안의 화면과 외부 웹으로 확장했습니다.
두 환경에서 다음 행동을 정하는 서버 상태 규칙은 공유하고, 광고 완료와 외부 복귀를 확인하는 방법은 나눴습니다. 서버의 참여·지급 정책과 상품 규칙은 담당자들과 맞췄습니다.
초기 허브에서 한 번의 참여를 끝까지 연결하다
초기 허브에서는 튜토리얼에서 콘텐츠·미션 참여와 리워드 안내까지 화면을 연결했습니다. 서버 상태를 읽어 지금 가능한 참여와 다음 안내를 계산하고, 외부 콘텐츠에서 돌아오면 다시 조회했습니다. 초기 허브 프론트엔드는 2025년 11월 상용 출시했고, 제품 담당자와 실제 참여를 확인했습니다.
이때 새 조회가 시작됐다고 방금 끝낸 행동의 결과까지 지우면 사용자는 리워드 안내를 놓칩니다. 랜덤박스 성공 안내는 사용자가 확인할 때까지 남기고, 새 조회는 다음 참여를 판단하는 데 썼습니다. 방금 마친 일의 결과와 지금 할 수 있는 일은 같은 화면에서도 다른 시점의 정보였습니다.
앱과 웹에선 같은 상태를 다른 방식으로 확인하다
후속 제품에서는 앱 안의 화면과 외부 웹이 같은 서버 응답에서 진행 수·수령 가능 여부·다음 행동을 계산하도록 했습니다. 하지만 앱은 광고 SDK의 완료 신호를 받고, 외부 웹은 이동 뒤 돌아와 서버 상태를 다시 확인합니다. SDK 응답만으로 서버에 기록된 참여나 지급 가능 상태까지 확정할 수는 없었습니다.
앱 화면에서 참여 요청·결과 안내·재조회를 먼저 연결한 뒤, 다음 행동 계산을 웹에도 적용했습니다. 광고 실행과 복귀 확인은 환경별로 남겼습니다. 화면마다 규칙을 복제하면 변경이 어긋나고, 실행까지 합치면 완료를 확인하는 시점 차이를 감출 수 있었기 때문입니다.
정각 QA에서 이 규칙의 반례가 드러났습니다. 새 시간대의 미션이 끝나지 않았어도 이전 시간대에 받을 보상이 남을 수 있었습니다. 현재 미션만 보면 수령 안내가 빠졌습니다. 서버 담당자와 응답의 의미를 확인하고, 이전 보상이 있으면 현재 미션의 완료 여부와 관계없이 복귀 수령을 안내하도록 바꿨습니다. 동료들이 해당 조건의 화면 노출을 확인했고 변경을 제품에 통합했습니다.
두 금융 파트너 앱까지 전달하다
후속 리워드 제품은 2026년 6월 두 금융 파트너 앱에 출시했습니다. 저는 프론트엔드 사전 배포와 진입점 전환, 실제 참여 확인을 연결했습니다. 두 차례 출시는 초기 허브 구축과 앱·웹 참여 확장을 전달한 근거입니다. 지급·정산의 최종 확정은 서버에서 다루며, 참여율 개선은 이 글에서 검증된 성과가 아닙니다.
이 경험의 기준은 다음 행동의 판단은 공유하고, 참여 완료를 확인하는 경로는 환경에 맞춰 분리한다는 것입니다. 이전 시간대 보상 사례는 이 구분이 UI 재사용보다 제품 상태의 의미를 지키는 문제였음을 보여줬습니다.
출시 뒤 참여 안내가 끊기는 지점을 조사하며 수집 방식을 바꾼 과정은 진단 수집 글에 적었습니다. 같은 제품의 별도 문제인 WebView 영상 재생과 광고 SDK 프리로딩은 버즈빌 기술블로그에서 다뤘습니다.