한 줄 정의

Docker는 앱 코드와 실행에 필요한 파일을 컨테이너 이미지로 묶고, 그 이미지를 격리된 프로세스로 실행하게 해 주는 도구야. 쉽게 말해 “내 컴퓨터에서는 됐는데 서버에서는 안 돼” 문제를 줄이려고, 실행 환경까지 같이 포장하는 방식이라고 보면 돼.

AI 쪽에서는 Docker가 더 자주 보여. Activepieces 같은 자동화 서버를 직접 설치하거나, Terminal-Bench처럼 평가 환경을 고정하거나, 에이전트가 위험한 명령을 바로 호스트에서 실행하지 않게 격리할 때 자주 등장해.

어떻게 작동하나

Dockerfile은 이미지를 만드는 설명서에 가깝고, 이미지는 실행 파일·라이브러리·설정이 담긴 포장 단위야. docker run을 하면 그 이미지에서 컨테이너가 만들어지고, Docker Engine 문서 기준으로 이 컨테이너는 자기 파일 시스템, 네트워크, 프로세스 트리를 가진 격리된 프로세스로 돌아가.

실무에서는 Docker CLI로 이미지를 빌드하고, 컨테이너를 시작하고, 로그와 포트와 볼륨을 확인해. 그래서 Docker는 개념어로도 쓰이지만 실제 작업에서는 명령줄 도구와 데스크톱 앱, Docker Engine이 같이 움직이는 도구 묶음에 가까워.

예를 들어 Activepieces 공식 Docker 문서는 activepieces/activepieces:latest 이미지를 8080:80으로 띄우고 ~/.activepieces를 볼륨으로 연결하는 빠른 시작 명령을 보여 줘. 하지만 같은 문서가 이 단일 이미지 배포를 개인용이나 테스트용으로 제한해. 운영이나 여러 인스턴스 배포로 가면 PostgreSQL과 Redis를 따로 두고 Docker Compose를 써야 해.

Compose는 여러 컨테이너를 한 파일에 선언하는 도구야. 앱 서버, 데이터베이스, Redis, 워커처럼 역할이 나뉘면 docker run 명령을 여러 번 외우는 대신 compose.yaml에 서비스, 네트워크, 볼륨을 적고 같이 올린다. 그래서 Compose 파일은 실행 이미지를 만드는 Dockerfile과 달리, 이미 만들어진 컨테이너들을 어떻게 같이 띄울지 적는 쪽에 가까워.

왜 중요한가

Docker를 알면 “Docker로 설치 가능”이라는 문장을 덜 순진하게 읽을 수 있어. 설치가 쉽다는 뜻일 수는 있지만, 운영이 쉽다는 뜻은 아니야. 데이터가 어디에 저장되는지, 컨테이너를 지워도 볼륨이 남는지, 업그레이드 전에 백업해야 하는지, 웹훅 URL이나 비밀값은 어떻게 넣는지를 따로 봐야 해.

AI 자동화에서는 이 차이가 더 커져. Local LLM 서버, 워크플로 자동화 도구, 브라우저 조작 에이전트, 코드 실행 샌드박스는 전부 외부 명령과 파일 접근을 다룰 수 있어. Docker는 이 실행을 반복 가능하게 만들고 호스트와 어느 정도 분리해 주지만, “안전하다”는 결론은 권한, 네트워크, 마운트, 이미지 출처까지 본 뒤에야 말할 수 있어.

Nous Research의 제품 사이트가 Docker를 local, SSH, Singularity, Modal과 함께 5개 실행 백엔드 중 하나로 적는 것도 같은 이유야. Docker는 에이전트 실행 위치를 고르는 선택지 중 하나이지, 멀티유저 권한 분리나 조직 보안 정책을 자동으로 설계해 주는 답은 아니야. 실제로 LocalLLaMA AMA에서도 회사 배포에서 사용자마다 컨테이너를 띄우는 부담과 GDPR식 분리 요구가 질문으로 나왔어.

주의해서 볼 점

  • 단일 컨테이너와 운영 배포를 섞지 마. 문서 첫 줄의 docker run은 빠른 체험용일 수 있고, 운영에서는 데이터베이스, 큐, 워커, 백업이 따로 필요할 수 있어.
  • 볼륨을 확인해. 컨테이너는 지워도 데이터가 남을 수 있고, 반대로 볼륨을 잘못 지우면 설정과 데이터가 같이 사라질 수 있어.
  • 이미지 출처를 확인해. 공식 이미지인지, 태그가 latest인지, 고정 버전인지에 따라 재현성과 업그레이드 위험이 달라져.
  • 에이전트 샌드박스라면 마운트 경로, 네트워크, 사용자 권한, CPU·메모리 제한을 같이 봐. Docker만 켰다고 임의 코드 실행이 자동으로 안전해지진 않아.

실무 활용

Docker가 잘 맞는 경우는 실행 환경을 짧게 고정해야 할 때야. 예를 들어 새 자동화 도구를 하루 안에 시험하거나, 에이전틱 코딩 평가에서 같은 테스트 환경을 여러 모델에 반복해서 주거나, 팀원이 같은 런타임을 바로 띄워야 할 때 유용해.

반대로 장기 운영이면 체크리스트가 달라져. 이미지 태그를 고정하고, .env 같은 비밀값 파일을 관리하고, 데이터 볼륨과 백업 경로를 문서화하고, Compose나 Kubernetes 같은 오케스트레이션을 어디까지 쓸지 정해야 해. Docker는 좋은 시작점이지만 운영 설계의 마지막 줄은 아니야. 급할 거 없어. docker run이 성공한 뒤부터 진짜 확인할 게 생겨.