Gemini CLI 로그인이 막혔다, 결국 agy로 넘어간 이유

2026년 10월 4일, 블로그 원고 작성을 Gemini에게 맡기려고 Gemini CLI를 열었다가 개인 Google 계정 로그인에서 막혔다. 같은 날 Antigravity CLI(agy)를 Homebrew로 설치하고 OAuth로 로그인한 뒤, 신뢰 폴더에서 -p 비대화형 실행으로 첫 문장을 받았다. 그 순서를 기록한다.

대상은 개인 계정으로 Gemini 계열 CLI를 처음 붙이려는 개발자다. 목표는 모델 품질 비교가 아니라 설치, 로그인, 첫 출력까지 한 번 통과하는 것이다. 아래 내용은 10월 4일 당시 내 환경의 기록이다. 일반 Gemini CLI가 서비스를 끝냈다는 뜻이 아니며, 지금 모든 개인 계정에서 같은 오류가 난다고 확인한 것도 아니다.

무엇이 막혔나

당시 설치돼 있던 것은 Homebrew로 받은 gemini 0.46.0이었다. 개인 Google 계정으로 로그인하려 하자 개인용 Gemini Code Assist 로그인이 더는 지원되지 않는다는 안내가 나왔다. 기록에 남긴 문구 일부는 다음과 같고, 안내는 Antigravity 쪽으로 이어졌다.

no longer supported for Gemini Code Assist for individuals

이 문구는 기록에 옮겨 둔 일부라 전체 원문은 아니다. 같은 오류를 만났다면 화면의 전체 문구와 안내 대상이 무엇인지 직접 확인하자. 나는 이 안내를 따라 Gemini CLI 로그인을 더 붙잡지 않고 Antigravity CLI로 옮겼다.

1. Homebrew로 agy 설치

설치는 cask 한 줄이었다.

brew install --cask antigravity-cli

설치 결과 실행 파일은 /opt/homebrew/bin/agy였고 버전은 1.2.16이었다. 같은 문제를 겪는다면 설치 직후 실행 파일 위치와 버전부터 기록해 두자. 나중에 동작이 바뀌었을 때 어느 버전 기준의 경험인지 구분할 수 있다.

2. Google OAuth로 로그인

로그인은 Google OAuth였다. 내가 쓴 계정은 Google AI Pro 요금제의 개인 계정이었다. 로그인을 시작한 정확한 명령 이름은 당시 기록에 남기지 않아 여기 적지 않는다.

내 경우 로그인은 원격으로 진행했다. NO_BROWSER 화면에 나온 링크를 브라우저로 열어 승인하고, 거기서 받은 인증 코드를 터미널에 입력했다.

두 가지를 같이 챙겼다.

  • 인증 코드는 입력에만 쓰고 어디에도 기록하지 않았다.
  • 데이터 수집 동의 체크는 해제했다.

3. 신뢰 폴더에서 실행

agy는 신뢰한 폴더에서 실행한다. 나는 처음에 아무 파일도 없는 빈 폴더(예: /tmp/agy-login)를 만들어 거기서 시험했다. 원고가 들어 있는 폴더에서 처음 실행하면 그 폴더를 신뢰할지 묻는 확인이 뜬다. 확인 화면의 정확한 문구는 기록하지 않았다.

빈 폴더부터 쓰면 로그인과 실행이 되는지만 먼저 확인할 수 있다. 실제 작업 폴더에 대한 신뢰는 그다음에 따로 결정하면 된다.

4. -p로 비대화형 실행

대화형 화면 대신 프롬프트 하나를 넘기고 텍스트만 받는 형식으로 실행했다.

agy -p "<프롬프트>" --output-format text --model <모델 id>
  • -p: 프롬프트를 인자로 넘긴다.
  • --output-format text: 결과를 텍스트로 받는다.
  • --model: 쓸 모델 id를 지정한다.

쓸 수 있는 모델은 agy models로 확인했다. 당시 목록에는 gemini-3.8-flash-high(기본)·medium·low, gemini-3.7-flash 계열, gemini-3.6-flash 계열, gemini-3.1-pro-high·low, claude-opus-5-5 계열이 있었다. 목록은 계정과 시점에 따라 다를 수 있으니 직접 조회한 값을 쓰자. 원고 작성용으로는 gemini-3.8-flash-high를 골랐다.

첫 출력에서 확인한 것

3.8 Flash로 받은 첫 시험 문장에는 "쏠쏠한 이자", "매력적인 금리 혜택", "필수 상품으로 꼽힌다" 같은 표현이 섞여 있었다. 출력 자체는 정상이었다. 로그인, 신뢰 폴더, 모델 지정이 모두 동작한다는 확인이 됐다.

다만 그대로 원고에 쓰기에는 홍보 투와 근거 없는 단정이 보였다. 그래서 다음 단계로 이렇게 정했다.

  • 작성 프롬프트에 글쓰기 규칙 11개, 과장 금지, 공식 출처 숫자만 사용을 명시한다.
  • 금지어 목록(꼭, 필수, 놓치지, 쏠쏠, 매력적, 고스란히, 마땅하다, 반드시)과 사실 자료에 없는 문장을 지우는 검사를 붙인다.
  • 숫자는 빌드 스크립트의 assert로 고정한다.
  • 고친 곳은 전후를 따로 기록한다.

역할도 나눴다. Gemini에게는 원고 본문 작성만 맡기고, 리서치와 숫자 검증, 빌드 검사, 다른 모델의 검토, 예약은 기존 흐름에 그대로 뒀다.

다른 CLI와 같이 쓴다면

Claude Code를 같은 컴퓨터에 아직 설치하지 않았다면 Claude Code 설치 3단계를 보면 된다. agy처럼 CLI로 붙일지, MCP 서버로 도구를 연결할지 고민된다면 MCP vs CLI, 둘 다 써보고 정리한 선택 기준이 판단에 도움이 된다.

결론: 로그인이 막히면 첫 문장까지의 경로부터 확보한다

10월 4일 내 환경에서는 gemini 0.46.0의 개인 계정 로그인이 막혔고, Antigravity CLI agy 1.2.16으로 옮겨 같은 날 첫 출력을 받았다. 순서는 Homebrew 설치, Google OAuth 로그인, 빈 신뢰 폴더, -p 비대화형 실행이었다. 첫 문장이 나온 뒤에야 문체 규칙과 검사 같은 실제 사용 조건을 정할 수 있었다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기