컨테이너화된 애플리케이션 배포 가이드 – Docker, Kubernetes, CI/CD 완전 정복

on
컨테이너화된 애플리케이션 배포 가이드 – Docker, Kubernetes, CI/CD 완전 정복


1. 서론 – 소프트웨어 배포의 패러다임을 바꾼 기술, 컨테이너

디지털 환경은 매일같이 진화하고 있습니다. 특히 소프트웨어 개발과 배포의 방식은 지난 수년간 급격한 변화를 겪어왔습니다. 예전에는 하나의 서버에 직접 소프트웨어를 설치하고, 수작업으로 환경을 구성하는 일이 다반사였습니다. 그러나 이러한 방식은 확장성과 유연성, 일관성 면에서 많은 한계를 노출시켰습니다.

이러한 문제를 근본적으로 해결하기 위해 등장한 개념이 바로 컨테이너(Container)입니다. 컨테이너 기술은 소프트웨어의 실행 환경을 표준화함으로써, 어디에서 실행하더라도 같은 결과를 보장할 수 있도록 합니다. 그 중심에는 Docker라는 혁신적인 도구가 있습니다. Docker는 애플리케이션과 그 종속성을 하나의 이미지로 패키징하여 배포와 실행을 매우 간편하게 만들어 줍니다.

이 글에서는 컨테이너 기술의 핵심 개념부터 시작하여, 컨테이너화된 애플리케이션의 실제 배포 과정까지 단계별로 상세히 살펴볼 것입니다. 또한 Docker Compose, Kubernetes, 그리고 CI/CD 파이프라인과의 연계까지 포괄적으로 다루며, 실무에서 컨테이너 기반 배포를 적용할 수 있도록 돕는 실질적인 인사이트를 제공할 예정입니다.

지금 우리가 목격하고 있는 이 변화는 단순한 기술적 진보가 아닙니다. 이것은 소프트웨어 배포 방식의 패러다임 전환이며, 그 중심에 있는 컨테이너화는 개발자와 운영자 모두에게 새로운 기회를 열어주고 있습니다. 이제, 그 구체적인 여정을 함께 시작해보겠습니다.


2. 컨테이너란 무엇인가? – VM과의 비교를 중심으로

컨테이너(Container)란, 애플리케이션이 실행되는 환경을 격리된 단위로 패키징한 가벼운 가상화 기술입니다. 이는 기존의 가상머신(Virtual Machine, VM)과는 근본적으로 다른 방식으로 동작하며, 효율성과 민첩성 측면에서 큰 장점을 제공합니다.

전통적인 가상머신은 하이퍼바이저(Hypervisor) 위에 각기 다른 운영체제를 포함한 독립적인 OS 인스턴스를 실행합니다. 이에 따라 높은 자원 소모와 느린 기동 시간, 복잡한 시스템 구성이 뒤따릅니다. 반면, 컨테이너는 호스트 운영체제를 공유하면서 사용자 공간에서 격리된 환경을 실행하므로 훨씬 더 가볍고 빠르게 동작합니다.

아래는 VM과 컨테이너의 구조적 차이를 간단히 도식화한 예입니다. 

[ VM 구조 ]
-----------------------
| Guest OS (OS1)      |
| Guest OS (OS2)      |
| Guest OS (OS3)      |
| Hypervisor          |
| Host OS             |
| Server Hardware     |
-----------------------

[ Container 구조 ]
-----------------------
| App1 | App2 | App3   |
| Docker Engine        |
| Host OS              |
| Server Hardware      |
-----------------------

이러한 구조상의 차이로 인해 컨테이너는 다음과 같은 장점을 지닙니다.

  • 경량화: 별도의 OS를 포함하지 않으므로 용량이 작고 실행 속도가 빠릅니다.
  • 이식성: 동일한 이미지를 어떤 환경에서든 실행할 수 있어 DevOps 환경에 최적화되어 있습니다.
  • 신속한 배포: 컨테이너 이미지를 기반으로 수초 만에 실행 가능합니다.
  • 격리성: 각각의 컨테이너는 서로 영향을 주지 않으며 독립적으로 실행됩니다.

따라서 컨테이너는 마이크로서비스 아키텍처, CI/CD 파이프라인, 멀티 클라우드 환경 등 현대적인 소프트웨어 개발과 운영 방식에 이상적인 솔루션으로 자리잡고 있습니다. 이러한 특성 덕분에 개발팀과 운영팀은 빠르게 변화하는 요구사항에 민첩하게 대응할 수 있게 되었습니다.


3. Docker의 등장과 주요 개념 소개

Docker는 2013년, 당시 스타트업이었던 dotCloud가 오픈소스로 공개하면서 시작되었습니다. 이후 폭발적인 반응을 얻으며, 컨테이너 기반 애플리케이션 실행 방식의 사실상 표준으로 자리매김하게 됩니다. Docker는 리눅스 커널의 cgroups와 namespaces 기능을 활용하여 프로세스 수준의 가벼운 격리 환경을 제공합니다.

Docker의 가장 큰 기여는 컨테이너 기술을 추상화하여 누구나 쉽게 사용할 수 있도록 만들었다는 점입니다. 복잡했던 리눅스 컨테이너 환경을 단일 명령어와 선언적 구성으로 조작할 수 있도록 하면서, 개발자와 운영자 모두에게 폭넓은 수용성을 얻게 되었습니다.

Docker 생태계는 여러 구성 요소로 이루어져 있으며, 각각이 중요한 역할을 담당합니다.

  • Docker 이미지(Docker Image): 컨테이너를 생성하기 위한 실행 가능한 패키지로, 애플리케이션 코드, 런타임, 라이브러리, 설정 등을 포함합니다.
  • Docker 컨테이너(Docker Container): 이미지를 기반으로 생성된 격리된 실행 환경입니다. 이미지의 인스턴스라 할 수 있습니다.
  • Dockerfile: 이미지 생성을 위한 스크립트 파일로, 실행 환경을 정의하고 패키지를 설치하는 등 일련의 명령어를 기술합니다.
  • Docker CLI & Daemon: 명령어를 통해 컨테이너를 제어하고 관리하는 도구이며, 백그라운드에서 동작하는 Docker 데몬이 이를 실행합니다.
  • Docker Hub: 이미지 저장소로, 공개 이미지 및 개인용 이미지를 업로드하고 공유할 수 있는 플랫폼입니다.

아래는 간단한 Dockerfile 예제입니다. 

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]

위 예제는 Node.js 애플리케이션을 위한 Docker 이미지 정의입니다. 필요한 파일을 복사하고, 의존성을 설치하며, 3000번 포트를 열고, 앱을 실행하는 일련의 과정을 간결하게 표현합니다.

이처럼 Docker는 단순히 컨테이너를 실행하는 도구가 아니라, 현대적 소프트웨어 배포 체계의 핵심 플랫폼이라 할 수 있습니다. 다음 단계에서는 이러한 Docker를 활용하여 실제로 애플리케이션을 컨테이너화하는 전 과정을 다뤄보겠습니다.


4. 컨테이너화된 애플리케이션이란?

컨테이너화된 애플리케이션(Containerized Application)은 애플리케이션이 실행되기 위한 모든 요소를 하나의 독립된 단위로 패키징한 형태를 말합니다. 여기에는 애플리케이션 코드뿐만 아니라, 종속된 라이브러리, 설정 파일, 시스템 도구, 런타임 환경 등이 모두 포함됩니다. 결과적으로, 개발자가 만든 환경 그대로 운영 환경에서 실행될 수 있습니다.

과거에는 개발 환경과 운영 환경 사이의 미묘한 차이로 인해 '로컬에서는 잘 되는데 서버에서는 안 됩니다'라는 문제가 자주 발생하곤 했습니다. 그러나 컨테이너화는 이러한 문제를 원천적으로 해결합니다. 환경 간의 일관성을 보장하며, 어디서나 동일한 방식으로 실행할 수 있도록 합니다.

컨테이너화의 핵심 이점은 다음과 같습니다.

  • 이식성(Portability): 동일한 컨테이너 이미지를 로컬, 테스트, 스테이징, 프로덕션 환경 등 어디서나 실행할 수 있습니다.
  • 확장성(Scalability): 동일한 이미지를 기반으로 여러 개의 컨테이너 인스턴스를 빠르게 복제할 수 있어, 부하 분산 및 확장이 용이합니다.
  • 일관성(Consistency): 개발자, QA, 운영팀 모두가 동일한 환경에서 작업하므로 협업이 수월해집니다.
  • 배포 자동화에 적합: CI/CD와의 통합이 쉬워 자동화된 빌드, 테스트, 배포 프로세스 구현이 가능합니다.

예를 들어, 간단한 웹 애플리케이션을 컨테이너화한다면 다음과 같은 구성이 될 수 있습니다. 

애플리케이션 컨테이너:
  - 웹 서버 (예: Nginx, Express)
  - 애플리케이션 코드
  - 종속된 Node.js 패키지들

데이터베이스 컨테이너:
  - MySQL or PostgreSQL
  - 초기화 스크립트
  - 설정 파일

이렇게 각 서비스(웹 서버, 데이터베이스 등)를 분리하여 독립적인 컨테이너로 구성하면, 유지보수와 배포가 훨씬 유연해집니다. 하나의 서비스에 문제가 발생해도 전체 애플리케이션에 영향을 주지 않으며, 특정 서비스만 재시작하거나 교체하는 것이 가능해집니다.

즉, 컨테이너화된 애플리케이션은 단순히 "패키징"을 넘어서 현대적인 소프트웨어 아키텍처의 기반이라 할 수 있습니다. 다음 단계에서는 실제로 이러한 애플리케이션을 Docker를 이용해 컨테이너화하는 과정을 단계별로 알아보겠습니다.


5. Docker로 애플리케이션을 컨테이너화하는 과정

컨테이너화된 애플리케이션을 만들기 위한 첫 번째 단계는, 애플리케이션 실행에 필요한 모든 구성 요소를 하나의 Docker 이미지로 패키징하는 것입니다. 이 과정은 일반적으로 다음과 같은 순서로 진행됩니다.

  1. Dockerfile 작성
  2. Docker 이미지 빌드
  3. 컨테이너 실행
  4. 포트 및 볼륨 설정

1. Dockerfile 작성

Dockerfile은 이미지 생성을 위한 스크립트 정의서입니다. 애플리케이션의 실행 환경, 의존성 설치, 실행 명령 등을 명시합니다. 아래는 간단한 Node.js 애플리케이션을 위한 예시입니다. 

# 베이스 이미지 지정
FROM node:18

# 작업 디렉토리 설정
WORKDIR /app

# 의존성 설치를 위한 파일 복사
COPY package*.json ./

# 의존성 설치
RUN npm install

# 애플리케이션 소스 복사
COPY . .

# 포트 노출
EXPOSE 3000

# 실행 명령어
CMD ["npm", "start"]

2. Docker 이미지 빌드

Dockerfile을 작성한 디렉토리에서 다음 명령어를 실행하여 이미지를 생성할 수 있습니다. 여기서 myapp은 이미지의 이름입니다. 

docker build -t myapp .

이 명령어는 현재 디렉토리(.)에 있는 Dockerfile을 기반으로 이미지를 빌드하고, 그 결과를 myapp이라는 이름으로 태깅합니다.

3. 컨테이너 실행

이제 생성된 이미지를 기반으로 컨테이너를 실행할 수 있습니다. 

docker run -d -p 3000:3000 --name my-running-app myapp
  • -d: 백그라운드 모드로 실행
  • -p 3000:3000: 호스트의 3000번 포트를 컨테이너의 3000번 포트에 매핑
  • --name: 컨테이너에 이름 부여

4. 포트 및 볼륨 설정

애플리케이션에 따라 데이터 영속성을 유지하거나 외부 접속을 허용해야 할 수 있습니다. 이때 볼륨 마운트와 포트 매핑이 중요합니다. 

docker run -d \
 -p 8080:80 \
 -v /host/data:/app/data \
 --name webapp \
 webapp-image

위 명령어는 호스트의 /host/data 디렉토리를 컨테이너 내부의 /app/data로 마운트하고, 외부에서 8080 포트로 접근할 수 있도록 구성합니다.

이처럼 Docker를 이용한 애플리케이션의 컨테이너화는 단순한 이미지 생성 그 이상입니다. 개발, 테스트, 운영 전반에 걸쳐 환경의 일관성과 자동화 가능성을 보장하며, 이는 DevOps 문화와도 깊이 연결됩니다.

다음 단락에서는 이렇게 만들어진 이미지를 다양한 환경에 배포하기 위한 준비 과정, 즉 컨테이너 이미지의 관리와 저장 방식에 대해 살펴보겠습니다.


6. 컨테이너 이미지의 빌드와 관리

컨테이너 이미지(Docker Image)는 컨테이너의 기반이 되는 중요한 요소입니다. 애플리케이션의 상태를 스냅샷처럼 저장하고 재현할 수 있는 이 이미지는, 소프트웨어의 배포 및 실행을 위한 핵심 자산으로 간주됩니다. 따라서 단순히 이미지를 생성하는 데서 그치지 않고, 효율적이고 체계적인 관리가 매우 중요합니다.

1. 이미지 태그(Tag)를 활용한 버전 관리

Docker 이미지에는 태그(tag)를 지정할 수 있으며, 이를 통해 버전별로 이미지를 구분하고 추적할 수 있습니다. 기본값은 latest이지만, 실제 운영 환경에서는 다음과 같은 방식의 버전 태깅을 사용하는 것이 일반적입니다. 

docker build -t myapp:1.0.0 .
docker build -t myapp:2025-03-23 .
docker build -t registry.example.com/myapp:stable .
  • 세부 버전 명시: 1.0.0, 2.1.3 등
  • 배포일 기반 태그: 2025-03-23
  • 배포 채널 구분: dev, staging, production

버전 태그를 명확하게 관리하면, 롤백이나 히스토리 추적이 용이하고 CI/CD 파이프라인에서도 안정적인 배포가 가능합니다.

2. 이미지 최적화와 경량화 전략

운영 환경에서 이미지는 작고 빠를수록 유리합니다. 불필요한 용량과 종속성을 제거하고, 경량화된 베이스 이미지를 사용하는 것이 중요합니다. 대표적인 최적화 전략은 다음과 같습니다.

  • 경량 베이스 이미지 사용: alpine, distroless 기반 이미지 사용
  • 멀티 스테이지 빌드: 빌드 환경과 실행 환경을 분리하여 최종 이미지를 최소화
  • .dockerignore 파일 설정: 빌드에 불필요한 파일 제외

다음은 멀티 스테이지 빌드의 간단한 예입니다. 

# 빌드 단계
FROM node:18 AS build
WORKDIR /app
COPY . .
RUN npm install && npm run build

# 배포 단계
FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

이 방식은 빌드에 필요한 도구를 최종 이미지에 포함하지 않으므로, 보안성과 크기 측면에서 매우 효율적입니다.

3. 이미지 정리와 보안

시간이 지남에 따라 이미지가 불필요하게 많이 쌓일 수 있습니다. 이는 디스크 용량 낭비와 보안 위험으로 이어질 수 있으므로, 정기적으로 이미지와 중간 레이어를 정리해주는 것이 좋습니다. 

# 사용하지 않는 이미지 제거
docker image prune

# 전체 정리 (주의!)
docker system prune -a

또한, 취약점 스캐너(예: Trivy, Docker Scout)를 통해 이미지 내부의 보안 취약점을 점검하는 것도 매우 중요한 실무 습관입니다.

이제 컨테이너 이미지가 준비되었다면, 이를 실제 배포 환경으로 옮겨야 합니다. 다음 단계에서는 이미지 저장소인 컨테이너 레지스트리와 그 활용 방식에 대해 살펴보겠습니다.


7. 컨테이너 레지스트리와 이미지 배포 방식

컨테이너 이미지를 단순히 로컬에서 빌드하고 실행하는 것은 개발 초기 단계에 불과합니다. 실제 서비스를 운영하기 위해서는 여러 서버나 클라우드 환경에서 동일한 이미지를 가져와 실행해야 하며, 이를 위해 사용하는 것이 바로 컨테이너 레지스트리(Container Registry)입니다.

컨테이너 레지스트리는 이미지 저장소 역할을 하며, 개발자가 빌드한 이미지를 업로드(push)하고 필요 시 내려받아(pull) 실행할 수 있도록 해줍니다. 대표적인 레지스트리 유형은 다음과 같습니다.

1. 공개 컨테이너 레지스트리 (Public Registry)

  • Docker Hub: 가장 널리 사용되는 공식 공개 저장소이며, 수많은 오픈소스 이미지가 존재합니다.
  • GitHub Container Registry: GitHub와 통합되어 있으며, CI/CD 파이프라인과 유기적으로 연동됩니다.

Docker Hub를 통해 이미지를 업로드하는 예시는 다음과 같습니다. 

# 로그인
docker login

# 태그 지정
docker tag myapp username/myapp:1.0.0

# 이미지 업로드
docker push username/myapp:1.0.0

이후 다른 머신에서는 다음 명령어를 통해 이미지를 가져와 실행할 수 있습니다. 

docker pull username/myapp:1.0.0
docker run -d username/myapp:1.0.0

2. 프라이빗 컨테이너 레지스트리 (Private Registry)

보안이나 기업 내부 정책상, 공개 저장소 대신 프라이빗 레지스트리를 운영하는 경우도 많습니다. 대표적인 서비스로는 다음이 있습니다.

  • Harbor: CNCF 프로젝트로, 강력한 권한 관리와 감사 기능 제공
  • Amazon ECR (Elastic Container Registry): AWS와 통합된 고성능 레지스트리
  • Google Artifact Registry: GCP 환경에서 컨테이너 및 패키지를 저장 및 관리
  • Azure Container Registry: Azure와의 통합 및 RBAC 기능 제공

프라이빗 레지스트리 사용 시, 다음과 같은 절차로 인증 및 이미지를 업로드할 수 있습니다. 

# AWS ECR 예시
aws ecr get-login-password | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com

# 태그 지정
docker tag myapp 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/myapp:1.0.0

# 이미지 푸시
docker push 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/myapp:1.0.0

3. 레지스트리 보안과 접근 제어

프라이빗 레지스트리를 사용할 때는 이미지 접근 권한, 인증 방식, HTTPS 전송 여부 등을 반드시 점검해야 합니다. 접근 제어가 제대로 설정되지 않으면, 민감한 내부 애플리케이션 코드가 외부에 노출될 위험이 있습니다.

또한, 이미지 서명 및 취약점 스캐닝 기능이 내장된 플랫폼을 사용하면 보안 수준을 더욱 높일 수 있습니다. 대표적으로 Docker Content Trust나 Notary와 같은 기능이 이를 지원합니다.

컨테이너 레지스트리는 단순한 저장소가 아니라, 배포 파이프라인의 핵심 노드이자 협업을 위한 플랫폼입니다. 효율적인 이미지 관리와 보안을 위해, 레지스트리 선택과 구성은 프로젝트 초기부터 전략적으로 접근해야 합니다.

이제 다음 단계에서는 이렇게 저장된 이미지를 실제로 다양한 환경에서 배포하는 과정을 살펴보겠습니다. 로컬 서버, 온프레미스, 퍼블릭 클라우드 등 각 환경에서의 배포 차이를 이해하는 것이 중요합니다.


8. 실제 배포: 로컬, 온프레미스, 클라우드 환경에서의 차이

컨테이너 이미지를 생성하고 레지스트리에 등록한 후에는 실제 운영 환경에 배포하는 단계로 이어집니다. 하지만 배포 대상이 어디인가에 따라 방식과 설정, 주의사항이 크게 달라질 수 있습니다. 여기서는 세 가지 주요 환경 — 로컬(Local), 온프레미스(On-premise), 클라우드(Cloud) — 를 중심으로 배포 방식의 차이점을 살펴보겠습니다.

1. 로컬 환경(Local Environment)

로컬 배포는 개발 및 테스트 단계에서 가장 많이 사용되며, Docker Desktop 또는 CLI 도구를 활용하여 실행됩니다. 단일 머신 환경이므로 설정이 단순하며, 빠른 반복 테스트가 가능합니다. 

docker run -d -p 8080:80 --name local-app myapp:1.0.0

로컬에서는 파일 시스템, 포트 충돌, 리소스 제한 등에 유의해야 하며, CI/CD 테스트 자동화 전 단계로 활용하기 적합합니다.

2. 온프레미스 환경(On-premise Environment)

온프레미스 환경은 기업 내부에 물리적으로 존재하는 서버에 Docker를 설치하고 컨테이너를 배포하는 방식입니다. 보안과 데이터 주권이 중요한 경우 자주 선택되며, 다음과 같은 특징을 가집니다.

  • 네트워크 및 방화벽 제어: 외부 접근을 차단하거나 제한 가능
  • 자체 인증 체계: LDAP, 사내 VPN 등과 연동
  • 프라이빗 레지스트리 운영: 내부 전용 이미지 저장소 구축

배포는 일반적으로 SSH나 자동화 스크립트, Ansible, Jenkins 등으로 구성됩니다. 다음은 간단한 예시입니다. 

ssh user@internal-server "docker pull registry.company.com/myapp:1.0.0 && docker run -d myapp:1.0.0"

운영과 보안 통제가 쉬운 반면, 확장성과 인프라 관리의 복잡도가 높습니다.

3. 클라우드 환경(Cloud Environment)

클라우드는 컨테이너 기반 배포에 가장 널리 사용되는 환경입니다. AWS, GCP, Azure와 같은 플랫폼은 컨테이너를 위한 다양한 서비스를 제공합니다. 대표적으로는 다음과 같습니다.

  • AWS: Amazon ECS, EKS, Fargate
  • GCP: Google Kubernetes Engine (GKE), Cloud Run
  • Azure: Azure Kubernetes Service (AKS), Azure Container Instances

가장 간단한 배포 예로는 Google Cloud Run을 들 수 있습니다. 이미지가 Container Registry(GCR)에 업로드되어 있으면, 몇 번의 클릭만으로 서비스화가 가능합니다. 

gcloud run deploy myapp \
  --image gcr.io/my-project/myapp:1.0.0 \
  --platform managed \
  --region asia-northeast3 \
  --allow-unauthenticated

클라우드 배포의 장점은 다음과 같습니다.

  • 자동 확장: 사용량에 따라 인스턴스 수를 자동 조정
  • 무중단 배포 지원: Rolling 업데이트, Traffic Splitting
  • 인프라 관리 부담 감소: 서버리스 환경에서 완전 자동화 가능

하지만, 클라우드 환경에서는 비용 관리, 벤더 종속성(lock-in), 보안 정책에 대한 고려가 필요합니다.

결론적으로, 어떤 환경에 배포하느냐에 따라 컨테이너 관리 방식과 아키텍처는 큰 차이를 보입니다. 요구사항에 따라 적절한 환경을 선택하고, 이에 맞는 배포 전략을 수립하는 것이 중요합니다.

다음 단락에서는 여러 개의 컨테이너를 동시에 실행하고 관리하는 방법인 Docker Compose를 소개합니다. 마이크로서비스 환경이나 복잡한 로컬 개발 환경에서 필수적인 도구입니다.


9. Docker Compose를 이용한 멀티 컨테이너 배포

현대 애플리케이션은 하나의 실행 단위로 구성되지 않고, 여러 서비스(예: 웹 서버, 데이터베이스, 캐시, 메시지 큐 등)가 유기적으로 연결되어 동작합니다. 이러한 환경에서는 여러 개의 컨테이너를 함께 실행하고 관리하는 기능이 필수적이며, 이를 가능하게 해주는 도구가 바로 Docker Compose입니다.

Docker Compose는 docker-compose.yml이라는 구성 파일을 통해 여러 컨테이너를 정의하고, 하나의 명령어로 동시에 실행하거나 중지할 수 있도록 해줍니다. 이를 통해 복잡한 서비스 구성을 쉽게 재현하고 관리할 수 있습니다.

1. 기본 구조

Compose 파일은 YAML 포맷으로 작성되며, 서비스 간의 관계, 네트워크, 볼륨, 환경 변수 등을 설정할 수 있습니다. 

version: '3.8'

services:
  web:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db

  db:
    image: postgres:14
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: myapp

이 예제에서는 Node.js 기반 웹 서버와 PostgreSQL 데이터베이스를 동시에 실행합니다. depends_on 설정은 웹 서비스가 DB에 의존하고 있다는 관계를 명시해줍니다.

2. 실행 및 관리

Docker Compose의 명령어는 매우 직관적이며, 다음과 같은 방식으로 서비스를 관리할 수 있습니다. 

# 모든 서비스 빌드 및 실행
docker compose up -d

# 상태 확인
docker compose ps

# 로그 확인
docker compose logs -f

# 서비스 중지
docker compose down

up 명령어는 모든 정의된 컨테이너를 실행하며, down은 관련 네트워크, 볼륨까지 함께 정리해줍니다. 개발 중에는 logs -f를 통해 실시간 로그를 모니터링할 수 있습니다.

3. 환경 변수 및 볼륨 활용

환경에 따라 설정을 유연하게 바꾸기 위해 .env 파일을 함께 사용할 수 있으며, 서비스 간 공유해야 하는 데이터는 볼륨을 통해 관리할 수 있습니다. 

volumes:
  db_data:

services:
  db:
    image: postgres
    volumes:
      - db_data:/var/lib/postgresql/data

이처럼 Docker Compose는 복잡한 멀티 컨테이너 환경을 코드화하고, 손쉽게 구성할 수 있도록 도와주는 강력한 도구입니다. 개발 환경은 물론 CI/CD 테스트 환경, 단일 서버 기반의 소규모 운영 환경에도 매우 적합합니다.

다음 단계에서는 더욱 복잡한 규모의 컨테이너 오케스트레이션을 위한 도구, Kubernetes의 개념과 필요성에 대해 살펴보겠습니다. 대규모 시스템 운영에서는 Compose를 넘어서는 체계적인 관리가 필요합니다.


10. 오케스트레이션 개념과 Kubernetes의 필요성

컨테이너 기반의 애플리케이션은 빠르고 유연한 배포를 가능하게 하지만, 서비스 규모가 커질수록 관리해야 할 컨테이너의 수, 구성, 네트워크, 보안, 로드 밸런싱 등의 복잡도가 기하급수적으로 증가합니다. 이때 필요한 것이 바로 컨테이너 오케스트레이션(Container Orchestration)입니다.

오케스트레이션이란, 여러 개의 컨테이너를 자동으로 배치, 실행, 복구, 확장, 모니터링할 수 있도록 제어하는 것을 의미합니다. 즉, 단순한 실행 도구가 아니라 전체 시스템의 상태를 인지하고 조율하는 자동화된 운영 관리자라고 할 수 있습니다.

1. 오케스트레이션이 필요한 이유

  • 자동 배치: 클러스터 내 리소스를 고려하여 컨테이너를 적절한 노드에 할당
  • 셀프 힐링(Self-healing): 문제가 생긴 컨테이너를 자동으로 재시작
  • 자동 확장 및 축소: 부하에 따라 컨테이너 수를 자동 조정
  • 서비스 디스커버리: 컨테이너 간 네트워크 연결과 DNS 설정 자동화
  • 롤링 업데이트: 중단 없이 애플리케이션을 점진적으로 업데이트

Docker Compose는 개발 환경에서 훌륭하지만, 운영 단계에서의 가용성, 복구, 확장성까지 고려하기에는 한계가 있습니다. 이러한 요구를 충족시키기 위해 구글이 내부 인프라에서 사용하던 기술을 오픈소스로 공개한 것이 바로 Kubernetes (쿠버네티스)입니다.

2. Kubernetes란 무엇인가?

Kubernetes는 컨테이너화된 애플리케이션을 배포, 스케일링, 관리하는 오픈소스 플랫폼입니다. 흔히 K8s라고도 불리며, 클러스터 구조를 기반으로 다수의 노드에서 컨테이너를 분산 실행하고 중앙에서 제어할 수 있도록 지원합니다.

Kubernetes의 핵심 구성 요소는 다음과 같습니다.

  • Pod: 하나 이상의 컨테이너로 구성된 최소 배포 단위
  • Deployment: Pod의 생성, 업데이트, 복제 전략을 정의
  • Service: 외부 접근과 로드밸런싱을 위한 네트워크 설정
  • Node: 컨테이너를 실행하는 물리 또는 가상 머신
  • Cluster: 모든 노드와 컨트롤 플레인을 포함하는 집합

예를 들어, 아래는 간단한 Nginx 서비스를 Kubernetes에 배포하는 Deployment 예시입니다. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23
        ports:
        - containerPort: 80

이 설정은 동일한 Nginx 컨테이너를 3개의 Pod로 실행하고, 장애가 발생하면 자동으로 복구하며, 추후 롤링 업데이트도 지원하게 됩니다.

3. Kubernetes의 활용 사례

  • 대규모 트래픽 대응이 필요한 웹 서비스
  • 마이크로서비스 기반의 애플리케이션
  • 멀티 클라우드 및 하이브리드 클라우드 환경
  • AI/ML, 빅데이터 워크로드 처리 환경

Kubernetes는 현재 클라우드 네이티브 생태계의 중심이며, AWS(EKS), GCP(GKE), Azure(AKS) 등 주요 클라우드 제공업체들이 완전 관리형 서비스를 통해 지원하고 있습니다.

이처럼 Kubernetes는 컨테이너 인프라의 안정성과 유연성을 극대화하기 위한 사실상의 표준으로 자리잡고 있으며, 그 복잡성에도 불구하고 현대 소프트웨어 운영에 필수적인 도구로 간주됩니다.

다음 단락에서는 Kubernetes와 같은 오케스트레이터 위에서 컨테이너를 운영할 때 반드시 고려해야 할 보안 및 네트워크 설계의 핵심 원칙을 살펴보겠습니다.


11. 보안과 네트워크: 컨테이너 배포 시 고려사항

컨테이너 기반 아키텍처는 유연하고 확장성이 뛰어나지만, 그만큼 새로운 보안 위협과 네트워크 설계의 복잡성도 수반합니다. 특히 마이크로서비스처럼 수많은 컨테이너가 유기적으로 통신하는 구조에서는 보안 격리와 통제, 정교한 네트워크 정책이 무엇보다 중요합니다.

1. 이미지 보안 및 취약점 관리

컨테이너 보안의 출발점은 신뢰할 수 있는 이미지를 사용하는 것입니다. 불필요한 패키지나 루트 권한 실행이 포함된 이미지, 오래된 취약한 의존성은 가장 큰 위협 요소입니다. 다음은 기본적인 보안 전략입니다.

  • 공식 또는 내부 검증 이미지만 사용
  • 최신 보안 패치가 적용된 경량 베이스 이미지 사용 (예: distroless, alpine)
  • Trivy, Clair, Grype 등의 도구로 이미지 취약점 스캔
  • Dockerfile 내에서 루트 사용자 사용 지양
# Trivy를 활용한 보안 스캔 예시
trivy image myapp:1.0.0

2. 런타임 보안 설정

컨테이너 실행 시에도 다양한 보안 제어가 가능합니다. Docker 및 Kubernetes에서는 다음과 같은 옵션을 통해 보안을 강화할 수 있습니다.

  • Read-only Filesystem: 컨테이너 파일 시스템을 읽기 전용으로 설정
  • Capability Drop: 불필요한 Linux Capabilities 제거
  • Seccomp, AppArmor, SELinux: 시스템 호출 필터링 및 접근 제어
  • Run as non-root: 루트가 아닌 사용자로 컨테이너 실행
securityContext:
  runAsUser: 1000
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

3. 네트워크 정책과 통신 격리

기본적으로 Kubernetes 클러스터 내 모든 Pod는 서로 자유롭게 통신할 수 있습니다. 이는 개발 초기에는 편리하지만, 보안 측면에서는 심각한 리스크입니다. 네트워크 정책(NetworkPolicy)을 통해 통신을 제어하고, 서비스 간 최소 권한 원칙을 적용해야 합니다. 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web

이 설정은 web이라는 라벨을 가진 Pod에서만 api Pod로의 접속을 허용합니다. 외부 노출 포트는 필요한 경우에만 열고, 인증/인가 체계를 적용하는 것이 중요합니다.

4. 비밀 정보(Secrets) 및 환경 변수 관리

DB 비밀번호, API 키 등 민감한 정보는 이미지 내부에 절대 포함해서는 안 됩니다. Kubernetes에서는 Secret 리소스를 사용하거나, HashiCorp Vault, AWS Secrets Manager 등의 외부 솔루션을 활용할 수 있습니다. 

# Kubernetes Secret 생성
kubectl create secret generic db-secret \
  --from-literal=DB_USER=admin \
  --from-literal=DB_PASS=securepassword

컨테이너는 가볍고 빠르지만, 오히려 그 특성 때문에 일시적이고 비영속적인 환경에 대한 고려가 필수적입니다. 설정 파일, 로그, 상태 정보 등을 안전하게 외부화하고, 보안 정책을 코드 수준에서 통제하는 것이 현대 DevSecOps의 핵심이라 할 수 있습니다.

이제 보안과 네트워크 측면의 기반을 다졌다면, 실제로 어떻게 애플리케이션을 안전하고 효율적으로 업데이트 및 배포할 수 있는지 살펴보겠습니다. 다음 단락에서는 다양한 배포 전략을 소개합니다.


12. 실무에서 자주 활용되는 배포 전략 (Blue-Green, Rolling 등)

컨테이너화된 애플리케이션의 배포는 단순히 “실행”하는 것을 넘어서, 사용자 경험을 해치지 않고, 신뢰성 있게 변경 사항을 적용하는 것이 핵심입니다. 이를 위해 실무에서는 다양한 배포 전략을 활용합니다. 이 단락에서는 Blue-Green Deployment, Rolling Update, Canary Deployment와 같은 주요 배포 기법을 소개하고, 각 전략의 장단점과 사용 사례를 비교합니다.

1. Blue-Green Deployment (청록 배포)

Blue-Green 배포는 두 개의 동일한 프로덕션 환경(Blue와 Green)을 유지하면서, 하나는 현재 서비스를 제공하고 다른 하나는 업데이트된 버전을 테스트한 후 전환하는 방식입니다.

  • Blue: 현재 서비스 중인 애플리케이션
  • Green: 새로운 버전이 배포되는 대기 상태의 환경

전환은 단순히 로드 밸런서의 트래픽만 변경하면 되기 때문에 무중단 배포가 가능하며, 문제가 발생했을 때 빠르게 Blue로 롤백할 수 있습니다. 

# 예시: Nginx 로드 밸런서 설정 변경으로 트래픽 전환
ln -sf /etc/nginx/sites-available/green /etc/nginx/sites-enabled/default
nginx -s reload

장점: 배포 중단 없음, 빠른 롤백 단점: 두 환경을 동시에 유지해야 하므로 리소스 비용 증가

2. Rolling Update (점진적 업데이트)

Rolling Update는 전체 인스턴스를 한 번에 교체하지 않고, 순차적으로 기존 인스턴스를 새 버전으로 대체하는 전략입니다. Kubernetes의 기본 업데이트 방식이기도 합니다.

Kubernetes에서는 Deployment 리소스 내에서 maxUnavailable과 maxSurge 설정을 통해 업데이트의 폭과 속도를 제어할 수 있습니다. 

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 2

이 설정은 기존 파드 중 하나만 동시에 내려가고, 두 개의 신규 파드를 추가적으로 생성하여 점진적으로 전환이 이루어지게 합니다.

장점: 트래픽 유지, 리소스 최적화 단점: 중간 상태의 혼재 가능성, 롤백에 시간 소요

3. Canary Deployment (카나리아 배포)

Canary 배포는 새로운 버전의 애플리케이션을 일정 비율의 트래픽에만 노출시킨 후, 이상이 없으면 점진적으로 전체 배포를 진행하는 방식입니다. 실제 사용자 환경에서 새로운 기능을 소규모로 실험할 수 있어, A/B 테스트나 기능 플래그와 함께 자주 사용됩니다. 

# Istio VirtualService 예시
spec:
  http:
    - route:
        - destination:
            host: myapp
            subset: stable
          weight: 90
        - destination:
            host: myapp
            subset: canary
          weight: 10

이 설정은 전체 트래픽 중 10%만 canary 버전으로 전환하고, 나머지 90%는 기존 stable 버전으로 유지합니다. 테스트 후 이상이 없으면 100%로 확장합니다.

장점: 리스크 최소화, 실제 사용자 반응 분석 가능 단점: 라우팅 설정이 복잡하며, 외부 서비스 연동이 필요할 수 있음

4. 선택 기준

배포 전략은 프로젝트의 특성과 팀의 운영 성숙도에 따라 달라질 수 있습니다. 다음은 전략 선택을 위한 간단한 가이드입니다.

전략 무중단 롤백 용이성 복잡도 권장 상황
Blue-Green ✓ 매우 쉬움 중간 보수적 배포, 긴급 롤백 필요 시
Rolling ✓ 중간 낮음 Kubernetes 기본 전략, 자동화 환경
Canary ✓ 높음 높음 기능 실험, 대규모 트래픽 환경

이처럼 컨테이너화된 애플리케이션의 배포는 단순한 기술 실행이 아니라, 사용자 경험과 안정성을 유지하기 위한 전략적 결정입니다. 각 전략의 특징을 파악하고, 상황에 따라 유연하게 조합하는 것이 실무에서의 핵심입니다.

이제 배포 전략까지 이해했다면, 이를 자동화하는 과정이 필요합니다. 다음 단락에서는 CI/CD 파이프라인과의 통합을 통해 컨테이너 배포를 어떻게 자동화하고 최적화할 수 있는지 살펴보겠습니다.


13. CI/CD 파이프라인과의 통합

컨테이너의 진정한 가치는 자동화된 배포와 운영에 있습니다. 아무리 이미지가 잘 만들어졌다고 해도, 수동으로 매번 빌드하고 테스트하고 배포한다면 시간과 인력이 낭비될 뿐 아니라, 일관성과 안정성도 확보하기 어렵습니다. 이를 해결하기 위한 DevOps 핵심 개념이 바로 CI/CD (Continuous Integration / Continuous Delivery)입니다.

1. CI/CD란 무엇인가?

CI (지속적 통합)는 개발자가 코드 변경을 리포지토리에 병합할 때마다 자동으로 테스트 및 빌드를 수행하여 문제를 조기에 발견하는 프로세스입니다. CD (지속적 배포 또는 전달)는 이러한 변경 사항이 자동으로 운영 환경 또는 스테이징 환경에 안전하게 배포되도록 합니다.

컨테이너 기반 CI/CD 파이프라인의 일반적인 흐름은 다음과 같습니다.

  1. 코드 푸시 (GitHub, GitLab 등)
  2. 자동 테스트 및 정적 분석
  3. Docker 이미지 빌드
  4. 이미지 레지스트리에 Push
  5. 테스트 환경 또는 운영 환경에 자동 배포

2. 대표적인 CI/CD 도구

다양한 CI/CD 도구들이 있으며, 각각의 프로젝트 성격에 따라 적절한 플랫폼을 선택할 수 있습니다.

  • GitHub Actions: GitHub 기반 프로젝트에 이상적인 워크플로우 자동화 도구
  • GitLab CI/CD: GitLab 자체에 내장된 강력한 파이프라인 기능
  • Jenkins: 플러그인 기반의 유연한 오픈소스 자동화 서버
  • CircleCI, TravisCI, ArgoCD: 클라우드 기반 또는 쿠버네티스 연동 특화 도구

3. GitHub Actions 예제

아래는 GitHub Actions를 사용하여 코드를 푸시할 때마다 Docker 이미지를 빌드하고 Docker Hub에 업로드하는 기본 워크플로우 예시입니다. 

name: CI/CD Pipeline

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Log in to Docker Hub
      uses: docker/login-action@v2
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}

    - name: Build and push Docker image
      uses: docker/build-push-action@v4
      with:
        context: .
        push: true
        tags: username/myapp:latest

이 파이프라인은 코드 변경이 발생할 때 자동으로 이미지를 생성하고, Docker Hub에 업로드하는 작업을 수행합니다. 이 과정을 통해 개발자는 코드 품질과 배포 가능성을 항상 확보할 수 있습니다.

4. Kubernetes와의 통합

CD 단계에서 Kubernetes와 연동하면, 이미지가 배포되는 즉시 자동으로 업데이트를 적용할 수 있습니다. 다음과 같은 도구를 활용할 수 있습니다.

  • Kubectl: CI 파이프라인 내부에서 직접 명령어를 실행하여 배포
  • Helm: Kubernetes 애플리케이션을 패키징하고 배포하는 템플릿 기반 도구
  • Argo CD: GitOps 방식으로 Kubernetes에 선언적 배포
# Kubectl을 사용한 이미지 업데이트
kubectl set image deployment/myapp myapp=username/myapp:latest

CI/CD는 단순한 자동화 이상의 의미를 지닙니다. 컨테이너 환경에서의 지속적인 통합과 배포는 개발 속도와 운영 품질을 동시에 높이는 핵심 엔진이 됩니다. 이를 기반으로 실시간 대응이 가능하고, 점진적인 개선을 반복할 수 있는 진정한 DevOps 문화가 완성됩니다.

마지막으로, 지금까지 다뤄온 내용을 정리하며 컨테이너화된 애플리케이션 배포가 왜 현대 IT 환경에서 중요한지 결론을 내려보겠습니다.


14. 결론 – 컨테이너화는 미래가 아닌 현재다

소프트웨어의 배포와 운영은 더 이상 단순한 설치와 실행의 문제가 아닙니다. 속도, 안정성, 확장성, 그리고 유연성이 요구되는 오늘날의 IT 환경에서, 컨테이너 기술은 이러한 모든 조건을 만족시키는 실질적인 해법으로 자리 잡았습니다.

Docker를 활용한 애플리케이션 컨테이너화는 단순히 실행 환경을 패키징하는 것을 넘어, 개발-테스트-배포 전 과정을 자동화하고 일관되게 만들어줍니다. Docker Compose로 복잡한 환경을 로컬에서 손쉽게 재현할 수 있으며, Kubernetes는 대규모 분산 환경에서도 안정적인 운영을 가능케 합니다. 여기에 CI/CD 파이프라인을 결합하면, 컨테이너화는 그야말로 현대 소프트웨어 개발의 표준이 됩니다.

중요한 것은 기술 자체보다, 이를 통해 어떻게 더 나은 협업과 더 빠른 변화 대응이 가능한지를 이해하고 적용하는 것입니다. 컨테이너화는 단지 도구가 아니라, 소프트웨어 팀의 사고방식과 일하는 방식을 혁신하는 기반입니다.

이제 컨테이너는 더 이상 '다가올 미래'의 기술이 아닙니다. 이미 수많은 기업과 개발자가 이 기술 위에서 일하고 있으며, 그 흐름은 되돌릴 수 없을 만큼 커졌습니다. 컨테이너화는 선택이 아닌 필수입니다. 지금 이 순간이 바로, 그 여정을 시작하기에 가장 좋은 시점입니다.

Comments

Post a Comment