headless VPS에서 Gemini CLI 설치 및 실행 방법

구축 목표

사용자 소유의 서버에서 SSH를 통해 접속하여 사용하는 상시 실행형 Gemini CLI를 구축합니다. 이 CLI는 노트북을 닫은 후에도 에이전트 작업이 중단되지 않고 계속 실행됩니다. 설치 과정은 세 개의 명령어로 완료됩니다. 주요 과제는 데스크톱 환경을 전제로 하는 설정들을 처리하는 것입니다. Google CLI는 로그인을 위해 브라우저를 실행하려 하지만, 서버에는 브라우저가 없습니다. 따라서 본 가이드는 대부분 headless 환경을 기준으로 설명합니다. 배포판에서 기본 제공하지 않는 최신 Node를 설치하고, root 권한이 필요 없는 global npm install을 수행하며, 쉘 히스토리에 남지 않는 API key를 사용하여 browserless 인증을 처리합니다. 또한, SSH 세션이 끊겨도 실행 중인 작업이 중단되지 않도록 tmux를 사용합니다.

Gemini CLI는 Google Gemini 모델과 통신하는 오픈 소스(Apache-2.0) Node 프로그램(@google/gemini-cli)입니다. 이 프로그램은 파일을 읽고 쓸 수 있으며, shell 명령어를 실행하고, 작업 디렉토리 내의 도구들을 제어할 수 있습니다. VPS에서 이 CLI는 상시 가동되는 소형 에이전트 역할을 수행합니다. 따라서 실행 계정 권한과 서버에 저장된 자격 증명(credentials) 관리가 본 가이드의 개별 설정보다 더 중요합니다.

Prerequisites and the honest gotchas

• root 또는 sudo 권한을 가진 신규 Ubuntu 24.04 KVM VPS. 모든 KVM 플랜에서 사용 가능합니다. CLI 자체는 가벼우며, 유휴 상태에서 RAM을 수백 MB만 사용합니다.
• Node.js 20 이상. 필수 최소 버전입니다. 배포판 패키지는 이보다 낮은 버전을 포함하므로 다음 섹션을 확인하십시오.
• Google API로의 Outbound HTTPS (port 443) 통신. 인바운드 포트는 필요하지 않습니다. 이 프로그램은 서버가 아닌 클라이언트이므로 방화벽 포트를 열 필요가 없습니다.
• 서버에서 브라우저를 사용할 수 없는 환경을 위한 인증 방식: Google AI Studio의 Gemini API key를 사용하거나, 로컬 PC의 브라우저로 SSH tunnel을 연결하십시오. 스크립트 및 자동화 실행에는 API-key 방식이 적합합니다.
• Docker 또는 Podman. --sandbox 격리 기능이 필요한 경우에만 필요합니다. 선택 사항이며 마지막 부분에서 다룹니다.

주의 사항: gemini의 초기 로그인 흐름은 데스크톱 환경을 기준으로 설계되었습니다. Headless 서버에서는 브라우저를 열려고 시도하다가 실패하거나, 작동하지 않는 링크를 생성합니다. 시작하기 전에 인증 방식을 결정하십시오.

Node: 배포판 패키지 버전이 너무 낮음

Ubuntu 24.04의 기본 저장소에는 npm 9.2.0과 함께 Node 18.19.1이 포함되어 있습니다. Gemini CLI의 package.json은 engines: { node: ">=20" }을 요구합니다. npm은 기본적으로 버전 불일치를 차단하지 않습니다. npm은 설치를 진행하며 버전 차이를 알리는 경고를 출력합니다.

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE   required: { node: '>=20' },
npm WARN EBADENGINE   current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }

경고를 무시하고 CLI를 실행하면 지원되지 않는 런타임에서 작동합니다. 이 경우 Node 20+ API를 호출하는 즉시 오작동하거나 충돌이 발생합니다. Node 18은 2025년 4월에 지원이 종료(EOL)되었으므로 사용이 불가능합니다. CLI를 설치하기 전에 최신 LTS 버전을 설치하십시오. 두 가지 해결 방법은 NodeSource(시스템 전체용 signed apt 저장소) 또는 nvm(사용자별 버전 관리자)입니다. 하나를 선택하십시오.

시스템의 모든 사용자가 Node를 사용하게 하려면 NodeSource를 사용하십시오:

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node --version

node --version은 v20.x 또는 그 이상의 버전을 출력해야 합니다. v24.x이 현재 활성 LTS입니다. NodeSource 페이지에서 최신 설정 스크립트를 확인하십시오. URL의 setup_24.x은 새로운 LTS가 출시될 때 업데이트해야 하는 부분입니다.

Node를 특정 사용자의 홈 디렉토리에만 유지하고 sudo를 사용하지 않으려면 nvm을 사용하십시오:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --version

해당 URL의 v0.40.1은 이 문서 작성 당시의 최신 버전입니다. nvm의 README에서 최신 릴리스를 확인하고 실행 전에 버전을 교체하십시오. nvm은 이 작업에 유리한 장점이 있습니다. Node와 글로벌 패키지를 ~/.nvm 아래에 설치하므로, 다음 섹션에서 다루는 글로벌 설치 권한 문제가 발생하지 않습니다. nvm을 사용하면 npm-prefix 단계는 건너뛰어도 됩니다.

sudo npm -g 없이 CLI 설치하기

sudo npm install -g @google/gemini-cli 명령어를 사용하고 싶을 수 있습니다. 하지만 사용하지 마십시오. root 권한의 global prefix를 사용하면 이후 모든 설치 과정에서 권한 오류가 발생합니다. 또한 npm cache에 root 소유의 파일이 남게 되어 나중에 문제가 발생합니다. sudo 없이 일반적인 npm install -g를 시스템 Node에 실행하면 다음과 같은 오류가 발생합니다.

npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'

이는 npm이 사용자가 쓰기 권한을 가질 수 없는 /usr/lib에 파일을 쓰려고 시도하기 때문입니다. 해결 방법은 sudo를 사용하는 것이 아닙니다. npm의 global prefix를 홈 디렉토리로 설정하여 global 설치 파일이 사용자의 소유 영역에 저장되도록 해야 합니다.

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @google/gemini-cli
gemini --version

~/.bashrc를 사용하고 ~/.profile를 사용하지 않는 것은 의도된 설정입니다. 두 섹션 뒤에 CLI를 실행할 tmux는 non-login shell을 시작합니다. 이 shell은 ~/.bashrc은 읽지만 ~/.profile은 건너뜁니다. 따라서 잘못된 파일에 PATH 라인이 있으면 필요한 시점에 gemini이 보이지 않게 됩니다. gemini --version이 버전 번호를 출력하면 테스트가 성공한 것입니다. 만약 gemini: command not found가 출력된다면 PATH export가 적용되지 않은 것이므로 실패 사례를 확인하십시오. nvm을 사용하는 경우 prefix 관련 설정은 생략하십시오. nvm은 이미 홈 디렉토리에 global 패키지를 설치합니다.

이전에 sudo npm를 실행하여 현재 Your cache folder contains root-owned files 오류가 발생한다면, sudo chown -R $(id -u):$(id -g) ~/.npm를 사용하여 한 번 복구하십시오.

Headless 인증 문제 및 해결 방법

처음 실행할 때 gemini을 interactively 실행하면 Google 계정 로그인을 요청합니다. 데스크톱 환경에서는 브라우저 탭이 열립니다. 하지만 브라우저가 없는 headless VPS에서는 localhost URL을 출력하여 직접 열도록 요청하거나, 다음과 같은 오류를 출력하며 실패합니다:

Failed to open browser. Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/v2/auth?...&redirect_uri=http://localhost:PORT

문제의 원인은 redirect_uri=http://localhost:PORT입니다. 노트북에서 해당 URL을 열어 승인하더라도, Google은 http://localhost:PORT으로 리다이렉트합니다. 이는 서버 내부의 localhost이므로 노트북에서는 접근할 수 없는 포트입니다. 따라서 로그인이 완료되지 않습니다.

해결 방법에는 두 가지가 있습니다.

첫 번째 방법은 API key를 사용하는 것이며, 서버 환경에 가장 적합한 기본 방식입니다. Google AI Studio(aistudio.google.com)에서 key를 생성한 후, CLI의 environment variable로 전달하십시오. CLI는 GEMINI_API_KEY을 읽어 브라우저 인증 과정을 생략합니다. 이때 보안을 위해 주의할 점이 있습니다. 프롬프트에 직접 export GEMINI_API_KEY=AIza...을 입력하지 마십시오. 입력된 값은 ~/.bash_history에 평문으로 저장됩니다. 또한 다른 사용자가 읽을 수 있는 파일에 저장하지 마십시오. 실행 시 shell이 source할 수 있는 mode-600 파일에 저장하십시오:

umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrc

chmod 600 설정은 해당 파일을 사용자 본인만 읽을 수 있음을 의미합니다. printenv GEMINI_API_KEY를 실행하여 key가 environment에 정상적으로 로드되었는지 확인하십시오. 아무것도 출력되지 않으면 CLI는 브라우저 인증을 시도하며 실패하게 됩니다. ~/.gemini/에 있는 .env 파일 형식을 사용해도 무방하며, 이 경우에도 chmod 600 ~/.gemini/.env 규칙을 동일하게 적용하십시오.

두 번째 방법은 OAuth callback을 노트북으로 터널링하여 개인 Google 계정 로그인(및 free tier)을 유지하는 방식입니다. CLI의 loopback server는 실행할 때마다 무작위 포트를 바인딩합니다. 따라서 OAUTH_CALLBACK_PORT environment variable로 포트를 고정하지 않으면 포워딩할 대상이 고정되지 않습니다. 포트를 고정한 후 다음과 같이 포워딩하십시오:

# from your laptop, forward the callback port into the SSH session:
ssh -L 8085:localhost:8085 user@your-server
# then, on the server, pin the callback to the same port and start the CLI:
export OAUTH_CALLBACK_PORT=8085
gemini

CLI는 브라우저를 열 수 없으므로 인증 URL을 출력합니다. 노트북 브라우저에서 해당 URL을 열어 승인하십시오. Google이 http://localhost:8085/...으로 리다이렉트하면 SSH forwarding을 통해 VPS의 loopback server로 전달되어 로그인이 완료됩니다. 포트를 고정하지 않으면 실행할 때마다 새로운 무작위 포트가 할당되므로, 미리 설정한 ssh -L으로는 이를 포착할 수 없습니다. 이 방법은 브라우저를 직접 조작해야 하므로 스크립트용으로는 적합하지 않습니다. 지속적으로 실행되는 프로세스에는 API key를 사용하십시오.

AI Studio 대신 Vertex AI 또는 Google Cloud 프로젝트를 사용하는 경우, GOOGLE_API_KEY과 GOOGLE_GENAI_USE_VERTEXAI=true를 함께 설정하거나 Code Assist 라이선스의 경우 GOOGLE_CLOUD_PROJECT을 설정하십시오. API key와 동일하게 environment variable를 사용하고 mode-600 파일을 적용해야 합니다.

SSH 세션이 끊겨도 프로세스가 종료되지 않도록 tmux 내부에서 실행하십시오

SSH 쉘에서 직접 실행한 gemini 프로세스는 해당 쉘의 자식 프로세스입니다. 노트북 덮개를 닫거나, Wi-Fi 연결이 끊기거나, 유휴 시간 초과로 인해 연결이 끊기면 sshd가 가상 터미널을 해제합니다. 이로 인해 쉘은 SIGHUP 신호를 받고 CLI 연결을 종료합니다. 파일 편집을 10분 동안 진행하던 작업도 연결 종료와 함께 중단되며, 다시 접속해도 복구할 수 있는 프로세스가 남아 있지 않습니다.

tmux는 sshd 대신 쉘의 소유권을 가짐으로써 이 문제를 해결합니다. 이는 원격 VPS의 tmux 내부에서 AI 코딩 에이전트를 실행하는 방식과 동일한 패턴이며, 여기서도 똑같이 작동합니다:

sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d — the task keeps running
# reconnect later from any machine:
tmux attach -t gemini

tmux new -A -s gemini는 gemini이라는 이름의 세션이 존재하면 연결하고, 존재하지 않으면 새로 생성합니다. 따라서 로그인 직후 실행할 단 하나의 명령어로 적합합니다. tmux 내부의 쉘은 SSH 세션이 아닌 분리된(detached) tmux 서버에 속하므로, 연결이 끊겨도 CLI는 계속 작동합니다. 다시 접속하여 세션에 연결하면 이전의 스크롤백 상태로 돌아갈 수 있습니다.

비대화형 스크립트 실행을 위해 Gemini CLI는 headless 모드를 제공합니다: gemini -p "summarise the failing tests in this repo"는 답변을 출력하고 종료하며, --output-format json은 다른 곳으로 파이프를 보낼 수 있는 기계 판독 가능 출력을 제공합니다. API 키를 사용한 headless 모드는 tmux 세션에서 긴 배치 작업을 실행하거나 cron 작업으로 실행할 때 유용합니다. 단, 주의 사항이 있습니다. cron 작업은 사용자의 로그인 파일을 불러오지 않습니다. 따라서 crontab 라인에 직접 GEMINI_API_KEY을 지정하거나, 명령어가 ~/.gemini_env를 불러오도록 설정해야 합니다. 그렇지 않으면 CLI가 브라우저 기반 흐름으로 전환되어 실행에 실패합니다.

운영 환경이 실행 중인 서버에서의 샌드박싱 및 권한 설정

Shell access 권한을 가진 agent는 shell과 같습니다. Gemini CLI는 명령어를 실행할 수 있으며, 기본적으로 위험한 명령어 실행 전에 사용자에게 확인을 요청합니다. 하지만 사용자가 --yolo(모든 tool call을 자동 승인)를 설정하면, agent는 실행 중인 사용자의 권한을 사용하여 파일을 삭제하거나, git에 push하거나, 내부 서비스에 접근할 수 있습니다. 운영 환경이 함께 실행되는 서버에서 이는 가상의 시나리오가 아닌 실제적인 blast radius가 됩니다.

보안 강화 수준이 높은 순서대로 나열한 세 가지 제어 방법은 다음과 같습니다:

• 전용 비특권 사용자(unprivileged user)로 실행하십시오. root나 sudo 그룹의 멤버가 아니어야 합니다. 별도의 home 디렉토리를 가진 agent 사용자를 생성하고, 해당 위치에 Node와 CLI를 설치하십시오. 이렇게 하면 잘못된 명령이 실행되어도 해당 계정 내로 피해가 국한됩니다. 이것이 가장 효과적인 결정입니다.
• 운영 환경의 자격 증명(credentials)을 서버에 두지 마십시오. 운영 환경의 ~/.aws/credentials, 운영 환경에서 복사해온 .env, 주요 데이터에 쓰기 권한이 있는 데이터베이스 비밀번호를 저장하지 마십시오. 대신 staging 환경용 또는 read-only 자격 증명을 제공하십시오.
• 내장된 sandbox를 사용하십시오. Docker 또는 Podman이 설치되어 있다면, gemini --sandbox(또는 GEMINI_SANDBOX=docker)는 agent의 tool call을 호스트 파일 시스템 및 네트워크와 격리된 컨테이너 내부에서 실행합니다. 이것이 비특권 사용자를 대체할 수는 없으나, 동일한 VPS에서 실제 업무를 수행할 때 강력한 두 번째 방어 계층이 됩니다.

만약 동일한 VPS에서 같은 VPS에서 agent에게 도구를 제공하는 MCP server와 같은 다른 self-hosted 도구들과 함께 Gemini CLI를 실행한다면, 추가되는 각 기능은 agent가 도달할 수 있는 공격 표면(surface)이 늘어나는 것으로 간주하십시오. 그리고 agent에게 부여되는 token의 범위를 정확히 하나의 작업으로 제한하십시오.

Quota, cost, and which auth path you chose

인증 경로에 따라 과금 방식이 결정됩니다. 개인 Google 계정(OAuth 경로)은 무료 Gemini Code Assist 티어를 사용하며, 분당 및 일일 제한이 적용됩니다. 제한을 초과하면 윈도우가 초기화될 때까지 rate-limit 오류가 발생합니다. AI Studio의 API key는 프로젝트 설정에 따라 무료 티어 또는 유료로 제공됩니다. 유료 키는 제한이 더 높으며 토큰당 비용이 발생합니다. Vertex 및 Cloud-project 인증은 Google Cloud를 통해 과금됩니다.

두 가지 주의 사항이 있습니다. 루프 내에서 작동하는 unattended agent는 할당량을 빠르게 소모할 수 있습니다. cron job에 등록하기 전에 처음 몇 번은 모니터링하십시오. 서버 측 모델을 사용하는 목적이 Google 호스팅 모델 대신 개인정보 보호나 무제한 추론을 위한 것이라면 다른 도구가 필요합니다. VPS에서 Ollama로 open LLM을 self-hosting하면 Gemini보다 훨씬 작은 모델을 실행해야 하지만, 가중치와 프롬프트를 자신의 서버에 유지할 수 있습니다.

Keeping it updated

Gemini CLI는 업데이트가 빈번합니다. 사용자 소유의 prefix에 설치했으므로 sudo 권한이 필요하지 않습니다.

npm install -g @google/gemini-cli@latest
gemini --version

릴리스 채널은 다음과 같습니다. @latest은 stable 버전이며, @preview은 weekly preview 버전입니다. @nightly은 bleeding edge 버전입니다. 안정적인 운영이 필요하다면 @latest으로 고정하십시오. nvm을 사용하는 경우, global package는 현재 활성화된 Node 버전 아래에 저장됩니다. 따라서 Node 버전을 nvm use으로 변경한 후에는 CLI를 다시 설치해야 할 수도 있습니다. 모든 패치를 따라가기보다는 release notes를 확인하십시오.

Failure modes, with the exact strings

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, 그리고 runtime에서 CLI가 충돌함. Node 버전이 너무 낮습니다. 배포판의 버전인 18.19.1은 이미 지원이 종료되었습니다. NodeSource 또는 nvm을 통해 Node 20 이상 버전을 설치하십시오. 설치 후 node --version로 확인하십시오. 여러 버전의 Node가 설치된 경우, which node가 /usr/bin/node이 아닌 새 버전을 가리키는지 확인하십시오.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root 권한의 prefix에 global install을 수행한 경우입니다. sudo를 사용하지 마십시오. npm config set prefix ~/.npm-global을 설정하고, PATH에 ~/.npm-global/bin을 설정한 뒤, 일반 사용자 계정으로 재설치하십시오. 이전의 sudo npm 작업으로 인해 root 소유의 캐시 파일(Your cache folder contains root-owned files)이 남았다면, sudo chown -R $(id -u):$(id -g) ~/.npm을 실행하십시오.

Failed to open browser, 로그인 중단, 또는 접속할 수 없는 redirect_uri=http://localhost:PORT. OAuth 흐름이 서버에 없는 브라우저를 요구합니다. 또한 localhost callback이 사용자의 노트북이 아닌 서버를 가리킵니다. API-key 방식(GEMINI_API_KEY)을 사용하거나, OAUTH_CALLBACK_PORT을 고정하십시오. 그 다음 ssh -L을 사용하여 SSH로 포트 포워딩을 수행한 뒤, 로컬에서 해당 URL을 여십시오.

SSH 연결이 끊기면서 프로세스가 종료됨. SSH 쉘에서 직접 gemini를 실행했기 때문입니다. 이 프로세스는 해당 쉘의 자식 프로세스이므로, 연결이 끊기면 pty와 함께 종료됩니다. 복구할 수 있는 방법은 없습니다. 모든 세션은 tmux new -A -s gemini으로 시작하고, 그 안에서 CLI를 실행하십시오.

키를 설정했음에도 인증이 실패함 — CLI가 다시 인증 선택 화면으로 돌아가거나, 요청 결과로 HTTP 400와 함께 API key not valid가 반환됨. 키가 CLI가 참조하는 환경 변수에 포함되어 있지 않습니다. printenv GEMINI_API_KEY으로 확인하십시오. 값이 비어 있다면 ~/.gemini_env이 로드되지 않은 것입니다. 해당 라인이 ~/.bashrc에 있는지 확인하십시오. tmux를 포함한 대화형 쉘은 이를 읽지만, cron 및 기타 비대화형 쉘은 읽지 않습니다. 키 값 안에 공백이나 따옴표가 잘못 포함되어도 API key not valid이 발생합니다.

429 / RESOURCE_EXHAUSTED / rate-limit 메시지. 인증에 사용 중인 티어의 할당량을 초과했습니다. 할당량이 초기화될 때까지 기다리거나, 에이전트의 속도를 줄이거나, 유료 API 키로 전환하십시오. 재시도 루프에 빠진 에이전트는 이 오류를 계속 발생시킵니다. 에이전트를 중지하고 수행 중인 작업을 확인하십시오.

FAQ

How do I authenticate Gemini CLI on a headless server?

브라우저 로그인이 아닌 API key를 사용하십시오. Google AI Studio에서 키를 생성한 후, 쉘이 소싱하는 export GEMINI_API_KEY=... 파일에 저장하십시오. 이렇게 하면 CLI가 OAuth 브라우저 흐름을 완전히 건너뜁니다. 개인 계정의 무료 티어를 사용하려면 OAUTH_CALLBACK_PORT=8085로 loopback port를 고정하고, ssh -L 8085:localhost:8085 user@server를 사용하여 노트북으로 포트 포워딩을 수행한 뒤, 로컬에서 출력된 URL을 여십시오. 하지만 이 방법은 브라우저를 사용할 수 있는 환경이 필요하므로 스크립트용으로는 적합하지 않습니다.

Why does the npm global install want sudo, and how do I avoid it?

npm의 기본 global prefix가 /usr/lib/node_modules이기 때문입니다. 일반 사용자는 이 디렉토리에 쓰기 권한이 없으므로, 일반적인 npm install -g 실행 시 EACCES 오류가 발생합니다. sudo npm -g를 사용하는 것은 잘못된 해결 방법입니다. 이 방식은 나중에 설치를 방해하는 root 소유의 파일을 남깁니다. 올바른 해결 방법은 prefix를 홈 디렉토리(npm config set prefix ~/.npm-global)로 변경하고 해당 bin를 PATH에 추가하는 것입니다. 또는 nvm을 사용하십시오. nvm은 global package를 홈 디렉토리에 자동으로 설치합니다.

How do I keep Gemini CLI running after I disconnect?

tmux 내부에서 실행하십시오. SSH 쉘에서 시작된 프로세스는 해당 쉘의 자식 프로세스이므로 연결이 끊어지면 종료됩니다. tmux는 연결이 끊겨도 유지되는 detached server에서 쉘을 실행합니다. tmux new -A -s gemini를 실행하고, 그 안에서 gemini를 실행한 뒤, Ctrl-b d로 detach하십시오. 나중에 tmux attach -t gemini를 사용하여 다시 연결할 수 있습니다.

Is it safe to run Gemini CLI on a production box?

주의해서 사용해야 합니다. 쉘 액세스 권한이 있는 에이전트는 실행 중인 사용자의 모든 권한을 가집니다. sudo 권한이 없는 전용 unprivileged user로 실행하십시오. 운영 환경의 자격 증명을 해당 머신에 두지 마십시오. --yolo 자동 승인을 피하고, --sandbox(Docker 또는 Podman)를 사용하여 도구 호출을 호스트로부터 격리하십시오. 설정하는 개별 flag보다 실행되는 계정의 권한이 더 중요합니다.

Do I need to open any firewall ports for Gemini CLI?

아니요. Gemini CLI는 Google API로 아웃바운드 HTTPS 호출을 수행하는 클라이언트입니다. 따라서 아웃바운드 443 포트는 필요하지만, 인바운드 포트는 필요하지 않습니다. OAuth 터널을 사용하는 경우, 고정된 callback port(예: 8085)는 localhost에서 동작하며 SSH 포트 포워딩을 통해 접근됩니다. 인바운드 포트는 항상 차단된 상태를 유지하십시오.