안드로이드 앱 껍데기 안에 웹 화면을 띄우는 웹뷰 앱이었습니다. 당시 회사의 스택은 ASP.NET Core 기반의 서버 렌더링이었기 때문에, 화면을 이동할 때마다 페이지 전체가 다시 그려졌습니다. 웹에서는 자연스러운 동작이지만 앱 안에서는 화면이 한 번 하얗게 깜빡이는 것으로 보입니다. 사용자는 그것을 '앱이 버벅인다'고 느낍니다.
SPA로 다시 만들 여건은 아니었습니다. 그래서 프레임워크를 바꾸는 대신, 바깥 껍데기는 그대로 두고 안쪽 내용만 갈아 끼우는 구조를 만들었습니다. 헤더와 하단 탭은 절대 다시 그려지지 않고, 본문 영역만 교체됩니다.
그러자 새로운 문제가 생겼습니다. 바깥 껍데기와 안쪽 내용이 서로 다른 문서라서 상태를 공유할 수 없습니다. 장바구니 개수 배지를 갱신하거나, 안쪽에서 로그인이 풀렸을 때 바깥이 알아채야 하는 상황이 계속 나왔습니다.
문제가 무엇이었고, 무엇을 골랐고, 그래서 어떻게 됐는지.
결정 01
결정 02
결정 03
안드로이드 앱 안에서 도는 주문·결제 흐름 구현.
헤더와 하단 탭을 유지한 채 본문만 갈아 끼워 화면 전환의 깜빡임을 없앴습니다.
껍데기와 본문이 정해진 메시지 규약으로만 상태를 주고받습니다.
지도·공유 등 카카오 서비스를 앱 흐름 안에 통합.
매장·주문 식별을 위한 QR 생성과 인식 처리.
'제대로 다시 만들기'가 언제나 최선은 아니라는 걸 배운 프로젝트입니다. 구조를 전부 바꾸지 않고도 사용자가 느끼는 문제의 대부분을 없앨 수 있었습니다. 다만 이렇게 얻은 개선은 임시방편이 되기 쉬워서, 통신 규약처럼 나중에 남을 부분만은 제대로 정해 두는 것이 중요했습니다.
웹뷰는 웹도 앱도 아닌 중간 지대라, 어느 쪽 상식도 그대로 통하지 않습니다. 이때 몸으로 익힌 감각은 나중에 Dpectrum에서 웹뷰 앱 여러 개를 맡게 됐을 때 그대로 쓰였습니다.