Gemini CLI 인증 오류: GOOGLE_CLOUD_PROJECT·종료 코드 41

Gemini CLI 인증이 막히면 빨간 한 줄이 나오는데, 문구만 봐서는 내 설정이 틀린 건지 계정이 막힌 건지 잘 안 갈립니다. gemini -p로 인증을 비워 보고, 가짜 키를 넣어 보고, 빈 폴더에서도 돌려 보니 문구보다 종료 코드가 막힌 자리를 훨씬 정확하게 알려 주더라고요.

인증 설정이 하나도 없으면 41로 끝났고, 키를 넣은 뒤에야 55에서 멈췄습니다. 실재하지 않는 키는 1이었고요.

41이면 GEMINI_API_KEY 같은 환경 변수나 ~/.gemini/settings.json을 채우면 되고, 1이면 서버가 키나 계정을 거부한 것이니 키 값과 계정 자격을 봐야 하고, 55면 인증이 아니라 폴더 신뢰 문제라 --skip-trust로 넘어갑니다.

검색으로 많이 찾는 This account requires setting the GOOGLE_CLOUD_PROJECT 오류는 회사·Workspace 계정이나 Code Assist 라이선스라면 프로젝트 ID를 넣어 풀고, 개인 계정에서 조직 구독 오류가 난다면 반대로 그 변수를 지웁니다.

변수를 만지기 전에 계정부터 확인하세요. 2026년 6월 18일부터 Gemini CLI는 무료로 쓰는 사용자와 Google AI Pro·Ultra 구독자의 요청을 처리하지 않습니다(메인테이너 Dmitry Lyalin, 2026년 5월 19일 공식 저장소 토론 글).

조직의 Gemini Code Assist Standard·Enterprise 라이선스나 Google Cloud, 유료 Gemini API 키와 Gemini Enterprise Agent Platform API 키는 계속 쓸 수 있어요.

개인 무료·AI Pro·Ultra 계정이라면 아래 변수를 고쳐서 풀리는 문제가 아닐 수 있으니 Windows에서 Antigravity CLI(agy)를 설치하고 Gemini CLI 설정·GEMINI.md를 옮기는 순서부터 보세요.

이 중단이 어떤 오류 문구로 나타나는지는 공지에 없고 직접 확인하지도 않았습니다. 저장소의 인증·할당량 문서는 2026년 9월 28일에도 무료 등급과 AI Pro·Ultra 이용을 안내하고 있어 공지와 어긋납니다.

종료 코드와 오류 출력은 2026년 9월 21일 Ubuntu 24.04 LTS · Node.js 22 · Gemini CLI 0.60.0 테스트 환경에서 직접 확인했고, 공식 저장소 문서도 같은 날 다시 봤습니다. 실제 Google 계정 로그인은 하지 않았기 때문에, 로그인 화면 뒤에서만 보이는 오류는 공개 이슈를 인용했습니다. 인증 방식을 고르는 기준은 Gemini CLI 설치와 인증 방식 고르기에 있어요.

종료 코드부터 보세요

오류 문구는 다 비슷한 빨간 한 줄이지만, 종료 코드는 막힌 자리를 정확히 나눠 줍니다. gemini -p로 실행하면 인증은 세 자리를 차례로 지나고, 멈춘 자리마다 코드가 달라요. 실패한 명령을 다시 실행하고 바로 Linux·macOS는 echo $?, PowerShell은 $LASTEXITCODE로 확인하면 됩니다.

종료 코드	뜻	볼 곳
41	인증 설정을 못 찾음	settings.json, 인증 환경 변수
55	폴더가 신뢰되지 않음	--skip-trust
1	서버가 자격 증명 거부	키 값, 계정 자격, 권한

직접 해 보니 인증 설정이 하나도 없으면 폴더 신뢰와 관계없이 41로 끝났고, 키를 넣은 뒤에야 55에서 멈췄습니다.

공식 문서 두 곳의 종료 코드 목록은 서로 다릅니다. 문제 해결 문서는 41(FatalAuthenticationError)·42·44·52·53을, 비대화형 모드 문서는 0·1·42·53만 실어요.

gemini -p도 실제로 41로 끝나니, 목록에 없는 코드가 나왔다고 이상한 일은 아닙니다. 거꾸로 41도 1도 아니라고 해서 인증 문제가 아니라고 단정할 수도 없어요. 목록에 없는 55도 실제로 나오거든요.

저는 종료 코드로 먼저 나누고, 최종 판단은 메시지 본문과 reason·service로 합니다.

41: 인증 설정을 못 찾았을 때

41이 나는 경우는 세 가지였습니다.

인증을 아무것도 정하지 않았을 때

메시지에 고를 값 세 개와 설정 파일 위치가 다 있습니다.

$ gemini -p "hello"
Please set an Auth method in your ~/.gemini/settings.json or specify one of the following environment variables before running: GEMINI_API_KEY, GOOGLE_GENAI_USE_VERTEXAI, GOOGLE_GENAI_USE_GCA

Vertex AI를 골랐는데 값이 모자랄 때

GOOGLE_CLOUD_PROJECT와 GOOGLE_CLOUD_LOCATION을 함께 넣거나, 익스프레스 모드라면 GOOGLE_API_KEY를 넣습니다. 공식 문서는 프로젝트와 위치만 말하는데, 메시지는 익스프레스 모드라는 선택지를 하나 더 보여 줘요.

$ GOOGLE_GENAI_USE_VERTEXAI=true gemini -p "hello"
When using Vertex AI, you must specify either:
• GOOGLE_CLOUD_PROJECT and GOOGLE_CLOUD_LOCATION environment variables.
• GOOGLE_API_KEY environment variable (if using express mode).
Update your environment and try again (no reload needed if using .env)!

브라우저가 없는 환경에서 Google 로그인을 골랐을 때

이건 설정이 틀린 게 아니라, 그 환경에서는 Google 로그인을 쓸 수 없다는 뜻입니다.

$ GOOGLE_GENAI_USE_GCA=true gemini -p "hello"
Error authenticating: FatalAuthenticationError: Manual authorization is required but the current session is non-interactive. Please run the Gemini CLI in an interactive terminal to log in, provide a GEMINI_API_KEY, or ensure Application Default Credentials are configured.

Google 로그인은 터미널과 통신할 수 있는 브라우저가 필요하고, 비대화형 실행은 캐시된 자격 증명이 없으면 환경 변수로 인증해야 합니다. CI나 원격 셸이라면 로그인을 다시 시도하지 말고 API 키나 Vertex AI로 바꾸세요. Vertex AI라면 서비스 계정 JSON 키가 CI/CD에 맞는 방식으로 안내돼 있습니다.

GOOGLE_CLOUD_PROJECT, 넣을까 지울까

같은 변수가 계정 종류에 따라 정반대로 작동합니다. 여기가 이 글에서 제일 헷갈리는 부분이에요.

계정·상황	이 변수를
개인 Google 계정	대부분 불필요. 있으면 지우고 재시도
회사·학교·Workspace 계정	프로젝트 ID로 설정
Code Assist 라이선스·구독	프로젝트 ID로 설정
Vertex AI	GOOGLE_CLOUD_LOCATION과 함께 설정

개인 계정 쪽에는 한정어가 붙어 있습니다. 공식 인증 문서는 “대부분의” 개인 계정에 Cloud 프로젝트가 필요 없다고 하고, 표에도 예외를 표시해 둬요. 개인 계정이라고 무조건 필요 없는 건 아닙니다.

개인 계정에서 지우라는 데는 이유가 있습니다. 이 변수가 정의돼 있으면 조직 구독 확인이 강제되니까, 개인 계정으로 쓰면서 남겨 두면 필요 없는 확인에 걸려 막힐 수 있어요.

늘 그런 건 아니지만 가장 먼저 볼 자리입니다. 지울 때 놓치기 쉬운 게 있어요.

• 이름이 둘입니다. CLI는 GOOGLE_CLOUD_PROJECT를 먼저 보고 없으면 GOOGLE_CLOUD_PROJECT_ID를 봅니다. 앞의 것만 지우면 효과가 없어요.
• 셸 밖에서도 들어옵니다. .bashrc·.zshrc와 .env까지 보세요. Gemini CLI는 현재 폴더에서 위로 올라가며 찾은 첫 번째 .env 하나만 읽으므로, 프로젝트의 .env가 홈 쪽 설정을 통째로 가릴 수 있습니다.

키를 바꿨는데 이전 오류가 그대로 나올 때도 이 두 가지를 먼저 의심하면 됩니다. 값이 여러 곳에 있을 수 있거든요.

This account requires setting the GOOGLE_CLOUD_PROJECT or GOOGLE_CLOUD_PROJECT_ID env var

로그인 직후 이 메시지가 나오면 프로젝트를 넣어야 하는 쪽입니다. Gemini CLI 소스 packages/core/src/code_assist/setup.ts(2026년 10월 1일 확인)를 보면, 로그인한 계정이 쓸 Google Cloud 프로젝트를 서버가 돌려주지 않았는데 두 변수도 비어 있을 때 이 오류가 납니다. 서버가 그 계정이 쓸 수 없는 등급 목록을 함께 돌려준 경우에는 등급 목록을 알리는 다른 오류가 나고요.

회사·학교·Workspace 계정이나 Code Assist 라이선스라면 프로젝트 ID를 넣고 다시 로그인하세요.

다른 사람들이 로그인에서 막힌 곳

실제 Google 계정으로 로그인해야 보이는 오류라서, 공식 문제 해결 문서와 작성자·날짜가 확인되는 공개 이슈를 정리했습니다. 대부분은 계정·라이선스·네트워크 쪽 문제이고, CLI 설정으로 풀리는 건 첫 두 개뿐이에요.

오류 문구	원인 쪽	먼저 할 일
You must be a named user on …	남은 프로젝트 변수	변수 지우기
Request contains an invalid argument	무료 등급 활성화 실패	프로젝트 ID 넣기
You do not have a valid license …	라이선스	관리자에게 확인
… not currently available in your location	지역	지원 지역 확인
unable to get local issuer certificate	사내 인증서	NODE_USE_SYSTEM_CA=1

You must be a named user on your organization’s Gemini Code Assist Standard edition subscription

liucf1224-del은 무료로 쓰다가 자동 업그레이드 뒤부터 이 403이 났다고 보고했고, 함께 올린 클라이언트 정보에는 CLI 0.15.3, win32, OAuth와 함께 Google Cloud 프로젝트 값이 채워져 있었습니다(2025-11-17, 이슈 #13190, “계획 없음”으로 닫힘).

공식 문서가 드는 원인은 프로젝트 변수 때문에 강제된 조직 구독 확인입니다. 이슈의 정보가 그 조건과 겹치지만 이슈 안에서 확정되지는 않았어요.

개인 사용자라면 GOOGLE_CLOUD_PROJECT와 GOOGLE_CLOUD_PROJECT_ID를 모두 해제하고 셸 설정 파일과 .env에서도 지우세요. 그래도 안 되면 다른 Google 계정으로 시도합니다. 조직 사용자라면 Google Cloud 관리자에게 구독에 추가해 달라고 요청하면 됩니다.

Failed to sign in. Message: Request contains an invalid argument

philontos는 브라우저 로그인은 성공했는데 터미널로 돌아와 Failed to login. Ensure your Google account is not a Workspace account. Message: Request contains an invalid argument.로 실패했다고 보고했습니다(2025-06-30, 이슈 #2634, 중복으로 닫힘).

공식 문서에는 Failed to sign in.으로 시작하는 문구로 실려 있어요.

원인은 Workspace 계정이나 Gmail에 연결된 Google Cloud 계정이 Code Assist 무료 등급을 활성화하지 못하는 경우가 있기 때문입니다. 모든 Workspace 계정이 그렇다는 뜻은 아닙니다.

Google Cloud 계정이라면 GOOGLE_CLOUD_PROJECT에 프로젝트 ID를 넣거나, Google AI Studio의 Gemini API 키로 바꾸세요. 문서는 API 키에도 무료 등급이 있다고 하지만 공지가 계속 쓸 수 있다고 밝힌 건 유료 키입니다.

앞 항목과 방향이 정반대라는 점도 기억해 두세요. 이쪽은 변수를 넣어서, 앞쪽은 빼서 풉니다.

같은 문구가 로그인 뒤 작업 중에 나오기도 합니다. CAJ2는 파일 하나를 만드는 계획이 승인된 직후 이 문구가 담긴 400을 받았다고 보고했습니다(CLI 0.36.0, oauth-personal, darwin, 2026-04-04, 이슈 #24695, 닫힘).

이건 인증 설정을 고쳐서 풀리는 오류가 아니에요. 로그인 단계인지 세션 중간인지 먼저 나누지 않으면 엉뚱한 곳을 고치게 됩니다.

Failed to sign in. Message: You do not have a valid license of this product

niels-collide는 유효한 라이선스가 있고 아무것도 바꾸지 않았는데 갑자기 이 문구로 끊겼으며, 안정판·프리뷰·나이틀리·이전 버전과 로컬 인증 데이터 삭제로도 풀리지 않았다고 보고했습니다(CLI 0.57.0, 프로젝트 ID를 설정한 Workspace 계정, 2026-08-26, 이슈 #29101, 열린 상태). 공식 문제 해결 문서에는 없는 문구이고 원인도 확정되지 않았습니다.

라이선스 상태를 가리키는 문구라 CLI 설정으로 풀 문제가 아니에요. 관리자에게 구독·라이선스 등록을 확인해 달라고 하세요.

Your current account is not eligible… it is not currently available in your location

Gemini CLI가 현재 위치를 지원하지 않는다는 뜻입니다. 문제 해결 문서에는 해결 절 대신 개인용 Gemini Code Assist 지원 지역 목록 링크만 있어요. 지원 지역 밖이면 계정을 바꿔도 풀리지 않습니다.

unable to get local issuer certificate

hypntzed78은 브라우저 승인까지 마쳤는데 토큰 교환 요청이 이 오류로 실패했다고 보고했고, 이슈는 보안 영역·p1·중복 가능성 라벨이 붙은 채 닫혔습니다(2025-11-27, 이슈 #13914).

계정이 아니라 인증서 문제예요. SSL/TLS를 가로채 검사하는 회사 네트워크에서는 Node.js가 신뢰할 사내 루트 CA가 따로 필요한 경우가 많습니다.

먼저 Node.js가 운영체제 인증서 저장소를 쓰게 하세요. 사내 인증서는 보통 거기 이미 들어 있습니다. 그래도 안 되면 NODE_EXTRA_CA_CERTS에 사내 루트 CA 파일의 절대 경로를 넣으면 됩니다.

export NODE_USE_SYSTEM_CA=1

1: 서버가 거부했을 때는 service부터

1은 요청이 서버까지 갔다가 거부됐다는 뜻입니다. 실재하지 않는 키로 두 경로를 직접 확인했는데, 둘 다 1로 끝났어요. 아래는 응답의 주요 필드만 남긴 것입니다.

경로	코드	service	reason
GEMINI_API_KEY	400	generativelanguage.googleapis.com	API_KEY_INVALID
Vertex AI + GOOGLE_API_KEY	401	aiplatform.googleapis.com	CREDENTIALS_MISSING

Gemini API 키 경로에서 API_KEY_INVALID가 나오면 키 문자열 자체가 거부된 것입니다. 오타, 섞여 들어간 줄바꿈, 값에 들어간 따옴표부터 보세요.

{"error":{"code":400,"message":"API key not valid. Please pass a valid API key.","status":"INVALID_ARGUMENT",…}}

Vertex AI 경로의 401은 이런 문구로 나옵니다.

{"error":{"code":401,"message":"API keys are not supported by this API. Expected OAuth2 access token or other authentication credentials that assert a principal.","status":"UNAUTHENTICATED",…}}

공식 인증 문서는 이 오류가 보이면 조직이 API 키 사용을 제한했을 수 있으니 다른 Vertex AI 인증 방식을 써 보라고 안내합니다.

주의: 이 401 문구만 보고 조직 정책 탓으로 단정하지 마세요. 아무 데도 등록되지 않은 가짜 키에서도 똑같이 나왔습니다.

그래서 저는 이 순서로 봅니다.

1. 키가 유효한지 먼저 확인합니다.
2. ADC(gcloud auth application-default login)나 서비스 계정 키로 바꿔 봅니다.
3. ADC로 넘어갈 때는 기존 GOOGLE_API_KEY와 GEMINI_API_KEY를 해제합니다.

55는 인증 문제가 아니다

인증 오류처럼 보여도 인증 설정을 고쳐서는 안 풀리는 게 55입니다. 유효해 보이는 키를 넣었는데 이 메시지로 멈췄고, API 오류는 남지 않았어요.

Gemini CLI is not running in a trusted directory. To proceed, either use `--skip-trust`, set the `GEMINI_CLI_TRUST_WORKSPACE=true` environment variable, or trust this directory in interactive mode. …

대화형으로 승인할 수 없는 환경에서 폴더가 신뢰되지 않으면 FatalUntrustedWorkspaceError로 끝납니다. --skip-trust나 GEMINI_CLI_TRUST_WORKSPACE=true로 넘어가면 돼요.

이상한 점이 하나 있습니다. 같은 문서는 신뢰 폴더 기능이 기본으로 꺼져 있다고 설명하는데, 설정 파일이 하나도 없는 빈 폴더에서 0.60.0을 실행했더니 문서 설명과 달리 이 메시지로 멈췄거든요.

마치며

인증 오류를 볼 때 문구를 먼저 검색하기 쉬운데, 직접 돌려 보니 종료 코드 하나가 훨씬 빨리 방향을 잡아 줬습니다. 그리고 가짜 키에서도 “조직이 API 키를 막았을 수 있다”는 401이 그대로 나왔으니, 오류 문구가 가리키는 원인을 그대로 믿기보다 키부터 확인하는 게 맞다고 봅니다.

같은 증상이라면 실패한 명령을 다시 실행하고 바로 echo $?(PowerShell은 $LASTEXITCODE)로 종료 코드부터 확인해 보세요. 41이면 설정, 1이면 계정·키, 55면 폴더 신뢰입니다. 인증을 넘겼다면 이어서 GEMINI.md를 어디에 두면 읽히는지를 보면 됩니다.