-
[Google OAuth][운영] reviewer가 열 수 있는 demo video 링크를 다시 보낸 뒤 published branding 반영 여부와 live consent screen을 어떤 순서로 재검증하나기타개발지식/풀스택개발 2026. 8. 5. 09:18
IT 리서치 노트
[Google OAuth][운영] reviewer가 열 수 있는 demo video 링크를 다시 보낸 뒤 published branding 반영 여부와 live consent screen을 어떤 순서로 재검증하나
Google OAuth Verification Center follow-up email에 답장하면서 reviewer가 열 수 있는 새 demo video 링크를 다시 보냈더라도, 그 직후 무엇을 다시 확인해야 할지가 더 자주 문제를 만든다. 2026년 8월 5일 기준 Google 공식 문서를 다시 보면 verification에는 demo video가 필요하고, 영상은 제출한 동일한 앱과 consent flow를 보여 줘야 하며, branding surface와 Draft Branding / Published Branding은 별도 개념으로 관리된다. 이 글은 reviewer가 열 수 있는 demo video 링크를 다시 보낸 뒤 published branding 반영 여부와 live consent screen을 어떤 순서로 재검증해야 덜 반복되는지 정리한 것이다.
1. 개요
결론부터 말하면 새 demo video 링크를 보냈다고 끝내지 말고, 곧바로 live consent screen과 Published Branding을 다시 확인하는 편이 맞다. reviewer 접근성 검증과 live branding 검증은 같은 작업이 아니다.
가장 짧은 순서는 시크릿 창 접근성 확인, 영상 속 consent flow 확인, Published Branding 확인, homepage/privacy 재확인, follow-up email 기록 업데이트다. 이 순서를 빼먹으면 stale 링크는 고쳤는데 brand mismatch가 다시 남는 상황이 반복된다.
2. 어디서 실제로 막히는가
현장에서 흔한 실패는 세 가지다. 첫째, 새 영상 링크가 열리는지만 확인하고 consent screen branding은 다시 보지 않는다. 둘째, Draft Branding을 저장한 직후 live 화면도 바뀌었을 것이라고 가정한다. 셋째, 홈페이지와 privacy policy는 고쳤지만 영상 속 앱 이름과 로고는 예전 상태 그대로 남긴다.
Google 문서는 demo video 필요성과 동일 앱 증빙과 branding surface와 Draft/Published 분리를 각각 따로 설명한다. 이 네 조각을 합치면 follow-up email 뒤 재검증은 링크 하나의 문제가 아니라 live surface와 영상의 동기화 문제라는 결론이 나온다.
실무에서는 화면, 메뉴, 버튼, 탭, 필드, 상태를 어디서 다시 볼지 정하지 않으면 같은 실수를 반복한다. Verification Center 상태 화면을 열고, Branding 메뉴 탭을 열고, Published Branding 필드를 확인하고, consent 화면 캡처와 video 결과를 비교하고, homepage 경로와 privacy policy 경로를 클릭해 상태를 확인해야 한다. 이런 비교와 표시 절차가 없으면 reviewer가 보는 화면과 운영자가 본 화면이 달랐는지 나중에 다시 설명하기 어렵다.
- 증상: reviewer가 링크는 열지만 같은 branding 지적이 반복된다.
- 실패: 접근성 확인 뒤 Published Branding 확인을 건너뛴다.
- 막힘: Draft 저장과 Published 반영을 같은 것으로 본다.
- 누락: 시크릿 창 검증 시각과 live 화면 확인 시각을 메모하지 않는다.
3. 실무에서 적용하는 순서
재검증 순서는 다섯 단계가 가장 짧다. 먼저 새 video 링크를 시크릿 창에서 연다. 두 번째로 영상 속 consent screen의 앱 이름, 로고, scope 사용 흐름이 현재 앱과 같은지 본다. 세 번째로 Google Auth Platform의 Published Branding 화면을 다시 열어 라이브 값이 영상과 같은지 본다. 네 번째로 homepage와 privacy policy와 support email을 같은 branding surface 기준으로 다시 확인한다. 마지막으로 follow-up email 답장 메모에 재검증 시각을 남긴다.
- 시크릿 창에서 reviewer 접근성을 다시 확인한다.
- 영상 속 consent flow가 현재 앱과 같은지 본다.
- Published Branding 값을 라이브 기준으로 다시 확인한다.
- homepage·privacy·support email을 같은 앱 기준으로 맞춘다.
- 재검증 시각과 링크를 follow-up 메모에 남긴다.
이때 중요한 것은 '내 브라우저에서 열리나'가 아니라 'reviewer 관점에서 로그인 없이 열리나'와 '라이브 consent screen이 영상과 같나' 두 줄이다. 두 줄이 모두 맞아야 follow-up 답장이 다시 길어지지 않는다.
recheck_order: open video link in incognito compare consent screen app name and logo open Published Branding tab click homepage and privacy policy links save timestamped reviewer memo4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 verification 제출 가이드의 기본 요구사항이다. Google은 verification 검토에 demo video 제출을 요구한다.
즉 reviewer가 열 수 있는 새 링크를 보냈다고 해서 검토 준비가 끝난 것은 아니다. 그 영상이 현재 live consent flow와 같은 앱을 보여 주는지도 바로 이어서 확인해야 한다.
두 번째 자료는 demo video 요구사항 문서의 핵심 문장이다. Google은 제출한 verification 앱과 같은 앱을 영상에서 보여 달라고 적고 있다.
그래서 새 링크 접근성만 확인하고 끝내면 반쪽이다. reviewer가 열 수 있는지와 영상 속 branding이 현재 앱과 같은지는 따로 봐야 한다.
세 번째 자료는 branding surface 정의다. app name, logo, support email, domain 같은 값이 실제 사용자 consent screen에 보이는 public surface라는 뜻이다.
재검증은 결국 이 live surface와 영상 캡처가 같은 앱을 가리키는지 보는 일이다. homepage나 privacy policy가 맞아도 consent screen 로고와 앱 이름이 엇갈리면 다시 막힌다.
네 번째 자료는 Draft Branding과 Published Branding 분리다. 저장한 값이 곧바로 라이브 사용자 화면에 보이는 것은 아니라는 뜻이다.
이 차이를 놓치면 최신 branding을 저장한 뒤 바로 영상을 다시 찍고도 reviewer가 보는 live 화면은 예전 값인 상황이 생긴다. 새 video 링크를 보낸 직후라면 특히 이 구분을 먼저 다시 봐야 한다.
실무에서는 재전송 뒤 다시 무엇을 열어 봐야 할지 순서가 중요하다. 링크 접근성, live consent screen, published branding, homepage/privacy를 한 줄로 섞어 보면 다시 놓친다.
전날 글인 stale video 링크와 brand mismatch를 가르는 글이 문제를 두 패키지로 나눴다면, 이번 표는 새 링크를 보낸 뒤 어떤 확인을 먼저 다시 해야 하는지에 집중한다.
마지막 자료는 reviewer 재검토 직전 체크리스트다. 영상 링크만 교체하고 메일을 보내지 말고, 라이브 화면과 링크 검증 로그를 같이 남기는 편이 좋다.
같은 클러스터의 선행 글인 Draft Branding과 Published Branding 차이 글, homepage·privacy policy·authorized domains 정리 글, follow-up email 패키지 재제출 글과 연결하면 재제출 흐름이 더 짧아진다.
5. 주의사항과 리스크
첫 번째 리스크는 새 링크 접근성만 확인하고 Published Branding을 다시 보지 않는 것이다. 두 번째는 Draft 변경 직후 영상을 다시 찍어 라이브와 다시 어긋나는 것이다. 세 번째는 링크 접근성 확인 시각을 남기지 않아 reviewer가 다시 못 열 때 원인을 추적하지 못하는 것이다.
video package와 live branding package는 연결돼 있지만 검증 포인트가 다르다. 둘을 따로 메모하지 않으면 어느 쪽이 흔들렸는지 다시 설명하기 어렵다.
6. 결론
reviewer가 열 수 있는 새 demo video 링크를 다시 보낸 뒤에는 Published Branding과 live consent screen을 바로 재검증하는 편이 가장 안전하다. 접근성 확인, 영상-앱 일치 확인, Published Branding 확인, 링크 surface 재확인 순서를 고정해 두면 같은 follow-up 지적을 크게 줄일 수 있다.
- 새 링크 접근성과 동일 앱 증빙은 따로 본다.
- Draft 저장 뒤에는 Published Branding을 다시 확인한다.
- 재검증 시각과 라이브 화면 확인 로그를 같이 남긴다.
만약 follow-up 답장 이전이나 직후에 Verification Center 상태가 아예 끊기듯 바뀌었다면 verification 제출 뒤 auto-cancelled가 뜰 때 Testing·Internal 전환과 reviewer 자격 증명을 어디서 먼저 다시 보는지 정리한 글도 바로 이어서 확인하는 편이 안전하다. 이 글이 live branding과 demo video 재검증 순서를 다뤘다면, 후속 글은 reviewer access 문제와 verification eligibility 변화 자체를 먼저 분리하는 흐름을 다룬다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
