업데이트와 단계적 출시

첫 출시를 마친 앱을 고쳐 다시 올리는 순서입니다. 업데이트도 처음 출시와 같은 심사 · 인증을 거치지만, 스토어마다 버전 번호 규칙과 단계적 출시, 문제가 생겼을 때 멈추는 방법이 다릅니다. 먼저 한 표로 견주고, 이어서 어느 스토어에나 쓰는 순서를 안내합니다.

준비물

• 첫 출시를 마친 앱 — 단계적 출시와 관리형 게시는 업데이트에만 쓸 수 있습니다. 첫 출시는 각 스토어 편(App Store · Mac App Store · Google Play · Microsoft Store)을 따릅니다.
• 직전에 올린 버전 번호 — 새 번호는 이전보다 높아야 합니다. 규칙은 식별자와 버전에 있습니다.
• 새 릴리스 빌드와 출시 노트 — 사용자에게 보여 줄 변경 내용을 짧게 정리해 둡니다.
• (선택) 시험 대상 — TestFlight 테스터 · Play 테스트 트랙의 테스터 · 패키지 플라이트 그룹처럼 새 빌드를 먼저 써 볼 사람입니다.

스토어별 차이

아래 표는 2026-10-09 에 확인한 값입니다. Mac App Store 는 App Store 와 같은 점이 많아 다른 점만 적었습니다. 스토어마다 단계적 출시를 부르는 이름이 달라(Apple 한국어판 「점진적 출시」 · Google 「단계적 출시」 · Microsoft 한국어판 「점진적인 패키지 배포」) 이 가이드는 「단계적 출시」로 통일했습니다.

단계

1. 바뀐 내용에 맞춰 선언을 점검합니다.

   • 개인정보 — 새로 수집하는 데이터 · 새 권한 · 새 SDK 가 있으면 스토어의 개인정보 선언(Apple 의 앱이 수집하는 개인정보, Google 의 데이터 보안, Microsoft 의 속성과 방침 URL)을 고칩니다. 방법은 개인정보와 권한을 보세요.
   • 연령 등급 — 콘텐츠나 기능이 바뀌어 등급 질문의 답이 달라질 수 있으면 설문을 다시 합니다. Microsoft 는 한 번 받은 등급을 이후 업데이트에도 쓰고, 업데이트의 내용이 등급에 영향을 주면 「편집(Edit)」으로 설문을 다시 할 수 있다고 안내하며, IARC 가 질문을 바꾸면 업데이트를 제출할 때 다시 답하라는 요청이 올 수 있다고 밝힙니다. 정책 7.20 의 11.11.2 는 2026-10-22 부터 연령 등급 정보를 제품 수명 주기 내내 정확하고 최신으로 유지하라고 정하니, Microsoft Store 에 낸 앱은 업데이트 때마다 이 점검을 하세요.
   • 사용자 생성 콘텐츠 — 사용자가 올린 콘텐츠를 다른 사용자가 볼 수 있는 기능을 더했다면 정책 11.12 의 약관 · 신고 수단 · 제거 의무를 함께 확인합니다. 이 의무는 현행 7.19 에도 있고, 7.20 의 11.12 가 2026-10-22 부터 행동 강령 · 제품 안과 웹사이트 양쪽 공개 · 보호자 설정 존중 · 제3자 게임 모드나 UGC 플랫폼 연동 규정을 더합니다. 요건은 Microsoft Store 편의 「스토어 정책 7.20」에 있습니다.

   성공 판정 — 각 콘솔의 개인정보와 등급 선언이 새 버전의 동작과 같습니다.

2. 버전 번호를 올립니다. Apple · Google 은 pubspec.yaml 의 version: 을 올리고, 버전 이름이 같아도 + 뒤 빌드 번호는 올립니다.

   yaml

   version: 1.0.1+2        # 1.0.0+1 에서 올림
   

   Microsoft Store 용 MSIX 는 msix 패키지가 msix_version(없으면 pubspec.yaml 의 x.y.z 뒤에 .0 을 붙인 값)으로 버전을 정하고 + 뒤 빌드 번호는 버립니다. 그래서 msix_config 에 msix_version 을 써 두었다면 그 값을 직접 올리고 네 번째 자리는 0 으로 둡니다.

   yaml

   msix_config:
     msix_version: 1.0.1.0   # 1.0.0.0 에서 올림
   

   성공 판정 — 올릴 버전이 직전에 올린 버전보다 높고, Microsoft 의 패키지 버전은 네 번째 자리가 0 입니다.

3. 새 빌드를 만들어 올립니다. 명령과 업로드 방법은 스토어별 편의 빌드와 업로드 단계를 따릅니다: App Store · Mac App Store · Google Play · Microsoft Store. Microsoft 는 앱 개요 페이지에서 먼저 「업데이트 시작」을 눌러 새 제출을 만든 뒤 패키지 페이지에 올립니다. Microsoft 는 설명 · 스크린샷 · 카테고리 · 가격만 바꿀 때 새 패키지를 올리지 않아도 새 제출을 만들 수 있다고 안내하고, 그 변경도 인증을 거칩니다.

   성공 판정 — 각 콘솔의 빌드(패키지) 목록에 새 버전이 나타납니다. Apple 은 TestFlight 탭의 빌드 업로드 상태가 「완료」이고, Google 은 「최신 버전 및 번들」에 보이며, Microsoft 는 패키지가 「유효성 검사됨」입니다.

4. 시험합니다. Apple 은 TestFlight 의 내부 · 외부 테스트로, Google 은 내부 · 비공개 테스트 트랙으로 새 빌드를 먼저 확인합니다. Microsoft 는 Windows 앱 인증 키트로 패키지를 점검하고, 첫 게시가 끝난 앱이면 앱 개요 페이지의 「New package flight」로 지정한 고객 그룹(알려진 사용자 그룹)에게만 패키지를 먼저 줄 수 있습니다. 패키지 플라이트에서는 일부 인증 키트 실패가 통과로 보고되지만 정식 출시 전에는 모두 고쳐야 합니다.

   성공 판정 — 시험 대상이 새 빌드를 설치해 실행했고 이전 버전에서 쓰던 데이터와 로그인이 그대로 동작합니다.

5. 제출하고 심사 · 인증을 기다립니다. Apple 은 새 버전에 빌드를 고르고 「심사에 추가」를 누른 뒤(상태가 「심사 준비됨」으로 바뀌지만 아직 App Review 로 전송되지 않은 상태입니다) 「심사를 위해 제출」까지 눌러야 하고, Google 은 변경을 저장한 뒤 게시 개요(Publishing overview)에서 「검토를 위해 전송(Send for review)」까지 눌러야 합니다. 「저장」만으로는 검토가 시작되지 않습니다(검토가 필요한 변경일 때이고, 검토가 필요 없는 변경에는 「저장」 대신 「게시」가 보이며 바로 공개됩니다). Microsoft 는 「인증을 위해 제출」을 누릅니다. 거절되면 심사 거절 대응을 보세요.

   성공 판정 — Apple 은 상태가 「심사 대기 중(Waiting for Review)」이고, Google 은 게시 개요의 「검토 중인 변경사항(Changes in review)」 구역에 변경이 있으며, Microsoft 는 앱 상태가 「인증 중(In certification)」입니다.

6. 출시 방식을 고르고 내보냅니다. 단계적 출시를 쓰려면 Apple 은 버전 페이지의 「자동 업데이트의 점진적 출시(Phased Release for Automatic Updates)」 구역에서 7일 단계적 출시를 고르고, Google 은 릴리스를 만들 때 「단계적 출시(Staged rollout)」 구역에 비율을 입력하며, Microsoft 는 패키지 페이지의 「Roll out update gradually after this submission is published」를 켜고 비율을 입력합니다. 출시 시점을 조절하려면 위 표의 수동 출시 · 관리형 게시 · 게시 보류 옵션을 씁니다. 단계적 출시 중에는 스토어 목록 변경을 100% 로 나간 뒤로 미루라고 Google 이 권합니다.

   성공 판정 — Apple 은 상태가 「배포 준비됨」이고 그 옆에 「점진적 출시(Phased Release)」가 붙으며, Google 은 릴리스 상세의 「출시 기록(Rollout history)」에서 비율을 볼 수 있고, Microsoft 는 앱 개요 페이지에서 롤아웃 비율을 조정할 수 있습니다.

7. 출시 뒤 지켜보고 문제가 있으면 멈춥니다. 충돌 보고서와 사용자 평가를 보면서 비율을 올립니다. Google 의 단계적 출시 비율은 자동으로 늘지 않아 직접 올려야 하고, Microsoft 는 비율을 올린 뒤에도 「패키지 출시 완료(Finalize package rollout)」를 눌러야 일부 이전 OS 의 고객까지 새 패키지를 받습니다. Apple 은 문제가 보이면 단계적 출시를 멈추고(합계 30일), 괜찮으면 「모든 사용자에게 출시(Release to All Users)」로 모두에게 내보낼 수 있습니다. 문제가 확인되면 Google 은 「출시 관리 → 출시 중지」, Microsoft 는 「패키지 롤아웃 중지(Halt package rollout)」로 멈추고 고친 버전을 더 높은 번호의 새 업데이트로 올립니다.

   성공 판정 — 문제 없이 모든 사용자에게 새 버전이 나가거나(Apple 은 7일 뒤 완료 알림, Google 은 비율이 100%, Microsoft 는 「패키지 출시 완료」로 롤아웃 마무리), 문제가 있으면 출시가 멈춘 상태에서 고친 버전의 새 제출이 시작됩니다.

8. 긴급 수정이 필요하면 같은 순서를 짧게 돕니다. 1~5단계를 그대로 거치되 변경 범위를 줄입니다. Apple 은 치명적인 버그 수정이라면 신속 심사를 요청할 수 있습니다. Apple 은 버그 수정 업데이트에서 심사 중 추가 문제를 찾으면 법적 · 안전 문제가 없는 한 다음 제출에서 고치도록 제안할 수 있고, 제안 메시지에 답해 현재 제출을 승인받는 방법도 안내합니다(거절된 뒤 이 제안을 받았을 때의 절차는 심사 거절 대응에 있습니다). Google 은 권한 선언 양식 작성이 필요한 릴리스가 확장 검토로 오래 걸릴 수 있으니, 급하면 해당 권한을 뺀 번들로 올리는 방법을 안내합니다.

   성공 판정 — 고친 빌드가 보통 업데이트보다 짧은 변경으로 제출되어 심사 · 인증 중이거나 이미 출시됐습니다.

확인

• 버전: 각 콘솔에 올라간 새 버전 번호가 직전 버전보다 높습니다. Microsoft 의 패키지 버전은 네 번째 자리가 0 입니다.
• 제출: Apple 은 「심사 대기 중」, Google 은 검토 중, Microsoft 는 「인증 중(In certification)」으로 보입니다.
• 출시: 단계적 출시라면 비율이 의도한 대로이고, 마무리할 때(Apple 7일 · Google 100% · Microsoft 「패키지 출시 완료」)까지 지켜봤습니다.
• 선언: 개인정보 · 연령 등급 선언이 새 버전과 같습니다.

자주 겪는 문제

다음 단계

업데이트가 심사나 인증에서 거절되면 심사 거절 대응으로 이어서 보세요. 올리기 전 점검은 제출 전 체크리스트를 다시 훑고, 스토어별 첫 출시 절차는 스토어별 안내에서 고릅니다.