Gemini CLI 종료 이후, 라이선스 티어별 개발 도구 이관 설계

종료 공지가 드러낸 도구 수명의 조건

Google은 2026년 6월 18일부터 Gemini CLI와 Gemini Code Assist IDE 확장에서 개인, Google AI Pro, Google AI Ultra 티어의 요청 처리를 중단한다. 이 대상 사용자는 Antigravity CLI(agy)로 이관된다. 반면 Gemini Code Assist Standard와 Enterprise 라이선스는 기존 경로가 따로 유지된다.

같은 이름의 개발 도구를 쓰고 있어도 인증 티어에 따라 이용 가능 여부와 수명주기가 달라지는 셈이다. 조직 안에서 두 경로가 함께 남으면 명령어, 설정 파일, 요청 한도, CI 파이프라인의 참조가 갈라진다.

Antigravity는 커맨드 센터, IDE, CLI, SDK, Gemini API 상의 관리형 에이전트를 포함하는 에이전틱 개발 플랫폼으로 규정된다. 오픈소스였던 CLI가 비공개 바이너리로 바뀌었고, 무료 티어 요청 한도도 하루 1,000건 수준에서 크게 축소된 것으로 보고됐다. 이 변화는 단순한 실행 파일 교체가 아니라 개발 도구 자산의 성격과 운영 조건이 함께 바뀌는 일이다.

인증 티어에서 시작하는 이관 경로

먼저 사용자와 서비스 계정이 어떤 라이선스로 인증되는지 파악해야 한다. 인증 정보를 기준으로 사용 가능한 CLI를 안내하는 래퍼 스크립트는 이 판단을 자동화하는 방법이 될 수 있다.

도구 자산 대장에는 인증 티어, CLI 종류, 버전, 지원 종료일을 함께 기록한다. 이 매트릭스가 없으면 어느 조합이 언제 끊기는지 추적하기 어렵다. 벤더 공지를 받았을 때 갱신할 수 있도록 자산 관리 체계에 포함하는 편이 낫다.

설정 형식이나 경로가 다르다면 규칙 파일, 모델 지정, 프로젝트 설정을 옮겨야 한다. 변환 스크립트로 일괄 처리하되 대응되지 않는 항목은 별도 목록으로 남겨 수동 판단으로 넘긴다. 기존 스크립트가 특정 CLI를 직접 호출한다면 호출부 전체를 고치기보다 명령 매핑 수준의 얇은 래퍼를 두는 편이 교체 지점을 줄인다.

⤢✕

CI는 별도 점검 대상이다. 도커 이미지에 고정된 바이너리와 캐시된 설치 스크립트는 쉽게 누락된다. 또 파이프라인은 개인 계정이 아니라 서비스 계정으로 인증되는 경우가 많으므로, 개발자 환경과 분리해 티어를 확인해야 한다.

두 도구를 병행하는 동안에는 설치 경로와 설정 디렉터리를 나눠 PATH 충돌과 설정 간섭을 막는다. 병행 기간과 정리 시점을 계획에 명시하고, 종료 뒤에는 잔여 설치본을 제거하며 자산 대장을 갱신한다.

전환 계획에서 먼저 확인할 대상

조사의 출발점은 누가 어떤 라이선스와 도구를 쓰는지 확인하는 일이다. 라이선스 관리 콘솔, 설치 자산 스캔, 개발자 설문을 교차 확인하면 누락을 줄일 수 있다. 팀 공용 서비스 계정과 개인 계정을 구분한 뒤 티어별로 이관 대상을 분류하고, 예외는 수동으로 확인한다.

개인 티어로 인증된 CI·자동화 계정은 서비스 중단 위험이 가장 크므로 우선 처리 대상이다. 조직 내부 전환 기한도 벤더 공지일과 별도로 잡아야 한다. 종료일에서 검증 완료 목표일, 전환 시작일, 조사 완료일 순으로 역산해 배치하면 공지 당일의 장애 대응을 피할 수 있다.

이번 전환에서 스크립트의 직접 CLI 호출을 래퍼 경유로 바꾸면 다음 교체 비용도 낮아진다. 요청 한도 축소에 대비해 재시도와 백오프 로직을 점검하는 일도 포함한다. 한도 초과는 이관 직후 가장 흔한 장애 유형이다.

명령어 체계가 달라진다면 자주 쓰는 명령의 대응표를 배포하는 방식이 교육 부담을 낮춘다. 종료 이후 남은 설치본은 보안 갱신을 받지 못하므로, 제거 절차 역시 자산 관리에 넣어야 한다. 종료 공지는 제품 블로그나 문서 각주에만 실리는 경우가 많으므로 수신 채널과 담당자를 지정하고, 자산 대장에는 지원·유예·종료 상태를 표시한다.

직접 의존과 얇은 래퍼의 운영 차이

구분	벤더 CLI 직접 의존	도구 추상화 계층 구축
초기 구현	단순	래퍼 개발 필요
전환 비용	호출 지점 전수 수정	래퍼 한 곳 수정
최신 기능 활용	즉시	래퍼 갱신 후
유지보수	없음	지속 필요
적합 상황	도구 교체 빈도 낮음	다중 도구·잦은 변경

벤더 CLI에 직접 의존하면 초기 구현이 간단하고 최신 기능을 바로 활용할 수 있다. 반대로 도구 추상화 계층에는 개발과 유지 비용이 든다. 다만 티어별로 도구가 교체되는 상황이 반복된다면, 얇은 래퍼는 한 번의 전환으로 이후 수정 범위를 줄이는 역할을 한다.

무료·개인 구독 티어는 비용이 낮지만 정책 변경에 그대로 노출된다. 기업 라이선스는 비용이 높되 지원 경로가 별도로 유지되고 종료 통지 조건이 계약으로 보호되는 경우가 많다. 업무 필수 경로에 개인 티어를 두는 구성은 비용 절감보다 위험 이전에 가깝다.

단일 도구 표준화는 교육, 스크립트, 지원을 한 갈래로 관리하게 한다. 다중 CLI 병행은 팀별 선택을 허용하지만 설정, 인증, CI 구성을 각각 유지해야 한다. 티어별로 도구가 강제되는 조건에서는 완전한 표준화가 어려우므로, 인터페이스를 래퍼로 통일하는 절충이 현실적이다.

개발 도구도 수명주기 관리 대상이다

개발 도구는 설치본, 라이선스, 지원 종료일을 관리해야 하는 자산이다. 이를 대장으로 다루지 않으면 종료 통지가 개인 개발자 수준에서 사라질 수 있다. 티어 정보까지 자산 속성으로 관리해야 티어별 종료에 바로 대응할 수 있다.

오픈소스 CLI에서 비공개 바이너리로의 변화는 자산 성격 자체를 바꾼다. 코드 감사 가능성, 오프라인 사용, 포크 가능성도 함께 사라진다. 도입 당시 오픈소스 여부를 근거로 삼았다면, 전환 시점에는 그 근거가 유효한지 다시 평가해야 한다.

벤더 관리에서는 사전 통지 기간, 통지 방식, 대체 경로 제공 조건을 계약 항목으로 확보하는 일이 중요하다. 대체 도구 목록과 추상화 계층을 유지하는 것이 벤더 종속을 줄이는 실질적 수단이다. 전환 계획 없이 종속만 우려하는 것은 통제가 아니다.

개발 도구의 라이선스 티어별 수명 분화는 일반화되고, 무료 티어 도구를 업무 필수 경로에 두는 구성은 위험 항목으로 인식되는 흐름이다. 비공개 에이전틱 플랫폼으로의 전환은 도구 감사 가능성 요구를 조달 기준에 편입시키고, 요청 한도 축소는 CI 파이프라인에서 한도 기반 재시도와 백오프 설계를 기본 요건으로 만들 수 있다.