새 앱 버전 없이 App Store 스크린샷을 변경하는 방법
오늘 라이브 앱의 스크린샷을 바꾸려고 App Store Connect를 열었더니 현재 버전의 스크린샷 필드가 읽기 전용으로 되어 있어요. 이건 버그가 아니라 Apple이 의도한 동작이에요. 스크린샷은 버전 메타데이터의 일부라서, 버전이 승인되고 출시된 후에는 그 메타데이터가 고정돼요. 실제로 구매자가 보는 화면을 바꾸는 경로들과, 각 경로가 빌드 업로드와 심사 시간 면에서 어떤 비용을 요구하는지 살펴볼게요.
필드가 잠겨 있는 이유
App Store Connect는 스크린샷을 특정 앱 버전에 연결해 저장해요. 앱이 라이브 상태일 때 그 버전은 출시됨 상태에 머물고, 스크린샷과 설명, 키워드는 모두 잠겨 있어요. 이 중 하나라도 수정하려면 별도의 편집 가능한 버전 레코드, 즉 "제출 준비 중" 상태의 레코드에서 작업해야 해요. 새 버전이 승인되어 그 위에 출시되기 전까지 라이브 목록은 계속 기존 스크린샷을 보여줘요.
Apple의 공식 문서도 이 점을 분명히 밝혀요. 앱이 제출되고 승인된 후에는 스크린샷을 업데이트하려면 새 버전을 만들어야 한다는 거예요. 그러니 질문은 "라이브 버전을 수정할 수 있는가"(불가능해요)가 아니라 "어떤 방법이 가장 작고 빠른 변경을 만들어내는가"예요.
경로 1: 새 버전 레코드(기본 방식)
대부분의 개발자가 이미 알고 있는 방식이에요. App Store Connect에서 새 버전을 만들고, 편집 가능한 "제출 준비 중" 레코드를 열어 스크린샷을 교체한 뒤 심사를 제출해요. 중요한 점은, 새로운 기능이나 버그 수정을 출시할 필요는 없지만 버전에 빌드가 첨부되어 있어야 한다는 거예요.
App Store Connect는 새 버전의 빌드 선택 목록에 현재 라이브 상태인 빌드를 표시하지 않아요. 그래서 실무에서는 둘 중 하나를 해요. 이미 업로드해 둔 다른 빌드를 고르거나(과거 TestFlight 업로드에서 남은 것도 괜찮아요), 같은 소스 코드로 빌드 번호만 올려 새 바이너리를 올리는 거예요. 어느 쪽도 기능을 추가하지 않아요. 하지만 빌드는 반드시 있어야 하고, 스크린샷을 포함한 버전 전체가 App Review를 거쳐요. 새 스크린샷은 그 버전이 승인되어 출시된 후에야 나타나요.
어차피 스크린샷 외에도 다른 걸 바꾸는 경우, 예를 들어 비주얼과 함께 새 설명과 키워드 세트도 바꾸는 경우라면 이 경로가 유리해요. 모든 게 하나의 제출로 묶여서 처리되니까요.
경로 2: Product Page Optimization(새 버전도, 새 빌드도 필요 없음)
Product Page Optimization(PPO)은 Apple 내장 A/B 테스트 기능이면서, 새 버전도 새 빌드도 전혀 없이 스크린샷과 프리뷰 동영상을 바꿀 수 있는 유일한 방법이기도 해요. 테스트를 만들고 새 스크린샷을 담은 처리안을 추가해서 제출하면 돼요. Apple도 이 메타데이터는 앱의 새 버전을 제출하지 않고도 제출할 수 있다고 직접 명시하고 있어요.
다만 여기에도 함정이 있어요. 새 크리에이티브는 테스트가 실행되기 전에 여전히 App Review를 거쳐야 해요. 유일한 예외는 이미 승인되어 스토어에 있는 스크린샷의 순서만 바꾸는 경우로, 이건 새 심사가 필요 없어요. 정말로 새로운 것은 모두 먼저 검토받아요.
PPO는 실험으로 설계되어 있어서 결과는 전환율의 추정 상승폭, 즉 현재 페이지 대비 백분율과 데이터 신뢰도로 돌아와요. 측정된 테스트보다 그냥 모두에게 새 스크린샷을 라이브로 보여주고 싶다면 테스트를 만들어 실행한 뒤, 승리한 처리안을 기본 제품 페이지에 적용하면 돼요. 처리안을 적용하면 테스트가 종료되고 그 크리에이티브가 모든 구매자에게 노출되며, 이때도 바이너리 업로드는 필요 없어요.
분명히 짚어둘 경계가 하나 있어요. 스크린샷과 프리뷰 동영상은 PPO를 통해 빌드 없이 바꿀 수 있지만, 대체 앱 아이콘은 아니에요. 아이콘은 이미 스토어에 있는 바이너리 안에 컴파일되어 있어야 하므로, 정말 새로운 아이콘이라면 여전히 빌드가 필요해요. 빌드 없는 스크린샷 교체에 아이콘은 포함하지 마세요.
경로 3: Custom Product Pages, 타겟팅용 변형 페이지
메인 목록을 바꾸는 게 아니라 특정 잠재고객이나 광고 캠페인용으로 다른 스크린샷 세트를 원한다면, Custom Product Pages를 이용해 별도의 URL로 대체 버전을 게시할 수 있어요. 각 변형 페이지는 개별적으로 심사를 받고 링크를 통해서만 접근하므로, 기본 페이지는 그대로 유지돼요. 이건 "라이브 목록을 바꾸는" 도구라기보다는 타겟팅 도구지만, 전체 앱 출시 없이 스크린샷을 이리저리 옮기는 방법을 고민할 때 함께 고려할 가치가 있어요.
언제든 바꿀 수 있는 유일한 필드: 홍보 텍스트
홍보 텍스트는 새 버전이나 App Review 없이 수정할 수 있는 유일한 App Store 필드예요. 설명 맨 위에 자리한 170자짜리 블록으로, 수정 사항은 몇 시간 안에 자동 반영돼요(Apple은 최대 48시간까지 허용해요). 키워드 순위에 색인되지 않으므로 검색 순위는 움직이지 않지만, 스크린샷 변경이 아직 심사 중일 때 시급한 문구를 넣기에 딱 맞는 자리예요.
경로별 비교: 빌드와 심사 한눈에 보기
어떤 경로를 선택할까
- 스크린샷만 교체하는 가장 빠른 방법. Product Page Optimization. 빌드 없이 새 크리에이티브에 대한 심사 한 번만 거치면, 처리안을 적용해 모두에게 라이브로 노출돼요.
- 스크린샷에 텍스트나 키워드까지 함께 바꾸는 경우. 새 버전 레코드로, 전체 업데이트가 하나의 제출로 나가요.
- 메인 페이지가 아닌 특정 캠페인용 다른 비주얼. Custom Product Page.
- 한 시간 안에 라이브로 반영해야 하는 문구. 실제 스크린샷 변경이 심사 중인 동안 홍보 텍스트로 대응하세요.
Mokbi가 어디에 도움이 될까
Mokbi는 스크린샷 갱신 전체 과정을 처음부터 끝까지 처리해요. 새 스크린샷과 Google Play 피처 그래픽을 디자인한 다음, 제목·부제목·설명·홍보 텍스트를 포함한 전체 목록을 작성하고, 한 번에 50개 언어로 모두 번역해요. 보통 스크린샷 갱신 작업을 지체시키는 부분이 바로 이 부분인데, Mokbi는 이걸 하나의 흐름 안에서 처리해요.
그런 다음 게시까지 진행해요. Mokbi는 Play Developer API를 통해 목록과 완성된 에셋을 Google Play에 바로 밀어넣어 즉시 라이브로 반영하고, App Store Connect에는 제출만 하면 되도록 모든 걸 준비해 둬요. 최종 제출과 App Review는 Apple 정책상 반드시 본인 계정에서 직접 진행해야 하므로 그 한 번의 클릭만은 사용자 몫으로 남지만, 크리에이티브와 카피는 이미 모든 언어로 준비된 채 새 버전이나 Product Page Optimization 테스트 안에 자리잡고 있어요. 콘솔을 여는 순간 바로 볼 수 있죠.