-
[Google OAuth][운영] Verification Center가 Pending에서 오래 멈출 때 brand evidence와 sensitive-scope justification을 어디부터 다시 제출하나기타개발지식/풀스택개발 2026. 7. 23. 20:14
IT 리서치 노트
[Google OAuth][운영] Verification Center가 Pending에서 오래 멈출 때 brand evidence와 sensitive-scope justification을 어디부터 다시 제출하나
Google OAuth Verification Center가 Pending 상태로 오래 멈춰 보일 때 운영팀은 무엇을 다시 내야 하는지부터 헷갈리기 쉽다. 2026년 7월 23일 기준 Google 공식 문서를 다시 보면 Branding review 상태, Publish branding 7일 유효기간, sensitive-scope justification, demo video, follow-up email 요청은 서로 다른 체크포인트다. 이 글은 Pending이 길어질 때 brand evidence와 sensitive-scope justification을 어디부터 다시 제출해야 하는지 실무 순서로 정리한다.
1. 개요
결론부터 말하면 Verification Center Pending이 오래 보일 때는 먼저 review가 진행 중인지, 추가 자료 대기로 pause된 것인지부터 확인한다. 그다음 자료를 두 묶음으로 나눈다. 하나는 live home page, privacy policy, support email, branding publish 상태 같은 brand evidence고, 다른 하나는 scope별 justification, demo video, 기능 문서 링크 같은 data access 증빙이다.
이 둘을 섞어서 한 번에 다시 올리면 어디서 막혔는지 다시 섞인다. 먼저 Branding 상태와 Verification Center 상태를 따로 보고, 필요한 묶음만 보강하는 편이 빠르다.
2. 어디서 실제로 막히는가
Pending이 길어질 때 가장 흔한 실패는 '콘솔에 Pending이라고만 보이니 그냥 기다리자'는 판단이다. Google 문서는 review가 추가 정보 대기로 pause될 수 있고, status는 Branding 페이지와 Verification Center에서 따로 확인할 수 있다고 적는다.
두 번째 실패는 brand evidence와 data access justification을 한 폴더에 섞어 놓는 것이다. 홈 페이지, privacy policy, terms, support email은 brand 측 증빙에 가깝고, scope별 이유, demo video, 기능 문서 링크는 sensitive-scope review 측 증빙에 가깝다. 이 둘을 구분하지 않으면 보완 요청 메일을 받아도 어디를 고쳐야 하는지 다시 찾게 된다.
- 증상: Verification Center가 며칠째 Pending으로만 보인다.
- 실패: 진행 중 상태와 추가 자료 대기 상태를 구분하지 않는다.
- 막힘: brand evidence와 scope justification을 한 묶음으로 섞어 둔다.
- 누락: support email, developer contact email 회신 여부를 점검하지 않는다.
멈춘 위치 대표 원인 보강 자료 Branding 홈페이지, 정책 페이지, support email 불일치 live URLs와 publish branding 상태 Sensitive scope review scope 이유 불충분, demo video 부족 scope justification, video, docs links 3. 실무에서 적용하는 순서
가장 짧은 재제출 순서는 여섯 단계다. 첫째, Branding 페이지와 Verification Center에서 어떤 단계가 멈췄는지 나눠 적는다. 둘째, support email과 developer contact email에 보완 요청이 왔는지 확인하고 요청 문구를 저장한다. 셋째, brand evidence 묶음의 live URLs와 publish branding 상태를 다시 확인하고 캡처를 갱신한다. 넷째, scope justification 문서와 demo video 링크를 새 scope 목록과 맞춘다. 다섯째, 제품 문서 링크를 최대 3개까지 최신 상태로 정리하고 data flow 설명을 다시 쓴다. 여섯째, 어떤 묶음을 다시 냈는지 제출 시각까지 기록한다.
- Branding 상태와 Verification Center 상태를 따로 적는다.
- support email과 developer contact email을 확인한다.
- brand evidence의 live URLs와 publish branding 상태를 다시 본다.
- sensitive-scope justification과 demo video를 새 scope 목록과 맞춘다.
- 기능 문서 링크와 data flow 설명을 최신화한다.
- 재제출 시각과 변경 내용을 로그로 남긴다.
branding_status=Ready to publish branding_published=false verification_center=Pending support_email_checked=true brand_evidence_home=https://example.com privacy_policy=https://example.com/privacy sensitive_scope=https://www.googleapis.com/auth/calendar.events justification_doc=https://example.com/google-scope-justification demo_video=https://youtu.be/example-unlisted resubmitted_at=2026-07-23T20:45:00+09:00이 로그가 있으면 '오래 Pending'이라는 감상 대신 어느 단계가 멈췄는지 바로 설명할 수 있다. branding이 아직 publish되지 않은 문제와 scope justification 부족 문제를 서로 다른 작업으로 분리하고, 어떤 자료를 다시 확인하고 제출하고 저장했는지 순서대로 비교할 수 있기 때문이다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 Google brand verification 문서의 review 상태 확인 구간이다. Google은 Branding 페이지와 Verification Center에서 현재 review가 어떤 상태인지, 추가 정보 대기 때문에 멈춘 것인지 확인하라고 직접 안내한다.
Pending이 오래 보인다는 말만으로는 부족하다. 실제로는 review가 진행 중인지, 추가 자료 대기 때문에 pause된 것인지 먼저 가려야 한다.
두 번째 자료는 Publish branding 전 7일 유효기간 규칙이다. branding 검증이 통과했더라도 7일 안에 publish하지 않으면 다시 verify가 필요하다는 점이 중요하다.
즉 Pending이 길 때는 scope review뿐 아니라 branding 결과를 publish하지 못해 다시 되감긴 상태인지도 같이 봐야 한다. 오래 멈춘 것처럼 보여도 실제 원인은 brand 재검증일 수 있다.
세 번째 화면은 Verification Center에서 추가 자료를 요구할 수 있다는 구간이다. demo video, 문서 링크, 추가 설명이 부족하면 review가 멈춘 채 대기 상태처럼 보일 수 있다.
따라서 Pending이 오래 갈 때는 단순 대기보다 자료 보강 여부를 먼저 점검하는 편이 빠르다. review 팀이 이미 필요한 자료를 요청했는데 support email을 놓친 경우도 흔하다.
네 번째 자료는 follow-up email triage 표다. Pending이 길 때는 콘솔만 보지 말고 어떤 메일함을 확인하고 어떤 링크를 다시 열어야 하는지 절차를 남겨 두는 편이 낫다.
이 표를 두면 review가 진행 중인지, 보완 요청에 답하지 않아 멈춘 것인지 훨씬 빨리 가른다. support email과 developer contact email을 둘 다 확인하고, 어떤 링크를 수정했는지 기록하는 습관이 필요하다.
다섯 번째 자료는 상태 분리표다. Branding status와 Verification Center 상태를 같은 줄에 놓으면 어느 쪽 자료를 다시 올려야 하는지 더 빨리 보인다.
따라서 brand evidence와 scope justification은 한 번에 다시 올리는 것이 아니라, 어느 화면에서 멈췄는지 확인한 뒤 필요한 묶음만 보강하는 편이 낫다.
마지막 표는 재제출 순서다. Pending이 오래 보일 때는 brand evidence 묶음과 sensitive-scope justification 묶음을 따로 재정렬해야 한다.
이미 Brand verification과 Sensitive scope verification을 나눈 글이 개념을 설명했다면, 이번 표는 실제 재제출 runbook이다.
5. 주의사항과 리스크
첫 번째 리스크는 branding verification이 통과했는데도 7일 안에 publish하지 않아 다시 되감기는 것이다. 두 번째는 scope 목록이 바뀌었는데 옛 justification 문서와 demo video를 그대로 두는 것이다. 세 번째는 follow-up email을 놓쳐 review가 pause된 상태를 단순 대기로 오해하는 것이다.
- branding과 data access review는 같은 Pending이라도 필요한 자료가 다르다.
- support email과 developer contact email은 실제 운영 채널이어야 한다.
- 재제출 후에는 어떤 묶음을 갱신했는지 시각까지 남겨야 다음 회신과 대조하기 쉽다.
6. 결론
Verification Center가 Pending에서 오래 멈출 때는 먼저 review 상태를 brand와 data access 두 칸으로 쪼갠다. 그다음 brand evidence와 sensitive-scope justification을 따로 다시 제출하면 보완 요청을 훨씬 짧게 처리할 수 있다.
같은 가지의 선행 글로는 Draft Branding과 Publish branding 분기 글, Brand verification과 Sensitive scope verification 분기 글, Pending인데 앱은 In production인 상태를 넓게 본 글을 같이 보면 좋다.
7. 참고 링크
- https://developers.google.com/identity/protocols/oauth2/production-readiness/brand-verification
- https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification
- https://support.google.com/cloud/answer/15549049?hl=en
- https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
