Troubleshooting 2026.08.10 4 min read

OAuth는 성공했는데 Drive API가 거절한 이유

Google 로그인과 token 발급은 성공했지만 Drive API 접근이 실패했다. client가 속한 프로젝트의 API 활성화부터 Kubernetes 백업 Job까지 확인했다.

이슈 발생: 2026-08-09 · 발행 기준: 2026-08-10 15:14 KST
환경: Google Cloud, OAuth 2.0, Google Drive API, rclone

Google 로그인과 rclone의 token 발급을 마쳤는데 Drive 접근이 실패했다. 이런 경우 오류에 accessNotConfigured, SERVICE_DISABLED, 또는 “API has not been used in project or it is disabled”와 비슷한 문장이 표시될 수 있다.

확인해 보니 OAuth 인증과 Google Drive API 활성화는 별도로 확인해야 하는 설정이었다.

사용자 인증 및 동의 성공
  → OAuth token 발급
  → Drive API 요청
  → 프로젝트에서 drive.googleapis.com 비활성
  → accessNotConfigured

로그인으로 사용자 인증과 권한 동의를 마쳐도 해당 프로젝트에서 Drive API를 호출할 수 있는지는 따로 확인해야 했다.

증상 분류

403 응답이라도 세부 원인에 따라 확인할 설정이 달랐다.

  • accessNotConfigured / SERVICE_DISABLED: API 자체가 비활성화됐거나 다른 프로젝트에서 활성화함
  • insufficientPermissions: 요청한 OAuth scope가 부족함
  • rateLimitExceeded: quota 또는 요청률 문제
  • invalid_grant: refresh token 만료·폐기·시간 오차 등 인증 문제

OAuth를 다시 승인하기 전에 응답 본문의 reason, 서비스 이름과 project number를 확인했다. 인증, scope, API 활성화와 quota 중 어느 쪽 문제인지 먼저 나누기 위해서다.

어떤 프로젝트에서 API를 켜야 하는가

OAuth client가 속한 프로젝트에서 Drive API를 활성화해야 한다. 다른 프로젝트에서 API를 켜는 실수를 피하려고 콘솔 상단의 현재 프로젝트도 함께 확인했다.

점검 순서는 다음과 같다.

  1. rclone 설정의 client ID가 어떤 Google Cloud 프로젝트 소속인지 확인한다.
  2. 오류 메시지에 나온 project number를 확인한다.
  3. 해당 프로젝트에서 Google Drive API 상태를 확인한다.
  4. 다른 프로젝트에 잘못 활성화한 것은 아닌지 비교한다.

CLI를 쓸 수 있는 환경이라면 다음처럼 확인할 수 있다.

gcloud services list --enabled \
  --project=<project-id> \
  --filter='config.name:drive.googleapis.com'

활성화 명령은 프로젝트 상태를 바꾸므로 올바른 프로젝트인지 다시 확인한 뒤 실행한다.

gcloud services enable drive.googleapis.com \
  --project=<project-id>

콘솔에서는 APIs & Services → Library → Google Drive API → Enable 순서로 처리할 수 있다.

활성화 직후에도 실패할 수 있다

API 활성화 직후에는 반영을 기다린 뒤 목록 조회부터 확인했다. token을 계속 새로 발급하면 설정 반영 문제와 인증 문제를 구분하기 어려워진다.

rclone lsd gdrive:

목록 조회가 성공한 뒤 작은 테스트 파일 업로드, restic repository 접근, 실제 백업 Job 순서로 확인 범위를 넓혔다.

rclone about gdrive:
restic -r rclone:gdrive:<repository-path> snapshots

명령 출력에는 원격 경로와 계정 정보가 포함될 수 있으므로 공개 로그에 그대로 올리지 않는다.

Kubernetes Job까지 검증하기

로컬 rclone이 성공해도 Kubernetes Secret이 예전 client/token을 담고 있으면 실제 백업은 계속 실패한다.

kubectl -n backup get cronjob <backup-cronjob> -o yaml
kubectl -n backup get secret <rclone-secret>
kubectl -n backup create job \
  --from=cronjob/<backup-cronjob> <drive-api-validation-job>
kubectl -n backup logs -f job/<drive-api-validation-job> --all-containers

확인할 것은 다음과 같다.

  • Job이 새 Secret을 참조하는가?
  • container 안의 설정 경로가 예상과 같은가?
  • accessNotConfigured가 사라졌는가?
  • 업로드 후 snapshot이 원격에 존재하는가?
  • 실제 restore가 가능한가?

이번 문제에서 얻은 진단 규칙

이후 Google API 오류를 확인할 때는 아래 순서로 나눠 보기로 했다.

1. 인증: token을 받을 수 있는가?
2. API 활성화: 해당 프로젝트에서 서비스가 Enabled인가?
3. 권한: scope가 요청 작업을 허용하는가?
4. 할당량: quota와 rate limit 안에 있는가?
5. 애플리케이션: 실제 Job이 새 설정을 사용하는가?

어느 단계가 실패했는지 먼저 확인하면 OAuth client 생성이나 token 재발급을 불필요하게 반복하지 않아도 된다.

재발 방지

  • 인프라 문서에 project와 사용 API 목록을 기록한다.
  • OAuth client 생성 체크리스트에 Drive API 활성화를 포함한다.
  • 오류 로그에서 HTTP 코드와 reason을 함께 수집한다.
  • client/token 교체 후 로컬 테스트와 Kubernetes Job 테스트를 따로 한다.
  • 백업 성공 뒤 원격 snapshot과 restore까지 검증한다.

참고 자료

SEARCH JOURNAL

기록 검색

글 제목, 요약, 태그에서 찾습니다.

검색을 준비하고 있어요.

검색어를 입력해 주세요.

    Ctrl/⌘ K 검색 Esc 닫기 ↑ ↓ 결과 이동