Docker Agent, 에이전트를 배포 가능한 설정으로

Docker Agent 공식 저장소는 AI 에이전트를 YAML로 정의하고 실행·공유하는 도구를 소개한다. Docker CLI 플러그인으로 docker agent 명령을 제공하며, 역할별 에이전트 구성, 도구 연결, 여러 모델 공급자와의 통합을 지원한다. 이번 글은 10월 8일 확인한 공개 저장소와 문서의 현재 상태를 분석한 것으로, 이날 처음 출시됐다는 의미는 아니다.

관심을 끄는 부분은 새로운 대형 모델이 아니라 에이전트의 작업 구성을 팀이 배포하고 관리하는 형식이다. 프롬프트를 개인 메모에 보관하는 대신 코드처럼 검토하고 버전을 붙일 수 있다. 그러나 Docker라는 이름이나 OCI 배포 형식이 에이전트의 모든 행동을 자동으로 격리해 준다고 생각해서는 안 된다.

YAML과 OCI는 에이전트를 팀의 자산으로 만든다

저장소 README는 에이전트의 모델, 설명, 지시문, 도구 묶음을 YAML로 지정하는 구조를 보여준다. 내장 도구뿐 아니라 로컬·원격·Docker 기반 MCP 서버를 연결하고, 역할을 나눈 에이전트가 작업을 위임하도록 구성할 수 있다. 검색 증강 생성에는 BM25, 임베딩, 하이브리드 검색과 재정렬 등의 선택지를 제시한다.

OCI 레지스트리에 에이전트를 푸시하고 가져와 실행하는 기능은 컨테이너 운영에 익숙한 조직에 자연스럽다. 코드 리뷰용 에이전트와 문서 점검용 에이전트를 공통 패키지로 배포하면 팀마다 지시문을 복사하다 생기는 차이를 줄일 여지가 있다. 다만 패키지가 같아도 모델 버전이나 검색 데이터가 달라지면 결과는 달라질 수 있다.

이 방향은 Google AX의 선언형 오케스트레이션과 맞닿아 있다. 차별화의 기준은 설정 문법의 짧음보다 기존 개발·배포 체계에 얼마나 자연스럽게 들어오느냐다.

여러 모델을 연결해도 비용과 품질은 자동 최적화되지 않는다

모델 설정 문서는 클라우드 공급자, Docker Model Runner를 통한 로컬 모델, 자체 호환 엔드포인트 등 여러 경로를 설명한다. 로컬 추론을 선택하면 외부 모델의 토큰 과금 없이 실행할 수 있지만, 하드웨어와 전력, 지연 시간의 비용까지 사라지는 것은 아니다.

더 중요한 점은 모델만 로컬이라고 전체 워크플로가 로컬이 되는 것은 아니라는 사실이다. 웹 검색이나 원격 MCP 도구를 연결하면 해당 도구로 정보가 나갈 수 있다. 국내 기업이 소스 코드나 고객 데이터를 다룬다면 모델의 위치와 도구의 네트워크 경로를 따로 확인해야 한다.

문서는 명시적 모델을 지정하지 않았을 때 자격 증명이 설정된 클라우드 공급자를 선택하고 로컬 모델로 폴백할 수 있는 자동 선택 방식도 설명한다. 따라서 로컬 전용 정책이 필요한 환경에서는 의도를 명확히 설정하고 실행 전 확인하는 편이 낫다. 여기서 문서의 기능 설명은 제품 사용법에 관한 것이며, 이번 기사 작성 과정에서 모델 호출이나 에이전트 실행을 시험한 것은 아니다.

배포 가능한 에이전트와 재현 가능한 실행은 다르다

멀티에이전트 문서는 OCI 레지스트리의 외부 에이전트를 하위 에이전트로 참조하는 구성을 소개한다. 태그는 바뀔 수 있으므로 문서는 불변 digest로 고정하는 방법도 권한다. 이는 동일한 이름을 가져왔는데 다음 날 지시문이나 도구 구성이 달라지는 문제를 줄이는 데 의미가 있다.

다만 이 문서 사이트는 main 브랜치를 추적하며 미출시 기능을 포함할 수 있다고 명시한다. 조직이 실제 설치한 릴리스에서 지원되는지 확인하지 않고 문서 예제를 바로 운영 표준으로 삼으면 안 된다. README가 제시하는 설치 경로, 릴리스 버전, 안정 문서를 함께 대조해야 한다.

재현성을 높이려면 에이전트 패키지 외에 모델 식별자, 검색 인덱스의 생성 시점, 도구 버전, 입력 데이터와 실행 결과를 기록해야 한다. Pi의 코드 기반 도구 조합처럼 호출 구성이 유연해질수록 어떤 경로로 결과가 나왔는지 추적하는 일이 중요해진다.

한국 개발팀은 읽기 전용 업무부터 운영 규칙을 만들 수 있다

도구 개념 문서를 보면 에이전트의 행동 범위는 연결된 도구에 의해 넓어진다. 파일 읽기와 셸 실행, 원격 서비스 변경은 같은 수준의 권한이 아니다. 코드 리뷰를 맡긴 에이전트에 배포 자격 증명까지 제공할 이유는 없으며, 역할별 최소 권한을 설정하는 것이 합리적이다.

실무 도입의 첫 후보는 릴리스 노트 초안이나 문서와 코드의 차이 탐지다. 결과를 파일로 남기되 외부 반영은 기존 리뷰 경로에 연결하면 평가가 쉽다. 이후 쓰기 작업을 늘릴 때는 재시도한 작업이 동일한 이슈나 배포를 중복 생성하지 않는지 살펴봐야 한다. Restate의 에이전트 재시작 문제는 패키지 배포와 실행 상태 관리가 별개라는 점을 보여주는 관련 분석이다.

성과 지표로는 설정 작성 시간뿐 아니라 새 팀원의 환경 재현 시간, 도구 오류율, 사람이 수정한 결과의 비율을 함께 볼 수 있다. Docker Agent의 기회는 에이전트 구성과 운영을 개발팀이 익숙한 자산 관리 방식으로 가져오는 데 있다. 그 가능성이 실제 운영 품질이 되는지는 버전·권한·실패 복구를 얼마나 명시적으로 다루느냐에 달렸다.

FAQ

Docker Agent는 새로운 언어 모델인가?

아니다. 모델과 도구를 연결하고 에이전트 구성을 실행·공유하는 런타임과 구성 도구다. 모델 자체의 품질과는 구분해야 한다.

로컬 모델만으로 사용할 수 있는가?

공식 문서는 Docker Model Runner 경로를 안내한다. 다만 연결한 외부 도구가 통신할 수 있으므로 전체 데이터 흐름은 별도로 점검해야 한다.

모든 에이전트가 컨테이너 안에 자동 격리되는가?

저장소 소개만으로 그런 보장을 할 수 없다. 도구의 실행 방식, 파일 접근, 네트워크와 샌드박스 설정을 실제 환경에서 확인해야 한다.

YAML 파일만 같으면 결과도 같은가?

아니다. 모델 버전, 외부 데이터, 도구 상태와 실행 시점이 영향을 준다. 구성의 재현성과 결과의 동일성은 다른 개념이다.

문서에 있는 기능을 바로 써도 되는가?

개발 문서는 main 브랜치 기준이며 미출시 기능이 있을 수 있다. 설치된 버전의 릴리스와 안정 문서에서 지원 여부를 확인해야 한다.