-
[Google OAuth][운영] basic profile만 요청하는 Published External Unverified 앱은 어떤 경우 user cap과 추가 검토를 피할 수 있나기타개발지식/풀스택개발 2026. 7. 24. 09:17
IT 리서치 노트
[Google OAuth][운영] basic profile만 요청하는 Published External Unverified 앱은 어떤 경우 user cap과 추가 검토를 피할 수 있나
Google OAuth 앱이 Published External Unverified 상태로 public 노출 중인데도 basic profile만 요청하는 경우가 있다. 이때 운영팀은 user cap과 추가 검토가 항상 따라붙는지, 아니면 예외가 있는지 헷갈리기 쉽다. 2026년 7월 23일 기준 Google 공식 문서를 다시 보면 basic profile subset, user cap, sensitive-scope verification은 서로 다른 규칙이다. 이 글은 basic profile만 요청하는 Published External Unverified 앱이 어떤 경우 user cap과 추가 검토를 피할 수 있는지 정리한다.
1. 개요
결론부터 말하면
Published External Unverified라는 라벨만으로 모든 운영 제약이 결정되지는 않는다. 실제 요청 scope가 openid, userinfo.email, userinfo.profile 같은 basic profile subset뿐이라면 warning, trusted-user requirement, 7-day expiration 쪽에서 예외가 적용될 수 있다. 반대로 추가 sensitive scope가 하나라도 섞이면 다시 user cap과 verification 흐름으로 들어갈 가능성이 크다.따라서 먼저 나눌 것은 publish 상태가 아니라 actual requested scopes다. 운영자는
basic profile subset만 요청하는지,추가 scope가 붙는지,verification center가 pending인 범위가 어디인지를 따로 적어야 한다. 이 세 줄을 분리해 두면 support 문의와 product 결정이 훨씬 짧아진다.2. 어디서 실제로 막히는가
실무에서 흔한 오해는 두 가지다. 첫째, In production 또는 Published External Unverified라면 무조건 100 total users cap이 붙는다고 생각하는 것이다. 둘째, basic profile subset 예외가 있으니 verification은 필요 없다고 오해하는 것이다. Google 문서는 이 둘을 다르게 설명한다. app state overview는 Published External Unverified 상태에서 warning과 user cap이 붙을 수 있다고 설명하고, Manage App Audience는 testing/production 흐름 안에서 basic profile subset 예외를 별도로 적어 둔다.
문제는 운영 중 scope가 조용히 늘어나는 순간이다. Sign in with Google만 쓰던 앱이 calendar, drive, gmail 같은 추가 권한을 한두 개 붙이는 순간, 이전까지는 조용하던 경고 화면과 cap 문의가 갑자기 생길 수 있다. 그런데 팀이 consent screen 로그를 남기지 않았다면 publish 상태가 바뀐 건지, scope가 늘어난 건지, review가 보류된 건지 분간하기 어렵다.
또 policy compliance 문서는 production 앱이 sensitive 또는 restricted scope를 쓴다면 verification을 제출해야 한다고 못 박고 있다. 즉 basic profile exception은
scope가 그 범위에 머물러 있을 때만 의미가 있다. 이 예외를 장기 운영 전략으로 이해하면, 어느 날 추가 scope가 붙었을 때 왜 갑자기 제약이 생겼는지 설명이 끊긴다.- 증상: 앱은 public인데 어떤 사용자에겐 경고가 없고, 어떤 사용자 흐름에선 cap 문제가 보인다.
- 실패: actual requested scopes를 기록하지 않은 채 publish 상태만 본다.
- 막힘: basic profile subset 예외와 sensitive-scope verification을 같은 규칙으로 본다.
- 누락: support email, privacy policy, scope change 이력을 같은 문서에 남기지 않는다.
상황 오해 실제 확인 포인트 Published External Unverified 무조건 같은 사용자 cap이 붙는다 actual requested scopes와 warning UI 여부를 같이 본다 basic profile subset만 요청 verification이 영영 필요 없다 scope가 정말 그 subset에 머무는지 계속 본다 추가 scope가 붙는다 branding만 늦어진 문제다 sensitive/restricted review와 cap을 다시 나눈다 3. 실무에서 적용하는 순서
가장 짧은 분기 순서는 다섯 단계다. 첫째, 현재 requested scopes를 실제 authorization request 기준으로 저장한다. 둘째, 그 목록이 openid, userinfo.email, userinfo.profile subset만으로 끝나는지 확인한다. 셋째, support email, privacy policy, home page가 최신인지 같이 본다. 넷째, 추가 sensitive 또는 restricted scope가 하나라도 있으면 verification 문서와 demo video 묶음을 따로 준비한다. 다섯째, user cap이나 warning UI 사례가 보이면 publish 상태가 아니라 scope 변화를 먼저 의심한다.
- actual requested scopes를 로그로 남긴다.
- basic profile subset만 요청하는지 먼저 확인한다.
- support email, privacy policy, home page를 최신으로 유지한다.
- 추가 scope가 있으면 verification 묶음을 별도 관리한다.
- warning UI 또는 user cap 증상은 scope 변화부터 다시 본다.
이 순서가 중요한 이유는 예외를 전략으로 삼지 않게 해 주기 때문이다. basic profile subset만 요청하는 동안에는 사용자 onboarding을 비교적 단순하게 유지할 수 있다. 하지만 product가 추가 기능을 붙이며 scope가 늘어나는 순간, 이전 예외는 사라질 수 있다. 따라서 scope change review를 릴리스 체크리스트에 넣고, 배포 전 요청 URL을 다시 조회하고, scope 로그를 저장하고, support 문의가 들어오면 warning 화면과 user cap 응답을 같이 확인하고, scope 변경 PR을 검토한 뒤 verification runbook을 재실행하는 편이 좋다. 누가 어떤 버튼을 눌렀는지보다 어떤 scope가 실제 요청에 들어갔는지가 훨씬 결정적이다.
requested_scopes=openid userinfo.email userinfo.profile contains_sensitive_scope=false publishing_status=Published External Unverified warning_ui_seen=false user_cap_seen=false support_email=oauth-support@example.com home_page=https://example.com privacy_policy=https://example.com/privacy이미 Pending인데 앱은 In production인 상태를 넓게 본 글, Pending에서 오래 멈출 때 brand evidence를 다시 내는 글, Published External Unverified + user cap을 넓게 본 글이 있다면, 이번 글은 그 가지에서
기본 프로필 subset 예외만 따로 떼어 내는 역할이다.4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 Google의 OAuth app state overview 표다. Published External Unverified 상태가 Testing External과 다르다는 점을 여기서 먼저 고정해야 한다.
즉 이미 In production이더라도 verification이 끝나지 않은 scope가 있으면 사용자 cap과 경고 화면이 살아 있을 수 있다. production이라는 단어만 보고 testing 예외 규칙을 그대로 기대하면 안 된다.
두 번째 자료는 Manage App Audience 문서의 basic-profile exception 구간이다. 어떤 범위에서 trusted user list와 warning, 7-day expiration 예외가 생기는지 Google이 직접 설명한다.
여기서 중요한 점은 이 예외가
다른 scope가 하나도 섞이지 않을 때만 의미가 있다는 것이다. 하나라도 추가 scope가 섞이면 예외가 무너지고, 운영자는 다시 user cap과 review 요구를 분리해서 봐야 한다.세 번째 화면은 OAuth user cap 설명이다. user cap이 언제 붙고 언제 안 붙는지 따로 읽어야 support 문의를 짧게 답할 수 있다.
따라서 Published External Unverified 상태에서 basic profile만 요청하는지, 아니면 아직 승인 안 된 sensitive scope가 섞였는지 먼저 나눠야 한다. cap은 branding 문구가 아니라 scope 위험도와 연결된 운영 제약이다.
네 번째 자료는 policy compliance 문서의 최소 scope 원칙이다. exception을 악용하는 대신 실제로 필요한 최소 권한으로 scope를 줄이라는 Google의 기준을 확인한다.
즉 운영 판단은
basic profile만으로 기능이 충분한가와다른 scope가 꼭 필요한가를 나누는 일이다. 이 분기가 바로 user cap 회피와 추가 검토 요구의 경계가 된다.scope를 한 장으로 분류해 두면 support, product, auth 담당자가 같은 표를 본다. basic profile subset, additional sensitive scopes, mixed production state를 따로 적는 편이 가장 실용적이다.
이미 Published External Unverified + Pending을 넓게 본 글을 읽었다면, 이번 표는 그 가지에서
기본 프로필만 요청하는 예외를 따로 떼어 낸 결정판이다.마지막 자료는 운영 로그 예시다. actual requested scopes, publish 상태, verification 상태, support 연락처를 같은 레코드에 넣어야 basic-profile exception이 깨진 순간을 빠르게 찾을 수 있다.
이 정도 기록만 있어도 경고 화면 문의가 들어왔을 때
scope가 늘었는지,review가 pending인지,support email이 최신인지를 같은 문서에서 바로 답할 수 있다.5. 주의사항과 리스크
첫 번째 리스크는 basic profile subset 예외를 장기 운영 상태처럼 이해하는 것이다. 두 번째는 scope가 하나 늘었는데도 같은 예외가 유지될 것이라 가정하는 것이다. 세 번째는 support email, privacy policy, home page를 방치해 정책 준수와 사용자 신뢰를 동시에 떨어뜨리는 것이다.
production 앱이라면 예외가 있더라도 scope change review는 계속 남기는 편이 좋다. 특히 product 기능이 늘어날 때 auth 코드 한 줄보다 consent screen scope 목록이 더 빨리 운영 상태를 바꾼다.
- 예외는
basic profile subset일 때만의미가 있다. - scope가 늘면 user cap과 verification 요구를 다시 본다.
- contact 정보와 정책 문서를 같은 변경 레코드에 묶어 둔다.
6. 결론
Published External Unverified 앱이라도 actual requested scopes가 basic profile subset뿐이면 user cap과 추가 검토 흐름을 다르게 볼 수 있다. 핵심은 publish 라벨보다 scope 목록이다. 따라서 운영자는
현재 scope가 정말 기본 프로필 범위에 머무는지를 먼저 확인하고, authorization request를 조회하고, scope 로그를 저장하고, warning 화면을 점검하고, 그 범위를 넘는 순간 바로 verification runbook으로 넘어가야 한다.같은 Google OAuth 가지의 선행 글로는 Pending인데 앱은 In production인 상태를 넓게 본 글, brand evidence와 sensitive-scope justification 재제출 글, Published External Unverified의 user cap 분리 글을 같이 보면 흐름이 끊기지 않는다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
