앱 보안·강제 업데이트·화면 성능을 한 사이클에 묶어 출시한 회고
목차
v3.1 릴리스 회고
세 가지를 한 사이클에 묶어 출시함. 보안 강화, 강제 업데이트 체크, 메인 화면 성능. 분리해서 내고 싶었지만 QA 라운드 비용 때문에 한 번에 묶음.
보안 강화에서 부딪힌 것
빌드 설정부터 손봄. 디버깅 흔적 노출, 난독화 미흡, 평문 트래픽 허용 같은 잔재들이 있어서 한 번에 정리함.
- 릴리스 빌드 디버깅 비활성
- 코드 난독화 규칙 재정비
- 평문 통신 차단
- 루팅/디버거 연결 감지 추가
문제는 난독화 켜자마자 리플렉션 쓰던 직렬화 코드가 죽은 거. 로그를 봐도 클래스명이 다 단축되어 있어서 처음엔 원인 파악에 시간 꽤 씀. 결국 keep 규칙을 좁게 다시 잡아서 해결.
버전 체크 — 단순할 줄 알았던 것
진입 시점에 서버로 현재 버전을 던지고, 응답으로 강제/권장/통과 셋 중 하나를 받도록 설계함. 의외로 신경 쓸 게 많았음.
| 케이스 | 동작 | UX |
|---|---|---|
| 강제 | 다이얼로그 + 스토어 이동 | 닫기 불가 |
| 권장 | 다이얼로그 + 나중에 | 스킵 가능 |
| 통과 | 무동작 | 평소 흐름 |
진짜 함정은 네트워크가 죽은 환경. 체크 자체가 실패하면 아예 앱이 안 열리는 사고가 날 수 있어서, 타임아웃 짧게 잡고 실패 시 통과로 fallback 하는 정책으로 마무리함.
UI 성능 — 측정부터
체감상 느린 화면 두어 개를 골라서 트레이스를 떠봄. 짐작했던 곳이 아니라 리스트 셀의 이미지 디코딩이 메인 스레드를 잡고 있었음.
- 뷰 트리 깊이 4단계 → 2단계
- 이미지 리사이즈를 백그라운드로
- 불필요한 무효화 호출 제거
세 가지만 손봤는데 첫 진입이 체감으로 절반 가까이 줄어듦. "원인을 추측하지 말고 측정하라"는 격언 다시 새김.
묶음 릴리스의 비용
세 가지 묶음의 위험 — 한 군데가 막히면 전체가 미뤄짐 — 을 다시 체험함. 보안 변경은 회귀 범위가 다른 둘과 너무 달랐고, 결국 검증 라운드가 두 배로 늘어남. 다음 릴리스부터는 보안성 변경은 별 트랙으로 빼서 따로 돌리기로 함.
다음
댓글 0
첫 댓글 달아줘.