안녕하세요, まさきん입니다.
Google OAuth 게시 상태가 “테스트 중”이면 리프레시 토큰은 7일 만에 만료됩니다. 저도 건강 데이터를 가져오는 개인용 도구에서 이 기한을 알게 됐습니다. Gmail 제한된 범위 검토까지 포함해, 프로덕션으로 게시하는 절차를 공식 자료로 정리해 둡니다.
※글 작성 시점의 정보입니다. 최신 조건은 공식 사이트에서 확인해 주세요.
- 게시 상태가 “테스트 중”인 외부용 앱은 리프레시 토큰이 7일 만에 만료됩니다
- 개인 도구라도 “프로덕션”으로 게시하면 7일 기한이 적용되지 않습니다
- 게시하려면 홈페이지와 개인정보처리방침 URL이 필요합니다. 연락처 이메일만으로는 부족합니다
- 민감한 범위나 제한된 범위는 프로덕션이라도 검토 전에는 미확인 앱 경고가 뜹니다
- 6개월 미사용이나 토큰 개수 상한 등, 7일 외에도 만료되는 조건이 있습니다
7일 만에 만료되는 구조
결론부터 말하면, Google 공식 문서에 다음과 같은 취지의 내용이 있습니다.
외부 사용자용이면서 게시 상태가 “테스트 중”인 프로젝트. 여기서 발급된 리프레시 토큰은 7일 만에 만료됩니다.
예외도 있습니다. 요청하는 범위가 이름, 이메일 주소, 프로필뿐인 경우입니다. 구체적으로는 userinfo.email, userinfo.profile, openid 범위 안에 들어갈 때입니다. Google 로그인만 하는 앱이라면 7일 기한은 적용되지 않습니다.
반대로 말하면 Gmail이나 캘린더 데이터를 읽는 앱은 대상입니다. 건강 관련 데이터도 마찬가지입니다. 개인용 스크립트라도 사용자 유형이 외부라면 똑같이 취급됩니다.
”테스트 중”과 “프로덕션”의 차이
게시 상태는 Google Auth Platform의 “대상” 화면에서 확인할 수 있습니다. 예전의 “OAuth 동의 화면”에 해당하는 곳입니다. 두 상태의 차이를 정리하면 다음과 같습니다.
| 항목 | 테스트 중(Testing) | 프로덕션(In production) |
|---|---|---|
| 사용할 수 있는 사람 | 등록한 테스트 사용자만 | Google 계정이 있는 모든 사람 |
| 테스트 사용자 상한 | 최대 100명 | 없음 |
| 동의 유효 기간 | 동의 후 7일에 만료 | 7일 기한 없음 |
| 리프레시 토큰 | 7일에 만료 | 다른 만료 조건에 걸릴 때까지 유효 |
| 동의 전 경고 | 테스트 액세스 경고 표시 | 민감한 범위는 검토 전 경고 |
| 검토 | 대상 아님 | 범위에 따라 필요 |
테스트 중은 어디까지나 개발용 상태라는 위치입니다. 테스트 사용자로 추가한 사람만 동의할 수 있고, 그 동의도 7일이면 끝납니다.
반면 프로덕션은 누구나 동의할 수 있는 상태입니다. 매일 자동으로 돌리는 개인 도구라면 프로덕션 쪽이 운영에 더 맞을 수 있습니다.
제 도구에서 일어난 일
제 도구는 Google의 Health 계열 API를 쓰고 있었습니다. 프로젝트 게시 상태는 “테스트 중” 그대로였습니다.
그래서 갖고 있던 리프레시 토큰은 발급 후 7일이면 만료될 예정이었습니다. 만료되면 자동 가져오기가 멈춰 버립니다. 그래서 브랜딩 항목을 채우고 “프로덕션”으로 게시하기로 했습니다.
프로덕션으로 게시하는 절차
공식 도움말의 흐름과 제가 실제로 거친 순서를 정리합니다.
- Google Cloud 콘솔을 열고 화면 상단의 프로젝트 선택을 확인한다
- Google Auth Platform의 “브랜딩”을 연다
- 앱 이름과 사용자 지원 이메일을 확인한다
- 앱 홈페이지와 개인정보처리방침 URL을 입력한다
- 승인된 도메인에 해당 URL의 도메인을 추가한다
- 개발자 연락처 이메일을 입력하고 저장한다
- “대상” 화면에서 “앱 게시”를 누르고 확인 화면에서 진행한다
- 게시 상태가 “프로덕션”이 되었는지 확인한다
- 도구 쪽에서 다시 동의하고 리프레시 토큰을 새로 받는다
공식 도움말에서는 승인된 도메인을 먼저 등록하라고 안내합니다. 홈페이지 등의 URL보다 먼저 넣어 두면 되돌아가는 일이 줄어들 겁니다.
도중에 막혔던 두 가지
프로젝트를 착각하고 있었다
첫 번째로 막힌 곳은 사소한 부분이었습니다. 열어 둔 Google Cloud 콘솔이 다른 프로젝트였던 겁니다. 블로그 접속 분석용으로 만든 프로젝트였습니다.
Google Cloud 콘솔은 마지막으로 연 프로젝트를 기억합니다. 그래서 별생각 없이 열면 엉뚱한 곳에 있을 수 있습니다. 작업 전에 화면 상단의 프로젝트 이름을 한 번 본다. 이것만으로 막을 수 있는 일이었습니다.
개인적으로 프로젝트를 여러 개 갖고 있으면 이름이 비슷해지기 마련입니다. 용도를 알 수 있는 이름을 붙여 두는 것도 은근히 효과적인 대책일 수 있습니다.
연락처 이메일만으로는 게시할 수 없다
두 번째는 게시 버튼이 활성화되지 않았던 일입니다. 처음에는 연락처 이메일만 입력해 두었습니다.
게시하려면 앱 홈페이지와 개인정보처리방침 URL이 필요했습니다. 공식 도움말에도 외부용 프로덕션 앱에는 이 링크들이 필수라고 나와 있습니다. 링크가 빠져 있으면 검토를 신청할 수도 없다고 합니다.
게시에 필요했던 것
브랜딩 화면에서 요구하는 항목을 공식 도움말을 바탕으로 정리합니다.
| 항목 | 내용 | 공식 도움말상의 취급 |
|---|---|---|
| 앱 이름 | 동의 화면에 표시되는 이름 | Google 상표와 혼동되는 이름은 불가 |
| 사용자 지원 이메일 | 사용자 문의처 | 본인 주소 또는 본인이 관리하는 그룹 |
| 앱 홈페이지 | 앱을 설명하는 페이지 | 외부용 프로덕션 앱에서는 필수 |
| 개인정보처리방침 | 데이터 취급을 적은 페이지 | 외부용 프로덕션 앱에서는 필수 |
| 서비스 약관 | 앱의 약관 페이지 | 선택 |
| 승인된 도메인 | 위 URL들의 도메인 | URL을 넣기 전에 등록 |
| 개발자 연락처 | Google의 알림 수신처 | 최신 상태로 유지하라는 안내 있음 |
| 로고 | 동의 화면 아이콘 | 프로덕션에서는 검토 후 표시 |
로고는 선택입니다. 다만 외부용 프로덕션 앱에 로고를 올리면 검토가 필요해집니다. 개인 도구라면 비워 두는 쪽이 손이 덜 갈 거라고 생각합니다.
홈페이지와 방침 페이지로 무엇을 쓸까
저는 홈페이지와 개인정보처리방침에 제 블로그 페이지를 썼습니다. 승인된 도메인에는 otokuken.com을 추가했습니다.
공식 도움말에는 검토를 받을 때의 요건도 적혀 있습니다. 홈페이지는 본인이 소유한 확인된 도메인에 둘 것. 개인정보처리방침은 홈페이지와 같은 도메인에 두고, 홈페이지에서 링크할 것. 방침에는 Google 사용자 데이터를 어떻게 다루는지 적을 것 등입니다.
검토를 받지 않는다면 여기까지 엄격하지 않아도 게시는 가능할지 모릅니다. 하지만 나중에 검토가 필요해질 가능성도 있습니다. 처음부터 요건에 맞춰 두면 안심입니다.
범위에 따라 검토가 필요하다
프로덕션으로 게시해도 모든 게 자유로워지는 건 아닙니다. 핵심은 범위(scope)의 구분입니다.
| 범위 구분 | 검토 | 검토 전 동작 |
|---|---|---|
| 민감하지 않음 | 불필요(이름과 로고를 표시하려면 브랜드 검토) | 경고 없이 동의 가능 |
| 민감함 | 필요 | 미확인 앱 경고 표시 |
| 제한됨 | 필요. 추가로 연 1회 보안 평가 | 미확인 앱 경고 표시 |
구분은 Cloud 콘솔에서 범위를 추가할 때 자동으로 표시됩니다. 내 앱이 어디에 해당하는지는 거기서 확인할 수 있습니다.
한편 개인용 앱에는 예외가 있습니다. 공식 도움말에 따르면 사용자가 100명 미만인 개인용 앱은 검토 없이 계속 쓸 수 있습니다. 이 경우 사용자는 로그인할 때 미확인 앱 경고를 넘기고 진행하는 방식입니다.
미확인 앱 경고와 사용자 상한
검토 전에 민감한 범위를 요청하면 동의 화면 앞에 경고가 뜹니다. “Google에서 확인하지 않은 앱입니다”라는 취지의 화면입니다.
사용자 수 상한도 있습니다. 미확인 앱 화면을 띄우는 앱은 신규 사용자가 합계 100명까지입니다. 이 상한은 프로젝트 전체 기간에 적용되며 초기화할 수 없다고 적혀 있습니다.
혼자 쓰는 도구라면 이 상한이 문제될 일은 거의 없을 겁니다. 다만 가족이나 지인에게도 쓰게 할 생각이라면 인원수를 의식해 두는 게 좋겠습니다.
주기적으로 만료되거나 갱신이 필요한 것들을 정리하는 김에, 매달 나가는 통신비도 함께 다시 보면 어떨까요. 고정비 전체가 조금 가벼워질 수도 있습니다.
7일 외에 토큰이 만료되는 조건
프로덕션으로 바꿔도 리프레시 토큰이 영원하지는 않습니다. 공식 문서에 나온 만료 조건을 정리합니다.
| 조건 | 내용 |
|---|---|
| 사용자가 액세스를 취소함 | Google 계정 쪽에서 앱 연결을 해제한 경우 |
| 6개월간 사용하지 않음 | 리프레시 토큰을 6개월 동안 쓰지 않은 경우 |
| 비밀번호를 변경함 | Gmail 범위가 포함된 토큰인 경우 |
| 토큰 개수 상한 | 계정 1개·클라이언트 ID 1개당 최대 100개 |
| 시간 제한이 있는 허용 | 기간을 정해 허용했고 그 기간이 지난 경우 |
| 관리자 제한 | Workspace 관리자가 서비스를 제한한 경우 |
| 세션 제어 | Google Cloud 조직에서 세션 길이가 정해져 있는 경우 |
특히 조심할 것은 토큰 개수 상한입니다. 상한에 도달하면 가장 오래된 토큰이 경고 없이 무효화됩니다. 시험 삼아 여러 번 다시 동의하다 보면, 실제로 쓰던 토큰이 사라질 수도 있습니다.
전체 상한도 있어서, 공식 문서에서는 허용하는 클라이언트를 계정 1개당 15~20개 정도로 줄이는 우회책을 소개하고 있습니다.
토큰 다시 받기
프로덕션으로 게시했다면 다음은 토큰을 다시 받는 일입니다. 테스트 중에 받은 동의는 동의 후 7일이면 만료된다고 공식적으로 적혀 있습니다. 그래서 게시 후에 본인이 다시 동의하는 조작이 필요합니다.
저도 토큰은 아직 다시 받지 않았습니다. 도구의 인증 흐름을 돌려서 브라우저에서 다시 동의할 예정입니다.
새로 받았다면 옛 토큰은 쓰지 않도록 해 두는 게 좋겠습니다. 새 토큰으로 저장 위치를 덮어쓰고 옛 토큰은 지운다. 보관 장소가 여러 곳이면 어느 게 살아 있는지 모르게 될 수 있습니다.
흔한 실수와 함정
지금까지의 내용을 흔한 실수 형태로 정리해 둡니다.
| 실수 | 일어나는 일 | 예방법 |
|---|---|---|
| 다른 프로젝트에서 작업함 | 설정이 반영되지 않음 | 작업 전에 프로젝트 이름 확인 |
| URL 없이 게시하려 함 | 게시 버튼을 누를 수 없음 | 홈페이지와 방침 페이지를 먼저 준비 |
| 승인된 도메인을 뒤로 미룸 | URL 등록 단계에서 막힘 | 도메인을 먼저 추가 |
| 게시만 하고 안심함 | 옛 토큰이 7일 만에 만료 | 게시 후 동의를 다시 받기 |
| 여러 번 다시 동의함 | 옛 토큰이 경고 없이 무효화 | 다시 받기는 필요할 때만 |
| 반년 동안 돌리지 않음 | 토큰이 만료됨 | 정기적으로 동작하는 구조로 만들기 |
개인 도구는 멈춰도 아무도 알려 주지 않습니다. 그러니 만료됐을 때 에러로 알아챌 수 있게 만들어 두는 것도 중요하다고 생각합니다.
무료 한도에 걸려 멈춘 이야기는 Cloudflare Workers 무료 플랜의 Cron Triggers 상한에 걸렸을 때의 대처법에도 정리해 두었습니다. 개인 자동화는 이렇게 “조용히 멈추는” 부분이 가장 큰 약점일지도 모릅니다.
시작하기 전에 확인할 것
- 콘솔에서 열려 있는 것이 목적한 프로젝트인가
- 사용자 유형이 외부인가 내부인가
- 현재 게시 상태가 테스트 중인가 프로덕션인가
- 사용 중인 범위가 민감하지 않음·민감함·제한됨 중 어디에 해당하는가
- 홈페이지와 개인정보처리방침 URL을 준비할 수 있는가
- 그 URL의 도메인을 승인된 도메인에 추가했는가
- 개발자 연락처 이메일이 최신인가
- 게시 후 동의를 다시 받을 시간을 낼 수 있는가
테스트 중에 받은 동의는 동의 후 7일이면 만료된다고 공식적으로 나와 있습니다. 프로덕션으로 게시해도 연장되지 않는다고 생각하는 편이 안전합니다. 게시 후에는 다시 동의해서 토큰을 새로 받아 주세요.
자동화의 전체 그림은 아침 준비하는 동안 AI에게 한 장짜리 ‘오늘의 브리핑’을 만들게 하는 이야기에도 썼습니다. 이런 구조도 뒤에서는 토큰이 받쳐 주고 있는 셈입니다.
자주 묻는 질문
Q. 테스트 중인 채로 두면 토큰은 얼마 만에 만료되나요?
외부 사용자용이면서 테스트 중인 프로젝트에서는 7일 만에 만료됩니다. 동의한 시점부터 7일입니다. 이름·이메일·프로필 범위만 쓴다면 이 기한은 적용되지 않습니다.
Q. 개인적으로만 써도 프로덕션으로 게시해도 되나요?
게시할 수 있습니다. 공식 도움말에서도 사용자가 100명 미만인 개인용 앱은 검토 없이 계속 쓸 수 있다고 합니다. 다만 민감한 범위에서는 미확인 앱 경고가 뜹니다.
Q. 게시 버튼이 눌리지 않는 이유는 무엇인가요?
브랜딩의 필수 항목이 빠져 있을 가능성이 있습니다. 외부용 프로덕션 앱에는 홈페이지와 개인정보처리방침 URL이 필요합니다. 승인된 도메인 등록도 확인해 주세요.
Q. 게시하면 지금 토큰을 그대로 쓸 수 있나요?
테스트 중에 받은 동의는 동의 후 7일이면 만료된다고 공식적으로 나와 있습니다. 그러니 게시 후에 다시 동의해서 토큰을 새로 받는 것이 확실합니다. 다시 받으려면 본인의 조작이 필요합니다.
Q. 검토는 반드시 받아야 하나요?
민감한 범위나 제한된 범위를 일반 사용자 대상으로 쓴다면 검토가 필요합니다. 개인용이고 100명 미만이라면 검토 없이 계속 쓸 수 있는 예외가 있습니다. 제한된 범위는 연 1회 보안 평가도 요구됩니다.
Q. 테스트 사용자는 몇 명까지 등록할 수 있나요?
테스트 중인 프로젝트에서 테스트 사용자는 최대 100명입니다. 한 번 추가하면 그 인원만큼 자리를 쓰는 것으로 취급됩니다.
Q. 프로덕션이면 토큰을 계속 쓸 수 있나요?
계속은 아닙니다. 6개월 동안 쓰지 않았거나 사용자가 액세스를 취소했을 때 만료됩니다. 계정 1개·클라이언트 ID 1개당 100개라는 상한도 있습니다.
Q. 로고나 앱 이름은 동의 화면에 표시되나요?
앱 이름이나 로고를 표시하려면 검토가 필요하다고 공식 도움말에 나와 있습니다. 검토 전에는 앱의 도메인이 표시되는 형태입니다. 개인 도구라면 로고를 올리지 않는 쪽이 손이 덜 갈 수 있습니다.
참고한 공식 자료
- OAuth 2.0을 사용하여 Google API에 액세스(Google for Developers)
- Manage App Audience(Google Cloud 도움말)
- Manage OAuth App Branding(Google Cloud 도움말)
- Get started with the Google Auth Platform(Google Cloud 도움말)
- OAuth App Verification Help Center(Google Cloud 도움말)
- Verification requirements(Google Cloud 도움말)
- When is verification not needed(Google Cloud 도움말)
- Unverified apps(Google Cloud 도움말)
- Google API용 OAuth 2.0 범위(Google for Developers)
- Google API 서비스 사용자 데이터 정책
마무리
리프레시 토큰이 7일 만에 만료되는 원인은 게시 상태의 “테스트 중”이었습니다. 개인 도구라도 프로덕션으로 게시하면 이 기한은 사라집니다.
필요했던 것은 홈페이지와 개인정보처리방침 URL, 그리고 승인된 도메인 등록이었습니다. 그 밖에는 프로젝트를 착각하지 않도록 주의하는 것. 저는 이제 토큰을 다시 받는 단계로 넘어갑니다.
자동으로 돌아가는 구조가 있다면, 한 번쯤 게시 상태만이라도 확인해 보세요.
이 글에는 제휴 광고가 포함되어 있습니다. 이 사이트의 링크를 통해 상품·서비스에 신청하시면 제휴사로부터 보상을 받을 수 있습니다. 또한 운영자는 라쿠텐 그룹 소속 직원으로, 사원 추천 프로그램을 통해 보상을 받는 경우가 있습니다. 기사 내용과 평가는 광고 유무와 관계없이 운영자의 실제 경험과 조사를 바탕으로 작성했지만, 위 관계를 이해하신 후 읽어 주시기 바랍니다. 자세한 내용은 면책조항·제휴 링크 안내를 참고해 주세요. 면책조항·제휴 링크 안내
이 글에는 기계 번역이 포함되어 있습니다. 정확한 조건은 라쿠텐 모바일 공식 사이트의 다국어 페이지에서 확인해 주세요.
라쿠텐 모바일의 통신 지역·전파 상황이 궁금하신 분은, 공식 전파 개선·조사 요청 양식 을 통해 문의하실 수 있습니다.
