-
[Google OAuth][운영] Verification Center가 Pending인데 앱은 In production일 때 테스트 사용자 한도와 경고 화면을 어떤 기준으로 다시 보나기타개발지식/풀스택개발 2026. 7. 20. 20:16
IT 리서치 노트
[Google OAuth][운영] Verification Center가 Pending인데 앱은 In production일 때 테스트 사용자 한도와 경고 화면을 어떤 기준으로 다시 보나
Google OAuth 앱이 Verification Center에서는 Pending인데 이미 In production으로 표시되면 운영팀은 바로 혼란스러워진다. 2026년 7월 20일 KST 기준 Google 공식 문서를 다시 보면 Testing의 100 test users 제한, In production 뒤의 unverified warning, sensitive scope review 대기는 서로 다른 규칙이다. 이 글은 Pending 상태에서 테스트 사용자 한도와 경고 화면을 어떤 기준으로 다시 봐야 하는지 정리한 것이다.
1. 개요
결론부터 말하면 Verification Center가 Pending이어도 먼저 봐야 하는 값은 현재 앱이 Testing인지 In production인지다. Testing External이면 allowlist된 최대 100 test users 제한이 먼저 적용되고, Published External Unverified면 누구나 접근할 수 있어도 unverified warning과 100 total users cap이 먼저 문제가 된다.
그다음에 brand verification 대기인지, sensitive scope verification 대기인지 나눠야 한다. production은 공개 범위 상태이고, verification은 branding 노출과 권한 승인 상태이므로 한 문장으로 묶어 읽으면 운영 판단이 계속 흔들린다.
2. 어디서 실제로 막히는가
현장에서 흔한 오해는 'Publish app 버튼을 눌렀으니 이제 review 문제는 끝났다'는 생각이다. 하지만 Google Help는 In production 상태에서도 이름과 로고 노출은 verification 대상일 수 있고, 민감하거나 제한된 scope는 별도 review를 기다릴 수 있다고 설명한다.
또 다른 오해는 Pending이면 언제나 test users 제한을 생각하는 것이다. 이 제한은 Testing 상태의 External 앱에 붙는 규칙이다. 반대로 Published External Unverified는 test user allowlist가 아니라 unverified app warning과 100 total users cap 쪽이 더 중요해진다.
Internal 앱도 자주 섞인다. internal은 verification이 필요 없다고 외운 뒤 external 프로젝트에 그대로 적용하면, production 전환 뒤 갑자기 경고 화면과 review 대기가 왜 남는지 설명이 안 된다. user type과 publishing status를 따로 기록해야 이런 착각이 줄어든다.
- 증상: 이미 production인데도 사용자 일부가 경고 화면을 본다.
- 증상: Production 전환 후에도 민감 권한 승인이 막힌다.
- 실패: test users 제한과 unverified app user cap을 같은 규칙으로 본다.
- 누락: internal / external 구분을 사건 메모에 남기지 않는다.
3. 실무에서 적용하는 순서
실무 triage는 다섯 단계로 고정하면 된다. 먼저 user type을 적는다. 두 번째로 publishing status를 적는다. 세 번째로 요청 scope를 basic identity와 sensitive or restricted로 다시 나눈다. 네 번째로 Verification Center 상태를 brand와 scope 제출로 분리한다. 마지막으로 현재 보이는 제한이 test user allowlist인지, unverified app user cap인지 구분한다.
- Internal / External을 먼저 적는다.
- Testing / In production을 확인한다.
- 현재 scope 분류를 다시 적는다.
- Brand와 scope verification 대기 상태를 따로 적는다.
- test user cap인지 user cap인지 제한 종류를 구분한다.
user_type=external publishing_status=in_production requested_scopes=openid,email,profile,drive.file brand_verification=pending scope_verification=pending current_limit=unverified_user_cap이 순서를 쓰면 'Pending이라서 다 막힌다' 같은 넓은 표현을 버릴 수 있다. 실제로는 로그인 자체는 되지만 branding이 덜 보이는 경우, branding은 반영됐지만 민감 scope review가 남은 경우, 여전히 Testing이라 allowlist에 막힌 경우가 서로 다르다.
운영 메모에는 Verification Center 상태를 조회하고, consent screen 설정을 확인하고, scope 목록 파일을 저장하고, warning 화면 결과와 오류 응답 로그를 비교하고, Publish app 실행 시각과 test user 목록 변경 시각을 함께 기록하는 편이 좋다. 이렇게 확인, 조회, 저장, 비교, 실행, 로그 기록을 같은 표에 두면 production 운영자가 바뀌어도 같은 판단을 재현하기 쉽다.
4. 공식 문서와 예시 화면으로 확인하기
첫 화면은 Google의 Manage App Audience 문서에서 Testing 상태를 설명하는 부분이다. Verification Center가 Pending이어도, 앱이 아직 Testing이면 먼저 test user allowlist 100명 제한부터 적용된다.
즉 Verification Center 상태와 상관없이 Testing이면 allowlist 규칙이 우선이다. Pending 검토 때문에 막힌 것인지, 여전히 Testing이라 막힌 것인지를 여기서 먼저 가를 수 있다.
두 번째 화면은 Google overview 표에서 Published External Unverified 상태를 설명하는 부분이다. production으로 열렸더라도 brand verification이 끝나지 않았고 민감 권한 심사가 남아 있으면 이름과 로고가 숨겨지거나 경고 화면이 붙을 수 있다는 점을 표로 보여 준다.
그래서 '이미 production인데 왜 아직 기다리라고 하지?'라는 질문에는 두 층이 섞여 있다. 공개 범위는 production으로 열렸지만, branding과 scope review는 아직 Pending일 수 있다.
실무에서는 Testing, Published Unverified, Published Verified를 한 표에서 구분해야 한다. 경고 화면도 다르고, 사용자 한도도 다르고, 운영 판단도 달라지기 때문이다.
이미 brand verification과 sensitive scope verification을 나눈 글이 큰 축을 설명했다면, 이번 표는 Pending 상태에서 실제 사용자 제한이 어떻게 달라지는지를 바로 보여 준다.
운영자 관점에서는 지금 무엇을 기다리는지 명시적으로 적어야 한다. Publishing status, brand assets, sensitive scopes, test user cap을 한 줄 메모로 동시에 보면 사건 분리가 빨라진다.
이 체크리스트는 Draft Branding과 Publish branding 글에서 다룬 branding 반영 문제를 user cap과 warning 문제와 분리해서 보는 데 유용하다.
마지막 자료는 운영 로그 예시다. 실제로는 warning 화면 스크린샷보다 이런 상태 로그가 더 오래 남는다.
이 정도만 남겨도 다음 사람이 '왜 production인데 아직 제한이 있지'를 다시 추측하지 않아도 된다. 특히 external 앱에서 민감 권한을 요청하는 팀이라면 반복해서 도움이 된다.
5. 주의사항과 리스크
첫 번째 리스크는 production을 verification 완료와 같은 상태로 보는 것이다. 두 번째는 Testing 제한과 Published External Unverified의 user cap을 섞는 것이다. 세 번째는 기본 identity scopes 예외를 기억하지 못해 모든 문제를 review 지연으로 해석하는 것이다.
운영 전에는 프로젝트별로
user_type,publishing_status,requested_scopes,brand_verification,scope_verification,current_limit를 함께 기록해 두는 편이 좋다. 그래야 Testing에서 In production으로 올리기 전 글과 unverified warning 글의 기준을 같은 시트 안에서 재사용할 수 있다.6. 결론
Verification Center가 Pending인데 앱이 In production이라면 먼저 현재 제한이 publish 범위 문제인지, branding 반영 문제인지, sensitive scope review 문제인지 분리해야 한다. Testing External의 100 test users 제한과 Published External Unverified의 경고·user cap은 서로 다른 규칙이므로 같은 원인으로 묶으면 안 된다.
같은 가지의 선행 글로는 Draft Branding과 Publish branding 글, brand verification과 sensitive scope verification 글을 같이 보면 좋다.
이번에 운영 범위를 더 좁혀 보고 싶다면 Published External Unverified와 100 total users cap 분리 글로 먼저 넘어가고, Pending이 오래 멈춘 프로젝트라면 brand evidence와 sensitive scope justification 재제출 순서 글을 바로 이어서 보는 편이 빠르다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
