본문 바로가기

GITHUB 추천

Gemini CLI 사용법: google-gemini gemini-cli GitHub AI agent terminal 추천

 

Gemini CLI GitHub 추천: 터미널에서 Gemini 에이전트 쓰는 법

설치, 첫 테스트, MCP, GitHub Actions, Antigravity CLI 전환까지 실제 도입 순서로 점검합니다.

 

Gemini CLI GitHub 추천: 터미널에서 Gemini 에이전트를 쓰는 법

 

Gemini CLI는 Gemini를 터미널에서 실행해 코드 탐색, 요약, 자동화 초안을 돕는 오픈소스 AI 에이전트입니다. 2026년 5월 기준 GitHub 활동성과 MCP, GitHub Actions 연동 근거가 있어 실습형 추천으로 볼 만하지만, 무료 개인 사용자는 Antigravity CLI 전환 공지를 함께 확인해야 합니다.

AI 코딩 도구를 IDE 안에서만 쓰다가 터미널로 가져오고 싶을 때 가장 먼저 막히는 지점은 의외로 단순합니다. 설치해도 되는 도구인지, 내 저장소 파일을 어디까지 읽고 수정하게 할지, 회사 계정이나 API 키로 운영해도 되는지부터 걸립니다.

`google-gemini gemini-cli GitHub AI agent terminal`이라는 키워드가 긴 이유도 여기에 있습니다. Gemini CLI는 Google이 공개한 `google-gemini/gemini-cli` 저장소의 TypeScript 기반 CLI이고, Gemini API와 MCP client/server 토픽을 함께 갖고 있습니다. 단순히 터미널에서 챗봇을 여는 도구라기보다 로컬 개발 워크플로 자동화 쪽에 더 가깝습니다.

다만 제가 보기에는 “지금 당장 무조건 갈아타라”는 식의 추천은 맞지 않습니다. Google Developers Blog가 2026-05-19에 무료 개인 사용자와 Google One 경로의 Antigravity CLI 전환을 공지했기 때문입니다. 그래서 여기서는 설치 명령만 나열하지 않고, 누가 바로 실험해도 괜찮고 누가 잠깐 멈춰서 계정 조건부터 봐야 하는지를 같이 짚겠습니다.

 
노트북 터미널에 gemini 명령과 저장소 폴더 요약 결과가 보이고, 옆에는 작은 GitHub PR 카드와 MCP 설정 파일이 놓인 16:9 기술 블로그 이미지
 

Gemini CLI 주요 변화 타임라인

 

2025년 저장소 생성과 공식 발표 이후, 2026년에는 설치 문서 갱신, 2026-05-19 Antigravity CLI 전환 공지, 2026-05-22 stable v0.43.0 공개, 2026-05-26 당일 push 활동이 이어졌습니다.

2026-05-26 GitHub API 확인 기준으로 `updated_at`은 2026-05-26T21:49:12Z, `pushed_at`은 2026-05-26T21:55:10Z였습니다. 저장소 활동이 당일에도 있었고 stars도 10만 개를 넘었지만, 이 수치는 전 세계 GitHub 지표입니다. 한국에서 많이 쓰인다는 뜻으로 읽으면 안 됩니다.

흐름만 놓고 보면 이렇게 정리할 수 있습니다.

날짜 확인할 의미
2025-04-17 `google-gemini/gemini-cli` 저장소 생성
2025-06-25 Google이 Gemini CLI를 공식 발표
2026-05-14 설치 문서가 Node.js 20 이상 등 권장 환경을 안내
2026-05-19 Antigravity CLI 전환 공지 게시
2026-05-22 GitHub Releases 기준 stable v0.43.0 공개
2026-05-26 GitHub API 기준 당일 저장소 활동 확인

여기서 볼 부분은 두 가지입니다. Gemini CLI는 멈춘 프로젝트가 아니라 실습해 볼 만한 GitHub 추천 도구입니다. 동시에 무료 개인 계정으로 장기 워크플로를 만들 사람은 전환 일정을 먼저 확인해야 합니다.

 

왜 지금 다시 볼 만한가

 

Gemini CLI는 단순 터미널 챗봇보다 넓은 개발자 도구입니다. CLI, Gemini API, MCP client/server, GitHub Actions 연동까지 한 번에 확인할 수 있어 로컬 개발 워크플로 자동화 관점에서 볼 만합니다.

실제로 중요한 포인트는 “Gemini를 터미널에서 부른다”보다 그 주변입니다. GitHub에서 확인되는 토픽은 `ai`, `ai-agents`, `cli`, `gemini`, `gemini-api`, `mcp-client`, `mcp-server`입니다. 대화형 AI 앱이라기보다 터미널과 외부 도구 사이에 놓이는 개발자용 에이전트에 가깝습니다.

한국 사용자 입장에서는 새 AI 도구를 하나 더 외우는 문제가 아닙니다. 이미 쓰는 터미널, GitHub, Node.js, 사내 스크립트, MCP 서버를 어떤 순서로 묶을지 보는 문제입니다. 작은 저장소에서 코드 구조를 요약하고, `GEMINI.md`로 프로젝트 규칙을 알려 주고, 이후 GitHub Actions에서 PR 리뷰 초안으로 넓히는 식이 현실적인 출발점입니다.

> 제가 보는 가치는 “Gemini와 대화한다”가 아니라 “반복되는 터미널 작업의 초안을 Gemini에게 맡겨 본다”에 있습니다.

Codex CLI와 비교할 때도 우열보다 생태계 선택이 먼저입니다. Google 계정, Gemini API, Vertex AI, Google 쪽 워크플로를 이미 쓰는 팀이라면 Gemini CLI의 실험 비용이 낮습니다. 반대로 기존 자동화가 다른 모델이나 CLI에 묶여 있다면 전환보다 비교 PoC가 먼저입니다.

 
터미널 창, GitHub pull request 카드, MCP server 설정 노드가 한 화면에서 연결된 개발 워크플로 다이어그램풍 이미지
 

설치와 첫 테스트: 가장 작은 안전한 PoC

 

처음에는 Node.js 20 이상을 확인한 뒤 `npx @google/gemini-cli`로 실행하고, 빈 테스트 디렉터리나 작은 저장소에서 읽기 전용 요약 프롬프트부터 확인하는 편이 안전하다.

바로 해볼 수 있는 순서는 간단합니다. 공식 설치 문서는 Node.js 20.0.0 이상, Bash/Zsh/PowerShell 같은 셸, 인터넷 연결을 요구사항으로 둡니다. macOS 사용자는 `npx @google/gemini-cli`로 먼저 실행해 보고, 계속 쓸 경우 `npm install -g @google/gemini-cli` 또는 `brew install gemini-cli`를 검토하면 됩니다.

제가 권하는 첫 테스트는 파일 수정이 아닙니다. 새 테스트 폴더를 만들거나 작은 공개 저장소를 열고, `gemini -p "이 저장소의 구조를 읽고 주요 폴더를 한국어로 요약해줘"`처럼 읽기 중심 프롬프트부터 실행합니다. 구조화 출력이 필요하면 공식 README에 문서화된 `--output-format json` 또는 `--output-format stream-json` 흐름을 확인합니다.

인증은 개인 실험과 팀 PoC를 나눠야 합니다. 개인은 `gemini` 실행 후 Google 로그인으로 시작하기 쉽지만, CI나 팀 환경에서는 Gemini API Key 또는 Vertex AI 경로를 검토해야 합니다. 실제로 확인할 부분은 요금 단정이 아니라 “어떤 계정으로, 어떤 저장소에서, 어떤 도구 권한까지 허용할 것인가”입니다.

저라면 첫날에는 여기까지만 보겠습니다.

1. `node -v`로 Node.js 20 이상인지 확인합니다.
2. `npx @google/gemini-cli`로 일회성 실행을 확인합니다.
3. `gemini`로 로그인 또는 API 키 인증 흐름을 확인합니다.
4. 작은 저장소에서 읽기 전용 요약 프롬프트를 실행합니다.
5. 파일 수정, shell command, MCP 도구 호출은 별도 브랜치와 제한된 권한에서 테스트합니다.

 
개발자가 노트북 터미널에서 npx와 gemini -p 명령을 실행하고, 옆 메모에 Node.js 20, Google login, API key 항목이 체크된 4:3 이미지
 

도입 시뮬레이션: 개인 실험과 팀 PoC를 나누기

 

개인 실험은 npx 또는 npm 전역 설치와 Google 로그인으로 시작하고, 팀 PoC는 프로젝트 `.gemini/settings.json`, `GEMINI.md`, API 키 또는 Vertex AI 인증, 버전 고정으로 운영 모델을 나누는 것이 좋다.

도구 소개보다 중요한 것은 하루 안에 무엇을 검증할지 정하는 일입니다. 개인 개발자는 설치와 요약 품질을 보면 되고, 팀은 권한·로그·버전·비밀값 관리까지 같이 봐야 합니다.

구분 개인 실험 팀 PoC
설치 `npx @google/gemini-cli` 또는 `npm install -g @google/gemini-cli` 패키지 버전 고정, Node.js 20 런타임 표준화
인증 Google 로그인 중심 `GEMINI_API_KEY` 또는 Vertex AI, secrets 관리
컨텍스트 현재 폴더와 간단한 프롬프트 `GEMINI.md`, `.gemini/settings.json`, 브랜치 정책
첫 성공 기준 저장소 구조 요약과 테스트 아이디어 생성 PR 리뷰 초안, 이슈 triage, MCP read-only 도구 연결
중단 조건 Antigravity CLI 전환이 더 적합한 무료 개인 사용 민감 저장소에서 도구 권한을 제한할 수 없는 경우

`google-gemini gemini-cli GitHub AI agent terminal`을 팀에 소개한다면 “AI가 코드를 알아서 고친다”가 아니라 “반복 설명과 리뷰 초안을 얼마나 줄이는가”로 잡는 편이 낫습니다. 오래된 README를 읽고 설치 절차를 갱신할 후보를 찾거나, 테스트가 부족한 모듈을 요약하게 하는 정도가 첫 성공 기준으로 적당합니다.

다만 운영으로 넘길 때는 버전 변화가 빠르다는 점을 감안해야 합니다. npm registry와 GitHub Releases에서 최신 stable을 재확인하고, CI에서는 액션이나 패키지 버전을 고정합니다. 민감한 저장소에서는 Gemini CLI가 접근할 수 있는 파일, 실행할 수 있는 shell command, MCP 서버 도구 목록을 제한해야 합니다.

 

MCP와 GitHub Actions는 어디까지 연결할까

 

MCP는 `settings.json`의 `mcpServers`로 연결하되 첫 설정은 read-only 도구, 제한된 `includeTools`, 신중한 `trust` 적용으로 시작하는 편이 안전합니다. GitHub Actions는 PR 리뷰, 이슈 triage, @gemini-cli 멘션 중 하나만 먼저 켜고 secrets와 토큰 권한을 최소화해야 합니다.

처음부터 사내 DB나 운영 API를 붙이는 방식은 피하는 편이 좋습니다. MCP는 Gemini CLI를 단순한 프롬프트 도구에서 외부 시스템과 연결되는 에이전트로 바꾸는 지점이기 때문입니다. 공식 문서는 `settings.json`의 `mcpServers` 객체 안에 `command`, `args`, `env`, `cwd`, `timeout`, `trust`, `includeTools`, `excludeTools` 같은 필드를 둘 수 있다고 설명합니다.

먼저 파일 읽기, 문서 검색, 샘플 MCP 서버처럼 되돌리기 쉬운 read-only 도구로 시작합니다. `includeTools`로 허용 도구를 좁히고, 필요 없는 도구는 `excludeTools`로 막습니다. `trust`는 편의 기능처럼 보이지만 실제로는 승인 절차와 연결되므로 팀 규칙이 생긴 뒤 다루는 편이 낫습니다.

GitHub Actions 연결도 같은 원칙입니다. 공식 `google-github-actions/run-gemini-cli`는 PR 리뷰, 이슈 triage, `@gemini-cli` 멘션 기반 지원을 문서화합니다. 하지만 첫 도입은 한 가지 워크플로만 켜야 합니다. 예를 들어 PR에 “변경 범위 요약과 테스트 누락 후보만 댓글로 남기기”처럼 쓰기 권한이 제한된 작업부터 시작합니다.

한국 팀에서 특히 볼 부분은 secrets 관리입니다. `GEMINI_API_KEY`, `GITHUB_TOKEN`, 별도 GitHub App 권한, branch protection, action 버전 고정을 체크하지 않으면 자동화가 편해지는 만큼 사고 범위도 커집니다.

 
 
 

도입 전에 확인할 리스크와 한국 독자용 판단

 

가장 큰 리스크는 계정 유형별 지원 변화, 과도한 도구 권한, secrets 노출, 빠른 릴리스 변화다. 특히 2026-06-18 이후 무료 개인 사용자 경로는 Antigravity CLI 전환 여부를 먼저 확인해야 한다.

무료 개인 사용자라면 여기서 한 번 멈춰야 합니다. 2026-05-19 Google Developers Blog 공지는 무료 및 Google AI Pro/Ultra 사용자 경로가 2026-06-18부터 Antigravity CLI 중심으로 바뀔 수 있음을 설명합니다. Standard/Enterprise나 유료 API 키 경로는 별도로 계속 지원된다고 되어 있지만, 개인 무료 사용자는 본인 계정 조건을 먼저 확인해야 합니다.

또 하나는 권한입니다. 터미널 AI 에이전트는 편하지만, 파일 조작·shell command·웹 fetch·MCP 도구 호출을 잘못 열면 민감 정보에 닿습니다. `google-gemini gemini-cli GitHub AI agent terminal`을 팀 도구로 소개할 때는 “무엇을 할 수 있는지”보다 “무엇을 못 하게 막을지”를 먼저 정해야 합니다.

한국 독자에게 의미 있는 지점은 국내 인기 여부가 아닙니다. 그 근거는 확인되지 않았습니다. 대신 Node.js 기반 개발 환경, GitHub PR 리뷰, MCP 실험, Gemini API/Vertex AI 검토를 한 번에 묶어 볼 수 있다는 점이 실무적입니다. 제가 보기에는 개인 블로그 독자라면 먼저 로컬 요약 PoC를 해 보고, 팀 독자라면 GitHub Actions까지 가지 전에 `.gemini/settings.json`과 `GEMINI.md` 운영 규칙을 문서화하는 편이 낫습니다.

마지막 판단은 간단합니다. Gemini 생태계를 쓰고 있고 터미널 자동화 실험이 필요하면 해볼 만합니다. 무료 개인 장기 사용, 강한 보안 통제, 기존 CLI와의 기능 동등성 보장이 필요한 상황이라면 Antigravity CLI와 대안을 먼저 비교해야 합니다.

 

자주 묻는 질문

 

Q. Gemini CLI는 지금 설치해도 되나요?
A. 실습 목적이라면 설치해 볼 만합니다. 다만 무료 개인 사용자라면 2026-06-18 Antigravity CLI 전환 공지를 먼저 확인해야 합니다. 장기 자동화는 계정 유형과 API 키 경로가 정리된 뒤 설계하는 편이 안전합니다.

Q. 첫 테스트는 어떤 명령으로 하는 것이 안전한가요?
A. Node.js 20 이상을 확인한 뒤 `npx @google/gemini-cli`로 실행하고, 작은 저장소에서 `gemini -p "이 저장소 구조를 요약해줘"`처럼 읽기 전용 프롬프트를 먼저 쓰는 것이 좋습니다. 파일 수정이나 shell 실행은 별도 브랜치에서 나중에 켭니다.

Q. Gemini CLI에서 MCP는 꼭 써야 하나요?
A. 꼭 필요하지는 않습니다. 기본 CLI만으로 요약과 코드 탐색을 확인한 뒤, 외부 도구 연결이 필요할 때 `.gemini/settings.json`의 `mcpServers`로 read-only MCP 서버부터 붙이면 됩니다.

Q. GitHub Actions에 바로 붙여도 되나요?
A. 바로 전체 자동화를 켜기보다 PR 리뷰 초안, 이슈 triage, `@gemini-cli` 멘션 중 하나만 고르는 편이 낫습니다. `GEMINI_API_KEY`, `GITHUB_TOKEN`, GitHub App 권한, action 버전 고정을 먼저 확인해야 합니다.

Q. Codex CLI 대신 Gemini CLI를 고를 만한 경우는 언제인가요?
A. Gemini API, Vertex AI, Google 계정 기반 개발 환경을 이미 쓰거나 MCP와 GitHub Actions를 Google 생태계 안에서 실험하려는 경우 Gemini CLI가 잘 맞습니다. 기존 워크플로가 다른 모델이나 CLI에 깊게 연결돼 있다면 기능 비교 PoC를 먼저 하는 편이 현실적입니다.

함께 읽으면 좋은 글

 

참조 링크