제01권 · 제10호 CS · AI · Infra 2026년 4월 8일

AI 용어집

용어 사전레퍼런스학습
제품 · 플랫폼 데이터 엔지니어링 인프라 · 하드웨어

Docker도커

도커는 애플리케이션이 실행에 필요한 코드, 런타임, 시스템 도구, 라이브러리, 설정을 하나의 격리된 패키지(컨테이너)로 묶어 어디서든 동일하게 실행되도록 해주는 컨테이너 기술과 도구 모음이다. 이를 통해 개발·배포 환경 차이에서 오는 오류를 줄이고, AI/ML을 포함한 소프트웨어의 이식성과 재현성을 높인다.

난이도

30초 요약

프로그램이 내 컴퓨터에서는 되는데 다른 곳에서는 깨지는 문제가 잦다. 도커는 실행에 필요한 파일과 설정을 하나의 상자에 담아 어디서 켜도 똑같이 돌아가게 한다. 이 상자는 레시피(Dockerfile)로 만든 이미지를 기반으로 만들어지고, 실행 시 컨테이너라는 독립된 공간처럼 동작한다. 필요한 도구와 라이브러리를 함께 묶어두어 일관성이 생긴다. 다만 상자에 무엇을 어떻게 담는지는 직접 정리해야 한다. -> 클라우드·AI 개발에서 ‘어디서나 같은 결과’를 보장하려고 도커가 널리 쓰인다.

쉽게 이해하기

우리가 겪는 대표적인 문제는 “내 컴퓨터에서는 되는데 서버에서는 안 된다”는 것이다. 개발자마다 라이브러리 버전, 환경변수, 시스템 도구가 제각각이라 같은 코드를 돌려도 결과가 달라진다. 도커는 이 문제를 “필요한 것 전부를 하나에 담아 옮기는 방식”으로 해결한다. 이때 핵심은 단순 압축이 아니라, 실행 환경 자체를 통째로 포장한다는 점이다.

비유하자면, 음식 레시피만 던져주는 대신 재료·조리도구·양념·조리 순서를 전부 한 박스에 담아 ‘요리 키트’로 보내는 느낌이다. 받는 사람은 박스를 열어 레시피대로 조리하면 어디서든 같은 맛이 난다. 도커에서도 먼저 Dockerfile이라는 ‘레시피’로 이미지를 만든다. 이 이미지에는 코드, 필요한 라이브러리, 시스템 툴, 설정 등이 포함된다. 그리고 이미지를 실행하면 컨테이너가 된다. 컨테이너는 서로 영향을 덜 주도록 격리된 환경처럼 동작해, 같은 이미지라면 노트북이든 클라우드든 동일하게 작동한다. 메커니즘 관점에서 보면, ‘Dockerfile → 이미지 빌드 → 컨테이너 실행’이라는 고정된 과정을 거치기 때문에 환경 차이가 줄고, 이미지에 포함된 종속성들이 컨테이너 내부에서 일관되게 사용되어 재현성이 높아진다. 또한 Docker Compose 같은 도구로 여러 컨테이너를 정의해 함께 구동하면 복잡한 서비스도 손쉽게 묶어 관리할 수 있다.

예시와 비유

  • 연구 재현 가능한 실험 키트: 팀원이 만든 머신러닝 실험을 다른 연구원이 그대로 따라 하려면, 프레임워크와 라이브러리 버전을 정확히 맞춰야 한다. 도커 이미지를 공유하면 필요한 의존성과 설정이 함께 담겨 있어, 다른 연구원이 어디서 실행하든 동일한 실험 환경을 즉시 재현할 수 있다.

  • 사내 도구의 빠른 배포: 사내 데이터 대시보드를 여러 부서 서버에 배포할 때, OS나 라이브러리 차이로 자주 실패한다. 도커로 패키징하면 동일한 이미지가 각 서버에서 같은 방식으로 실행되어, 배포 시 ‘환경 맞춤 작업’이 크게 줄어든다.

  • 생성형 AI 모델 테스트 샌드박스: 새로운 LLM을 시도하려고 모델 가중치, 런타임, 설정을 매번 로컬에 설치하는 건 번거롭다. 도커 컨테이너로 모델과 필요한 구성요소를 한데 묶어두면, 로컬이든 원격 서버든 같은 컨테이너를 띄워 테스트를 빠르게 반복할 수 있다.

  • 멀티서비스 데모 구성: 데이터베이스, 백엔드 API, 프런트엔드가 함께 움직이는 데모를 외부 파트너에게 보여줘야 할 때, 각 서비스 설치를 안내하는 대신 Docker Compose 파일 하나로 여러 컨테이너를 동시에 구동해 ‘한 번에 켜지는’ 데모 환경을 전달할 수 있다.

한눈에 보기

Dockerfile/이미지 vs Compose → 단일 서비스 패키징 vs 다중 서비스 오케스트레이션 이미지 vs 컨테이너 vs Model Runner → 설계도 vs 실행 결과물 vs AI 모델 지향 실행기 Compose vs Cloud 배포 흐름 → 로컬 정의 파일 vs 클라우드에 맞춘 변환/적용 절차


Dockerfile/이미지Docker ComposeDocker Model Runner
목적단일 애플리케이션을 이미지로 패키징여러 컨테이너 서비스를 정의·동시에 실행AI 모델을 가벼운 런타임과 함께 OCI 규격 컨테이너로 쉽게 실행/패키징
사용 시점빌드·배포의 기본 단위 생성로컬 개발/테스트 및 프로덕션 구성 선언로컬에서 모델을 CLI/API로 실행, 모델 아티팩트 패키징
이점일관성·이식성·재현성 확보복잡한 다중 서비스 환경을 파일 하나로 관리Python 환경이나 웹서버 직접 구성 없이 모델 실행 가능
비고Lifebit 글에서 Dockerfiles를 기본 도구로 언급Docker 페이지에서 Compose의 프로덕션 준비 언급Docker 블로그에서 기능과 워크플로 소개

알아야 하는 이유

  • 재현성 강화: 컨테이너가 코드·라이브러리·설정을 함께 담아 어디서 실행해도 같은 동작을 보장한다. 메커니즘상 Dockerfile로 고정된 이미지를 만들고 그 이미지를 그대로 배포·실행하기 때문에 환경 차이가 줄어든다. (출처: Lifebit, Runpod)

  • 의존성 충돌 완화: 서로 다른 라이브러리 요구사항을 가진 애플리케이션을 분리해 담을 수 있다. 컨테이너마다 필요한 구성요소를 분리해 포함하므로 시스템 전반의 충돌을 줄인다. (출처: Lifebit, Runpod)

  • 이식성 향상: 동일한 컨테이너 이미지를 로컬부터 클라우드까지 가져가 실행한다. 하나의 패키지로 옮기기 때문에 프로토타입에서 운영으로 옮길 때 변수가 줄어든다. (출처: Lifebit, Docker)

  • AI 개발 가속: AI/ML 이미지를 쉽게 활용하고, 모델 러너 등 도구로 로컬 실행이 단순해진다. 실행 준비물을 함께 묶고 반복 실험 절차를 줄여 초기 셋업 시간을 단축한다. (출처: IBM, Docker)

▶ 이런 것도 궁금하지 않으세요?
  • 실제로 어디서 쓰여요?
  • 뉴스에서 만났다면
  • 자주 하는 실수가 뭐예요?
  • 이해 체크리스트
  • 회의에서 어떻게 말해요?
  • 다음에 뭘 공부하면 좋아요?
  • 직군별 활용 포인트
  • 더 깊이 알고 싶다면

실제로 어디서 쓰이나

  • Docker Hub의 AI/ML 이미지 활용: 다양한 AI/ML 이미지를 바로 가져와 개발에 사용할 수 있다. IBM 자료에 따르면 Docker Hub에는 수많은 AI/ML 이미지가 제공되어 팀을 지원한다. (출처: IBM)

  • Docker Model Runner로 로컬 모델 실행: Docker 블로그에 따르면 Model Runner는 Docker Hub나 Hugging Face에서 모델을 가져와 로컬에서 CLI 또는 API로 실행·패키징하도록 돕는다. 다만 로컬 리소스 한계와 모델 아티팩트 관리는 여전히 사용자가 책임진다. (출처: Docker 블로그)

  • Compose에서 클라우드로의 전개: Docker 공식 페이지는 “Compose is now production ready”와 함께 Google Cloud Run, Azure로 쉽게 푸시할 수 있음을 언급한다. 실제로는 클라우드 네이티브 설정에 맞도록 Compose 정의를 변환하거나 배포 흐름에 맞게 적용하는 과정이 필요할 수 있다. (출처: Docker)

  • Runpod로 생성형 AI 컨테이너 배포: Runpod 가이드는 도커 컨테이너로 모델과 의존성을 한 번에 패키징해 프로토타입에서 프로덕션으로 옮기는 과정을 설명한다. 단, 확장·자원 제한 등 운영상의 제약은 가이드에 따른 구성이 필요하다. (출처: Runpod)

뉴스에서 만났다면

뉴스에서 'Compose가 프로덕션 준비 완료'라고 나오면 → 로컬에서 쓰던 Compose 정의를 기반으로 운영 환경에도 적용하기 쉬워졌다는 의미. 개발자는 여러 서비스를 하나의 파일로 정의하고, 클라우드 배포 흐름에 맞춰 변환·적용 단계를 거쳐 릴리스 절차를 단순화할 수 있다. 뉴스에서 'Docker Model Runner 업데이트'라고 나오면 → 모델+경량 런타임을 함께 다루는 도구가 개선됐다는 뜻. 개발자는 Python 가상환경·웹서버를 직접 꾸리지 않고도 로컬에서 모델을 실행·패키징하는 단계 수를 줄일 수 있지만, 모델 파일과 자원 제한은 여전히 관리해야 한다. 뉴스에서 'Docker AI 출시/개선'이 보이면 → Dockerfile/Compose 편집 시 문맥 기반 가이드를 제공하는 도구가 강화됐다는 의미. 개발자는 이미지 최적화나 베스트 프랙티스를 에디터 안에서 바로 안내받아 빌드 오류를 줄인다. (출처: IBM) 뉴스에서 '클라우드로 손쉽게 푸시'라고 나오면 → Docker가 Cloud Run, Azure 등과의 연계를 강조한다는 뜻. 실제 현업에서는 계정/권한, 레지스트리 푸시, 서비스 설정 등 배포 파이프라인에 맞춘 절차가 뒤따른다. (출처: Docker)

주의할 점

  • ❌ 오해: 도커를 쓰면 자동으로 성능이 최적화된다 → ✅ 실제: 도커는 환경을 일관되게 묶어주는 도구이지, 애플리케이션 자체의 성능을 자동 튜닝해주지는 않는다. (일관성·이식성에 초점, 출처: Lifebit/Runpod)

  • ❌ 오해: 한 번 만든 Compose 파일은 어떤 클라우드에도 즉시 버튼 한 번으로 배포된다 → ✅ 실제: Docker는 Cloud Run, Azure로 손쉽게 전개할 수 있다고 안내하지만, 각 클라우드의 배포 흐름에 맞춘 적용·변환이 필요할 수 있다. (출처: Docker)

  • ❌ 오해: 도커만 쓰면 보안 문제가 자동으로 해결된다 → ✅ 실제: 도커는 격리와 패키징을 제공하지만, 이미지를 어떻게 만들고 어떤 구성요소를 포함하느냐에 따라 보안 수준은 달라진다. (일반적 주의, 일관성 관련 출처: Lifebit)

  • ❌ 오해: 로컬에서 모델 실행은 모든 준비가 필요 없다 → ✅ 실제: Docker Model Runner로 환경 구성은 단순해지지만, 모델 아티팩트 관리와 하드웨어 자원 한계는 사용자가 관리해야 한다. (출처: Docker 블로그)

이해 체크리스트

□ Dockerfile → 이미지 → 컨테이너로 이어지는 단계가 각각 무엇을 의미하는지 설명할 수 있는가? □ 왜 도커가 재현성과 이식성을 높이는지, ‘무엇이 함께 패키징되기 때문’인지 말할 수 있는가? □ Docker Compose가 단일 컨테이너와 무엇이 다른지, 언제 쓰는지 구체적으로 구분할 수 있는가? □ Docker Model Runner가 해결하는 개발자 문제(로컬 모델 실행/패키징 단순화)를 설명할 수 있는가? □ 클라우드 배포 시 Compose 정의를 어떻게 배포 흐름에 맞춰 적용/변환할지 감을 갖고 있는가?

대화에서는 이렇게

  • Dockerfile 최적화 필요해요. 베이스 이미지 바꾸고 레이어 줄이면 빌드 시간 단축될 듯해요.

  • 로컬에선 Compose로 API/DB/웹 세 개 컨테이너 올려서 테스트했고, Cloud Run 배포는 설정 변환 쪽 검토 중입니다.

  • 이번 PoC는 Docker Model Runner로 LLM 로컬 실행부터 패키징까지 가겠습니다. 모델 아티팩트는 사내 레지스트리에 올려요.

  • Docker Hub에서 제공되는 AI/ML 이미지를 기반으로 시작하고, 필요한 라이브러리만 추가로 레이어링합시다.

  • Runpod 가이드대로 컨테이너 만들면 프로토타입 전개는 빠릅니다. 다만 자원 제한이 있어 배치 작업은 분리하죠.

함께 알면 좋은 용어

  • Dockerfile — 이미지 빌드의 레시피. 무엇을 설치·복사·설정할지 명시한다. 잘 쓰면 이미지가 가벼워지고 빌드가 빨라진다.

  • 도커 이미지 (Image) — 실행 가능한 스냅샷. 어디로 옮겨도 같은 컨테이너를 만들 수 있어 이식성과 재현성이 높다.

  • Docker Compose — 여러 컨테이너를 한 파일로 정의·기동. 단일 서비스엔 과하지만, 다중 서비스 개발·테스트엔 강력하다.

  • Docker Hub — 공개/공식 이미지를 검색·활용하는 허브. ‘처음부터 만들지 않고’ 검증된 베이스에서 시작할 수 있다.

  • Docker Model Runner — 모델을 로컬에서 쉽게 실행·패키징. 일반 앱 컨테이너링보다 모델 아티팩트 취급이 단순해진다.

직군별 활용 포인트

주니어 개발자: 간단한 앱을 Dockerfile로 컨테이너화하고, Docker Hub의 AI/ML 이미지를 기반으로 로컬에서 실행해보세요. Compose로 다중 서비스 로컬 환경을 띄워보면 배포 감이 잡힙니다. PM/기획자: PoC 범위에서 도커 도입으로 얻는 이점(재현성, 배포 시간 단축)을 수치 대신 흐름 관점으로 정리하세요. 클라우드 전개 시 Compose 정의가 어떻게 적용·변환되는지 개발팀과 배포 플로우를 합의하세요. 시니어 엔지니어/리드: 이미지 레이어 전략, 캐시 활용, 베이스 이미지 선정 기준을 세우고, 레지스트리/권한/스캔 정책을 표준화하세요. Model Runner 도입 시 모델 아티팩트 저장·배포·자원 관리 책임 범위를 명확히 하세요. 데이터/ML 엔지니어: 실험 환경을 컨테이너로 고정해 재현성을 확보하고, 팀 공용 베이스 이미지를 마련하세요. Runpod 같은 가이드를 참고해 프로토타입→운영 전개 경로를 문서화하세요.

더 깊이 알고 싶다면

정석 자료

  • What Is Docker? (IBM) (블로그/개요) — Docker와 AI/ML 개발 가속, Docker Hub의 AI/ML 이미지, Docker AI 소개 등 개요 파악에 적합

  • Docker for AI (Docker 공식 페이지) (공식문서/솔루션) — Compose의 프로덕션 준비, Cloud Run/Azure 전개, Model Runner 등 최신 흐름을 확인

  • How to Build, Run, and Package AI Models Locally with Docker Model Runner (Docker 블로그) — 로컬에서 모델을 실행·패키징하는 구체적 방법과 개발자 워크플로 이해에 도움

다음에 읽을 용어

  1. Dockerfile — 이미지 빌드의 레시피를 이해해야 재현성과 이미지 최적화의 핵심을 잡을 수 있다.
  2. 도커 이미지 (Image) — ‘같은 이미지는 같은 동작’ 원리를 이해하면 이식성과 배포 전략이 선명해진다.
  3. Docker Compose — 다중 컨테이너 서비스 정의·기동을 익혀야 로컬-운영 간 환경 차이를 줄일 수 있다.
도움이 되었나요?