Gemini CLI는 로컬 파일과 명령을 직접 다룰 수 있어 복사, 붙여넣기를 줄이지만, 처음부터 쓰기 권한을 모두 주기보다 Plan Mode에서 범위와 변경 계획을 확인한 뒤 단계적으로 허용하는 편이 안전합니다. 이 글은 2026년 3월 원문에 담긴 기능 스냅샷을 기준으로 합니다.
Gemini CLI에 파일 수정 권한을 줘도 될까: Plan Mode, MCP 안전선
답변기가 아니라 도구 반복을 수행한다
Gemini CLI 저장소가 설명하는 작업 단위는 질문 한 번과 답변 한 번으로 끝나지 않습니다. 모델이 프로젝트 구조를 알아야 한다고 판단하면 파일 검색과 읽기를 호출하고, 결과를 관찰한 뒤 다음 행동을 고르는 ReAct 형태의 반복을 수행합니다. 파일 쓰기와 터미널 도구가 허용되면 분석이 실제 변경과 실행으로 이어질 수 있습니다.
이 장점은 곧 위험입니다. 잘못된 가정으로 넓은 디렉터리를 읽으면 토큰과 시간이 늘고, 쓰기나 셸 실행을 잘못 고르면 사용자 변경을 덮을 수 있습니다. node_modules처럼 불필요한 경로는 .geminiignore로 제외하고, 처음 요청에서 대상 파일과 금지 행동, 완료 조건을 명확히 적어야 합니다.
어떤 작업부터 맡기는 것이 맞을까
좋은 첫 작업은 범위가 작고 성공 조건을 자동 확인할 수 있습니다. 한 함수의 타입 오류, 문서와 테스트가 있는 작은 리팩터링, 정해진 명령으로 재현되는 버그가 여기에 가깝습니다. 반면 요구가 모호한 아키텍처 변경, 운영 데이터 수정이나 배포처럼 실패 비용이 큰 작업은 탐색과 계획까지만 맡기고 사람이 결정을 내려야 합니다.
작업을 고를 때는 세 질문을 씁니다. 변경 대상 파일을 미리 좁힐 수 있는가, 테스트나 정적 검사로 완료를 확인할 수 있는가, 잘못 고쳐도 diff로 되돌릴 수 있는가입니다. 세 항목이 모두 그렇다면 제한된 쓰기 시험에 적합합니다. 하나라도 아니라면 읽기 전용 조사나 제안서 생성으로 범위를 낮추는 편이 낫습니다.
짧은 오타 수정은 모델이 저장소를 읽고 계획하는 시간이 사람이 직접 고치는 시간보다 길 수 있습니다. 반대로 여러 파일에서 같은 규칙을 찾아 바꾸고 테스트해야 하는 반복 작업은 도구 루프의 이득이 큽니다. 에이전트를 쓸 수 있는가보다 작업당 검토 비용까지 줄어드는가로 후보를 골라야 합니다.
MCP는 연결 규격이지 신뢰 보증이 아니다
MCP 서버를 붙이면 GitHub, 데이터베이스, 사내 시스템의 자료와 도구를 같은 대화에서 사용할 수 있습니다. CLI는 클라이언트로서 필요한 기능을 요청하고, 서버가 외부 시스템과 통신한 결과를 모델에 돌려줍니다. 새 서비스마다 연결 코드를 제각각 만들지 않아도 되는 것이 장점입니다.
그러나 MCP라는 공통 형식이 서버의 안전성이나 데이터 정확성을 보증하지는 않습니다. 서버별로 읽기, 쓰기 권한, 접근 계정, 전송되는 필드와 감사 로그를 확인해야 합니다. 데이터베이스나 저장소에는 별도 최소 권한 계정을 쓰고, 삭제, 게시, 병합 같은 행동은 자동 호출 목록에서 빼는 편이 좋습니다.
MCP 연결에서는 어떤 경계를 그을까
서버가 반환한 텍스트도 신뢰하지 않은 입력으로 취급해야 합니다. 이슈 본문이나 외부 문서에 모델에게 다른 명령을 따르라고 적혀 있을 수 있고, 에이전트가 그것을 사용자 지시로 오해할 가능성이 있습니다. 외부 콘텐츠는 참고 자료일 뿐 권한을 늘리는 명령이 될 수 없다는 규칙과 도구별 허용 목록이 필요합니다.
읽기 서버와 쓰기 서버는 계정부터 분리하는 것이 좋습니다. 코드 검색에는 읽기 토큰을 쓰고, 이슈 수정이나 PR 생성이 필요할 때만 좁은 쓰기 권한을 별도 승인합니다. 자격 증명의 실제 값은 대화나 프로젝트 파일에 붙이지 않고 비밀 저장소나 환경 설정이 제공하도록 합니다. 로그에는 비밀 값을 가리면서 누가 어떤 도구를 어떤 인자로 호출했는지 남겨야 사후 검토가 가능합니다.
연결 장애도 시험합니다. MCP 서버가 늦게 응답하거나 잘못된 스키마를 반환했을 때 무한 재시도하지 않는지, 일부 자료만 받은 상태에서 변경을 시작하지 않는지 봅니다. 외부 시스템이 실패했을 때 로컬 파일까지 어중간하게 고쳐 둔다면 연결 편의보다 복구 부담이 커질 수 있습니다.
Plan Mode와 ask_user의 역할을 나눈다
원문이 소개한 Plan Mode는 코드를 바로 고치지 않고 읽기 중심으로 구조와 변경 계획을 만드는 단계입니다. ask_user는 연결 문자열이나 구현 선택처럼 모호한 조건을 모델이 임의로 채우지 않고 사용자에게 질문하게 합니다. Plan Mode 안내는 이 두 장치를 이해할 출발점입니다.
Plan Mode가 모든 위험을 없애지는 않습니다. 계획에 빠진 테스트나 잘못된 파일 범위가 없는지 사람이 확인하고, 쓰기 단계에서는 작은 패치 단위로 진행해야 합니다. 질문이 나왔을 때 비밀 값을 대화에 그대로 붙이기보다 환경 설정 경로와 사용 방법만 알려 주는 경계도 필요합니다.
계획을 승인할 때 무엇을 확인할까
계획에는 바꿀 파일, 바꾸지 않을 영역, 예상한 테스트와 실패 시 복구 방법이 있어야 합니다. “관련 코드를 수정한다”처럼 넓은 문장은 승인할 근거가 되지 않습니다. 기존 사용자 변경을 어떻게 보존할지, 새 의존성을 추가하는지, 네트워크나 외부 계정을 쓰는지도 쓰기 전에 드러나야 합니다.
ask_user가 묻는 선택지는 결과가 어떻게 달라지는지 함께 설명되어야 합니다. 데이터베이스를 어떤 것으로 쓸지처럼 큰 선택을 모델이 임의로 채우면 이후 코드가 모두 잘못된 가정 위에 놓입니다. 반대로 사소한 이름을 매번 묻게 하면 흐름이 멈춥니다. 공개 API, 데이터 보존, 권한과 되돌리기 어려운 변경은 질문하고 지역 변수 이름처럼 diff에서 쉽게 고칠 수 있는 세부는 프로젝트 규칙으로 처리합니다.
승인 뒤에도 패치가 계획과 일치하는지 확인합니다. 계획에 없던 파일, 잠금 파일이나 설정이 바뀌면 그 이유를 묻고 작업을 잠시 멈춥니다. 계획 승인은 이후 모든 행동에 대한 포괄 권한이 아니라 합의한 작은 범위에 대한 권한입니다.
실제 도입은 작은 저장소에서 검증한다
첫 시험은 민감정보가 없고 테스트가 빠른 저장소에서 하는 것이 좋습니다. 읽기 전용 분석, 한 파일 수정, 테스트 실행 순으로 권한을 넓히며 각 단계의 도구 호출과 diff를 확인합니다. 같은 작업을 사람이 했을 때와 비교해 완료 시간, 잘못 읽은 파일, 재시도, 리뷰 수정량을 기록하면 편의가 실제 이득인지 알 수 있습니다.
원문에는 개인 계정의 호출 한도, 100만 토큰 컨텍스트와 검색 Grounding 같은 수치와 기능도 소개되지만 이는 시점과 계정에 따라 달라질 수 있는 스냅샷입니다. 설치와 사용 한도를 고정 사실로 가정하지 말고 저장소와 연결된 공식 안내를 확인해야 합니다. 터미널 에이전트의 가치는 통제권을 통째로 넘기는 데 있지 않고, 사람이 검토할 수 있는 범위에서 탐색과 반복 작업을 줄이는 데 있습니다.
실패와 비용을 포함해 어떻게 평가할까
대표 작업을 수동 방식과 Gemini CLI 방식으로 각각 수행하고 결과를 같은 테스트로 확인합니다. 에이전트 쪽에는 계획 시간, 모델과 도구 호출, 잘못 읽은 파일, 재시도, 사람의 수정 줄 수와 전체 완료 시간을 남깁니다. 한 번 빠르게 성공한 데모보다 여러 작업의 중앙값과 실패 분포가 유용합니다.
권한 시험도 평가에 포함합니다. 금지한 파일을 읽으려 할 때 멈추는지, 테스트 실패 뒤 임의로 요구 사항을 낮추지 않는지, 삭제나 외부 게시 전에 승인을 요구하는지 확인합니다. 잘못된 변경을 발견했을 때 원래 사용자 수정은 보존하면서 자신의 패치만 되돌릴 수 있는지도 중요합니다.
토큰과 호출 한도는 바뀔 수 있으므로 고정된 무료 수치보다 작업당 실제 사용량을 기록합니다. 생산성 향상이 사람의 리뷰 시간을 줄이지 못하거나 반복 실패 비용을 더하면 범위를 축소해야 합니다. 반대로 명확한 반복 작업에서 수정량과 대기 시간이 안정적으로 줄어들 때 다음 저장소나 권한으로 확대할 근거가 생깁니다.
함께 읽으면 이해가 이어지는 글
- Qwen Code: 코드베이스 메모리와 MCP로 터미널에 구현한 완전 무료 AI 에이전트 — Qwen Code는 알리바바 Qwen 팀이 개발한 오픈소스 터미널 AI 코딩 에이전트입니다. 파일 시스템과 영구적인 메모리 계층을 갖추고 있으며, MCP(Model Context Protocol)를 통해 외부 도구와 상호작용합니다…
- AI 코딩 에이전트에 터미널 권한을 줘도 될까? Goose의 안전 경계 — Block의 오픈소스 에이전트 Goose가 명령 실행과 MCP 도구를 연결하는 방식을 살피고, 샌드박스, 최소 권한, 모델 선택의 실무 기준을 정리합니다.
- LLM 작업 하나에 LangChain이 꼭 필요할까? Axe 12MB CLI의 경계 — 단발성 LLM 작업을 UNIX 파이프라인에 붙이는 Axe의 장점과, 워크플로 엔진, 재시도, 권한 관리가 필요한 순간 드러나는 한계를 함께 짚습니다.
자주 묻는 질문
Gemini CLI에 처음부터 파일 쓰기와 셸 권한을 모두 줘도 되나요?
권장하지 않습니다. 읽기 전용 분석과 Plan Mode로 범위를 확인한 뒤 한 파일 수정, 테스트 실행 순으로 권한을 넓히고 삭제, 게시, 배포는 별도 승인을 두는 편이 안전합니다.
MCP 서버를 연결하면 외부 도구도 자동으로 안전해지나요?
아닙니다. MCP는 연결 규격이며 서버의 신뢰성이나 데이터 정확도를 보증하지 않으므로 계정 권한, 전송 필드, 쓰기 행동과 감사 로그를 서버별로 검토해야 합니다.
Gemini CLI의 생산성은 무엇으로 측정하나요?
완료 시간만 보지 말고 잘못 읽은 파일 수, 재시도, 사람의 diff 수정량, 테스트 누락, 모델, 도구 호출 비용과 실패 후 복구 시간까지 같은 작업의 수동 기준선과 비교해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.