양쪽 스토어에 현지화된 스크린샷 일괄 업로드하기
deliver/supply)뿐이에요. Mokbi는 모든 로케일 × 기기 조합을 렌더링해 양쪽 스토어에 세트를 게시해줘요. Google Play에는 Play Developer API로 바로 밀어 넣고, App Store Connect에는 최종 제출만 하면 되도록 준비해 둬요.출시를 한창 진행 중이라고 해봐요. 스크린샷은 완성됐어요. 이제 지원하는 모든 언어로, 각 스토어가 요구하는 모든 기기 크기에 맞춰 양쪽 스토어에 올려야 해요. 아무도 미리 알려주지 않는 부분이 바로 여기예요. 그리고 사람들이 조용히 "bulk upload localized screenshots app store connect / google play all languages" 같은 검색어를 입력하게 되는 순간이기도 하죠.
먼저 솔직한 답부터 드리자면, 더 찾아볼 필요 없어요. 두 스토어 모두 로케일 전체를 아우르는 네이티브 일괄 업로드는 없어요. 로케일별, 기기 크기 그룹별로 웹 UI에서 하나씩 업로드해야 해요.
"일괄 업로드가 없다"는 게 실제로 의미하는 것
App Store Connect에서는 앱을 열고 버전을 고른 다음 스크린샷 섹션으로 스크롤해서 6.9", 6.5", 13" iPad 등 특정 디스플레이 타입 슬롯에 PNG를 드래그해요. 그런 다음 로케일 드롭다운을 다음 언어로 바꿔서 다시 반복해요. Apple은 기기 종류별, 로케일별로 최대 10장까지 스크린샷을 허용하지만, 이미지에 대한 "모든 언어에 적용" 버튼은 없어요.
Google Play Console도 방식은 같아요. 기본 스토어 등록정보에서 로케일을 선택한 뒤, 휴대전화·7인치 태블릿·10인치 태블릿, 그리고 선택적으로 Chromebook, Wear OS, Android TV 등 신규 기기 유형별 섹션에 스크린샷을 업로드해요. 기기 종류별 최대 8장까지 가능하고, 언어를 바꿔가며 반복해요.
즉 작업 단위는 "스크린샷 세트 하나"가 아니에요. 1개 언어 × 1개 기기 크기 그룹 = 1개의 작업 단위이고, 이 작업 단위를 하나하나 손으로 채워야 해요.
이 작업량을 숫자로 따져보면
작업 단위 수를 정직하게 세어봐요. Apple에서는 일반적인 제출이 최소 iPhone 디스플레이 그룹과 iPad 디스플레이 그룹을 채우니, 2개로 볼게요. 6.9" 외에 별도로 6.5" iPhone 세트까지 유지한다면 더 늘어나요. Play에서는 휴대전화와 태블릿 두 사이즈를 채우니 3개로 잡고, Chromebook이나 Wear OS를 추가하면 더 늘어나요.
- 1개 언어, 양쪽 스토어: Apple 작업 단위 약 2개 + Play 작업 단위 약 3개 = 수동 업로드 5회.
- 10개 언어: 약 20 + 30 = 채워야 할 작업 단위 50개, 각각 최대 8~10장의 이미지.
- 50개 언어: 약 100 + 150 = 개별 드래그 앤 드롭 업로드 250회. 이건 올바른 자리에 올바른 이미지가 들어갔는지 확인하기도 전 얘기예요.
로케일당 30분 드래그라는 수치는 괜히 나온 게 아니에요. 언어 수가 조금만 많아져도 이건 더 이상 작업이 아니라 오후 시간을 통째로 잡아먹는 일이 되고, 다음 출시 때 또 반복돼요.
유일한 두 자동화 경로
웹 UI를 완전히 건너뛰고 싶다면, 각 스토어당 정확히 하나씩, 공식 지원되는 문이 두 개 있어요.
- App Store Connect API. screenshots 리소스를 이용하면 특정 로케일과 기기 디스플레이 타입에 대해 세트를 만들고 이미지를 프로그래밍 방식으로 업로드할 수 있어요. API 키로 인증한 뒤 로케일별, 디스플레이 그룹별로 이미지를 밀어 넣어요.
- Google Play Developer API.
edits.images.upload메서드는 지정한 언어와 이미지 타입(phoneScreenshots,sevenInchScreenshots,tenInchScreenshots등)의 이미지 한 장을 대기 중인 편집(edit)에 업로드하고, 이후 커밋하면 반영돼요.
대부분의 팀은 이 API를 직접 호출하지 않고 fastlane을 그 위에 얹어 써요. deliver(upload_to_app_store로도 노출됨)는 App Store Connect API를 구동하고, supply(upload_to_play_store)는 Play Developer API를 구동해요. supply는 여러 업로드 스레드를 동시에 띄워 현지화 이미지를 병렬로 밀어 넣기도 해요. 이게 진짜 "일괄 업로드"예요. 대시보드의 버튼이 아니라 API 반복 호출인 셈이죠.
다만 비용도 분명히 짚어야 해요. fastlane을 쓰려면 Ruby 툴체인, fastfile, 스토어 API 자격 증명, 그리고 (Apple 쪽은) 코드 서명과 시뮬레이터 관련 작업까지 따라와요. 자주 출시하는 앱이라면 확실히 이득이지만, 1년에 몇 번만 제출하는 앱이라면 스크린샷 업로드 하나만을 위해 이걸 구축하는 게 오히려 원래 하던 드래그 작업보다 더 큰 일이 될 수 있어요. 이미 빌드용으로 fastlane을 돌리고 있다면 스크린샷 단계를 추가하는 건 거의 공짜예요.
진짜 병목: 스크린샷은 어디서 나오나
위에서 언급한 모든 경로는 파일이 이미 존재한다고 가정해요. 크기가 정확하고, 기기 그룹별로 세트가 하나씩 있고, 언어별로 번역돼 있어야 하죠. 사실 그게 진짜 어려운 부분이에요. App Store Connect API와 Play Developer API는 완성된 이미지를 옮길 뿐, 디자인하거나 리사이즈하거나 문구를 번역해주지는 않아요. 만약 디자인 툴에서 5개 기기 크기 × 50개 언어 변형을 수작업으로 만들고 있다면, 업로드는 애초에 병목이 아니었던 셈이에요.
이게 바로 Mokbi가 메워주는 빈틈이에요. 디자인 하나를 만들면, 그 하나의 소스에서 모든 기기 크기와 50개 언어 각각을 렌더링해요. 문구는 번역되고, 레이아웃은 자동으로 다시 배치되며, 각 프레임은 해당 스토어 슬롯이 요구하는 정확한 픽셀 치수로 내보내져요. 결과물은 하나의 배치, 즉 이름이 붙고 정리된 로케일 × 기기 파일 세트로, 바로 슬롯에 넣기만 하면 돼요.
원클릭으로 양쪽 스토어에 게시
Mokbi는 바로 이 문제를 해결해요. 세트 하나를 만들면 모든 로케일 × 모든 기기 크기를 렌더링하고 양쪽 스토어에 게시해요. Google Play에는 Play Developer API로 바로 밀어 넣고, App Store Connect에는 세트를 준비해 둬서 제출만 하면 돼요. Apple은 최종 제출과 심사를 요구하므로 그 마지막 탭은 직접 눌러야 하지만, 그 앞의 모든 과정은 자동으로 처리돼요. 로케일별, 기기별 수동 업로드는 필요 없어요.
이미 자체 CI에서 fastlane이나 스토어 API를 돌리고 있다면, 같은 방식으로 내보낸 파일이 deliver와 supply에 바로 들어가요. 어느 쪽이든 디자인, 리사이즈, 50개 언어 번역은 이미 끝나 있고, 이제 게시까지 끝나 있어요.
실제로 그 오후 시간을 되찾아주는 워크플로우
- 한 번만 디자인. 에디터에서 캐러셀을 딱 한 번 만들어요.
- 전체 조합을 일괄 내보내기. 모든 기기 크기 × 모든 언어를 정확한 스토어 치수로 한 번에 내보내요.
- 양쪽 스토어에 게시. Mokbi가 Google Play로 세트를 밀어 넣고 App Store Connect에는 최종 제출용으로 준비해 둬요. 자체 CI를 쓴다면 파일을 fastlane
deliver/supply에 넘겨도 돼요. - 다음 출시 때는 다시 내보내고 반복. 디자인을 한 번만 바꾸면 전체 조합을 다시 생성해 다시 업로드해요.
중요한 계산은 이래요. 작업 단위 개수는 그대로지만, 완성되고 정확한 크기의 파일을 그대로 올리기만 하면 되니 단위당 걸리는 시간이 확 줄어들어요. 오후 시간과 커피 한 잔의 차이인 셈이죠.