[Google OAuth][인증] Testing에서 In production으로 올리기 전에 brand verification과 sensitive scope 검토를 어떤 순서로 나누나

Sophie_ 2026. 7. 18. 09:18

IT 리서치 노트

[Google OAuth][인증] Testing에서 In production으로 올리기 전에 brand verification과 sensitive scope 검토를 어떤 순서로 나누나

Google OAuth 앱을 Testing에서 In production으로 올리기 직전이 가장 헷갈린다. 2026년 7월 17일 기준 Google 공식 문서를 다시 보면 Testing 상태의 100명 제한과 7일 refresh token 만료, external published 앱의 brand verification, sensitive scope 검토는 서로 다른 규칙이다. 이 글은 production 전환 전에 audience, brand, scope 검토를 어떤 순서로 나누는 편이 덜 꼬이는지 정리한 것이다.

1. 개요

결론부터 말하면 production 전환 전에 먼저 계속 Testing으로 남아도 되는지 판단하고, 그다음 audience 공개 여부를 정한 뒤, brand verification과 sensitive scope 검토를 분리해 보는 편이 맞다. brand는 공개 표시 정보의 신뢰 검토에 가깝고, sensitive scope는 어떤 데이터 접근이 필요한지에 대한 검토다.

따라서 refresh token 7일 만료나 test user 100명 제한이 불편하다고 바로 production으로 올리기보다, 앱이 실제로 외부 사용자에게 열릴 준비가 됐는지, 요청 범위가 과하지 않은지 먼저 점검해야 한다.

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

실무에서 흔한 실패는 세 가지다. 첫째, Testing 상태의 7일 refresh token 만료가 불편하다는 이유만으로 production 전환을 서두른다. 둘째, brand verification과 sensitive scope 검토를 같은 절차로 생각해 준비 순서를 섞는다. 셋째, scope를 충분히 줄이지 않은 채 production으로 올렸다가 사용자에게 unverified 경고를 보여 준다.

Google의 app state overview와 Manage App Audience 문서를 같이 보면 Testing은 최대 100명의 test user와 7일 refresh token 만료라는 뚜렷한 제약이 있지만, 그 대신 개발과 검증 단계에선 verification이 필수는 아니다. 반대로 In production은 any user with a Google Account 접근이 가능해지고, branding이나 scope에 따라 검토가 걸릴 수 있다. 여기서 실제로 해야 할 일은 OAuth consent screen을 열고 Publishing status를 확인하고, test user 목록을 확인하고, 현재 scope 목록을 다시 읽는 것이다.

또 brand verification 문서는 external + published + branding 표시 조건에서 검토가 필요할 수 있다고 설명하고, sensitive scope verification 문서는 개발·테스트 단계라면 Testing에 남아 separate project로 검증하라고 권한다. 즉 audience 공개, 브랜드 표시, 데이터 접근 범위는 서로 다른 질문이다. Console에서 audience를 바꾸기 전에 어떤 값을 입력했고 어떤 homepage와 privacy policy를 저장했고 어떤 scope를 추가 또는 제거했는지 기록해야 production 전환 뒤 혼선이 줄어든다.

증상: test user 100명 제한과 7일 refresh token 만료가 운영을 막는다.
실패: brand와 scope 검토를 같은 준비 목록으로 묶는다.
막힘: production 전환 직후 경고 UI를 팀이 예상하지 못한다.
누락: 테스트 프로젝트에서 최소 scope 검증을 먼저 하지 않는다.

막히는 지점	먼저 볼 문서 축	판단 기준
계속 Testing으로도 되는가	Audience	외부 공개와 100명 제한이 충돌하는지 본다
앱 이름과 로고를 공개로 보여야 하는가	Brand verification	external + published + branding 조건인지 본다
scope가 과한가	Sensitive scope verification	최소 scope로 줄일 수 있는지 본다

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

실무 적용 순서는 다섯 단계가 가장 단순하다. 먼저 Cloud Console에서 OAuth consent screen 화면을 열고 현재 Publishing status가 Testing인지 확인한다. 두 번째로 test user 목록을 클릭해 실제 운영 인원이 100명 제한 안에 들어오는지 확인한다. 세 번째로 외부 공개가 필요하다면 audience를 production으로 올릴 날짜를 정하고, homepage, privacy policy, app name, logo 입력값을 다시 확인하고 저장한다. 네 번째로 scope 목록을 열어 필요한 범위만 남기고 테스트 프로젝트에서 로그인과 refresh token 동작을 다시 실행한다. 마지막으로 production 전환 직후 예상되는 경고와 Submit for verification 제출 여부를 팀 문서에 기록한다.

OAuth consent screen을 열고 Publishing status를 확인한다.
test user 목록을 클릭해 실제 운영 인원과 비교한다.
homepage, privacy policy, app name, logo 입력값을 다시 확인하고 저장한다.
scope 목록을 열어 불필요한 범위를 제거하고 필요한 범위만 추가한다.
필요한 경우 Submit for verification 전에 테스트 프로젝트로 다시 로그인하고 결과를 기록한다.

전환 메모 예시

publishing_status=testing
external_users_needed=true
brand_assets_ready=true
scope_review_needed=true
test_project_scope_minimized=true
go_production_after_scope_review=false

이 순서대로 보면 Testing의 불편과 production 검토를 분리할 수 있다. 예를 들어 아직 민감 범위 검토가 끝나지 않았다면 production 전환 자체를 미루고 scope를 줄여 다시 로그인 테스트를 실행하는 편이 낫다. 반대로 scope는 기본 identity 수준인데 branding만 공개로 보여야 한다면 brand 입력값을 수정하고 verification 화면을 준비하는 쪽이 더 빠르다.

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

첫 자료는 OAuth app state overview의 비교표다. 여기서는 Testing, In production, user type, verification status에 따라 접근 가능 범위와 경고 UI가 어떻게 달라지는지 한 번에 정리한다.

Google은 OAuth app state overview에서 Testing과 In production 상태별 동작 차이를 표로 정리한다.

즉 production 전환은 버튼 하나의 문제가 아니다. 누가 접근할 수 있는지, 어떤 경고를 보게 되는지, 어떤 검증이 필요한지가 함께 바뀐다.

두 번째 자료는 Manage App Audience 도움말이다. 여기서는 Testing 상태가 최대 100명의 test user로 제한되고, offline access를 받을 경우 refresh token도 7일 뒤 만료된다고 적고 있다.

Google Cloud Console Help는 Testing 상태에서 100명 제한과 7일 refresh token 만료 규칙을 분명히 설명한다.

이 문장을 기준으로 보면 Testing은 개발과 검증용 경계다. 이미 refresh token 7일 만료 글이 증상을 다뤘다면, 이번 글은 그다음 질문인 production 전환 순서를 다룬다.

세 번째 자료는 brand verification 안내다. External user type에 Published 상태이고, consent screen에 로고나 display name을 보여 주려면 brand verification이 걸릴 수 있다고 설명한다.

$brand verification 문서는 external + published + branding 표시 여부가 검토 필요 조건이 될 수 있다고 설명한다.$

brand verification 문서는 external + published + branding 표시 여부가 검토 필요 조건이 될 수 있다고 설명한다.

여기서 중요한 점은 brand verification과 scope verification이 같은 절차가 아니라는 것이다. production 전환 전에 어떤 검증이 왜 필요한지를 분리해 적어 두지 않으면 불필요한 준비를 하거나, 반대로 scope 검토를 놓치기 쉽다.

실무에서는 Testing과 In production 전환 전 체크판이 필요하다. brand, scope, audience, token 만료가 한 화면에 없으면 팀 내에서 준비 순서가 자주 뒤섞인다.

Testing에서 In production으로 갈 때 audience, brand, scope를 나눠 보는 전환 표다.

이 표를 먼저 두면 redirect URI나 test user 증상을 다루는 기존 글과도 연결이 쉬워진다. 어떤 팀은 아직 Testing 유지가 맞고, 어떤 팀은 brand만 준비하면 되며, 어떤 팀은 scope 검토가 먼저라는 점이 분리된다.

마지막 자료는 production 전환 전 체크리스트다. audience, brand, scope를 한 줄로 적어 두면 누가 어떤 준비를 해야 하는지 훨씬 명확해진다.

Testing에서 production 전환 전 확인할 순서를 정리한 체크리스트다.

특히 consent screen 정보와 scope 설명, 홈페이지와 개인정보처리방침, test project 분리 같은 실무 항목을 함께 적어 두는 편이 좋다.

5. 주의사항과 리스크

첫 번째 리스크는 Testing 제약을 피하려고 너무 일찍 production으로 올리는 것이다. 두 번째는 brand verification만 끝나면 모든 검토가 끝난다고 오해하는 것이다. 세 번째는 scope 축소 없이 production으로 가 사용자에게 경고를 노출하는 것이다. 이때 자주 빠지는 행동 누락은 consent screen을 다시 열지 않고, scope 목록을 다시 확인하지 않고, test project 로그인 결과를 기록하지 않는 것이다.

운영 전에는 최소한 audience, brand, scope 세 축을 같은 체크리스트로 분리해 두는 편이 좋다. 그래야 redirect URI나 refresh token 만료처럼 개별 증상 글과 production 전환 판단 글이 서로 충돌하지 않는다. 팀 문서에는 누가 어떤 화면을 클릭했고 어떤 값을 입력했고 어떤 검토를 제출했는지까지 남겨 두는 편이 안전하다.

Testing의 불편과 production 공개 필요성을 같은 문제로 보지 않는다.
brand 검토와 scope 검토를 अलग 절차로 기록한다.
테스트 프로젝트에서 최소 scope를 먼저 검증한다.

6. 결론

Google OAuth 앱을 Testing에서 In production으로 올릴 때는 audience, brand, scope 검토를 분리해야 한다. 계속 Testing으로 남아도 되는지 먼저 판단하고, production 공개가 필요하다면 brand 준비와 scope 최소화를 각자 완료한 뒤 전환하는 편이 가장 안전하다.

관련 흐름으로는 Testing 상태 7일 refresh token 만료 글, redirect_uri_mismatch 점검 글을 같이 보면 개발 단계 증상과 production 전환 판단을 한 흐름으로 정리하기 쉽다.

전환까지 끝냈는데도 경고가 남는 경우에는 후속 글인 In production인데 unverified app 경고가 뜰 때 publishing status와 brand·scope 검토를 다시 나누는 글로 이어 가면 전환 전 준비와 전환 후 분기 대응을 한 사다리로 이어 보기 좋다.