들어가며
이번에 App Store 배포를 담당하게 되었습니다. 그 동안은 대부분 정규 릴리즈 담당이었어서 특별한 이슈가 없었는데, 이번에는 여러 번의 배포를 거치면서 많은 것을 배웠습니다.
특히 이번 배포는 특별했습니다. 특정 날짜 이후로 기능이 배포되어야 하는 상황이었고, x.x.0 버전은 미리 배포해두고, x.x.1 버전을 스크린샷과 앱 설명을 업데이트해서 배포해야 했어요.
일요일 오전에 배포를 시작하고 싶었고, 금요일 오후에 심사 제출을 했기 때문에 여유로운 상황은 아니었습니다. 그래서 긴급 심사 요청을 하게 되었습니다.
그런데 예상치 못한 문제들이 연속으로 발생했습니다. 스크린샷 규정 위반으로 첫 번째 제출이 리젝되었고, 승인 받았던 빌드를 실수로 취소했고, 예약 배포도 제대로 작동하지 않았습니다.
이번 글에서는 실제로 겪은 문제들과 해결 방법, 그리고 배운 점들을 배포 과정의 흐름에 따라 정리해보겠습니다.
심사 제출 전 준비 과정
스크린샷 규정 위반으로 첫 번째 리젝
첫 번째로 마주한 문제는 스크린샷 규정이었습니다. 스크린샷은 디자이너에게 받았는데, 가격 정보가 포함되면 안 된다는 사실을 몰랐습니다.
“무료”라는 표현이 스크린샷 이미지에 포함되어 있었는데, 이것 때문에 심사에서 반려되었습니다. 가격 정보를 제거하니 심사를 통과했어요.
흥미로운 점은 앱 설명에는 가격 정보가 포함되어도 된다는 것입니다. 스크린샷과 앱 설명의 규정이 다르다는 점이 이상하더라고요.
특수문자 사용 제한
앱 설명에 < 키보드로 입력한 꺾쇠 문자를 넣으면 “사용할 수 없는 단어가 포함되어 있다”는 에러가 발생했습니다.
이 문제를 해결하기 위해 <과 비슷한 특수문자를 찾아서 사용했습니다:
〈(U+2329) - left-pointing angle bracket〉(U+232A) - right-pointing angle bracket
눈으로 봤을 때는 제대로 표시되었고, App Store Connect의 정책상 제한사항인 것 같습니다.
스크린샷 업데이트를 위한 전략
비즈니스 내용을 반영하기 위해 빠르게 스크린샷을 바꿔야 하는 상황이 있었습니다. 그런데 앱 버전을 올리지 않고 스크린샷과 앱 설명만 바꾸는 것은 불가능하더라고요.
동료의 조언을 듣고 스크린샷 업데이트를 위해 다음 빌드를 미리 만들어두는 전략을 사용했습니다. 동일한 구현에 버전만 바꿔서 빌드를 만들어두고, 앞선 버전의 심사가 완료된 직후 업데이트된 스크린샷과 설명으로 심사 요청을 했습니다.
이 방법 덕분에 빠른 스크린샷 업데이트가 가능했어요.
긴급 심사
스크린샷과 앱 설명을 업데이트한 후 긴급 심사를 요청했습니다. 남들이 진행하는 것을 보기만 했는데 직접 요청한 것은 처음이었습니다. 예전에는 긴급 심사가 필요한 이유를 메시지로 작성할 수 있었던 것 같은데, 지금은 그런 입력란이 없어졌더라고요.
현재는 Apple Developer Contact 페이지에서 앱 심사 > 빠른 앱 심사 요청 > 앱 심사 문의 > App Information에서 App Name과 Platform만 입력하면 끝입니다.
처음에는 스크린샷과 앱 설명에 규정 위반 사항이 있어서 반려되었는데, 수정해서 다시 제출했을 때는 1~2시간 안에 승인해주더라고요. 긴급 심사의 효과를 직접 체감할 수 있었습니다.
공유하기 부끄럽지만 긴급 심사를 통해 승인되었던 것을 실수로 취소했습니다. 자동화 스크립트 실행 중 실수로 제출이 취소되었습니다… 순간 식은땀나고 아주 당황했어요. 다행히 다시 제출했을 때 1시간 내로 승인되었습니다.
예약 배포와 점진적 배포에 대한 오해
예약 배포의 불안정성
아침 6시에 릴리즈되어야 하는 상황이 있어서 예약 배포를 사용해보았습니다. App Store Connect에서 현지 날짜와 시간으로 정확하게 설정되어 있었는데, 이상하게도 제대로 작동하지 않았어요.
“출시 대기 중” 상태로 계속 남아있었습니다. 20분 정도 기다려도 변화가 없어서 결국 “수동으로 버전 출시”로 변경한 후 직접 출시 시작을 했습니다.
예약 배포 기능은 편리해 보이지만 가끔은 안정적이지 않은 것 같습니다. 여러번 해본 것은 아니라서 개인 프로젝트에서 나중에 다시 써보려고 합니다.
점진적 배포에 대한 오해
점진적 배포에 대해서는 완전히 잘못 알고 있었습니다. 처음에는 마치 A/B 테스트처럼 App Store에서도 점진적으로 유저에게 보여진다고 생각했어요.
실제로는 App Store에는 모든 유저에게 즉시 공개되고, 자동 업데이트를 허용한 유저에게만 점진적으로 배포되는 기능이었습니다.
이 점을 제대로 이해하지 못하고 있었던 게 큰 오해였네요.
재제출 과정에서 발견한 주의사항들
앱 내 이벤트 취소 시 주의사항
앱 심사 제출을 취소할 때 주의해야 할 점을 발견했습니다. 특정 마케팅 이벤트가 앱 내 이벤트로 등록되어 있었는데, 앱 심사 제출을 취소하면서 앱 내 이벤트도 함께 취소되었습니다.
출시를 취소할 때는 심사 대상에 앱 내 이벤트가 있었는지 확인해보고, 있다면 마케팅 담당자에게 미리 알려주는 것이 좋겠습니다.
Apple 심사 속도 개선
긴급 심사가 아니더라도 24시간 이내에 심사 등록부터 배포까지 가능했습니다. 예전에 비해 Apple의 심사 속도가 빨라졌다는 얘기를 몇 년 전부터 들었는데, 실제로 체감할 수 있었습니다.
앱 카테고리, 심사 복잡도 등 여러 요인이 있을 수 있겠지만, 전반적으로 심사 속도가 개선된 것 같습니다.
배포 담당자로서의 배움
중요한 배포였어서 걱정도 있었고 압박감을 많이 느꼈습니다. 그래도 이번 배포를 거치면서 많은 것을 배웠습니다. 특히 App Store의 복잡한 정책들과 예상치 못한 제한사항들을 직접 경험하면서, 사전 준비의 중요성을 깨달았습니다.
주요 배운 점들을 정리하면:
- 스크린샷 규정: 가격 정보 포함 금지, 앱 설명과는 다른 규정
- 긴급 심사: 메시지 입력란 없음, Apple Developer Contact에서 별도 요청
- 스크린샷 업데이트: 새 버전 필요, 미리 빌드 준비 전략
- 특수문자 제한: 유니코드 특수문자로 대체 가능
- 예약 배포: 이번 경험에서 불안정했음
- 점진적 배포: App Store 노출과 무관, 자동 업데이트 사용자에게만 적용
- 앱 내 이벤트: 심사 취소 시 함께 취소됨, 사전 협의 필요
갑자기 생각났는데 앱스토어 규정 위반에 걸릴게 없는지 미리 확인해주는 서비스가 있으면 좋을 것도 같네요.
마무리
App Store 배포는 단순히 빌드를 업로드하고 심사를 기다리는 것이 아니라, 다양한 정책과 제한사항을 이해하고 대응해야 한다고 생각해요. 이번에도 팀원들의 도움을 받으며 많은 것을 배울 수 있었습니다. 이슈들을 겪으면서 예전에는 운이 없었다고 생각했던거 같은데, 요즘에는 이상하게 긍정적으로 변해서 좋은 경험과 추억거리가 쌓여서 기분이 좋기도 합니다. 아무튼 다음번 배포 때는 좀 더 능숙할거라는 희망을 가져봅니다.
참고 자료