Docker를 사용해야 하는 이유 (Docker와 Container)

도커가 없던 시절

---

 

도커가 컨테이너 이전에 살던 개발자는 비효율 속에서 개발을 진행했다.
새로 취업하면 개발환경 세팅만 하다가 하루가 날아갔고, 개발환경을 업데이트할 때마다 뭔가 하나는 반드시 망가졌다.
그리고 로컬에서 잘 돌아가던 코드를 서버에 올리는 순간, 에러가 터지거나 컴퓨터가 폭발하는 일도 흔했다.

이 모든 혼돈은 도커와 컨테이너의 등장으로 상당 부분 사라졌다.

 

때문에 도커는 지금 개발자가 가장 많이 쓰는 도구 중 하나다.
코딩 책을 보거나 딥러닝 모델을 다운로드해 실행하려고 해도 설명 첫 줄에 도커 명령어가 등장하는 경우가 흔하다.

도커는 리눅스 컨테이너를 기반으로 한 OS 레벨 가상화를 쉽게 쓰게 해주는 도구다.
개발환경을 통째로 묶어 동일하게 재현할 수 있게 해준다.

 

같은 코드를 다른 컴퓨터에서 실행해야 하는 상황은 매우 흔하다.
하지만 내 컴퓨터에서 잘 돌아가던 코드가 다른 컴퓨터에서는 잘 안 돌아간다. 이유는 간단하다.
OS가 다르고, 설치된 기본 프로그램이 다르고, 라이브러리 버전도 다르기 때문이다.

그래서 해결책은 하나다.
내가 쓰던 OS와 라이브러리, 실행 환경을 통째로 복제해서 그 위에서 코드를 실행하는 것.

 

 

 

 

VM에서 컨테이너로

---

 

예전에는 이를 위해 VM을 썼다.
하나의 OS 위에 또 다른 OS를 띄우는 방식이다.

문제는 무겁고 느리다는 점이다. 성능 손실도 크고 관리도 번거롭다.

그래서 등장한 것이 도커와 컨테이너다.

 

구체적으로 설명하면, 가상 머신은 하이퍼바이저 위에 Guest OS가 올라가는 구조다.
각 VM마다 Ubuntu나 CentOS 같은 완전한 운영체제가 필요하며, 여기에는 커널, 시스템 라이브러리, 각종 유틸리티까지 모두 포함되고, 이 때문에 VM 하나당 수 GB의 디스크 공간을 차지하게 된다.

 

반면 컨테이너는 도커 엔진과 같은 컨테이너 런타임 위에서 동작한다.
호스트 OS의 커널을 공유하고, 각 컨테이너는 필요한 라이브러리와 실행 파일만을 포함한 논리적으로 격리된 구조를 가진다.

이 구조적 차이로 인해 컨테이너는 훨씬 가볍다.
커널을 포함하지 않기 때문에 이미지 크기는 MB 단위에 불과하며, 시작 시간도 가상 머신의 분 단위가 아니라 초 단위로 줄어든다.

 

리소스 오버헤드에서도 분면한 차이를 보이는데, 가상 머신은 CPU와 메모리를 VM 단위로 고정 할당해야 한다.
예를 들어 메모리를 4GB 할당한 VM이 실제로 2GB만 사용하더라도, 나머지 2GB는 다른 VM이 사용할 수 없다.

 

반면 컨테이너는 호스트의 리소스를 공유하면서 필요에 따라 사용한다.
이 때문에 동일한 하드웨어에서 훨씬 높은 밀도를 낼 수 있다.
64GB 메모리를 가진 서버에서 가상 머신은 보통 10~15개 정도가 한계인 반면, 컨테이너는 50개에서 많게는 100개 이상까지도 실행할 수 있다.

결과적으로 컨테이너는 더 가볍고, 더 빠르며, 더 높은 자원 효율을 제공하는 실행 단위라 할 수 있다.

 

 

도커에서 컨테이너 만드는 데 필요한 것은 파일 하나인데, 이름은 Dockerfile이다.

여기에 다음 내용을 순서대로 적는다.

• 어떤 OS를 쓸 것인지
• 어떤 프로그램과 라이브러리를 설치할지
• 어떤 코드를 어떻게 실행할지

그리고 명령어 하나를 치면 개발환경이 그대로 포장된 이미지가 만들어진다.

 

 

 

도커가 바꿔버린 개발 문화

---

도커와 컨테이너가 등장한 이후, 개발자들은 신기한 짓을 하기 시작했다.

배포가 너무 쉬워졌기 때문이다.

• 서버 기능을 하나의 거대한 프로그램에 몰아넣던 방식에서 잘게 쪼개 여러 서비스로 나누는 구조로 바뀌었다.
  이것이 바로 Micro Software Architecture다.
• 빌드, 테스트, 배포가 자동화되면서 CI/CD가 표준처럼 자리 잡았다.
• 원하는 프로그램을 원하는 버전으로 설치했다가 흔적 없이 삭제할 수 있어
  로컬 환경을 더럽히기 싫어하는 결벽증 개발자도 생겨났다.

 

 

사실 도커의 핵심은 리눅스다.

도커는 신기술이 아니다.
컨테이너라는 개념은 1960년대부터 존재했고,
도커가 등장하기 전에도 LXC, OpenVZ, Solaris Zones, FreeBSD Jail 같은 기술은 이미 있었다.

심지어 도커 자체도 LXC 기반으로 만들어진 구현체 중 하나에 불과했다.

 

프로세스를 격리하고, 자원을 분리하고, 독립된 실행 환경을 제공한다는 아이디어는 메인프레임 시절부터 존재했다.

도커의 격리기술 분야 자체는 기술적으로는 이미 충분히 성숙한 영역이었다.

 

하지만 문제는 이것들이

• 개발자에게 친절하지 않았고
• 배포 단위로 쓰기 어려웠으며
• “이걸 왜 써야 하는지”를 설명하지 못했다는 점이다.

 

도커의 가장 큰 차별점은 컨테이너 기술을 ‘개발자가 쓰는 제품’으로 재정의했다는 점이다.

기존 컨테이너 기술은 인프라 엔지니어의 영역이었다.
설정은 복잡했고, 문서는 불친절했으며, “이걸 쓰면 뭐가 좋아지는데?”라는 질문에 답하기 어려웠다.

반면 도커는 처음부터 달랐다.

• Dockerfile 하나로 환경을 정의하고
• docker build, docker run이라는 직관적인 UX를 제공하고
• 이미지를 중심으로 한 명확한 사고 모델을 제시했다

 

 

 

도커의 단점

---

물론 단점도 있다.

• 새로운 보안 이슈가 생길 수 있다
• 컨테이너가 많아지면 관리 인력이 필요하다
• 초기 서버 비용이 생각보다 많이 든다
• 데이터를 영구적으로 저장해야 하는 경우에는 적합하지 않을 수 있다

 

가장 큰 문제는 학습 곡선이다

가장 중요한 문제는 코딩 초보자의 러닝 커브가 훨씬 가팔라졌다는 점이다.

도커가 좋다고 해서 코딩 입문 단계부터 도커 세팅을 시키는 경우도 많다.

이건 요리를 배우겠다면서 밀키트만 튀겨보는 것과 같다.

 

코딩 입문 단계에서는 내 컴퓨터와 직접 싸워보는 경험이 중요하다.

라이브러리 충돌도 겪어보고, 환경 변수도 망가뜨려보고, OS 설정으로 뻘짓을 한 번쯤 해봐야 한다.

그래야 나중에 Dockerfile을 자신 있게 작성하고, 컨테이너를 이해한 상태로 빌드와 배포를 할 수 있다.