[2장] 도커 명령어 중, 유사한 기능으로 보이지만 다른 실행을 의미하는 것

 

도커를 처음 접하면 docker run, docker start처럼 겉보기에는 비슷한 동작을 하는 것처럼 보이는 명령어들이 상당히 많습니다. 하지만 실제로 내부적으로는 다른 실행 흐름이나 목적을 갖고 있어서, 잘 구분해 사용하지 않으면 예상치 못한 결과를 얻게 될 수도 있습니다. 이번 포스팅에서는 그중에서도 자주 헷갈릴 만한 10가지 명령어(혹은 명령어 조합)을 비교해봅니다.

---

1. docker run vs docker start

• docker run [이미지명]
• 새로운 컨테이너를 생성(create)하고, 바로 실행(start)까지 진행
• -it, -d, -p 같은 옵션을 통해 컨테이너 환경을 세팅하면서 생성 가능
• docker start [컨테이너명 or ID]
• 이미 생성되어 멈춰 있는 컨테이너를 재시작할 때 사용
• 기존 컨테이너에 대한 설정이나 환경은 변경 없이 그대로 유지

요점: run은 새 컨테이너 생성 + 실행, start는 정지된 기존 컨테이너만 재실행하는 명령어입니다.

출처 입력

---

2. docker exec -it vs docker attach

• docker exec -it [컨테이너명 or ID] bash
• 새 프로세스를 컨테이너 안에서 실행하며, 해당 프로세스에 터미널로 접속
• 기존 애플리케이션과는 별개로 새로운 쉘 세션을 띄워주는 느낌
• docker attach [컨테이너명 or ID]
• 이미 컨테이너 내부에서 실행되고 있는 프로세스(주로 PID1 프로세스)에 연결
• 프로세스의 표준 입출력과 직접 연결되므로, 다른 사용자가 attach한 프로세스 화면을 공유하는 셈

요점: exec -it는 새 프로세스를 실행해 접속, attach는 이미 실행 중인 프로세스(주로 메인 프로세스)에 연결해 동일 세션을 공유합니다.

출처 입력

---

3. docker stop vs docker kill

• docker stop [컨테이너명 or ID]
• 컨테이너 내부의 프로세스에 안전하게 종료 신호(SIGTERM)를 보내고, 일정 시간이 지난 후(SIGKILL) 종료
• 애플리케이션이 정상적으로 종료할 수 있는 시간을 부여
• docker kill [컨테이너명 or ID]
• 즉시 SIGKILL(강제 종료)을 보내서 프로세스를 종료
• 애플리케이션이 종료 루틴을 수행할 시간을 주지 않으므로, 주의가 필요

요점: stop은 안전 종료, kill은 즉시 강제 종료에 가깝습니다.

출처 입력

---

4. docker create vs docker run -d

• docker create [이미지명]
• 컨테이너를 “생성”만 하고 바로 실행하지는 않음
• docker start로 나중에 실행 가능
• docker run -d [이미지명]
• 백그라운드(Detached) 모드로 컨테이너를 생성+실행
• -d 옵션을 붙이면 실행 로그가 터미널에 표시되지 않고, 백그라운드에서 프로세스가 동작

요점: create는 실행 없이 컨테이너 “껍데기”만 만들고, run -d는 컨테이너를 바로 백그라운드 실행까지 해줍니다.

출처 입력

---

5. docker logs vs docker attach

• docker logs [컨테이너명 or ID]
• 컨테이너에서 발생한 표준 출력 및 에러 로그를 확인
• -f 옵션으로 실시간 스트리밍 형태로 로그를 모니터링 가능
• docker attach [컨테이너명 or ID]
• (2번에서 설명한 것처럼) 이미 실행 중인 프로세스에 직접 연결
• 로그는 물론이고 해당 프로세스의 실제 화면(표준 입출력)에 참여하게 됨

요점: logs는 컨테이너가 출력한 기록을 단순히 조회, attach는 프로세스의 실제 세션에 참여해 상호작용하는 개념입니다.

출처 입력

---

6. docker build vs docker commit

• docker build -t [이미지이름:태그] [Dockerfile 경로]
• Dockerfile을 바탕으로 단계별로 이미지를 제작
• 빌드가 지속적으로 재현 가능하고, 형상 관리가 용이
• docker commit [컨테이너명 or ID] [이미지이름:태그]
• 현재 실행 중인 컨테이너의 상태(파일, 설정 등)를 새로운 이미지로 저장
• 일회성, 임시성 성격이 강해 일반적으로 운영보다 테스트 용도로 더 자주 사용

요점: build는 Dockerfile을 통해 체계적으로 이미지를 생성, commit은 지금 실행 중인 컨테이너 상태를 “스냅샷” 떠서 이미지화 합니다.

출처 입력

---

7. docker pull vs docker load

• docker pull [이미지명]
• Docker Hub(또는 다른 레지스트리)에서 이미지를 다운로드
• docker load -i [tar파일]
• 이미지가 저장된 tar 파일을 로컬 이미지로 불러오기(복원)
• 인터넷 연결이 어려운 환경에서 이미지 파일 형태로 전달받아 사용할 때 활용

요점: pull은 레지스트리에서 가져오는 것, load는 압축된 이미지 파일을 로컬로 불러오는 방식입니다.

출처 입력

---

8. docker push vs docker save

• docker push [이미지명:태그]
• 로컬의 이미지를 Docker Hub(또는 다른 레지스트리)에 업로드
• docker save -o [저장할파일이름.tar] [이미지명:태그]
• 로컬 이미지를 tar 형태로 저장(백업)
• docker load 명령어로 다시 불러올 수 있음

요점: push는 로컬 이미지를 원격 레지스트리에 올리는 작업, save는 이미지를 tar 파일로 내보내는 작업입니다.

출처 입력

---

9. docker system prune vs docker image prune

• docker system prune
• 사용되지 않는 컨테이너, 네트워크, 이미지, 볼륨 등을 한 번에 정리
• -a 옵션을 붙이면 더 광범위하게 사용되지 않는 리소스들을 정리
• docker image prune
• 사용되지 않는 도커 “이미지”들만 정리(dangling images 등)
• 네트워크나 볼륨, 컨테이너 등은 건드리지 않음

요점: system prune은 전체적인 자원을 한꺼번에 정리, image prune은 이미지에만 집중해 깔끔히 관리합니다.

출처 입력

---

10. docker network create vs docker network connect

• docker network create [네트워크명]
• 새로운 사용자 정의 네트워크를 생성
• Bridge, Overlay 등의 드라이버를 지정 가능
• docker network connect [네트워크명] [컨테이너명 or ID]
• 이미 실행 중이거나 존재하는 컨테이너를 특정 네트워크에 연결
• 네트워크를 미리 생성해두고 필요한 시점에 컨테이너를 붙일 수 있음

요점: network create는 네트워크 자체를 만드는 작업, network connect는 이미 존재하는 네트워크에 컨테이너를 “붙이는” 작업입니다.

출처 입력

---

마무리

도커 명령어들은 얼핏 보기에는 비슷해 보이지만, 실제로는 각각의 목적과 기능이 다릅니다. “비슷해 보이지만 서로 다른 동작”을 이해하는 것이 도커를 안정적으로 활용하는 첫 걸음입니다.

앞으로 도커를 더 깊이 사용하다 보면, 이러한 차이가 실무나 학습에서 얼마나 중요한지를 직접 체감하실 수 있을 것입니다.

---

 

docker-run#docker-start#docker-exec#docker-attach#docker-stop#docker-kill#docker-create#docker-commit#docker-pull#docker-prune