요약
Docker Agent는 코드 없이 YAML 설정만으로 여러 AI 에이전트를 만들고 실행하는 도커의 오픈소스 도구입니다.
도커 엔지니어링 팀이 만든 에이전트 빌더이자 런타임(실행 환경)입니다. docker agent 명령으로 쓰는 도커 CLI 플러그인이며, Docker Desktop 4.63 이상에는 기본으로 들어 있습니다.
왜 중요한가
- 에이전트를 컨테이너 이미지처럼 OCI 레지스트리(이미지 저장소 표준)에 올리고 내려받아 실행하는 배포 방식을 제시합니다.
- 오픈AI, 앤트로픽, Gemini, AWS Bedrock 등 여러 모델을 고를 수 있어 특정 회사에 묶이지 않습니다.
- Docker Model Runner를 쓰면 API 키 없이 로컬 모델로도 에이전트를 돌릴 수 있습니다.
핵심 내용
- 에이전트는 YAML 파일에 모델, 설명, 지시문, 도구 묶음을 적어 정의하고
docker agent run으로 실행합니다. - 역할이 다른 에이전트들이 팀을 이뤄 일을 자동으로 나눠 맡는 멀티 에이전트 구조를 지원합니다.
- 생각 정리·할 일 목록·메모리 같은 내장 도구에 MCP 서버(AI가 외부 도구를 쓰게 하는 규약)를 붙일 수 있습니다.
- 키워드 검색, 임베딩, 하이브리드 검색, 재순위화를 조합하는 RAG(검색 증강 생성)도 들어 있습니다.
- Apache 2.0 라이선스이며, 익명 사용 데이터를 수집하고, 프로젝트 자체도 Docker Agent로 개발합니다.
HN 반응
- 에이전트 하네스(모델을 감싸 실행하는 도구)가 예전 자바스크립트 프레임워크처럼 쏟아진다는 냉소와, 코드를 금방 짜 주는 시대에 "코드 불필요"가 장점이냐는 반문이 나왔습니다.
- 보안 설명이 안 보인다는 지적에, 다른 이용자들은 VM에서 돌리는 샌드박스 모드와 비밀값을 모델에 숨겨 주는 sbx 도구를 짚었습니다.
다른 사람들이 오케스트레이션에 접근하는 방식을 보니 흥미롭네요.
저는 Pullboard를 만들고 있었고 방금 오픈소스로 공개했습니다. https://github.com/pullboard-dev/pullboard
제 생각에 오케스트레이션은 핵심 문제가 아닙니다. 더 큰 난제는 에이전트가 긴 시간 동안 일관성을 유지하게 하는 것(드리프트)입니다. 그래서 저는 포럼 같은 살아 있는 시스템을 만들었습니다. 에이전트들이 서로에게 외치고, 작업 내용을 항목으로 기록하고, 개발자가 내려 준 원칙을 따르며, 검증할 수 있는 명세를 기준으로 일합니다. 반드시 정확해야 하는 대규모 프로젝트 여러 건에서 이 워크플로를 써 봤고, 저에게는 잘 맞습니다. 지금은 다른 사용자들이 쓸 수 있게 정리하고 있습니다.
딱 이 경우라고 할 수는 없지만, Jira를 싫어하는 개발자들이 에이전트 팀을 관리하겠다며 Jira 같은 걸 만드는 모습을 보는 게 정말 좋아요. 아이러니해서 보기 즐겁죠.
소프트웨어 엔지니어로 죽거나, 아니면 오래 살아서 자기가 프로젝트 매니저가 되는 꼴을 보게 되거나 둘 중 하나죠.
이제 우리 모두 프로젝트 매니저잖아요...
아니면 해고당해서 다른 일을 하러 가거나요. :/
아름답네요.
앞으로 이런 모습을 점점 더 많이 보게 될 거라고 생각합니다. 열린 질문에 답하는 일이나 새로운 작업이 LLM을 처음 접하는 사람들의 경험이지만, 사람들이 하는 일 대부분을 대표하는 건 아니라고 봐요. 코딩은 새로운 작업이면서도 어느 정도 구조가 있어서 그 중간쯤에 놓여 있습니다.
채팅은 새롭고 열린 작업에는 훌륭하지만 동시성, 즉 에이전트를 둘 이상 돌리며 관리하는 데는 형편없습니다. 에이전트가 더 싸지면 한꺼번에 많은 항목을 흘려보내는, 범위가 정해진 프로세스가 늘어날 테고, 그러면 Jira 같은 것들이 나오게 되겠죠... (저희도 이 문제를 겪다가 비슷한 걸 만들었습니다. 좀 더 중세풍 콘셉트이긴 하지만요 [0])
그리고 Jira 방식이 해결해 주는 또 하나(채팅으로는 몹시 어려운 것)가 멀티플레이어입니다. 동시에 일하는 에이전트들을 여럿이 함께 다루는 좋은 채팅형 해법은 아직 본 적이 없고, 저희가 내린 결론은 비동기 모델이 유일하게 제정신인 방법이라는 겁니다.
[0] https://pumpup.com
저도 Backlog.md를 딱 이런 식으로 쓰고 있는데 아주 효과적입니다. 끝낸 작업들이 git 히스토리로는 담기지 않는 지식 저장소가 되어 줘요. 얼마 전에 아주 큰 프로젝트를 마쳤는데, 계획을 세우고 명세를 짠 다음 백로그 작업으로 쪼갰습니다. 작업을 하나씩 진행하면서 변경 사항과 비즈니스 로직 문제를 전부 해당 작업에 기록해 뒀고요. 사고 과정과 실험 결과가 타임스탬프와 함께 남아 있으니 정말 유용했습니다. https://github.com/MrLesk/Backlog.md/
덕분에 한참 웃었어요. 아이디어도 멋지고, 기록을 남기는 방식도 마음에 들어요. OpenAI 해킹 사건들이 살짝 떠오르기도 하네요.
하하, 로컬에서는 통과했어요. 저 배지는 GitHub가 자기네 머신에서 테스트를 돌린 결과인데, 새로 추가한 브라우저 테스트 몇 개가 실패하고 있어요. 수정도 같은 루프로 진행 중이에요. 에이전트 하나가 고치고, 다른 하나가 검증한 다음 머지합니다.
저는 "에이전트가 작업이 끝났다고 했는데 끝나지 않았다"는 문제를, 작업을 pytest 스위트 형태의 실행 가능한 명세로 정의해서 해결해 보려 하고 있습니다.
먼저 새 명세나 갱신된 명세로 작업을 정의하고, 그다음에 변경을 합니다. 자연어 할 일 목록을 만들고 싶은 유혹을 참고, 에이전트가 실행 가능한 단위 테스트를 쓰게 해야 해요. 제 프로젝트는 CLI 도구라서 비교적 쉽습니다.
끝났는지 확인하는 건 명세 테스트 스위트를 돌리면 되고요.
전혀 독창적이지 않게도, 이 워크플로를 제가 만든 에이전트 오케스트레이션 도구에서 시험하고 있습니다. 압니다, 이미 너무 많죠. 저 쓰려고 만드는 겁니다.
지금까지는 시스템이 버티고 있지만, 성공이라고 선언하기엔 너무 이릅니다.
여기서 볼 수 있어요:
https://github.com/egzo-ai/egzo/tree/main/specs
같은 아이디어를 다른 분야의 프로젝트에도 적용할 수 있다고 생각합니다.
이 워크플로를 쓰면 명세를 읽고 고칠 수 있고, 빌드된 바이너리를 상대로 돌려 볼 수 있어서 코드가 제대로 동작한다는 확신이 훨씬 커집니다. Claude code도 대체로 군말 없이 이 시스템을 받아들였어요.
에이전트가 원하는 코드를 거의 즉석에서 줄줄이 뱉어 주고 그게 대체로 맞는 코드인데, "코드 불필요"가 어떻게 세일즈 포인트가 되나요?
Go API로 원하는 걸 직접 만들 수도 있고( https://docker.github.io/docker-agent/guides/go-sdk/ ), 많은 경우에는 YAML 설정과 docker-agent 바이너리만으로 반복해 가며 해결할 수 있습니다.
코드는 YAML이나 JSON 같은 것보다 머리를 조금 더 써야 한다는 뜻이잖아요. 그걸 검토하든 안 하든, 어쨌든 부담이 하나 더 얹히는 거죠. 저는 한동안 docker-the-bloater가 만든 건 손도 안 댈 생각이지만, 적어도 그런 이유는 생각해 볼 수 있겠네요.
네, 이상하죠. 게다가 프로그래머가 아닌 사람 대부분은 yaml도 프로그래밍이라고 할걸요.
결국 모든 프로그래밍은 언어예요. 보통 사람들이 쓰지 않는 언어일 뿐이죠.
이런 번역 계층이 전부 존재하는 건 컴퓨터가 0과 1만 이해하기 때문이에요. 이진수밖에 이해하지 못하는 사람과 대화한다고 상상해 보세요.
새로운 오픈소스 개발은 언제나 반갑고(특히 Go라면 더더욱!), 그런데 에이전트 하네스가 왕년의 JS 프레임워크처럼 되어 가고 있네요.
잘나가는 애들은 다 하나씩 갖고 있죠!
LLM이 등장했을 때 제가 인류에게 걸었던 단 하나의 희망은 Electron, React Native 같은 "JS 계열 물건"과 "모든 걸 TS/JS로 만들거나 그렇게 바꿀 수 있다"는 문화가 마침내 죽는 것이었습니다. 오히려 기하급수적으로 늘고 있는 것 같네요.
Rust + GPUI가 새로운 대세가 되고 있고, 저는 대찬성입니다.
그리고 JS 프레임워크들이 그랬듯이, "승자"는 아마 대형 IT 기업들이 겪는 문제를 해결하는 쪽이 될 겁니다.
그러면 아마 그것도 복잡하고, 좀 느리고, 배우기도 좀 어렵겠죠. 대형 IT 기업의 온갖 문제를 풀어 주느라 그렇게 될 테니까요.
거기에 이걸 관리하겠다고 나오는 VSCode 포크들까지 한 세트죠.
https://docker.github.io/docker-agent/configuration/sandbox/
저처럼 링크된 페이지에서 보안 관련 정보를 찾지 못한 분들을 위해 남깁니다.
Docker Agent는 하네스입니다. docker sandbox(컨테이너가 아니라 VM)에서 실행하는 샌드박스 모드가 있습니다. 샌드박스 모드를 쓰지 않으면 컨테이너에서 돌아갈 거라고 짐작합니다.
그쪽 하네스를 쓰고 싶지 않다면 docker agent 대신
sbxCLI로 원하는 하네스(claude, codex, pi 등)를 실행하면 됩니다.Docker가 사람들을 보안 VM에 익숙하게 만들어 준다면 정말 좋겠다고 생각합니다. 저도 비슷한 프로젝트를 개발하고 있습니다(아직 작업 중입니다). https://github.com/gregwebs/agent-vm
저는 sbx가 아주 유용했습니다. 센티널 값 래퍼 방식이 정말 마음에 들어요. 시크릿을 추가해도 모델은 볼 수 없고, 외부로 나가는 호출에서 센티널 값을 찾아 실제 값으로 바꿔 인증하려는 API로 보내 줍니다. 다른 기능도 있지만, claude를 샌드박스에서 돌리면서 접근할 수 있는 것과 없는 것을 쉽게 확인할 수 있다는 점만으로도 아주 좋았습니다.
샌드박스끼리 허용 도메인 목록을 공유하는 게 더 쉽거나 직관적이면 좋겠어요. 지난번에 sbx로 해 보려 했을 때는 그쪽 yaml 파일을 손으로 일일이 만졌거든요.
흥미롭네요. 저희도 비슷한 걸 하고 있는데, 저희는 팀을 위한 서버 쪽에 초점을 맞춘다는 점이 다릅니다. 이 Docker와 Apple container 아이디어에 대한 블로그 글도 썼습니다. https://virtainer.io/blog/docker-sandboxes-and-virtainer-appvm/
docker sandbox 문서를 처음부터 끝까지 훑어봤던 기억이 나는데, 공격 벡터에 대한 언급은 하나도 없었어요. 그건 고쳤나요?
솔직히 이것들이 각각 어떤 주요 사용 사례나 워크플로를 위한 건지 헷갈립니다.
다들 마찬가지예요. 우리 모두 똑같은 걸 만들고 있으니까요.
기본적으로 이 상태가 영원히 계속되겠죠. https://delightful-marigold-803f7f.netlify.app/