Docker가 컨테이너 워크플로우용 AI 에이전트 Gordon을 정식 공개했습니다. 핵심은 “코드를 대신 써주는 챗봇”이 아니라 Docker Desktop과 CLI 안에서 현재 컨테이너 환경을 읽고, 수정안을 제안한 뒤 사용자가 승인한 작업만 실행하는 운영 보조 에이전트라는 점입니다.

핵심 요약

  • 제공 위치: Gordon은 Docker Desktop 4.74 이상과 CLI의 docker ai에서 사용할 수 있습니다.
  • 보는 컨텍스트: 실행 중인 컨테이너 로그, 이미지, Compose 파일, 작업 디렉터리, 볼륨·네트워크 등 Docker 환경 정보를 바탕으로 답합니다.
  • 할 수 있는 일: 컨테이너가 종료되는 원인 추적, Dockerfile·Compose 초안 작성, 이미지 정리 명령 제안, Dockerfile 최적화, 실행 중인 리소스 확인 같은 작업을 한 대화 안에서 처리하도록 설계됐습니다.
  • 통제 방식: 모든 셸 명령, 파일 수정, Docker 작업은 실행 전에 표시되고 사용자가 승인해야 합니다. 세션을 닫으면 권한이 초기화됩니다.
  • 가격 방향: Docker 계정이 있으면 무료로 시작할 수 있고, 더 많은 사용량이 필요하면 Gordon Plus 등 별도 플랜으로 확장하는 구조입니다.

무엇이 바뀌었나

기존 AI 코딩 도구는 대체로 사용자가 붙여 넣은 코드나 설명을 바탕으로 답합니다. Docker가 강조한 Gordon의 차이는 “이미 Docker 환경 안에 있다”는 점입니다. 예를 들어 빌드 캐시가 예상과 다르게 무효화되거나, Postgres와 Redis가 서로 보이지 않거나, 로컬에서는 동작하던 이미지가 CI에서 죽는 상황에서는 코드 조각보다 로그·Compose·네트워크·이미지 상태가 더 중요합니다.

Gordon은 Docker Desktop 안의 전용 탭과 문제 발생 지점의 실행入口, 그리고 터미널의 docker ai 명령으로 접근할 수 있습니다. Docker는 Gordon이 셸 접근, 파일 시스템 작업, Docker CLI, Docker 문서·베스트프랙티스 지식 기반, 웹 접근을 조합해 사용자가 요청한 작업을 수행한다고 설명합니다.

실제 사용 사례도 컨테이너 운영에 맞춰져 있습니다. “컨테이너가 계속 종료된다”라고 요청하면 로그를 읽고 누락된 환경 변수, 잘못된 베이스 이미지, 볼륨 마운트 오류 같은 후보를 찾은 뒤 수정안을 제안합니다. “이 앱을 컨테이너화하고 Postgres 개발 환경을 만들어 달라”라고 요청하면 코드베이스를 읽어 Dockerfile과 Compose 구성을 제안하는 흐름입니다.

비교 포인트: 코딩 에이전트와 무엇이 다른가

구분 일반 AI 코딩 도구 Docker Gordon
주요 초점 애플리케이션 코드 작성, 리팩터링, 테스트 보조 컨테이너 빌드·실행·디버깅·정리·최적화
컨텍스트 사용자가 붙여 넣은 코드, IDE가 제공하는 파일 정보 Docker Desktop/CLI가 보는 컨테이너, 이미지, 로그, Compose, 볼륨, 네트워크
실행 방식 코드 제안 또는 제한된 툴 실행 셸 명령·Docker 작업·파일 수정안을 보여주고 승인 후 실행
도입 기준 코드 생산성, 리뷰 시간, 테스트 보조 효과 로컬 개발 환경 복구 시간, Dockerfile 품질, Compose 재현성, 권한 통제

실사용 전에 확인할 기준

  • 명령 승인 흐름: 기본은 “Gordon이 제안하고 사용자가 결정”하는 구조입니다. 자동 승인 옵션은 반복 업무에는 편하지만, 파일 삭제·이미지 정리·네트워크 변경 같은 작업까지 자동화할 수 있는지 범위를 먼저 정해야 합니다.
  • 로그와 비밀값: 컨테이너 로그, 환경 변수, Compose 파일에는 토큰·DB 접속 문자열·내부 호스트명이 들어갈 수 있습니다. Docker는 코드나 개인 정보를 저장하지 않고 AI 제공자도 데이터를 보존하지 않는다고 설명하지만, 팀 정책상 전송 가능한 로그 범위는 별도로 정하는 것이 안전합니다.
  • 재현성과 롤백: Dockerfile 최적화나 Compose 수정은 작은 diff로 남기고, 변경 전 이미지 크기·빌드 시간·캐시 적중 여부·서비스 기동 여부를 기록해야 합니다. “빨라졌다”보다 “어떤 레이어가 어떻게 바뀌었는가”가 중요합니다.
  • CI/CD 적용 범위: Gordon은 로컬 Desktop/CLI 경험에 강점이 있습니다. CI 파이프라인이나 프로덕션 배포 정책에 바로 연결하기 전에는 동일한 명령이 팀 환경에서도 재현되는지 검증해야 합니다.
  • 비용과 사용량: 무료 사용량은 일상적 사용을 전제로 하며 제한은 몇 시간마다 재설정된다고 Docker는 설명합니다. 팀에서 매일 쓰는 도구가 된다면 Gordon Plus와 2배~20배 용량 플랜의 월 비용을 기존 디버깅 시간 절감과 비교해야 합니다.

팀에서 먼저 검증할 순서

  1. 테스트 전용 프로젝트를 고릅니다. 실제 고객 데이터나 운영 비밀값이 없는 작은 Node.js·Python 서비스와 Postgres/Redis Compose 구성이 적당합니다.
  2. Docker Desktop 4.74 이상에서 Gordon을 켭니다. 먼저 자동 승인 없이 실행하고, Gordon이 어떤 명령을 제안하는지 기록합니다.
  3. 실패 상황을 하나 만듭니다. 잘못된 환경 변수, 누락된 포트 매핑, 깨진 볼륨 경로처럼 원인이 분명한 문제를 넣고 Gordon이 로그와 Compose를 어떻게 연결하는지 확인합니다.
  4. 수정안은 diff로 검토합니다. Dockerfile 멀티스테이지 빌드, 베이스 이미지 변경, 헬스체크 추가, 레이어 순서 변경은 모두 장단점이 있으므로 한 번에 합치지 말고 단계별로 검증합니다.
  5. 팀 규칙을 정합니다. 자동 승인 허용 명령, 금지 명령, 로그 마스킹 기준, 실패 시 원복 방법, 유료 플랜 전환 기준을 문서화합니다.

결론

Gordon은 “AI가 Docker 명령을 대신 기억해준다” 수준의 기능보다 넓은 방향을 가리킵니다. Docker가 가진 로컬 컨테이너 컨텍스트와 에이전트 실행 능력을 묶어, 개발자가 코드 작성 이후의 빌드·실행·디버깅·정리 작업까지 한 흐름에서 처리하게 만드는 시도입니다.

다만 에이전트가 셸과 파일 시스템, Docker CLI에 접근할 수 있다는 점은 곧 운영 리스크이기도 합니다. 실제 도입 판단은 발표 문구보다 승인 흐름, 로그·비밀값 처리, 자동 승인 범위, 롤백 가능성, 유료 플랜 비용을 기준으로 하는 편이 좋습니다.

출처와 검증