Gemini CLI 최신 업데이트
무료 티어 실사용 주의
Gemini CLI Plan 모드: “읽기 전용이니 안전하다”고 믿으면 Pro 쿼터 50개 함정 그대로 맞는 이유
구글이 4일 전 공식 출시한 Plan 모드. 코드를 건드리지 않으니 무조건 아껴 쓰는 모드라고 생각하시나요? 실제로는 Plan 모드가 활성화되는 순간 Gemini CLI가 자동으로 Pro 모델을 호출하도록 설계되어 있습니다. 하루 1,500 요청 중 Pro 쿼터는 고작 200 API 요청, 실제 대화로는 50~60 메시지에 불과합니다.
(무료 Google 계정 Pro 쿼터)
자동 활성화 상태
고비용 추론 모델
Plan 모드란 무엇인가 — 구글이 설명하지 않은 한 가지
2026년 3월 11일, 구글이 Gemini CLI에 Plan 모드를 공식 출시했습니다. 이 기능의 핵심은 단순합니다. AI가 코드를 직접 수정하기 전에 먼저 읽기 전용(read-only) 환경에서 코드베이스를 탐색하고, 전략을 세우고, 사용자의 확인을 받은 뒤에야 실행으로 넘어가는 구조입니다. (출처: Google Developers Blog, 2026.03.11)
공식 발표에 따르면 Plan 모드에서 Gemini CLI는 read_file, grep_search, glob 등 읽기 전용 도구만 허용합니다. 파일을 수정하는 것은 ~/.gemini/tmp/ 디렉터리 내의 .md 계획 파일에만 허용됩니다. GitHub 이슈 조회, PostgreSQL 스키마 확인 같은 외부 MCP 도구도 읽기 전용으로 안전하게 연결할 수 있습니다.
새로 추가된 ask_user 도구를 통해 AI가 직접 질문을 던져 요구사항을 명확히 한 뒤 계획을 수립합니다. 이렇게 완성된 계획은 Markdown 파일로 저장되며, Ctrl+X를 누르면 외부 에디터(VS Code, Vim 등)에서 직접 편집도 가능합니다. 그런데 바로 여기에 많은 사람이 놓치는 한 가지가 숨어 있습니다. Plan 모드는 단순히 “건드리지 않는 모드”가 아니라, 내부적으로 훨씬 무거운 추론 모델을 사용하도록 자동 설계되어 있다는 점입니다. 이 부분은 다음 섹션에서 공식 수치와 함께 구체적으로 짚겠습니다.
“1,500 요청”의 진실 — Pro 쿼터는 따로 있다
💡 이 섹션의 분석은 공식 Gemini CLI 요금 문서(geminicli.com/docs)와 실사용자 커뮤니티(Reddit r/GeminiCLI, 2026.03.08)의 수치를 교차한 결과입니다. 공식 안내만 보면 절대 알 수 없는 실사용 함정을 담았습니다.
Gemini CLI 무료 플랜(Google 계정 로그인)은 하루 1,000 요청, 분당 60 요청을 제공합니다. 유료 Google AI Pro 구독자는 하루 1,500 요청까지 늘어납니다. 숫자만 보면 꽤 넉넉해 보입니다. (출처: geminicli.com/docs/resources/quota-and-pricing/, 2026.03)
그런데 여기에 공식 문서에는 작게 적혀 있지만 실사용에서 치명적인 규칙이 있습니다. “1,500 요청은 메시지 수가 아니라 API 호출 수”입니다. 실제 커뮤니티 사용자(Reddit r/GeminiCLI)의 측정에 따르면 Gemini CLI가 내부적으로 루프 감지, 모델 라우팅 결정, 컨텍스트 확인 등에 매 대화마다 추가 API 호출을 발생시킵니다. 결과적으로 사용자가 입력한 메시지 1개가 내부적으로는 3~4개의 API 요청으로 처리되는 경우가 빈번합니다.
| 인증 방식 | 일일 총 요청 | Pro 모델 가용 요청 | 실사용 메시지(추정) |
|---|---|---|---|
| Google 계정 (무료) | 1,000 | 약 200 | 약 50~60개 |
| API Key (무료 티어) | 250 | Flash 전용 (Pro 없음) | 약 60~80개 |
| Google AI Pro (유료) | 1,500 | 약 200 | 약 50~60개 (Pro) |
| Gemini Code Assist Standard | 1,500 | Pro 포함 | 약 120~150개 |
이것이 실제로 의미하는 것은 이렇습니다. Plan 모드를 켜고 코드베이스 분석 작업을 하루에 몇 번 진행하면, 하루 1,500 요청이라는 숫자와 무관하게 Pro 모델 쿼터만 먼저 소진됩니다. Pro 쿼터가 떨어지면 이후 Plan 모드 요청은 Flash 모델로 라우팅되거나 한도 초과 오류가 발생하게 됩니다.
자동 모델 라우팅 구조 — 계획할 때 Pro, 실행할 때 Flash
💡 이 분석은 Google Developers Blog 공식 발표(2026.03.11)와 공식 문서의 Automatic Model Routing 섹션을 함께 검토한 결과입니다. 기존 어떤 블로그도 이 두 가지를 연결해서 분석하지 않았습니다.
Gemini CLI Plan 모드에는 자동 모델 라우팅(Automatic Model Routing)이라는 설계가 내장되어 있습니다. 공식 문서에 따르면 Plan 모드가 활성화된 동안은 Gemini 3.1 Pro처럼 고추론력(high-reasoning) Pro 모델이 우선 호출됩니다. 이는 복잡한 아키텍처 결정을 위해 의도된 설계입니다. (출처: geminicli.com/docs/cli/plan-mode/#automatic-model-routing, 2026.03)
그런데 계획이 승인되어 구현 단계로 전환되면, CLI는 자동으로 고속 Flash 모델로 전환됩니다. 이 전환이 일어나는 이유는 코드를 실제로 작성할 때는 빠른 처리 속도가 필요하고, 이미 계획된 작업을 수행하는 데 Pro 수준의 추론이 필요하지 않기 때문입니다.
다음 순서를 직접 계산해볼 수 있습니다:
📊 Plan 모드 1회 세션의 실제 API 호출 시뮬레이션 (추정)
- 사용자 입력 → 모델 라우팅 판단 요청 (Flash, 1 API 호출)
- 코드베이스 탐색: read_file × N회 (Pro, 2~5 API 호출)
- ask_user 질문 처리 (Pro, 1~2 API 호출)
- 계획 초안 생성 (Pro, 2~3 API 호출)
- 사용자 피드백 반영 및 계획 수정 (Pro, 2~3 API 호출)
→ 대화 1회에 Pro 모델 기준 최소 7~14 API 호출 소비. 200 Pro 쿼터 ÷ 최소 7회 = 하루 약 14~28 세션 가능 (단, 각 세션의 복잡도에 따라 실제 가능 횟수는 더 낮아질 수 있음, 추정)
이것이 의미하는 것은 명확합니다. “Plan 모드 = 읽기 전용 = 가볍다”는 직관과 달리, Plan 모드는 구현 모드보다 API 비용 측면에서 오히려 더 무거운 모드입니다. 설계 의도 자체가 “추론을 충분히 한 뒤 실행”이므로, 충분한 추론을 위해 Pro 모델을 집중적으로 사용하는 것은 당연한 결과입니다.
Plan 모드가 기본 ON인 이유 — 알고 끄는 것과 모르고 켜두는 것의 차이
Plan 모드는 설치 후 별도 설정 없이 기본(Default) 활성화된 상태로 제공됩니다. 구글이 이 선택을 한 이유는 명확합니다. AI 에이전트가 실수로 파일을 덮어쓰거나 의도치 않은 명령을 실행하기 전에, 먼저 계획을 검토할 기회를 주는 것이 더 안전하다는 철학 때문입니다. (출처: Google Developers Blog, 2026.03.11)
실제로 Shift+Tab을 누르면 승인 모드가 Default → Auto-Edit → Plan 순으로 순환합니다. 그런데 /settings에서 Default Approval Mode를 Plan으로 설정하면 세션 시작부터 항상 Plan 모드로 진입합니다. 여기에 함정이 있습니다. 빠른 질문 하나를 하려고 Gemini CLI를 실행했는데, 이미 Plan 모드로 설정되어 있다면 그 한 번의 질문에도 Pro 모델이 먼저 호출됩니다.
⚠️ 이런 상황이라면 쿼터가 빠르게 소진됩니다
/settings에서 Default Approval Mode를 Plan으로 설정해 놓은 경우- 대규모 코드베이스를 대상으로 Plan 모드 사용 (파일 탐색 API 호출 수 급증)
- ask_user 질문-답변 반복이 많은 복잡한 요구사항 작업
- Conductor 익스텐션과 함께 Plan 모드를 병행 사용하는 경우
/stats session 명령어를 치면 현재 세션의 모델별 API 호출 수를 실시간으로 확인할 수 있습니다. 이 명령어를 습관화해 Pro 잔여 쿼터를 자주 체크하는 것이 Plan 모드 활용의 기본 원칙이 됩니다.
Claude Code·Cursor와 비교하면 보이는 것
AI 코딩 CLI 도구 시장에는 현재 15개 이상의 경쟁 도구가 존재합니다. 그중 가장 자주 비교되는 세 도구를 Plan 모드의 핵심 기준인 “계획-실행 분리 구조”와 “비용” 관점에서 살펴볼 필요가 있습니다. (출처: tembo.io, AI Coding CLI Tools Comparison 2026.02)
| 도구 | 계획-실행 분리 | 무료 접근성 | 특이사항 |
|---|---|---|---|
| Gemini CLI | Plan 모드 (기본 ON) | 무료 (1,000 req/일) | Pro 쿼터 소진 주의 |
| Claude Code | 없음 (고자율 에이전트) | 유료 (API 키 필수) | 200K 컨텍스트, 복잡 리팩터 강점 |
| Cursor | 없음 (IDE 인라인) | 제한 무료 | 에디터 내 실시간 편집 강점 |
| Kiro (AWS) | Spec-driven (요구사항→설계→코드) | 크레딧 기반 | EARS 표기법으로 요구사항 구조화 |
Claude Code와 Kiro(AWS)를 비교하면 흥미로운 차이가 드러납니다. Claude Code는 계획 없이 바로 자율 실행하는 고자율 에이전트 방식인 반면, AWS Kiro는 EARS(Easy Approach to Requirements Syntax) 표기법으로 요구사항을 구조화한 뒤 코드로 넘어가는 Spec-driven 방식입니다. Gemini CLI의 Plan 모드는 이 두 철학의 중간점에 위치합니다. 바로 실행하지는 않지만, Kiro처럼 엄격한 형식을 요구하지도 않습니다. 이 유연함이 장점이기도 하고, “어느 정도까지 계획해야 하는가”를 스스로 결정해야 한다는 부담으로 작용하기도 합니다.
무료 접근성 측면에서 보면 Gemini CLI는 현재 AI 코딩 도구 가운데 가장 관대한 무료 티어를 제공합니다. 단, 위에서 살펴본 것처럼 Plan 모드를 적극 활용할 경우 무료 티어의 Pro 쿼터가 예상보다 빠르게 소진된다는 점은 다른 도구를 선택할 때와 달리 반드시 사전에 인지해야 하는 조건입니다.
쿼터를 아끼면서 Plan 모드를 제대로 쓰는 방법
Plan 모드를 쿼터 낭비 없이 활용하는 방법은 구조적으로 접근하는 데 있습니다. Plan 모드의 강점인 “Pro 모델의 깊은 추론”을 아껴서 쓰는 것이 핵심입니다.
✅ Plan 모드 쿼터 절약 실전 원칙
- 복잡도가 낮은 작업은 Plan 모드 비활성화:
/settings에서 Default Approval Mode를Default로 유지하고, 복잡한 작업에만/plan으로 수동 진입하는 것을 권장합니다. - 사전에 요구사항 정리 후 진입: ask_user 질문-답변 루프가 많을수록 Pro API 호출이 쌓입니다. Plan 모드에 진입하기 전 미리 요구사항을 정리해서 AI에게 명확히 전달하면 루프 횟수를 줄일 수 있습니다.
- 자동 모델 라우팅 비활성화 고려:
settings.json에서"modelRouting": false를 설정하면 Pro 자동 전환을 막고 Flash 모델로 Plan 모드를 실행할 수 있습니다. 단, 계획 품질이 낮아질 수 있으므로 간단한 작업에만 적용합니다. - 세션 중
/stats session주기적 확인: Pro 잔여 쿼터를 실시간으로 파악해 소진 전에 Flash 전환 또는 작업 중단을 결정합니다. - Conductor 익스텐션 활용: 복잡한 장기 프로젝트는 Conductor 익스텐션이 Plan 모드와 ask_user를 자동 조율합니다. 임시 작업마다 새 세션을 열 때보다 세션 연속성을 유지하면 내부 라우팅 판단 API 호출을 줄일 수 있습니다.
또한 Plan 모드가 생성한 계획 파일(.md)은 ~/.gemini/tmp/에 기본 저장되며, 30일 후 자동 삭제됩니다. settings.json에서 "directory": ".gemini/plans"로 커스텀 경로를 지정하면 계획 파일을 프로젝트 내에서 직접 버전 관리할 수 있습니다. 이 경우 계획 파일이 자동 삭제되지 않으므로 수동 관리가 필요합니다. (출처: geminicli.com/docs/cli/plan-mode/, 2026.03)
자주 묻는 질문 5선
마치며 — Plan 모드를 제대로 쓰는 사람과 그렇지 않은 사람의 차이
Gemini CLI Plan 모드는 분명히 좋은 기능입니다. AI가 실수로 코드를 망가뜨리기 전에 계획을 검토하고, 사용자가 방향을 확인한 뒤에야 실행으로 넘어가는 구조는 안전한 에이전트 코딩의 올바른 방향성입니다. 구글이 이 기능을 기본 활성화로 배포한 것도 그 철학에서 비롯된 선택입니다.
그러나 “읽기 전용이니 쿼터를 아낀다”는 직관은 틀렸습니다. Plan 모드는 오히려 구현 모드보다 더 무거운 Pro 모델을 집중적으로 사용합니다. 하루 1,500 요청이라는 숫자가 실제로는 Pro 쿼터 기준으로 50~60 메시지 수준이라는 것을 알고 쓰는 것과 모르고 쓰는 것은 완전히 다른 결과를 낳습니다.
Plan 모드를 제대로 활용하는 핵심은 세 가지입니다. 첫째, 복잡한 작업에만 Plan 모드를 수동으로 진입시킵니다. 둘째, /stats session으로 Pro 쿼터를 주기적으로 확인합니다. 셋째, 단순 작업에는 자동 모델 라우팅을 끄거나 Default 모드를 유지합니다. 이 세 가지를 지키는 것만으로도 같은 무료 티어에서 몇 배 더 오래, 더 깊이 있는 작업을 이어갈 수 있습니다.
📚 본 포스팅 참고 자료
- Google Developers Blog — Plan mode is now available in Gemini CLI (2026.03.11) · https://developers.googleblog.com/plan-mode-now-available-in-gemini-cli/
- Gemini CLI 공식 문서 — Plan Mode · https://geminicli.com/docs/cli/plan-mode/
- Gemini CLI 공식 문서 — Quotas and Pricing · https://geminicli.com/docs/resources/quota-and-pricing/
- Tembo.io — The 2026 Guide to Coding CLI Tools: 15 AI Agents Compared (2026.02) · https://www.tembo.io/blog/coding-cli-tools-comparison
- Reddit r/GeminiCLI — 실사용자 쿼터 소진 보고 (2026.03.08) · https://www.reddit.com/r/GeminiCLI/comments/1ro5hrd/
※ 본 포스팅은 2026년 3월 16일 기준으로 작성되었습니다. Gemini CLI의 요금 정책, 쿼터 구조, Plan 모드 기능은 Google의 업데이트에 따라 수시로 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으므로, 최신 정보는 반드시 공식 문서(geminicli.com/docs)에서 확인하시기 바랍니다.
댓글 남기기