AI Native Notes
Gemini CLI로 돌아가기
Gemini CLI고급10분 소요

Gemini Extensions & MCP — 커스텀 워크플로 만들기

Gemini CLI 확장 시스템, MCP 연동, 그리고 강력한 Agent Skills를 활용한 커스텀 워크플로 설계법

확장mcphooksskills커스터마이징

공식 레퍼런스: Extensions 개요 · Extension reference · Skills · Tools

학습 경로

  1. Gemini CLI 시작하기 — 설치, 인증, 메모리 기초
  2. 100만 토큰의 장점 — 전체 코드베이스로 작업하기 — 저장소 단위 분석을 낭비 없이
  3. Gemini Extensions & MCP — 커스텀 워크플로 만들기 — 명령, MCP, 스킬 패키징 ← 현재 문서
  4. Gemini CLI MCP 연동 — 외부 도구와 데이터 연결하기
  5. Trusted Folders, Sandboxing, 그리고 Restore — 신뢰, 격리, 복구
  6. Gemini Task Decomposition — 복잡한 작업을 성공적으로 완수하기
  7. Gemini CLI Headless Automation — 스크립트, CI, 구조화 출력
  8. Gemini Git Worktrees — 병렬 작업 최적화
  9. 서브 에이전트와 스킬 오케스트레이션 — 위임과 전문가 워크플로
  10. GEMINI.md Mastery — 계층적 컨텍스트 설계
  11. Gemini 첫날 안전 루프
  12. Multi-Agent Orchestration — 서브 에이전트와 스킬 조합
  13. Gemini 주간 단위 딜리버리 플레이북
  14. Gemini GitHub Actions — CI 자동화와 리뷰
  15. Gemini 고위험 변경 통제 모델
  16. Gemini Effective Prompting — 100만 토큰을 지배하는 프롬프팅
  17. Gemini 운영 매뉴얼 — 팀 단위 CLI 딜리버리 리듬
  18. Gemini Hooks Automation — 로컬 자동화의 방패
  19. Gemini 사고 복구 플레이북
  20. Mid-size Refactor Playbook — 중규모 리팩터링
  21. Gemini 사고 후 하드닝 루프
  22. Gemini 카오스 복원력 드릴
  23. Human-Agent Handoffs — 인간과 AI의 릴레이
  24. Ralph Persistence Loops — 끝까지 물고 늘어지는 자가 치유
  25. Gemini 복원력 지표와 SLO
  26. Release Readiness Automation — 배포 자동화
  27. ADR Automation — 아키텍처 결정 기록 자동화

이 문서에서 참고한 공식 문서

Extensions는 "플러그인 하나"보다 훨씬 넓은 개념이다

많은 사람이 extension을 들으면 “명령 하나 추가하는 작은 플러그인” 정도로 떠올립니다. 하지만 Gemini CLI 문서가 설명하는 extension은 훨씬 넓습니다.

extension은 여러 워크플로 표면을 한 번에 묶을 수 있습니다.

  • 재사용 가능한 prompts / commands
  • MCP 서버 연결
  • hooks / policies
  • sub-agents
  • agent skills
  • extension 범위의 설정

즉 extension의 본질은 기능 추가가 아니라 운영 패키징입니다. “이 저장소를 이렇게 읽고, 이 시스템과 연결하고, 이 절차대로 검토하라”를 팀 단위로 배포하는 형식에 더 가깝습니다.

먼저 "정말 extension이 필요한가"부터 판단하자

커스터마이징 수단은 여러 개라서, 가장 무거운 방법부터 고르면 오히려 관리가 어려워집니다.

필요 가장 잘 맞는 표면 이유
저장소 규칙 고정 GEMINI.md 가장 단순하고 항상 적용됨
외부 시스템 접근 MCP DB, 문서, 티켓 시스템 연결에 적합
한 가지 전문가 절차 Skill 행동 규칙을 강하게 바꾸기 좋음
여러 명령·스킬·MCP를 팀에 배포 Extension 운영 패키지로 공유하기 좋음

좋은 순서는 대체로 이렇습니다.

  1. GEMINI.md로 규칙을 고정한다.
  2. 수동 프롬프트로 워크플로를 검증한다.
  3. 반복되면 skill로 승격한다.
  4. 팀 배포가 필요해질 때 extension으로 묶는다.

실전용 extension은 "적게 담을수록" 강하다

좋은 extension은 이것저것 다 넣은 만능 꾸러미가 아닙니다. 보통 아래 네 가지면 충분합니다.

  1. 자주 쓰는 명령 1~3개
  2. 진짜 가치가 큰 MCP 1~2개
  3. 명확한 목적의 skill 1개
  4. 과도한 권한을 막는 policy / guardrail

문서에서 manifest와 정책 필드를 굳이 자세히 제공하는 이유도 여기 있습니다. command만 추가하는 수준을 넘어서, “어떤 도구를 막을지”, “어떤 설정을 민감 정보로 취급할지”, “어떤 컨텍스트 파일을 읽게 할지”까지 설계해야 실무용 extension이 됩니다.

많은 팀은 사실 skill부터 시작하는 편이 맞다

Gemini CLI에서 가장 빠르게 체감되는 커스터마이징은 full extension보다 skill인 경우가 많습니다.

왜 skill이 좋은 출발점이냐면:

  • 범위가 좁아서 검토하기 쉽고
  • 절차를 문서가 아니라 실행 규칙으로 고정할 수 있고
  • 같은 작업을 반복 호출하기 좋고
  • 무엇을 "완료"로 볼지 명확히 정하게 만들기 때문입니다.

예를 들면 이런 skill이 좋습니다.

  • locale-review — 번역 패리티 점검
  • docs-qa — frontmatter / 링크 / 설명 품질 검토
  • release-note-drafter — 릴리즈 노트 초안 생성
  • security-review 변형 — 우리 조직 위협 모델에 맞춘 보안 리뷰

skill이 충분히 유용해졌을 때 commands, hooks, MCP와 함께 extension으로 묶는 편이 가장 자연스럽습니다.

extension 설계도 저장소 trust 모델을 따라가야 한다

공식 문서를 읽어보면 extension은 CLI의 trust / safety 세계 바깥에 따로 존재하지 않습니다. 결국 같은 세션 안에서 작동하기 때문에, 설계할 때도 “낯선 동료가 설치해서 바로 감사할 수 있는가?”를 기준으로 봐야 합니다.

체크 포인트는 이렇습니다.

  • 위험한 명령은 숨기지 말고 노출하기
  • read-only 도우미부터 우선 제공하기
  • secrets / 환경변수 접근을 민감한 설정으로 취급하기
  • extension이 repo workflow를 어떻게 바꾸는지 README에 적기
  • auto-approve처럼 놀라운 동작을 남기지 않기

extension이 성공적이라는 건 설치 후에 팀원이 아래 질문에 답할 수 있다는 뜻입니다.

이 extension은 무엇을 추가하나? 어떤 도구와 시스템을 만지나? 설치했을 때 어디가 위험해질 수 있나?

도입은 "수동 검증 → skill → MCP → extension" 순서가 좋다

1단계: 수동으로 먼저 검증

프롬프트와 GEMINI.md만으로도 충분히 유용한지 확인합니다.

2단계: 반복 행동을 skill로 캡슐화

skill-creator를 쓰거나 SKILL.md를 직접 작성해 절차와 제약을 고정합니다.

3단계: 복붙이 병목일 때만 MCP 추가

Jira, CMS, 내부 문서처럼 매번 붙여 넣는 외부 정보가 생겼을 때 구조화 연결로 전환합니다.

4단계: 팀 배포가 필요하면 extension으로 패키징

이 시점의 extension은 목적이 분명합니다. 배포, 일관성, 온보딩 속도입니다.

AI Native Notes라면 이런 extension이 어울린다

이 저장소가 계속 커진다면 Gemini extension은 아마 아래 조합이 좋습니다.

  • ko / en / es slug parity 점검 command
  • MDX frontmatter와 broken link를 보는 content-audit skill
  • 나중에 CMS나 문서 인벤토리와 연결할 MCP
  • 과도한 자동 콘텐츠 수정 작업을 막는 좁은 policy

공통점이 있습니다. 모두 이미 존재하는 편집 운영을 패키징할 뿐, 새로운 혼란을 만들지 않습니다.

extension 출고 전 체크리스트

팀에 공유하거나 배포하기 전에는 아래를 꼭 확인하세요.

  • extension 없이도 그 워크플로가 이미 유용한가?
  • 다른 엔지니어가 짧은 시간 안에 audit할 수 있을 만큼 범위가 좁은가?
  • 위험한 도구는 opt-in인가?
  • 어떤 MCP / settings / policies가 들어오는지 팀이 이해하고 있는가?
  • 사실 GEMINI.md나 단독 skill이면 충분한 문제는 아닌가?

앞 네 개가 yes, 마지막이 no라면 extension으로 승격할 이유가 충분합니다.

다음에 읽으면 좋은 글

연결된 가이드