Docker의 “Fleet” 사례는 AI 에이전트를 한두 번 실험해 본 이야기가 아니라, 제품 개발·테스트·릴리스·이슈 정리에 역할 기반 에이전트를 붙인 운영 사례다. 핵심은 에이전트 수를 늘리는 것이 아니라, 각 에이전트가 맡을 일과 맡기지 않을 일을 분명히 나눈 점이다.
핵심 요약
- Docker는 Coding Agent Sandboxes 팀에서 7개 역할의 가상 에이전트 팀을 운영해 테스트, 이슈 분류, 릴리스 노트 작성, 버그 수정 보조를 자동화했다고 설명한다.
- 각 에이전트는 단순 스크립트가 아니라 Claude Code Skill 형태의 “역할 설명”을 가진다. 실패했을 때 멈추는 자동화가 아니라, 조사하고 보고하는 역할에 가깝다.
- 중요한 설계 원칙은 로컬 우선, CI 확장이다. 먼저 개발자 노트북에서 같은 스킬을 돌려보고, 동작이 안정되면 GitHub Actions 같은 CI에 연결한다.
- 도입 전에는 병렬 실행 비용, 권한 범위, 실패 시 사람에게 넘기는 기준, 에이전트가 수정해도 되는 파일 범위를 정해야 한다.
Docker Fleet가 하는 일
원문에서 Docker는 Coding Agent Sandboxes, 즉 sbx 프로젝트를 대상으로 Fleet를 만들었다고 설명한다. sbx는 Claude Code, Gemini, Codex, Docker Agent, Kiro 같은 코딩 에이전트를 마이크로VM 기반 격리 환경에서 실행하기 위한 CLI 도구다. 이 도구 자체가 여러 OS, 업그레이드 경로, 네트워크 설정, 장시간 실행 안정성을 테스트해야 하므로 반복 검증 부담이 크다.
Docker는 이 부담을 하나의 거대한 에이전트에게 맡기지 않고 역할로 나눴다. CLI를 탐색적으로 테스트하는 역할, 빌드와 릴리스를 확인하는 역할, 이슈를 분류하는 역할, 릴리스 노트를 정리하는 역할처럼 사람 팀의 업무 구분을 에이전트에도 적용한 것이다.
스크립트와 다른 점
일반 CI 스크립트는 정해진 명령을 실행하고 결과가 다르면 실패한다. 반면 역할 기반 에이전트는 실패 이유를 읽고 다음 확인을 시도할 수 있다. 예를 들어 테스트가 실패했을 때 단순히 빨간불을 켜는 대신, 어떤 명령에서 실패했는지, 재현 가능한지, 기존 이슈와 중복되는지까지 정리할 수 있다.
물론 이 유연성이 장점만은 아니다. 에이전트가 스스로 판단하기 때문에 권한 경계와 산출물 형식이 더 중요해진다. “이슈를 정리하라”는 지시는 안전하지만, “필요하면 배포하라”는 지시는 위험하다. Docker 사례에서 배울 점은 자동화 범위를 좁게 쪼개고 각 역할의 책임을 문서화한 부분이다.
운영 설계에서 볼 포인트
| 설계 포인트 | 왜 중요한가 | 적용 기준 |
|---|---|---|
| 로컬 우선 | CI에서만 돌면 디버깅이 느리고 에이전트 행동을 관찰하기 어렵다. | 먼저 로컬에서 같은 스킬과 명령을 반복 실행해 혼동 지점을 줄인다. |
| 역할 분리 | 하나의 에이전트가 모든 권한을 가지면 실패 반경이 커진다. | 테스트, 이슈 분류, 릴리스 정리, 코드 수정 역할을 분리한다. |
| 권한 제한 | 에이전트가 CI 토큰, 릴리스 권한, 비밀값에 접근할 수 있다. | 읽기 전용 역할과 쓰기 가능 역할을 나누고 최소 권한 토큰을 사용한다. |
| 산출물 표준화 | 에이전트가 남긴 결과가 매번 다르면 리뷰 비용이 줄지 않는다. | 요약, 재현 단계, 위험도, 추천 조치 같은 출력 형식을 고정한다. |
| 사람에게 넘기는 기준 | 모호한 판단까지 자동화하면 잘못된 수정이 누적된다. | 보안·배포·삭제·외부 공개는 사람 승인으로 넘긴다. |
실제로 도움이 되는 상황
- CLI나 SDK처럼 테스트 조합이 많고 반복 검증이 많은 프로젝트
- 이슈가 자주 쌓여 triage만으로도 시간이 많이 드는 저장소
- 릴리스 노트, 변경 요약, 재현 단계 정리처럼 형식화 가능한 문서 작업
- 여러 OS·버전·업그레이드 경로를 매번 확인해야 하는 도구
도입 전에 피해야 할 착각
Fleet 방식은 “에이전트를 많이 띄우면 개발 속도가 무조건 빨라진다”는 뜻이 아니다. 병렬 에이전트는 로그와 리뷰도 병렬로 만든다. 산출물 형식이 정리되지 않으면 사람은 더 많은 결과를 검토해야 하고, 잘못된 수정이 여러 갈래로 생길 수 있다.
또한 CI에서 에이전트를 돌리는 순간 비용과 보안 문제가 함께 커진다. 실행 시간이 길어지고, 토큰 사용량이 늘고, 외부 API 호출이 많아질 수 있다. 따라서 처음부터 코드 수정 권한을 주기보다 테스트 보고서와 이슈 분류처럼 되돌리기 쉬운 작업부터 시작하는 편이 안전하다.
작게 테스트하는 방법
- 하나의 저장소에서 “테스트 실패 원인 요약”처럼 읽기 중심 역할 하나를 만든다.
- 로컬에서 같은 명령을 여러 번 실행해 출력 형식과 실패 기준을 고정한다.
- CI에는 PR 댓글 또는 아티팩트 업로드처럼 안전한 산출물만 남기게 한다.
- 2주 정도 사람이 직접 쓴 triage와 에이전트 요약을 비교해 정확도와 시간 절감 효과를 확인한다.
- 충분히 안정되면 코드 수정 제안까지 확장하되, 자동 merge나 배포는 마지막 단계로 둔다.
결론
Docker Fleet 사례의 가치는 화려한 에이전트 데모가 아니라, 에이전트를 운영 가능한 역할 단위로 쪼갠 데 있다. 에이전트 자동화는 “한 번에 많이 맡기기”보다 “반복 업무 하나를 좁게 맡기고 품질을 측정하기”에서 시작해야 한다.
ActualStack 관점에서 이 사례는 CI 자동화의 다음 단계로 볼 수 있다. 다만 성공 조건은 에이전트 성능보다 권한 설계, 로컬 재현성, 출력 형식, 사람 승인 기준에 있다.