[Google OAuth][인증] Testing 상태에서 refresh token이 7일 만에 끊길 때 test users와 production 전환을 어떤 순서로 나누나

IT 리서치 노트

[Google OAuth][인증] Testing 상태에서 refresh token이 7일 만에 끊길 때 test users와 production 전환을 어떤 순서로 나누나

Google OAuth를 붙였는데 로그인은 되지만 refresh token이 일주일쯤 지나면 다시 끊기는 경우가 있다. 2026년 7월 17일 기준 Google 공식 문서를 다시 보면 External user type에 Publishing status가 Testing인 프로젝트는 특정 조건에서 7일짜리 refresh token을 받는다. 이 글은 이 문제가 토큰 저장 로직인지 앱 상태 문제인지, test users와 production 전환을 어떤 순서로 나눠야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 정확히 7일 전후로 refresh token이 끊기면 저장소보다 앱 상태를 먼저 봐야 한다. External + Testing이면 7일 만료 규칙이 적용될 수 있고, 테스트 사용자 allowlist와 스코프 범위에 따라 접근 범위도 달라진다.

따라서 개발용 앱인지, 공개 운영 앱인지, 자사 Workspace 전용인지 먼저 결정해야 한다. 이 구분을 안 하면 토큰 재발급 코드를 고쳐도 같은 문제가 반복된다.

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

실무에서 흔한 실패는 세 가지다. 첫째, refresh token 만료를 캐시 저장 버그로만 보고 앱 상태를 안 본다. 둘째, 테스트 사용자 allowlist와 실제 사용자 범위를 섞는다. 셋째, redirect URI 문제를 해결한 뒤에도 consent screen 상태를 그대로 둔 채 장기 운영을 시작한다.

Google 기본 OAuth 문서는 External user type에 Publishing status가 Testing이면 refresh token이 7일 만에 만료될 수 있다고 직접 적고 있다. production readiness overview는 Testing External, Published External, Internal의 동작 차이를 표로 정리하고, Testing External은 테스트 사용자 100명 cap과 함께 설명한다.

• 증상: 로그인은 되는데 7일쯤 지나면 refresh token이 끊긴다.
• 실패: 토큰 저장 로직만 의심하고 앱 상태를 확인하지 않는다.
• 막힘: 테스트 사용자 범위와 실제 운영 사용자 범위를 섞는다.
• 누락: consent screen 상태와 스코프를 같은 로그에 안 남긴다.

증상	먼저 볼 값	판단 기준
정확히 7일 전후 만료	Publishing status	Testing External인지 확인
특정 계정만 접근 가능	Test users allowlist	테스트 사용자 등록 여부 확인
외부 공개 운영 예정	Published External 전환	검증과 브랜딩 설정 준비

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

실무 순서는 다섯 단계면 충분하다. 먼저 OAuth consent screen에서 User type과 Publishing status를 확인한다. 두 번째로 테스트 사용자 allowlist를 본다. 세 번째로 scope가 기본 identity 범위만인지 확인한다. 네 번째로 실제 서비스 범위가 자사 Workspace 전용인지, 외부 공개인지 결정한다. 마지막으로 공개 운영이라면 Published 전환과 검증 일정을 별도 작업으로 잡는다.

1. User type과 Publishing status를 먼저 확인한다.
2. 테스트 사용자 allowlist를 점검한다.
3. 요청 스코프가 무엇인지 기록한다.
4. Internal 전용인지 Published External인지 제품 범위를 정한다.
5. 그다음 토큰 저장 로직을 재검증한다.

이 순서가 중요한 이유는 상태 규칙과 코드 버그를 섞지 않기 위해서다. 정확히 7일 전후라면 상태 규칙 신호가 강하고, 무작위 시점이라면 저장 로직이나 사용자 토큰 회전 로직 쪽을 더 의심할 수 있다. 먼저 분류해야 원인 추적이 짧아진다.

if user_type == "external" and publishing_status == "testing":
    check_test_user_allowlist()
    check_requested_scopes()
    expect_refresh_token_window("7 days")
else:
    inspect_storage_and_rotation_logic()

이 정도 기준만 있어도 디버깅 방향이 훨씬 빨리 갈린다. 특히 개발자가 이미 redirect_uri_mismatch를 해결한 뒤에는 클라이언트 값 자체보다 앱 상태와 사용자 범위가 남은 핵심 분기가 되는 경우가 많다. 운영 시작 직전에 이 표와 로그 블록을 같이 남겨 두면 나중에 토큰 장애가 재현돼도 다시 처음부터 추측하지 않아도 된다.

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

첫 자료는 Google OAuth 기본 문서의 핵심 문장이다. External user type에 Publishing status가 Testing이면 refresh token이 7일 만에 만료될 수 있다는 조건이 여기서 직접 나온다.

Google OAuth 기본 문서는 External + Testing 상태일 때 refresh token이 7일 만에 만료될 수 있다고 설명한다.

즉 토큰 저장 로직만 의심할 일이 아니다. 특히 개발 중인데 정확히 일주일 전후로 끊기면 앱 상태부터 다시 봐야 한다.

두 번째 자료는 Google OAuth app state overview의 비교표다. 여기서는 Testing External이 테스트 사용자 100명 제한과 함께 동작하고, Internal과 Published External이 어떻게 다른지 한 화면에서 볼 수 있다.

Google OAuth 상태 비교표는 Internal, Testing External, Published External의 접근 범위와 제한을 나눠 보여 준다.

이 표를 보면 문제를 두 갈래로 분리할 수 있다. 지금 필요한 게 단순 개발용 allowlist인지, 아니면 실제 장기 refresh token이 필요한 공개 운영 상태인지를 먼저 정해야 한다.

세 번째 자료는 OAuth consent screen 구성 문서다. Google은 이 화면이 사용자와 앱 검토자에게 보이는 정보와 이후 publish를 위한 등록 지점이라고 설명한다.

OAuth consent screen 구성 문서는 사용자에게 보이는 정보와 향후 publish 준비가 이 설정에서 시작된다고 설명한다.

그래서 redirect URI가 맞아도 테스트 상태와 브랜딩 설정이 운영 요구를 못 따라가면 다시 막히게 된다. 인증 에러는 클라이언트 값만의 문제가 아니다.

실무에서는 Testing에 머물지, Published로 올릴지, Internal로 바꿀지를 한 표로 보는 편이 빠르다. 사용자 범위와 refresh token 수명, 검증 필요성이 한 번에 보이기 때문이다.

앱 상태를 Testing External, Published External, Internal로 나눠 읽는 결정표다.

이미 redirect_uri_mismatch 글이 문자열 일치 문제를 다뤘다면, 이번 표는 그 다음 단계인 앱 상태 분기다.

실제 장애 처리에서는 토큰 저장소보다 앱 상태와 테스트 사용자 범위를 먼저 점검하는 편이 빠르다. 일주일 주기로 끊기는 패턴은 보통 만료 정책 힌트가 더 강하기 때문이다.

refresh token 7일 만료가 의심될 때 확인 순서를 정리한 체크리스트다.

이 순서가 있으면 브라우저 쿠키나 서버 캐시를 며칠씩 뒤지기 전에 상태 문제를 자를 수 있다. 또 Notion internal connection과 public OAuth 글처럼 공개형과 내부형을 먼저 가르는 감각과도 통한다.

마지막 자료는 운영 로그 예시다. 사용자 범위, 앱 상태, 스코프를 같이 남겨야 나중에 왜 어떤 계정만 끊겼는지 설명할 수 있다.

토큰 만료 이슈를 재현할 때 남겨야 할 최소 로그 예시다.

이 정도만 남겨도 redirect URI 문제인지 앱 상태 문제인지가 훨씬 빨리 분리된다.

5. 주의사항과 리스크

첫 번째 리스크는 개발 중 Testing External을 그대로 두고 운영까지 밀어붙이는 것이다. 두 번째는 test user allowlist와 실제 고객 범위를 혼동하는 것이다. 세 번째는 Internal로 두면 편하다고 생각하지만 외부 고객까지 로그인해야 하는 제품에 그대로 적용하는 것이다.

또 Google Workspace 환경에서는 관리자 Trusted 상태가 일부 제한을 덮어쓸 수 있지만, 그건 특정 조직 사용자에게만 적용되는 예외적 경로다. 공개 서비스 전체 기준의 해결책으로 일반화하면 안 된다.

• 정확히 7일 패턴이면 앱 상태부터 본다.
• 테스트용과 운영용 사용자 범위를 먼저 가른다.
• Internal, Testing External, Published External을 제품 범위에 맞춰 선택한다.

6. 결론

Google OAuth에서 refresh token이 7일 만에 끊길 때는 토큰 저장소보다 앱 상태를 먼저 보는 편이 맞다. External + Testing, test users allowlist, 스코프 범위, 제품의 실제 사용자 범위를 순서대로 자르면 원인이 훨씬 빨리 좁혀진다.

관련 흐름으로는 redirect_uri_mismatch 글과 internal connection과 public OAuth 분기 글을 같이 보면 문자열 일치 문제와 앱 상태 문제를 더 분명하게 나눌 수 있다.

Testing에서 production 전환 직전 체크리스트까지 이어서 보려면 brand verification과 sensitive scope 검토 순서 글을 같이 보면 된다. test users 범위와 심사 준비를 같은 타임라인으로 묶기 좋다.

7. 참고 링크

1. https://developers.google.com/identity/protocols/oauth2
2. https://developers.google.com/identity/protocols/oauth2/production-readiness/overview
3. https://developers.google.com/workspace/guides/configure-oauth-consent