-
[Google OAuth][운영] verification 제출 뒤 auto-cancelled가 뜰 때 Testing·Internal 전환과 reviewer 자격 증명을 어디서 먼저 다시 보나기타개발지식/풀스택개발 2026. 8. 5. 20:20
IT 리서치 노트
[Google OAuth][운영] verification 제출 뒤 auto-cancelled가 뜰 때 Testing·Internal 전환과 reviewer 자격 증명을 어디서 먼저 다시 보나
Google OAuth verification을 제출한 뒤 follow-up email이나 pending만 예상했는데 auto-cancelled 알림이 뜨면 원인 분기를 잘못 잡기 쉽다. 2026년 8월 5일 기준 Google 공식 도움말을 다시 보면, Publishing Status가 Testing으로 바뀌거나 User Type이 Internal로 바뀌는 것처럼 verification 대상 자체가 달라지는 경우가 있고, reviewer가 앱에 실제로 접근할 수 있도록 authorized login credentials를 제공해야 하는 별도 요구도 있다. 이 글은 auto-cancelled가 떴을 때 Testing·Internal 전환과 reviewer 자격 증명을 어디서 먼저 다시 봐야 하는지 정리한 것이다.
1. 개요
결론부터 말하면 auto-cancelled는 보완 자료 부족과 같은 종류의 상태가 아니다. 먼저 앱이 여전히 verification 대상 상태인지 확인하고, 그다음 reviewer가 실제로 앱에 로그인해 흐름을 재현할 수 있는지 확인해야 한다.
가장 먼저 볼 항목은 Publishing Status와 User Type이다. 앱이 Testing이나 Internal로 바뀌면 brand package나 demo video를 아무리 다듬어도 같은 경로에서 해결되지 않을 수 있다. 그 다음 단계가 reviewer credentials다.
2. 어디서 실제로 막히는가
실무에서 auto-cancelled가 어려운 이유는 pending과 겉으로 비슷해 보이기 때문이다. 팀은 보통 demo video를 다시 찍거나 scope justification을 보완하려 하지만, 실제 원인이 상태 전환이면 그런 작업은 핵심을 건드리지 못한다.
Google의 auto-cancellation 도움말은 Publishing Status가 In Production에서 Testing으로 바뀌거나, User Type이 External에서 Internal로 바뀌거나, verification 요구를 만들었던 scope가 제거된 경우를 분명히 예로 든다. 동시에 In-app Testing 문서는 reviewer가 앱에 실제로 로그인할 수 있도록 authorized login credentials를 요구한다. 이 두 문서를 같이 보면 auto-cancelled는 '서류 부족'보다 '심사 전제 자체가 변했는지'를 먼저 보는 상태다.
또 branding 쪽 Ready to publish 또는 Need to re-verify와 auto-cancelled를 같은 문제처럼 보는 실수도 많다. branding publish 누락은 live consent screen 반영 문제이고, auto-cancelled는 verification eligibility 또는 reviewer access 문제에 더 가깝다. 메뉴도 다르고 먼저 고칠 항목도 다르다.
- 증상: verification 제출 뒤 auto-cancelled 알림이 온다.
- 실패: 상태 전환을 보지 않고 영상과 justification부터 다시 낸다.
- 막힘: reviewer가 로그인 가능한지 검증하지 않는다.
- 누락: auto-cancelled와 Need to re-verify를 같은 메모에 섞는다.
3. 실무에서 적용하는 순서
가장 짧은 대응 순서는 다섯 단계다. 먼저 Publishing Status가 여전히 In Production인지 본다. 두 번째로 User Type이 External인지 확인한다. 세 번째로 현재 scope 목록이 verification 제출 당시와 같은지 본다. 네 번째로 reviewer access 방식이 allow-list인지 별도 테스트 계정인지 확인한다. 마지막으로 branding 재검증 문제인지 아닌지를 따로 분기한다.
- Audience와 Publishing Status를 먼저 확인한다.
- User Type이 External인지 다시 본다.
- 현재 scope 목록과 제출 당시 justification을 대조한다.
- reviewer email allow-list 또는 테스트 계정 상태를 확인한다.
- branding publish 문제는 별도 트랙으로 분리한다.
이 순서가 좋은 이유는 작업 낭비를 줄여 주기 때문이다. Testing 상태였다면 In Production으로 돌리는 것이 먼저고, Internal 상태였다면 app audience 설계부터 다시 정해야 한다. reviewer가 로그인할 수 없다면 영상과 링크를 새로 보내도 심사가 멈춘다.
checklist: 1. publishing_status=In Production 2. user_type=External 3. requested_scopes=current expected scopes 4. reviewer_access=allow-list or test account verified 5. branding_issue_tracked_separately=true4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 Google의 Brand Approvals & Auto-Cancellations 도움말이다. 여기서 Google은 Publishing Status가 In Production에서 Testing으로 바뀌면 verification 대상에서 벗어나 auto-cancellation이 생길 수 있다고 설명한다.
즉 auto-cancelled가 떴을 때 먼저 scope justification 문서를 더 쓰기 전에, 상태가 Testing으로 떨어졌는지부터 봐야 한다. 운영팀이 staging 편의를 위해 바꿔 둔 설정이 원인일 수 있다.
두 번째 자료는 Testing 전환과 Internal 전환을 한 번에 비교하는 운영 카드다. 같은 auto-cancelled라도 먼저 볼 메뉴와 복구 방식이 달라진다는 점을 짧게 모았다.
이 경우는 reviewer video나 brand package를 고쳐도 바로 안 풀릴 수 있다. 앱 자체가 더 이상 external verification 경로에 있지 않기 때문이다.
세 번째 자료는 scope 변경과 reviewer access를 함께 보는 triage 카드다. auto-cancel 원인이 eligibility 쪽인지 access 쪽인지 바로 분리하기 위한 보조 메모다.
즉 auto-cancelled를 단순한 심사 지연으로 보면 안 된다. 요구 조건 자체가 사라졌는지, 또는 reviewer가 앱에 못 들어가는지를 먼저 나눠야 한다.
네 번째 공식 화면은 In-app Testing 도움말이다. Google은 reviewer가 앱에 들어가 기능을 시험할 수 있도록 authorized login credentials가 필요하다고 못 박고 있다.
따라서 auto-cancelled 직후 다시 제출할 때는 상태 복구만으로 끝나지 않는다. reviewer가 지금도 staging 또는 test deployment에 들어갈 수 있는지까지 함께 점검해야 한다.
다섯 번째 자료는 reviewer 계정 허용 방식이다. Google은 verification team이 보낸 reviewer email을 allow-list 하거나, 별도 테스트 계정 자격 증명을 제공하라고 안내한다.
즉 단순히 '로그인 정보는 보냈다'로 끝낼 수 없다. 이메일 allow-list 방식인지, 별도 계정 방식인지, 현재도 유효한지까지 기록해야 한다.
마지막 공식 화면은 branding publish 구간이다. Ready to publish와 Need to re-verify는 auto-cancelled와 다른 문제라는 점을 구분할 필요가 있다.
이미 reviewer video 뒤 published branding 재검증 글이 live consent screen 쪽을 다뤘다면, 이번 글은 그보다 앞선 상태 전환과 reviewer access 문제를 따로 떼어 다룬다.
보조 자료는 auto-cancel triage 표다. Testing 전환, Internal 전환, reverted scope, reviewer credential 누락, branding re-verify는 서로 먼저 볼 메뉴가 다르다.
이 표를 팀 메모로 써 두면 verification center 상태명이 비슷해 보여도 대응 순서를 짧게 맞출 수 있다. pending과 published external unverified 분기 글, stale video와 brand mismatch 글과도 자연스럽게 이어진다.
5. 주의사항과 리스크
첫 번째 리스크는 auto-cancelled를 pending 보완 메일처럼 처리하는 것이다. 두 번째는 reviewer credentials가 이미 전달됐다고 믿고 현재 유효성을 재검증하지 않는 것이다. 세 번째는 branding re-verify와 eligibility change를 한 문서에 섞어 회고가 불가능해지는 것이다.
운영 전에 확인할 때는 최소한 status, user type, scope diff, reviewer access 방식, branding 상태를 각기 다른 필드로 남기는 편이 좋다. 그래야 같은 Verification Center라도 무엇이 멈췄는지 곧바로 갈라진다.
6. 결론
Google OAuth verification 뒤 auto-cancelled가 떴다면 먼저 심사 전제가 유지됐는지부터 확인해야 한다. Testing·Internal 전환과 scope 변경을 확인하고, 그 다음 reviewer 자격 증명과 접근성을 점검하면 같은 보완 작업을 반복하는 일을 크게 줄일 수 있다.
반대로 상태값은 정상인데 승인된 앱 변경 자체가 다시 검토를 부를 때는 이름·로고·redirect URI 변경 후 re-verification 재제출 글을 이어 보면 좋다. 이 글이 auto-cancelled triage라면, 새 글은 brand verification 재제출 묶음을 어떤 순서로 다시 맞출지에 초점을 둔다.
- auto-cancelled는 pending 보완과 같은 상태가 아니다.
- Testing·Internal·scope diff를 먼저 본다.
- reviewer access와 branding 문제를 따로 기록한다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
