배경 및 맥락

AI 코딩 도구의 초기 경쟁은 자동완성 정확도와 채팅 품질 중심이었다. 그러나 2026년 들어서는 여러 파일에 걸친 리팩터링과 테스트 수정, 문서 보완을 한 번에 처리하는 워크플로우가 핵심 경쟁 영역으로 올라왔다. 실제 소프트웨어 작업은 병렬화 가능한 하위 작업과 순차 의존 작업이 섞여 있기 때문이다.

기존 CLI형 코딩 에이전트는 긴 작업을 한 세션 안에서 직렬로 수행하는 경우가 많아, 컨텍스트가 비대해지고 작업 간 충돌이나 누락이 생기기 쉬웠다. GitHub가 /fleet를 전면에 내세운 것은 Copilot을 단순한 코드 생성기가 아니라 작업 관리자이자 오케스트레이터로 재정의하려는 움직임으로 볼 수 있다.

핵심 내용

GitHub 설명에 따르면 /fleet는 Copilot CLI 내부 오케스트레이터가 사용자의 목표를 받아 다음 순서로 처리한다.

• 작업을 의존 관계가 있는 discrete work item으로 분해
• 병렬 가능한 항목과 대기해야 하는 항목을 구분
• 독립 항목을 background sub-agent로 동시 실행
• 완료 상태를 폴링한 뒤 다음 wave를 배치
• 결과를 검증하고 최종 산출물로 합성

각 sub-agent는 자체 컨텍스트 윈도우를 가지지만 동일한 파일시스템을 공유한다. GitHub는 이 구조의 장점과 함께 위험도 명시했다. 같은 파일을 두 에이전트가 동시에 수정하면 마지막 writer가 덮어쓰는 구조이므로, 프롬프트에서 파일 경계와 책임 범위를 분명히 나누는 것이 중요하다고 안내한다. 또한 비대화형 실행 시 copilot -p "/fleet <task>" --no-ask-user 형태도 지원한다.

경쟁 구도 / 비교

이 기능은 AI 코딩 도구 시장이 더 똑똑한 한 명의 에이전트에서 협업하는 여러 에이전트로 이동하고 있음을 보여준다. Cursor가 병렬 서브에이전트와 BugBot류 검토 흐름으로 앞서가고, Claude Code 계열이 작업 루프와 도구 호출 구조에서 강점을 보여준 상황에서 GitHub는 Copilot CLI에 명시적 병렬화 인터페이스를 추가해 대응했다.

차별점은 사용자에게 병렬화 규칙을 노출했다는 점이다. GitHub는 deliverable 단위 분해, 파일 경계 지정, 의존 관계 선언, 검증 기준 명시 같은 운영 규칙을 제품 사용법 자체에 포함시켰다. 이는 단순한 모델 업그레이드가 아니라 에이전트 운영 방법론을 제품 안에 집어넣은 사례다.

의미

/fleet의 등장은 AI 코딩 생산성의 병목이 모델 품질만이 아니라 작업 설계 능력이라는 점을 분명히 보여준다. 앞으로 개발팀의 차별화 포인트는 어떤 모델을 쓰느냐보다, 에이전트에게 일을 어떻게 분해해서 맡기고 검증 루프를 어떻게 붙이느냐가 될 가능성이 크다.

테크 리더 관점에서는 에이전트 친화적인 저장소 구조와 작업 단위 설계가 중요해진다. 문서, 테스트, 구현, 마이그레이션을 독립적으로 실행 가능한 경계로 관리하는 팀이 병렬 에이전트의 이점을 가장 먼저 흡수하게 된다.