「한 대의 코딩 에이전트와 대화하며 코드를 작성하는」 단계에서, 「여러 에이전트를 동시에 실행하고 그 군단(fleet)을 설계·감독하는」 단계로——2025년부터 2026년에 걸쳐 개발 현장에서는 이 전환을 지칭하는 용어들이 여러 개 등장했습니다. 그중 하나가 플릿 엔지니어링 (fleet engineering) 입니다.

이 기사에서 알 수 있는 점은 다음 세 가지입니다.

• 「플릿 엔지니어링 (fleet engineering)」이라는 용어가 가리키는 것과, 그 용법이 두 계통으로 나뉘어 있는 실상
• 왜 단일 에이전트에서 「군단」 운용으로 향하는가, 그 기술적 배경
• 군단을 돌리기 위한 대표적인 아키텍처·운용 패턴과 그 한계

대상 독자는 Claude Code, Cursor, GitHub Copilot 등의 코딩 에이전트를 일상적으로 사용하고 있으며, 「여러 개를 동시에 구동하는 운용」에 관심이 있는 개발자입니다. 전제 지식은 LLM을 사용한 코딩 지원 도구를 한 번이라도 접해본 정도면 충분합니다.

참고로 필자는 이 기사를 작성하기 위해 각사의 1차 정보(공식 블로그·문서)를 추적하여 정리했습니다. 용어의 해상도가 아직 낮은 영역이므로, 사실과 필자의 추측은 구분하여 작성했습니다.

먼저 솔직히 말씀드리면, 「fleet engineering」은 아직 확립된 정의를 가진 단일 조어(造語)가 아닙니다. 2025~2026년에 여러 당사자가 병행하여 사용하기 시작한, 수렴 과정에 있는 호칭입니다. 그리고 용법이 크게 두 가지로 나뉘어 있습니다.

하나는, 기업 내에서 다수의 에이전트를 통치·운용한다는 거버넌스(governance) 측면의 의미입니다. 예를 들어 Cobus Greyling 씨는 fleet engineering을 「프로덕션 소프트웨어에 요구되는 것과 동일한 엄격함으로, 조직 횡단적으로 다수의 에이전트를 운용하는 규율」이라고 정의하고 있습니다 (Cobus Greyling, 2026-06-18). 이 문맥에서는 LangChain의 「LangSmith Fleet」과 같이 업무 에이전트 전반을 build/use/manage 하는 프로덕트가 배경에 있습니다 (LangChain Blog, 2026-03-19).

또 다른 하나는, 이 기사에서 다루는 개발자가 여러 코딩 에이전트를 병렬로 실행하여 설계·감독하는 개발 규율입니다. 이쪽은 "fleet engineering"이라는 숙어보다는, "running a fleet"나 "agentic engineering"이라는 표현으로 불리는 경우가 많은 것이 실태였습니다.

주목할 점은, 코딩 문맥에서 "fleet"을 명확하게 기능명으로 채택한 가장 이해하기 쉬운 1차 소스가 GitHub라는 점입니다. GitHub Copilot CLI의 /fleet 명령어는 「여러 서브 에이전트를 병렬로 동시 가동시키는」 기능으로 정의되어 있습니다 (GitHub Blog, 2026-04-01). Docker도 사내 CI에서 구동되는 7개의 에이전트 역할을 "a fleet of agents"라고 부르고 있습니다 (Docker Blog, 2026-05-01).

즉, 「fleet engineering」이라는 용어의 최초 사용자를 일의적으로 특정하는 것은 필자가 조사한 범위 내에서는 불가능했습니다. 동시다발적으로 태어난 수렴어라고 파악하는 것이 타당해 보입니다.

배경에는 몇 가지 기술적인 압력이 있습니다.

병렬화가 곧바로 스코어와 속도에 영향을 미친다. Anthropic은 리드 에이전트가 3~5대의 서브 에이전트를 동시에 spawn 하는 구성으로, 복잡한 조사 태스크의 시간을 최대 90% 단축하며 단일 에이전트를 크게 상회했다고 보고했습니다. 나아가 「토큰 사용량만으로 성능 분산의 80%를 설명할 수 있다」고도 언급했는데, 이는 탐색을 병렬로 확장하여 계산을 투입할 수 있다는 것 자체가 품질에 영향을 미친다는 시사입니다 (Anthropic Engineering, 2025-06-13).

컨텍스트 길이(context length)의 한계. 단일 에이전트의 문맥 창(context window)은 유한하며, 대규모 마이그레이션이나 횡단 감사에서는 넘치게 됩니다. 서브 에이전트에게 전용 컨텍스트로 작업을 시키고 요약만 반환하게 하면, 주 대화를 오염시키지 않고 해결할 수 있습니다 (Claude Code Docs).

작업 격리 기술의 보급. 여러 에이전트가 동일한 리포지토리에서 충돌 없이 작동하는 토대로 git worktree를 통한 분리가 정착되었습니다. Cursor 2.0은 최대 8대를 병렬로 실행하며, worktree나 원격 머신을 통해 파일 충돌을 방지하고 각 에이전트에게 독립된 복사본을 부여합니다 (Cursor 2.0 Changelog).

하지만 이러한 동기는 동시에 제약 사항이기도 합니다. Anthropic은 "에이전트는 채팅의 약 4배, 멀티 에이전트(Multi-agent)는 약 15배의 토큰을 사용한다"며, 이는 태스크의 가치가 높을 경우에만 성립한다고 명시했습니다. "왜 지금인가"에 대한 답은 곧 "어디에서 사용해야 하는가"에 대한 답이기도 합니다.

군단(Fleet)을 운영하는 방식에는 몇 가지 반복적으로 등장하는 패턴이 있습니다.

중심이 되는 것은 이 패턴입니다. 리드 에이전트(Lead Agent, 오케스트레이터)가 복잡한 태스크를 구체적인 소규모 태스크로 분해하고, 여러 서브 에이전트(Sub-agent)를 기동하여 병렬로 처리하게 한 뒤 결과를 통합합니다.

중요한 점은 GitHub /fleet의 설계가 명시하고 있듯이, 서브 에이전트끼리는 직접 대화하지 않으며 오케스트레이터만이 조정한다는 점입니다. 각 서브 에이전트는 자신만의 전용 컨텍스트 윈도우(Context Window)를 가지지만, 파일 시스템은 공유합니다 (GitHub Blog).

또 다른 핵심은 구현하는 에이전트와 평가하는 에이전트를 분리하는 것입니다. Docker는 "Ralph-loop"라고 부르는 메커니즘을 통해, 워커(Worker)가 구현하고 독립된 리뷰어가 차이점(Diff)을 평가하며, 인간의 리뷰 전에 최대 5회까지 반복(Iteration)하게 합니다. 각 반복은 별도의 모델 호출로 이루어집니다 (Docker Blog).

생성물이 늘어날수록 검증의 체계화가 필요합니다. Docker의 플릿(Fleet)은 "PR(Pull Request)은 만들지만 머지(Merge)는 하지 않는다"고 명시하고 있습니다. 승인과 머지는 인간이 담당하는 것입니다. GitHub /fleet에서도 오케스트레이터가 각 서브 에이전트의 출력을 검증한 후 최종 결과물을 조립합니다.

지금까지 병렬 운용의 장점을 기술했지만, 강력한 반대론이 존재한다는 점도 유념해야 합니다.

Cognition(Devin 개발사)의 Walden Yan은 "Don't Build Multi-Agents"를 통해, 멀티 에이전트는 의사결정이 너무 분산되어 취약하며, 병렬 에이전트는 충분한 공유 문맥(Shared Context)이 부족하여 해석이 충돌한다고 주장했습니다. 제시된 원칙은 "메시지 단체가 아니라 에이전트의 전체 트레이스(Trace)와 문맥을 공유하라", "행동은 암묵적인 결정을 수반하며, 모순된 결정은 나쁜 결과를 낳는다"는 것입니다 (Cognition, 2025-06-12). 그는 서로의 작업을 보지 않고 UI 컴포넌트를 별도로 만들면 시각적 스타일이 어긋나는 사례를 들며, **단일 스레드의 선형 에이전트(Linear Agent)**를 권장했습니다.

흥미로운 점은 양 진영 모두 "공유 문맥의 결여야말로 실패 요인"이라는 진단에는 일치한다는 것입니다. 의견이 갈리는 지점은 처방전입니다. Cognition은 "피하라(선형으로 가라)"는 입장인 반면, Anthropic, GitHub, Docker는 "독립적으로 분할 가능한 탐색·검증 태스크라면 병렬 방식이 승리한다. 단, 문맥 공유와 검증을 설계하라"는 입장입니다.

보충하자면, Walden Yan은 이후 "실제로 작동하는 구성도 몇 가지 발견되었다"는 취지의 발언을 한 것으로 알려져 있으나, 필자는 원문 포스트의 전문을 확보하지 못해 확증할 수 없습니다 (검증 필요).

즉, 실무상의 함정은 상호 의존성이 강한 작업을 무리하게 병렬화하는 것으로 요약됩니다. 병렬화를 통해 승리할 수 있는 시점은, 독립적으로 분리할 수 있는 태스크에 문맥 공유와 검증을 설계로서 얹었을 때뿐이라는 것이 현시점의 결론입니다.

1차 정보에서 얻을 수 있는 실천적 지식을 필자 나름대로 정리하면 다음과 같습니다.

• 태스크는 '독립성'을 기준으로 나눈다. 상호 의존성이 강한 작업은 병렬화하지 않는다.
• worktree로 격리한다. 동일한 파일을 다루는 태스크는 별도의 체크아웃(Checkout)으로 분리한다.
• 사양(Acceptance Criteria) 기반으로 리뷰하고 순차적으로 머지한다. 모든 브랜치를 한꺼번에 머지하지 않는다.
• 생성과 평가를 분리한다. 구현 에이전트와 독립 리뷰어를 분리하고, 인간의 리뷰 전에 자동 반복 단계를 거친다.
• 비용은 가치로 정당화한다. 멀티 에이전트는 15배의 토큰을 사용한다는 전제하에, 가치·병렬도·비용의 균형을 사전에 산출한다.

엔지니어의 역할은 "코드를 쓰는 사람"에서 "사양을 작성하고, 작업을 분해하며, 군단의 출력을 검증하고 감독하는 사람"으로 이동하고 있습니다. GitHub은 개발자를 "팀에 업무를 할당하는 프로젝트 리드(Project Lead)"에 비유했는데, 이 비유가 플릿 엔지니어링(Fleet Engineering)의 본질을 잘 나타내고 있다고 생각합니다.

플릿 엔지니어링(Fleet Engineering)은 아직 용어로서 확립되지 않았습니다. 엔터프라이즈의 에이전트 거버넌스 (Agent Governance)를 지칭하는 용법과, 코딩 에이전트 (Coding Agent)의 병렬 운용을 지칭하는 용법이 병행되고 있습니다. 다만, 후자의 실체인 —— 오케스트레이터 (Orchestrator) + 서브 에이전트 (Sub-agent), 워크트리 (Worktree) 격리, 생성과 평가의 분리, 휴먼 인 더 루프 (Human-in-the-loop) —— 는 각 기업의 1차 정보에서 실제로 작동하고 있으며, 무시할 수 없는 트렌드입니다.

한편, Cognition의 "공유 컨텍스트를 깨뜨리지 마라"라는 지적은 지금도 유효한 설계 제약입니다. 승리 공식은 "독립적으로 분할 가능한 태스크 (Task) × 컨텍스트 공유와 검증의 설계"입니다. 이 두 가지가 갖춰지지 않는다면, 아직은 단일 선형 에이전트 (Linear Agent)로 신중하게 진행하는 것이 더 빠르다는 것이 필자의 솔직한 결론입니다.

실제로 에이전트 군단을 돌려본 지견이나, 성공했거나 실패했던 구성이 있다면 꼭 댓글로 알려주세요.

• How we built our multi-agent research system — Anthropic Engineering (2025-06-13)
• Run agents in parallel — Claude Code Docs
• Run multiple agents at once with /fleet in Copilot CLI — GitHub Blog (2026-04-01)
• A Virtual Agent team at Docker: a fleet of agents — Docker Blog (2026-05-01)
• Cursor 2.0 Changelog (2025-10-29)
• Don't Build Multi-Agents — Cognition, Walden Yan (2025-06-12)
• Introducing LangSmith Fleet — LangChain Blog (2026-03-19)
• Fleet Engineering — Cobus Greyling (2026-06-18)
• Agentic Engineering: Running Parallel AI Coding Agents — amux (2026)