Quest 링크가 빈 화면에 머문 지점을 찾고, 페이지 이동을 없애다

파트너 앱에서 PlayHub Quest 링크를 열면, 진입 화면이 앱의 지원 기능을 확인하고 두 참여 화면 중 하나를 골랐습니다. 동료가 일부 Android WebView에서 다음 화면 대신 빈 화면이 남는 사례를 재현했습니다. 저는 프론트엔드에서 기능 확인, 새 화면의 응답, 실제 화면 전환 중 어디가 지연되는지 구별하고 전환 구조를 수정했습니다.

수정 목표는 페이지 이동을 없애는 데서 끝나지 않았습니다. 이동이 맡던 URL과 레이아웃 조건까지 옮겨야 같은 참여 화면이 시작됩니다.

응답이 늦은 문제와 화면이 늦게 바뀌는 문제를 나누다

당시 진입 화면은 앱의 지원 기능으로 목적지를 고른 뒤 router.replace로 새 페이지에 이동했습니다. 목적지를 알아도 페이지 전환이 끝나기 전까지는 사용자가 참여 화면을 볼 수 없었습니다.

목적지를 고른 시점, 새 화면을 구성할 서버 응답(RSC)이 도착한 시점, 실제 화면 전환이 끝난 시점을 나눠 기록했습니다. 조사한 사례에서는 응답이 도착한 뒤에도 화면이 바뀌지 않았습니다. 그래서 네트워크 요청을 반복하기보다, 응답 뒤에 남은 페이지 전환을 변경 대상으로 좁혔습니다. 그 전환이 내부적으로 왜 지연됐는지까지 확정한 것은 아닙니다.

페이지를 통째로 다시 여는 방식도 시도했지만, 일부 매체의 WebView에서 그 이동이 가로막히는 회귀가 확인됐습니다. 그래서 목적지를 고른 현재 주소에서 바로 참여 화면을 렌더해 별도 페이지 전환에 기대지 않도록 했습니다.

기존: 목적지 선택 → 새 페이지로 이동 → 응답 도착 → 전환 완료 → 화면 표시
변경: 목적지 선택 → URL의 진입 정보 반영 → 현재 페이지에 화면 표시

이동을 없애면서 기존 화면의 조건을 보존하다

페이지 이동을 없애는 것만으로는 같은 화면이 나오지 않았습니다. 원래 목적지 페이지는 URL에서 앱 안에서 시작했는지 같은 진입 정보를 읽고, 페이지 레이아웃에서 테마와 광고 설정을 적용했습니다. 목적지 컴포넌트만 현재 화면에 넣으면 이 조건이 빠질 수 있었습니다.

history.replaceState로 주소의 진입 정보(target)를 먼저 반영하고, 목적 화면이 바뀐 값을 읽은 뒤에 렌더하도록 순서를 정했습니다. 이를 건너뛰면 앱에서 시작한 참여를 외부 웹의 참여로 잘못 판단할 수 있었습니다. 기존 페이지가 적용하던 테마와 광고 설정도 공통 화면 틀로 옮겼습니다. 화면을 고르는 일과 그 화면의 실행 조건을 갖추는 일은 별개였습니다.

새 화면 코드를 전환 중 다시 기다리지 않도록 목적지 코드를 진입 단계에 포함했습니다. 처음 내려받는 코드가 커지는 비용을 감수한 선택입니다. 목적지를 결정하기 전에는 빈 화면 대신 로딩 상태를 보여줬습니다.

확인한 변화와 남은 경계

회귀 테스트는 지원 기능 조회 실패 시 외부 경로로 진행하는지, URL의 진입 정보가 반영되기 전에 잘못된 모드로 화면이 뜨지 않는지를 확인했습니다.

변경은 2026년 6월 제품 코드에 통합됐습니다. 코드와 테스트에서는 별도 페이지 이동 없이 목적지를 렌더하는 경로를 확인했습니다. 문제가 재현된 기기군에서 빈 화면 발생률이 얼마나 달라졌는지 확인한 운영 지표는 없습니다. 따라서 모든 기기의 문제가 해소됐다고 주장하지 않습니다.

목적지는 이미 정해졌는데 화면이 비어 있다면, 응답 도착과 화면 표시를 하나의 성공으로 묶어 볼 수 없습니다. 저는 두 단계를 나눠 관찰해 수정 지점을 찾았고, 이동을 제거하면서 그 이동이 전달하던 조건을 보존했습니다.