Docker부터 K8s까지: 백엔드 개발자가 알아야 할 컨테이너 배포 완벽 가이드

Docker부터 K8s까지: 백엔드 개발자가 알아야 할 컨테이너 배포 완벽 가이드

안녕하세요, 개발자 여러분. 백엔드 개발을 공부하다 보면 '내 컴퓨터에서는 잘 되는데, 서버에서는 왜 안 되지?'라는 벽에 부딪힐 때가 많습니다. 이 문제를 근본적으로 해결해 주는 것이 바로 컨테이너 기술입니다.

컨테이너는 애플리케이션과 그 실행에 필요한 모든 환경(라이브러리, 런타임 등)을 하나로 패키징하여, 어떤 환경에서든 동일하게 동작하도록 보장해 줍니다. 이 글에서는 이 컨테이너 기술의 핵심 단계들을, 마치 레고 블록을 쌓듯이 단계별로 설명해 드릴게요. 이론보다는 '이걸 왜 써야 하는가?'에 초점을 맞추겠습니다.

🧱 1단계: Dockerfile 작성법 기초 (컨테이너의 설계도)

Dockerfile은 여러분의 애플리케이션을 담을 컨테이너 이미지를 만들기 위한 '설계도'와 같습니다. 이 파일 하나만 잘 작성하면, 복잡한 환경 설정 과정 없이 일관된 이미지를 얻을 수 있습니다.

핵심 명령어 3가지

1. FROM (기반 이미지 지정):

   • 가장 먼저 무엇을 기반으로 할지 정합니다. 예를 들어, Python 웹 앱을 띄우려면 Python이 설치된 이미지를 가져와야겠죠.
   • 예시: FROM python:3.10-slim (Python 3.10 환경을 기반으로 시작하겠다.)

2. RUN (실행할 명령어):

   • 이미지 빌드 과정 중에 실행되어야 하는 명령어들입니다. 의존성 설치, 파일 다운로드 등이 여기에 해당합니다.
   • 예시: RUN pip install -r requirements.txt (의존성 라이브러리를 설치해라.)

3. CMD (기본 실행 명령어):

   • 컨테이너가 실제로 구동될 때 기본적으로 실행할 명령어를 지정합니다. 이 명령어가 컨테이너의 '심장 박동'과 같습니다.
   • 예시: CMD ["python app.py"] (컨테이너가 시작되면 이 파이썬 스크립트를 실행해라.)

💡 실습 팁: 간단한 Node.js 서버가 있다면, FROM node:18-alpine으로 시작하여, COPY package*.json ./ 후 RUN npm install을 거쳐, CMD ["node server.js"]로 마무리하는 구조를 연습해보세요.

🔗 2단계: Docker Compose (로컬 환경의 오케스트레이션)

여러분의 백엔드 서비스는 보통 단독으로 돌아가지 않습니다. 웹 서버(API)가 있고, 데이터베이스(DB)가 필요하죠. 이처럼 두 개 이상의 서비스가 서로 통신하며 돌아가는 환경을 로컬에서 쉽게 띄우고 테스트하고 싶을 때, docker-compose.yml 파일이 등장합니다.

Docker Compose는 여러 컨테이너들의 묶음(Service)을 정의하고, 이들이 어떻게 서로 연결되어야 하는지(네트워크 설정)를 YAML 파일 하나로 관리하게 해줍니다.

docker-compose.yml의 역할

• 서비스 정의: web: (내 웹 앱 서비스), db: (PostgreSQL 서비스)와 같이 각 컴포넌트를 정의합니다.
• 의존성 관리: depends_on을 사용하여 웹 앱이 DB가 완전히 준비된 후에 시작하도록 순서를 지정할 수 있습니다.
• 볼륨 마운트: 로컬 개발 코드를 컨테이너 내부로 실시간으로 연결(volumes)하여, 코드를 수정할 때마다 이미지를 다시 빌드할 필요 없이 즉시 반영되게 할 수 있습니다. (개발 생산성 극대화!)

실습 시나리오: docker-compose.yml을 작성하여, web 서비스가 db 서비스의 환경 변수(예: DB_HOST=db, DB_USER=user)를 참조하도록 설정하는 것이 핵심입니다. 이렇게 하면, docker compose up 한 번으로 전체 개발 환경이 한 번에 구축됩니다.

🚀 3단계: Kubernetes (K8s)의 개념적 이해 (프로덕션 레벨)

Docker Compose는 '내 컴퓨터'나 '개발팀의 테스트 서버'처럼 제어 가능한 소규모 환경에 최적화되어 있습니다. 하지만 서비스가 수백 명의 사용자를 만나고, 트래픽이 폭증하는 대규모 프로덕션 환경에서는 더 강력한 관리 시스템이 필요합니다. 그게 바로 Kubernetes(K8s)입니다.

K8s는 컨테이너를 '배포'하는 것을 넘어, 컨테이너들이 '항상 원하는 상태를 유지하도록' 관리해주는 시스템입니다. 이론을 깊게 파기보다, 이 세 가지 개념이 왜 필요한지 이해하는 것이 중요합니다.

1. Pod (가장 작은 배포 단위)

• 개념: 컨테이너를 담는 가장 작은 단위입니다. 하나의 Pod 안에는 보통 관련된 여러 컨테이너(예: 웹 앱 컨테이너 + 로깅 에이전트 컨테이너)가 함께 묶여서 동작합니다.
• 왜 필요한가? 컨테이너들이 서로 긴밀하게 협력해야 할 때, 이들을 하나의 논리적 단위로 묶어 관리하기 위함입니다.

2. Deployment (원하는 상태 유지 관리자)

• 개념: '나는 이 애플리케이션의 웹 서버가 항상 3개가 돌아가야 해'라는 **'원하는 상태(Desired State)'**를 정의합니다. Deployment는 이 상태를 감시합니다.
• 왜 필요한가? 만약 웹 서버 컨테이너 중 하나가 갑자기 다운되거나 비정상적으로 종료되면, Deployment가 이를 감지하고 자동으로 새 컨테이너를 띄워 3개를 유지시켜 줍니다. (Self-Healing 기능)

3. Service (안정적인 접근 경로)

• 개념: Pod들은 IP 주소가 계속 바뀝니다. 만약 다른 서비스가 웹 서버에 접속할 때마다 Pod의 IP를 알아내야 한다면 매우 복잡하겠죠?
• 왜 필요한가? Service는 웹 서버 Pod들이 어떤 IP를 가지든 상관없이, 항상 같은 이름과 고정된 네트워크 주소를 제공하는 '가상 로드 밸런서' 역할을 합니다. 다른 서비스들은 이 Service 주소만 알면 되므로, 아키텍처가 매우 안정적이고 예측 가능해집니다.

🏁 요약: 개발 프로세스의 진화

1. 개발 (Local): Dockerfile & Docker Compose $ ightarrow$ 내가 원하는 환경을 로컬에서 완벽히 재현한다.
2. 테스트/배포 (Staging/Prod): Kubernetes $ ightarrow$ 트래픽 변화에 맞춰, 원하는 상태를 유지하며 무중단으로 서비스를 운영한다.

이 흐름을 이해하는 것만으로도 여러분의 포트폴리오와 면접 답변의 깊이가 한 단계 올라갈 겁니다. 꾸준히 실습하며 이 개념들을 체화하시길 응원합니다!