-
[Google OAuth][인증] In production인데 unverified app 경고가 뜰 때 publishing status와 brand·scope 검토를 어디부터 다시 나누나기타개발지식/풀스택개발 2026. 7. 18. 20:16
IT 리서치 노트
[Google OAuth][인증] In production인데 unverified app 경고가 뜰 때 publishing status와 brand·scope 검토를 어디부터 다시 나누나
Google OAuth 앱을 In production으로 바꿨는데도 사용자에게 unverified app 경고가 보이면 보통 어디부터 다시 봐야 할지 헷갈린다. 2026년 7월 18일 기준 Google 공식 문서를 다시 보면 production 상태, brand verification, sensitive scope verification은 서로 다른 축이다. 이 글은 production인데 경고가 남을 때 publishing status와 brand·scope 검토를 어디부터 다시 나누는 편이 빠른지 정리한 것이다.
1. 개요
결론부터 말하면 production 경고는 먼저 publishing status, 그다음 brand verification, 마지막으로 scope verification 순서로 다시 분리해 봐야 한다. In production이라는 표시는 audience 공개 상태일 뿐이고, 이름·로고 표시와 민감 범위 검토는 별도로 미완료일 수 있다.
따라서 production 전환 뒤 경고가 보이면 scope를 무작정 줄이거나 brand만 다시 손보기보다, 현재 앱이 Published External + Unverified인지부터 확인하는 편이 빠르다. 이후 brand 제출 상태와 scope classification을 분리해야 원인이 짧게 갈린다.
- 먼저 publishing status를 확인하고 user type을 기록한다.
- 다음으로 brand 제출 상태를 점검하고 경고 계정을 비교한다.
- 마지막으로 scope 목록을 분류하고 verification 필요 범위를 정리한다.
- 경고가 재현되면 날짜를 기록하고 계정 종류를 비교하고 화면을 확인한다.
- 민감 범위가 있으면 제출 여부를 확인하고 대기 상태를 점검하고 팀 문서에 정리한다.
2. 어디서 실제로 막히는가
실무에서 먼저 꼬이는 지점은 세 가지다. 첫째, production이면 verification도 끝난 것으로 오해한다. 둘째, brand verification과 sensitive scope verification을 같은 심사로 묶어 생각한다. 셋째, 경고 UI가 떠도 현재 앱이 Testing인지 Published인지, scope가 basic identity인지 sensitive인지 기록하지 않는다.
하지만 OAuth app state overview는 Published External + Unverified를 Testing과 별도 행으로 분리해 두고, any Google user가 접근하더라도 warning UI와 100 total users cap이 남을 수 있다고 설명한다. 즉 production 전환 자체는 경고 제거를 보장하지 않는다.
또 brand verification 문서는 external user에 app name이나 logo를 공개로 보여 줄 때 verification이 걸릴 수 있다고 적고 있고, OAuth policies 문서는 production app이 sensitive 또는 restricted scope를 쓰면 verification submission이 필요하다고 적고 있다. 같은 경고처럼 보여도 원인은 brand일 수도 있고 scope일 수도 있다.
- 증상: In production인데 사용자에게 unverified app 경고가 뜬다.
- 실패: production 전환과 verification 완료를 같은 상태로 본다.
- 막힘: brand와 scope 미완료를 같은 backlog로 합쳐 둔다.
- 누락: current publishing status와 scope class를 문서에 안 남긴다.
막히는 지점 먼저 볼 축 판단 기준 production인데 경고 UI가 남는다 publishing status Published External + Unverified에 머무는지 본다 이름과 로고 노출이 이상하다 brand verification external + branding 공개 조건과 제출 상태를 본다 민감 데이터 접근 경고가 남는다 scope verification sensitive/restricted scope인지와 제출 상태를 본다 3. 실무에서 적용하는 순서
실무 triage 순서는 다섯 단계면 충분하다. 먼저 OAuth consent screen에서 publishing status가 실제로 Published인지 확인한다. 두 번째로 current user type이 External인지와 warning UI 캡처를 남긴다. 세 번째로 brand assets 공개 여부와 brand verification 제출 상태를 기록한다. 네 번째로 현재 scope 목록을 basic identity, sensitive, restricted로 다시 분류한다. 마지막으로 sensitive 또는 restricted scope가 남아 있으면 verification 제출 여부와 대기 시간을 팀 문서에 적는다.
- Publishing status와 user type을 먼저 확인한다.
- warning UI가 실제로 언제 누구에게 보였는지 기록한다.
- brand assets 공개 여부와 brand verification 제출 상태를 본다.
- scope를 basic identity, sensitive, restricted로 다시 분류한다.
- 필요한 verification 제출 여부와 대기 기간을 남긴다.
publishing_status=check user_type=record warning_account=record brand_verification=submitted_or_pending scope_classification=review scope_verification=required_if_sensitive팀 runbook에는 확인, 기록, 분류, 제출, 비교, 점검, 정리 순서를 그대로 적어 두는 편이 좋다. 그래야 같은 경고가 다시 떠도 누구나 같은 축부터 확인하고 같은 방식으로 기록할 수 있다.
실제 운영에서는 status 확인, account 기록, brand 점검, scope 분류, verification 제출, 대기 비교, 결과 정리까지 한 번에 이어서 처리하면 재작업이 줄어든다.
- OAuth 콘솔 설정 화면에서 publishing status를 확인한다.
- 권한 범위와 brand 설정을 같은 파일에 저장하고 확인한다.
- 경고 오류가 난 계정을 기록하고 로그처럼 날짜를 남겨 확인한다.
- scope 권한 변경 뒤에는 설정 응답을 다시 조회해 확인한다.
이 순서를 고정해 두면 brand가 미완료인데 scope만 줄이는 실수나, scope verification 대기인데 publishing status를 반복 토글하는 실수를 줄일 수 있다. 특히 외부 공개가 필요한 앱이면 warning UI를 본 계정 종류와 scope 종류를 같이 적어 두는 편이 중요하다.
4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 Google OAuth app state overview의 비교표다. 여기서는 Published External인데도 Unverified인 상태가 별도 행으로 분리돼 있고, 이때 danger UI와 100 user cap이 남을 수 있다고 적고 있다.
즉 production 전환을 했다는 사실과 verification이 끝났다는 사실은 다르다. 경고가 남는다면 먼저 지금 앱이 실제로 Published External + Unverified에 머물러 있는지 확인해야 한다.
두 번째 자료는 brand verification 기준이다. external user로 공개했고 consent screen에 app name이나 logo를 보여 준다면 brand verification 축이 별도로 걸릴 수 있다고 Google이 직접 설명한다.
따라서 production인데 경고가 남는다면 먼저 브랜드 표시 정보를 공개했는지, 제출한 brand verification이 끝났는지 별도 축으로 분리해야 한다. brand가 끝나지 않았는데 scope만 줄여도 경고가 유지될 수 있다.
세 번째 자료는 sensitive scope verification 시간 안내다. 이 문서는 민감 범위 검토가 launch plan에 반영돼야 하고 최대 10일까지 걸릴 수 있다고 적고 있다.
이 구간이 중요한 이유는 production 전환 직후 경고가 남았을 때 단순 버그인지, 아직 scope 검토 대기인지 구분하는 데 직접 도움이 되기 때문이다.
네 번째 자료는 OAuth 2.0 Policies 문서의 production 원칙이다. Google은 production app이 sensitive 또는 restricted scope를 쓰면 verification submission이 필요하다고 못 박고 있다.
즉 이미 In production이라면 scope 축은 더 이상 선택이 아니라 필수 점검 항목이다. 경고 UI를 없애려면 현재 범위가 basic identity인지, sensitive인지, restricted인지부터 다시 표로 나눠야 한다.
실무에서는 production 경고 원인을 audience, brand, scope 세 축으로 고정해 두는 편이 빠르다. 같은 unverified 경고라도 어느 축이 미완료인지에 따라 다음 행동이 달라지기 때문이다.
이미 production 전환 전 brand·scope 준비 글이 출발점 체크리스트였다면, 이번 표는 전환 뒤 남은 경고를 다시 자르는 후속판이다.
마지막 자료는 production 경고 조사에 남기면 좋은 메모 형식이다. publishing status, brand 제출 상태, scope class를 한 줄에 같이 남겨야 나중에 팀이 같은 화면을 다시 볼 수 있다.
이 정도 구조면 test user 제한 글, redirect URI 글과도 충돌 없이 이어진다. 증상 글은 증상대로, production 검토 글은 검토대로 분리되는 셈이다.
5. 주의사항과 리스크
첫 번째 리스크는 production 전환 뒤 warning UI를 보고도 여전히 Testing 시절 체크리스트만 보는 것이다. 두 번째는 brand verification만 끝나면 scope 경고도 같이 사라질 것으로 기대하는 것이다. 세 번째는 scope를 최소화하지 않은 채 production에서 검토 대기를 시작해 사용자 경험을 그대로 노출하는 것이다.
운영 전에는 최소한 publishing status, brand 제출 상태, scope class 세 칸을 같은 runbook에 분리해 두는 편이 좋다. 그래야 refresh token 7일 만료 같은 개발 단계 글과 production warning triage 글이 서로 섞이지 않는다.
- production 공개와 verification 완료를 같은 상태로 보지 않는다.
- brand 검토와 scope 검토를 따로 기록한다.
- warning UI를 본 계정·scope·날짜를 같이 남긴다.
6. 결론
Google OAuth 앱이 In production인데도 unverified app 경고가 뜬다면 먼저 publishing status를, 그다음 brand verification을, 마지막으로 scope verification을 본다. 이 세 축을 분리하면 경고가 단순 대기인지, 브랜드 미완료인지, 민감 범위 검토 미완료인지 빠르게 나뉜다.
관련 흐름으로는 production 전환 전 brand·scope 준비 글, Testing 상태 7일 refresh token 만료 글을 같이 보면 전환 전과 전환 후를 한 사다리로 정리하기 쉽다.
같은 Google OAuth production 흐름에서 unverified 경고를 넘긴 뒤 consent screen 값이 왜 예전 그대로 보이는지까지 확인하려면 Draft Branding과 Publish branding 순서를 정리한 후속 글을 이어서 보면 좋다.
7. 참고 링크
- https://developers.google.com/identity/protocols/oauth2/production-readiness/overview
- https://developers.google.com/identity/protocols/oauth2/production-readiness/brand-verification
- https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification
- https://developers.google.com/identity/protocols/oauth2/policies
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
