Edge-to-edge란 무엇인가
Android에서 edge-to-edge는 앱 콘텐츠가 화면의 안전한 영역에만 그려지는 것이 아니라, 상태바(Status bar)와 내비게이션 바/제스처 바(Navigation/Gesture bar) 영역 “뒤”까지 포함해서 디스플레이 전체에 걸쳐 렌더링되는 방식이다.
여기서 핵심은 “화면이 커 보인다”가 아니라 레이아웃 책임이 바뀐다는 점이다.
edge-to-edge에서는 뷰가 시스템 바 뒤에 그려질 수 있다.
그 결과, 앱은 Insets(인셋) 을 이용해 겹침을 처리해야 한다(상단/하단 패딩, 콘텐츠 위치 보정).
즉, “전체 화면에 먼저 그리고(inclusive), 가려지면 안 되는 요소는 인셋으로 피한다”가 edge-to-edge의 동작 모델이다.
최근에 갑자기 체감되는 이유
개념 자체는 예전부터 있었지만, 최근에는 Android 쪽에서 edge-to-edge를 기본 UX 패턴으로 밀면서 실무 이슈로 자주 폭발한다.
특히 Android 15 쪽 변화로 인해 “타깃 SDK를 올리면 화면이 갑자기 넓어지고(=시스템 바 뒤까지 그려지고) 기존 UI가 가려진다”는 상황이 생긴다. RN 커뮤니티에서도 targetSdk 35로 올리면 Android 15에서 OS가 edge-to-edge를 enforce해서 콘텐츠 영역이 status/navigation bar 아래로 확장된다고 정리한다
참고) GitHub
추가로 RN 개발자 입장에서는 StatusBar로 해결하던 습관이 더 이상 통하지 않는 구간이 생긴다. React Native 공식 문서에서도 Android 15의 edge-to-edge enforcement 때문에 API 35에서 StatusBar의 translucent 및 상태바 배경색 설정이 deprecated이며 효과가 없을 수 있다고 경고한다
정리하면:
“이제 디폴트가 edge-to-edge에 가까워졌다”
“기존 레이아웃이 우연히 안전했던 부분이 드러나면서 UI가 깨져 보인다”
“StatusBar 트릭으로 덮는 방식은 점점 덜 먹힌다”
확인한 문제부분
edge-to-edge가 적용되면 가장 먼저 터지는 지점은 거의 고정이다.
상단 헤더/타이틀 “파먹힘”
커스텀 헤더의 타이틀, 뒤로가기 버튼이 상태바 아래로 들어감
터치 영역이 위로 밀려 UX가 이상해짐
하단 CTA/탭바 “제스처 바에 걸림”
하단 고정 버튼이 제스처 바 영역에 겹쳐 눌리기 불편
탭바가 하단 인디케이터와 겹치거나 시각적으로 답답해짐
스크롤 마지막 아이템 “가림”
FlatList마지막 아이템이 바닥에 걸려 반쯤 보임“스크롤은 되는데 마지막 액션 버튼이 안 보이는” 종류의 결함이 생김
이것들은 버그라기보다 edge-to-edge의 기본 동작(시스템 바 뒤까지 그림)에서 생기는 자연스러운 결과다.
핵심 개념: Insets(인셋)으로 “겹침을 처리”한다
Android 공식 가이드에서도 edge-to-edge에서 중요한 건 insets에 반응해서 겹치는 영역을 처리하는 것이라고 말한다.
인셋을 실무적으로 해석하면 다음과 같다.
Top inset: 상태바(노치/펀치홀 포함) 때문에 피해야 하는 높이
Bottom inset: 내비게이션/제스처 바 때문에 피해야 하는 높이
좌우 인셋: 제스처 영역/화면 형태에 따라 필요한 여백
RN에서는 이걸 그대로 “Safe Area”로 이해해도 되지만, 중요한 포인트는 safe area가 목적이 아니라 “시스템 UI와의 겹침을 인셋으로 처리한다”가 목적이라는 점이다.
React Native 실무 원칙: 배경과 콘텐츠를 분리해서 표준화
실무에서는 edge-to-edge를 이렇게 표준화하는 편이 가장 유지보수에 좋다.
원칙 A) 배경은 edge-to-edge / 콘텐츠는 inset-aware
배경(ImageBackground/그라데이션/지도 등): 화면 끝까지 깔아도 된다
콘텐츠(텍스트/버튼/입력/CTA): top/bottom inset을 적용한다
Android 공식 가이드가 말하는 “뷰가 시스템 바 뒤에 그려질 수 있으니 인셋으로 겹침을 처리하라”를 RN식으로 번역하면 이 원칙이다.
원칙 B) “고정 UI”는 무조건 인셋 포함 값으로 계산
고정 UI는 특히 취약하다.
상단 고정: 커스텀 헤더, 상단 탭
하단 고정: CTA, 탭바, 바텀시트 액션
인셋을 포함한 padding/margin을 기본값으로 잡아야 “기기/모드” 차이를 먹는다.
원칙 C) 스크롤 컨테이너는 bottom padding을 규칙으로 둔다
FlatList/ScrollView에서 마지막 아이템 가림은 대부분
contentContainerStyle.paddingBottom = bottomInset + 여유
를 팀 규칙으로 고정하면 사라진다.
네이티브 설정/플래그는 “무엇을 해결하고 무엇은 해결 못 하는가
1. edgeToEdgeEnabled=true는 “전환 스위치”에 가깝다
RN 생태계(특히 Expo/일부 라이브러리/최신 RN 설정)에서는 edge-to-edge를 활성화하는 옵션으로 edgeToEdgeEnabled가 등장한다.
예를 들어 react-native-edge-to-edge 저장소 README에서도 RN 0.81+라면 built-in edgeToEdgeEnabled=true Gradle property를 고려하라고 언급한다.
react-native-edge-to-edge
또 Expo도 Android edge-to-edge를 다루는 업데이트/가이드를 따로 문서화하고 있다.
다만 중요한 점:
이 스위치는 “edge-to-edge ON/OFF”에 가깝고, 레이아웃이 안 깨지게 만드는 핵심은 여전히 인셋 처리다.
2. <item name="android:enforceNavigationBarContrast">false</item>는 “표현/대비 보호” 영역이다
이건 레이아웃을 정상화하는 해결책이라기보다, 내비게이션 바가 완전 투명해지지 않거나 시스템이 가독성(대비)을 위해 스크림을 올리는 것처럼 보이는 문제
같은 시각적/접근성 보호 동작에 영향을 주는 옵션이다.
결론
“상단/하단 가림” 같은 레이아웃 문제는 인셋으로 해결한다.
그 다음 “내비게이션 바가 원하는 만큼 투명하지 않다” 같은 표현 문제에서 이 옵션을 검토할 수 있다. (단, 접근성/가독성 트레이드오프가 생긴다)