앱 MVP Android edge-to-edge: 타깃 SDK·insets·터치 영역을 나누는 5가지 기준
앱 MVP Android edge-to-edge: 타깃 SDK·insets·터치 영역을 나누는 5가지 기준
Android 앱 MVP에서 edge-to-edge는 화면을 더 넓게 쓰는 디자인 선택처럼 보이지만, 실제로는 어떤 기기·OS에서 시스템 바 뒤까지 그려지는지, 어떤 콘텐츠가 가려지면 안 되는지, 터치 가능한 요소가 시스템 제스처와 겹치지 않는지까지 나누어 확인해야 하는 출시 검수 항목입니다. Android Developers는 Android 15(API 35) 이상 기기에서 앱이 target SDK 35를 대상으로 하면 edge-to-edge가 강제된다고 안내합니다(C001). 따라서 SDK를 올린 뒤 첫 화면만 확인하고 끝내기보다, 화면 역할과 inset 유형을 함께 점검하는 편이 안전합니다.
이 글은 특정 앱의 Play 심사 통과나 모든 기기에서의 동일한 화면 결과를 보장하지 않습니다. 대신 Android MVP 팀이 target SDK 변화, 시스템 바 뒤 콘텐츠, View·Compose inset 처리, 제스처·입력 영역, 실제 기기 검수를 하나의 “화면이 열림” 신호로 섞지 않도록 다섯 기준을 제시합니다.
먼저 답하기: edge-to-edge는 여백 하나를 더하는 작업이 아닙니다
상태바가 투명하게 보이거나 화면 배경이 하단까지 이어진다는 관찰만으로 전환이 끝난 것은 아닙니다. 시스템 바 뒤에 그리기는 허용될 수 있지만, 읽기·조작 콘텐츠가 가려지는지와 시스템 동작에 가까운 터치가 충돌하는지는 별도 문제입니다.
구분 | 먼저 확인할 질문 | 완료로 오해하기 쉬운 신호 |
|---|---|---|
타깃 조건 | target SDK와 테스트 기기의 Android 버전은 무엇인가 | 빌드만 성공함 |
배경과 콘텐츠 | 시스템 바 뒤로 배경만 갈지, 본문도 갈지 | 상태바가 투명함 |
inset 유형 | 시스템 바·cutout·IME·제스처 중 무엇을 피할 것인가 | 모든 화면에 같은 padding 적용 |
조작 영역 | 고정 버튼·목록 끝·입력창이 눌리고 읽히는가 | 화면이 스크롤됨 |
기기 검수 | 방향·내비게이션 방식·키보드에서 실제 결과가 맞는가 | 한 에뮬레이터에서만 확인함 |
기준 1: target SDK 변화와 화면 전환을 따로 기록합니다
Android Developers의 View 안내에 따르면 Android 15 이상 기기에서 target SDK 35 이상 앱은 시스템 바 뒤까지 화면을 그리는 edge-to-edge가 적용됩니다(C001). 이 사실은 “모든 화면을 같은 방식으로 고쳐야 한다”는 뜻이 아니라, 기존에 시스템 바 밖에 있다고 가정했던 콘텐츠를 화면별로 다시 검수해야 한다는 뜻입니다.
먼저 릴리스 후보의 target SDK, 테스트 기기의 OS 버전, 화면 진입 경로를 기록합니다. 로그인 전·후, 목록 끝의 고정 CTA, 상세 화면, 입력 폼, 바텀 시트, 전체 화면 미디어처럼 시스템 바와 만나는 형태가 다른 화면을 분리하세요. 라이브러리나 테마 변경으로 화면이 열렸다는 관찰은 남길 수 있지만, 각 화면의 읽기·조작 결과까지 확인하기 전에는 전환 완료로 읽지 않습니다.
기준 2: 배경 확장과 콘텐츠 보호를 다른 결정으로 둡니다
edge-to-edge에서는 배경이나 이미지가 시스템 바 뒤까지 이어질 수 있습니다. 그러나 제목, 탭, 목록의 첫·마지막 항목, 주요 버튼처럼 사용자가 읽거나 눌러야 하는 요소까지 가려져도 된다는 뜻은 아닙니다. View 문서는 시스템 바에 가려지면 안 되는 탭 가능한 View에 system bars insets를 쓰는 방법을 제시합니다(C002).
따라서 화면별로 “배경은 확장”, “본문은 안전 영역 안”, “고정 조작 요소는 시스템 바와 충돌하지 않게”처럼 의도를 기록합니다. 상단 앱 바, 하단 버튼, RecyclerView의 끝 항목은 같은 padding 값으로 묶기보다 각각의 콘텐츠 역할을 먼저 봐야 합니다. 표시 잘림 영역이 있는 기기라면 system bars만이 아니라 display cutout도 검토 대상이 될 수 있습니다(C003).
관련 글 앱 MVP Android 글꼴 크기: 확대·줄바꿈·버튼을 나누는 기준은 글꼴 확대에서의 줄바꿈과 버튼 검수를 다룹니다. 이 글은 시스템 UI와 화면 경계가 바뀔 때의 inset·터치 영역 판단을 다룹니다.
기준 3: View와 Compose의 구현 단위를 섞지 않습니다
View 기반 화면에서는 `WindowCompat.enableEdgeToEdge()`를 Activity의 `onCreate`에서 호출하는 방법과 `WindowInsetsCompat`로 필요한 View에 insets를 적용하는 방법이 공식 문서에 안내됩니다(C004). 이 호출 자체는 시작점이지, 모든 자식 View의 레이아웃 검수를 대신하지 않습니다.
Compose에서는 `WindowInsets`가 상태바·내비게이션 바·IME·제스처·display cutout 같은 시스템 UI 정보를 제공하며, `safeDrawing`, `safeGestures`, `safeContent` 같은 조합도 제공합니다(C005). 무엇을 적용할지는 컴포넌트 역할에 따라 달라집니다. 예를 들어 본문을 가리지 않는 것이 목적이면 safe drawing 관점이, 시스템 제스처와 충돌하지 않는 조작 영역이 목적이면 safe gestures 관점이 더 직접적입니다(C006).
같은 화면에 View와 Compose가 함께 있다면 “한 쪽에서 padding을 적용했으니 다른 쪽도 안전하다”고 가정하지 마세요. inset을 소비하거나 전달하는 경계, 상위 컨테이너와 하위 고정 버튼의 중복 padding을 실제 화면에서 확인해야 합니다. 기술 선택은 팀 구조에 맞추되, 검수 기록은 화면 단위로 남기는 편이 추적하기 쉽습니다.
기준 4: 제스처·키보드·고정 CTA는 별도 테스트 항목입니다
시스템 제스처 영역은 단순한 여백이 아닙니다. Android Developers는 Compose에서 `safeGestures`를 시스템 제스처와 충돌해서는 안 되는 콘텐츠 보호에 쓰는 방법을 설명합니다(C006). 화면 가장자리의 스와이프와 맞닿는 버튼·슬라이더·지도 조작이 있다면, 보이는지뿐 아니라 실제로 눌리는지를 확인합니다.
입력 화면에서는 IME도 따로 봅니다. 키보드가 열렸을 때 하단 입력창과 제출 버튼이 남는지, 목록의 마지막 항목으로 이동 가능한지, 키보드를 닫은 뒤 여백이 중복되지 않는지를 기록하세요. 고정 CTA는 콘텐츠 스크롤과 별도로, 제스처 내비게이션과 버튼 내비게이션에서 모두 도달·탭 가능한지 확인합니다. 이는 모든 기기에서 완벽한 동일성을 약속하는 체크리스트가 아니라, 문제 발생 지점을 구분하기 위한 최소 관찰입니다.
기준 5: 렌더링 관찰과 출시 판정을 분리합니다
한 기기에서 배경이 시스템 바까지 보였다는 것은 렌더링 관찰입니다. 반면 출시 준비 판정에는 지원 OS, 화면 방향, 글꼴 크기, 키보드, 제스처·버튼 내비게이션, 표시 잘림 영역이 있는 기기 등 제품이 정한 범위의 결과가 필요할 수 있습니다. Android 공식 문서도 edge-to-edge 호환 작업이 Material 3 `Scaffold` 같은 구성 요소로 줄어들 수 있다고 설명하지만, 그것이 화면별 QA를 대체한다는 뜻은 아닙니다(C007).
검수표에는 최소한 OS·target SDK, 화면·진입 경로, 시스템 바 상태, 적용한 inset 유형, 키보드·내비게이션 방식, 가려짐 여부, 탭 결과를 따로 남기세요. 이렇게 하면 “edge-to-edge 적용”이라는 하나의 라벨보다 어느 화면의 어떤 경계에서 문제가 생겼는지 더 빨리 좁힐 수 있습니다.
우리 서비스에 맞는 앱 MVP 화면·출시 검수 기준 설계하기
자주 묻는 질문
target SDK 35로 올리면 모든 화면을 다시 만들어야 하나요?
아닙니다. Android 15 이상 기기에서는 edge-to-edge가 적용될 수 있으므로, 먼저 시스템 바 뒤에 가려지는 화면과 조작 요소를 찾아 insets 처리가 필요한 곳부터 검수합니다. 화면별 구현 방식은 View 또는 Compose 구조에 맞춰 정합니다.
상단 상태바와 하단 내비게이션 바는 같은 여백으로 처리하면 되나요?
항상 그렇지는 않습니다. 상태바, 내비게이션 바, 표시 잘림 영역, IME, 시스템 제스처 영역은 용도와 상황이 다릅니다. 가려지면 안 되는 콘텐츠인지, 제스처와 충돌하면 안 되는 조작 요소인지에 따라 적절한 inset 유형을 고릅니다.
Scaffold를 썼으면 모든 edge-to-edge 검수가 끝난 건가요?
아닙니다. Scaffold는 일부 호환 작업을 줄일 수 있지만, 실제 화면의 스크롤 콘텐츠, 고정 버튼, 입력창, 다이얼로그, 가로·세로 방향을 지원 기기에서 확인해야 합니다.
화면이 시스템 바 뒤까지 그려지면 오류인가요?
그 자체로 오류는 아닙니다. edge-to-edge는 시스템 바 뒤에 콘텐츠를 그릴 수 있게 합니다. 다만 읽어야 할 텍스트나 눌러야 할 요소가 가려지거나 제스처와 충돌하면 해당 요소에 맞는 inset 처리가 필요합니다.
공식 출처
Android Developers: Display content edge-to-edge in views — 2026-09-26 직접 확인
Android Developers: About window insets in Compose — 2026-09-26 직접 확인
발행일: 2026-09-26 · 작성: 유인어스 정책자금·정부지원사업 인사이트