콘솔 저장 공간 부족 시 패치·세이브·스크린샷 실패 메시지 검증 가이드
콘솔 저장 공간이 부족할 때 패치 설치, 세이브 기록, 스크린샷 캡처가 어떻게 실패하는지 검증하는 QA 절차와 오류 메시지 설계 기준을 정리합니다.

핵심 요약
콘솔의 저장 공간 부족 테스트는 표시된 여유 공간이 아니라 실제로 쓸 수 있는 usableFreeBytes와 작업별 임시 공간까지 기준으로 검증해야 합니다. 패치·세이브·스크린샷은 실패 시점을 구분하고 데이터 손상 여부를 확인한 뒤 사용자가 다음 행동을 알 수 있는 메시지를 보여줘야 합니다.
핵심 판정식은 다음과 같습니다.
여기서 requiredBytes는 최종 결과물 크기이고 temporaryBytes는 기존 파일을 유지한 채 새 파일을 쓰거나 압축을 푸는 데 필요한 추가 공간입니다.
콘솔 저장 공간 부족 오류는 왜 작업마다 다르게 발생하는가?
저장 공간을 사용하는 방식이 작업마다 다르기 때문입니다.
- 패치: 다운로드 파일, 압축 해제 공간, 기존 파일 교체를 위한 임시 공간이 필요합니다.
- 세이브: 세이브 파일과 메타데이터를 기록하고 경우에 따라 백업 또는 저널 파일을 생성합니다.
- 스크린샷: 이미지 인코딩 버퍼와 캡처 파일 저장 공간이 필요합니다.
- 운영체제: 표시된 여유 공간 중 일부를 시스템 예약 영역으로 사용할 수 있습니다.
따라서 “여유 공간이 500MB 이상이면 성공”처럼 단일 기준을 적용하면 실제 콘솔에서만 실패하는 문제가 생길 수 있습니다. 플랫폼별 저장소 API는 어댑터로 감싸고 게임 로직에는 다음과 같은 공통 결과를 전달하는 편이 안전합니다.
public enum StorageCheckResult
{
Available,
InsufficientSpace,
StorageUnavailable,
PermissionDenied,
UnknownFailure
}
public sealed class StorageRequirement
{
public string Operation { get; }
public long RequiredBytes { get; }
public long TemporaryBytes { get; }
public long SafetyMarginBytes { get; }
public StorageRequirement(string operation, long requiredBytes,
long temporaryBytes, long safetyMarginBytes)
{
Operation = operation;
RequiredBytes = requiredBytes;
TemporaryBytes = temporaryBytes;
SafetyMarginBytes = safetyMarginBytes;
}
}
패치·세이브·스크린샷의 저장 공간 요구사항 비교
| 작업 | 확인해야 할 공간 | 주요 실패 시점 | 데이터 보호 기준 |
|---|---|---|---|
| 패치 설치 | 다운로드 + 압축 해제 + 교체 임시 공간 | 다운로드 전, 설치 중, 재시작 후 | 기존 실행 가능 버전 유지 |
| 세이브 기록 | 세이브 파일 + 백업 또는 저널 공간 | 기록 시작, 교체 중, 동기화 중 | 이전 정상 세이브 보존 |
| 스크린샷 캡처 | 인코딩 버퍼 + 이미지 파일 공간 | 캡처 버튼 입력, 인코딩 완료, 저장 직전 | 게임 플레이와 현재 상태 유지 |
QA 케이스에는 requiredBytes, temporaryBytes, usableFreeBytes, 파일시스템 오류 코드, 사용자에게 표시된 메시지를 함께 기록합니다. 파일시스템 오류 코드는 플랫폼별로 다를 수 있으므로 테스트 리포트에는 원본 코드와 게임 내부 매핑 결과를 모두 남겨야 합니다.
저장 공간 부족 상태를 어떻게 재현할까?
실제 콘솔 저장소를 무작정 채우는 방법만 사용하면 재현 시간이 길고 테스트 환경도 쉽게 오염됩니다. 다음 세 가지 방법을 조합하는 것이 효율적입니다.
1. 경계값을 계산한다
최소한 다음 상태를 준비합니다.
| 상태 | 조건 예시 | 기대 결과 |
|---|---|---|
| 충분한 공간 | usableFreeBytes > requiredBytes + temporaryBytes + safetyMarginBytes | 작업 성공 |
| 정확한 경계 | usableFreeBytes = requiredBytes + temporaryBytes + safetyMarginBytes | 정책에 따라 성공 또는 보수적 차단 |
| 부족한 공간 | usableFreeBytes < requiredBytes + temporaryBytes + safetyMarginBytes | 작업 시작 전 차단 |
| 설치 중 부족 | 시작 시 충분하지만 임시 파일 생성 후 부족 | 롤백 후 기존 데이터 유지 |
| 저장소 불가 | 저장소 분리, 권한 거부, I/O 오류 | 저장소 오류 메시지 표시 |
여기서 safetyMarginBytes는 임의의 큰 값이 아니라 플랫폼 저장소 동작과 파일시스템 메타데이터를 고려한 제품 정책값이어야 합니다. 정책값은 빌드별로 변경될 수 있으므로 로그에 반드시 남깁니다.
2. 저장소 상태를 주입한다
게임 코드가 플랫폼 API를 직접 호출하면 자동화 테스트가 어려워집니다. IStorageProvider 같은 인터페이스를 만들고 정상 저장소, 부족한 저장소, 쓰기 실패 저장소를 테스트 더블로 주입합니다.
public interface IStorageProvider
{
long GetUsableFreeBytes();
Task<StorageCheckResult> WriteAtomicallyAsync(
string targetPath,
ReadOnlyMemory<byte> data,
CancellationToken cancellationToken);
}
public sealed class FakeStorageProvider : IStorageProvider
{
public long UsableFreeBytes { get; set; }
public bool FailDuringCommit { get; set; }
public long GetUsableFreeBytes() => UsableFreeBytes;
public Task<StorageCheckResult> WriteAtomicallyAsync(
string targetPath,
ReadOnlyMemory<byte> data,
CancellationToken cancellationToken)
{
return Task.FromResult(
FailDuringCommit
? StorageCheckResult.InsufficientSpace
: StorageCheckResult.Available);
}
}
이 코드는 특정 콘솔 SDK의 실제 API를 대체하는 예시가 아니라 저장소 상태와 실패 지점을 분리하기 위한 구조입니다. 콘솔별 구현은 IStorageProvider 뒤에 배치해야 합니다.
3. 실제 콘솔에서 최종 확인한다
에뮬레이터나 테스트 더블은 오류 분기와 메시지 연결을 검증하는 데 유용하지만 실제 콘솔의 저장소 예약 영역, 파일시스템 동작, 백그라운드 다운로드 정책까지 재현하지는 못합니다. 릴리스 후보 빌드에서는 실제 기기에서 다음을 확인합니다.
- 테스트 계정과 일반 사용자 계정에서 저장소 상태를 준비합니다.
- 게임 설치 공간과 별도 세이브 공간의 잔여 용량을 각각 기록합니다.
- 패치·세이브·스크린샷을 단독으로 실행한 뒤 순서를 바꿔 반복합니다.
- 작업 중 전원 종료, 앱 종료, 네트워크 중단, 저장소 부족 상태를 조합합니다.
- 재실행 후 데이터와 메시지가 정상인지 확인합니다.
실패 메시지는 어떤 정보를 포함해야 하는가?
좋은 메시지는 원인과 다음 행동을 함께 알려줍니다. “저장 실패”처럼 결과만 표시하면 사용자는 세이브 슬롯 문제인지 콘솔 저장 공간 문제인지 판단할 수 없습니다.
| 상황 | 피해야 할 메시지 | 권장 메시지 구성 |
|---|---|---|
| 패치 시작 전 공간 부족 | 설치에 실패했습니다 | 저장 공간이 부족해 업데이트를 설치할 수 없습니다. 최소 필요 공간을 확보한 뒤 다시 시도하세요. |
| 세이브 기록 실패 | 세이브 오류 | 저장 공간이 부족해 진행 상황을 저장하지 못했습니다. 게임을 종료하기 전에 공간을 확보하세요. |
| 스크린샷 실패 | 캡처 실패 | 스크린샷을 저장할 공간이 부족합니다. 콘솔 저장 공간을 확보한 뒤 다시 시도하세요. |
| 저장소 접근 불가 | 알 수 없는 오류 | 저장 장치에 접근할 수 없습니다. 저장 장치 연결과 콘솔 상태를 확인하세요. |
| 설치 중 실패 후 롤백 | 패치 실패 | 업데이트를 완료하지 못해 이전 버전으로 복구했습니다. 저장 공간을 확보한 뒤 다시 시도하세요. |
메시지는 다음 조건을 만족해야 합니다.
- 실패한 작업을 명시한다.
- 저장 공간 부족인지 저장소 접근 오류인지 구분한다.
- 사용자가 할 수 있는 다음 행동을 제시한다.
- 세이브 데이터가 보존되었는지 또는 재시도가 필요한지 알려준다.
- 현지화 문자열 길이가 UI를 넘지 않는다.
- 오류 코드나 내부 경로 같은 개발자 정보는 사용자 메시지와 분리한다.
패치·세이브·스크린샷 실패 흐름을 어떻게 검증할까?
작업 시작 전 사전 검사와 실제 기록 중 오류를 분리하면 누락되는 메시지가 줄어듭니다. 특히 사전 검사에 통과한 뒤 임시 공간 부족으로 실패하는 경로를 별도 케이스로 유지해야 합니다.
flowchart TD
A[작업 요청] --> B{저장소 상태 확인}
B -->|공간 부족| C[작업별 공간 부족 메시지]
B -->|저장소 접근 불가| D[저장소 접근 오류 메시지]
B -->|충분한 공간| E[임시 데이터 생성]
E --> F{실제 쓰기 성공}
F -->|성공| G[커밋 및 성공 UI]
F -->|실패| H[임시 데이터 삭제 또는 롤백]
H --> I[원인별 실패 메시지]
패치 설치 테스트
- 패치 전 현재 버전으로 게임을 실행하고 세이브와 설정을 확인합니다.
- 다운로드에 필요한 공간은 충분하지만 압축 해제 공간이 부족한 상태를 만듭니다.
- 설치를 실행하고 다운로드 파일과 임시 파일의 정리 여부를 확인합니다.
- 설치 실패 후 기존 버전이 실행되는지 검증합니다.
- 재시도 시 같은 오류가 반복되지 않고 공간 확보 후 정상 설치되는지 확인합니다.
패치는 기존 파일을 먼저 삭제한 뒤 새 파일을 쓰는 방식보다 임시 경로에 기록하고 검증 후 교체하는 방식이 안전합니다. 패키지 해시 또는 서명 검증 실패도 저장 공간 부족과 다른 메시지로 분리해야 합니다.
세이브 기록 테스트
- 정상 세이브 슬롯과 자동 세이브가 모두 존재하는 상태를 준비합니다.
- 저장 전 공간 부족과 저장 중 공간 부족을 각각 재현합니다.
- 실패 후 이전 세이브의 타임스탬프, 파일 크기, 체크섬을 비교합니다.
- 게임을 재실행해 로드 가능한 세이브가 남아 있는지 확인합니다.
- 사용자에게 세이브 실패가 전달되고 재시도 또는 메뉴 이동이 가능한지 확인합니다.
세이브는 임시 파일 기록, flush, 원자적 교체, 이전 파일 백업 순서를 명확히 정의해야 합니다. 교체 도중 실패하면 새 파일과 이전 파일이 모두 손상될 수 있으므로 복구 가능한 커밋 전략이 필요합니다.
스크린샷 캡처 테스트
- 게임 플레이 중 캡처 버튼을 입력합니다.
- 이미지 인코딩이 끝나기 전에 저장 공간 부족을 유도합니다.
- 캡처 실패 메시지가 게임 입력과 프레임 진행을 불필요하게 막지 않는지 확인합니다.
- 갤러리나 미디어 목록에 깨진 썸네일과 0바이트 파일이 남지 않는지 확인합니다.
- 공간을 확보한 뒤 재캡처하면 정상적으로 저장되는지 검증합니다.
스크린샷은 캡처 요청, 이미지 인코딩, 파일 저장, 미디어 라이브러리 등록이 서로 다른 단계일 수 있습니다. 따라서 최종 파일 생성에 성공했더라도 라이브러리 등록에 실패하면 사용자에게 성공으로 표시하지 않아야 합니다.
QA 체크리스트와 로그 기준
테스트 결과에는 “실패했다”는 사실만 기록하지 말고 어느 단계에서 어떤 상태가 관찰됐는지 남깁니다.
- 빌드 번호와 플랫폼 모델
- 운영체제 버전과 게임 버전
- 작업 종류: 패치, 세이브, 스크린샷
- 작업 시작 전
usableFreeBytes requiredBytes,temporaryBytes,safetyMarginBytes- 사전 검사 결과와 실제 쓰기 결과
- 플랫폼 원본 오류 코드
- 사용자에게 표시된 현지화 문자열 키
- 임시 파일과 백업 파일의 정리 결과
- 재실행 후 데이터 무결성 결과
- 재시도 성공 여부
로그에는 세이브 데이터 원문, 계정 토큰, 개인정보가 포함되지 않도록 합니다. 재현에 필요한 파일 식별자는 경로 대신 해시나 비식별화된 ID를 사용하는 것이 좋습니다.
자주 묻는 질문 (FAQ)
저장 공간이 조금 남아 있는데도 패치가 실패하는 이유는 무엇인가요?
패치는 다운로드 파일 외에 압축 해제와 기존 파일 교체를 위한 임시 공간이 필요합니다. 운영체제 예약 영역까지 고려한 usableFreeBytes 기준으로 검사해야 합니다.
저장 공간 부족으로 세이브가 실패하면 기존 세이브를 삭제해야 하나요?
삭제하면 안 됩니다. 임시 파일에 먼저 기록하고 커밋이 완료된 경우에만 기존 세이브를 교체해야 하며 실패하면 이전 정상 세이브를 유지해야 합니다.
에뮬레이터에서 통과한 오류 메시지를 실제 콘솔에서도 신뢰할 수 있나요?
메시지 분기와 UI는 검증할 수 있지만 실제 저장소 예약 영역과 플랫폼별 오류 코드는 다를 수 있습니다. 릴리스 전 실제 콘솔에서 경계값과 저장 중 실패를 반드시 재검증해야 합니다.
정리
콘솔 저장 공간 부족 테스트의 핵심은 작업별 요구 공간을 계산하고 실패 시점을 분리하는 것입니다. 패치에서는 롤백, 세이브에서는 이전 데이터 보존, 스크린샷에서는 깨진 미디어 방지를 확인해야 합니다. 최종 품질 기준은 오류가 발생했는지가 아니라 사용자가 원인을 이해하고 안전하게 복구할 수 있는지까지 포함해야 합니다.



