하이브리드 앱의 업무 화면을 준비하면서 하단 GNB를 어떻게 처리할지 논의하게 되었습니다.

처음에는 GNB가 앱 화면에 이미 존재하니 웹에서는 크게 신경 쓰지 않아도 될 것처럼 보였습니다.

하지만 WebView를 전체 화면으로 띄우고 앱 GNB를 그 위에 노출하는 구조에서는 웹도 GNB의 존재를 알아야 했습니다. 그렇지 않으면 웹 콘텐츠의 마지막 영역이 GNB 뒤에 가려질 수 있었습니다.

앱에서 그리지만 웹 레이아웃에도 영향을 주었습니다

이번 구조에서는 GNB를 앱 영역으로 유지했습니다.

앱 전체에서 동일한 메뉴 경험을 제공하고, 앱 화면과 WebView 화면 사이에서도 일관된 동작을 유지하기 위한 선택이었습니다.

대신 웹 화면에는 GNB 높이만큼 하단 여백을 추가했습니다. 이 여백은 디자인을 위한 공간이 아니라 GNB가 웹 콘텐츠 위를 덮어도 마지막 내용이 잘리지 않게 하기 위한 영역입니다.

GNB가 없는 화면에서는 불필요한 여백이 생기지 않도록 웹에서도 옵션으로 적용 여부를 선택할 수 있게 했습니다.

바텀시트가 올라오면 GNB는 어떻게 해야 할까

레이아웃을 맞추고 나니 동작에 대한 질문이 이어졌습니다.

웹 바텀시트가 화면 아래에서 올라올 때 GNB가 그대로 남아 있으면 두 개의 하단 UI가 겹칩니다. 바텀시트가 GNB 위에서 멈추게 할 수도 있고, GNB를 숨기고 바텀시트를 화면 끝까지 올릴 수도 있습니다.

이번 프로젝트에서는 바텀시트가 올라올 때 앱 GNB가 아래로 내려가고, 바텀시트가 닫힐 때 다시 올라오는 흐름을 검토했습니다.

웹은 바텀시트의 상태를 알고 있고 앱은 GNB를 제어합니다. 두 영역이 함께 움직여야 하므로 상태를 전달하는 기준과 애니메이션 타이밍을 맞추는 일이 필요했습니다.

스크롤은 앱에서 감지하기로 했습니다

스크롤이 긴 화면에서는 콘텐츠에 집중할 수 있도록 GNB를 숨기는 동작도 필요했습니다.

웹이 스크롤 방향을 계산해 매번 앱에 전달하는 방법도 생각할 수 있습니다. 하지만 화면마다 같은 감지 로직을 구현하면 기준이 달라질 수 있고 Bridge 호출도 반복됩니다.

현재 구조에서는 앱이 WebView의 스크롤을 감지해 GNB의 노출과 숨김을 처리하는 방향으로 정리했습니다. 웹 화면은 GNB의 존재를 고려한 여백과 노출 옵션을 담당하고, 실제 스크롤 동작은 앱이 일관되게 처리합니다.

모달의 딤 처리는 남은 경계였습니다

웹에서 모달을 띄우고 WebView 내부만 딤 처리하면 앱 GNB는 어두워지지 않습니다.

모달 하나를 위해 매번 Bridge를 연결하면 웹 UI의 독립성이 줄어들 수 있습니다. 반대로 아무 처리도 하지 않으면 화면 전체가 하나의 레이어처럼 보이지 않을 수 있습니다.

이 부분은 실제 구현 결과를 확인한 뒤 다시 판단하기로 했습니다. 모든 경계를 처음부터 복잡하게 연결하기보다 사용자 경험에 문제가 되는지 먼저 확인하는 것도 필요한 기준이라고 생각했습니다.

GNB는 앱에서 그리는 UI이지만 웹과 분리된 영역은 아니었습니다.

하이브리드 앱에서 앱과 웹의 경계는 누가 화면을 그리는지만으로 정해지지 않습니다. 서로의 존재가 레이아웃과 동작에 어떤 영향을 주는지 함께 정할 때 비로소 하나의 화면처럼 움직일 수 있었습니다.