[Google OAuth][인증] basic profile만 요청하는 Published External Unverified 앱은 어떤 경우 user cap과 추가 검토를 피할 수 있나

IT 리서치 노트

[Google OAuth][인증] basic profile만 요청하는 Published External Unverified 앱은 어떤 경우 user cap과 추가 검토를 피할 수 있나

Google OAuth 앱을 Published External Unverified로 올린 뒤에도 모든 경고와 제한이 같은 방식으로 남는 것은 아니다. 2026년 7월 28일 기준 Google 공식 문서를 다시 보면 openid, email, profile만 요청하는 basic profile-only 앱은 allowlist 예외와 접근 경계가 따로 설명되고, sensitive 또는 restricted scope를 요청하는 앱은 warning UI와 100 total users cap, 추가 검토가 다른 층으로 남는다. 이 글은 Published External Unverified 상태에서 basic profile-only 앱이 어떤 경우 user cap과 추가 검토를 피할 수 있고, 어떤 경우 여전히 verification 경로로 넘어가야 하는지 실무 기준으로 정리한다.

목차

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

1. 개요

결론부터 말하면 Published External Unverified 상태라고 해서 모든 앱이 같은 100 total users cap과 추가 검토를 그대로 받는 것은 아니다. 현재 요청 scope가 openid, email, profile 같은 basic identity 범위에서 끝나면 운영 해석이 달라지고, sensitive 또는 restricted scope를 포함하면 warning UI와 user cap과 verification 대기를 별도 이슈로 적어야 한다.

즉 먼저 봐야 할 값은 Publish 상태 그 자체보다 현재 scope 목록이다. basic profile-only 앱은 brand verification과 warning UI 품질 문제를 먼저 보고, Google API 데이터에 닿는 scope가 있으면 cap과 추가 검토를 production 운영 계획에 바로 반영해야 한다.

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

현장에서 가장 흔한 혼선은 세 가지다. 첫째, Published External Unverified라는 상태명만 보고 모든 앱이 동일한 user cap과 검토 경로를 갖는다고 생각한다. 둘째, redirect URI나 homepage URL을 고친 뒤에는 consent screen 문제가 끝났다고 오해한다. 셋째, 현재 요청 scope가 basic identity 범위인지, 아니면 이미 sensitive scope로 넘어갔는지 메모하지 않는다.

하지만 Google 문서는 Published External Unverified 행에서 user access, warning UI, verification 필요 조건을 분리해 적고 있다. 특히 sensitive 또는 restricted scope를 요청하는 경우에만 100 total users cap과 unverified app warnings를 같이 보라고 설명한다. 반대로 basic identity 범위만 요청하는 앱은 같은 Published 상태라도 운영 판단 기준이 달라진다.

문제는 팀 메모에서 이 구분이 자주 지워진다는 점이다. 같은 External, 같은 Published라 해도 현재 scope가 달라지면 다음 행동이 완전히 달라진다. 그래서 status만 적고 scope를 안 적으면 basic profile-only 예외와 additional review 대기를 같은 문제로 오판한다.

• 증상: Published로 바꿨는데도 warning UI와 user cap 해석이 팀마다 다르다.
• 실패: current scope를 메모하지 않고 Published External Unverified만 적는다.
• 막힘: basic identity 예외와 sensitive scope verification 대기를 같은 상태로 묶는다.
• 누락: brand verification과 scope verification을 다른 단계로 저장하지 않는다.

증상	먼저 보는 값	판단 기준
Published인데 warning UI가 남는다	brand verification 여부와 current scope	basic profile-only인지, sensitive scope가 들어갔는지 나눈다
public access는 되는데 cap 설명이 섞인다	scope 목록과 Published External Unverified 행	100 total users cap이 언제 붙는지 따로 적는다
review가 필요한지 팀 판단이 다르다	sensitive 또는 restricted scope 포함 여부	추가 검토 대상이면 production readiness 체크리스트로 넘긴다

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

실무 순서는 네 단계면 충분하다. 1단계에서 publishing status와 user type을 적는다. 2단계에서 현재 요청 scope를 basic identity와 sensitive 또는 restricted로 다시 분리한다. 3단계에서 warning UI, brand verification, user cap 기대값을 한 줄 메모로 붙인다. 4단계에서 basic profile-only로 유지할지, 아니면 verification 절차로 올라갈지 결정을 기록한다.

실제 확인할 때는 OAuth app state overview 화면을 열고, Audience 표에서 user type을 확인하고, Data Access 경로로 들어가 Add or remove scopes 버튼을 클릭해 scope 목록을 확인하고, warning UI와 review 상태를 메모에 입력하고, 마지막으로 표를 비교해 다음 행동을 기록하는 순서가 가장 짧다.

팀 runbook에는 최소한 화면 조회, 메뉴 클릭, scope 설정 확인, review 상태 입력, warning UI 로그 저장, scope 표 비교, verification 경로 기록 같은 동작어를 그대로 남기는 편이 좋다. 그래야 다음 작업자가 같은 콘솔 화면을 열고 같은 경로를 따라가며 권한 상태를 확인하고, 현재 설정과 응답 차이를 로그와 메모 파일에 다시 저장할 수 있다.

1. publishing status와 user type을 먼저 적는다.
2. 요청 scope를 basic identity와 sensitive 또는 restricted로 분리한다.
3. warning UI와 brand verification 상태를 메모한다.
4. basic profile-only 유지 또는 verification 진행 결정을 기록한다.

이 구조를 쓰면 same-state confusion이 크게 줄어든다. 예를 들어 로그인만 필요한 마케팅 사이트나 계정 연동 시작점이면 basic profile-only 유지가 가능할 수 있고, Calendar나 Drive 데이터까지 읽는 앱이면 Published External Unverified 상태만으로는 production 운영 기준이 성립하지 않는다.

운영 메모 예시

publishing_status=Published
user_type=External
requested_scopes=openid,email,profile
warning_ui=brand_warning_only
expected_user_cap=false_for_basic_profile_only
verification_path=brand_only_or_none
owner_next_action=keep_current_scope

반대로 현재 scope가 calendar.readonly 같은 sensitive 범위로 넘어가면 같은 표를 써도 결론은 달라진다. 이 경우에는 basic profile-only 예외를 기대하기보다 verification 준비와 cap 경계를 먼저 운영 계획에 넣는 편이 안전하다.

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

첫 화면은 basic identity scope 예외가 어디에 붙는지 보여 준다. Google 문서는 External + Testing 상태에서도 openid, email, profile만 요청하면 allowlist 예외가 있다고 직접 적고 있다.

Google OAuth overview 문서는 basic identity scopes만 요청하면 test user allowlist 예외가 생긴다고 설명한다.

이 예외를 먼저 읽어야 Published External Unverified 상태에서도 무엇이 그대로 열리고 무엇이 다시 막히는지 구분할 수 있다. basic profile-only 앱과 sensitive scope 앱은 같은 경고 문구처럼 보여도 운영 조건이 다르다.

두 번째 자료는 Published External Unverified 행이다. 이 행에는 어떤 사용자가 접근할 수 있는지, brand verification이 없으면 어떤 경고가 남는지, 그리고 sensitive 또는 restricted scope에서 언제 100 total users cap이 붙는지가 함께 적혀 있다.

Published External Unverified 상태에서는 접근 가능 여부와 warning UI와 100 total users cap 조건이 같은 표에 정리돼 있다.

즉 basic profile-only 앱이 모두 같은 리스크를 갖는 것은 아니다. 어떤 cap과 추가 검토가 남는지는 실제 scope 구성이 basic identity에서 끝나는지, sensitive 범위로 넘어가는지에 따라 갈린다.

세 번째 자료는 scope 선언 단계다. Published로 올렸더라도 현재 요청 scope를 다시 선언하지 않으면 basic profile-only 예외인지, sensitive verification 대상인지 운영 메모가 섞이기 쉽다.

Google은 production readiness 과정에서 현재 요청 scope를 다시 선언하고 검토하라고 안내한다.

그래서 user cap과 추가 검토를 피하는 핵심은 Publish 버튼 자체보다 scope 경계다. `openid`, `email`, `profile`까지만 쓰는 앱과 Google API 데이터를 여는 앱은 같은 Published External Unverified라도 후속 조치가 다르다.

실무에서는 consent screen의 상태명을 읽는 것보다 scope 경계와 warning 조건을 한 표로 붙여 두는 편이 빠르다. 이 표는 basic profile-only 앱과 sensitive scope 앱을 같은 Published External Unverified 상태 안에서 다시 나눠 보는 용도다.

Published External Unverified 상태에서 basic profile-only 앱과 sensitive scope 앱을 나눠 보는 표다.

이미 redirect URI와 origin triage 글이 URL 설정층을 잡아 줬다면, 이번 표는 그 다음인 scope·verification 층을 정리한다.

마지막 자료는 운영 메모 예시다. user type, publishing status, 현재 scope, warning UI 종류를 한 줄 메모로 같이 남기면 basic profile-only 예외와 추가 검토 대기를 같은 문제로 묶지 않게 된다.

Published External Unverified 앱의 scope 경계를 남기는 runbook 메모 예시다.

이 메모가 있으면 Testing 상태 refresh token 7일 만료 글과 Testing 상태와 publishing status 재분리 글을 Published 단계 후속 판단까지 자연스럽게 연결할 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 Published External Unverified라는 상태명을 너무 크게 읽는 것이다. 두 번째 리스크는 basic identity 예외를 모든 scope에 일반화하는 것이다. 세 번째 리스크는 brand verification과 scope verification을 같은 항목으로 기록해 어느 검토가 남았는지 나중에 못 찾는 것이다.

운영 전에 확인할 때는 최소한 현재 scope 목록과 warning UI 종류와 verification 필요 여부를 같은 메모에 남기는 편이 좋다. 그래야 cap과 추가 검토를 피하는 경우와 못 피하는 경우를 한 줄로 다시 설명할 수 있다.

• basic identity 예외는 scope 경계가 바뀌는 순간 의미가 달라진다.
• Published 상태와 verification 완료는 같은 말이 아니다.
• brand 경고와 user cap 조건을 각각 따로 적는다.

6. 결론

Published External Unverified 상태의 Google OAuth 앱을 해석할 때는 상태명보다 scope 경계를 먼저 읽는 편이 맞다. basic profile-only 앱은 user cap과 추가 검토 해석이 달라질 수 있지만, sensitive 또는 restricted scope가 붙는 순간 verification과 cap을 별도 운영 리스크로 다뤄야 한다.

• status보다 current scope를 먼저 기록한다.
• basic profile-only와 sensitive scope 앱을 같은 Published 상태로 묶지 않는다.
• brand verification과 scope verification을 별도 항목으로 남긴다.

7. 참고 링크

1. https://developers.google.com/identity/protocols/oauth2/production-readiness/overview
2. https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification
3. https://developers.google.com/identity/verification/authentication-policy-compliance
4. https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid