가상폰 관련 버그


에뮬레이터에서 겪고 계신 현상은 안드로이드 개발자라면 한 번쯤은 반드시 마주하게 되는 '스냅샷 오염(Snapshot Corruption)' 이슈입니다. 특히 최근처럼 API 36 같은 최신 시스템 이미지를 사용하고 Intel Iris Xe 같은 통합 그래픽 환경에서는 더욱 빈번하게 발생합니다.
질문하신 내용들을 바탕으로 스냅샷의 원리와 왜 문제가 반복되는지 정리해 드립니다.
1. 스냅샷(Snapshot)이란 무엇인가?
스냅샷은 말 그대로 **'에뮬레이터의 현재 상태를 사진 찍듯 저장해두는 기능'**입니다. 게임기의 '강제 저장(Save State)'이나 PC의 '최대 절전 모드(Hibernate)'와 원리가 같습니다.
 * 작동 원리: 에뮬레이터를 끌 때 메모리(RAM)의 데이터, CPU의 레지스터 상태, 그리고 GPU의 렌더링 상태를 그대로 디스크 파일(snapshots.img)로 덤프(Dump)합니다.
 * Quick Boot: 다음 실행 시 처음부터 부팅 과정을 거치지 않고, 저장된 파일을 메모리로 바로 올립니다. 덕분에 2~3초 만에 이전에 작업하던 화면이 바로 뜨게 됩니다.
2. 왜 버그가 발생하고, 왜 흔한가요?
스냅샷 버그는 '저장된 시점의 환경'과 '불러오는 시점의 환경'이 어긋날 때 발생합니다. 이는 아주 흔한 버그이며 주된 이유는 다음과 같습니다.
 * GPU 가속의 민감성: 스냅샷은 GPU의 텍스처 정보와 상태까지 저장하려고 시도합니다. 그런데 PC의 그래픽 드라이버가 업데이트되었거나, 에뮬레이터 설정(Renderer)을 바꾼 채로 스냅샷을 로드하면 GPU 경로가 꼬이면서 **검은 화면(Black Screen)**이 나옵니다.
 * API 버전의 불안정성: 지금 사용 중인 API 36은 매우 최신 버전입니다. 구글에서도 최신 API의 호스트 GPU 가속 로직을 계속 수정 중이라, 스냅샷 저장 로직 자체가 완벽하지 않을 수 있습니다.
 * 드라이버 호환성: Intel Iris Xe 드라이버와 에뮬레이터의 Vulkan 구현체 사이에서 상태 값을 복구할 때 오류가 나면 그래픽 초기화가 실패하게 됩니다.
3. 포맷(Wipe Data)을 해도 왜 복구되는 것처럼 보일까요?
사용자 입장에서는 '포맷'을 했으니 깨끗해졌다고 생각하시겠지만, 에뮬레이터의 '자동 저장' 옵션 때문에 오류가 무한 반복될 수 있습니다.
 * 오류의 저장: host 모드에서 그래픽이 깨진 상태로 에뮬레이터를 끕니다. 이때 에뮬레이터는 "깨진 상태" 그대로를 default_boot 스냅샷에 저장합니다.
 * 포맷의 함정: 'Wipe Data'를 하면 사용자 데이터(/data 영역)는 날아가지만, 에뮬레이터의 부팅 상태를 정의하는 스냅샷 정보는 그대로 남아 있거나, 다시 실행할 때 잘못된 GPU 캐시를 참조할 수 있습니다.
 * 임시방편의 부작용: swiftshader_indirect(소프트웨어 렌더링)로 켜서 화면이 잘 나오면, 에뮬레이터를 끌 때 이 '정상적인 상태'가 다시 스냅샷에 덮어씌워집니다. 그래서 그다음에 host로 켜도 잠시 동안은 그 정상적인 스냅샷 정보를 물고 들어와서 잘 되는 것처럼 보이는 것입니다.
> 결론: 문제는 앱 데이터가 아니라 **'에뮬레이터 엔진의 메모리 복구 프로세스'**에 있기 때문에 일반적인 포맷으로는 해결되지 않는 경우가 많습니다.
4. 해결을 위한 체크리스트
설정에서 다음 항목들을 조정하여 스냅샷 문제를 완전히 뿌리 뽑을 수 있습니다.
Step 1: Quick Boot 비활성화 (가장 확실한 방법)
매번 처음부터 부팅하게 만들어 스냅샷 오염을 원천 차단합니다.
 * Android Studio -> Device Manager
 * 해당 AVD의 수정 버튼(연필 아이콘) 클릭
 * Show Advanced Settings 클릭
 * Emulated Performance 항목의 Boot option을 Cold Boot로 변경
Step 2: 스냅샷 수동 삭제
이미 오염된 스냅샷 파일이 문제라면 직접 지워야 합니다.
 * C:\Users\사용자이름\.android\avd\Pixel_10.avd\ 폴더로 이동
 * snapshots 폴더 내부의 파일들을 삭제하거나, snapshots.img 파일을 삭제합니다.
Step 3: GPU 모드 고정
auto 대신 명확하게 설정해 주는 것이 좋습니다.
 * 안정성 우선: Software - GLES (속도는 느리지만 검은 화면 확률 거의 없음)
 * 성능 우선: Hardware - GLES 2.0 (현재 Intel 드라이버와 충돌 날 확률 있음)
지금 상황에서는 Cold Boot 설정만 해주셔도 "어제는 됐는데 오늘은 왜 안 되지?" 하는 스트레스의 90%는 사라질 것입니다. 특히 API 36 같은 최전선 버전에서는 성능보다 안정적인 부팅 환경을 먼저 확보하는 것이 정신 건강에 이롭습니다.
현재 개발 중인 앱의 UI가 복잡해질수록 GPU 부하가 늘어나니, 가급적 **실제 기기(Physical Device)**를 연결해 테스트하는 비중을 늘려보시는 것도 좋은 방법입니다.
혹시 AVD 설정 화면에서 특정 옵션을 찾는 데 어려움이 있으시면 바로 말씀해 주세요! 해당 부분만 따로 짚어드리겠습니다.

댓글

이 블로그의 인기 게시물

발로란트 1067 오류

허리 펴면 멍든 느낌으로 아풀때 척추 경직