앱 MVP Android 예측 뒤로가기: 기본 이동·사용자 처리·취소를 나누는 5가지 기준

Android 앱 MVP에서 예측 뒤로가기의 기본 탐색, UI 콜백, 제스처 취소와 출시 전 검수를 나누어 점검하는 기준입니다.

Sep 20, 2026

앱 MVP Android 예측 뒤로가기: 기본 이동·사용자 처리·취소를 나누는 5가지 기준

Android 앱에서 뒤로가기 제스처는 단순히 이전 화면으로 돌아가는 버튼이 아닙니다. 사용자는 스와이프를 끝까지 수행하기 전에도 어디로 돌아갈지 미리 볼 수 있고, 앱은 그 순간에 화면 이동을 가로채거나 시스템에 맡길지를 선택하게 됩니다. MVP에서 이 흐름을 한 줄의 뒤로가기 처리로 남기면, 화면 닫기·작성 중인 내용 확인·목록 복귀·앱 종료가 서로 다른 조건인데도 같은 동작처럼 섞이기 쉽습니다.

이 글은 Android MVP에서 예측 뒤로가기(predictive back)를 준비할 때 기본 시스템 이동, 앱이 가로채는 UI 상태, 제스처 취소, 사용자 정의 애니메이션, 실제 기기 검수를 분리해 기록하는 방법을 정리합니다. 특정 앱의 UX 품질, Android 버전 호환, 출시 승인, 성능 또는 사용자 행동 결과를 보장하지 않습니다. 대상 SDK와 Navigation·Compose·View 구성은 실제 빌드에서 따로 확인해야 합니다.

먼저 정할 것: 이 뒤로가기는 어디로 가는가

예측 뒤로가기는 사용자가 가장자리에서 뒤로 스와이프할 때 목적지를 미리 보여 주는 시스템 제스처입니다(C001). 하지만 앱 안의 모든 뒤로가기 목적지가 같지는 않습니다. 루트 화면에서 홈으로 나가는 일, 상세 화면을 목록으로 닫는 일, 바텀시트를 닫는 일, 작성 중인 폼을 포기하기 전에 확인하는 일은 각각 다른 상태 전환입니다.

기능 문서에는 ‘뒤로가기’라는 이름만 적지 말고, 현재 표면·다음 표면·가로채는 조건·취소했을 때 남아야 하는 상태를 한 행씩 적어 두세요. 예를 들어 입력값이 없는 편집 화면은 탐색 스택에 맡길 수 있지만, 저장되지 않은 내용이 있을 때만 확인 UI가 앞서야 할 수 있습니다. 이 구분은 애니메이션을 화려하게 만드는 일보다, 사용자가 어떤 결과를 예상할 수 있는지 먼저 합의하는 작업입니다.

기준 1: 기본 탐색은 가능한 한 시스템과 라이브러리에 맡깁니다

Android Developers는 기본 뒤로가기 탐색을 쓰는 앱에서는 예측 뒤로가기가 기본으로 활성화되며, Fragment나 Navigation Component를 쓴다면 AndroidX Activity 1.6.0 이상으로 올리도록 안내합니다(C002). 따라서 MVP가 별도의 뒤로가기 규칙을 추가할 이유가 없다면, 기존 탐색 구성요소가 스택을 처리하도록 두고 실제 화면 이동을 먼저 검수하는 편이 낫습니다.

이때 ‘라이브러리를 올렸다’와 ‘모든 화면에서 의도한 목적지가 보인다’는 다른 확인입니다. 홈으로 나갈 때, 앱 안의 이전 화면으로 돌아갈 때, 다른 Activity로 돌아갈 때를 대표 시나리오로 나누세요. Navigation 라이브러리에 이미 예측 뒤로가기 지원이 있다면 별도 콜백을 덧붙이기 전에 그 동작을 우선 사용하라는 안내도 확인할 수 있습니다(C003).

기준 2: 앱이 가로채야 하는 UI 상태만 별도 콜백으로 둡니다

확인 대화상자, 펼쳐진 검색 패널, 바텀시트, 작성 중인 폼처럼 현재 UI만 먼저 닫아야 하는 경우에는 앱이 뒤로가기 처리의 우선순위를 가질 수 있습니다. Android의 가이드는 콜백마다 하나의 책임을 두고, UI 상태에 따라 활성화 여부를 정하도록 권합니다(C004). 여러 콜백은 스택으로 쌓이며, 마지막에 추가된 활성 콜백이 다음 제스처를 처리합니다.

즉 ‘뒤로가기 때 분석 로그를 남기기’나 ‘서버 상태를 바꾸기’를 이유로 화면 콜백을 항상 켜 두면 시스템 이동을 막을 수 있습니다. Android는 UI 로직에는 시스템 뒤로가기 콜백을 쓰되, 비즈니스 로직이나 기록 때문에 제스처를 소비하지 말라고 안내합니다(C005). MVP 문서에는 콜백 이름, 활성 조건, 닫을 UI, 콜백이 꺼진 뒤 맡길 다음 처리자를 분리해 적는 편이 좋습니다.

기준 3: 제스처 완료와 취소는 서로 다른 결과입니다

사용자는 스와이프를 시작했다가 손을 떼어 뒤로가기를 취소할 수 있습니다. Compose의 PredictiveBackHandler는 진행 정보를 제공하고, 취소되면 임시 UI 상태를 되돌릴 수 있도록 설명합니다(C006). 사용자 정의 전환을 만드는 경우라면 ‘스와이프가 시작됨’, ‘진행 중’, ‘완료’, ‘취소’가 한 이벤트가 아니라는 점을 확인해야 합니다.

예를 들어 화면을 작게 축소하거나 다음 화면을 미리 보이게 했다면, 취소 시 현재 입력값·스크롤·선택 상태가 그대로 복귀하는지 별도로 봅니다. 완료 콜백에서만 실제 탐색 상태를 변경하고, 진행 중인 프레임을 완료 기록으로 읽지 않는 식의 경계를 두세요. 한 번의 스와이프 화면 녹화만으로 모든 기기와 모든 중단 조건을 증명할 수는 없습니다.

우리 앱 MVP의 화면 전환과 출시 전 QA 항목을 함께 정리해 보세요

기준 4: 사용자 정의 애니메이션은 기본 이동과 분리해서 검토합니다

예측 뒤로가기의 기본 시스템 애니메이션이 충분한 화면과, 진행도에 맞춰 앱 안 전환을 직접 보여 줄 화면은 같은 구현 범위가 아닙니다. Android 문서는 Compose와 Views에서 진행도 API를 이용해 사용자 정의 전환을 만들 수 있다고 설명하며, 진행도는 사용자가 스와이프한 정도를 나타냅니다(C007). 직접 애니메이션을 넣는다면 시작·진행·취소·완료 네 상태마다 어떤 시각적 변화가 있어야 하는지 먼저 적습니다.

다만 사용자 정의 애니메이션이 필요하다는 판단이 기본 시스템 이동을 대체해야 한다는 뜻은 아닙니다. 홈으로 나가기나 앱 간 전환처럼 시스템이 목적지를 보여 줄 수 있는 경우, 불필요하게 콜백이 제스처를 소비하면 사용자의 예측과 달라질 수 있습니다. 화면별로 ‘기본 시스템에 맡김’, ‘UI를 먼저 닫음’, ‘진행도 기반 전환을 만듦’ 중 하나를 명시하고, 이유 없이 여러 처리를 중첩하지 마세요.

기준 5: 대상 버전과 실제 기기 관찰을 별도 기록합니다

Android Developers는 Android 15부터 지원 앱에서 홈·작업 간·Activity 간 시스템 애니메이션이 기본으로 나타난다고 설명합니다(C008). Android 13과 14에서는 개발자 옵션으로 뒤로가기 애니메이션을 시험하는 안내도 있습니다(C009). 이는 특정 앱이 모든 Android 버전에서 같은 모습으로 동작한다는 보증이 아니라, 테스트 기기·OS·target SDK·탐색 구조를 함께 남겨야 하는 이유입니다.

출시 전에는 최소한 루트 화면, 화면 스택, 바텀시트 또는 검색 같은 임시 표면, 입력 중인 폼을 고르고 각 시나리오에서 완료·취소 결과를 확인하세요. 테스트 기록에는 기기와 OS, 앱 버전, 현재 화면, 스와이프 시작 가장자리, 완료 또는 취소, 기대한 다음 상태, 관찰한 결과를 남깁니다. 미확인 기기나 중첩된 콜백 순서는 확인됨으로 바꾸지 않는 것이 좋습니다.

출시 전 기록 체크리스트

각 화면에서 뒤로가기 목적지가 홈·이전 화면·현재 UI 닫기 중 무엇인지 적었는가
기본 탐색에 맡길 화면과 UI 콜백이 필요한 상태를 구분했는가
콜백마다 한 가지 UI 책임과 활성·비활성 조건을 적었는가
제스처 시작·진행·완료·취소 뒤 상태를 별도 시나리오로 확인했는가
기기·OS·target SDK·탐색 구성과 관찰 결과를 함께 남겼는가

예측 뒤로가기는 기능 추가 여부보다 화면 상태의 경계를 드러내는 점검 항목에 가깝습니다. 기본 이동, 일시적인 UI, 실제 상태 변경, 취소 복귀를 구분해 두면 다음 화면을 추가하거나 탐색 라이브러리를 바꿀 때도 무엇을 다시 확인해야 하는지 찾기 쉬워집니다. 각 앱의 구현과 지원 범위는 최신 플랫폼 문서와 배포 후보에서 다시 검증해야 합니다.