Docker의 실무 활용 사례 및 사용법

서론: Docker란 무엇인가?

Docker는 애플리케이션을 컨테이너화하여 어디서나 동일하게 실행할 수 있도록 도와주는 오픈 소스 플랫폼입니다. 개발자는 Docker를 통해 애플리케이션과 그 실행에 필요한 라이브러리, 종속성을 하나로 묶은 컨테이너 이미지를 만들고 실행할 수 있습니다. 이러한 컨테이너는 운영 체제 커널을 공유하면서 애플리케이션을 격리된 환경에서 동작시키는 기술로, 기존의 가상 머신(VM)과 비교했을 때 훨씬 가볍고 효율적입니다. 실제로 Docker는 컨테이너 분야에서 약 80% 이상의 시장 점유율을 차지할 정도로 널리 사용되고 있으며, 'Docker'와 '컨테이너'라는 용어가 같은 의미로 쓰일 정도로 표준 도구가 되었습니다.

가상 머신(VM) 아키텍처: VM 환경에서는 각 애플리케이션이 자체 운영체제(Guest OS)를 포함하여 동작하기 때문에 시스템이 상당히 무겁습니다. 이러한 구조에서는 하나의 물리 서버 위에서 하이퍼바이저를 통해 여러 VM을 실행합니다. 그리고 각 VM이 자체 OS를 갖고 있기 때문에 실행 속도와 자원 효율 면에서 추가적인 부담이 생깁니다.

Docker 컨테이너 아키텍처: Docker 환경에서는 컨테이너들이 호스트 OS의 커널을 공유하여 필요한 라이브러리와 애플리케이션 코드만을 포함하므로, VM보다 훨씬 빠르고 경량으로 동작합니다. 각 컨테이너는 격리된 환경을 제공하여 한 컨테이너의 환경이 다른 컨테이너에 영향을 주지 않으며, 한 번 컨테이너 이미지를 만들어 두면 어디서나 동일한 환경으로 실행할 수 있어 일관성이 높습니다. 이러한 특성 덕분에 개발 머신에서는 잘 돌아가지만 다른 환경에서는 문제가 생기는 이른바 "내 컴퓨터에서만 잘 돌아가는(works on my machine)" 상황을 예방할 수 있습니다.

Docker의 실무 활용 사례

이제 Docker가 실제 현업에서 어떻게 활용되는지 주요 사례들을 살펴보겠습니다:

• 배포 및 환경 일관성: Docker 컨테이너 이미지는 개발 환경에서 만든 그대로의 설정을 프로덕션 서버에 배포할 수 있어, 환경 차이로 인한 오류를 크게 줄여줍니다. 예를 들어, 온프레미스(사내 서버)에서 개발한 애플리케이션을 클라우드 환경으로 이전할 때도 Docker 이미지를 활용하면 수월하게 이전할 수 있습니다. Docker의 이식성 덕분에 한 번 만든 이미지를 다양한 환경에 손쉽게 배포할 수 있어 클라우드 마이그레이션에도 적극 활용되고 있습니다.
• 테스트 및 CI/CD 환경 구축: Docker는 테스트 환경 세팅을 자동화하고 표준화하는 데 유용합니다. 컨테이너 내부에 테스트에 필요한 서비스나 DB 등을 구성해 두고, CI(지속적 통합) 파이프라인에서 해당 컨테이너들을 올려 테스트함으로써 로컬 환경과 테스트/스테이징 환경을 동일하게 유지할 수 있습니다. 이를 통해 배포 단계에서 환경 차이로 인한 오류를 감소시킬 수 있습니다. 또한 개발 중에도 Docker를 이용해 손쉽게 로컬에 데이터베이스나 캐시 서버 등을 구동하여 테스트할 수 있고, 앞서 언급한 "works on my machine" 문제 역시 컨테이너로 동일한 환경을 재현함으로써 해결됩니다.
• 마이크로서비스 아키텍처: 오늘날 많은 기업들이 거대 모놀리식(monolithic) 애플리케이션 대신 마이크로서비스 아키텍처를 도입하고 있는데, 실제 통계로도 글로벌 대기업의 85% 이상이 마이크로서비스를 활용하고 있다고 알려져 있습니다. Docker는 각 서비스를 컨테이너 단위로 분리하여 패키징함으로써 이러한 마이크로서비스 구현을 쉽게 만들어줍니다. 각 서비스별로 컨테이너로 배포하면 필요한 환경을 따로 구성할 필요 없이 컨테이너 이미지로 관리 및 확장할 수 있어 전체 애플리케이션 배포가 간소화됩니다. 필요에 따라 특정 서비스 컨테이너만 손쉽게 확장(스케일 아웃)하거나 업데이트할 수도 있어 유연성이 높습니다.
• DevOps와 개발 프로세스 개선: Docker의 등장은 개발(Dev)과 운영(Ops)의 경계를 허물며 DevOps 문화 정착에도 기여했습니다. 개발 팀은 Docker로 애플리케이션 환경을 컨테이너 이미지로 만들어 운영팀에 전달하고, 운영팀은 해당 이미지를 그대로 배포함으로써 환경 구성에 드는 시간을 절약할 수 있습니다. 이처럼 DevOps 파이프라인에 Docker를 활용하면, 빠른 빌드와 배포 사이클을 구현하여 애플리케이션을 더욱 민첩하게(iterative) 개선할 수 있습니다. 실제로 Docker 및 컨테이너 기술은 현대 소프트웨어 개발에서 필수 요소가 되었으며, 변화하는 요구에 빠르게 대응하는 데에 핵심적인 역할을 하고 있습니다.

Docker의 장점 정리

위의 사례들에서 언급되었듯이, Docker를 사용하면 얻을 수 있는 장점이 매우 많습니다. 주요 장점을 정리하면 다음과 같습니다:

• 경량 및 빠른 실행: Docker 컨테이너는 필요한 OS 프로세스와 라이브러리만 포함하기 때문에 이미지 크기가 수 메가바이트(MB) 정도로 작고, VM처럼 수 분이 아닌 몇 초 만에 기동할 수 있을 정도로 가볍습니다. 반면 VM은 게스트 OS 전체를 포함하여 수 기가바이트(GB)에 달하기 때문에 부팅에 시간이 걸리고 메모리 등 자원도 더 많이 사용하게 됩니다. Docker의 경량 컨테이너는 이러한 비효율을 제거하여 서버 자원을 효율적으로 활용합니다.
• 이식성 & 환경 일관성: "한 번 작성하면 어디서나 실행할 수 있다"는 문구처럼, Docker로 패키징된 애플리케이션은 개발 PC, 테스트 서버, 프로덕션 클라우드 등 어디서든 동일한 환경에서 동작합니다. 이를 통해 라이브러리 버전 불일치나 OS 설정 차이로 인한 오류를 방지할 수 있습니다. Docker를 사용하면 모든 개발 단계에서 동일한 환경을 유지할 수 있어 배포 시 예측하지 못한 문제가 줄어들고, 팀 간 환경 설정 공유도 간편해집니다.
• 높은 자원 효율성과 확장성: Docker 컨테이너는 VM 대비 훨씬 높은 밀도로 하나의 호스트에서 여러 애플리케이션을 실행할 수 있습니다. 동일한 하드웨어에서 VM을 사용할 때보다 몇 배 이상의 컨테이너를 구동할 수 있어 자원 활용 효율을 극대화하고, 그만큼 클라우드 인프라 비용을 절감할 수 있습니다. 또한 컨테이너는 필요에 따라 손쉽게 추가 생성하거나 제거할 수 있어 애플리케이션의 수평 확장(horizontal scaling)이 용이합니다.
• 격리된 안정적인 환경: Docker는 프로세스 격리를 통해 각 컨테이너가 독립된 환경을 갖도록 합니다. 하나의 컨테이너에 새로운 라이브러리를 설치하거나 설정을 변경해도 다른 컨테이너에는 영향을 주지 않으며, 호스트 시스템에도 격리된 형태로 적용됩니다. 이러한 격리성 덕분에 서로 다른 버전의 소프트웨어나 충돌할 수 있는 의존성도 한 시스템에서 공존시킬 수 있고, 애플리케이션을 안정적으로 운영할 수 있습니다. 컨테이너 자체가 하나의 프로세스로 동작하기 때문에 필요 시 빠르게 재시작하거나 문제 발생 시 다른 컨테이너로 교체할 수 있다는 점에서도 안정성이 높습니다.
• 신속한 배포 및 롤백: Docker 이미지는 애플리케이션의 상태를 불변(immutable)하도록 패키지하기 때문에, 한 번 이미지를 빌드해 두면 동일한 버전을 여러 서버에 일관되게 배포할 수 있습니다. 새로운 버전을 출시할 때도 기존 컨테이너를 수정하는 대신 새로운 컨테이너를 배포하고, 문제가 발생하면 이전 버전 이미지로 쉽게 롤백할 수 있습니다. 이러한 Immutable Infrastructure 개념을 통해 시스템 설정을 코드로서 관리하고, 자동화된 대규모 배포 및 **자동 확장(Auto-scaling)**에 유리한 환경을 구현할 수 있습니다. Docker를 활용한 배포 파이프라인에서는 출시 속도가 크게 빨라지고 오류 발생 시에도 신속한 대처가 가능합니다.

실습: Python 웹 서버(Flask) 컨테이너 만들기

이제 간단한 예제로 Docker 컨테이너를 만들어 보겠습니다. Python으로 작성된 웹 애플리케이션(Flask 프레임워크 사용)을 Docker를 이용해 컨테이너화하고 실행하는 과정을 단계별로 따라가 볼 텐데요. 예제 애플리케이션은 "Hello, Docker!"라는 문자열을 웹 페이지에 출력하는 단순한 웹 서버이며, 이를 Docker 이미지로 빌드하여 로컬에서 실행해 보겠습니다.

먼저 실습을 위한 프로젝트 디렉터리를 하나 생성하고, 아래와 같은 구조로 파일을 준비합니다:

my-docker-app/
├── app.py
├── requirements.txt
└── Dockerfile

Python 애플리케이션 파일 작성 (app.py)

Flask를 사용하여 간단한 웹 애플리케이션을 만들어봅시다. app.py 파일을 생성하고 다음과 같이 내용을 작성합니다:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello, Docker!"

if __name__ == "__main__":
    # Flask 내장 서버 실행 (모든 호스트에서 접속 가능하도록 설정)
    app.run(host="0.0.0.0", port=5000)

위 코드에서는 Flask 프레임워크로 웹 서버 객체 app을 생성하고, 루트 경로(/)에 접속했을 때 "Hello, Docker!"라는 응답을 돌려주는 함수를 정의했습니다. 마지막 부분에서 app.run(host="0.0.0.0", port=5000)로 애플리케이션을 구동하는데, host="0.0.0.0" 설정을 통해 컨테이너 내에서 모든 호스트의 요청을 받을 수 있도록 했습니다. (이 설정이 없으면 Flask는 기본적으로 localhost(127.0.0.1)에서만 접속을 받기 때문에 Docker 컨테이너 외부에서 접근이 불가능합니다.)

requirements.txt 생성

Flask 애플리케이션이 의존하는 패키지들을 나열하는 requirements.txt 파일을 생성합니다. 해당 파일에는 우리의 앱을 실행하기 위한 Python 패키지와 버전을 명시합니다:

Flask==3.1.1

예제에서는 Flask의 최신 버전인 3.1.1을 사용했습니다. 실제 환경에 따라 필요에 따라 다른 라이브러리나 특정 버전을 이 파일에 추가할 수 있습니다. requirements.txt 파일에 의존성을 명시해 두면 Docker 이미지 빌드 시 이 파일을 참조하여 필요한 패키지들을 자동으로 설치하기 때문에 편리합니다.

Dockerfile 작성

이제 Docker 컨테이너 이미지를 만들기 위한 Dockerfile을 작성합니다. Dockerfile은 컨테이너 빌드 과정을 명시한 스크립트 파일로, 아래 내용을 Dockerfile에 작성합니다:

# 베이스 이미지로 가벼운 Python 3.11 슬림 이미지 사용
FROM python:3.11-slim

# 작업 디렉터리 생성 및 설정
WORKDIR /app

# Python 의존성 목록을 먼저 복사하고 설치
COPY requirements.txt ./
RUN pip install -r requirements.txt

# 애플리케이션 소스 코드를 모두 복사
COPY . .

# Flask 앱이 사용할 포트 열기 (옵션)
EXPOSE 5000

# 컨테이너 실행 시 Flask 앱 구동
CMD ["python", "app.py"]

각 지시어의 역할을 살펴보겠습니다. FROM은 해당 이미지를 생성할 기반 이미지를 지정하는 것으로, 여기서는 공식 Python 3.11 슬림(slim) 이미지를 사용했습니다. WORKDIR /app은 컨테이너 내부에서 작업 디렉터리를 /app 경로로 설정합니다. 다음으로 COPY requirements.txt ./는 현재 디렉터리의 requirements.txt 파일을 컨테이너의 작업 디렉터리(/app)로 복사하는 명령입니다. 이어서 RUN pip install -r requirements.txt를 실행하여 복사된 requirements.txt 기반으로 필요한 파이썬 패키지들을 컨테이너 환경에 설치합니다. 그런 다음 COPY . . 명령으로 현재 디렉터리의 모든 파일(우리의 app.py 포함)을 컨테이너 이미지에 복사합니다. EXPOSE 5000은 (선택 사항이지만) 이 컨테이너가 5000번 포트를 사용한다는 것을 명시하여 메타데이터로 표시하는 지시어입니다. 마지막으로 CMD ["python", "app.py"]는 컨테이너가 시작될 때 실행할 명령을 지정하는 것으로, 컨테이너가 구동되면 파이썬으로 app.py 파일을 실행하여 Flask 웹 서버를 시작하라는 의미입니다.

이 Dockerfile을 통해 Flask 및 그 의존 라이브러리가 설치된 애플리케이션 환경이 하나의 이미지로 패키징됩니다. 이제 이 이미지를 빌드하여 실제로 컨테이너를 실행해보겠습니다.

Docker 이미지 빌드와 실행

터미널에서 프로젝트 디렉터리(my-docker-app)로 이동한 후, 다음 명령을 실행하여 Docker 이미지를 빌드합니다:

$ docker build -t my-flask-app .

-t my-flask-app 옵션은 새로 만드는 이미지에 my-flask-app 이라는 이름(or 태그)을 지정하는 것입니다. 마지막의 .은 현재 디렉터리를 빌드 컨텍스트로 사용하겠다는 의미로, Docker가 이 디렉터리에서 Dockerfile을 찾고 그 내용을 기반으로 이미지를 생성하게 됩니다. 명령 실행 후 로그에 설치 과정 등이 출력되며, 성공적으로 완료되면 로컬 Docker에 my-flask-app이라는 이름의 이미지가 생성됩니다.

이미지가 빌드되었다면, 이제 해당 이미지로 컨테이너를 생성하여 실행해보겠습니다. 아래 명령을 입력하세요:

$ docker run -d -p 5000:5000 my-flask-app

여기서 -d 옵션은 컨테이너를 백그라운드(detached) 모드로 실행하라는 의미입니다. -p 5000:5000 옵션은 호스트의 포트 5000을 컨테이너의 포트 5000에 연결(port mapping)하는 것으로, 내 컴퓨터에서 localhost:5000으로 접근하면 Docker 컨테이너 내부의 Flask 앱(포트 5000)에 접속할 수 있게 해줍니다. 명령의 마지막 부분 my-flask-app은 실행할 이미지의 이름입니다.

정상적으로 실행되었다면 Docker 데몬이 백그라운드에서 Flask 앱 컨테이너를 구동하고 있을 것입니다. docker ps 명령으로 현재 실행 중인 컨테이너 목록을 확인하면 my-flask-app 이름의 컨테이너가 리스트에 나타나는 것을 볼 수 있습니다.

컨테이너 테스트 방법

마지막으로, 웹 브라우저를 열고 http://localhost:5000에 접속해 보십시오. Flask 애플리케이션이 정상적으로 동작하고 있다면 브라우저 화면에 "Hello, Docker!" 메시지가 표시될 것입니다. 만약 터미널에서 확인하고 싶다면 curl 명령을 이용해도 됩니다:

$ curl http://localhost:5000
Hello, Docker!

위와 같이 "Hello, Docker!" 문자열이 출력되면 컨테이너화된 Flask 웹 서버가 성공적으로 작동하고 있는 것입니다. 로컬 머신에 Python이나 Flask를 직접 설치하지 않았더라도, Docker 컨테이너만으로 애플리케이션이 구동됨을 확인할 수 있습니다. 이 컨테이너는 호스트 환경과 격리되어 있으므로, Flask 서버가 사용하는 포트 외에는 호스트 시스템에 영향을 주지 않습니다. 애플리케이션 코드를 수정하여 새로운 버전의 이미지를 빌드하고 컨테이너를 재실행하면 변경사항이 반영된 새로운 환경을 손쉽게 배포할 수도 있습니다.

테스트를 완료했다면 docker stop <컨테이너 ID> 명령으로 실행 중인 컨테이너를 중지시킬 수 있습니다 (<컨테이너 ID>는 docker ps 명령으로 확인한 값).

마무리: Docker를 활용한 개발의 변화

Docker의 등장 이후 소프트웨어 개발 및 배포 방식에는 큰 변화가 생겼습니다. 과거에는 개발 환경과 서버 환경의 차이를 일일이 조율하고, 새로운 서버를 설정할 때마다 여러 설정을 반복해야 했습니다. Docker를 도입한 후에는 애플리케이션을 둘러싼 환경 전체를 이미지로 만들어 공유함으로써 이러한 과정을 자동화하고 일관성 있게 만들 수 있게 되었습니다. 덕분에 개발팀과 운영팀 사이의 협업이 수월해졌고, **인프라를 코드로 관리(Infrastructure as Code)**하는 흐름의 핵심 도구로 컨테이너 기술이 자리잡았습니다.

특히 마이크로서비스의 확산과 함께 Docker 컨테이너는 필수적인 도구가 되었습니다. 수십 개 이상의 서비스로 구성된 대규모 시스템에서도 각 서비스를 컨테이너로 배포함으로써, 새로운 기능을 배포하거나 문제가 있는 서비스를 롤백하는 작업이 과거보다 훨씬 빠르고 안전해졌습니다. 이는 기업들이 시장 변화에 더욱 민첩하게 대응할 수 있게 해주었으며, 자동 확장이나 셀프 힐링(장애 자동 복구)과 같은 클라우드 네이티브 패턴을 구현하는 데에도 Docker가 핵심적인 역할을 했습니다. Docker 컨테이너를 활용한 Immutable Infrastructure 개념은 배포 후 컨테이너의 상태를 변경하지 않고 새 버전을 배포하는 전략을 가능케하여, 장애 발생 시 신속히 이전 상태로 복구하는 것을 쉽게 만들었습니다.

요약하자면, Docker는 개발자가 "개발 환경 구축"에 들이는 시간을 획기적으로 줄였을 뿐 아니라, 애플리케이션을 배포하고 운영하는 방식을 표준화함으로써 오늘날 클라우드 시대의 DevOps 문화에 없어서는 안 될 요소가 되었습니다. 2013년 첫 공개 이후 불과 10여 년 만에 Docker는 전 세계 수많은 개발자와 기업이 사용하는 핵심 기술로 자리매김했으며, 컨테이너 기반의 클라우드 네이티브 개발 패러다임은 앞으로도 계속 확장될 것으로 기대됩니다.