App Store 메타데이터 반려: 2.3.x, 2.3.7, 4.3, 5.2.1 해결하기
방금 메일을 받았어요. 상태가 Metadata Rejected로 바뀌었고, Resolution Center 메모에는 찾아봐야 알 수 있는 가이드라인 번호가 적혀 있죠. 다행히 메타데이터 반려는 비교적 빨리 해결되는 편이에요. 빌드를 다시 업로드하는 게 아니라 버전 레코드를 수정하고 재제출하면 되니까요.
가장 먼저 확인할 것은 Resolution Center 메시지에 적힌 가이드라인 번호예요. 그게 어떤 필드를 고쳐야 하는지 정확히 알려주거든요. 이 글은 리스팅 반려에서 가장 자주 보게 되는 네 가지를 다뤄요. 가이드라인 번호는 시간이 지나면서 재정리되기도 하니, 여기 나온 내용은 현재 App Store Review Guidelines를 기준으로 해요.
먼저 구조부터: "Metadata Rejected"가 실제로 의미하는 것
Metadata Rejected 상태는 컴파일된 앱이 아니라 스토어 리스팅, 즉 앱 이름, 부제, 키워드, 설명, 스크린샷, 프리뷰, URL을 가리켜요. 문제가 메타데이터에 있으니 새 바이너리는 필요 없어요. App Store Connect에서 지적된 필드를 수정하고, 기존 빌드는 버전에 그대로 붙인 채 재제출하면 돼요.
분명히 짚어둘 유의 사항이 두 가지 있어요. 첫째, 재제출해도 다시 리뷰 대기열에 들어가요. 빌드는 필요 없지만 리뷰는 다시 받는다는 뜻이에요. 사람이든 자동화든 다시 검토가 이루어져요. 둘째, Apple이 지적한 필드 하나만 고친다고 리스팅 전체가 면역이 생기는 건 아니에요. 다음 심사 때 리뷰어가 다른 가이드라인을 걸고 넘어질 수도 있어요. 지적받은 문장만 고치지 말고, 손을 대는 김에 리스팅 전체를 정리하세요.
가이드라인 2.3.3 — 스크린샷은 앱의 실제 사용 모습을 보여줘야 함
유발 원인. 스크린샷이 앱이 실제로 하는 일을 보여주지 않는 경우예요. 대표적인 예로 첫 번째 슬롯이 스플래시 화면, 로그인 페이지, 혹은 실제 UI 없이 태그라인만 있는 타이틀 아트인 경우가 있어요. 앱에 없는 기능을 보여주거나 다른 플랫폼의 기기·인터페이스를 참조할 때도 걸려요.
수정 전: 첫 번째 슬롯이 그라데이션 배경 위에 로고를 가운데 놓고 "일주일을 계획하는 가장 똑똑한 방법"이라는 문구만 있고, 실제 앱 화면은 어디에도 없어요.
수정 후: 첫 번째 슬롯을 핵심 플로우의 실제 화면, 예를 들어 실제 일정이 채워진 주간 뷰로 바꾸고, 기기 위에 혜택을 짚는 짧은 캡션을 넣어요. 리뷰어(그리고 사용자)가 썸네일만 봐도 앱이 뭘 하는지 알 수 있어야 해요. 마케팅 캡션과 기기 프레임은 유지하되, 그 안의 앱 UI는 진짜이고 최신 상태여야 해요.
이건 메타데이터 변경 사항이에요. 버전 레코드의 이미지만 교체하고 재제출하면 돼요. 새 빌드는 필요 없어요.
가이드라인 2.3.7 — 키워드는 앱을 설명해야지, 게임 검색이 되면 안 됨
유발 원인. 키워드 오남용 가이드라인이에요. 메타데이터에 앱을 설명하지 않는 단어들, 즉 소유하지 않은 상표, 더 크거나 인기 있는 앱 이름, 잘못된 필드에 들어간 가격 관련 문구, 도달률을 노리고 넣은 유명인이나 공인 이름, 검색을 낚기 위해 채운 일반적인 문구가 들어가면 걸려요. 100자 키워드 필드가 가장 흔한 문제 지점이지만, 부제와 이름도 지적받을 수 있어요. 앱 이름은 30자 제한이 있고, 가격이나 프로모션 문구는 이름·부제·스크린샷 어디에도 들어가면 안 돼요.
수정 전(키워드 필드): 같은 카테고리의 더 큰 앱 세 개 이름, 유명 크리에이터 이름, 무관한 트렌드 단어 몇 개가 들어가 있고, 그중 어느 것도 실제로 제공하는 기능을 설명하지 않아요.
수정 후: 사용자가 실제 기능을 찾으려고 검색할 만한 단어, 즉 앱이 수행하는 작업, 해결하는 문제, 실제 화면에 나오는 명사로 채워진 키워드예요. 모든 단어는 앱이 진짜로 하는 일을 가리켜야 해요.
수정 전(부제): 이름이 언급된 경쟁 앱과 자신을 비교하는 문구예요.
수정 후: 다른 브랜드 이름 없이, 앱이 제공하는 결과를 명확한 말로 담은 부제예요. 부제는 앱을 설명하는 자리이지, 남의 트래픽을 빌려오는 자리가 아니에요.
가이드라인 4.3 — 스팸 및 유사 중복 앱
유발 원인. 4.3은 유사성에 관한 규정이에요. 도시별, 팀별, 고객별로 하나의 앱 안에 변형을 담는 대신 별도의 번들 ID로 거의 동일한 앱을 여러 개 출시하거나, 이미 널리 알려진 것과 구분하기 힘든 앱을 제출할 때 걸려요. 대개 콘셉트 자체의 문제이지만, 중복을 눈에 띄게 만드는 건 리스팅이에요. 자신의 앱들 사이에서 설명과 스크린샷이 똑같다면 강한 신호가 돼요.
수정 전: 계정 안에 다섯 개의 앱이 있고, 레이아웃과 기능 목록이 같고, 도시나 팀 이름 하나만 바꾼 카피예요.
수정 후: 그 변형들을 앱 내 옵션이나 구매 항목으로 담은 앱 하나와, 실제로 다른 점을 설명하는 리스팅이에요. 정말 별개의 제품이라면, 고유명사만 바꾸는 게 아니라 스크린샷과 설명에서 실제로 무엇이 다른지 각 리스팅이 보여주게 하세요.
기반이 되는 앱이 정말로 얇은 리스킨이라면 4.3은 메타데이터 수정 이상이 필요할 수 있어요. 하지만 리스팅들이 서로의 복제본처럼 읽히는 게 문제라면, 카피와 스크린샷을 차별화하는 건 메타데이터 수정으로 해결돼요.
가이드라인 5.2.1 — 메타데이터에 담긴 타인의 지식재산
유발 원인. 권리가 없는 보호된 제3자 자료, 즉 상표, 저작권이 있는 저작물, 모방한 이름을 번들, 개발자 이름, 메타데이터 어디에든 사용하는 경우예요. 흔한 변형은 리스팅에 표시된 앱·브랜드와 실제 제출 주체가 일치하지 않는 경우로, 이 경우 Apple이 이름의 소유자가 누구인지 묻게 돼요.
수정 전: 소유하지 않은 브랜드나 플랫폼 이름을 앱 제목, 부제, 키워드 필드에 넣어 그 검색 트래픽을 가로채는 경우예요.
수정 후: 제목, 부제, 키워드에 자신의 제품 이름을 쓰는 거예요. 실제로 제3자 플랫폼과 연동하고 그 사실을 언급해야 한다면, 허용되는 범위에서 설명란에만 사실적인 호환성 언급을 남기고 이름과 부제에는 넣지 마세요. 상표 소유자인 고객을 위해 앱을 만들었다면, 그 주체의 계정으로 제출하거나 그 팀에 추가되어 판매자 이름과 브랜드가 일치하도록 하세요.
빌드가 필요 없다는 점, 다시 한번
네 가지 모두, 수정 사항이 버전 레코드, 즉 텍스트와 이미지에 있다면 App Store Connect에서 고치고 같은 바이너리로 재제출하면 돼요. 빌드 번호를 올리거나 처리를 기다릴 필요가 없어요. 그게 메타데이터 반려가 주는 빠른 경로예요. 대신 다시 리뷰를 거쳐야 하니, 하나씩 반려당할 때마다 고치기보다는 재제출하기 전에 리스팅 전체를 이 네 가지 기준으로 한 번에 점검하는 게 나아요.
Mokbi가 도움이 되는 지점(그리고 아닌 지점)
2.3.7 문제 대부분은 작성 단계에서 시작돼요. 키워드 필드나 부제를 도달률 욕심에 부풀리면서요. Mokbi의 AI는 앱이 실제로 하는 일을 바탕으로 이름, 부제, 키워드, 설명 같은 리스팅 카피를 초안으로 작성해서, 처음부터 키워드 반려를 부르는 과잉 채움이나 남의 브랜드를 빌리는 습관에서 멀어지게 해줘요. 그런 다음 그 카피를 50개 언어로 현지화하니, 시장마다 새로 키워드 필드를 손으로 쓰면서 같은 함정을 되풀이하지 않아도 돼요.
한계는 분명히 짚을게요. 이건 문구 때문에 2.3.x나 5.2.1이 걸릴 확률을 낮춰줄 뿐, 승인을 보장하지는 않고 빌드 안에 무엇이 들어있는지는 결정하지 않아요. 리뷰는 Apple의 몫이에요. 규정에 맞고 앱과 일치하는 카피가 해주는 건 스스로 자초한 손쉬운 반려 사유를 없애는 것뿐이에요. Mokbi는 리스팅에 자동으로 게시하지 않아요. 카피와 스크린샷을 만들어주고, 검토하고 제출하는 건 당신 몫이에요.