SMART LOTTO 개발기 3편 — QR 코드 기능이 앱스토어 심사를 막았다

앱은 완성됐는데 심사가 안 통과된다

기능을 다 만들고 앱스토어 심사를 제출했습니다. 그런데 반려가 왔습니다.

반려 이유를 읽어보니 황당했습니다. 심사관이 제 앱을 실제 복권을 구매하거나 도박을 하는 앱으로 판단했습니다. 당연히 그런 앱이 아닙니다. 저는 그냥 통계와 번호 생성 도구를 만든 거였습니다.

그 당시 앱에는 카메라로 로또 구매 용지의 QR 코드를 스캔하면 당첨 결과 페이지로 바로 이동하는 기능을 넣어뒀습니다. 편의 기능이었습니다. 직접 동행복권 사이트에 들어가서 번호를 조회하는 것보다 훨씬 빠르니까요.

하지만 심사관의 눈에는 달라 보였던 것 같습니다. "카메라로 복권 QR을 스캔해서 결과를 보여준다" — 이 동작이 실제 복권 서비스 앱처럼 보였던 거죠.

반려 사유는 대략 이런 내용이었습니다.

이 앱은 실제 복권 거래를 지원하는 것으로 보입니다. 복권 판매 또는 도박 관련 앱은 별도의 심사 기준을 충족해야 합니다.

Appeal을 작성했습니다. 제 앱은 복권을 사거나 판매하지 않는다, 현금이 오가지 않는다, QR 스캔은 단순히 외부 웹사이트로 이동하는 기능이다 — 최대한 명확하게 설명했습니다.

결과는 같은 반려였습니다.

심사관이 바뀐 건지 같은 사람인지 알 수 없지만, 비슷한 이유로 또 반려. 몇 차례 반복됐습니다.

이 문제를 해결한 방법은 기능을 제거하는 게 아니라 숨기는 것이었습니다.

QR 스캔 기능 자체는 코드에 남겨뒀습니다. 단지 해당 화면으로 이동하는 버튼을 UI에서 제거했습니다. 기능은 있지만 접근할 방법이 없는 상태.

그렇게 제출했더니 심사가 통과됐습니다.

논리적으로 이상한 결과입니다. 기능의 존재 여부가 문제였다면 코드에 남아 있는 것도 안 되어야 합니다. 하지만 심사관은 앱을 실행해서 화면을 확인하는 방식으로 검토하기 때문에, 접근 불가능한 기능은 보이지 않았던 겁니다.

앱스토어 심사는 자동화된 검토와 사람의 검토가 섞여 있습니다. 그리고 사람이 개입하는 부분에서는 정책 문서와 실제 판단 사이에 불일치가 생길 수 있습니다.

이 경험 이후로 새 기능을 기획할 때 항상 심사 가이드라인을 먼저 읽는 습관이 생겼습니다. 특히 결제나 외부 서비스 연동, 사용자 생성 콘텐츠가 들어가는 경우에는요.

편의 기능 하나 때문에 심사를 몇 번이나 반복한 건 아까웠지만, 앱스토어가 어떻게 돌아가는지를 일찍 배운 건 나쁘지 않았습니다.

다음 편에서는 1,200회 분량의 데이터를 다룰 때 성능을 어떻게 잡았는지 이야기해보겠습니다.