Android 17은 비정상적으로 많은 메모리를 사용하는 앱을 처리하는 방식을 바꾼다. Google은 먼저 Pixel 기기에 앱별 메모리 한도를 도입해 하나의 앱이 RAM을 과도하게 사용하면서 휴대전화 전체의 반응성을 떨어뜨리는 일을 막는다. 할당량을 넘은 앱은 속도가 제한되고 일부 데이터가 압축 메모리로 이동하며, 사용량이 계속 늘면 Android가 프로세스를 종료할 수 있다. 메모리 효율은 이제 단순한 권장 사항이 아니라 플랫폼 동작 조건이 되고 있다.
Android 17의 앱별 메모리 예산
Google은 한도에 닿는 즉시 앱을 닫는 것이 아니라 단계적으로 대응한다고 설명한다. 전체 기기의 반응성을 보호하면서 앱이 회복할 기회를 주는 방식이다. 게임, 미디어 도구, 복잡한 앱처럼 많은 데이터를 오랫동안 메모리에 유지하는 소프트웨어가 특히 영향을 받을 수 있다.
RAM 한도를 넘으면 일어나는 일
앱이 할당된 메모리 한도에 도달하면 Android는 일부 메모리 페이지를 압축 RAM 영역인 zRAM으로 강제로 옮길 수 있다. 물리 RAM 압박은 줄지만 압축과 해제에 CPU 자원이 필요해 앱이 종료되기 전에도 UI 끊김이나 지연이 나타날 수 있다.
– 1단계 — zRAM 스와핑: 메모리 페이지를 압축해 zRAM으로 옮겨 물리 RAM 부담을 낮춘다. 프로세스는 유지되지만 CPU 부하로 느려질 수 있다.
– 2단계 — 프로세스 종료: zRAM 임계치를 넘어 사용량이 계속 증가하면 Android가 앱을 종료할 수 있다. 개발자는 ApplicationExitInfo에서 확인할 수 있으며 설명에 “MemoryLimiter:AnonSwap”이 포함될 수 있다.
Google이 지금 메모리를 더 엄격히 관리하는 이유
Google은 메모리 가격 상승으로 일부 신형 기기가 물리 메모리 용량을 유지하거나 줄이는 시장 변화를 배경으로 든다. 사용자는 여전히 빠르고 부드러운 앱을 기대하기 때문에 Android는 최적화가 부족한 하나의 프로세스가 전체 기기를 느리게 하지 못하도록 더 강한 보호가 필요하다는 설명이다.
정책은 Pixel에만 머물지 않는다. Android 17은 Pixel에서 시작하지만 향후 1년 동안 더 많은 제조사가 4GB부터 16GB 이상까지 다양한 RAM 구성의 기기에 앱별 메모리 한도를 적용할 예정이다. 개발자는 이를 Pixel 전용 문제로 볼 수 없다.
개발자와 Android 사용자가 예상할 변화
개발자에게 Google은 사용자 불만을 기다리지 말고 메모리를 측정하라고 권한다. Android vitals는 프로세스 상태와 RAM 등급별 메모리 및 Bitmap Memory를 보여주며, Firebase Crashlytics 20.1.0은 OOM과 Memory Limiter 종료의 디버그 정보를 강화한다. ProfilingManager는 실제 기기에서 힙 덤프와 프로파일을 수집해 메모리 누수와 과도한 할당을 찾는 데 도움을 준다.
사용자 입장에서는 백그라운드 앱 하나가 RAM을 독점해 휴대전화 전체를 느리게 만들 가능성이 줄어든다. 반면 최적화가 부족하거나 메모리를 매우 많이 쓰는 앱은 이전보다 끊기거나 다시 로드되거나 종료될 가능성이 높다. 현재 Android 17 Pixel에서 시작됐고 앞으로 몇 달 동안 다른 제조사로 확대될 전망이며, RAM이 적은 구형·보급형 기기에서 최적화 중요성이 더 커진다.
