brunch

You can make anything
by writing

C.S.Lewis

by Bryan Bogeun Song Jun 29. 2018

애플 심사 뽀개기

리젝만 50번 이상 당하면서 깨우친 애플 심사의 모든 것

내가 운영하고 있는 '엑씽크'라는 스타트업은 이벤트앱을 전문으로 만들고 있다. 

이벤트앱은 특성상 행사장에서만 일시적으로 쓰이기 때문에 행사를 위해서 새롭게 배포하게 된다. 그리고 앱을 배포할 때 항상 우리는 애플이라는 거대한 사과를 넘어야 한다. 


만약 이 글을 읽고 있는 iOS 개발자라면 애플 심사 때문에 빡친 적이 있을 것이다. 

나도 수없이 빡쳤고, 애플을 달래보기도, 협박하기도, 타이르기도 하면서 행사일까지 문제없이 앱이 배포되도록 사업을 진행해 왔다. 

지금까지 대략 30~40 개 정도의 앱을 배포한 것 같은데, 행사일까지 반드시 앱이 배포되어야 하는 우리 일의 특성상, 앱이 리젝당할 때마다 리젝 사유를 분석하고, 애플 가이드라인을 검토해왔다. 

지금까지 거절당하며 배운 애플의 심사에 대한 이야기를 해보겠다. 



우선 몇 가지 설명과 꿀팁들은 쓰고 시작하는게 좋을 듯 하다. 


게임은 심사 과정이 다르다. 우리는 지금까지 게임을 심사받아본 적은 없기 때문에 그 분야는 모른다. 

애플 심사원은 CA에 근무하며 한글을 읽을 수 있다. 고로 메모에 한글을 써도 알아본다. 당연한 얘기지만 앱이 한글로 되어 있어도 알아 본다. (간혹 메모를 영어로 열심히 쓰는 경우가 있는데 굳이 그럴 필요 없다) 

애플 심사원은 코드를 뜯어보지 않는다. 앱의 표면적인 기능을 심사할 뿐이다. (2020년 댓글 보고 추가 : 앱의 코드를 뜯어보는 부분이 추가된 것으로 추정됩니다. 메타데이터의 경우 봇이 긁어서 검사하는 것으로 추정합니다. ) 

애플 심사원은 월~토 일한다. 물론 미국시간 기준이다. 토요일에는 반일 근무하는 것으로 추정한다. (한국 시간으로 일요일 아침에 앱 승인이 떨어지는 경우가 있다.) 

앱이 복잡할 수록 앱 심사에 걸리는 시간이 길다. 

2017년 애플에서 심사 기준을 완화하고 인력을 충원하면서 보통 2일 내에 승인이든 리젝이든 나는 경우가 많다. 

Expedited Review 는 항상 받아주는 것은 아니다. 메모에 구구절절 얼마나 급한지 어필하면 받아들여주는 경우가 많기는 하다. 

2017년 이후 기본 심사 시간이 빨라지면서 Expedited Review 와 일반 Review 간의 차이는 대략 12시간 정도이다. (정말 크리티컬한 이슈 아니면 이제 우리도 딱히 신청하지 않는다) 

한 번 리젝을 당하면 expedited review 와 수정제출은 동일하다. 단, expedited review는 기존 심사 내용을 developer reject 하고 다시 올려야 한다. (그러므로 앱 아이콘, 앱 이름 등을 수정해야 하는 경우에는 반드시 developer reject 해야겠지만, 그이외의 경우에는 그냥 수정제출하는 편이 낫다) 

한 번 리젝을 당하고 나서 수정 심사를 요청할 경우, 처음 심사를 진행했던 심사원이 다시 심사한다. 

앱 승인에 걸리는 시간을 추정하기 위해서는 이 사이트를 참고하면 좋다. http://appreviewtimes.com
단! 이 사이트의 시간을 절대적으로 믿으면 안 된다. 트위터를 통해 유저들이 제보하는 정보를 기반으로 하고 있기 때문에 모수가 많지 않다. 때문에 각각의 유저들이 며칠 걸렸다고 제보했는지 반드시 보는 것이 좋다. (글을 쓰고 있는 지금 이 순간 기준으로 33개의 리뷰가 제출되었는데, 대부분 0 아니면 1일 인데, 몇몇 리뷰에서 10 이상이 제출되어서 평균값이 3으로 나온다. 다시 말하면 앱에 기능이 많지 않고, 아래 내가 쓰는 주요한 리젝 사유만 피한다면 0~1일 사이로 승인이 날 가능성이 높다) 

미국 휴일이 낄 경우 애플 심사에 걸리는 시간이 순간적으로 매우 길어진다. (특히 크리스마스 때 1주일 정도 긴 휴일이 있는데, 이 휴일 직후에 3~5일 정도로 리뷰시간이 길어졌다. 물론 1주일 이내에 안정화되었다. 크리스마스 때에는 애플에서 이메일도 날아온다. 자기네 쉴거니깐 앱 심사 미리미리 받으라고. 애플 말은 잘 듣는게 좋다.) 



자 이제 애플의 흔한 리젝 사유들을 araboza. 
내가 장담컨대, 이 리젝 사유들만 온전히 피하면 앱 승인 받는게 어렵지 않을 것이다. 

1. 로고나 저작권 도용

이벤트앱 쪽에서는 가장 흔한 애플 리젝 사유이다. 근데 다른 앱들도 은근히 이거 많이 걸린다. 

특히 샘플 데이터로 제대로 제휴되지 않은 업체의 로고나 연예인 사진 등을 넣었다가 리젝먹은 경우 많다. 

엑씽크의 경우 특히나 연예인 팬미팅 앱을 심사받는 경우 허락받지 않고 연예인 사진을 썼다는 이유로 리젝도 맞아봤다. 그러면 공문 첨부해서 다시 리뷰 요청해야 한다. 정말 귀찮... 

앱 아이콘과 스크린샷에도 로고나 저작권에 대해 주의해야 한다. 설명글은 물론이다. 

앱 아이콘과 스크린샷의 로고 도용은 구글 플레이스토어의 봇도 엄격하게 체크하는 항목이니 조심하여야 한다. 가급적 구글 쪽은 로고를 빼는 것도 나쁘지 않다. 봇은 대화가 통하지 않는다... 


2. 앱 빌더 사용

이건 2018년에 추가된 이슈인데, 앱 빌더를 사용하여 다수의 앱을 하나의 계정으로 배포하는 걸 금지한다. 다시 말하면 하나의 사업체에서 다른 사업체의 앱까지 다 만들어서 하나의 계정으로 관리하는 것이 불가능하다. 반드시 개별 사업체에서 애플 개발자계정을 발급받아야 한다. 

앱 빌더를 사용하지 않고 만드는 건 허용하지만, 해당 사업체가 널리 알려진 사업체일 경우 (대기업 등) 애플에서는 가끔 계약서를 요구한다. 엑씽크의 경우 SK 나이츠 농구단 앱을 만들 때 계약서와 공문을 애플에 보낸 적이 있었다. 그래서 앱 배포에 2주일 정도 걸렸다. 


3. 테스트용 아이디

만약 앱에 회원가입이 있다면 반드시 테스트 아이디와 비밀번호를 발급해서 안내해야 한다. 애플 심사 직원은 회원가입을 하지 않는다. 


4. 회원가입 필수 필드

회원가입시 필수로 적어야 하는 필드가 있을 때, 그 필드와 앱의 기능이 밀접한 연관이 있어야 한다. 

최근 유럽에서 통칭 GDPR 이라는 개인정보보호법 관련 규정 강화안이 발효되면서 애플도 덩달아 개인정보에 대해 매우 엄격하게 보기 시작했다. 

위에서 말했듯이 애플 직원은 코드를 뜯어보지 않기 때문에 필수필드와 앱의 기능이 표면적으로 연관이 있어야 심사를 통과할 수 있으며, 만약 표면적으로 연관성을 알아보기 힘들다면 memo에라도 써서 설명하는 것을 추천한다. 

만약 연관성이 설득력이 없으면 애플은 가차없이 리젝한다. "마케팅에 앞으로 쓸거다" 이런 얘기 안 통한다. 

아 참! SNS로그인을 도입하더라도 일반적인 이메일 또는 아이디 생성을 통한 회원가입절차가 없으면 이것도 리젝 사유이다. 단! SNS로그인이 정말 필수적임을 설득할 수 있다면 허용되는 경우도 있더라. (우리는 SNS로그인만으로 진행한 적은 없어서 모르겠다.) 


5. ip 노출

앱과 연동되어 있는 그 어떤 웹사이트에서도 ip가 노출되어서는 안 된다. 다시 말하면 도메인이 연결되어 있어야 한다. 

특히 테스트 과정에서 아마존 ip를 그대로 가져다가 쓰는 경우가 있는데, 리젝 사유이다. 

애플 심사 직원은 의외로 꼼꼼하게 앱의 모든 링크들을 눌러본다. 


6. 테스트 콘텐츠 노출

앱을 개발하면서 테스트를 위해 이것저것 콘텐츠를 넣을 것이다. 테스트1, 테스트2, 테테테스스트트, 테스트테스트, test1, test88... '테스트', '샘플' 이런 단어가 들어가면 안 된다. 차라리 아무 콘텐츠가 없는 건 리젝 사유가 아니다. 테스트 콘텐츠가 있으면 리젝 사유이다. 

애플의 원칙상, 앱 심사는 앱 출시 직전 단계이기 때문에, 앱의 모든 기능이 출시를 위해 맞춰져 있어야 한다. 

작가의 이전글 웹 vs 하이브리드 vs 네이티브
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari