Gemini CLI OAuth 크론 오류 체크리스트: API 키·trust·명령 길이 확인
Gemini CLI를 새벽 크론 작업에 붙이면 일반 터미널에서는 보이지 않던 문제가 드러난다. 명령은 같은데 크론에서는 멈추고, 로그에는 인증인지 권한인지 명령 길이인지 바로 보이지 않는 경우가 있었다. FMNOTE에서는 AI 도구를 원고 작성자가 아니라 마지막 말투 점검 도구로만 쓰기 때문에, 자동 실행이 실제로 어느 인증 경로를 타는지 확인하는 일이 중요했다.
지금 운영 기준은 Antigravity CLI 쪽으로 옮겨가고 있지만, 이 글에서 정리한 문제는 그대로 남는다. OAuth로 로그인한 CLI 도구를 크론이나 자동 작업에 붙일 때는 인증 경로, 작업공간 trust, 입력 전달 방식을 따로 확인해야 한다.
10초 결론: 응답이 왔다고 OAuth가 검증된 것은 아니다
CLI가 한 번 답했다고 해서 개인 OAuth가 정상으로 작동한다고 보면 안 된다. 환경변수에 API 키가 남아 있으면 다른 인증 경로로 응답할 수 있고, 사람이 보는 터미널에서 넘겼던 trust 확인은 크론에서는 정지 지점이 된다. 긴 HTML 원고를 명령 인수로 넣으면 Windows 실행 단계에서 깨질 수도 있다.
그래서 저는 점검 순서를 이렇게 고정했다. 인증 변수를 비운다. 짧은 프롬프트로 OAuth 계정을 확인한다. 작업공간 trust를 명시한다. 긴 원고는 표준입력으로 보낸다. 결과는 그대로 믿지 않고 diff와 공개 검증을 다시 본다.
확인한 실행 환경
이 문제는 모델 성능 문제가 아니었다. 실행 위치가 바뀌면서 생긴 운영 문제에 가까웠다. 사람이 직접 여는 터미널과 새벽 크론은 같은 명령을 실행해도 조건이 다르다.
- OS: Windows 기반 작업 환경
- 실행 형태: 사람이 여는 터미널과 예약 크론 작업
- 입력 대상: 블로그 원고 HTML 또는 말투 점검 프롬프트
- 실패 형태: 빈 출력, 멈춤, 인증 경로 혼동, 긴 명령 인수 문제
이 조건을 적어두지 않으면 나중에 “Gemini가 안 된다”라는 한 줄만 남는다. 실제 원인은 CLI 자체가 아니라 자동 실행 환경인 경우가 많았다.
증상은 단순하지만 원인은 셋으로 갈린다
처음에는 “Gemini CLI가 크론에서 멈춘다”는 하나의 문제처럼 보였다. 실제로는 인증 경로, 작업공간 trust, 명령 길이가 서로 다른 층에서 걸렸다. 사람 손으로 터미널을 열어 실행하면 넘어가는 확인창도, 크론에서는 멈춘 상태로 남는다.
API 키가 환경변수에 남아 있으면 더 헷갈린다. 응답이 왔다고 해서 개인 OAuth가 정상이라는 뜻은 아니기 때문이다. 이 상태에서 원고 품질만 보고 있으면 원인을 잘못 잡는다.
API 키가 남아 있으면 OAuth 확인이 흐려진다
가장 먼저 본 것은 환경변수였다. GEMINI_API_KEY, Google API 키, Vertex AI, ADC 서비스 계정 쪽 변수가 남아 있으면 CLI가 개인 OAuth가 아니라 다른 길로 붙을 수 있다. 테스트할 때는 그 변수들을 비운 상태에서 실행하고, 설정 파일의 인증 선택값이 개인 OAuth 경로인지 따로 확인했다.
env | grep -E 'GEMINI|GOOGLE|VERTEX|ADC'
이 명령은 값을 공개하려는 목적이 아니다. 어떤 종류의 인증 변수가 남아 있는지 이름만 보는 점검이다. 실제 키 값은 로그에 남기면 안 된다.
블로그 원고 보정처럼 계정 구분이 필요한 작업에서는 “응답이 왔다”보다 “어느 계정, 어느 인증 방식으로 응답했는가”가 더 중요했다. 이 구분이 안 되면 문제를 해결한 것처럼 보여도 다음 크론에서 다시 깨진다.
크론에서는 trust와 PTY가 먼저 걸린다
두 번째는 실행 환경이었다. 사람이 보는 터미널에서는 한 번 눌러 넘기는 trust 확인이, 새벽 크론에서는 그대로 정지 지점이 된다. 이미 신뢰한 작업공간이 아니라면 자동 실행용 조건을 명확히 둬야 했다.
GEMINI_CLI_TRUST_WORKSPACE=true
OAuth도 비슷하다. Google CAPTCHA, 2단계 인증, 계정 보호 화면이 뜨면 자동화로 우회할 문제가 아니다. 이때는 실패 로그를 남기고, 사람이 실제 브라우저에서 승인한 뒤 짧은 응답 테스트로 되살리는 쪽이 안전했다.
긴 원고는 -p 인수 대신 표준입력으로 보냈다
세 번째는 Windows 명령 길이였다. 긴 HTML 원고를 -p 인수 하나에 통째로 넣으면 원고 자체는 멀쩡해도 실행 단계에서 깨질 수 있다. 그래서 실제 원고는 표준입력으로 보내고, -p에는 “아래 HTML의 한국어 말투만 다듬고 구조와 링크를 보존하라” 같은 짧은 지시만 남겼다.
python scripts/agy_print_capture.py --timeout 5m < prompt.txt
현재 FMNOTE 운영에서는 이 방식처럼 입력 파일과 출력 로그를 분리해 남기는 쪽을 선호한다. 직접 CLI를 호출했는데 stdout이 비어도 transcript 로그에 모델 응답이 남는 경우가 있어서, 출력 위치를 정해두는 편이 원인 추적에 더 낫다.
결과는 말투 초안일 뿐이다
CLI가 돌았다고 해서 바로 공개하면 안 된다. 출력은 말투 초안으로만 본다. 링크, 가격, 제품 사실, 이미지 URL, HTML 구조는 diff로 다시 봐야 한다. 특히 WordPress 글은 작은 태그 하나가 깨져도 공개 화면에서 바로 티가 난다.
- 링크 URL이 바뀌지 않았는지 확인한다.
- 이미지 URL과 alt가 남아 있는지 본다.
- 표, 리스트, 코드 블록이 깨지지 않았는지 확인한다.
- 공개 URL 200, canonical, noindex, 내부링크를 다시 검사한다.
이 단계 때문에 자동화가 조금 느려져도 괜찮다. 공개 글은 한 번 깨지면 검색 신뢰도와 독자 경험을 동시에 잃는다.
실제로 남겨둔 점검 순서
- 크론 실행 전
GEMINI_API_KEY, Vertex, ADC 관련 환경변수가 남아 있는지 이름만 확인한다. - API 키 경로가 섞이지 않도록 테스트 환경을 비운다.
- 개인 OAuth 경로를 보고 있는지 짧은 프롬프트로 확인한다.
- 자동 실행 작업공간에는 trust 조건을 명시한다.
- Google 계정 보호 화면이 뜨면 자동화 실패로 처리하고 수동 승인 후 재시험한다.
- 긴 HTML은 명령 인수에 넣지 않고 표준입력으로 전달한다.
- 출력은 diff로 확인하고, 링크·HTML 구조·이미지 URL은 별도 검사로 다시 본다.
FMNOTE 운영에서 이 기준이 필요한 이유
FMNOTE의 목표는 AI 도구를 멋있게 소개하는 것이 아니라 실제 작업 흐름에서 어디가 막히는지 기록하는 것이다. Gemini CLI도 마찬가지다. 모델 성능보다 자동 실행에서 반복 실패를 줄이는 기준이 더 오래 남는다. 특히 블로그 원고 보정처럼 공개 콘텐츠와 연결된 작업은 계정, 인증, 파일 전달 방식을 대충 넘기면 나중에 원인 추적이 어려워진다.
관련해서 크론 결과 파일을 남기는 방식은 AI 에이전트 크론 작업은 결과 파일부터 남겨야 덜 꼬인다에서 따로 정리했다. 장기기억에 무엇을 저장할지 고민한다면 AI 에이전트 장기기억 설계 기준도 함께 볼 만하다. 맥에서 AI 작업환경을 처음 붙이는 단계라면 맥 AI 작업환경 세팅 체크리스트가 더 앞단의 점검표에 가깝다.
