퇴근 후 나만의 AI 팀
PART 12앱스토어심사반려

세 번 거절당했다 — 기계에게, 사람에게, 정책에게

제출 4번, 반려 3번, 8일. 거절은 자동 심사에서 사람 심사로, 다시 정책 심사로 점점 깊어졌다.

2026-08-107분 분량
자동사람정책

앞 편을 "스토어 등록을 마쳤다"로 끝냈는데, 솔직히 말하면 그건 제출이었다. 등록과 출시 사이에는 심사라는 관문이 있고, 나는 그 관문 앞에서 세 번 돌려보내졌다.

8일이 걸렸다. 제출 네 번, 반려 세 번. 그리고 지금 돌아보면 이 세 번의 거절이 이 프로젝트 전체에서 가장 많이 배운 구간이었다. 반려가 자동 심사 → 사람 심사 → 정책 심사 순서로 점점 깊어졌기 때문이다.

  • 1차 : 사람이 보기도 전에 기계가 막았다
  • 2차 : 사람이 앱을 열어보고 막았다
  • 3차 : 앱은 멀쩡한데 정책이 막았다

1차 — 쓰지도 않는 마이크 때문에

첫 제출 이틀 뒤 도착한 반려 사유는 이랬다. "권한 설명 문구에 자리표시자(placeholder) 텍스트가 포함되어 있습니다." 지목된 것은 마이크 권한 문구였다.

황당했던 건, 채록에는 마이크를 쓰는 코드가 한 줄도 없다는 것이다. 음성 녹음 기능이 아예 없다.

범인은 사진 첨부 기능을 위해 넣은 라이브러리였다. 이 라이브러리는 사진뿐 아니라 동영상 촬영도 지원하는데, 동영상에는 소리가 붙으니 마이크 권한이 필요하다. 그래서 내가 마이크 문구를 지정하지 않으면 "이 앱이 마이크에 접근하도록 허용"이라는 기본 문구가 자동으로 들어간다. 애플의 기계는 그 문구를 보고 "성의 없는 자리표시자"라고 판정한 것이다.

내가 쓰지 않는 기능도, 내가 가져다 쓴 부품이 대신 신고하고 있었다.

조치는 간단했다. 안 쓰는 권한은 문구를 잘 쓰는 게 아니라 아예 꺼서 항목 자체를 없앴다. 마이크도, 카메라도(사진첩에서 고르기만 하고 촬영은 안 하니까). 남은 사진 권한 문구에는 용도와 구체적인 예시를 넣어 보강했다.

여기서 하나 배웠다. 이 권한 목록은 앱의 뼈대에 박히는 정보라, 앞에서 이야기한 무선 업데이트로는 못 고친다. 새로 빌드해서 다시 올려야 한다. 사람 심사에 가보지도 못하고 하루를 썼다.

2차 — 예쁘게 만든 게 감점이었다

두 번째 반려는 사람 심사였고, 지적이 두 개였다.

첫째, iPad에서 기록을 열면 오류 화면이 뜬다. 심사자는 iPad Air 5세대에서 테스트했다. 문제는 내가 그 화면을 재현할 수 없었다는 것이다. 코드를 아무리 뒤져도 그 자리에서 오류 메시지를 띄우는 코드가 없었다. 즉 앱이 의도한 안내가 아니라 화면 그리기 자체가 실패한 것이라는 뜻이었다.

AI 팀원과 함께 용의자를 하나씩 지워나갔다. 날짜 표시 문제인가, 데이터가 비어 있어서인가, 화면 폭 계산이 iPad에서 터지는가. 하나씩 근거를 대고 배제했다. 결론은 정직하게 "아직 'iPad라서'라는 증거가 없다"였고, 그래서 재제출 메모에 이렇게 적었다. 다시 반려하시면 그때는 오류 화면 캡처를 주세요.

그러면서도 iPad 표면 전체를 훑어 고칠 건 고쳤다. 화면이 넓어질 때의 레이아웃, 작아지던 탭바, 그리고 혹시 화면 그리기가 실패하더라도 빈 화면 대신 안내가 뜨도록 안전망을 깔았다. 원인을 못 찾았을 때 할 수 있는 최선은, 같은 일이 또 나도 사용자가 덜 다치게 만드는 것이었다.

이 과정에서 하나 뜨끔했던 게 있다. 처음에 AI가 상황을 정리하며 "iPad에서 검증된 적이 없다"고 적었는데, 사실이 아니었다. 나는 iPad에서 테스트한 적이 있었다. 다만 작업 문서에 그 기록을 안 남겼을 뿐이다. 문서에 없다고 안 한 게 아니다 — 이건 그날 규칙으로 적어뒀다.

둘째, 스크린샷이 "실제 앱 화면이 아니다". 이게 진짜 뼈아팠다.

앞 편에서 스크린샷 만드는 게 제일 오래 걸렸다고 썼다. 그 공들인 결과물이 바로 이 이유로 반려됐다. 테라코타 배경에 헤드라인을 얹고 기기 프레임 안에 화면을 넣은, 흔히 보는 그 스타일. 정성껏 디자인한 것이 오히려 "광고물"로 판정된 것이다.

애플의 기준은 명확했다. 스크린샷의 다수가 실제 앱 사용 화면이어야 한다. 그래서 24장을 전부 다시 만들었다(아이폰·iPad × 한국어·영어, 각 6장). 그 과정에서 배운 것들이다.

  • 스플래시·로그인·온보딩 화면은 넣지 않는다 — 애플이 "앱 사용 화면이 아니다"라고 명시한다. 이전 세트의 1번이 정확히 스플래시였다
  • 합성 스타일 자체는 문제가 아니다 — 배경과 헤드라인은 그대로 두고, 기기 프레임 안을 진짜 캡처로 바꾸면 통과한다
  • 배경에 깔리는 웹페이지도 심사 대상이다 — '공유해서 담기' 장면을 찍으려면 뒤에 웹페이지가 필요한데, 자사 소개 페이지(자기 광고), 자사 제품 목록, 애플 공식 페이지(상표·보증 오해)를 차례로 썼다가 전부 물렸다. 최종 답은 위키피디아였다
  • 헤드라인과 화면이 모순되면 안 된다 — "기록은 기기 안에 머뭅니다"라는 문구 아래에 클라우드 동기화가 켜진 설정 화면을 넣어뒀었다. 심사는 스크린샷의 종류만이 아니라 말과 그림이 맞는지까지 본다

마지막 항목이 제일 부끄러웠다. 나는 카피라이터 흉내를 내며 문구를 쓰고, 화면은 아무거나 잘 나온 걸 골랐던 것이다. 기획자가 할 실수는 아니었다.

3차 — 앱은 멀쩡한데 정책이 막았다

세 번째가 가장 근본적이었다. 지적은 한 줄이었다.

계정 기반이 아닌 인앱 구매에 개인정보 등록을 강제하지 마십시오.

우리 앱의 구독 화면에서 "무료로 시작"을 누르면 로그인 시트가 먼저 떴다. 결제하려면 먼저 가입하라는 구조였던 것이다.

여기엔 나름의 논리가 있었다. 유료 기능 대부분이 클라우드 기능이고, 클라우드는 사용자 식별자가 있어야 열린다. 결제 정보도 그 식별자에 붙는다. 계정 없이 결제하면 돈만 나가고 아무것도 안 열리는 구조였으니, 로그인을 앞세운 건 게으름이 아니라 설계 결과였다.

그래서 처음엔 "이건 설명하면 되겠는데?"라고 생각했다. 그런데 반려문을 다시 읽고 마음을 접었다. 애플은 내가 할 반박까지 미리 적어놓고 막아뒀다. 요지는 이랬다 — 구독을 여러 기기에서 쓸 수 있게 하라는 요건이 있는 건 맞지만, 그걸 위해 등록을 강제하는 건 부적절하고 등록은 어디까지나 선택이어야 한다.

읽는 순간 내 잘못이 보였다. 나는 "식별자가 필요하다"를 "계정이 필요하다"로 읽고 있었다. 그 둘은 같지 않았다.

해법은 익명 인증이었다. 개인정보를 하나도 받지 않고 식별자만 발급받는 방식이 이미 표준으로 존재한다. 앱을 켜면 조용히 익명 식별자가 생기고, 결제도 클라우드 기능도 그걸로 전부 동작한다. 나중에 사용자가 로그인하면 그 식별자를 유지한 채 계정이 붙는다 — 구독도 기록도 끊기지 않는다.

  • 결제 전 : 로그인 없음. "무료로 시작"을 누르면 바로 결제창
  • 결제 후 : "계정을 연결하면 다른 기기에서도 이어 쓸 수 있어요"라는 닫아도 되는 제안
  • 끝까지 계정을 요구하는 것 : 기기 간 기록 동기화 하나뿐. 이건 성격상 계정이 있어야 하는 기능이라 정당하다

놀랍게도 서버는 한 줄도 고치지 않았다. 서버는 원래 "유효한 식별자인가"만 확인하고 있었지, 그게 계정인지 익명인지 물어본 적이 없었기 때문이다. 막고 있던 건 서버가 아니라 내 머릿속 전제였다.

반려문에 답장 쓰는 법

세 번째 대응에서는 심사자에게 보내는 회신도 공들여 썼다. AI 팀원과 구조를 잡았는데, 다음에 또 반려당하면 그대로 쓸 생각이라 여기 남긴다.

  • 무엇을 바꿨는지 먼저, 사족 없이
  • 왜 이제 선택인지 — 지적의 핵심에 대한 직접적인 답
  • 반려문이 미리 막아둔 논리에 대한 반박이 아니라 해명 — "구매 복원이 로그인 없이 항상 열려 있으니 다른 기기 요건은 이미 충족됩니다"
  • 이 빌드의 다른 변화 — 반려 대응 빌드가 예상보다 많이 달라져 있으면 심사자가 의심한다. 기능이 추가됐음을 먼저 밝히고 "새 권한 없음, 새 결제 항목 없음, 데이터 수집 변화 없음"을 못 박았다
  • 테스트 순서 4줄 — 지난 심사자는 로그인 시트에서 막혀 그 뒤를 못 봤다. 어디를 눌러야 하는지 알려주면 같은 자리에서 헤매지 않는다

마지막 항목이 특히 그랬다. 심사자는 우리 앱을 처음 여는 사람이다. 그 사람이 헤매면 그건 심사자 잘못이 아니라 내 잘못이다.

거절은 벌이 아니라 명세서였다

셋 다 결국 같은 성격이었다. 내가 몰랐던 기준을 알려주는 문서. 그리고 세 번 다, 문구는 딱딱해도 무엇이 문제인지는 정확하게 적혀 있었다.

AI 팀과 일하면서 이 구간이 특히 좋았다. 반려문 원문을 그대로 붙여넣으면 관련된 코드를 전부 뒤져 원인 후보를 좁혀준다. 감정이 없다는 게 이럴 땐 장점이다. 사람이라면 "이건 억울한데요"부터 나올 상황에서, AI는 조용히 근거를 모아 왔다. 억울해하는 건 내 몫이었고, 항고할지 수정할지 정하는 것도 내 몫이었다.

세 번 다 수정을 택했다. 그리고 8월 11일 밤, 승인 메일이 왔다.

다만 이야기는 여기서 끝나지 않았다. 세 번째 반려를 고치느라 결제의 뿌리를 건드렸는데, 뿌리를 건드리면 잎이 흔들린다. 다음 편은 그 이야기다.