Gemini CLI를 단순한 터미널 챗 도구로만 쓰면 활용 범위가 생각보다 빨리 한계에 닿습니다. 반대로 외부 도구를 연결하면 GitHub 이슈 확인, Slack 요약, 데이터 조회처럼 더 실무적인 흐름으로 확장할 수 있습니다. 여기서 핵심이 되는 구조가 MCP입니다.
이 글은 Gemini CLI MCP 사용법을 처음 보는 기준으로 정리한 글입니다. MCP가 무엇인지, 어디에 설정하는지, 어떤 도구부터 붙여보면 좋은지, 처음 연결할 때 어디서 가장 많이 막히는지를 순서대로 설명합니다.
Gemini CLI MCP 사용법은 외부 도구 연결이라는 말 때문에 어렵게 느껴지지만, 핵심은 연결 범위와 권한을 분명히 잡는 일입니다. 이 글은 처음 연결할 때 꼭 보는 기준을 순서대로 정리했습니다.
Table of Contents
MCP는 무엇을 위한 구조인가
공식 저장소 설명 기준으로 Gemini CLI는 MCP 서버를 통해 새 기능을 붙일 수 있습니다. 즉 모델이 기본으로 갖고 있지 않은 외부 도구 접근 능력을, 표준화된 서버 형태로 확장하는 방식입니다.
예를 들면 GitHub, Slack, 데이터베이스, 사내 API 같은 도구를 별도 MCP 서버로 연결할 수 있습니다.
설정은 어디에 두나
공식 저장소에는 ~/.gemini/settings.json에 MCP 서버를 설정하는 예시가 나옵니다. 따라서 처음에는 전역 설정 파일 위치부터 이해하는 편이 좋습니다.
~/.gemini/settings.json처음에는 모든 프로젝트에서 공통으로 쓸 연결만 전역에 두고, 프로젝트 특화 도구는 따로 관리하는 편이 안전합니다.
처음에는 어떤 도구를 붙여보면 좋을까
- GitHub: 이슈, PR, 리포지토리 흐름 확인
- Slack: 작업 요약 전송
- Database: 읽기 전용 질의
이 중에서도 가장 무난한 시작점은 GitHub 계열입니다. 개발 블로그 흐름에도 설명하기 쉽고, 실제로 연결 결과를 확인하기도 편합니다.
처음 연결할 때 자주 막히는 부분
설정 파일 위치를 잘못 잡는 경우
설정이 반영되지 않으면 경로부터 다시 확인하는 편이 빠릅니다.
도구는 연결했는데 실제 호출이 안 되는 경우
MCP 서버 실행 상태와 인증 정보를 같이 봐야 합니다. 모델 문제처럼 보여도 실제로는 서버 설정 문제일 때가 많습니다.
처음부터 너무 많은 도구를 붙이는 경우
이 경우 오히려 어디서 막혔는지 추적이 어려워집니다. 하나씩 붙여보는 편이 낫습니다.
│ 보안 체크: MCP 연결은 기능보다 최소 권한 설계가 먼저입니다
MCP는 외부 도구를 붙이는 순간 편해지지만, 동시에 권한 범위가 넓어질 수 있습니다. 그래서 연결 개수보다 중요한 건 어디까지 허용할지를 명확히 정하는 일입니다. 처음에는 읽기 전용 중심으로 시작하고, 꼭 필요한 작업에만 단계적으로 권한을 여는 방식이 안전합니다.
│ 외부 도구 연결 전에 점검할 4가지
- 개인용 키와 프로젝트용 키를 분리해 관리하기
- 불필요한 서버/툴 연결은 비활성화하고 필요한 것만 유지하기
- 토큰/비밀값은 설정 파일에 평문으로 남기지 않기
- 노출 의심 시 해당 키를 즉시 폐기하고 재발급하기
핵심은 “연결이 되는가”가 아니라 “노출 사고가 나도 피해를 작게 제한할 수 있는가”입니다.
정리
Gemini CLI MCP 사용법의 핵심은 복잡한 자동화보다, 필요한 외부 도구를 안정적으로 하나씩 붙이는 데 있습니다. 처음에는 GitHub처럼 확인이 쉬운 도구부터 연결하고, 설정 파일 위치와 인증 흐름을 먼저 잡는 편이 가장 현실적입니다.
참고한 공식 문서
- Google Gemini CLI GitHub repository