게으른 개발자의 끄적거림

[Docker] Docker 완벽 정리

끄적잉 2026. 2. 10. 22:55

내 컴퓨터에선 됐는데 왜 서버에선 안 될까? (도커 입문 가이드)

 안녕하세요! 오늘은 개발자라면 누구나 한 번쯤 겪어봤을, 아니 어쩌면 지금 이 순간에도 여러분의 뒷목을 잡게 만들고 있을 그 주제에 대해 이야기해보려 합니다. 바로 **도커(Docker)**입니다.

우리가 개발을 하다 보면 가장 많이 하는 거짓말(?) 중 하나가 뭔지 아세요? 바로 이겁니다.

 

"어? 내 컴퓨터에선 분명히 잘 됐는데요?"

분명 내 로컬 환경(맥북, 윈도우)에서는 쌩쌩 돌아가던 코드가, 배포 서버에만 올라가면 에러를 뿜어냅니다. 자바 버전이 다르다느니, 환경 변수가 안 잡혔다느니, 리눅스 패키지 뭐가 없다느니... 이런 '환경 지옥'에서 우리를 구원해 줄 고래 한 마리, 지금부터 제대로 파헤쳐 보겠습니다.


 

1. 도커는 왜 태어났을까? (환경 지옥의 종말)

우리가 흔히 겪는 문제를 떠올려봅시다. 새로 합류한 팀원에게 개발 환경을 세팅해줘야 할 때, 우리는 보통 이런 가이드를 줍니다.

  1. "자바 17 깔으시고요."
  2. "환경 변수 JAVA_HOME 잡으세요."
  3. "아, 아나콘다 쓰시나요? 그럼 가상환경부터 만드시고..."
  4. "DB는 포스트그레스(Postgres) 13버전인데, 설정 파일은 제가 카톡으로 보내드릴게요."

이 과정에서 꼭 한두 명은 "저 에러 나는데요?"라고 말하죠. 운영체제마다 파일 경로가 다르고, 이미 설치된 다른 소프트웨어와 충돌이 나기 때문입니다.

도커는 여기서 **"그냥 내가 돌아가는 환경을 통째로 박스에 담아서 줄게!"**라는 기발한 생각을 합니다. 이 박스 안에는 코드뿐만 아니라 운영체제 핵심 기능, 라이브러리, 설정값까지 싹 다 들어있습니다. 이 박스만 있으면 윈도우든 리눅스든 맥이든, 어디서든 똑같이 실행됩니다. 이게 바로 도커의 본질입니다.


 

2. 가상 머신(VM)과 도커, 뭐가 다른데?

보통 도커를 처음 배우면 "어, 그럼 VMware나 VirtualBox 같은 가상 머신이랑 똑같은 거 아니야?"라고 묻습니다. 결론부터 말씀드리면 **"비슷하지만 훨씬 가볍고 빠르다"**입니다.

이해를 돕기 위해 아파트와 고시원 비유를 들어볼게요.

  • 가상 머신 (Virtual Machine): 아파트를 한 채 통째로 짓는 것입니다. 집마다 전용 현관문, 부엌, 화장실, 배관이 다 따로 있죠. 안전하고 독립적이지만, 짓는 데 오래 걸리고 자원(땅)을 많이 차지합니다. OS 위에 또 OS를 올리는 격이라 굉장히 무겁습니다.
  • 도커 컨테이너 (Docker Container): 이미 지어진 건물에 방만 빌리는 방식입니다. 수도나 전기는 같이 쓰되(OS 커널 공유), 내 방 안에서는 내가 뭘 하든 간섭받지 않습니다. 방만 꾸미면 되니까 만드는 속도가 엄청나게 빠르고, 아파트 한 채 지을 자원에 방 수십 개를 만들 수 있습니다.

실제로 VM은 부팅하는 데 몇 분씩 걸리지만, 도커 컨테이너는 실행 명령을 내리는 즉시 1초 만에 뜹니다. 개발자에게 이 '속도'는 엄청난 축복이죠.


3. 도커의 핵심 삼인방: Dockerfile, Image, Container

도커를 공부하다 보면 이 세 단어가 계속 나올 텐데요. 요리 과정에 비유하면 뇌에 박제할 수 있습니다.

① Dockerfile (레시피)

"라면을 끓이려면 물 500ml를 넣고, 스프를 먼저 넣고, 면을 넣어라"라고 적힌 텍스트 파일입니다.

  • FROM python:3.9 (파이썬 3.9 환경에서 시작해!)
  • COPY . /app (내 소스 코드를 복사해 넣어!)
  • CMD ["python", "main.py"] (이걸 실행해!) 이렇게 명령어를 적어두는 설계도입니다.

② Image (밀키트)

설계도(레시피)를 바탕으로 실제 요리 재료들을 다 모아서 얼려놓은 밀키트입니다. 이 밀키트는 변하지 않습니다(Immutable). 누가 사 가든, 어디서 뜯든 그 안의 재료는 항상 똑같죠. 이미지는 실행되기 전의 '상태'를 의미합니다.

③ Container (완성된 요리)

밀키트를 뜯어서 냄비에 끓인 상태입니다. 실제로 서비스가 돌아가고 있는 실체죠. 우리는 하나의 밀키트(이미지)로 수십 개의 요리(컨테이너)를 동시에 만들어낼 수 있습니다. 배달 주문이 밀리면(트래픽이 늘어나면) 냄비 수만 늘리면 되는 거죠.


 

4. 개발자가 도커를 쓰면 얻는 개이득(Advantage) 3가지

첫째, "Clean & Clear" 내 컴퓨터가 깨끗해집니다.

예전에는 새로운 프로젝트를 할 때마다 온갖 DB와 라이브러리를 내 컴퓨터에 직접 깔았습니다. 프로젝트가 끝나도 지우기 귀찮아서 방치하다 보면 어느새 내 맥북은 쓰레기장이 되죠. 도커를 쓰면? 컨테이너만 지우면 끝입니다. 내 컴퓨터 본체는 언제나 쾌적합니다.

둘째, 협업 효율의 극대화

"저기, 제 컴퓨터에선 되는데..."라는 말을 원천 봉쇄합니다. 모든 팀원이 동일한 이미지를 내려받아 실행하기 때문에, "환경 설정 때문에 하루 버렸어요"라는 핑계가 사라집니다. (이건 좀 슬픈 일일 수도 있겠네요...)

셋째, 배포의 혁명

로컬에서 테스트 완료한 이미지를 그대로 서버에 올리기만 하면 됩니다. "서버 가니까 라이브러리 버전이 다르네?" 같은 공포스러운 상황에서 해방됩니다. CI/CD 파이프라인의 핵심이 바로 이 도커입니다.


5. 마치며: 고래 등에 올라타는 것을 두려워하지 마세요

처음엔 터미널에 명령어를 치는 게 낯설고, 네트워크 설정이나 볼륨 마운트 같은 개념이 어렵게 느껴질 수 있습니다. 하지만 한 번 익숙해지고 나면, 도커 없는 개발 인생으로는 절대 돌아갈 수 없을 겁니다.

마치 피처폰을 쓰다가 스마트폰을 처음 썼을 때의 충격 같달까요? 여러분의 소중한 코드가 어떤 환경에서도 당당하게 돌아갈 수 있도록, 오늘 당장 docker run 한 번 쳐보시는 건 어떨까요?