Start-End 쌍 이벤트 로그의 실패 시나리오 검증과 오프라인 재전송
채널 입장이나 퀘스트 보상 수령처럼 한 번 찍고 끝나는 이벤트와 달리, Start-End 쌍으로 묶인 이벤트는 소요 시간(duration), 성공 여부(result), 호출 순서(flow)가 모두 중요하다.
QA 기간 동안 실패 케이스가 거의 잡히지 않았다. 그래서 라이브 배포 전에 직접 실패를 만들어, 예외 상황에서도 시퀀스 로그의 데이터가 정확한지 검증했다.
주요 시퀀스 실패 재현
섹션 제목: “주요 시퀀스 실패 재현”디버그 패널로 각 시퀀스의 실패 상황을 재현하고 로그 필드를 확인했다. 에디터나 빌드에서 제스처로 디버그 모드를 열고 버튼을 눌러 실패를 일으킨다.
| 대상 | 재현 시나리오 | 검증 포인트 |
|---|---|---|
| 로비 로드 | 번들 누락, 씬 이름 오기입 | failed, duration, total_time |
| 게임 로드 | 게임 임시·긴급 점검 | game_ssn, failed, duration |
| 로그인 | 사용자 취소, 토큰 갱신 실패 | login_type, failed, reason |
| Config | CDN URL 오류, 서버 404 응답 | failed, duration, app_version |
| 에셋 | 저장 공간 부족, CRC 불일치 | failed, duration, reason |
| 게임 서버 연결 | 타임아웃, 연결 거부 | host/port, failed |
네트워크 단절 시 로그 유실
섹션 제목: “네트워크 단절 시 로그 유실”네트워크가 불안정해 사용자가 이탈하면 단절 지점의 로그가 유실되어 이탈 원인을 분석할 수 없었다. 목표는 두 가지였다.
- 네트워크 문제로 인한 실패 사유(
NETWORK_DISCONNECTED)를 누락 없이 모아 이탈 분석 정밀도를 높인다. - 네트워크 상태와 상관없이 앱이 켜져 있는 동안 발생한 이벤트의 무결성을 확보한다.
- 오프라인 캐싱: 네트워크가 끊긴 상태(
NotReachable)에서 생긴 로그는 바로 보내지 않고 메모리의 전용 큐(pendingEvents)에 보관한다. - 복구 감지: Tick 루틴에서 네트워크 상태를 계속 확인해 연결이 돌아오는 시점을 잡는다.
- 자동 재전송(flush): 복구를 확인하는 즉시 큐에 쌓인 로그를 꺼내 이벤트 수집 SDK로 보낸다.
기기의 네트워크를 물리적으로 끊었다 연결해 확인했다. 에셋 다운로드를 시작한 뒤 네트워크를 끊자 단절로 인한 failed 로그가 남았고, 몇 분 뒤 복구하자 success 로그가 이어서 전송됐다.
시퀀스 예외 케이스
섹션 제목: “시퀀스 예외 케이스”아래 케이스도 확인했고 특이사항은 없었다.
| 테스트 케이스 | 재현 시나리오 | 검증 포인트 |
|---|---|---|
| Start 중복 호출 | Start(A) → Start(B) 후 End(B, false) | 마지막으로 호출된 B 시점 기준으로 시간을 다시 재는지 |
| Start 없는 End 호출 | Start 없이 바로 End(false) 호출 | 유효하지 않은 시퀀스로 보고 로그를 만들지 않는지 |