앱 MVP 상태 복원: 회전·시스템 종료 뒤 되돌릴 것 5가지
앱을 잠깐 벗어났다가 돌아왔는데 검색어가 사라지거나, 작성하던 화면이 처음으로 돌아가면 사용자는 앱이 "멈췄다"고 느끼기 쉽습니다. 하지만 모든 화면 값을 영구 보관하는 것이 답은 아닙니다. 앱 MVP에서는 다시 열었을 때 이어져야 하는 작업 맥락과 처음부터 다시 받아도 되는 화면 표현을 나눠야 합니다.
Android는 화면 회전 같은 구성 변경과 시스템이 프로세스를 종료한 상황을 구분하며, UI 상태의 성격에 따라 ViewModel, 저장 상태 API, 로컬 저장소를 함께 쓰도록 안내합니다. Apple도 앱이 중단된 뒤 시스템이 종료될 수 있으므로, 사용자가 이전 작업 지점으로 돌아갈 수 있게 UI 상태 보존·복원을 지원합니다.
이 글은 기술 구현을 정답처럼 제시하지 않고, 출시 전에 어떤 상태를 남길지 정하는 MVP 의사결정 기준을 정리합니다.
먼저 구분할 것: 화면이 다시 그려지는 이유
같은 "화면이 초기화됐다"는 현상도 원인은 다릅니다. 회전이나 창 크기 변경처럼 앱이 살아 있는 상황에서는 메모리 안의 상태가 이어질 수 있습니다. 반면 시스템이 자원을 확보하려고 프로세스를 종료한 뒤 재생성하면, 메모리에만 있던 값은 남아 있지 않습니다. Android 공식 문서는 ViewModel이 구성 변경에는 유용하지만 시스템 주도 프로세스 종료 때는 제거된다고 설명합니다.
이 경우 가벼운 UI 상태는 저장 상태 API, 오래 보관해야 할 앱 데이터는 로컬 저장소를 검토해야 합니다.
Apple의 UIKit 문서도 중단이 길어지면 시스템이 앱을 종료할 수 있으며, 상태 보존·복원은 사용자가 이전 작업 지점으로 돌아오는 데 도움을 준다고 안내합니다. 즉, "회전 테스트는 통과했다"가 "재실행 뒤에도 사용자가 맥락을 잃지 않는다"는 뜻은 아닙니다.
우리 앱 MVP에서 남길 상태와 다시 불러올 데이터를 구분해 상담하기
MVP에서 되돌릴 상태를 고르는 5가지 기준
1. 사용자가 지금 막 하던 일을 이어야 하는가
검색 필드의 입력값, 선택한 탭, 작성 중인 짧은 문구, 현재 보고 있던 항목처럼 사용자가 바로 이어서 행동할 값은 후보가 됩니다. 반대로 일회성 토스트, 자동 재생 위치처럼 돌아왔을 때 의미가 바뀌거나 오래된 값은 굳이 복원하지 않는 편이 낫습니다. 핵심은 데이터량이 아니라, 사라졌을 때 사용자가 같은 행동을 다시 해야 하는지입니다.
2. 값 자체가 아니라 식별자만 남겨도 되는가
상품 상세 전체, 검색 결과 목록, 서버 응답을 통째로 저장하면 오래된 내용이나 용량 문제가 생길 수 있습니다. 많은 경우에는 선택한 항목의 ID, 검색어, 필터 값, 작성 단계처럼 화면을 다시 구성하는 데 필요한 최소 단서만 남기고 최신 데이터는 다시 읽는 방식이 더 안전합니다.
Android도 복잡하거나 큰 데이터에는 영구 로컬 저장소를 검토하되, 저장 상태 API는 장기 저장소의 대체물이 아니라고 설명합니다.
3. 다시 불러왔을 때도 유효한가
쿠폰 잔여 수량, 권한 상태, 결제 단계, 예약 가능 시간처럼 서버에서 달라질 수 있는 값을 옛 화면 그대로 보여 주면 오히려 혼란을 줍니다. 이 경우에는 "어디로 돌아갈지"만 복원하고, 금액·권한·재고 같은 사실은 다시 조회한 뒤 표시하는 경계를 정하세요. 복원은 과거 화면의 복제가 아니라, 사용자에게 다음 판단을 할 수 있는 위치를 돌려주는 일입니다.
상태 예시 | MVP에서 남길 최소 단서 | 재진입 때 할 일 |
|---|---|---|
검색 화면 | 검색어·필터·정렬 선택 | 결과는 최신 조건으로 재조회 |
작성 폼 | 임시 입력값·현재 단계 | 제출 완료 여부와 필수 조건 재확인 |
상세 화면 | 항목 ID·선택 탭 | 해당 항목 존재·권한·최신 내용 확인 |
결제·인증 흐름 | 복귀 목적지 또는 안전한 재시작 지점 | 민감한 값은 다시 인증하고 현재 상태 조회 |
4. 민감하거나 공유되면 안 되는 값은 없는가
비밀번호, 인증 코드, 결제 수단 전체 정보, 접근 토큰처럼 저장 자체가 위험한 값은 복원 대상에서 제외해야 합니다. 사용자가 다시 인증해야 하는 단계는 불편해 보여도, 복원보다 안전한 재시작이 우선일 수 있습니다.
어떤 값이 민감 화면에 남는지 점검할 때는 민감 화면 보호 기준도 함께 확인해 보세요.
5. 복원에 실패했을 때의 다음 화면이 있는가
항목이 삭제됐거나 권한이 사라졌다면, 과거 화면으로 억지로 들어가게 하지 말고 이유와 다음 선택지를 보여줘야 합니다. 예를 들어 검색 결과가 없어졌으면 검색어는 남기되 0건 상태를 보여줄 수 있고, 작성 초안이 없으면 새 작성 화면으로 자연스럽게 이동할 수 있습니다.
뒤로 가기와 복귀 흐름의 맥락은 MVP 뒤로가기 기준, 검색 상태 처리는 MVP 검색 상태 기준에서 이어서 볼 수 있습니다.
구현 선택보다 먼저 만드는 상태 목록
개발 논의 전에 화면마다 아래처럼 한 줄로 합의하면 범위가 선명해집니다.
사용자가 무엇을 하다가 떠날 수 있는가?
돌아왔을 때 반드시 남아야 하는 최소 단서는 무엇인가?
최신성·권한·보안 때문에 다시 확인할 값은 무엇인가?
복원 실패 시 보여 줄 안내와 다음 행동은 무엇인가?
회전, 백그라운드 전환, 시스템 종료 뒤 재실행에서 각각 무엇을 확인할 것인가?
Android의 저장 상태 안내는 상태가 비즈니스 로직에 쓰이면 ViewModel과 SavedStateHandle, UI 로직에만 쓰이면 Compose의 저장 상태 API를 고려하도록 구분합니다. Apple의 상태 복원 예시는 장면별 NSUserActivity로 인터페이스를 다시 구성하는 데 필요한 정보를 보관하는 방식을 소개합니다.
어느 API를 택하든, 이 목록에서 정한 "최소 단서"를 넘겨 모든 응답과 화면을 저장하지 않는 것이 출발점입니다.
출시 전에 해볼 4가지 재진입 테스트
화면 회전 또는 창 크기 변경 뒤, 입력·선택·현재 위치가 의도한 범위에서만 유지되는지 확인합니다.
앱을 백그라운드로 보낸 뒤 돌아와, 서버에서 달라질 수 있는 값이 최신 상태로 바뀌는지 확인합니다.
개발 환경에서 시스템 종료 뒤 재실행 상황을 재현해, 복원할 값과 초기화할 값이 기획과 같은지 확인합니다.
삭제된 항목, 만료된 권한, 네트워크 실패가 섞였을 때 사용자가 빈 화면이나 잘못된 완료 화면에 갇히지 않는지 확인합니다.
이 테스트는 플랫폼 심사나 보안을 보장하지 않습니다. 서비스의 데이터 처리, 인증 방식, OS 버전, 실제 기기 조건에 따라 별도 검토가 필요합니다. 다만 MVP의 상태 복원 범위를 미리 정하면 "앱이 다시 열렸지만 사용자는 어디에 있었는지 모르는" 경험을 줄이는 데 도움이 됩니다.
자주 묻는 질문
모든 입력값을 자동 저장하면 상태 복원이 충분한가요?
아닙니다. 사용자에게 다시 필요한 최소 입력과 민감 정보, 오래된 값이 될 수 있는 서버 데이터를 구분해야 합니다. 제출 상태나 권한처럼 바뀔 수 있는 사실은 재진입 시 다시 확인하세요.
ViewModel이 있으면 프로세스 종료 뒤에도 상태가 남나요?
그렇지 않습니다. Android는 ViewModel이 구성 변경에는 유지되지만 시스템 주도 프로세스 종료 때는 제거된다고 안내합니다. 종료 뒤에도 필요한 가벼운 상태는 저장 상태 API, 장기 데이터는 적절한 영구 저장소를 별도로 검토해야 합니다.
iOS와 Android에서 같은 상태를 똑같이 복원해야 하나요?
사용자가 이어야 할 작업 맥락은 같을 수 있지만, 플랫폼의 UI·수명 주기·지원 방식은 다를 수 있습니다. 공통 의사결정 목록을 두고 각 플랫폼의 공식 문서와 실제 기기 테스트로 구현 범위를 확인하세요.
이 기준을 따르면 앱 심사나 개인정보 보호가 보장되나요?
아닙니다. 이 글은 MVP 화면 범위와 재진입 QA를 정하기 위한 기획 기준입니다. 실제 심사, 데이터 처리, 보안 설계와 법적 의무는 서비스 상황에 맞춰 별도로 확인해야 합니다.
우리 서비스의 재진입 흐름과 MVP 출시 범위를 함께 점검하기