새 버전 없이 바꿀 수 있는 것들: 애플 vs 구글
스토어 리스팅을 건드리기 전에 답해볼 가치가 있는 질문이 하나 있습니다. 이 수정이 전체 제출 절차를 요구할까요, 아니면 조용히 나갈 수 있을까요? 잘못 판단하면 예상치 못한 심사 대기열에 갇히거나, 실제로는 승인을 기다리고 있는데 이미 반영됐다고 착각하게 됩니다. 두 스토어는 이 질문에 정반대로 답하며, 이 차이야말로 두 스토어의 리스팅을 동기화하는 일이 번거로운 근본 이유입니다.
여기 필드별로 솔직하게 정리한 내용이 있습니다 — 먼저 비교표를 보고, 이어서 각 스토어 규칙의 이유를 살펴보면 이 표에 나오지 않은 경우도 예측할 수 있습니다.
비교표
흔히 쓰이는 모든 리스팅 필드와, 각 스토어가 그 필드를 수정할 때 요구하는 것입니다. "새 버전/릴리스"는 스토어가 그 수정을 제출해야 할 절차의 일부로 취급한다는 뜻이고, "심사"는 게시되기 전에 사람 또는 자동화된 검사가 실행된다는 뜻입니다.
| 앱 아이콘 | 기본 아이콘은 바이너리에 포함되어 배포되므로 변경하려면 새 빌드가 필요합니다. 그 빌드와 함께 심사를 거칩니다. | 스토어 아이콘은 리스팅 자산입니다. 새 릴리스가 필요 없습니다. 심사는 거칩니다. |
여기서 두 가지가 눈에 띕니다. 애플은 거의 모든 것을 버전 레코드로 몰아넣습니다. 구글은 리스팅 전체가 독립적으로 움직일 수 있게 합니다. 하지만 어느 스토어도 중요한 자산에 대한 심사는 건너뛰지 않습니다 — "심사"라는 단어가 거의 모든 칸에 등장합니다. 그러니 진짜 질문은 "이게 심사를 받을까"가 아니라 "이 수정이 제출 절차를 함께 끌고 오는가"입니다.
애플: 새 버전 레코드는 새 빌드와 다르다
사람들이 헷갈리는 지점이 바로 이겁니다. App Store에서 스크린샷, 이름, 부제, 키워드 필드, 설명을 수정하면 리스팅의 새 버전이 만들어집니다. 이러면 Xcode로 다시 돌아가야 할 것 같지만, 그렇지 않습니다. 애플은 현재 메타데이터를 새 버전에 자동으로 그대로 옮기며, 메타데이터만 바꾸는 경우 새 앱 코드는 필요 없습니다 — 빌드를 하나 첨부해야 하지만(App Store Connect는 버전에 빌드를 여전히 요구합니다) 앱의 동작은 아무것도 바뀌지 않습니다. 대기 중인 필드들을 수정하고, 제출하면, 심사 한 번으로 전부 처리됩니다.
그래서 "새 코드는 없지만 심사는 받는다"가 정확한 표현입니다. 컴파일 단계도, 새 기능도 없지만 그 수정은 여전히 App Review에 들어가고 공개되기 전까지 차례를 기다립니다. 변경 사항은 한꺼번에 모으세요. 하나의 버전 레코드에 새 스크린샷, 다시 쓴 설명, 새로운 부제, 업데이트된 키워드를 모두 담을 수 있으니, 굳이 각각에 별도의 심사 사이클을 쓸 이유가 없습니다.
앱 아이콘은 빌드가 실제로 필요한 예외입니다. 기본 아이콘은 바이너리 안에 구워져 그것에서 그려지므로, 진짜로 새로운 아이콘은 새 빌드를 뜻합니다. 대체 아이콘도 마찬가지입니다 — 사용하려면 앱에 번들되어 있어야 하므로, 하나를 추가하는 것은 리스팅 수정이 아니라 빌드입니다.
애플의 두 가지 예외 통로
프로모션 텍스트. 버전도 심사도 없이 바꿀 수 있는 유일한 필드입니다. 170자이고 설명 위에 표시되며, 원할 때마다 업데이트할 수 있습니다 — 세일, 출시 안내, 시의성 있는 문구에 유용합니다. 검색 순위에 영향을 주지 않고 어떤 제출에도 속하지 않는데, 바로 그 이유로 스토어에서 가장 빠르게 바꿀 수 있는 항목입니다. 오늘 당장 반영해야 할 것이 있다면 이 필드로 가능합니다.
제품 페이지 최적화(PPO). PPO는 스크린샷, 앱 미리보기, 아이콘의 최대 세 가지 버전을 실제 제품 페이지에서 테스트할 수 있게 해줍니다 — 새 앱 버전 배포 없이요. 이는 애플에서 정상적인 제출 절차 밖에서 비주얼을 바꾸는 것에 가장 가까운 방법입니다. 다만 두 가지 유의점이 있습니다. 테스트 메타데이터는 테스트가 시작되기 전에 여전히 승인을 받아야 하고(즉 심사는 받되 즉시는 아닙니다), 테스트하려는 아이콘은 반드시 현재 앱 바이너리에 이미 포함되어 있어야 합니다. PPO는 방문자가 보는 화면을 바꿀 뿐, 심사를 건너뛰지는 않습니다.
Google Play: 릴리스 없이 리스팅 게시하기
Play는 반대로 작동합니다. 제목, 짧은 설명, 전체 설명, 스크린샷, 기능 그래픽, 아이콘, 프로모션 동영상 등 스토어 등록정보는 새 앱 릴리스를 첨부하지 않고도 독립적으로 수정하고 게시할 수 있습니다. 수정을 하면, Publishing 개요에서 심사 제출 준비가 된 변경 사항으로 표시됩니다. 이를 제출하면 구글의 심사를 거쳐, 어떤 빌드와도 무관하게 게시됩니다.
과장하지 않도록 정확히 짚어야 할 몇 가지가 있습니다. 이 변경 사항도 여전히 심사를 받습니다 — Play의 심사는 리스팅 수정에도 적용되며 앱 이름이나 아이콘 같은 요소도 검사되므로, 조용히 즉시 바뀌는 것은 아닙니다. 그리고 리스팅은 이미 출시된 앱과 무관하게 존재할 수 없습니다. Play는 수정할 공개 리스팅이 있으려면 앱이 이전에 릴리스된 적이 있어야 합니다. 한 번도 출시된 적 없는 것을 위한 독립 스토어 페이지를 올릴 수는 없습니다. 관리형 게시(managed publishing)를 알아두면 하나 더 짚을 만합니다 — 이게 켜져 있으면, 승인된 변경 사항은 당신이 실제로 게시하기 전까지 대기하는데, 이를 예상하고 있다면 지연이 아니라 기능입니다.
비대칭, 그리고 그것이 시간을 잡아먹는 이유
두 모델을 나란히 놓으면 구분이 뚜렷합니다. 애플은 거의 모든 텍스트와 이미지 수정을 버전 레코드와 심사 절차에 묶어두며, 프로모션 텍스트와 PPO만이 예외입니다. 구글은 리스팅을 릴리스에서 완전히 분리하고, 수정 사항을 심사한 다음 앱이 이미 존재하는 한 자체 일정대로 게시합니다.
두 스토어를 함께 운영하면 이 비대칭은 조용히 비용을 잡아먹습니다. 같은 스크린샷 갱신이 한 스토어에서는 버전 레코드 제출이고, 다른 스토어에서는 독립적인 리스팅 업데이트입니다. 설명 다시 쓰기는 애플에서는 심사받는 버전이고 구글에서는 심사받는 리스팅 변경입니다. 내용은 같지만 절차가 다르므로, Play에서는 한 번의 동작인 변경이 App Store에서는 다른 동작이 됩니다 — 하나만 반영하고 다른 하나는 잊어버리기 쉽고, 애플에서 아직 심사 중인데 이미 반영됐다고 착각하기도 쉽습니다.
Mokbi가 맞아떨어지는 지점
이 스토어 간 비대칭이야말로 퍼블리싱 도구가 제 역할을 하는 이유 전부입니다. Mokbi는 스크린샷 에디터로 시작했지만, 리스팅은 텍스트와 이미지가 함께 있는 것입니다 — 그래서 스크린샷 세트를 디자인하고 두 스토어의 리스팅 문구를 한곳에서 작성합니다. App Store의 이름, 부제, 키워드 필드, 설명, 그리고 Play의 제목, 짧은 설명, 전체 설명까지요. 두 번 붙여넣는 하나의 텍스트 덩어리 대신, 각 스토어가 실제로 색인화하는 필드를 그 스토어에 맞게 얻는 것입니다.
그다음 스크린샷과 문구를 포함한 리스팅 전체를 50개 언어로 번역하므로, 한 번 바꾼 내용이 다른 곳은 모두 현지화되어 있는데 영어만 남는 일 없이 모든 마켓의 올바른 필드에 반영됩니다. 그리고 게시까지 합니다. Mokbi는 완성된 리스팅을 Play Developer API를 통해 Google Play에 바로 반영하고, App Store Connect에는 제출 준비 상태로 올려둡니다 — 애플 쪽에서는 여전히 마지막 Submit과 심사가 필요한데, 이는 애플의 규칙이자 이 글 전체가 다루는 스토어 간 비대칭성 그 자체입니다. 이 마지막 심사가 바로 이 글에서 다룬 시계가 돌기 시작하는 지점이기도 합니다.