App Store Connect vs Google Play Console: 게시 워크플로 비교
한 스토어에만 출시한다면 콘솔 하나만 익히면 돼요. 하지만 두 스토어에 모두 출시하면 같은 단어가 서로 다른 의미로 쓰이는 두 가지 사고 모델을 동시에 다뤄야 해요. "릴리스", "심사", "롤아웃"은 App Store Connect와 Google Play Console에서 미묘하게 다른 뜻을 가져요. 이 글에서는 두 워크플로를 단계별로 나란히 정리해서, 예상치 못한 상황 없이 두 스토어 모두에 출시할 수 있는 계획을 세우도록 도와드릴게요.
워크플로 나란히 비교하기
여기서 시작하세요. 각 행은 업데이트를 실제로 출시하기까지의 단계이고, 두 열은 각 콘솔에서 실제로 일어나는 일이에요.
| 메타데이터 전용 수정 | 대부분의 등록정보 변경은 새 버전으로 심사를 거치며, 일부 필드만 실시간으로 수정돼요. | 빌드를 새로 출시하지 않고 제출·심사되는 스토어 등록정보 수정이에요. |
Apple이 버전을 출시하는 방식
App Store Connect의 작업 단위는 버전이에요. 빌드를 첨부하고 메타데이터와 스크린샷을 채운 뒤, 전체를 App Review에 제출해요. Apple은 이를 하나의 패키지로 취급하기 때문에, 스크린샷 교체나 설명 문구 수정 하나만으로도 대개 새 버전과 또 한 번의 심사가 필요해요.
App Review가 승인하면 출시 옵션에 따라 이후 진행이 결정돼요. 자동을 선택하면 즉시 공개돼요. 수동을 선택하면 "Pending Developer Release" 상태로 대기해요 — Apple은 승인했지만 버튼을 누르기 전까지는 아무것도 공개되지 않아요(누른 뒤에도 최대 24시간까지 반영을 기다려야 할 수 있어요). 예약을 선택하면 지정한 날짜와 시간에 자동으로 출시돼요. 이 옵션은 버전마다 선택하므로, 업데이트마다 새로 결정하게 돼요.
점진적으로 출시하려면 단계적 출시를 켜세요. 기존 사용자의 자동 업데이트에만 적용되며 7일에 걸쳐 비율을 점점 늘려가고, 지표에 문제가 보이면 일시 중지할 수 있어요. 신규 앱에는 적용되지 않고 수동 출시에도 적용되지 않아요 — 이는 Google의 단계적 출시에 해당하는 개념이지, 전체 릴리스를 보류하는 기능이 아니에요.
Google이 트랙에 출시하는 방식
Google은 같은 작업을 트랙 단위로 나눠요. 빌드는 내부, 비공개, 공개 중 하나의 테스트 트랙에서 시작해, 준비가 되면 프로덕션으로 승격돼요. 내부 테스트는 소규모 신뢰 그룹(최대 100명)을 대상으로 해요. 비공개 테스트는 초대 목록(목록당 최대 2,000명)으로 확대돼요. 공개 테스트는 인원 제한 없이 누구나 참여할 수 있어요. 프로덕션은 선택한 국가의 모든 사용자를 대상으로 해요.
릴리스를 푸시할 때 관리형 게시는 Apple의 수동 보류에 해당해요. 이를 켜두면 승인된 변경 사항이 Publishing 개요의 "보낼 준비가 된 변경 사항"에 쌓이고, 직접 게시해야만 공개돼요 — 마케팅 일정에 맞춰 릴리스를 조정할 때 유용해요. 꺼두면 심사를 통과하는 즉시 게시돼요.
점진적으로 출시하려면 단계적 출시를 사용하세요. 일정 비율의 사용자에게 먼저 릴리스한 뒤 직접 비율을 높여가고, 오류율이 급증하면 중단할 수 있어요. Apple의 단계적 출시와 마찬가지로 업데이트를 위한 기능이지 첫 출시를 위한 것은 아니에요 — 신규 프로덕션 릴리스는 한 번에 모든 사용자에게 전달돼요.
사람들이 자주 헷갈리는 차이점
꼭 기억해야 할 핵심 차이는 이거예요. Apple은 메타데이터를 버전에 결합하지만, Google은 스토어 등록정보를 릴리스와 분리해서 관리해요.
Apple에서는 스크린샷, 설명, 키워드가 심사 대상인 버전의 일부예요. 빌드 사이에 스크린샷만 새로 바꾸고 싶어도 대부분의 필드는 새 버전과 또 한 번의 심사를 의미해요. Google에서는 스토어 등록정보가 독립된 객체예요 — 배포된 앱 번들은 그대로 둔 채 텍스트와 이미지만 수정해서 심사에 제출할 수 있어요. "전체 릴리스 없이 이걸 바꿀 수 있나요?"라는 질문에 두 스토어는 아주 다르게 답해요.
이 차이는 출시 때 챙길 게 많을수록 특히 중요해져요. 빌드, 스크린샷 세트, 수십 개 마켓에 걸친 현지화 텍스트 같은 것들이에요. Apple에서는 보통 이 모든 것을 하나의 버전으로 묶어 함께 심사받도록 해요. Google에서는 등록정보와 릴리스를 독립적으로 준비해서, 계획에 맞는 순서로 게시할 수 있어요.
심사 시간과 신규 계정의 함정
Apple의 App Review는 2026년 기준 일반적인 업데이트에 약 24~48시간이 걸리며, 신규 개발자의 첫 제출이나 더 꼼꼼히 볼 필요가 있는 항목은 더 오래 걸려요. Google의 심사는 대체로 더 빨라요 — 기존 계정이라면 몇 시간에서 며칠 정도 — 하지만 신규 계정에는 관문이 하나 있어요.
2023년 11월 중순 이후 만든 개인 Google Play 개발자 계정은 프로덕션 액세스를 신청하기 전에, 12명 이상의 테스터가 참여한 비공개 테스트를 14일 연속으로 운영해야 해요. 테스터가 12명 아래로 떨어지면 연속 일수가 초기화될 수 있어요. 조직 계정과 기존 개인 계정은 이 과정을 건너뛰어요. Apple에는 이에 직접 대응하는 절차가 없으므로, 두 스토어에 첫 앱을 출시한다면 Google의 테스트 기간을 미리 일정에 반영하세요 — 보통 더 오래 걸리는 쪽이에요.
Mokbi가 도움이 되는 지점
두 콘솔 모두 같은 완성된 에셋을 원해요: 프레임에 담긴 스크린샷과, 필요한 모든 사이즈에 맞춘 깔끔한 현지화 카피예요. Mokbi는 그 작업을 한 번만 하면 되도록 만들어줘요. 하나의 프로젝트에서 스크린샷을 디자인하고 스토어 텍스트 초안을 작성한 뒤, 두 가지 모두 50개 언어로 번역하고, App Store Connect와 Google Play Console의 규격에 맞는 세트를 한 번에 내보낼 수 있어요 — 같은 작업 하나로 두 개의 등록정보를 채우는 셈이라, 두 배로 고생하지 않아도 돼요.
Mokbi는 게시까지 해줘요. Play Developer API를 통해 등록정보와 에셋을 Google Play에 바로 전송하고, App Store Connect에는 제출 준비가 된 버전을 미리 올려 둬요. Apple은 최종 제출과 심사 절차를 반드시 개발자가 직접 진행하도록 요구하므로, 그 마지막 한 번의 탭은 여전히 사용자의 몫이에요(이는 Apple의 규정이지 Mokbi의 제약이 아니에요). 어느 쪽이든 하나의 구독으로 두 콘솔의 등록정보 업데이트를 한 곳에서 처리할 수 있어요: 에디터는 워터마크 포함으로 무료이며, Solo (월 €29.99) 또는 Studio (월 €49.99)는 구독을 유지하는 동안 무제한 내보내기와 게시를 제공해요.