Gemini CLI OAuth가 크론에서 멈출 때 확인한 것

새벽 자동 작업에 Gemini CLI를 붙일 때 제일 먼저 본 건 모델 성능이 아니었다. 같은 명령이 일반 터미널에서는 잘 되는데, 크론에서는 인증 방식·워크스페이스 trust·Windows 명령 길이에서 조용히 멈출 수 있었다. 이 글은 그때 다시 막히지 않으려고 남긴 점검 순서다.

FMNOTE 운영에서는 Gemini를 원고 작성자가 아니라 마지막 말투 보정 도구로만 쓴다. 그래서 더더욱 “실제로 어떤 인증 경로로 실행됐는지”가 중요했다. API 키로 우회 실행된 결과를 OAuth 정상 작동으로 착각하면, 다음 크론에서 같은 자리에서 다시 막힌다.

API 키가 남아 있으면 OAuth 확인이 흐려진다

가장 먼저 본 것은 환경변수였다. GEMINI_API_KEY, Google API 키, Vertex AI, ADC 서비스 계정 쪽 변수가 남아 있으면 CLI가 개인 OAuth가 아니라 다른 길로 붙을 수 있다. 테스트할 때는 그 변수들을 비운 상태에서 실행하고, 설정 파일의 인증 선택값이 oauth-personal인지 따로 확인했다.

이 확인은 조금 번거롭지만, 한 번 해두면 로그를 읽기가 훨씬 쉽다. “응답이 왔다”보다 중요한 건 “어느 계정·어느 인증 방식으로 응답했는가”였다. 블로그 원고 보정처럼 계정 구분이 필요한 작업에서는 이 차이가 꽤 크다.

크론에서는 trust와 PTY가 먼저 걸린다

두 번째는 실행 환경이었다. 사람이 보는 터미널에서는 한 번 눌러 넘기는 trust 확인이, 새벽 크론에서는 그대로 정지 지점이 된다. 이미 신뢰한 작업공간이 아니라면 --skip-trust를 붙이거나 GEMINI_CLI_TRUST_WORKSPACE=true처럼 자동 실행용 조건을 명확히 둬야 했다.

OAuth도 비슷하다. Google CAPTCHA, 2단계 인증, 계정 보호 화면이 뜨면 자동화로 우회할 문제가 아니다. 이때는 실패 로그를 남기고, 사람이 실제 브라우저에서 한 번 승인한 뒤 짧은 응답 테스트로 되살리는 쪽이 안전했다.

긴 원고는 -p 인수로 밀어 넣지 않았다

세 번째는 Windows 명령 길이였다. 긴 HTML 원고를 -p 인수 하나에 통째로 넣으면, 원고 자체는 멀쩡해도 실행 단계에서 깨질 수 있다. 그래서 실제 원고는 표준입력으로 보내고, -p에는 “아래 HTML의 한국어 말투만 다듬고 구조와 링크를 보존하라” 같은 짧은 지시만 남겼다.

여기서도 결과를 그대로 믿지는 않았다. Gemini 출력은 말투 초안일 뿐이고, 링크·가격·제품 사실·이미지 URL·HTML 구조는 diff로 다시 봐야 한다. 특히 WordPress 글은 작은 태그 하나가 깨져도 공개 화면에서 티가 난다.

내가 남겨둔 짧은 점검표

• 전역 gemini가 Windows용 .CMD shim으로 잡히는지 확인한다.
• ~/.gemini/settings.json의 인증 선택값이 개인 OAuth인지 확인한다.
• OAuth 확인 실행에서는 API 키, Vertex, ADC 관련 환경변수를 비운다.
• 크론 실행에는 --skip-trust 또는 trust 환경값을 명시한다.
• 긴 HTML은 표준입력으로 보내고, -p는 짧게 둔다.
• 응답 후에는 diff로 링크, 이미지, HTML 구조가 바뀌지 않았는지 확인한다.

결론은 단순했다. Gemini CLI가 한 번 대답했다고 바로 자동화가 완성된 것은 아니다. 새벽에 혼자 돌아가야 하는 작업이라면, 인증 경로와 입력 방식부터 고정해야 한다. 그래야 말투 보정 같은 작은 단계도 다음 날 아침에 다시 설명 가능한 결과로 남는다.