핵심 요약
출시 직전에는 기능 추가보다 상태의 소유권, 중복 요청, 오래된 응답, 취소와 재시도 규칙을 실제 사용자 시나리오로 검증해야 합니다.
검수 범위
추상적인 CPU 비유를 줄이고 앱 아키텍처와 오류 복구 체크리스트 중심으로 검수했습니다.
앱 출시 직전의 설계 점검은 새로운 패턴을 도입하는 시간이 아닙니다. 이미 구현한 로그인, 네트워크, 저장, 화면 전환이 실제 사용자 흐름에서 충돌하지 않는지 확인하고 실패했을 때 복구 규칙을 고정하는 단계입니다.
상태의 소유자를 한 곳으로 정하기
로그인 사용자, 장바구니, 선택한 탭처럼 여러 화면에서 쓰는 값은 누가 변경할 수 있는지 정해야 합니다. 화면마다 같은 값을 따로 저장하면 한쪽만 갱신되어 서로 다른 상태를 보여줄 수 있습니다. 읽기와 변경 경로를 문서로 남기고, 변경 함수가 실패할 때 이전 값을 유지할지 되돌릴지도 정합니다.
오래된 응답이 최신 화면을 덮지 않게 하기
검색어 A 요청 뒤에 B 요청을 보냈는데 A가 늦게 도착하면, 응답 순서만 믿는 화면은 다시 A 결과를 보여줄 수 있습니다. 요청 식별자, 취소, 최신 요청 확인 중 하나를 사용해 어떤 응답을 반영할지 결정합니다. 화면이 닫힌 뒤 비동기 콜백이 상태를 갱신하지 않는지도 확인합니다.
중복 요청의 결과를 정의하기
버튼 연속 탭, 네트워크 재시도, 백그라운드 복귀로 결제나 저장 요청이 두 번 실행될 수 있습니다. 버튼을 잠그는 UI만으로는 충분하지 않습니다. 서버에서도 idempotency key, 고유 제약조건, 처리 상태 확인처럼 같은 요청이 반복되어도 결과가 한 번만 반영되게 설계합니다.
재시도와 타임아웃을 분리하기
모든 실패를 즉시 재시도하면 서버 장애 때 요청이 더 몰릴 수 있습니다. 연결 실패, 인증 실패, 입력 오류, 서버 오류를 구분하고 자동 재시도가 가능한 경우만 제한 횟수와 지수 백오프를 적용합니다. 사용자가 취소할 수 있는 긴 작업에는 취소 결과와 부분 저장 여부를 정합니다.
오프라인과 앱 생명주기 확인하기
- 요청 중 앱이 백그라운드로 이동했다가 돌아오면 화면이 어떻게 되는가?
- OS가 앱을 종료한 뒤 다시 열면 작성 중이던 데이터가 필요한가?
- 네트워크가 끊겼을 때 이전 캐시와 오류 중 무엇을 보여주는가?
- 로그아웃하면 민감한 캐시와 토큰이 실제로 제거되는가?
오류 메시지를 사용자 행동과 연결하기
“오류가 발생했습니다”만 보여주면 사용자는 다음 행동을 알 수 없습니다. 다시 시도할 수 있는지, 입력을 수정해야 하는지, 로그인해야 하는지, 고객지원에 전달할 오류 코드가 있는지를 구분합니다. 내부 스택 트레이스나 토큰 같은 민감한 정보는 화면과 일반 로그에 노출하지 않습니다.
출시 전 시나리오 테스트
- 느린 네트워크에서 버튼을 연속으로 누릅니다.
- 요청 도중 화면을 이동하고 앱을 백그라운드로 보냅니다.
- 토큰 만료와 서버 500 오류를 의도적으로 만듭니다.
- 저장공간이 부족하거나 권한이 거부된 상태를 확인합니다.
- 업데이트 설치 후 기존 로컬 데이터가 정상적으로 열리는지 봅니다.
완료 기준
정상 경로만 한 번 성공하는 것이 아니라 실패와 재시도 후에도 데이터가 중복되지 않고, 최신 상태가 유지되며, 사용자가 다음 행동을 이해할 수 있어야 합니다. 이 기준을 자동 테스트와 배포 체크리스트로 남기면 마지막 설계가 개인 기억에 의존하지 않습니다.
개인정보와 관찰 가능성 점검
장애를 찾기 위한 로그에는 요청 ID, 실패 단계, 앱 버전처럼 필요한 정보만 남기고 비밀번호, 전체 토큰, 결제 정보, 사용자가 입력한 민감한 본문은 기록하지 않습니다. 분석 도구와 오류 수집 SDK가 어떤 데이터를 외부로 전송하는지 확인하고 개인정보처리방침과 실제 동작이 일치해야 합니다.
배포와 롤백 계획
스토어에 올린 뒤 즉시 되돌릴 수 없는 변경도 있습니다. 서버 API와 이전 앱 버전의 호환 기간, 기능 플래그 기본값, 데이터 마이그레이션 실패 시 복구, 긴급 배포 담당자를 정합니다. 새 버전만 정상인 API를 갑자기 강제하면 업데이트하지 않은 사용자가 앱을 사용할 수 없으므로 지원할 최소 버전과 차단 화면도 미리 설계합니다.
릴리스 직전에는 설치·로그인·핵심 작업·결제 또는 저장·로그아웃처럼 사용자가 반드시 통과하는 경로를 실제 배포 빌드로 다시 확인합니다. 자동 테스트 결과만 보지 말고 새 설치와 이전 버전에서 업데이트하는 경로를 나누어 검사해야 초기 데이터와 마이그레이션 문제를 발견할 수 있습니다.
검사 결과에는 담당자와 확인 시각, 사용한 빌드 번호를 남겨 문제가 발생했을 때 같은 조건을 재현할 수 있게 합니다.
검증 기준과 참고 자료
이 글은 2026-09-08에 아래 공식 문서와 공개 기술 문서를 기준으로 내용과 용어를 다시 검수했습니다. 제품 버전과 기기 제조사에 따라 화면 이름은 달라질 수 있으므로 실제 화면과 공식 문서를 함께 확인하세요.