[Google OAuth][운영] paused review 상태에서 새 follow-up email이 왔을 때 기존 response sent 기록과 새 evidence package를 어떤 표로 다시 자르나

IT 리서치 노트

[Google OAuth][운영] paused review 상태에서 새 follow-up email이 왔을 때 기존 response sent 기록과 새 evidence package를 어떤 표로 다시 자르나

Google OAuth 심사에서 current review status가 paused인데 새 follow-up email이 오면, 많은 팀이 이전 답장 전체를 다시 복사해 보낸다. 하지만 2026년 8월 26일 기준 Google 공식 문서를 다시 보면 paused review 확인, follow-up email 처리, Add or remove scopes 재확인은 서로 다른 판단 축이다. 이 글은 paused review 상태에서 새 follow-up email이 왔을 때 기존 response sent 기록과 새 evidence package를 어떤 표로 다시 나눠 적어야 중복 회신을 줄일 수 있는지 정리한다.

목차

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

1. 개요

결론부터 말하면 paused review 뒤 새 follow-up email이 왔을 때는 기존 response sent 기록과 새 evidence package diff를 한 표로 다시 나눠 적는 편이 좋다. status가 paused라는 사실만으로는 brand, video, scope 중 무엇이 실제로 바뀌었는지 설명되지 않기 때문이다.

이미 current review status paused일 때 scope justification 재전송 타이밍 글이 resend와 wait의 1차 판단을 다뤘다면, 이번 글은 새 follow-up이 다시 들어온 뒤 evidence package를 재분류하는 단계다. 기존 response sent 시각이 있고 scope diff가 없다면, 전체 재전송보다 부분 갱신이 더 맞을 수 있다.

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

가장 흔한 실패는 새 메일이 오자마자 이전 response 전체를 다시 보내는 것이다. 이 경우 reviewer가 실제로 요구한 새 evidence가 video link 하나인지, brand screenshot 갱신인지, scope justification 변경인지가 메모에서 사라진다.

두 번째 실패는 current review status와 response sent 기록을 분리해 두지 않는 것이다. paused 상태는 계속 유지될 수 있으므로, 새 메일이 와도 직전 response가 이미 며칠 전에 갔는지, 방금 전에 갔는지에 따라 대응이 달라져야 한다.

세 번째 실패는 Add or remove scopes를 다시 확인하지 않고 scope package를 재전송하는 것이다. 새 follow-up이 왔더라도 declared scopes diff가 없으면, scope justification 대신 demo video나 brand evidence만 업데이트하면 되는 상황이 적지 않다.

• 증상: 새 follow-up이 올 때마다 같은 답장 전체를 다시 보낸다.
• 실패: response sent 시각과 current review status를 따로 저장하지 않는다.
• 막힘: scope diff가 없는 상황에서도 scope package를 다시 묶는다.
• 누락: brand, video, scope 중 어떤 evidence가 새로 바뀌었는지 메모에 없다.

새 메일에서 보이는 현상	먼저 같이 볼 기록	재분류 이유
paused인데 추가 영상 요청이 왔다	last response sent, video diff	scope package 전체를 다시 보낼 필요가 없을 수 있다
paused인데 scope 설명을 다시 요청했다	declared scopes, previous justification	실제 diff가 있는지부터 확인해야 한다
paused인데 같은 요청이 반복된다	status checked at, response sent at	부분 resend와 wait를 다시 가를 수 있다

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

가장 실용적인 처리 순서는 여섯 단계다. 먼저 current review status를 다시 확인한다. 다음으로 마지막 response sent 시각과 그때 보낸 package 이름을 꺼낸다. 세 번째로 새 follow-up 메일이 brand, video, scope 중 어떤 evidence를 다시 요청하는지 태깅한다. 네 번째로 Add or remove scopes와 실제 앱 기능을 비교해 scope diff를 다시 확인한다. 다섯 번째로 바뀐 evidence package만 다시 묶는다. 마지막으로 새 response sent 시각과 next status check를 메모에 남긴다.

1. current review status를 다시 확인한다.
2. last response sent 기록과 기존 package 이름을 찾는다.
3. 새 follow-up 요청을 brand, video, scope로 태깅한다.
4. declared scopes diff를 다시 확인한다.
5. 바뀐 evidence package만 부분 갱신한다.
6. 새 response sent와 next status check를 저장한다.

실행할 때는 먼저 Verification Center 또는 Branding 페이지에서 current review status를 확인하고, 직전 response sent 메모를 연다. 그다음 follow-up email 본문에서 reviewer가 실제로 요구한 새 자료를 태깅한다. 이어서 Add or remove scopes와 actual feature scope inventory를 비교해 scope diff 유무를 확인하고, diff가 없다면 video나 brand package만 갱신해 보낸다.

여기서는 current review status 필드, response sent 시각, follow-up email 요청 항목, Add or remove scopes 버튼, scope 결과, video 링크 결과를 한 표에 같이 넣어 두는 편이 좋다. reviewer가 요구한 항목을 확인한 뒤 필요한 package만 업데이트하고, 다음 status check 날짜를 입력하면 같은 메일을 전체 resend하는 실수를 줄일 수 있다.

paused review handling example

1. current review status를 확인한다
2. last response sent 시각과 package 이름을 조회한다
3. follow-up email 요청 항목을 brand, video, scope로 구분한다
4. Add or remove scopes 결과를 확인한다
5. 필요한 evidence package만 업데이트하고 next status check를 입력한다

실무 메모는 최소한 last_response_sent_at, new_followup_received_at, new_followup_package, scope_diff, next_action를 포함하는 편이 좋다. 이 필드들이 있어야 새 follow-up이 왔을 때 전체 resend와 부분 resend를 구분할 수 있다.

주의

paused review라는 상태만 보고 전체 evidence package를 다시 보내면 reviewer가 실제로 요구한 변경점이 서로 섞일 수 있다. 새 메일이 왔을 때는 먼저 기존 response sent 기록과 새 diff 종류를 한 표로 묶어야 한다.

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

첫 공식 문구는 Branding 또는 Verification Center에서 current review status를 계속 확인하라고 말한다. paused review 상태에서 새 메일이 와도 먼저 status와 기존 response sent 기록을 함께 봐야 한다.

Google은 current review status에서 review가 paused인지 확인할 수 있다고 안내한다.

즉 follow-up email 하나만 보고 곧바로 새 답장을 보내기보다, 현재 status가 여전히 paused인지와 직전 response sent가 언제였는지를 같은 표에 올려 두는 편이 맞다.

두 번째 문구는 Trust & Safety 팀이 추가 정보를 메일로 요청할 수 있음을 보여 준다. 새 follow-up이 왔다면 메일 본문만 따로 읽지 말고, 기존 response sent 기록과 묶어서 봐야 같은 자료를 반복 전송하지 않는다.

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

이 문구가 말하는 핵심은 '새 요청이 왔다'이지 '무조건 전체 패키지를 다시 보내라'는 뜻이 아니다. 기존 회신과 달라진 evidence package가 무엇인지부터 다시 구분해야 한다.

세 번째 화면은 Add or remove scopes 경로다. 새 follow-up이 scope 관련이면 현재 declared scopes가 기존 response 이후 바뀌었는지 먼저 봐야 한다.

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

만약 declared scopes diff가 없다면, 새 메일이 demo video나 brand evidence 변경만 요구하는지 확인해야 한다. 반대로 scope가 달라졌다면 새 evidence package가 분명히 필요하다.

네 번째 문구는 brand verification 자체가 며칠 걸릴 수 있음을 보여 준다. paused 상태에서 새 메일이 온 뒤에도 모든 것을 즉시 재전송하기보다, 어떤 항목이 새 diff인지 구분해야 불필요한 중복 회신이 줄어든다.

Google은 brand verification이 보통 2-3 business days 정도 걸린다고 설명한다.

즉 시간축도 표에 들어가야 한다. 기존 response sent가 방금 전인지 며칠 전인지에 따라, 새 evidence package를 일부만 보낼지 전체를 갱신할지 판단이 달라진다.

다섯 번째 문구는 sensitive scope verification이 더 긴 시간을 가질 수 있음을 보여 준다. 같은 paused review라도 brand package와 scope package를 한 묶음으로 재전송하면 timing 판단이 섞이기 쉽다.

Google은 sensitive scope verification이 보통 3-5 business days 정도 걸린다고 설명한다.

그래서 paused review + new follow-up 상황에서는 기존 response sent 시각, current review status, 새 evidence package 종류를 한 표로 다시 나눠 적어야 한다. 그래야 wait가 맞는지, 부분 resend가 맞는지 판단이 선다.

실무에서는 paused review 뒤 follow-up이 새로 오면 한 줄 메모로 버티기 어렵다. response sent 기록과 새 evidence package를 같이 보는 triage 표가 있어야 한다.

paused review 상태에서 기존 response sent와 새 evidence package를 다시 자르는 triage 표 예시다.

이미 current review status paused일 때 resend와 wait를 가르는 글이 첫 판단을 다뤘다면, 이번 표는 그 다음 단계인 새 follow-up 재분류용 후속편이다. 요청 패키지 분기는 follow-up triage 허브 글과 current scope diff 글이 배경이 된다.

마지막 메모 예시는 새 follow-up이 왔을 때 기존 response sent 기록과 새로운 evidence diff를 어떤 필드로 함께 남기면 좋은지 보여 준다. 이 정도만 있어도 같은 답장을 두 번 보내는 실수를 줄일 수 있다.

paused review 뒤 새 follow-up email을 기존 response 기록과 함께 저장하는 메모 예시다.

핵심은 새 evidence package가 brand인지 video인지 scope인지, 그리고 기존 response 이후 실제로 바뀐 것이 무엇인지 분리해서 남기는 것이다. paused라는 status 하나만 메모에 적어 두면 이후 회신 판단이 계속 흔들린다.

5. 주의사항과 리스크

첫 번째 리스크는 기존 response sent 기록이 없어서 새 follow-up을 최초 요청처럼 처리하는 것이다. 두 번째는 scope diff가 없는데도 scope package 전체를 재전송하는 것이다. 세 번째는 video나 brand 변경만 있었는데 current review status 메모가 업데이트되지 않는 것이다.

심사 대응 문서에는 상태, 시간축, 증거 종류 세 가지가 모두 있어야 한다. 그래야 paused review가 길어져도 왜 기다렸는지, 왜 부분 resend만 했는지, 왜 전체 package를 다시 보냈는지 설명이 짧다.

• response sent 기록은 시간축을 설명한다.
• new evidence package 태그는 무엇이 바뀌었는지 설명한다.
• scope diff 유무는 전체 resend가 필요한지 판단하는 기준이 된다.

6. 결론

paused review 뒤 새 follow-up email이 왔을 때는 status 하나만 보고 움직이면 기존 response와 새 diff가 섞인다. 기존 response sent 기록과 새 evidence package를 한 표로 다시 나눠 적으면 부분 resend와 wait 판단이 훨씬 쉬워진다.

• current review status와 response sent 기록을 같이 본다.
• 새 follow-up을 brand, video, scope 패키지로 다시 태깅한다.
• scope diff가 없는 한 전체 resend보다 부분 갱신을 먼저 검토한다.

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/verification/authentication-verification
4. https://developers.google.com/identity/protocols/oauth2/policies