App Store Connect 단계적 출시, 일시 중지해야 할까요? 2026 판단 가이드

새 버전 배포 뒤 크래시 제보가 들어왔지만 재현 여부가 불분명합니다.
데이터 손실·보안 위험·핵심 기능의 광범위한 실패를 뒷받침하는 증거가 있으면 단계적 출시를 우선 멈추고, 산발적인 제보라면 로그와 영향 범위를 확인한 뒤 결정합니다.

방금 버전을 공개하고 크래시와 사용자 피드백을 살피는 독립 개발자에게 적합합니다.
여러 앱의 배포 상태를 관리하는 소규모 팀은 중지, 재개, 전체 공개의 차이를 확인할 수 있습니다.
긴급 수정 빌드를 준비 중인 개발자는 문제 판단부터 검증까지의 연결 절차를 살펴보세요.

단계적 출시가 제어하는 범위

App Store Connect의 단계적 출시는 버전 업데이트를 사용자에게 자동으로 배포하는 속도를 조절합니다. 이미 공개한 버전을 되돌리거나 새 버전의 모든 접근을 차단하는 기능은 아닙니다. 출시를 멈춘다고 해서 사용자가 스토어에서 업데이트를 직접 선택하는 것까지 막히지는 않습니다. 이 차이를 놓치면 위험한 버전이 계속 설치될 수 있습니다.

공식 안내에 따르면 단계적 배포는 7일 동안 진행되며, 매일 자동 업데이트 대상 비율은 1%, 2%, 5%, 10%, 20%, 50%, 100% 순으로 늘어납니다. 또한 진행을 멈출 수 있는 기간에는 최대 30일의 제한이 있습니다. 실제 조작 가능 여부와 현재 상태는 단계적 버전 출시의 공식 안내에서 확인하고, 앱스토어 커넥트 화면의 최신 상태와 대조해야 합니다.

따라서 “중지할까?”라는 질문은 배포 비율만으로 답할 수 없습니다. 영향을 받는 사용자와 기능, 문제가 재현되는 조건, 사용자가 업데이트를 직접 받을 가능성까지 함께 평가해야 합니다.

문제 유형별 대응 우선순위

아래 평가는 기능이 아니라 출시 판단을 돕기 위한 위험 등급입니다. 영향이 크고 근거가 강한 문제일수록 기존 자동 배포를 멈추는 쪽에 무게를 둡니다.

상황	판단 등급	우선 조치	계속 배포를 검토할 조건
데이터 손실이나 보안 노출이 재현됨	높음	자동 배포를 멈추고 수정 빌드를 준비합니다	위험이 제거되고 검증 결과가 확인된 뒤 판단합니다
로그인, 결제 등 핵심 흐름이 여러 사례에서 실패함	높음	문제 버전과 영향 범위를 확인하고 중지를 검토합니다	재현 조건이 제한적이며 사용자 영향이 낮다는 근거가 있을 때 검토합니다
단일 사용자 제보이며 재현되지 않음	보통 이하	버전·기기·운영체제·로그를 확인합니다	추가 제보와 진단 자료에서 시스템성 문제가 확인되지 않을 때 검토합니다
원인이 확인됐고 수정 빌드 검증 중임	상황별	현재 배포를 멈출지, 안전 확인 후 재개할지 비교합니다	수정 결과와 회귀 테스트가 통과하고 기존 버전의 위험이 낮을 때 검토합니다

재현 가능한 고위험 문제

핵심 화면에 진입할 수 없거나, 저장 데이터가 손상되거나, 민감 정보가 노출되는 문제는 단순한 불편 제보와 다르게 다뤄야 합니다. 해당 버전에서 문제가 재현되는지 확인하고, 영향을 받는 기능과 사용자 범위를 구체화하세요. 신뢰할 수 있는 근거가 확보되면 자동 배포를 우선 중단하고, 수정 및 검증 작업을 병행하는 편이 안전합니다.

한 건의 보고만으로도 보안 노출이나 데이터 손실이 명확하게 확인됐다면 제보 수가 적다는 이유로 기다릴 필요는 없습니다. 반대로 심각해 보이는 표현만 있고 근거가 없다면 문제를 확인하는 동안 원본 자료를 보존해야 합니다. 크래시 보고서와 기기 로그를 진단하는 공식 문서는 로그를 분석할 때 참고할 수 있습니다.

산발적 제보와 확인되지 않은 회귀

소셜 미디어의 단일 사례나 재현되지 않은 사용자 의견은 조사 신호로는 유용하지만, 곧바로 전체 사용자에게 발생하는 결함을 뜻하지는 않습니다. 먼저 제보자의 앱 버전, 기기 모델, 운영체제 버전, 문제가 시작된 시점과 재현 단계를 확보하세요. 같은 조건에서 반복되는지 확인하면 단순한 환경 차이와 배포 이후 회귀를 구분하기 쉬워집니다.

크래시 자료가 부족하다면 진단 로그를 확보하는 방법을 확인하고, 제품 분석에서는 앱스토어 커넥트 지표 정의와 같은 기준으로 관련 추이를 살펴볼 수 있습니다. 다만 지표 변화만으로 원인을 확정하지 말고 고객 지원 기록과 재현 결과를 함께 검토해야 합니다.

수정 버전 준비와 재개 판단

문제가 수정됐다는 사실만으로 곧바로 기존 배포를 재개해서는 안 됩니다. 수정 사항이 해당 증상을 해결하는지, 다른 핵심 흐름에 회귀를 만들지 확인한 뒤 배포 경로를 선택해야 합니다. 테스트가 끝나지 않았거나 빌드와 검증 결과의 연결이 불분명하다면 속도보다 추적 가능성을 우선하세요.

선택지	적합한 조건	주요 위험 또는 한계
기존 단계적 배포 계속	제보가 제한적이고 재현되지 않으며 영향이 낮다는 근거가 충분함	추가 사용자에게 문제가 노출될 수 있습니다
단계적 배포 중지 후 수정 버전 준비	재현 가능한 결함이나 영향 범위 확대가 확인됨	중지만으로 직접 업데이트를 차단할 수는 없습니다
검증 후 단계적 배포 재개	수정 여부와 회귀 테스트를 확인했고 기존 출시 상태를 이어갈 이유가 있음	재개 가능한 상태와 중지 기간 제한을 현재 화면에서 확인해야 합니다
모든 사용자에게 공개	수정 빌드가 검증됐고 즉시 넓게 배포할 필요가 있음	문제 확인이 부족하면 영향 범위가 한 번에 넓어질 수 있습니다

전체 공개는 자동 배포 대상의 확대를 뜻하며, 버전 자체를 회수하는 동작과는 다릅니다. 사용자가 업데이트를 받지 못하게 해야 하는 상황이라면 버전을 다운로드할 수 없게 하는 설정과 스토어에서 앱 이용 가능성을 관리하는 안내를 별도로 확인하세요. 두 설정은 단계적 출시 중지와 목적 및 영향이 다르므로 현재 상태를 확인하지 않은 채 같은 조치로 간주하지 않아야 합니다.

배포 판단을 재현 가능한 기록으로 남기기

아래 항목을 채우면 “계속” 또는 “중지” 결정의 근거를 팀 안에서 공유하고, 다음 검토 시점에 같은 자료를 다시 확인할 수 있습니다.

[ ] 문제를 보고한 앱 버전과 빌드, 기기 및 운영체제 정보를 기록합니다.
[ ] 크래시 로그, 고객 지원 문의, 재현 절차를 확보하고 자료의 출처를 남깁니다.
[ ] 영향을 받는 핵심 기능과 사용자 범위를 확인하고, 확인된 사실과 추정을 분리합니다.
[ ] 현재 출시 상태와 자동 배포를 멈췄는지 여부를 앱스토어 커넥트에서 확인합니다.
[ ] 중지 또는 계속을 선택한 이유와 결정 시점의 근거를 남깁니다.
[ ] 수정 빌드의 변경 사항, 테스트 결과, 제출한 빌드가 서로 맞는지 대조합니다.
[ ] 다음 검토 조건을 정합니다. 예를 들어 새 재현 사례가 접수되거나 회귀 테스트가 완료되면 상태를 다시 평가합니다.

수정 빌드를 만들 때는 아카이브 산출물, 서명된 빌드, 테스트 결과가 같은 버전과 빌드에 대응하는지 확인해야 합니다. 진단용 심볼이 맞지 않으면 크래시 분석에 필요한 정보를 얻기 어려울 수 있으므로, 디버깅 정보를 포함한 빌드 관련 공식 설명을 빌드 검토에 참고하세요.

Xcode 프로젝트, 아카이브, 서명 자료와 검증 기록을 같은 실행 환경에서 관리하면 긴급 수정 시 환경 차이로 인한 혼선을 줄일 수 있습니다. 다만 운영체제나 도구 버전이 바뀌었을 때 결과가 달라질 수 있으므로, 빌드 환경과 실제 제출 버전을 함께 기록해야 합니다. 단계적 출시 상태를 API로 확인하는 팀은 단계적 출시 상태 필드 문서를 기준으로 상태 값을 검토하되, API 표시만으로 사용자에게 업데이트가 차단됐다고 해석해서는 안 됩니다.

자주 확인하는 배포 질문

크래시 제보가 한 건이면 중지해야 하나요?

제보 수만으로 결정하지 않습니다. 데이터 손실이나 보안 문제를 실제로 재현할 수 있다면 한 건이라도 즉시 위험을 평가해야 합니다. 반면 재현되지 않는 단일 크래시라면 버전과 기기 정보, 진단 로그, 지원 문의를 확인해 다른 사용자에게도 같은 문제가 나타나는지 살펴보세요. 확인 전까지는 사실과 추정을 구분해 기록합니다.

중지한 단계적 출시를 다시 진행할 수 있나요?

진행 상태에 따라 재개할 수 있지만, 허용되는 기간과 현재 가능한 조작은 앱스토어 커넥트의 상태 및 공식 안내를 확인해야 합니다. 수정이 필요했던 문제라면 재개 전에 수정 빌드의 테스트 결과와 기존 버전의 위험을 검토하세요. 문제가 해결되지 않았다면 기존 배포를 재개하기보다 수정 버전을 검증하고 배포하는 편이 적절할 수 있습니다.

배포를 멈추면 수동 업데이트도 차단되나요?

아닙니다. 단계적 출시는 자동 업데이트의 배포 속도를 제어합니다. 사용자가 앱스토어에서 업데이트를 직접 선택할 가능성까지 없애지는 않습니다. 따라서 사용자에게 해당 버전을 제공하지 않아야 하는 상황에서는 단계적 배포 중지만으로 충분하다고 가정하지 말고, 버전 제공 상태와 앱 이용 가능성 설정을 따로 확인해야 합니다.

단계적 배포와 전체 공개 중 어느 쪽을 선택해야 하나요?

영향 범위가 확인되지 않았거나 위험한 회귀가 의심된다면 배포를 계속 넓히기 전에 증거를 수집하고 중지를 검토합니다. 핵심 기능과 수정 사항이 검증됐고 빠르게 모든 사용자에게 제공할 필요가 있다면 전체 공개를 고려할 수 있습니다. 현재 출시 상태에서 실제로 선택할 수 있는 동작은 화면에 표시되는 안내를 기준으로 판단해야 합니다.

수정 빌드 환경 점검과 다음 선택

긴급 수정에는 기존 개발 환경을 그대로 쓰는 방법이 가장 간단할 수 있습니다. 다만 로컬 맥의 저장 공간 부족, 개발자가 자리를 비웠을 때 빌드가 이어지지 않는 문제, 윈도우나 리눅스만으로는 네이티브 엑스코드 아카이브와 서명 작업을 수행하기 어려운 점이 실제 제약이 됩니다. 반대로 맥을 임시로 빌리면 빌드 환경을 확보할 수 있지만, 장기간 반복되는 고정 부하나 물리 장치 연결이 필수인 테스트에는 직접 보유한 장비가 더 적합할 수 있습니다.

수정 빌드와 서명을 마칠 임시 환경이 필요하고 로컬에 쓸 수 있는 맥이 없다면, 먼저 원격 맥 지원 범위와 대여 기간 및 요금제를 비교해 현재 작업에 맞는지 확인할 수 있습니다. 원격 맥 대여가 모든 팀에 최선인 것은 아닙니다. 반복적인 상시 빌드에는 장기 운영 비용과 접근 권한을 비교하고, 기기 연결이 필요한 검증에는 물리 장비가 있는 환경을 선택하세요. 중요한 것은 배포를 서두르는 일이 아니라, 확인된 문제와 검증된 빌드를 같은 기준으로 연결하는 일입니다.

자주 묻는 질문

단계적 출시 중 크래시가 발견되면 바로 멈춰야 하나요?

데이터 손실이나 보안 문제, 핵심 기능의 광범위한 실패를 뒷받침하는 재현 가능한 증거가 있다면 우선 출시를 멈추고 수정 빌드를 준비하는 편이 안전합니다. 반면 단일 제보만 있고 재현되지 않는다면 먼저 해당 사용자의 앱 버전과 기기, 운영체제 정보, 크래시 기록을 확인해야 합니다. 문제의 범위가 확인되기 전에 모든 제보를 시스템 문제로 단정하지 마세요.

단계적 출시를 일시 중지한 뒤 다시 진행할 수 있나요?

진행 중인 단계적 출시라면 상태를 확인한 뒤 재개할 수 있습니다. 다만 중지한 기간과 조작 가능 여부에는 공식 안내에 따른 제한이 있으므로 현재 앱스토어 커넥트에 표시되는 상태와 동작을 확인해야 합니다. 재개 전에 수정 여부, 회귀 테스트 결과, 미해결 위험을 기록하고, 문제가 남아 있다면 기존 배포를 재개하는 대신 수정 버전을 검토하세요.

단계적 출시를 멈추면 사용자는 새 버전을 직접 내려받을 수 없나요?

아닙니다. 단계적 출시는 대상 사용자의 자동 업데이트 배포 속도를 조절하는 기능이지, 새 버전을 회수하거나 스토어에서 숨기는 기능이 아닙니다. 사용자가 스토어에서 직접 업데이트를 선택할 가능성은 남습니다. 따라서 문제가 심각하면 중지 조작만으로 위험이 모두 차단된다고 판단하지 말고, 버전의 제공 상태와 별도 이용 가능성 설정을 함께 확인해야 합니다.

단계적 출시와 모든 사용자 대상 공개는 어떻게 선택하나요?

문제가 발견됐거나 영향 범위가 불분명하면 자동 배포 속도를 유지하면서 추가 증거를 모을 수 있도록 단계적 출시를 검토합니다. 반대로 빌드와 핵심 흐름을 충분히 검증했고 즉시 넓은 사용자층에 제공해야 할 이유가 있다면 모든 사용자 대상 공개를 고려할 수 있습니다. 이미 진행 중인 배포 상태와 선택 가능한 조작은 앱스토어 커넥트의 현재 화면에서 확인하세요.