-
[Google OAuth][인증] In production인데 consent screen 값이 예전 그대로일 때 Draft Branding과 Publish branding을 어디부터 다시 보나기타개발지식/풀스택개발 2026. 7. 19. 20:15
IT 리서치 노트
[Google OAuth][인증] In production인데 consent screen 값이 예전 그대로일 때 Draft Branding과 Publish branding을 어디부터 다시 보나
Google OAuth 앱을 In production으로 올린 뒤에도 consent screen의 이름, 로고, support email, privacy policy URI가 예전 그대로 보여서 당황하는 경우가 있다. 2026년 7월 19일 기준 Google 공식 문서를 다시 보면 Branding 변경은 Draft Branding으로 저장되고, verification 성공 뒤에도 Publish branding 단계가 따로 있다. 이 글은 production 상태인데 live consent screen 값이 안 바뀔 때 무엇부터 다시 보는 편이 빠른지 정리한 것이다.
1. 개요
결론부터 말하면 In production 상태와 live consent screen branding 반영은 같은 상태가 아니다. Google은 Branding 변경사항을 먼저 Draft Branding으로 저장하고, verification이 끝나 Ready to publish가 되더라도 Publish branding을 눌러야 live에 반영한다고 설명한다.
그래서 production인데도 옛 app name이나 privacy policy URI가 보인다면, 먼저 Draft Branding에만 머무는지, verification 결과가 7일 안에 publish되지 않았는지, 그리고 실제 동의 화면에서 어느 client를 보고 있는지를 차례로 확인해야 한다.
2. 어디서 실제로 막히는가
현장에서 가장 자주 생기는 오해는 Audience를 Testing에서 In production으로 올렸으니 branding 수정도 자동으로 live consent screen에 반영될 것이라고 생각하는 것이다. 하지만 최근 Google Auth platform 구조는 Branding, Audience, Data Access를 분리해서 관리하고, 문서도 Branding 수정은 Draft Branding으로 저장된다고 설명한다.
또 verification이 성공했다고 해서 곧바로 live 반영이 끝나는 것도 아니다. Google 문서는 Ready to publish 뒤 Publish branding을 눌러야 변경이 live에 반영된다고 적고, 7일 안에 publish하지 않으면 다시 verification이 필요하다고 안내한다. 이 단계가 빠지면 production인데도 예전 앱 이름이 계속 보일 수 있다.
- 증상: app name이나 privacy policy URI를 바꿨는데 동의 화면은 예전 값이 보인다.
- 실패: Audience가 production이면 branding도 live라고 가정한다.
- 막힘: verification 성공과 live publish를 같은 단계로 본다.
- 누락: Draft Branding 변경 후 7일 내 Publish branding을 하지 않는다.
특히 external 앱에서 display name과 logo를 노출하는 경우 brand verification 흐름이 다시 연동될 수 있다. production 상태는 audience 범위의 문제이고, branding 노출은 review와 publish 상태의 문제이므로 두 축을 분리해서 봐야 한다.
3. 실무에서 적용하는 순서
실무 점검 순서는 다섯 단계가 가장 짧다. 먼저 Google Auth platform의 Branding 화면에서 지금 값이 Draft Branding 상태인지 확인한다. 다음으로 Verify Branding이 완료되어 Ready to publish인지 본다. 세 번째로 Publish branding을 실제로 눌렀는지와 결과가 7일 안에 있었는지 확인한다. 네 번째로 실제 OAuth 동의 화면에서 app name, support email, privacy policy URI가 새 값으로 보이는지 테스트한다. 마지막으로 필요하면 Data Access verification과 client별 흐름을 다시 확인한다.
- Branding 화면의 현재 변경사항이 draft인지 본다.
- Verify Branding이 완료됐는지 확인한다.
- Ready to publish 뒤 Publish branding을 눌렀는지 본다.
- 7일 유효기간 안에 publish했는지 확인한다.
- 실제 동의 화면에서 app name, support email, URI를 다시 본다.
이 순서를 고정해 두면 production 전환 문제와 branding live 반영 문제를 섞지 않을 수 있다. 이미 unverified warning 글이 warning 자체를 다뤘다면, 이번 글은 warning이 없어도 consent screen 값이 바뀌지 않는 분기다.
1. Branding 값 수정한다 2. Draft Branding 저장 여부 확인한다 3. Verify Branding 완료 확인한다 4. Publish branding 눌렀는지 확인한다 5. 실제 consent screen에서 새 값 확인한다4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 새 Google Auth platform 구조를 보여 준다. Branding, Audience, Data Access가 분리되어 있기 때문에 이름만 바꾸고 바로 live에 반영될 것이라고 기대하면 흐름을 놓치기 쉽다.
즉 In production 상태라도 Branding 수정은 별도 draft와 publish 흐름을 탄다. Audience가 production이라고 해서 branding 변경이 자동 반영되는 구조는 아니다.
두 번째 자료는 Draft Branding 저장 규칙을 못 박는다. Google은 Branding 페이지의 변경사항이 바로 published state가 아니라 draft로 저장된다고 설명한다.
그래서 consent screen 값이 예전 그대로일 때는 name, logo, privacy policy URI를 이미 바꿨다는 사실보다 draft에만 머물러 있는지를 먼저 봐야 한다. production 상태와 live branding 상태는 다른 축이다.
세 번째 화면은 Publish branding 단계다. 문서는 검증 성공 뒤에도 직접 publish branding 버튼을 눌러야 live consent screen에 반영된다고 적고, 7일 안에 publish하지 않으면 재검증이 필요하다고 안내한다.
이 문장 하나로 'production인데 왜 옛날 이름이 보이지?'라는 질문의 상당수가 정리된다. 검증 성공과 live 반영은 같은 버튼이 아니다.
네 번째 자료는 brand verification이 왜 얽히는지를 보여 준다. 외부 사용자용 앱에서 consent screen의 이름이나 로고를 노출하면 brand verification이 필요한 경우가 생긴다고 문서가 설명한다.
따라서 production 전환 자체는 끝났더라도 branding 변경이 verification과 publish 흐름을 다시 탈 수 있다. 이름만 바꿨는데 화면이 안 바뀌는 상황을 단순 캐시 문제로 보면 안 되는 이유다.
마지막 표는 Draft Branding에서 live consent screen까지 상태를 어떻게 읽을지 정리한 표다. 이 표가 있으면 production, ready to publish, published branding을 서로 다른 상태로 구분할 수 있다.
이미 In production인데 unverified app 경고가 뜰 때 보는 글이 verification 경고를 다뤘다면, 이번 글은 live branding 반영 순서다. 또 Testing에서 In production으로 올리기 전 글과도 바로 이어진다.
5. 주의사항과 리스크
첫 번째 리스크는 production 상태만 보고 branding live 반영을 끝난 것으로 판단하는 것이다. 두 번째는 verification 완료 후 7일 안에 publish하지 않아 다시 Need to re-verify로 돌아가는 것이다. 세 번째는 여러 OAuth client가 있는 프로젝트에서 실제로 다른 client의 consent screen을 보고 있으면서 branding 반영 문제로 오해하는 것이다.
운영 전에는 app name, support email, home page, privacy policy URI를 바꿀 때마다 Draft Branding, verification status, publish 시각을 함께 기록하는 편이 좋다. 그래야 다음 수정 때 어디서 멈췄는지 빠르게 알 수 있다.
6. 결론
Google OAuth에서 In production인데도 consent screen 값이 예전 그대로라면 Audience보다 Branding 상태를 먼저 봐야 한다. Draft Branding 저장, Verify Branding 완료, Publish branding 실행, 7일 유효기간을 차례로 확인하면 같은 증상을 훨씬 짧게 줄일 수 있다.
관련 글로는 Testing에서 In production으로 올리기 전 글, In production인데 unverified warning이 뜰 때 보는 글, redirect_uri_mismatch 점검 글을 같이 보면 좋다.
만약 문제의 핵심이 live branding 반영 지연 자체보다 production 운영에서 brand verification과 sensitive scope verification을 언제 각각 기다려야 하는지 구분하는 데 있다면 Brand verification과 Sensitive scope verification을 운영 기준으로 나눈 후속 글을 같이 보면 좋다. Draft Branding과 Publish branding 문제를 더 넓은 production 운영 메모에 붙여 주는 역할을 한다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
