Docker 컨테이너 실행부터 삭제까지 명령어 확인 순서

Docker를 처음 켠 날, 저는 docker run ubuntu를 입력하고 5분을 멍하니 기다렸습니다. 아무 일도 안 일어나더군요. 에러 메시지도 없었습니다. 나중에 알고 보니 그건 실패가 아니라 “할 일 다 하고 정상 종료”였습니다.

이런 오해가 입문 단계에서 가장 흔합니다. 명령어를 몰라서가 아니라, 명령어가 뭘 하는지 몰라서 생깁니다. 그래서 이 글은 명령어 사전이 아니라 순서로 정리했습니다. 설치 확인 → 이미지 받기 → 컨테이너 실행 → 확인 → 접속 → 중지·재시작 → 삭제, 이 흐름 그대로 따라오시면 됩니다.

기준은 로컬 개발 환경(Docker Desktop), 2026년 7월 기준 공식 문서입니다. 서버 리눅스의 Docker 엔진은 일부 경로와 권한 처리가 다르니 이 점만 미리 알고 계세요.

Docker 컨테이너 만들기 전, 데몬부터 살아있는지 확인

컨테이너를 만들기 전에 Docker 엔진이 실제로 돌고 있어야 합니다. 이게 안 되면 그 뒤 명령이 전부 헛돕니다.

docker --version
docker info

docker info에서 Server 정보까지 나오면 정상입니다. Client 정보만 나오고 그 아래가 에러라면 데몬이 안 뜬 겁니다.

처음 설치하신 분들이 자주 마주치는 화면은 두 가지입니다.

증상	실제 원인	대응
command not found	PATH 미적용, 설치 후 미재부팅	터미널 재시작 또는 재로그인
permission denied (리눅스)	Docker 소켓 접근 권한 없음	sudo 사용 또는 사용자를 docker 그룹에 추가
Docker Desktop이 시작 안 됨 (Windows)	WSL2·Hyper-V·BIOS 가상화 비활성	OS 가상화 설정 확인

Windows 커뮤니티 글을 보면 “가상화가 비활성화되어 있습니다” 메시지에서 Docker를 지웠다 깔았다 반복하는 사례가 정말 많습니다. Docker 문제가 아니라 BIOS·WSL2 설정 문제인 경우가 대부분입니다. 저도 사내 노트북에서 같은 화면을 봤고, 결국 BIOS에서 가상화 항목 하나 켜는 걸로 끝났습니다. 재설치는 시간 낭비였습니다.

리눅스에서 sudo 없이 쓰고 싶다면 docker 그룹에 사용자를 추가한 뒤 다시 로그인하면 됩니다. 다만 이 설정은 배포판·버전마다 조금씩 다르니, 공식 문서를 함께 보시길 권합니다.

이미지 받기와 docker 컨테이너 실행의 차이

가장 많이 헷갈리는 지점부터 정리하겠습니다.

• 이미지: 실행에 필요한 파일들의 묶음. 그냥 파일입니다.
• 컨테이너: 그 이미지를 실제로 돌린 결과물. 격리된 프로세스입니다.

Docker 공식 문서는 컨테이너를 호스트의 다른 프로세스와 격리된 샌드박스 프로세스이자 이미지의 실행 인스턴스로 설명합니다. 즉 이미지를 받아놨다고 뭔가 돌아가는 게 아닙니다.

docker pull nginx:latest     # 이미지만 내려받음
docker images                # 로컬 이미지 목록
docker run nginx:latest      # 여기서 처음 컨테이너가 생김

docker pull은 다운로드까지입니다. 실행은 docker run이 합니다. 국내 입문 강의 댓글에 “이미지 설치했는데 왜 실행이 안 되나요”라는 질문이 반복해서 올라오는 이유가 여기 있습니다.

docker 컨테이너 실행 옵션, 이 네 개면 충분합니다

옵션	뜻	언제 씁니까
--name	컨테이너 이름 지정	안 주면 랜덤 이름이 붙어 관리가 번거로움
-d	백그라운드 실행	웹서버·DB처럼 계속 떠 있어야 할 때
-p 호스트:컨테이너	포트 연결	브라우저로 접속해야 할 때
-it	터미널 연결 유지	컨테이너 안에서 셸을 쓸 때

실전 예시입니다.

docker run -d --name my-nginx -p 8080:80 nginx:latest

이러면 브라우저에서 localhost:8080으로 들어갈 수 있습니다. 80번 포트를 그대로 쓰지 않고 8080으로 바꾼 이유는 뒤에서 설명하겠습니다.

컨테이너가 바로 종료되는 건 에러가 아닙니다

docker run ubuntu를 치면 컨테이너가 즉시 exited 상태가 됩니다. 이건 정상 동작입니다. 이미지에 정의된 기본 명령이 끝나면 프로세스가 끝나고, 프로세스가 끝나면 컨테이너도 끝납니다.

계속 살려두고 싶으면 셸을 붙이면 됩니다.

docker run -it ubuntu /bin/bash

이 한 줄을 몰라서 “도커가 고장 났다”고 결론 내리는 경우가 커뮤니티 질문 게시판에 꾸준히 올라옵니다.

docker 컨테이너 확인과 리스트 조회

지금 뭐가 돌고 있는지 모르면 그다음 명령을 못 씁니다. 컨테이너 리스트 확인이 사실상 모든 작업의 출발점입니다.

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

docker ps에 안 보인다고 컨테이너가 사라진 게 아닙니다. 중지된 컨테이너는 디스크에 그대로 남아 용량을 차지합니다. -a를 붙여야 보입니다.

출력에서 봐야 할 칸은 세 개입니다.

• STATUS: Up ...이면 정상, Exited (숫자)면 종료. 괄호 안 숫자가 종료 코드입니다.
• PORTS: 포트가 실제로 연결됐는지. 비어 있으면 브라우저 접속이 안 됩니다.
• NAMES: 이후 명령에 쓸 이름.

컨테이너 ID는 전부 입력할 필요 없습니다. 앞 3~4자리만 써도 구분됩니다.

docker 컨테이너 접속, exec와 attach는 다릅니다

컨테이너 내부에 들어가는 방법은 두 가지인데 성격이 완전히 다릅니다.

docker exec -it my-nginx /bin/bash    # 권장
docker attach my-nginx                # 주의 필요

exec는 컨테이너 안에서 새 프로세스를 하나 띄웁니다. 나와도 컨테이너는 계속 돕니다. attach는 이미 돌고 있는 메인 프로세스에 터미널을 붙입니다. 여기서 exit를 치면 메인 프로세스가 끝나면서 컨테이너까지 같이 꺼집니다.

저는 처음에 이 차이를 모르고 운영 중인 컨테이너에 attach로 들어갔다가 exit로 나오면서 서비스를 내린 적이 있습니다. 다행히 로컬이었습니다. 디버깅 목적이면 무조건 exec를 쓰세요.

attach 상태에서 컨테이너를 살려둔 채 빠져나오려면 Ctrl + P 다음 Ctrl + Q를 누릅니다. 이건 외워두시면 언젠가 구해줍니다.

컨테이너 중지·종료·재시작 명령어

명령	동작
docker stop 이름	정상 종료 신호를 보냄 (기본 대기 후 강제 종료)
docker start 이름	중지된 컨테이너 다시 실행
docker restart 이름	중지 후 재시작을 한 번에

docker stop my-nginx
docker start my-nginx
docker restart my-nginx

docker stop은 컨테이너를 지우지 않습니다. 껐다 켜는 것뿐이라 설정과 데이터가 그대로 남습니다. docker start는 처음 run할 때 준 옵션(포트, 이름 등)을 그대로 다시 씁니다. 그래서 포트를 바꾸고 싶으면 start가 아니라 지우고 다시 run 해야 합니다.

포트 충돌은 대부분 이 순서로 풀립니다

ports are not available 또는 port is already allocated 메시지는 입문자가 가장 자주 보는 에러 중 하나입니다. 누군가 이미 그 포트를 쓰고 있다는 뜻입니다.

• docker ps로 같은 포트를 쓰는 컨테이너가 있는지 확인 → 있으면 docker stop
• 컨테이너가 아니라면 OS 레벨 프로세스가 범인입니다. Windows에서는 MySQL(3306), 웹서버(80·8080)가 단골입니다.
• 굳이 싸울 필요 없으면 호스트 포트만 비켜 갑니다. -p 8081:80처럼요.

앞에서 80 대신 8080을 쓴 이유가 이겁니다. 호스트 쪽 번호는 안 겹치는 걸로 고르는 게 제일 빠릅니다.

docker 컨테이너 삭제, 이미지 삭제와 헷갈리지 마세요

이 둘은 지우는 대상이 다릅니다.

docker rm my-nginx          # 컨테이너 삭제 (중지된 상태여야 함)
docker rmi nginx:latest     # 이미지 삭제

rm과 rmi, 알파벳 한 글자 차이라 섞어 쓰다 원하는 게 안 지워지는 일이 흔합니다. rm은 컨테이너, rmi는 이미지(image) 로 외우면 안 헷갈립니다.

실행 중인 컨테이너를 지우려 하면 거부당합니다. -f로 강제 삭제할 수는 있지만, 입문 단계에서는 stop → rm 순서를 권합니다. 강제 옵션이 습관이 되면 언젠가 지우면 안 되는 걸 지웁니다.

디스크가 꽉 찼을 때 안전하게 정리하는 법

빌드 중에 no space left on device가 뜨면 이미지와 중지된 컨테이너가 쌓인 겁니다. 이미지 하나가 수백 MB에서 1GB를 넘기도 하니, 몇 개만 쌓여도 금방 찹니다.

docker system df           # 뭐가 얼마나 먹고 있는지 먼저 확인
docker container prune     # 중지된 컨테이너만 정리
docker image prune         # 태그 없는 이미지만 정리

여기서 한 가지 당부드립니다. 에러가 뜰 때마다 반사적으로 docker system prune -a --volumes를 치는 습관은 위험합니다. 이 명령은 사용하지 않는 이미지·컨테이너·네트워크에 볼륨까지 전부 날립니다. 볼륨에 DB 데이터가 들어 있으면 그대로 사라집니다. 저는 system df로 확인부터 하고, 대상을 좁힌 prune만 씁니다.

컨테이너가 안 뜰 때 먼저 하는 3가지

여기가 입문 글에서 잘 안 다루는 부분입니다. 대부분의 글이 명령어 목록에서 끝나고, “안 될 때 뭘 보는지”를 순서로 알려주지 않습니다. 저는 이 세 줄을 순서대로 칩니다.

1단계 — 로그를 봅니다.

docker logs my-nginx
docker logs -f my-nginx     # 실시간으로 따라가기

컨테이너가 올라가자마자 죽는다면 십중팔구 애플리케이션 에러입니다. 로그에 이유가 적혀 있습니다. Docker를 의심하기 전에 여기부터 보세요.

2단계 — 설정을 봅니다.

docker inspect my-nginx

포트 매핑, 환경변수, 볼륨, 네트워크가 의도대로 붙었는지 확인합니다. “분명 포트를 열었는데 접속이 안 된다”는 상황의 절반은 여기서 답이 나옵니다.

3단계 — 자원을 봅니다.

docker stats

CPU·메모리 사용량을 실시간으로 보여줍니다. 메모리 한계에 부딪혀 컨테이너가 강제 종료되는 경우가 있는데, 이건 로그만 봐서는 안 잡힙니다.

로그 → 설정 → 자원. 이 순서만 기억하시면 “그냥 안 돼요” 상태에서 벗어날 수 있습니다.

명령어 한눈에 정리

목적	명령어
설치 확인	docker info
이미지 받기	docker pull 이미지:태그
컨테이너 만들기·실행	docker run -d --name 이름 -p 8080:80 이미지
컨테이너 확인·리스트	docker ps / docker ps -a
컨테이너 접속	docker exec -it 이름 /bin/bash
중지 / 재시작	docker stop 이름 / docker start 이름
컨테이너 삭제	docker rm 이름
이미지 삭제	docker rmi 이미지:태그
용량 확인·정리	docker system df / docker container prune
문제 확인	docker logs → docker inspect → docker stats

CLI 옵션은 버전에 따라 기본 동작이 조금씩 달라질 수 있습니다. 세부 구문이 헷갈리면 Docker 공식 문서(docs.docker.com/get-started)를 함께 확인하시는 편이 안전합니다.

자주 묻는 질문

함께 보면 좋은 글

• 리눅스 터미널 기본 명령어 정리 – 초보자가 실제로 막히는 지점까지 해결
• IT 취업 로드맵, 2026년 비전공자도 통하는 현실 전략
• 파이썬 가상환경 설정 방법: VSCode 연동까지 한 번에 끝내기