[도커 30강] 1강. 도커를 왜 쓰는가: 내 컴퓨터에서는 되는데 서버에서는 안 되는 문제 끝내기

Last updated on 
[도커 30강] 1강. 도커를 왜 쓰는가: 내 컴퓨터에서는 되는데 서버에서는 안 되는 문제 끝내기

도커를 처음 접하면 run, build, compose 같은 명령어가 먼저 보입니다. 그런데 진짜 출발점은 명령어가 아니라 문제 인식입니다. 도커는 "새 기술"이라서 배우는 게 아니라, 개발 환경 불일치로 생기는 반복 장애를 줄이기 위해 배웁니다. 오늘은 첫 강의답게 Docker의 본질을 이해하고, 최소한의 명령으로 실행 경험까지 가져가 보겠습니다.

핵심 개념

도커는 앱을 실행하는 데 필요한 요소(런타임, 라이브러리, 설정)를 이미지로 묶어 어디서나 같은 방식으로 실행하게 해줍니다. 그래서 팀원이 바뀌거나 서버가 달라져도 "같은 입력이면 같은 결과"를 기대할 수 있습니다.

여기서 많이 헷갈리는 개념이 VM(가상머신)과 컨테이너의 차이입니다. VM은 운영체제 전체를 가상화하고, 컨테이너는 호스트 커널을 공유하면서 프로세스 격리 방식으로 가볍게 실행됩니다. 실무에서는 이 차이 때문에 컨테이너가 더 빠른 시작 속도와 낮은 리소스 비용을 갖습니다.

그리고 가장 중요한 관점 하나: 도커는 배포 도구이면서 동시에 개발 표준화 도구입니다. 배포 직전에만 쓰는 게 아니라, 로컬 개발 단계부터 같은 컨테이너를 쓰는 팀이 장애를 덜 만납니다.

기본 사용

예제 1) 컨테이너 개념 체감: hello-world 실행

docker run --rm hello-world

설명:

  • docker run은 이미지를 가져와 컨테이너를 실행합니다.
  • --rm은 컨테이너 종료 후 자동 삭제라서 실습 흔적을 깔끔하게 정리합니다.
  • 처음 실행 시 이미지 다운로드가 일어나므로 네트워크 상황에 따라 시간이 걸릴 수 있습니다.

확인 포인트:

  • 출력에 "Hello from Docker!"가 보이면 Docker 데몬/CLI 연결이 정상입니다.

예제 2) 환경 일관성 체감: 파이썬 버전 고정 실행

docker run --rm python:3.11-slim python --version

설명:

  • 로컬에 Python이 없어도, 컨테이너 안의 Python 3.11을 즉시 실행합니다.
  • 팀에서 "3.10, 3.11 섞여서" 생기는 미묘한 버그를 줄이는 가장 간단한 시작점입니다.
  • 이미지 태그(3.11-slim)를 고정하면 재현성이 올라갑니다.

확인 포인트:

  • 출력이 Python 3.11.x면 버전 고정 실행 성공입니다.

예제 3) 프로젝트 폴더 연결: 내 코드 컨테이너에서 실행

# 현재 폴더의 파일을 컨테이너 /app 에 마운트
# macOS/Linux

docker run --rm -it -v "$PWD":/app -w /app python:3.11-slim python -c "print('컨테이너에서 코드 실행 OK')"

설명:

  • -v "$PWD":/app은 로컬 폴더를 컨테이너에 연결합니다(바인드 마운트).
  • -w /app은 작업 디렉터리를 /app으로 지정합니다.
  • 즉, "내 파일은 로컬에 두고, 실행만 컨테이너에서"라는 실무 패턴의 출발입니다.

확인 포인트:

  • 출력 문자열이 나오면 실행 성공.
  • 이후 requirements.txt 설치, 테스트 실행까지 같은 방식으로 확장할 수 있습니다.

예제 4) 여러 서비스 시작: docker compose 최소 실행

# 예시: docker-compose.yml이 있는 폴더에서
docker compose up -d

docker compose ps

설명:

  • compose는 앱 + DB + 캐시 같이 여러 컨테이너를 한 번에 관리합니다.
  • up -d는 백그라운드 실행, ps는 현재 상태 확인입니다.
  • 강의가 진행되면 단일 run보다 compose 비중이 크게 늘어납니다.

자주 하는 실수

실수 1) Docker CLI만 설치하고 데몬이 안 떠 있는 상태

원인:

  • docker 명령은 있는데 백엔드(Desktop/Colima)가 안 켜져서 Cannot connect to the Docker daemon 오류 발생.

해결:

  • Docker Desktop을 실행하거나 Colima를 시작합니다.
colima start --runtime docker

확인:

docker info

실수 2) latest 태그 남용으로 재현성 깨짐

원인:

  • python:latest처럼 가변 태그를 쓰면 시점마다 다른 환경이 실행됩니다.

해결:

  • 가능하면 python:3.11-slim처럼 고정 태그를 사용합니다.
  • 운영 단계에서는 digest pinning까지 고려합니다.

실수 3) 컨테이너와 이미지 정리를 안 해서 디스크 폭증

원인:

  • 실습 반복 후 중간 이미지/중지 컨테이너가 쌓입니다.

해결:

docker ps -a
docker image ls
docker system prune -f

주의:

  • prune은 불필요 리소스를 정리하므로, 필요한 볼륨/이미지를 지우지 않게 확인 후 실행합니다.

실무 패턴

도커를 오래 잘 쓰는 팀은 규칙이 단순합니다.

  1. 개발 시작 명령 통일
    make up 또는 docker compose up -d처럼 시작 명령을 팀 공통으로 고정합니다.

  2. 버전/이미지 태그 고정
    언어 런타임 버전, DB 버전을 명시적으로 박아 재현성을 확보합니다.

  3. 로컬-스테이징-운영 차이 최소화
    환경변수만 바꾸고 실행 구조는 동일하게 유지합니다.

  4. 로그/헬스체크 먼저 설계
    "일단 뜨는가"를 넘어서 "문제 시 어디가 아픈가"를 바로 볼 수 있게 만듭니다.

오늘의 결론

한 줄 요약: 도커의 핵심은 컨테이너 기술이 아니라, 환경 차이로 생기는 불확실성을 줄이는 운영 습관입니다.

첫 강의에서는 명령어 몇 개보다 이 관점을 가져가는 게 훨씬 중요합니다. 앞으로 강의에서는 이 위에 이미지 빌드, Dockerfile 설계, Compose 실전, 데이터 영속성, 배포 전략까지 차근차근 쌓겠습니다.

연습문제

  1. hello-world를 실행하고 --rm 유무에 따라 docker ps -a 결과 차이를 비교해보세요.
  2. python:3.11-slim 컨테이너에서 python --version과 pip --version을 확인해보세요.
  3. 현재 프로젝트 폴더를 마운트해 컨테이너에서 파일 목록(ls)을 출력해보세요.

이전 강의 정답

  • 1강이므로 이전 강의 정답은 없습니다.

실습 환경/재현 정보

  • OS: macOS / Linux 공통
  • Docker: Docker Engine(또는 Desktop) + Docker Compose
  • 실습 순서:
    1. docker run --rm hello-world
    2. docker run --rm python:3.11-slim python --version
    3. docker run --rm -it -v "$PWD":/app -w /app python:3.11-slim python -c "print('OK')"
  • 재현 체크:
    • Docker 데몬 연결이 정상인지(docker info)
    • 이미지가 정상 pull되는지
    • 바인드 마운트 경로가 올바른지