메이저 OS 업데이트 대응 플레이북 — iOS 27 사이클로 정리한 앱 점검 순서

나는 예전에 업데이트 당일 새 기능 대응부터 시작했다가 낭패를 봤다. 일주일 뒤에야 특정 기기에서 결제 화면이 안 뜬다는 걸 알았다. 스토어 리뷰로 먼저 알게 되는 건 최악의 시나리오다. 그 뒤로는 순서를 바꿨다. 지키는 일이 먼저, 새로 얻는 일은 나중.

첫 72시간 — 신호 확인

# 분할해서 보는 감각 (대시보드 예시)
# OS 버전       세션        크래시프리    전 버전 대비
# iOS 26.x     1,240,000    99.83%        기준
# iOS 27.0        86,400    99.41%        -0.42%p   <- 조사 대상
#
# 여기서 -0.42%p 는 "새 OS 사용자 1만 명당 42명이 추가로 크래시"라는 뜻.
# 초기 채택자 표본이라 편향이 있을 수 있으나, 추세가 유지되면 실제 문제다.

레이아웃과 시스템 UI 회귀

메이저 업데이트에서 가장 흔한 회귀는 크래시가 아니라 화면이 어긋나는 것이다. 시스템 UI 요소가 추가되거나 크기가 바뀌면, 안전 영역을 직접 계산하던 코드가 틀어진다.

// 안전 영역은 시스템에서 받아 쓴다 (하드코딩 금지)
struct ContentView: View {
    var body: some View {
        GeometryReader { geo in
            VStack { /* ... */ }
                .padding(.top, geo.safeAreaInsets.top)   // 상수 20/44 를 쓰지 않는다
        }
    }
}

// UIKit
// let top = view.safeAreaInsets.top
// 과거 노치 대응 잔재(if hasNotch { 44 } else { 20 })가 남아 있으면 제거 대상

첫 2주 — 새 기능 대응

신호가 안정되면 그때 새 기능을 본다. 여기서 중요한 건 선택과 집중이다. 모든 신기능에 대응할 필요는 없고, 대부분은 대응하지 않아도 된다.

인텐트 노출을 높은 우선순위로 두는 이유는 명확하다. 어시스턴트나 시스템 검색에서 호출될 수 있는 경로는 사용자가 앱을 열지 않아도 앱이 쓰이는 통로다. 다만 처음부터 넓게 열지 말고 대표 동작 두세 개로 시작해 호출 로그를 보는 편이 안전하다.

심사 지연을 전제로 한 릴리스 설계

메이저 OS 직후는 스토어 제출이 몰려 심사가 길어진다. 출시일을 심사 통과일에 묶으면 계획이 무너진다. 해법은 하나다. 기능 노출 시점을 배포가 아니라 서버가 정하게 하는 것.

// 원격 설정으로 노출을 제어하는 최소 형태
struct FeatureFlags: Codable {
    var newCheckout: Bool = false      // 기본값은 항상 안전한 쪽
    var useSystemIntents: Bool = false
}

// 앱 시작 시 원격 설정을 가져오되, 실패하면 기본값 유지
let flags = (try? await remote.fetchFlags()) ?? FeatureFlags()

if flags.newCheckout {
    showNewCheckout()
} else {
    showLegacyCheckout()               // 심사 통과 시점의 검증된 경로
}

// 핵심: 새 코드는 "배포됐지만 꺼져 있다".
// 문제가 생기면 스토어를 거치지 않고 즉시 끌 수 있다.

최소 지원 버전 결정

메이저 OS가 나오면 항상 같은 회의가 열린다. 답은 데이터에 있지만, 숫자 하나로 자르면 안 된다.

사이클을 반복 가능하게 만들기

이 모든 것을 매년 기억에 의존해 하면 매년 같은 실수를 한다. 체크리스트를 저장소에 문서로 두고, 사이클마다 수정하는 게 가장 싸게 먹히는 개선이다. 나는 docs/os-update-playbook.md 하나를 두고 매년 갱신한다. 새로 발견한 함정을 한 줄씩 추가하는 것만으로 다음 해가 편해진다.

자주 묻는 질문

메이저 OS 업데이트 당일 가장 먼저 무엇을 봐야 하나요?

OS 버전별로 분할한 크래시프리율입니다. 전체 지표는 새 OS 사용자 비중이 작아 변화가 묻히므로 반드시 분할해서 보고, 직전 버전 대비 차이가 유지되는지 며칠간 추세로 판단하세요.

크래시 스택이 주소로만 보입니다.

심볼리케이션 파일(dSYM)이 업로드되지 않은 경우입니다. 빌드 파이프라인에서 업로드 단계가 실패했거나, 배포된 빌드와 업로드된 파일의 버전이 어긋났을 수 있습니다. 이 문제를 해결하기 전에는 원인 분석이 불가능합니다.

새 OS의 신기능에 모두 대응해야 하나요?

아닙니다. 권한·프라이버시 변경과 시스템 어시스턴트 노출처럼 대응하지 않으면 기능이 막히거나 진입점을 잃는 항목이 우선이고, 시각 효과나 실험적 API는 다음 사이클로 미뤄도 됩니다.

심사가 길어질 때 출시일을 어떻게 지키나요?

기능을 꺼진 상태로 미리 제출해 심사를 통과시켜 두고, 출시일에 서버 설정으로 켜는 방식이 가장 확실합니다. 이렇게 하면 심사 일정과 마케팅 일정이 분리되고, 문제가 생겨도 즉시 되돌릴 수 있습니다.

최소 지원 버전은 언제 올리는 게 좋나요?

업데이트 확산이 안정되는 2~4주 뒤에 데이터로 결정하세요. 활성 사용자 1~2% 미만이 통상 기준이지만, 해당 구간의 매출 기여도와 국가별 분포를 함께 확인해야 합니다. 되돌리기 어려운 결정이므로 보수적으로 접근하는 편이 안전합니다.

레이아웃 회귀를 미리 막을 방법이 있나요?

안전 영역 값을 상수로 하드코딩하지 않고 시스템에서 받아 쓰는 것이 기본입니다. 베타 기간에 주요 화면의 스크린샷 비교 테스트를 돌려 두면 시스템 UI 변화로 인한 어긋남을 조기에 발견할 수 있습니다.