앱 MVP 뒤로가기: 화면 복귀·입력 취소·앱 종료를 나누는 5가지 기준

앱 MVP에서 ‘뒤로가기’를 한 동작으로 적어 두면 QA가 가장 늦게 흔들립니다. 상세 화면에서는 목록으로 돌아가야 하고, 작성 화면에서는 입력을 버릴지 물어야 하며, 바텀시트에서는 시트를 닫아야 할 수 있습니다. 앱의 첫 화면이라면 사용자가 앱을 떠나는 흐름까지 연결됩니다.

직접 답하면, 첫 MVP에서는 뒤로가기 자체를 복잡하게 꾸미기보다 현재 화면이 무엇을 되돌리는지를 다섯 상태로 먼저 분리하는 편이 안전합니다. Android의 Predictive Back은 사용자가 제스처를 끝내기 전에 목적지를 미리 볼 수 있게 설명하며, 취소하면 화면이 원래 상태로 돌아가는 설계를 안내합니다. iOS도 계층을 거슬러 가는 Back과 모달을 닫는 Close를 구분합니다. Android Predictive Back design, Apple toolbars guidance

먼저 ‘뒤로’가 무엇을 의미하는지 정하세요

‘뒤로’라는 한 단어에는 서로 다른 결과가 섞여 있습니다. 사용자가 상세에서 목록으로 돌아가는 일과, 입력하던 값을 버리는 일, 잠깐 연 필터 시트를 닫는 일은 같은 결과가 아닙니다. 화면 이름만 나열하지 말고, 각 상태에서 사용자가 보게 될 다음 화면과 남는 데이터를 한 줄로 기록하세요.

이 표는 기능 명세가 아니라 검수 경계입니다. 예를 들어 상세 화면의 뒤로가기에서 목록으로 돌아간다고 정했다면, 목록 위치·필터·선택 상태 중 무엇을 유지할지까지 테스트할 수 있습니다. 검색 UI의 입력·결과·0건·취소를 이미 구분했다면, 그 취소가 ‘검색 모드만 종료’인지 ‘상위 화면으로 이동’인지도 따로 남겨야 합니다. 검색 기능 상태를 나누는 기준

1. 계층 복귀와 임시 표면 닫기를 같은 콜백에 넣지 마세요

상세 화면에서의 뒤로가기는 보통 계층을 한 단계 되짚습니다. 반면 바텀시트, 전체 화면 안내, 선택 패널은 그 위에 잠시 올라온 표면일 수 있습니다. 둘을 같은 ‘이전 화면’ 처리로 합치면, 사용자는 필터만 닫으려 했는데 목록까지 이동한 것처럼 느낄 수 있습니다.

Android 공식 가이드는 뒤로가기 콜백마다 활성화될 UI 상태를 먼저 정하고, 콜백에 하나의 책임을 주는 방식을 권합니다. MVP 기획 문서에서도 같은 원칙을 적용하면 됩니다. 필터 시트가 열려 있으면 시트 닫기, 시트가 닫히고 상세라면 목록 복귀처럼 우선순위를 적어 두세요. 이는 특정 코드 구조를 강제하는 말이 아니라, 기획·개발·QA가 같은 화면 전환을 확인하기 위한 기록입니다. Android의 current back-gesture guide

2. 입력 취소는 ‘이전 화면’이 아니라 데이터 결정입니다

작성 화면의 뒤로가기는 네비게이션만의 문제가 아닙니다. 사용자가 이름 한 글자만 입력했든 여러 필드를 바꿨든, 어떤 변경을 ‘저장되지 않음’으로 보고 어떤 선택지를 줄지 정해야 합니다. MVP에서는 아래 세 가지면 시작할 수 있습니다.

1. 변경이 없으면 바로 이전 화면으로 복귀한다.

2. 변경이 있으면 계속 작성·저장 후 나가기·변경 버리기 중 제품에 맞는 선택지를 보인다.

3. 선택 결과와 실제 데이터 상태가 맞는지 재진입 테스트로 확인한다.

여기서 ‘자동 저장’은 편리해 보이지만 별도 범위입니다. 초안 생성 시점, 동기화 실패, 다른 기기에서의 충돌까지 새 상태가 생기기 때문입니다. 백업·복원 준비와도 섞지 말고, 이번 MVP의 저장 방식과 실패 안내를 별도 결정으로 남기세요. 백업·복원 준비 점검

3. 예측 가능한 뒤로가기에서는 취소와 완료를 구분하세요

Android의 Predictive Back은 사용자가 제스처를 마치기 전에 목적지를 미리 보고, 계속할지 현재 화면에 남을지 선택할 수 있도록 설명합니다. 공식 디자인 문서는 커밋 전에 손을 놓는 경우 원래 상태로 되돌아가는 동작도 안내합니다. 따라서 QA는 단순히 ‘스와이프하면 이전 화면이 나오는가’만 보지 말고 다음을 나눠야 합니다.

• 시작했지만 취소한 제스처 뒤에 입력값·선택값·스크롤이 그대로인지

• 완료한 제스처 뒤에 다음 화면과 상단 제목이 기대한 계층인지

• 임시 표면이 열렸을 때 표면이 먼저 닫히는지

• 루트 화면에서 앱의 시스템 전환을 가로채고 있지 않은지

특히 분석 이벤트나 비즈니스 로직을 뒤로가기 처리에 억지로 결합하면 화면 전환과 기록의 책임이 엉킬 수 있습니다. Android 문서도 시스템 애니메이션을 유지하려면 UI 로직과 별개로 관찰할 수 있는 방식을 설명합니다. MVP 단계에서는 먼저 사용자가 보는 결과를 확정하고, 측정은 그 결과가 실제로 완료된 뒤 별도 이벤트 설계로 검토하세요.

4. iOS에서는 Back·Close·제스처를 한 경험으로 맞추세요

Apple은 계층을 되짚는 표준 Back 버튼과 모달을 닫는 Close 버튼을 구분해 안내합니다. 또한 빠른 제스처는 익숙한 내비게이션을 보완해야지 대체해서는 안 된다고 설명합니다. 즉, 스와이프만 가능한 화면을 만들기보다 사용자가 보이는 버튼으로도 같은 결과에 도달할 수 있는지 확인하는 편이 좋습니다.

이 기준은 플랫폼별 화면을 똑같이 만들라는 뜻이 아닙니다. Android와 iOS 각각의 시스템 동작을 존중하면서도, 사용자가 ‘이 버튼은 한 단계 돌아간다’, ‘이 X는 임시 화면을 닫는다’고 예측할 수 있게 역할을 맞추라는 뜻입니다. 커스텀 동작을 넣을수록 기존 제스처와 충돌하지 않는지도 테스트 대상에 추가하세요.

5. 출시 전에는 다섯 장면만 실제 기기에서 확인하세요

MVP 내비게이션을 검수할 때 긴 시나리오부터 쓰지 않아도 됩니다. 아래 다섯 장면을 실제 기기에서 한 번씩 통과시키면, 초기 범위의 빈칸이 빨리 드러납니다.

1. 목록 → 상세 → 뒤로: 목록의 필요한 맥락이 남는가

2. 목록 → 필터 시트 → 뒤로: 시트만 닫히고 목록은 유지되는가

3. 작성 → 값 변경 → 뒤로: 버리기·계속·저장 흐름이 명확한가

4. 검색 모드 → 뒤로: 검색 취소와 화면 이동이 혼동되지 않는가

5. 루트 화면 → 뒤로: 앱이 시스템 내비게이션을 부자연스럽게 막지 않는가

이 다섯 장면을 화면 캡처, 현재 상태, 사용자 행동, 기대 결과, 실제 결과로 남기면 다음 기능이 붙어도 기준을 재사용할 수 있습니다. 출시 직전의 배포 되돌리기 판단과도 다르게 관리하세요. 전자는 사용자 이동 경험의 검수이고, 후자는 릴리스 운영의 결정입니다. MVP 릴리스 롤백 체크리스트

앱 화면이 늘어날수록 뒤로가기를 예외 처리로 미루기 쉽습니다. 하지만 첫 MVP에서는 ‘어디로 가는가’보다 ‘무엇을 되돌리는가’를 먼저 정하는 편이 더 작고 검증 가능한 범위를 만듭니다. 유인어스와 현재 화면 흐름을 기준으로 MVP 범위를 점검하고 싶다면 앱 MVP 기획 상담을 시작해 보세요.

자주 묻는 질문

뒤로가기를 누르면 항상 이전 화면으로 가게 하면 안 되나요?

상세처럼 계층을 이동한 화면에서는 그럴 수 있습니다. 다만 바텀시트·모달·작성 중 입력처럼 현재 화면 위의 임시 상태나 데이터 변경이 있으면, 먼저 닫기 또는 확인이 더 맞을 수 있습니다. 화면마다 결과를 정해 테스트하세요.

작성 중 뒤로가기는 무조건 확인창을 보여줘야 하나요?

아닙니다. 변경이 없을 때까지 확인할 필요는 없습니다. 어떤 변경을 저장되지 않은 상태로 볼지, 저장·버리기·계속 작성 중 어떤 선택이 필요한지를 제품의 저장 방식에 맞춰 정하세요.

Android Predictive Back을 넣으면 모든 뒤로가기 문제가 해결되나요?

아닙니다. Predictive Back은 사용자가 가게 될 목적지를 미리 보거나 취소할 수 있게 돕는 시스템 경험입니다. 상세 복귀, 임시 화면 닫기, 입력 취소처럼 제품이 정해야 할 상태와 우선순위는 별도로 설계해야 합니다.

iOS에서는 스와이프만 제공해도 되나요?

Apple의 가이드는 빠른 제스처가 익숙한 내비게이션을 보완해야 한다고 설명합니다. 계층 이동이라면 표준 Back처럼 사용자가 이해할 수 있는 경로도 함께 확인하는 편이 좋습니다.

처음 앱의 화면 흐름과 검수 기준을 함께 정리하려면 유인어스 앱 MVP 상담에서 현재 기획을 공유해 주세요.