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

이슈 발생: 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

로그인 성공은 “누가 어떤 권한을 위임했는가”를 증명한다. API 활성화는 “이 프로젝트가 해당 Google API를 호출하도록 허용되었는가”를 결정한다.

증상 분류

다음 오류는 겉보기에는 모두 403일 수 있지만 원인이 다르다.

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

따라서 HTTP 상태 코드만 보고 OAuth를 반복 승인하면 문제를 해결하지 못한다. 응답 본문의 reason, 서비스 이름, project number를 같이 확인해야 한다.

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

OAuth client를 만든 프로젝트와 Drive API를 활성화한 프로젝트가 같아야 한다. Google 계정에 여러 프로젝트가 있으면 콘솔 상단 프로젝트 선택기가 바뀌어 있는 경우가 흔하다.

점검 순서는 다음과 같다.

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까지 검증한다.

참고 자료

• Google Workspace API 활성화
• Google Drive API 오류 처리
• Google Drive API 인증과 권한