도커(Docker) 입문 — 개념·설치·명령어부터 실제로 막히는 지점까지

도커, 왜 배워야 할까

“제 컴퓨터에서는 되는데요”라는 말, 개발하면서 한 번쯤 들어보셨을 겁니다. 로컬 환경과 서버 환경이 달라서 생기는 이 문제를 해결하기 위해 등장한 게 바로 도커입니다.

도커는 애플리케이션과 실행에 필요한 라이브러리·설정을 컨테이너 형태로 묶어서 어디서든 동일하게 실행할 수 있게 해주는 오픈소스 컨테이너 플랫폼입니다. 공식 문서에서도 컨테이너 기반 애플리케이션을 빌드하고 공유하고 실행하는 플랫폼으로 정의하고 있습니다.

문제는 여기서부터 대부분의 초보자가 막힌다는 점입니다. “컨테이너가 정확히 뭔데?”, “VM이랑 뭐가 다른데?” 같은 질문에서 진도가 안 나가는 경우가 많습니다. 이 글은 그 막히는 지점을 하나씩 짚어가면서 실전 흐름까지 이어지도록 구성했습니다.

도커 vs 가상머신(VM), 헷갈리는 게 정상입니다

초보자가 가장 먼저 막히는 지점이 바로 이 개념입니다. “도커도 결국 OS를 하나 더 설치하는 거 아닌가요?”, “하이퍼바이저가 필요한가요?” 같은 질문이 반복적으로 나옵니다.

핵심만 정리하면 이렇습니다.

구분	가상머신(VM)	도커 컨테이너
커널	각자 독립된 OS 커널 사용	호스트 OS 커널 공유
무게	무겁고 부팅 시간 김	가볍고 시작 속도 빠름
격리 수준	하드웨어 수준 완전 격리	프로세스 수준 격리
배포 단위	가상 디스크 이미지(GB 단위)	이미지 레이어(MB 단위인 경우 多)

VM은 하이퍼바이저 위에 각각의 완전한 OS를 올리는 방식이라 무겁습니다. 반면 도커 컨테이너는 호스트의 커널을 공유하면서 프로세스만 격리하기 때문에 훨씬 가볍고 빠르게 뜹니다. 그래서 “OS를 또 설치하는 것”이 아니라 “이미 떠 있는 OS 위에서 격리된 프로세스를 실행하는 것”이라고 이해하시면 됩니다.

이미지와 컨테이너, 이 관계부터 확실히 잡고 가기

두 번째로 많이 막히는 지점입니다. “이미지를 만들었는데 왜 실행이 안 되지?”, “컨테이너를 삭제했는데 이미지가 왜 남아있지?” 같은 질문이 커뮤니티에서 자주 보입니다.

가장 직관적인 비유는 이렇습니다.

• 이미지(Image): 실행 불가능한 템플릿, 즉 ‘붕어빵 틀’
• 컨테이너(Container): 이미지를 실제로 실행한 인스턴스, 즉 ‘붕어빵’

docker run 명령을 실행하면 내부적으로는 docker create(컨테이너 생성)와 docker start(컨테이너 실행)가 순차적으로 일어납니다. 이 관계를 알고 나면 “이미지 삭제해도 컨테이너가 왜 남아있지?”, “컨테이너 지워도 이미지가 왜 남아있지?” 같은 혼동이 대부분 해소됩니다. 이미지는 원본 설계도이고, 컨테이너는 그 설계도로 찍어낸 실행 개체이기 때문에 서로 독립적으로 존재할 수 있습니다.

도커 설치와 버전 확인

Docker Desktop과 Docker Engine의 차이

도커는 두 가지 형태로 설치할 수 있습니다.

• Docker Desktop: Windows, macOS, 일부 Linux용 GUI 번들 버전. 초보자에게 권장됩니다.
• Docker Engine: 서버·CLI 중심의 설치 방식. 주로 리눅스 서버 환경에서 사용됩니다.

공식 문서는 Docker Desktop 릴리스 노트와 Docker Engine 릴리스 노트를 별도 페이지로 제공하고 있으니, 설치 전에 반드시 해당 문서에서 최신 버전과 시스템 요구 사항을 확인하는 것이 안전합니다. 도커 버전과 지원 OS는 자주 바뀌기 때문에, 타 사이트의 버전 정보표보다는 Docker Desktop 릴리스 노트 공식 페이지를 기준으로 삼는 걸 권장드립니다.

설치 후 버전 확인하기

설치가 끝나면 아래 두 명령으로 정상 설치 여부를 확인합니다.

docker --version
docker version

두 명령은 역할이 다릅니다. docker --version은 CLI(클라이언트) 버전만 간단하게 출력하는 용도이고, docker version은 클라이언트와 서버(데몬) 양쪽의 버전 정보를 모두 출력합니다. 설치 후 데몬이 정상적으로 떠 있는지까지 확인하려면 docker version을 사용하시는 게 정확합니다.

첫 번째 컨테이너 실행해보기

개념 설명은 이 정도로 하고, 직접 손으로 실행해보는 게 가장 빠릅니다.

docker run hello-world

이 명령을 실행하면 도커가 로컬에 이미지가 없는 걸 확인하고 자동으로 다운로드한 뒤 컨테이너를 실행합니다. 성공 메시지가 뜨면 설치가 정상적으로 완료된 것입니다.

실행 중이거나 종료된 컨테이너 목록은 아래 명령으로 확인합니다.

docker ps        # 실행 중인 컨테이너만
docker ps -a      # 종료된 것까지 전체 목록

반드시 익혀야 할 기본 명령 세트

초보자들이 가장 많이 하는 질문 중 하나가 “명령어가 너무 많은데 뭐부터 외워야 하나요?”입니다. 아래 표 정도만 익혀도 기본적인 실습은 충분히 가능합니다.

이미지 관련 명령

명령	역할
docker images	로컬에 저장된 이미지 목록 확인
docker pull [이미지명]	이미지 다운로드
docker rmi [이미지ID]	이미지 삭제

컨테이너 관련 명령

명령	역할
docker run [이미지명]	컨테이너 생성 및 실행
docker stop [컨테이너ID]	컨테이너 정지
docker rm [컨테이너ID]	컨테이너 삭제
docker logs [컨테이너ID]	컨테이너 로그 확인
docker exec -it [컨테이너ID] bash	실행 중인 컨테이너 내부 접속

디스크 공간이 부족해지면 docker system prune 명령으로 사용하지 않는 이미지·컨테이너·네트워크를 한 번에 정리할 수 있습니다.

포트 포워딩, 순서 헷갈리지 않는 법

-p 옵션은 초보자가 정말 많이 헷갈려하는 부분입니다. docker run -p 8080:80에서 어느 쪽이 내 컴퓨터(호스트) 포트이고 어느 쪽이 컨테이너 포트인지 순서를 자주 반대로 씁니다.

규칙은 하나만 기억하시면 됩니다.

-p 호스트포트:컨테이너포트

예를 들어 -p 8080:80이라면, 브라우저에서 localhost:8080으로 접속했을 때 컨테이너 내부의 80번 포트로 연결된다는 뜻입니다. 반대로 쓰면 원하는 대로 접속이 안 되니, 항상 왼쪽이 ‘내가 접속할 포트’, 오른쪽이 ‘컨테이너 안의 포트’라고 외워두시면 실수를 줄일 수 있습니다.

볼륨/바인드 마운트, 파일이 안 보일 때

“컨테이너 안에서 파일을 만들었는데 호스트에서 안 보여요”, “로컬 파일을 마운트했는데 컨테이너 안에서 안 보여요” 같은 질문도 매우 자주 나옵니다.

기본 문법은 다음과 같습니다.

docker run -v /호스트/경로:/컨테이너/경로 [이미지명]

이 옵션으로 호스트 디렉토리와 컨테이너 디렉토리를 연결하면, 컨테이너가 삭제되어도 데이터는 호스트에 남아있게 됩니다.

여기서 macOS나 Windows 사용자가 자주 놓치는 부분이 있습니다. Docker Desktop에서는 마운트하려는 호스트 경로가 파일 공유 허용 목록에 포함되어 있어야 정상적으로 인식됩니다. 파일이 안 보인다면 개념 문제가 아니라 Docker Desktop 설정에서 해당 경로의 파일 공유가 활성화되어 있는지부터 확인해보시는 걸 권장드립니다.

Dockerfile로 나만의 이미지 만들기

기본 명령에 익숙해졌다면 다음 단계는 직접 이미지를 빌드하는 것입니다. Dockerfile 작성에서 초보자가 가장 자주 겪는 문제는 FROM, RUN, CMD, ENTRYPOINT의 차이를 혼동하는 것입니다.

간단한 예시로 살펴보겠습니다.

FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "index.js"]

• FROM: 베이스 이미지 지정 (여기서는 Node.js 20 버전)
• WORKDIR: 컨테이너 내부 작업 디렉토리 지정
• COPY: 호스트 파일을 컨테이너로 복사
• RUN: 이미지 빌드 시점에 실행되는 명령 (패키지 설치 등)
• CMD: 컨테이너 실행 시점에 실행되는 명령

여기서 자주 발생하는 실수가 있습니다. docker run 명령 뒤에 별도의 실행 명령을 붙이면 Dockerfile에 작성된 CMD가 무시되고 덮어써집니다. “빌드는 됐는데 원하는 명령이 실행이 안 된다”는 문제의 상당수가 이 케이스입니다.

빌드와 실행은 아래 명령으로 진행합니다.

docker build -t 내이미지 .
docker run 내이미지

환경변수와 디버깅 기초

컨테이너 실행 시 환경변수를 주입하려면 -e 옵션을 사용합니다.

docker run -e NODE_ENV=production [이미지명]

컨테이너가 예상대로 동작하지 않을 때는 아래 순서로 확인하시면 원인 파악이 빠릅니다.

• docker logs [컨테이너ID]로 로그부터 확인
• docker exec -it [컨테이너ID] bash로 컨테이너 내부에 직접 들어가서 확인
• 필요하면 docker ps -a로 종료된 컨테이너까지 포함해 상태 점검

참고로 한국어 환경에서는 컨테이너 로그나 터미널에서 한글이 깨지는 로케일 문제가 종종 발생합니다. 이런 경우 Dockerfile에 로케일 패키지를 설치하고 LANG, LC_ALL 환경변수를 설정해주는 방식으로 우회하는 경우가 많습니다.

Docker Desktop이 실행되지 않을 때 (자주 겪는 예외 상황)

기초 단계에서 실제로 부딪히는 설치·실행 오류 상황들을 정리했습니다. 해당되는 상황이 있다면 참고해보세요.

• 회사·학교 PC에서 설치가 막히는 경우: 보안 정책이나 관리자 권한 제한으로 Docker Desktop 설치 자체가 불가능한 환경이 있습니다. 이런 경우 클라우드 기반 실습 환경이나 원격 서버 접속 방식이 대안이 될 수 있습니다.
• CPU 가상화 미지원 또는 BIOS 비활성화: 구형 PC이거나 BIOS에서 가상화 옵션이 꺼져 있으면 Docker Desktop이 실행되지 않습니다. BIOS 설정에서 가상화(VT-x/AMD-V) 옵션을 활성화해야 합니다.
• Windows에서 WSL2 미설치: Windows용 Docker Desktop은 WSL2 기반으로 동작하는 경우가 많아, WSL2가 설치되어 있지 않으면 정상 실행되지 않습니다.
• ARM(M1/M2) 맥 환경: Apple Silicon에서는 일부 이미지가 x86 기반으로 만들어져 있어 에뮬레이션이 필요하거나 동작에 제약이 있을 수 있습니다. 이미지를 선택할 때 ARM 지원 여부를 확인하는 습관이 필요합니다.
• 회사 프록시·방화벽 환경: docker pull이 실패한다면 프록시 설정 문제일 가능성이 있습니다. 이 경우 도커 데몬 설정에 프록시 환경변수를 별도로 등록해야 합니다.

도커와 쿠버네티스, 지금 같이 배워야 할까

“도커를 배우면 쿠버네티스도 바로 써야 하나요?”라는 질문도 자주 나옵니다. 결론부터 말씀드리면, 도커 기초 단계에서는 쿠버네티스를 함께 학습할 필요가 없습니다.

쿠버네티스는 여러 컨테이너를 대규모로 운영·관리하기 위한 오케스트레이션 도구이고, 도커는 컨테이너를 만들고 실행하는 도구입니다. 즉 쿠버네티스를 이해하려면 도커의 기본 개념(이미지, 컨테이너, 이미지 레지스트리 정도)만 알고 있어도 충분하며, 지금 단계에서는 도커 자체에 집중하는 것을 권장드립니다.

이 글의 검증 기준

이 글에 소개된 도커 명령과 옵션은 Docker 공식 문서(docs.docker.com)를 기준으로 작성했습니다. 다만 Docker Desktop과 Docker Engine은 버전에 따라 화면 구성이나 옵션이 달라질 수 있으므로, 설치나 최신 기능 관련 내용은 Docker Desktop 릴리스 노트에서 최신 정보를 다시 한번 확인하시는 걸 권장드립니다.

자주 묻는 질문

함께 보면 좋은 글

• 리눅스 터미널 기본 명령어 정리 – 초보자가 실제로 막히는 지점까지 해결
• 깃허브 사용법 초보 완전정복: 첫 저장소 만들기부터 에러 해결까지
• IT 취업 로드맵, 2026년 비전공자도 통하는 현실 전략