앱인토스 심사 반려 통지를 받았습니다.
사유는 **“미니앱 자체 헤더 및 뒤로가기 버튼을 제거해 주세요”**였습니다.
그런데 제 앱에는 자체 헤더가 없었습니다.
앞 글에서 계산기를 알림 구독 구조로 바꾼 이야기를 적었습니다. 이 글은 그 개편을 실제로 붙이다가 만난 실패 셋과, 반려 사유를 어떻게 읽었는지에 대한 기록입니다.
셋 다 공통점이 있었습니다. 성공처럼 보이는 신호가 실패를 덮고 있었습니다.
원인을 찾아 고친 버전은 통과해서 지금 출시된 상태입니다.
파일이 있다는 것은 그 안에 무엇이 들었는지 보증하지 않습니다.
빌드도 업로드도 검토도 성공했는데 화면만 다섯 시간 전 것이었습니다
첫 번째는 번들이었습니다.
코드를 고치고, 게이트를 통과시키고, 번들을 만들어 올렸습니다.
빌드 성공, 업로드 200, 컴파일 완료.
그런데 실기기에서 열어보니 화면이 그대로였습니다.
파일 시각을 찍어보고 원인을 알았습니다.
소스
09:05 수정됨
빌드 산출물
04:14 — 다섯 시간 전
번들
09:06 — 04:14짜리를 담아 만듦
앱인토스의 번들 명령은 소스를 다시 빌드하지 않습니다.
이미 있는 산출물 폴더를 그대로 포장합니다.
저는 격리된 작업 폴더에서 게이트를 돌려 거기 산출물을 만들었고, 병합한 뒤에는 원래 폴더에서 포장만 했습니다.
두 폴더는 산출물을 공유하지 않습니다.
그래서 낡은 화면이 담긴 번들이 만들어졌고, 모든 단계가 성공을 보고했습니다.
이 유형이 위험한 이유는 실패 신호가 하나도 없다는 점입니다.
지금은 올리기 전에 번들 파일을 열어 새로 넣은 문구가 실제로 들어 있는지 확인합니다.
화면이 사용자에게 거짓말을 하고 있었습니다
두 번째는 제가 쓴 코드였습니다.
알림 동의를 받으면 서버에 식별값을 등록하도록 만들었습니다.
이때 등록 실패를 조용히 삼키게 짰습니다.
동의는 이미 플랫폼에 기록됐으니, 서버 문제로 사용자를 놀라게 하지 말자는 생각이었습니다.
실기기에서 동의를 눌렀고, 화면은 “알려드릴게요"로 바뀌었습니다.
그런데 서버 테이블을 조회하니 0행이었습니다.
등록되지 않은 사람에게 등록됐다고 말하는 화면이었습니다.
더 나쁜 건 원인을 짚을 수 없었다는 점입니다.
실패를 삼켰으니 어디서 끊겼는지 남은 기록이 없었습니다.
이걸 발견한 계기가 제 코드가 아니라 질문이었습니다.
“내가 동의했는지 확인하고 철회하는 건 없어도 되냐"는 물음이었습니다.
상태를 보여줄 화면이 없다는 지적이었는데, 그 화면이 없어서 결함도 안 보였던 것입니다.
그래서 상태를 셋으로 나눠 정직하게 표시하도록 고쳤습니다.
켜짐, 실패, 아직 안 켬입니다.
서버 등록이 확인된 뒤에만 켜짐으로 표시합니다.
고치고 다시 눌렀더니 그 자리에서 등록이 확인됐습니다.
앱인토스 심사 반려 사유는 증상이지 원인이 아니었습니다
세 번째가 반려입니다.
검토 요청 11분 만에 반려가 왔습니다.
사유는 자체 헤더와 뒤로가기를 지우라는 것이었습니다.
그런데 세 가지가 그 사유와 맞지 않았습니다.
첫째, 화면 구조를 프로그램으로 훑어보니 본문 최상단은 카드 제목 한 줄이었고 헤더 요소가 없었습니다.
둘째, 같은 구조로 이미 네 번 승인을 받았습니다.
셋째, 승인본과 반려본의 코드 차이는 버튼 3개와 문단 2개가 전부였고 헤더 관련 변경은 0건이었습니다.
여기서 코드를 추측으로 고치면 네 번 통과한 화면을 망가뜨릴 위험만 있었습니다.
그래서 실기기 화면을 다시 봤습니다.
진짜 중복은 헤더가 아니라 버튼 두 개였습니다
스크린샷 상단에 이렇게 있었습니다.
왼쪽에 뒤로가기, 가운데에 아이콘과 앱 이름, 오른쪽에 더보기와 닫기입니다.
전부 플랫폼이 그리는 바 하나입니다.
두 겹이 아니었습니다.
대신 같은 일을 하는 버튼이 둘이었습니다.
이 앱은 화면이 하나뿐이라 첫 화면의 뒤로가기는 곧 종료입니다.
오른쪽 닫기도 종료입니다.
반려 문구의 마지막 문장이 “중복된 버튼을 제거해 주세요"였는데, 조정할 수 있는 중복은 이것뿐이었습니다.
설정에서 뒤로가기를 끄고 종료 경로를 닫기 하나로 정리해 재제출했습니다.
재제출은 통과했고, 그 버전이 지금 라이브입니다.
다만 여기부터는 제 해석입니다.
원인을 검수자에게 확인받은 것이 아니라 화면과 코드를 대조해 좁힌 결론입니다.
통과했다는 사실이 제 해석이 맞았다는 증명은 아니고, 바꾼 것이 그것 하나였다는 정황일 뿐입니다.
정리 — 다섯 줄
- 번들 명령은 소스를 다시 빌드하지 않아, 다섯 시간 전 산출물이 담긴 채로 모든 단계가 성공을 보고했습니다.
- 실패를 삼킨 코드가 등록되지 않은 사용자에게 “알려드릴게요"라고 말했고, 서버 테이블은 0행이었습니다.
- 상태를 켜짐·실패·미설정 셋으로 나눠 표시하자 결함이 그 자리에서 드러났습니다.
- 반려 사유는 자체 헤더였지만 헤더는 없었고, 같은 구조로 네 번 승인받았으며 헤더 변경은 0건이었습니다.
- 진짜 중복은 화면 하나짜리 앱에서 뒤로가기와 닫기가 같은 일을 하는 것이었고, 설정 한 줄을 고쳐 재제출한 버전이 통과·출시됐습니다.
저는 이 셋을 겪고 “성공 신호가 여러 개 겹쳐도 결과물을 직접 열어보기 전에는 모른다"를 규칙으로 적어 두었습니다.
다음 글에서는 출시 뒤 알림 구독자가 실제로 몇 명 쌓이는지, 그리고 리텐션이 0%에서 움직였는지를 적겠습니다.
이어서 볼 글
https://blog.naver.com/devarchi33/224403717747
이 글은 특정 플랫폼의 심사 결과를 보장하지 않습니다. 반려 사유 해석은 화면·코드 대조로 좁힌 제 판단이며 검수 담당자의 확인을 받은 것이 아닙니다. 수치는 2026년 9월 8일 콘솔·검수 이력 실측치입니다.
참고자료 · 앱인토스 미니앱 운영 정책