체크박스 한 칸이 개인 계정을 막았던 앞편의 결론대로, 개발자 계정을 개인에서 조직으로 전환했습니다.
서류 검증까지 끝나 Account type = Organization이 됐고, 스토어의 개발자 정보가 상호명으로 바뀐 것도 눈으로 확인했습니다. 그래서 거부됐던 앱들을 재제출했습니다.
몇 분 만에 같은 사유로 다시 거부됐습니다. 다음 날 다른 앱으로 한 번 더 시도했고, 역시 거부됐습니다.
당신의 시스템에서, "바뀐 걸 확인할 수 있는 화면"과 "판정을 실제로 내리는 시스템"이 같은 것을 보고 있다고 확신하십니까?
저는 "전파 완료 신호"를 찾아냈다고 믿었고, 그 믿음이 거부 세 건을 만들었습니다
전환 직후에 바로 재제출하지 않는 게 맞다고 판단했습니다. 대신 판정 신호를 스스로 정했습니다 — 스토어 개발자 정보가 상호로 바뀌면, 그때 한 앱만 올려 결과를 본다.
합리적으로 들렸습니다. 그리고 실제로 그 신호가 켜졌습니다. 그래서 올렸고, 거부됐습니다.
지원 티켓을 넣고 받은 회신이 빠진 조각을 알려줬습니다. 셋이 확정됐습니다.
- in-place 전환으로 충분하다. 앱을 별도 계정으로 이전할 필요가 없다.
- 검증 상태가 enforcement 시스템에 동기화되는 데 최대 72시간이 걸린다.
- 그 창이 닫힌 뒤 versionCode를 올려서 재제출하라.
즉 스토어 표시와 enforcement는 따로 놉니다. 앞쪽은 계정 정보를 읽어 그 자리에서 렌더합니다. 뒤쪽은 자기 시스템에 동기화된 상태를 봅니다. 제가 신호로 삼은 것은 앞쪽이었습니다.
반전은 여기입니다
관측할 수 있는 신호가 하나뿐일 때, 그 신호가 내가 알고 싶은 것을 말한다는 보장은 없습니다.
저는 "관측 가능한 것"과 "판정에 쓰이는 것"을 같은 것으로 취급했습니다. 화면이 바뀌었으니 시스템도 바뀌었겠지 — 그 추론에는 근거가 없었습니다. 두 값은 서로 다른 경로로 갱신되고, 한쪽이 켜졌다는 게 다른 쪽도 켜졌다는 뜻이 아닙니다.
올바른 판정 기준은 상태가 아니라 날짜였습니다 — 전환 완료일 + 72시간. 관측 불가능하지만 확실한 기준이, 관측 가능하지만 틀린 기준보다 낫습니다.
당신이라면 어떻게 하시겠습니까
재제출은 버튼 몇 번입니다. 거부가 미제출 변경을 그대로 보존하니까요. "한 앱만 조심스럽게 올려 본다"는 계획을 세워 놓고, 첫 거부 뒤에 두 번째·세 번째를 참으시겠습니까? 아니면 "이번엔 다를지도" 하고 한 번 더 누르시겠습니까?
싸게 다시 시도할 수 있는 행동일수록, 근거 없이 반복하게 됩니다. 저는 세 번 눌렀습니다.
코드·명령·수치
- 재제출 타임라인: 전환 완료 당일 2건 거부 → 다음 날 1건 거부 → 티켓 회신 수신 → 전환 완료 + 3일에 재개.
- 거부는 사람 심사가 아니라 몇 분 만의 자동 판정이었습니다. 그래서 "빨리 다시 해볼 수 있다"는 착각이 강화됩니다.
- versionCode를 올려서 재제출하라는 지시는 중요합니다. 같은 versionCode를 다시 올리면 403
already been used로 막힙니다. - 확인 경로: 앱 → Publishing overview, 그리고 Submission activity. 거부 건은 Submission activity에 시각과 함께 남습니다.
- 72시간은 최대치입니다. 더 일찍 열릴 수도 있지만 확인할 방법이 없으므로, 기다리는 편이 쌉니다. 실제로 언제 열렸는지는 저도 모릅니다 — 창이 닫히는 날까지 아무것도 올리지 않았기 때문입니다.
자가진단 3개
- 어떤 상태가 "반영됐다"고 판단할 때, 그 근거가 판정에 실제로 쓰이는 값입니까, 아니면 그 옆에서 같이 갱신되는 표시입니까?
- 관측 가능한 신호가 하나뿐이라면, 그 신호가 없을 때는 무엇을 기준으로 삼겠습니까? "날짜 + 고정 대기시간"처럼 관측 불가능하지만 확실한 기준이 있습니까?
- 재시도 비용이 거의 0인 행동이 있습니까? 있다면, 그 행동에는 근거 없이 반복하지 않을 명시적 게이트가 붙어 있습니까?
솔직한 부분
재제출 3회, 전부 자동 거부. 얻은 것은 정책 이력뿐입니다. "한 앱만 올려 본다"는 신중함은 두 번째·세 번째에서 지키지 못했습니다. 전환 직후 재제출을 피해야 한다는 것까지는 맞게 판단해 놓고, 판정 신호를 스스로 발명해서 그 판단을 무력화했습니다. 근거 없는 신호는 대기하지 않을 핑계가 됩니다.
티켓 회신은 1차 AI 답변이 원인을 명시했고 그것이 관측과 합치했지만, 그대로 믿지 않고 사람 답변으로 한 번 더 확인했습니다. 그럼에도 이건 지원 채널의 설명이지 문서화된 사양이 아닙니다.
이 계열의 앞선 사례가 completed 100%는 게시가 아니다입니다 — 상태 표시가 실제를 말하지 않는다는 같은 이야기의 다른 판입니다.
지금 딱 하나만 해보세요. 최근에 "반영됐다"고 판단하고 다음 행동으로 넘어간 순간을 하나 떠올려, 그 판단의 근거가 판정에 쓰이는 값이었는지 표시였는지 확인해 보시기 바랍니다.