[도커 30강] 02강. Docker 설치/데몬 구조 이해와 첫 실행 점검

Last updated on 
[도커 30강] 02강. Docker 설치/데몬 구조 이해와 첫 실행 점검

1강에서 도커를 왜 써야 하는지 큰 그림을 잡았다면, 2강에서는 실제로 “제대로 설치되어 있고, 지금 당장 실습 가능한 상태인지”를 확인해야 합니다. 많은 초보자가 여기서 막히는 이유는 Docker를 하나의 프로그램으로 생각하기 때문입니다. 하지만 실제 Docker는 CLI(명령 입력 도구) + 데몬(백그라운드 엔진) + 이미지/컨테이너 저장소가 함께 동작하는 구조입니다. 즉, 터미널에서 docker 명령이 실행된다고 해서 끝이 아니라, 내부 엔진과 통신이 되는지까지 점검해야 비로소 준비 완료입니다.

이번 강의에서는 설치 자체보다 더 중요한 세 가지를 잡습니다. 첫째, Docker 데몬이 어떤 역할을 하는지. 둘째, CLI와 데몬 연결이 실패할 때 어디를 봐야 하는지. 셋째, 첫 실행 점검을 체계적으로 하는 방법입니다. 이 흐름을 익혀두면 이후 강의에서 나오는 build/run/compose 문제의 절반 이상을 빠르게 진단할 수 있습니다.

핵심 개념

도커는 터미널에서 입력하는 docker 명령어(클라이언트)와 실제 컨테이너를 만들고 실행하는 백엔드 프로세스(데몬)가 분리되어 있습니다. 우리가 docker run nginx를 입력하면, CLI가 데몬에게 API 요청을 보내고 데몬이 이미지를 pull하고 컨테이너를 생성/실행합니다. 그래서 데몬이 꺼져 있거나 권한이 없으면 CLI는 정상이어도 실행이 실패합니다.

운영체제별로 체감도 다릅니다. Linux는 보통 dockerd가 시스템 서비스로 동작하고, macOS/Windows는 Docker Desktop이 가상화 계층 위에서 엔진을 제공합니다. 즉 "설치했다"보다 "엔진이 현재 살아 있고, 내 계정이 접근 가능하다"가 더 정확한 완료 조건입니다.

또 하나 중요한 점은 버전 호환성입니다. docker, docker compose, 데몬 버전 차이가 크면 예기치 못한 옵션 오류가 날 수 있습니다. 실무에서는 팀 온보딩 문서에 최소 버전과 점검 명령을 명시해 환경 차이를 줄입니다.

기본 사용

예제 1) 설치/버전/컴포넌트 점검 한 번에 확인

docker version

설명:

  • Client/Server 두 블록이 모두 보여야 정상입니다.
  • Client만 나오고 Server가 비어 있거나 에러면 데몬 연결 실패 상태입니다.
  • 추후 문제 제보 시 docker version 출력만 공유해도 진단 속도가 크게 올라갑니다.

추가 확인:

docker compose version

설명:

  • Compose 플러그인이 정상 설치되어 있는지 확인합니다.
  • 강의 후반부에서 compose를 계속 쓰므로 지금 미리 점검해두는 게 좋습니다.

예제 2) 데몬 상세 상태와 런타임 정보 확인

docker info

설명:

  • Storage Driver, Cgroup, CPU/메모리 인식, Registry 설정 등 운영에 중요한 정보가 나옵니다.
  • Server: 섹션이 제대로 뜨면 데몬 연결은 성공입니다.
  • 실무에서 "내 컴퓨터에서만 느림" 같은 이슈는 이 출력의 차이(리소스 할당/드라이버)에서 자주 발견됩니다.

문제 상황 예시:

  • Cannot connect to the Docker daemon → 데몬 미기동/권한 문제
  • TLS 관련 오류 → 원격 Docker Host 설정(DOCKER_HOST) 꼬임 가능성

예제 3) 첫 실행 점검: pull + run + 로그 확인

docker run --rm hello-world

설명:

  • 이미지 pull, 컨테이너 생성, 실행, 종료, 정리까지 최소 경로를 한 번에 검증합니다.
  • --rm으로 실습 흔적을 남기지 않아 점검 루프를 여러 번 돌리기 좋습니다.

상태 재확인:

docker ps -a

설명:

  • --rm을 붙였으면 hello-world 컨테이너가 남지 않는 것이 정상입니다.
  • 남아 있다면 옵션이 빠졌거나 실행 흐름을 잘못 이해했을 수 있습니다.

예제 4) 데몬과 CLI 통신 장애를 의도적으로 점검할 때 자주 쓰는 명령

# Linux
sudo systemctl status docker
sudo systemctl restart docker

# macOS
# GUI로 Docker Desktop 실행 후, 아래 명령으로 재확인
docker info

설명:

  • 환경별로 재시작 방법이 다릅니다.
  • Linux는 서비스 상태 확인이 핵심이고, macOS/Windows는 Desktop 앱 상태 확인이 핵심입니다.

자주 하는 실수

실수 1) docker 명령만 되면 설치 완료라고 판단

  • 원인: CLI 설치와 데몬 상태를 구분하지 못함.
  • 해결: 설치 직후 반드시 docker version에서 Server 블록까지 확인하고, docker info로 엔진 정보를 점검합니다.

실수 2) 권한 설정 없이 Linux에서 매번 sudo로만 실행

  • 원인: 현재 사용자가 docker 그룹에 속하지 않아 소켓 접근 권한이 없음.
  • 해결: 운영 정책에 맞게 docker 그룹 권한을 설정하고 재로그인 후 점검합니다.
sudo usermod -aG docker $USER
newgrp docker
docker run --rm hello-world
  • 주의: 보안 정책상 루트 권한에 준하는 영향이 있으므로 팀/서버 정책에 맞춰 적용해야 합니다.

실수 3) 원격 호스트 환경변수(DOCKER_HOST)가 남아 로컬 엔진 접속 실패

  • 원인: 과거 실습에서 설정한 환경변수가 쉘 프로필에 남아 있음.
  • 해결: 현재 셸의 Docker 관련 환경변수를 확인하고 의도치 않은 값은 제거합니다.
env | grep -E '^DOCKER|^COMPOSE'
unset DOCKER_HOST DOCKER_CONTEXT

실수 4) Desktop 리소스 할당이 너무 낮아 컨테이너가 자주 죽음

  • 원인: 기본 CPU/메모리 제한이 프로젝트 요구보다 낮음.
  • 해결: Docker Desktop 리소스 설정을 조정하고 docker info에서 반영 여부를 확인합니다.

실무 패턴

실무에서는 "설치 가이드"보다 "온보딩 검증 스크립트"가 더 중요합니다. 신규 팀원이 들어오면 아래 순서만 통과하면 다음 단계로 넘어가게 만드는 식입니다.

  1. 버전 검증: docker version, docker compose version
  2. 엔진 검증: docker info
  3. 실행 검증: docker run --rm hello-world
  4. 프로젝트 검증: 팀 표준 docker compose up -d

이 네 단계의 출력 예시를 사내 위키에 스크린샷/텍스트로 남겨두면, "어디까지 정상인가" 기준점이 생깁니다. 또한 문제 제보 템플릿에 docker version, docker info, OS 정보를 필수 항목으로 넣으면 커뮤니케이션 비용이 크게 줄어듭니다.

팀 규칙으로는 다음 두 가지를 강하게 추천합니다.

  • 도커/컴포즈 최소 버전 명시(예: Engine 27+, Compose v2.29+)
  • 트러블슈팅 1단계 명령 고정(docker context ls, docker info, docker ps -a)

이렇게 해야 개인 경험 의존이 줄고, 누구나 비슷한 속도로 문제를 해결할 수 있습니다.

오늘의 결론

한 줄 요약: Docker 설치의 완료 조건은 "명령어가 있다"가 아니라 "CLI-데몬-실행 경로가 모두 검증됐다"입니다.

오늘 점검 루틴을 습관으로 만들면 이후 강의에서 에러가 나도 당황하지 않고, 원인을 빠르게 좁힐 수 있습니다. 도커 학습 속도는 명령어 암기보다 진단 루틴을 얼마나 빨리 몸에 익히느냐로 결정됩니다.

연습문제

  1. 본인 환경에서 docker version, docker compose version, docker info를 실행하고 출력 차이를 정리해보세요. (Client/Server 구분 포함)
  2. docker run --rm hello-world 실행 후 docker ps -a 결과를 확인하고, 왜 컨테이너가 남지 않는지 설명해보세요.
  3. Docker 연결 오류가 났다고 가정하고, 원인 후보 3개(데몬 미기동/권한/환경변수)를 어떤 순서로 점검할지 체크리스트를 작성해보세요.

이전 강의 정답

1강 연습문제 해설:

  1. --rm 없이 실행하면 종료된 컨테이너가 docker ps -a에 남고, --rm을 쓰면 종료 후 자동 삭제됩니다. 실습 반복 시 --rm이 정리 비용을 줄입니다.
  2. python:3.11-slim 컨테이너에서 python --version, pip --version을 실행하면 로컬 설치 여부와 무관하게 컨테이너 내부 버전 기준으로 출력됩니다. 이게 환경 일관성의 핵심입니다.
  3. 바인드 마운트(-v "$PWD":/app) 후 컨테이너에서 ls를 실행하면 로컬 파일이 그대로 보입니다. 즉 코드는 로컬에 두고 실행 환경만 컨테이너로 고정할 수 있습니다.

실습 환경/재현 정보

  • OS: macOS 15+/Linux(ubuntu 계열) 기준
  • Docker 버전: Docker Engine/CLI 최신 안정 버전 권장
  • Compose: Docker Compose v2 플러그인
  • 실행 순서:
    1. docker version
    2. docker compose version
    3. docker info
    4. docker run --rm hello-world
    5. docker ps -a
  • 재현 체크:
    • Client/Server 모두 정상 출력되는가
    • 데몬 연결 오류 없이 info가 조회되는가
    • hello-world가 정상 실행/종료되는가
    • 점검 후 불필요 컨테이너가 남지 않는가