에뮬레이터 세이브 손실: 진행 상황을 복구할 수 있을까요?

브라우저 기반 에뮬레이터에서 세이브 손실이 발생했다면, 결론부터 말씀드리자면 복구가 가능한 경우는 거의 없습니다. 브라우저 에뮬레이터는 세이브 데이터를 하드 드라이브의 파일로 저장하는 것이 아니라, 브라우저에 내장된 구조적 키-값 데이터베이스인 IndexedDB에 저장합니다. 해당 저장소가 초기화되거나 애초에 쓰기가 이루어지지 않았다면, 그 데이터는 사라진 것입니다.

IndexedDB는 웹 스토리지 명세의 일부로, 출처(프로토콜 + 도메인 + 포트)별, 그리고 브라우저 프로필별로 샌드박스 처리됩니다. 즉, Chrome에서 https://retrogamespace.com 에 생성한 세이브 데이터는 Firefox, Safari, 혹은 동일한 컴퓨터의 다른 Chrome 프로필에서 생성된 데이터와 완전히 분리되어 있습니다. 브라우저는 이 데이터를 탐색하거나 내보낼 수 있는 사용자 인터페이스를 별도로 제공하지 않으며, 모든 관리는 해당 탭에서 실행 중인 웹 애플리케이션이 담당합니다.

에뮬레이터의 관점에서 세이브 쓰기는 비교적 단순한 과정입니다. 에뮬레이션된 게임이 SRAM (배터리 백업 세이브 RAM)을 플러시할 때, 에뮬레이터는 해당 메모리 영역을 직렬화하여 IndexedDB에 저장합니다. 페이지를 불러올 때는 이를 다시 읽어옵니다. IndexedDB가 해당 레코드를 유지하는 한 모든 것이 정상적으로 동작합니다 — 그런데 그렇지 못한 경우가 여럿 있습니다.

브라우저 세이브 데이터 소실 사건에는 네 가지 뚜렷한 원인이 있으며, 각각 복구 가능성이 다릅니다. 어떤 원인이 해당되는지 파악하는 것이 다음 조치를 결정하는 첫걸음입니다.

• 인터넷 사용 기록 삭제: Chrome, Firefox, Edge, Safari 모두 '사이트 데이터' 또는 '쿠키 및 사이트 데이터'를 삭제하는 옵션을 제공합니다. IndexedDB는 사이트 데이터로 분류됩니다. 쿠키만 삭제하려는 의도였더라도 해당 옵션을 선택했다면, 모든 출처의 IndexedDB 데이터베이스가 동시에 삭제됩니다. 이는 데스크톱에서 가장 흔한 원인이며, 아무런 경고 없이 진행됩니다.
• 시크릿 또는 프라이빗 브라우징 모드: 브라우저는 프라이빗 창이 닫힐 때 IndexedDB를 디스크에 저장하지 않도록 명시적으로 설계되어 있습니다. 해당 세션 중에 저장된 세이브 데이터는 RAM에만 존재했으며, 창을 닫는 순간 완전히 삭제됩니다. 복구 가능한 사본은 존재하지 않습니다.
• iOS Safari 스토리지 할당량 초과 삭제: iOS의 Apple WebKit 엔진은 특정 조건에서 웹사이트 스토리지에 7일 비활성 규칙을 적용하며, 기기 저장 공간이 심각하게 부족할 경우 OS가 사이트 데이터를 강제로 삭제할 수 있습니다. iPhone 및 iPad의 Safari는 원인 불명의 에뮬레이터 진행 상황 손실로 가장 자주 언급되는 환경입니다.
• 다른 브라우저 프로필 또는 브라우저 사용: IndexedDB는 출처 및 프로필 단위로 범위가 지정되므로, 회사용 Chrome 프로필에서 개인용 Chrome 프로필로 전환하거나 Chrome에서 Firefox로 전환하면 완전히 비어 있는 데이터베이스가 표시됩니다. 이전 세이브 데이터는 다른 프로필에 그대로 존재하므로, 해당 프로필로 다시 전환하면 간단히 복구할 수 있습니다.

한 가지 더 언급할 만한 예외 케이스가 있습니다. '프라이버시' 또는 '추적 방지' 기능을 내세우는 일부 브라우저 확장 프로그램은 일정한 주기로 사이트 스토리지를 자동 삭제합니다. 위의 네 가지 원인 중 어느 것도 해당되지 않는다면, 설치된 확장 프로그램 중 스토리지 삭제 동작을 수행하는 것이 없는지 확인해 보세요.

에뮬레이터 세이브 데이터 복구를 시도하려면 다음 조건 중 최소 하나가 충족되어야 합니다. 모든 경우에 적용되는 조건은 없으므로, 시간을 투자하기 전에 각 항목을 꼼꼼히 읽어보시기 바랍니다.

1. 손실 전에 .srm 파일을 내보낸 경우: 이전에 에뮬레이터의 내보내기 또는 다운로드 기능을 사용하여 .srm(SRAM 덤프) 파일을 기기에 저장했다면, 해당 파일은 여전히 하드 드라이브에 존재합니다. 에뮬레이터의 가져오기 기능을 통해 파일을 다시 불러오면 내보내기 시점의 진행 상황으로 복원됩니다.
2. 다른 브라우저 프로필에 세이브 데이터가 있는 경우: 브라우저의 프로필 전환 기능을 열어 다른 프로필이 있는지 확인하세요. 각 프로필에서 에뮬레이터 사이트로 이동해 보세요. 세이브 데이터가 확인되면 즉시 .srm 파일로 내보낸 뒤, 기본 프로필로 다시 가져오세요.
3. 클라우드 또는 동기화 백업이 있는 경우: 사용 중이던 에뮬레이터가 클라우드 동기화 서비스와 연동되어 있다면, 해당 서비스의 웹 인터페이스나 앱에서 저장된 세이브 스테이트 또는 SRAM 파일을 확인해 보세요. RGS의 클라우드 동기화 기능은 향후 릴리스에서 제공될 예정입니다 — 현재 제공 여부는 사이트 블로그를 참고하세요.
4. Android Chrome을 사용 중이며 재부팅하지 않은 경우: Android의 Chrome은 IndexedDB 쓰기를 디스크에 저장하기 전에 메모리에 캐시합니다. 충돌과 재부팅 사이의 짧은 시간 내에 해당 페이지를 다시 방문하여 강제 동기화를 유발하면 마지막 세션을 복구할 수 있는 경우가 있습니다. 다만 이는 신뢰할 수 없는 예외 케이스이므로, 확실한 방법으로 기대해서는 안 됩니다.

개발자 도구 없이는 브라우저 내부에서 IndexedDB 데이터를 직접 추출할 방법이 없으며, 설령 도구를 사용하더라도 데이터베이스가 삭제되지 않은 경우에만 가능합니다. Chrome에서는 DevTools(F12)를 열고 Application → Storage → IndexedDB로 이동하여 해당 사이트의 데이터베이스가 아직 남아 있는지 확인할 수 있습니다. 항목이 표시된다면, 에뮬레이터 자체의 가져오기/내보내기 도구를 사용하는 것이 올바른 추출 방법입니다. Chrome이 내부적으로 사용하는 LevelDB 파일을 직접 편집하려는 시도는 삼가십시오. 다른 브라우저 데이터가 손상될 위험이 있습니다.

IndexedDB 저장 데이터 복구에 관한 냉혹한 현실은, 데이터베이스 레코드가 일단 삭제되면 휴지통도, 섀도 복사본도, 의존할 수 있는 서버 측 백업도 전혀 존재하지 않는다는 점입니다. 바탕 화면에서 삭제한 파일과 달리, IndexedDB 데이터는 사용자가 접근할 수 있는 방식으로 운영 체제의 파일 삭제 파이프라인을 거치지 않습니다.

구체적으로, 다음과 같은 상황에서는 복구가 불가능합니다. 브라우저에서 '사이트 데이터 삭제' 또는 이에 상응하는 옵션을 사용한 경우, 시크릿/사생활 보호 창에서 세션이 진행된 경우, iOS Safari가 비활성 상태 또는 저장 공간 부족으로 인해 데이터를 삭제한 경우, 또는 개인 정보 보호 확장 프로그램이 예약된 일정에 따라 저장소를 삭제한 경우입니다. 이 네 가지 경우 모두, 해당 데이터의 실제 바이트는 이미 덮어쓰여졌거나 처음부터 영구 저장소에 기록되지 않았습니다.

포렌식 디스크 복구 도구(파일 삭제 취소에 사용되는 도구 등)는 이 경우 도움이 되지 않습니다. Chrome, Firefox, Safari 모두 IndexedDB를 압축된 이진 형식(Chrome의 경우 LevelDB)으로 저장하며, 일반적인 브라우저 작동 중에 이 파일들은 지속적으로 다시 작성됩니다. 저장 데이터가 사라진 것을 알아차렸을 때쯤이면, 해당 데이터가 존재했던 물리적 섹터는 이미 거의 확실하게 덮어쓰여진 상태입니다.

온라인에 떠도는 서드파티 'IndexedDB 복구' 유틸리티는 권장하지 않습니다. 저희가 검토해 본 것들은 게임 저장 데이터와 무관한 일반적인 파일 시그니처를 스캔하거나, 브라우저 내부 정보를 클로즈드 소스 애플리케이션에 넘겨야 하는 방식이었습니다. 어느 쪽도 이 용도에서는 신뢰할 수 없으며, 두 방식 모두 실질적인 위험을 수반합니다.

브라우저 저장 데이터가 사라지는 상황에 대한 유일하게 신뢰할 수 있는 방어책은, IndexedDB 외부에 저장 데이터의 복사본을 별도로 보관하는 것입니다. 즉, 의미 있는 플레이 세션이 끝날 때마다 — 가급적 매번 — .srm 파일을 내보내고, 브라우저 데이터 삭제의 영향을 받지 않는 곳에 보관해야 합니다.

• .srm 파일을 정기적으로 내보내기: 각 세션이 끝난 후 에뮬레이터의 내보내기 기능을 사용하고, 생성된 파일을 하드 드라이브나 클라우드 저장소의 폴더에 저장하십시오. .srm 파일은 용량이 작아(표준 SRAM을 사용하는 Super Nintendo 게임의 경우 일반적으로 8 KB), 다운로드하는 데 몇 초면 충분합니다.
• 날짜가 표시된 복사본을 최소 두 개 보관하기: 파일 이름에 날짜 접미사를 붙이면(예: zelda-lttp-2024-11-03.srm) 저장 데이터가 손상되었을 때 이전 체크포인트로 되돌리기가 쉬워집니다. 최근 백업 하나도 없는 것보다는 낫지만, 날짜가 다른 백업 두 개가 있으면 가장 최근 내보내기에 문제가 생기더라도 복구 지점이 확보됩니다.
• 소중한 게임은 절대 시크릿 모드로 플레이하지 않기: 시크릿 모드는 테스트나 일회성 세션에 적합합니다. 수십 시간에 걸친 RPG 플레이스루에는 적합하지 않습니다. 창을 닫는 순간 브라우저가 모든 저장소를 조건 없이 삭제하기 때문입니다.
• iOS에서는 최소 7일마다 에뮬레이터 사이트를 방문하기: Apple의 WebKit 저장소 삭제 타이머는 사이트 방문 시마다 초기화됩니다. 정기적인 방문은 iOS가 데이터를 삭제할 위험을 줄여주지만 — 완전히 없애지는 못합니다.
• RGS 클라우드 동기화 기능을 주목하기: 클라우드 동기화가 출시되면 저장 데이터를 서버 측에 보관하고 여러 기기에서 동기화할 수 있게 됩니다. 해당 기능이 제공되기 전까지는 .srm 내보내기가 이 사이트에서 기기 간 백업을 위한 유일한 방법입니다. 출시 공지는 RGS 블로그에서 확인하십시오.
• 사이트 데이터를 삭제하는 브라우저 확장 프로그램 주의하기: 개인 정보 보호 확장 프로그램을 사용 중이라면, 자동 저장소 삭제 일정 설정이 있는지 확인하고 해당 기능을 비활성화하거나 retrogamespace.com을 허용 목록에 추가하십시오.

iOS 사용자에게 플랫폼 관련 주의 사항을 하나 안내드립니다. iOS 17부터는 웹사이트를 Progressive Web App으로 홈 화면에 추가할 수 있습니다. 홈 화면 PWA 내에서 생성된 저장소는 일반 브라우저와 별도의 할당량 컨테이너에 보관되며, Safari 탭에 적용되는 7일 삭제 규칙의 적용을 받지 않습니다. iPhone이나 iPad에서 자주 플레이하신다면, 사이트를 홈 화면에 추가하는 것은 완전한 해결책은 아니더라도 구조적으로 의미 있는 개선입니다. 그럼에도 불구하고 .srm 파일은 계속 내보내셔야 합니다. PWA 컨테이너도 수동으로 삭제되거나 앱이 홈 화면에서 제거될 때 초기화될 수 있기 때문입니다.