Docker(도커)를 활용한 컨테이너화와 클라우드 배포 기초

내 컴퓨터에서는 완벽하게 돌아가던 코드가 서버에만 올리면 파이썬 버전이 다르다느니, 라이브러리가 꼬였다느니 하며 온갖 에러를 뿜어내기 일쑤입니다. 과거에는 이를 해결하기 위해 서버마다 환경 설정을 일일이 맞추는 '삽질'의 시간이 필요했습니다.
하지만 현대 백엔드 아키텍처는 Docker(도커)라는 혁신적인 도구로 이 문제를 해결했습니다. 오늘은 내 코드를 어디서나 동일하게 실행시키는 컨테이너 기술의 핵심과, 이를 클라우드 서버에 올리는 배포 아키텍처의 기본 원리에 대해 파헤쳐 보겠습니다.

 

1. 가상머신(VM)을 넘어 컨테이너(Container)로: 왜 Docker인가?
과거에는 하나의 서버 자원을 쪼개 쓰기 위해 가상머신(VM)을 썼습니다. 하지만 VM은 OS 위에 또 다른 OS를 통째로 올리는 방식이라 너무 무겁고 느렸죠.
반면 Docker는 '컨테이너'라는 개념을 사용합니다. OS 커널은 공유하되, 내 애플리케이션 실행에 필요한 코드, 라이브러리, 환경 설정만 딱 묶어서 격리된 환경을 만드는 것입니다. 덕분에 가볍고 빠르며, 무엇보다 **"내 컴퓨터에서 돌아가는 컨테이너는 AWS에서도, GCP에서도 똑같이 돌아간다"**는 엄청난 신뢰성을 제공합니다.

 

2. 실무 API 서버(FastAPI) Dockerizing: Dockerfile 작성법
백엔드 서버를 컨테이너로 만드는 과정은 의외로 간단합니다. 프로젝트 루트 폴더에 Dockerfile이라는 이름의 설정 파일을 만들고, 우리 서버가 어떤 환경에서 돌아가야 하는지 명시해 주면 됩니다.
# 1. 가벼운 파이썬 3.10 이미지 기반으로 시작
FROM python:3.10-slim

# 2. 서버 내 작업 디렉토리 설정
WORKDIR /app

# 3. 라이브러리 설치를 위해 requirements.txt 복사
COPY requirements.txt .

# 4. 의존성 라이브러리 설치 (캐시 최적화)
RUN pip install --no-cache-dir -r requirements.txt

# 5. 소스 코드 전체 복사
COPY . .

# 6. FastAPI 서버 실행 (uvicorn 사용)
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

 코드 인사이트:
여기서 가장 중요한 기술적 디테일은 '레이어 캐싱(Layer Caching)'입니다. 소스 코드를 복사하기 전에 requirements.txt를 먼저 복사하고 라이브러리를 설치했죠? 이렇게 하면 코드가 수정될 때마다 무거운 라이브러리를 다시 설치할 필요 없이, 바뀐 코드 부분만 빠르게 빌드할 수 있습니다. 이는 실무에서 배포 속도를 수십 배 단축시키는 핵심 기법입니다.

 

3. 클라우드 배포 아키텍처: EC2 vs ECS vs 서버리스(Serverless)
도커 이미지를 빌드했다면, 이제 이 컨테이너를 올릴 땅(Server)이 필요합니다. 클라우드 서비스(AWS/GCP/Azure)는 크게 세 가지 방식의 배포 환경을 제공합니다.
 * IaaS (EC2): 가상 서버 한 대를 통째로 빌리는 방식입니다. 가장 자유도가 높지만, OS 업데이트나 보안 설정을 직접 관리해야 하는 번거로움이 있습니다. 초기 스타트업이나 학습용으로 적합합니다.
 * CaaS (ECS / GKE): 컨테이너만 던져주면 클라우드가 알아서 관리해 주는 방식입니다. 서버가 죽으면 자동으로 살려주고, 트래픽이 몰리면 컨테이너 개수를 늘려주는 '오케스트레이션'이 핵심입니다.
 * Serverless (Cloud Run / Lambda): 요청이 올 때만 컨테이너를 잠깐 깨워서 실행하는 방식입니다. 트래픽이 없을 땐 비용이 0원이라 경제적이지만, 첫 요청 시 반응이 살짝 느린 '콜드 스타트' 문제가 있습니다.

 

실무 대처법: 도커 빌드 시 발생하는 '플랫폼(Arch) 불일치' 에러 해결
최근 M1/M2/M3 맥북을 사용하는 개발자들이 가장 많이 겪는 대참사가 있습니다. 내 맥북에서 도커 이미지를 빌드해서 AWS(리눅스 서버)에 올렸는데, exec format error를 뱉으며 서버가 아예 실행되지 않는 현상입니다.
이는 맥북의 ARM 아키텍처와 서버의 x86(Intel) 아키텍처가 다르기 때문에 발생합니다.
해결책:
도커 빌드 시 아래와 같이 --platform 옵션을 명시해 주어야 합니다.
docker build --platform linux/amd64 -t 내이미지이름 .
이렇게 빌드해야 서버 아키텍처에 맞는 실행 파일이 생성되어 클라우드 환경에서도 문제없이 작동합니다. 실무에서 배포 직전에 가장 많이 당황하는 포인트이니 반드시 기억해 두세요.

 

4. 마무리 (인프라를 아는 개발자가 강하다)
컨테이너화는 단순히 배포를 편하게 만드는 도구를 넘어, 개발과 운영의 경계를 허무는 DevOps의 시작점입니다. 내가 짠 코드가 어떤 환경에서, 어떤 자원을 소모하며 돌아가는지 이해하는 백엔드 개발자는 단순한 코더(Coder)를 넘어 아키텍트(Architect)로 성장하게 됩니다.
이제 우리의 API 서버는 도커라는 튼튼한 장갑차에 실려 클라우드라는 광활한 대지로 나갈 준비를 마쳤습니다. 하지만 서버를 올렸다고 끝이 아닙니다. 유저들이 접속하기 시작하면 "서버가 왜 느리지?", "에러가 어디서 터졌지?"라는 질문에 답해야 하죠.
다음 포스팅에서는 배포된 서버의 건강 상태를 24시간 감시하고 에러를 추적하는 '프로덕션 로깅(Logging)과 모니터링(Monitoring) 시스템 구축 전략'에 대해 심도 있게 다루어 보겠습니다.