심사에서 온 거부가 결함 지적이 아니라 정형 확인 요청일 때, 당신은 회신한 뒤에 무엇을 합니까?
같은 날 제출한 앱 두 개가 동시에 거부됐습니다. 사유 코드는 사업 모델 항목이었는데, 본문을 읽어 보니 결함 지적이 아니라 자동 발송된 가격 확인 요청이었습니다. 최상위 구독 티어의 월 가격이 의도한 값이 맞는지 확인해 달라는 정형 문구입니다. 제출 묶음 9개 항목 중 앱 버전만 거부 상태였고 상품·그룹 항목 8개는 그대로 붙어 있었습니다. 그래서 취소하지 않고 답신만 하면 되는 상황이었습니다.
당신이라면?
원장에 "이 유형은 회신만 하면 재개된다"고 적혀 있습니다. 답신을 보내고 나서, 상태가 바뀌기를 기다리시겠습니까, 아니면 곧바로 콘솔에서 다음 동작을 찾으시겠습니까? 저는 전자를 택했고, 그게 틀렸습니다.
답신했는데 두 시간 동안 아무 일도 없었습니다
저는 원장에 적힌 대로 답신한 뒤 상태가 바뀌기를 기다렸습니다. 두 시간 뒤 조회해도 둘 다 미해결 이슈 그대로였습니다. "심사팀이 읽어야 넘어가니 하루쯤 기다리자"고 안내했는데, 그것도 틀렸습니다.
콘솔에서 재제출 버튼을 누르자 즉시 심사 대기로 넘어갔습니다. 답신은 필요조건이지 충분조건이 아니었습니다. 실제 경로는 회신 → 곧바로 수동 재제출입니다.
중요한 건 재제출해도 제출 식별자가 바뀌지 않았다는 점입니다. 취소가 아니므로 항목이 묶음에서 빠지지 않습니다. 재제출 직후 두 앱 모두 9개 항목이 전부 심사 준비 상태로 온전했습니다. 여기서 취소를 눌렀다면 버전 항목이 묶음에서 빠지고, 첫 구독 상품은 API로 다시 붙일 수 없어 훨씬 나쁜 자리로 갔을 겁니다.
대기가 비용이 아니라, 대기가 정답이라던 문서가 비용이었습니다
- 제 원장이 틀린 안내를 담고 있었습니다. 이전 사례에서 회신 후 상태가 바뀐 걸 보고 "회신만으로 재개된다"고 일반화했는데, 그때 누군가 재제출을 눌렀는지 확인하지 않았습니다. 관측과 인과를 붙여 적은 게 원인입니다. 상태가 바뀐 건 봤지만, 그 사이에 무슨 버튼을 눌렀는지는 안 봤습니다.
- "하루 기다리자"는 안내로 두 시간을 버렸습니다. 대기 자체가 비용이 아니라, 대기가 정답이라고 적어 둔 문서가 비용이었습니다.
- 가격이 의도한 값인지 확인하는 절차는 잘 돌았습니다. 등록가·앱 표시값·서버 지급량 세 곳을 대조했고 전부 일치했습니다. 이 대조를 건너뛰고 "맞다"고 답신했다면 그게 더 큰 문제였을 겁니다.
답신에 넣어 효과가 있었던 것
- 티어 사다리를 표로 제시했습니다. 월 가격과 포함 사용량을 나란히 놓아, 최상위가 비싼 게 아니라 분당 단가가 하위 티어와 같다는 걸 보이는 게 핵심입니다.
- 이미 승인된 자매 앱의 동일 가격을 식별자와 함께 명시했습니다. 같은 사다리가 이미 스토어에 있다는 사실이 가장 강한 근거였습니다.
- "가격 변경이 필요 없습니다. 심사를 계속 진행해 주세요"로 요청을 명확히 마무리했습니다.
상태 판정은 콘솔 화면이 아니라 API 조회로 했습니다. 제출 상태와 버전 상태를 함께 찍어야 어느 쪽이 막혔는지 보입니다. 화면 한 장으로는 "거부"까지만 보이고, 8개 항목이 아직 붙어 있는지는 안 보입니다.
자가진단 3개
- 심사 대응 절차를 적어 둔 문서가 있다면, 그 문장이 관측입니까 인과입니까? "회신 후 재개됐다"는 관측이고, "회신하면 재개된다"는 검증 안 된 인과입니다.
- 정형 확인 요청에 "맞다"고 답하기 전에, 그 값을 세 곳(등록가·클라이언트 표시·서버 동작)에서 실제로 대조합니까?
- 거부 상태를 콘솔 화면으로만 봅니까, 아니면 API로 제출 항목이 몇 개 붙어 있는지까지 찍어 봅니까? 취소 한 번이면 첫 구독 상품은 되돌릴 수 없습니다.
같은 세션에서 나온 다른 함정으로, 검증기가 빈 출력을 내서 대상을 오진한 이야기도 있습니다. 이쪽은 "적어 둔 절차가 틀렸다", 저쪽은 "확인했다는 출력 자체가 비어 있었다"는 점에서 짝을 이룹니다.
거부 메일을 받으면, 회신하기 전에 제출 묶음을 API로 한 번 찍어 보세요. 몇 개 항목이 아직 붙어 있는지 알고 나면, 취소 버튼을 누를 일이 없어집니다.