도커란 무엇인가 — 가상머신과의 차이 이해하기
처음 서버 배포를 하던 시절, 개발 환경이 제멋대로 달라지는 게 정말 골칫거리였습니다.
로컬에서는 잘 돌던 코드가 서버에 올리면 에러가 나고,
“그거 너 노드 버전 달라서 그래” 같은 말을 수도 없이 들었죠.
그러다 “환경 자체를 코드로 묶어서 관리할 수 있다”는 말을 듣고 처음 접한 게 Docker였습니다.
당시엔 이름부터 낯설었지만, 한 줄 요약하자면 도커는 **‘어디서나 똑같이 실행되는 개발 환경을 만드는 도구’**였습니다.
환경이 다르면 코드가 망가진다
서버를 옮기거나 팀원이 새로 합류할 때마다 생기는 “환경 차이” 문제는 정말 흔합니다.
리눅스 버전이 달라서 패키지가 깨지고,
라이브러리 버전이 엇나가서 빌드가 실패하는 등,
결국 해결책은 “환경 자체를 통째로 묶는 것”이었습니다.
이걸 가능하게 만든 게 바로 컨테이너 개념입니다.
가상머신과 컨테이너의 차이, 감으로 이해하기
가상머신(VM)을 한 번이라도 써본 분들은 알 겁니다.
Ubuntu 이미지를 깔면 수 GB짜리 OS가 통째로 돌아가죠.
그 위에 프로그램을 설치하니 무겁고 느립니다.
반면, 도커 컨테이너는 OS 전체를 복사하지 않습니다.
호스트 운영체제의 커널을 공유하면서 필요한 부분만 격리해서 실행합니다.
그래서 훨씬 가볍고 빠르게 동작합니다.
간단히 말하면 이렇습니다:
구분 가상머신 도커 컨테이너
| OS | 게스트 OS 필요 | 호스트 OS 공유 |
| 실행 속도 | 느림 | 빠름 |
| 용량 | 수 GB | 수백 MB |
| 사용 목적 | 완전한 시스템 분리 | 서비스 단위 격리 |
이걸 이해하면 “왜 요즘 대부분의 서비스가 VM 대신 도커를 쓰는지” 바로 감이 옵니다.
도커가 해결한 진짜 문제
도커의 진짜 강점은 기술보다 ‘일관성’에 있습니다.
어떤 환경에서 실행하든 **“항상 같은 결과”**를 보장한다는 점이죠.
개발자는 “한 번 설정한 환경”을 도커 이미지로 묶어두고,
배포할 땐 단순히 그 이미지를 서버에서 실행하기만 하면 됩니다.
서버마다 환경을 새로 맞추던 시대에서,
이제는 “도커 이미지 하나면 끝나는” 세상으로 바뀐 겁니다.
직접 써보니 느껴졌던 부분
처음엔 “그냥 가상머신이랑 비슷하겠지”라는 생각으로 접근했습니다.
그런데 실제로 써보니, 가상머신은 시스템 전체를 띄우는 반면 도커는 필요한 부분만 격리해서 돌린다는 차이가 엄청났습니다.
컨테이너를 띄우는 데 몇 초밖에 안 걸리고, 서버 리소스도 훨씬 효율적으로 쓰이더군요.
게다가 이미지를 한 번 만들어 두면,
팀원 전부가 같은 환경에서 개발할 수 있습니다.
“내 컴퓨터에선 되는데?”라는 말이 사라졌죠.
다음 단계에서 배우게 될 것들
이제 도커가 왜 필요한지는 감이 잡히셨을 겁니다.
다음 편에서는 도커 이미지와 컨테이너의 관계를 구체적으로 다뤄볼 겁니다.
어떻게 이미지가 실행돼 컨테이너로 변하는지,
그리고 그 과정에서 어떤 파일 구조가 만들어지는지 실습으로 직접 확인해보겠습니다.
이 형태가 지금 문체 규칙에도 가장 잘 어울립니다.
다음 강의는 “도커 이미지와 컨테이너의 관계” 주제로 같은 톤으로 이어갈까요?