앱 MVP Android 메모리 압박: 캐시·프로세스 종료·상태 복원을 나누는 5가지 기준
앱 MVP Android 메모리 압박: 캐시·프로세스 종료·상태 복원을 나누는 5가지 기준
Android 앱 MVP에서 화면을 잠시 떠났다가 돌아왔을 때 목록이 사라지거나, 이미지가 다시 내려받아지거나, 입력하던 값이 초기화되는 일을 모두 “메모리 문제”라고 부르면 대응 범위가 흐려집니다. 캐시를 줄여야 하는 상황, 시스템이 프로세스를 종료한 상황, 화면 상태를 다시 만들어야 하는 상황은 서로 다릅니다. 이 글은 앱이 항상 메모리에 남는다는 전제 대신, 사용자가 핵심 과업을 다시 이어갈 수 있도록 메모리 압박을 검수하는 기준을 정리합니다.
먼저 답하기: 메모리 절약, 프로세스 생존, 화면 복구는 같은 완료 조건이 아닙니다
Android Developers의 메모리 관리 공식 안내는 앱이 참조를 유지하는 메모리는 RAM에 남으며, 더는 필요하지 않은 객체 참조를 놓아야 가비지 컬렉터가 회수할 수 있다고 설명합니다. 반면 사용자가 앱을 떠난 뒤에는 시스템이 프로세스를 캐시해 둘 수 있지만, 메모리가 부족하면 캐시 프로세스를 종료할 수 있습니다. 즉 “지금 화면이 보인다”는 관찰만으로 다음 복귀에서도 같은 메모리·프로세스·화면 상태가 유지된다고 판단할 수 없습니다.
구분 | 확인할 질문 | 같은 완료로 묶으면 안 되는 것 |
|---|---|---|
메모리 사용 | 더 이상 필요하지 않은 큰 객체·이미지·리소스를 계속 잡고 있는가 | 프로세스가 절대 종료되지 않는다는 기대 |
메모리 압박 신호 | 줄이거나 다시 만들 수 있는 캐시가 무엇인가 | 사용자가 입력한 핵심 상태 삭제 |
프로세스 종료 | 종료 뒤 필요한 상태를 어디서 다시 읽거나 복원하는가 | 단순히 Activity가 백그라운드로 감 |
화면 재생성 | 사용자가 하던 과업을 안전하게 이어 갈 수 있는가 | 모든 임시 UI를 영구 저장하는 것 |
출시 QA | 어떤 기기·흐름에서 관찰했는가 | 개발자 기기 한 번의 정상 복귀 |
1. 먼저 ‘다시 만들 수 있는 것’과 ‘잃으면 안 되는 것’을 분리합니다
메모리 압박에 대비한다고 모든 값을 저장하거나 모든 캐시를 유지하면, 오히려 앱이 필요 이상으로 메모리를 점유할 수 있습니다. 먼저 화면에 보이는 값을 다음 세 부류로 나누는 편이 좋습니다.
다시 불러올 수 있는 값: 서버·로컬 DB·파일에서 다시 조회할 수 있는 목록, 미리보기, 파생 화면 데이터
다시 계산할 수 있는 값: 선택 상태에서 계산한 합계, 정렬 결과, UI 효과처럼 원본으로 재구성할 수 있는 값
잃으면 사용자가 곤란한 값: 작성 중인 입력, 진행 중인 다단계 신청의 단계, 아직 전송하지 않은 선택처럼 과업 연속성에 필요한 값
이 분류는 Android 시스템의 고정 규칙이 아니라 MVP 운영을 위한 설계 제안입니다. 중요한 점은 캐시를 비우는 일과 사용자의 업무를 잃지 않는 일을 하나의 토글로 다루지 않는 것입니다. 실제로 어떤 값이 다시 조회 가능한지는 서비스의 동기화, 오프라인 정책, 개인정보 처리 방식에 따라 달라집니다.
Android Developers는 앱 프로세스별 힙의 한도가 기기 메모리 상황에 따라 달라질 수 있고, 한도를 넘겨 추가 할당을 시도하면 `OutOfMemoryError`를 받을 수 있다고 설명합니다. 따라서 “고사양 테스트 기기에서 괜찮았다”는 관찰만으로 이미지·첨부파일·긴 목록을 같은 방식으로 유지해도 안전하다고 일반화하면 안 됩니다.
2. `onTrimMemory` 신호는 저장 완료가 아니라 캐시 정리 우선순위를 정하는 입력입니다
Android의 메모리 문서는 Android 4.1(API 16) 이상에서 `TRIM_MEMORY_EVENTS` 콜백이 프로세스에 대한 상세 메모리 경고를 제공한다고 설명합니다. 이 신호를 받았다고 사용자의 입력을 즉시 버리거나, 서버 저장이 끝났다고 간주해서는 안 됩니다. 이 글의 실무적 해석은 신호를 ‘무엇을 먼저 줄일지’ 판단하는 입력으로 쓰는 것입니다.
예를 들어 다시 내려받을 수 있는 큰 이미지 미리보기, 화면 밖 목록의 파생 결과, 즉시 필요하지 않은 프리로드는 후보가 될 수 있습니다. 반대로 작성 중인 문의 내용처럼 사용자가 다시 만들기 어려운 값은 별도의 복구 경로가 있는지 먼저 확인해야 합니다. 캐시 정리의 범위와 복구 설계는 코드 소유자, 데이터 보존 정책, 오프라인 요구에 맞춰 정하세요.
앱 MVP의 핵심 화면·데이터 보존 범위와 출시 전 검수 항목을 함께 정리해야 한다면, 유인어스에 MVP 범위 상담하기로 현재 사용자 흐름을 공유해 보세요.
3. 앱을 떠난 것과 프로세스가 종료된 것을 구분합니다
Android Developers에 따르면 사용자가 앱을 전경에서 떠나면 시스템은 앱 프로세스를 캐시할 수 있고, 사용자가 다시 돌아올 때 이를 재사용해 앱 전환을 빠르게 할 수 있습니다. 하지만 캐시된 프로세스는 시스템 요구에 따라 언제든 종료될 수 있습니다. 메모리를 적게 쓰면 캐시에 남을 가능성에 도움이 될 수는 있어도, 종료되지 않음을 보장하지는 않습니다.
따라서 QA에서 뒤로 가기, 홈으로 나가기, 다른 앱을 오래 쓰기, 시스템이 프로세스를 정리한 뒤 재진입하는 상황을 같은 “복귀” 결과로 기록하지 마세요. Android의 앱 시작 안내는 시스템이 앱을 메모리에서 내보낸 뒤 다시 실행하는 경우, 프로세스와 Activity가 다시 시작되며 저장된 instance state가 `onCreate`로 전달될 수 있다고 설명합니다. 이것은 모든 데이터가 복구된다는 보장이 아니라, 복구 설계를 검증해야 할 별도 경로가 있다는 뜻입니다.
관찰 상황 | 확인할 결과 | 흔한 오해 |
|---|---|---|
짧게 다른 앱으로 전환 | 현재 프로세스에서 화면이 다시 보이는가 | 프로세스 종료 복구도 검증됨 |
메모리 압박 뒤 재진입 | 캐시가 줄어든 뒤 필수 화면이 다시 만들어지는가 | 화면이 한 번 보이면 데이터가 안전함 |
프로세스 종료 뒤 실행 | 핵심 입력·단계·권한 안내가 정의한 방식으로 복구되는가 | 모든 UI를 그대로 재현해야 함 |
저메모리 기기·분할 화면 | 지원 범위에서 핵심 행동을 끝낼 수 있는가 | 한 기기 성공이 전체 기기 보장 |
4. 앱 시작 시간과 메모리 재생성 비용을 따로 봅니다
캐시를 일률적으로 줄이면 다시 화면을 만들 때 더 많은 작업이 필요할 수 있고, 반대로 오래 유지하면 시스템 전체의 메모리 압박에 영향을 줄 수 있습니다. Android의 시작 시간 문서는 첫 화면 표시 시간(TTID)과 앱이 완전히 상호작용 가능해지는 시간(TTFD)을 서로 다른 지표로 설명합니다. 또한 hot start에서도 메모리 정리 이벤트로 일부 객체가 제거됐다면 다시 만들어야 할 수 있다고 안내합니다.
여기서 중요한 것은 ‘캐시가 남았으니 성능이 좋다’ 또는 ‘캐시를 비웠으니 안정적이다’라는 한 문장 결론을 피하는 것입니다. MVP에서는 다음의 관찰을 따로 남기면 수정 범위를 좁히기 쉽습니다.
어떤 화면·객체가 메모리 압박 전후에 다시 만들어졌는가
첫 화면 표시와 핵심 행동 가능 시점 사이에 무엇이 남았는가
이미지·목록·폼 입력 중 무엇을 다시 조회했고, 무엇을 복원했는가
다시 만들기 실패 시 사용자에게 어떤 재시도·오류 안내를 보여 주는가
실제 기기에서 재현한 조건과 앱 버전은 무엇인가
성능 수치의 목표값은 앱의 사용자 흐름과 대상 기기에 따라 정해야 합니다. Android 공식 문서는 메모리 진단 도구와 프로파일링 경로를 안내하지만, 특정 앱의 출시 가능 여부나 전환 성과를 보장하지는 않습니다.
5. 출시 전에는 ‘메모리가 적을 때의 핵심 과업’을 시나리오로 남깁니다
Android Developers는 저메모리 기기에서도 메모리 압박 환경을 재현해 앱 동작을 검증할 필요가 있다고 안내합니다. 모든 기기·상태를 다 검증한다는 뜻은 아닙니다. 지원 대상 안에서 실제 MVP의 핵심 행동을 고르고, 어떤 상태를 다시 불러오며 어떤 상태를 명시적으로 안내할지 합의하는 편이 현실적입니다.
짧은 QA 기록 템플릿
대상 과업: 예) 작성 중인 문의를 저장하지 않은 상태에서 다른 앱을 사용한 뒤 다시 열기
환경: 앱 버전, Android 버전, 기기 또는 에뮬레이터, 네트워크·화면 상태
압박 또는 전환: 캐시 정리 신호 관찰, 백그라운드 전환, 프로세스 종료 뒤 재실행 중 무엇인가
복구 기준: 다시 조회할 데이터, 보존할 입력, 재시도·오류 안내
결과: 첫 화면, 핵심 행동 가능 시점, 누락된 상태, 재현 가능 여부
후속 조치: 담당 영역, 수정 후보, 다시 확인할 빌드
메모리 압박 대응의 목표는 앱을 메모리에 영구히 남기는 것이 아니라, 시스템이 상태를 바꿔도 사용자가 핵심 과업을 이해하고 이어갈 수 있게 만드는 것입니다.
기기 조건과 사용자 흐름을 기준으로 앱 MVP의 상태 복구·성능·QA 범위를 정리하고 싶다면, 앱 MVP 상태 복원 기준도 함께 확인해 보세요. 이 글은 화면 상태의 제품 설계가 아니라 Android 메모리 압박과 프로세스 경계를 중심으로 다룹니다.
자주 묻는 질문
Android에서 메모리를 줄이면 프로세스가 종료되지 않나요?
아닙니다. Android Developers는 캐시 프로세스가 시스템 요구에 따라 언제든 종료될 수 있다고 설명합니다. 메모리를 적게 쓰는 것은 전체 압박을 줄이는 데 도움이 될 수 있지만, 앱이 계속 살아 있음을 보장하지 않습니다. 종료 뒤 필요한 상태를 어떻게 복구할지도 별도로 정해야 합니다.
`onTrimMemory`가 오면 모든 화면 데이터를 지워야 하나요?
그렇게 단정할 수 없습니다. 이 신호는 메모리 경고를 알려 주는 입력입니다. 다시 만들 수 있는 캐시와 사용자가 잃으면 곤란한 입력·진행 상태를 구분하고, 서비스의 데이터 보존 정책에 맞춰 정리·복구 범위를 정하세요.
화면이 다시 보이면 메모리 대응은 끝난 것인가요?
아닙니다. 현재 프로세스가 캐시에서 재사용된 것인지, 일부 객체만 다시 만들어진 것인지, 프로세스 종료 뒤 저장 상태로 복구된 것인지 구분해야 합니다. 핵심 행동을 끝까지 수행할 수 있는지와 오류·재시도 안내도 따로 확인하세요.
메모리 문제는 고사양 기기에서만 테스트해도 되나요?
권장하기 어렵습니다. Android 공식 문서는 저메모리 기기에서도 메모리 압박 환경을 재현해 동작을 검증할 필요가 있다고 안내합니다. 지원 범위 안의 기기·OS·핵심 과업을 정해 재현 조건과 결과를 기록하세요.
Android MVP의 캐시·복구·핵심 행동 검수 기준을 실제 제품 범위에 맞춰 설계하고 싶다면, 유인어스에 MVP 개발 상담하기로 문의해 보세요.