[Google OAuth][운영] Verification Center follow-up 뒤 current review status가 paused일 때 scope justification를 언제 다시 보내고 언제 기다리나

IT 리서치 노트

[Google OAuth][운영] Verification Center follow-up 뒤 current review status가 paused일 때 scope justification를 언제 다시 보내고 언제 기다리나

Google OAuth Verification Center follow-up 뒤 current review status가 paused로 보이면 많은 팀이 같은 scope justification를 다시 보낸다. 하지만 2026년 8월 26일 기준 Google 공식 문서를 다시 보면 paused 상태는 review가 아직 응답을 기다린다는 뜻일 수 있고, declared scopes가 달라졌다는 뜻은 아니다. 이 글은 current review status가 paused로 보일 때 scope justification를 언제 다시 보내고 언제 기다리는 편이 맞는지, 그리고 어떤 필드를 메모에 남겨야 재전송을 줄일 수 있는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 current review status가 paused라고 해서 scope justification를 바로 다시 보내는 편이 항상 맞지는 않다. 먼저 follow-up에 아직 응답하지 않은 paused인지, 이미 응답했고 declared scopes diff도 없는데 reviewer 처리만 대기 중인 paused인지 나눠야 한다.

scope justification resend는 declared scopes와 actual feature scopes가 달라졌거나 새 증거가 생겼을 때가 더 타당하다. 이미 follow-up triage 허브 글에서 brand, video, scope 묶음을 가른 상태라면, 이번 글은 paused status에서 resend와 wait를 고르는 운영판이다.

2. 어디서 실제로 막히는가

가장 흔한 실패는 current review status가 paused로 보이는 순간 같은 justification 문장을 다시 보내는 것이다. reviewer가 실제로 추가 증거를 기다리는 paused와, 이미 답장을 받았지만 아직 검토가 끝나지 않은 paused를 구분하지 않으면 같은 메일만 여러 번 쌓인다.

두 번째 실패는 Add or remove scopes를 다시 보지 않는 것이다. scope justification는 현재 앱이 요청하는 declared scopes와 기능 흐름이 맞아야 의미가 있는데, teams는 기존 메일 문구만 재전송하고 실제 scope declaration은 확인하지 않는 경우가 많다.

세 번째 실패는 paused 상태와 follow-up 유형을 섞는 것이다. 어떤 paused는 demo video 재촬영 때문일 수 있고, 어떤 paused는 scope justification 때문일 수 있다. triage 없이 resend timing만 결정하면 brand evidence를 고쳐야 할 상황에서 scope 설명만 다시 보내게 된다.

• 증상: current review status가 paused인데 같은 justification를 여러 번 다시 보낸다.
• 실패: declared scopes와 actual feature scopes를 비교하지 않는다.
• 막힘: paused 이유가 scope인지 video인지 brand인지 메모에 안 남긴다.
• 누락: response sent 시각과 next status check 시각을 따로 저장하지 않는다.

겉으로 보이는 상태	실제 해석	먼저 볼 곳
paused	Google이 아직 답변을 기다리거나 reviewer 처리 대기 중일 수 있음	follow-up email, response sent 기록, current review status
paused + 새 scope 논의	declared scope와 실제 앱이 어긋났을 수 있음	Add or remove scopes, actual feature scope inventory
paused + evidence already sent	새 증거 없이 wait가 더 맞을 수 있음	response sent at, next status check, new diff 여부

3. 실무에서 적용하는 순서

가장 짧은 점검 순서는 다섯 단계다. 먼저 follow-up email 요구 항목을 다시 읽고 어떤 묶음인지 태깅한다. 다음으로 current review status가 paused인지와 마지막 response sent 시각을 확인한다. 세 번째로 Add or remove scopes에서 declared scopes를 다시 확인한다. 네 번째로 actual feature scopes와 justification 문구를 대조한다. 마지막으로 새 diff가 있으면 resend하고, diff가 없으면 next status check만 남기고 기다린다.

1. follow-up 요구 항목이 scope인지 brand인지 video인지 다시 태깅한다.
2. current review status와 response sent 시각을 함께 본다.
3. Add or remove scopes에서 declared scopes를 다시 확인한다.
4. actual feature scopes와 justification 문구를 비교한다.
5. 새 diff가 있으면 resend하고, 없으면 next status check를 남기고 기다린다.

실행할 때는 먼저 Verification Center에서 current review status를 조회하고, follow-up email을 열어 요청 필드와 요청 증거를 확인한다. 다음으로 Add or remove scopes 버튼을 클릭해 declared scopes를 다시 확인하고, 내부 scope inventory 파일을 열어 actual feature scopes diff를 비교한다. 새 diff가 있으면 justification 문구를 수정해 응답 메일을 보내고 response sent 시각을 저장한다. diff가 없으면 next status check 일자를 입력하고 상태만 다시 조회한다.

실무 메모는 최소한 current_review_status, response_sent_at, scope_diff, next_status_check를 가져가는 편이 좋다. paused 상태가 며칠 이어져도 이 네 줄이 있으면 왜 resend하지 않았는지 또는 왜 resend했는지를 설명하기 쉽다.

paused review 처리 순서

1. follow-up 유형을 다시 태깅한다
2. current review status와 response sent 시각을 본다
3. declared scopes를 다시 확인한다
4. actual feature scopes diff를 확인한다
5. diff가 있을 때만 resend한다

이 순서를 쓰면 paused를 보고도 무조건 재전송하는 습관을 줄일 수 있다. status와 scope diff가 그대로라면 기다리는 편이 더 맞을 수 있고, declared scopes가 실제 앱과 달라졌다면 기다리기보다 scope justification package를 고쳐서 다시 보내는 편이 낫다.

4. 공식 문서와 예시 화면으로 확인하기

첫 공식 화면은 current review status 문구다. Google은 follow-up 뒤 Branding 또는 Verification Center에서 review가 paused인지까지 확인하라고 적고 있다.

Google은 current review status에서 review가 paused while we wait for your response인지 확인하라고 안내한다.

즉 follow-up 답장을 보낸 뒤 status가 paused면 바로 재전송부터 할 일이 아닐 수 있다. 현재 paused 이유가 미회신인지, 이미 회신했지만 아직 reviewer가 처리 전인지 먼저 나눠야 한다.

두 번째 자료는 follow-up email 자체의 위치다. review는 이메일 추가 요청과 current review status를 함께 봐야 한다.

Google은 Trust & Safety 팀이 추가 정보가 필요하면 email follow-up을 보낼 수 있다고 설명한다.

따라서 resend timing은 메일을 다시 보냈는지 아닌지보다 '추가 정보 요청이 무엇이었는지'와 'status가 아직 paused인지'를 함께 묶어 봐야 한다.

세 번째 화면은 scope declaration 갱신 경로다. scope justification를 다시 보낼지 결정하려면 먼저 실제 declared scopes가 지금 앱과 일치하는지 확인해야 한다.

Google은 Add or remove scopes 버튼으로 현재 앱이 요청하는 모든 scope를 다시 선언하라고 안내한다.

scope가 실제로 바뀌지 않았다면 justification resend는 새 증거 없이 반복될 수 있다. 반대로 declared scopes가 달라졌다면 paused 상태를 길게 기다리기보다 scope diff를 먼저 고쳐야 한다.

네 번째 자료는 justification 기준 자체다. Google 정책은 scope 요청 전에 사용자에게 맥락과 justification을 제공하라고 적고 있다.

OAuth 2.0 정책은 scope 요청 전에 사용자 맥락과 justification을 제공하라고 요구한다.

즉 reviewer에게 다시 보내는 justification도 실제 제품 흐름과 연결돼야 한다. 같은 문장만 재전송해도 consent flow와 scope parameter가 안 맞으면 paused 상태가 풀리지 않을 수 있다.

실무에서는 paused status를 세 갈래로 나눠 보는 표가 필요하다. 미회신 paused, 증거 갱신 필요 paused, reviewer 처리 대기 paused는 다음 행동이 서로 다르다.

current review status가 paused일 때 resend와 wait를 나누는 상태표다.

이미 follow-up triage 허브 글이 brand, video, scope 세 갈래를 다뤘다면, 이번 표는 status가 paused로 보이는 순간 resend와 wait를 가르는 후속편이다. current scope diff 글과도 직접 이어진다.

마지막 자료는 resend timing 메모 예시다. 답장을 보냈는지 여부만 적지 말고 declared scopes diff와 next status check 시각을 같이 남기는 편이 좋다.

paused review 상태에서 resend와 wait를 구분하는 verification memo 예시다.

이 메모 구조를 쓰면 괜히 같은 justification를 여러 번 보내는 일을 줄일 수 있다. paused라고 해서 항상 resend가 정답은 아니고, status와 scope diff가 바뀌었는지가 먼저다.

5. 주의사항과 리스크

첫 번째 리스크는 paused 상태만 보고 같은 justification 메일을 반복 발송하는 것이다. 두 번째는 declared scopes가 달라졌는데도 response sent 기록만 보고 계속 기다리는 것이다. 세 번째는 brand, video, scope follow-up을 같은 paused 상태로 묶어 다음 행동을 헷갈리는 것이다.

운영 문서에는 follow-up type, response sent at, declared scopes, actual scopes, current review status, next status check를 같이 남기는 편이 좋다. 이 필드가 있어야 resend와 wait를 같은 규칙으로 반복 적용할 수 있다.

메일 응답을 보냈다면 어떤 메일 스레드에 응답했는지, 어떤 scope 값을 확인했는지, 어떤 파일에 증거 링크를 저장했는지까지 적는 편이 좋다. 그래야 다음 조회 때 같은 응답을 다시 보내는 오류를 줄일 수 있다.

• paused는 곧바로 resend 신호가 아닐 수 있다.
• scope justification는 declared scope diff와 함께 봐야 한다.
• 새 evidence가 없으면 next status check만 남기고 기다리는 편이 맞을 수 있다.

6. 결론

Verification Center follow-up 뒤 current review status가 paused일 때는 상태만 보고 재전송부터 하면 같은 메일을 반복하기 쉽다. current review status, response sent 시각, declared scope diff를 같이 보면 scope justification를 지금 다시 보내야 하는지 아니면 기다리는 편이 맞는지 훨씬 짧게 고를 수 있다.

새 follow-up email이 다시 들어왔을 때 기존 response sent 기록과 새 evidence package를 어떻게 구분할지 더 내려가 보고 싶다면 후속편인 paused review 뒤 새 follow-up email 재분류 글을 이어서 보면 좋다. 이 글이 resend와 wait의 1차 판단을 다뤘다면, 후속편은 새 메일이 왔을 때 어떤 package만 다시 보내야 하는지 정리한다.

• paused와 follow-up 유형을 먼저 분리한다.
• declared scope diff가 있을 때만 resend를 우선한다.
• diff가 없으면 next status check를 남기고 기다린다.

7. 참고 링크

1. https://developers.google.com/identity/protocols/oauth2/production-readiness/brand-verification
2. https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification
3. https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification
4. https://developers.google.com/identity/verification/authentication-verification
5. https://developers.google.com/identity/protocols/oauth2/policies