Gemini CLI 서브에이전트: 계층형 오케스트레이션 아키텍처와 설계 원칙

2026년 4월, Google은 Gemini CLI에 서브에이전트 기능을 공식 추가했다. 복잡하고 반복적인 태스크를 전문화된 AI 에이전트에게 위임하고, 주 세션과 병렬로 실행하는 이 기능은 Claude Code가 선도해 온 서브에이전트 아키텍처 패턴을 CLI 에코시스템 전반으로 확산시키는 신호탄이 되었다.

격리성·명시성·투명성 위에 세운 구조

Gemini CLI 서브에이전트 시스템은 세 가지 핵심 원칙 위에 설계되었다. 첫째, 격리성이다. 각 서브에이전트는 독립적인 컨텍스트 윈도우, 전용 시스템 프롬프트, 분리된 도구 집합, 그리고 별도의 MCP 서버 연결을 가진다. 둘째, 위임의 명시성이다. 사용자는 프롬프트 문법을 통해 특정 에이전트에게 명시적으로 태스크를 할당할 수 있으며, 자동 라우팅에만 의존하지 않아도 된다. 셋째, 집계의 투명성이다. 서브에이전트가 수십 번의 도구 호출과 파일 탐색을 수행하더라도, 그 전체 실행 결과는 하나의 응답으로 주 에이전트에게 반환된다.

Gemini CLI가 기본 제공하는 내장 서브에이전트는 세 종류다. generalist는 모든 도구에 접근 가능한 범용 에이전트이고, cli_help는 Gemini CLI 자체에 대한 전문 지식을 보유한 에이전트이며, codebase_investigator는 아키텍처 매핑, 버그 원인 분석, 시스템 전체 의존성 파악에 특화된 코드베이스 탐색 전문 에이전트다.

어떤 태스크를 병렬로 돌릴 수 있는가

Gemini CLI 서브에이전트의 가장 강력한 특징은 병렬 실행 능력이다. 주 에이전트(오케스트레이터)는 태스크를 분해한 뒤, 독립적으로 실행 가능한 서브태스크들을 동시에 여러 서브에이전트에게 위임한다. 이 과정에서 핵심은 태스크 독립성 평가다.

병렬 실행 가능 여부를 결정하는 기준은 다음과 같다. 서브태스크 간 데이터 의존성이 없어야 하고, 공유 자원에 대한 쓰기 경합이 없어야 하며, 각 에이전트의 실행 결과가 다른 에이전트의 입력으로 필요하지 않아야 한다. 예를 들어 코드베이스에서 보안 취약점 분석과 성능 병목 분석은 동시에 수행할 수 있지만, 의존성 업데이트와 해당 의존성을 사용하는 코드 리팩토링은 순차적으로 실행해야 한다.

⤢✕

자원 제한 측면에서 Gemini CLI는 동시에 실행할 수 있는 서브에이전트 수를 제한하는 메커니즘을 제공한다. 이는 API 요금, 메모리 사용량, 네트워크 대역폭을 제어하는 데 중요하다. 각 서브에이전트의 컨텍스트 윈도우 크기도 별도로 설정할 수 있어, 경량 태스크에는 작은 컨텍스트를 할당하고 복잡한 분석 태스크에는 큰 컨텍스트를 부여하는 최적화가 가능하다.

Claude Code와 갈라지는 지점: 계층 구조 vs 피어투피어

두 시스템의 아키텍처는 유사한 목표를 추구하지만 설계 철학에서 명확한 차이를 보인다.

계층 구조 vs 피어-투-피어: Gemini CLI는 계층적(hierarchical) 모델을 채택했다. 주 에이전트가 유일한 오케스트레이터 역할을 하고, 서브에이전트 간에는 직접적인 통신이 없다. 반면 Claude Code의 에이전트 팀(Agent Teams) 기능은 에이전트 간 실시간 메시지 교환을 지원하는 피어-투-피어 협업 구조를 구현했다. 이 차이는 태스크 복잡성에 따라 실질적인 성능 차이를 만든다.

세션 관리: Gemini CLI 서브에이전트는 단일 세션 내에서 동작한다. 서브에이전트가 종료되면 그 컨텍스트는 사라진다. Claude Code 에이전트 팀은 다중 세션(multi-session)을 지원하여 장시간 실행되는 태스크를 여러 세션에 걸쳐 지속할 수 있다. 이는 대규모 리팩토링이나 장기 프로젝트에서 중요한 차이다.

태스크 위임 방식: Claude Code의 서브에이전트는 subagent_description 메타데이터를 기반으로 Claude가 자동으로 적합한 에이전트를 선택한다. Gemini CLI는 명시적 프롬프트 문법과 자동 라우팅을 모두 지원하여 사용자 제어권이 더 크다. 개발자 친화적인 접근이라 할 수 있다.

도구 접근 권한: 두 시스템 모두 서브에이전트별로 도구 접근을 제한할 수 있다. Claude Code의 경우 각 서브에이전트의 tools 필드에서 허용 도구 목록을 명시하고, Gemini CLI는 서브에이전트 정의 시 사용 가능한 MCP 서버와 내장 도구를 지정한다.

⤢✕

CLI 에이전트 생태계 전반의 수렴

Gemini CLI 서브에이전트 도입은 단순한 기능 추가가 아니라 CLI 에이전트 생태계 표준화의 신호다. Codex CLI, Claude Code, Gemini CLI 세 플랫폼 모두 2026년 1분기를 전후로 멀티에이전트 아키텍처를 핵심 기능으로 채택했다. 이 수렴은 몇 가지 공통 설계 원칙을 중심으로 이루어지고 있다.

역할 특화(Role Specialization)는 범용 에이전트 하나보다 특화된 여러 에이전트가 복잡한 태스크를 더 효율적으로 처리한다는 패러다임이다. 코드 리뷰 에이전트, 문서화 에이전트, 테스트 에이전트 등 역할 기반 서브에이전트 구성이 표준이 되고 있다. 컨텍스트 격리는 각 에이전트가 독립적인 컨텍스트를 유지함으로써 주 에이전트의 컨텍스트 오염을 방지하고, 복잡한 태스크를 더 예측 가능하게 처리하게 한다. 대규모 코드베이스 작업에서 특히 중요한 이점이다. 결과 집계 투명성은 서브에이전트의 중간 과정을 숨기고 최종 결과만 전달하는 추상화 레이어로 사용자 경험을 단순화하며, 동시에 로깅과 디버깅을 위한 실행 추적 기능도 병행 제공된다. 선언적 에이전트 정의는 YAML 또는 JSON 기반의 방식이 확산되고 있음을 뜻한다. Gemini CLI의 서브에이전트 설정 파일과 Claude Code의 subagent 디렉토리 기반 정의 모두 이 방향을 따른다.

실무 적용 시 고려할 것들

Gemini CLI 서브에이전트를 실제 개발 워크플로우에 도입할 때는 몇 가지 실용적 고려사항이 있다. 첫째, 태스크 분해 비용이다. 오케스트레이터가 태스크를 서브태스크로 분해하고 결과를 집계하는 과정 자체에도 API 호출 비용과 지연이 발생한다. 단순한 태스크라면 단일 에이전트 처리가 더 효율적일 수 있다. 둘째, 에러 전파 처리다. 서브에이전트 중 하나가 실패했을 때 전체 워크플로우를 어떻게 처리할지에 대한 명확한 정책이 필요하다. 재시도 로직, 폴백 에이전트, 부분 결과 활용 전략을 미리 설계해야 한다. 셋째, 컨텍스트 공유 한계다. 서브에이전트가 독립적인 컨텍스트를 갖는다는 것은 주 에이전트의 대화 이력이나 이전 작업 결과를 자동으로 공유하지 않는다는 의미다. 필요한 컨텍스트는 위임 시 명시적으로 전달해야 한다.

Gemini CLI 서브에이전트의 등장은 CLI 기반 AI 개발 도구가 단일 에이전트 모델에서 멀티에이전트 협업 모델로 전환하는 흐름을 공식화한 사건이다. Claude Code의 피어-투-피어 에이전트 팀과 Gemini CLI의 계층적 서브에이전트는 각기 다른 설계 철학을 유지하면서도, 태스크 위임·병렬 실행·결과 집계라는 공통 패턴을 수렴시키고 있다. 개발자 입장에서는 두 아키텍처의 트레이드오프를 이해하고, 태스크 특성에 맞게 선택하는 것이 2026년 CLI 에이전트 활용의 핵심 역량이 될 것이다.