배경 및 맥락

코딩 에이전트와 CLI 에이전트는 빠르게 강력해졌지만, 실제 사용자는 긴 세션이 쌓일수록 성능 저하와 문맥 오염을 체감해 왔다. 하나의 세션이 조사, 설계, 코드 수정, 테스트, 문서 작성까지 모두 떠안으면 컨텍스트 창이 비대해지고, 중간 추론 흔적이 이후 의사결정 품질을 떨어뜨리는 문제가 발생한다.

Gemini CLI의 subagents는 이 문제를 세션 확장이 아니라 역할 분리로 해결하려는 시도다. 메인 에이전트는 전략과 최종 응답에 집중하고, 반복적이거나 고용량인 하위 작업은 별도의 컨텍스트와 도구 집합을 가진 specialist agent에게 위임하는 구조다. 이는 CLI 제품이 단순 채팅 UI가 아니라 팀형 오케스트레이션 런타임으로 진화하고 있음을 보여준다.

핵심 내용

Google Developers Blog에 따르면 subagent는 자체 context window, custom system instructions, curated tools, MCP servers를 가진 독립 실행 단위다. 실행 과정에서 발생한 수십 개의 tool call과 탐색 결과는 메인 세션에 요약된 응답으로만 되돌아와, 주 세션의 컨텍스트 밀도를 낮춘다.

정의 방식도 실용적이다. 사용자는 ~/.gemini/agents 또는 저장소 내부 .gemini/agents에 Markdown 파일과 YAML frontmatter로 subagent를 만들 수 있고, @frontend-specialist 같은 형태로 직접 호출할 수 있다. 또한 Google은 병렬 subagent 실행을 지원해 조사, 코드 탐색, 테스트 같은 작업을 동시에 분산할 수 있다고 설명했다. 반면 대규모 코드 편집을 병렬로 실행하면 충돌과 overwrite 위험이 커진다는 주의도 함께 제시했다.

경쟁 구도 / 비교

최근 Copilot, Claude 계열, 오픈소스 CLI 에이전트들도 장기 작업을 더 잘게 쪼개는 방향으로 진화하고 있다. 하지만 이번 발표의 차별점은 subagent를 숨겨진 내부 루프가 아니라 명시적인 제품 표면으로 올렸다는 점이다. 각 agent가 어떤 도구를 갖고 어떤 역할을 수행하는지 사용자가 파일로 정의하고 저장소에 공유할 수 있다는 점에서, 개인 프롬프트 해킹이 아니라 팀 단위 운영 모델에 가깝다.

이 구조는 소프트웨어 아키텍처의 microservice 분해와 유사하다. 단일 초대형 agent보다 supervisor와 specialist를 나누면 유지보수, 모델 교체, 권한 제한이 쉬워진다. 동시에 subagent 정의 자체가 조직의 작업 규칙과 전문성을 코드처럼 관리하는 새로운 단위가 될 수 있다.

의미

Gemini CLI subagents의 의미는 에이전트 UX가 대화형 assistant에서 delegation system으로 바뀌고 있다는 데 있다. 앞으로 핵심 경쟁력은 한 세션이 얼마나 똑똑한가보다, 작업을 얼마나 잘 분해하고 적절한 전문가에게 배분하며 결과를 다시 통합하는가에 있을 가능성이 높다.

실무적으로는 에이전트 도입 가이드를 role taxonomy와 tool governance 관점에서 다시 써야 한다. 어떤 subagent가 읽기 전용인지, 어떤 에이전트가 shell과 network에 접근 가능한지, 병렬 실행 시 어떤 파일 범위를 독점하는지를 명확히 정의해야 충돌과 보안 리스크를 줄일 수 있다.