[Docker 시리즈 12편] Compose로 충분한 범위를 확인하고 다음 인프라 단계로 가기

마지막 회차입니다. 지금까지 Docker 이미지, Nginx, 개발용 볼륨 전략을 차근차근 익혔다면 이제 "이 도구들이 어디까지 우리를 도와줄 수 있는가?"를 판단할 차례입니다. 고등학생 개발자 입장에서는 학교 프로젝트나 사이드 프로젝트를 빠르게 돌리고 싶은데, 도구마다 배워야 할 양이 다르기 때문에 범위를 잡는 감각이 매우 중요합니다.

이 글의 흐름

1. Docker·Compose가 학습과 소규모 프로젝트에 주는 장점
2. Compose만으로 충분한 대표 시나리오
3. Compose가 한계를 드러내는 순간과 징후
4. 다음 단계 학습 로드맵
5. 여러 프로젝트에 적용하는 대표 예시

읽기 카드

• 예상 소요 시간: 17분
• 사전 준비: 앞선 111편 중 적어도 811편
• 읽고 나면: 현재 프로젝트에 필요한 인프라 범위를 스스로 판별하고, 다음 학습 주제를 정리할 수 있습니다.

Docker·Compose가 주는 장점

• 환경 통일: 모든 팀원이 같은 Dockerfile과 Compose 파일을 실행하면 Node, Python, DB 버전 차이로 헤매지 않습니다.
• 손쉬운 재현: 한 번 만들어 둔 이미지는 어디서든 docker run 한 줄로 결과를 재현할 수 있습니다.
• 문서 대체: Compose 파일 자체가 "서비스가 몇 개이고, 어떤 포트로 열리고, 무슨 볼륨을 쓰는지"를 보여 주는 최신 문서가 됩니다.
• 학습 친화적: 로컬 노트북 한 대만 있으면 프런트엔드+백엔드+DB를 합쳐 놓고도 관리 부담이 크지 않습니다.

덕분에 동아리 프로젝트, 공모전 준비, 블로그 운영처럼 규모가 작은 서비스에서는 Docker/Compose가 가장 빠르게 완성도를 올리는 도구가 됩니다.

Compose만으로 충분한 대표 시나리오

1. 정적 웹사이트 + 간단한 API: Nginx로 정적 파일을 내보내고 /api는 Node/Express 컨테이너로 프록시하는 구조. 상태 저장소가 거의 없으니 Compose 한 장이면 끝납니다.
2. 학습용 데이터베이스 연동: MySQL/PostgreSQL 같은 DB를 이름 있는 볼륨과 함께 Compose에 추가해 두면, 보고서나 과제 때마다 동일한 데이터를 바로 띄울 수 있습니다.
3. 동아리 프로젝트: 프런트, 백엔드, Redis 큐 정도로 구성된 서비스를 노트북이나 학교 서버 한 대에 올려 두고, docker compose up -d로 재시작만 관리해도 충분합니다.

이런 상황에서 쿠버네티스를 도입하면 오히려 학습 속도를 떨어뜨릴 수 있습니다. Compose는 단일 호스트에 최적화되어 있어 "코드를 바꾸면 즉시 반영되고, 문제가 생기면 재시작" 같은 단순한 사이클에 강합니다.

처음 판단이 어렵다면 아래 체크리스트로 생각해 볼 수 있습니다.

• 서버가 한 대인가?
• 팀이 아직 작고, 배포 절차도 단순한가?
• 자동 스케일링이나 롤링 업데이트가 꼭 필요하지 않은가?
• 로그와 메트릭을 간단히 보는 정도면 충분한가?

이 질문에 대부분 "예"라고 답한다면 Compose로 시작해도 충분합니다.

Compose가 한계를 드러내는 순간

• 여러 서버로 확장해야 한다면: Compose는 한 대의 머신에서만 동작하므로 서버 수가 늘수록 배포 명령을 반복해야 합니다.
• 상태ful 서비스 증가: PostgreSQL, Redis, MinIO 같이 데이터를 보존해야 하는 컨테이너가 많아지면 백업·복구 전략이 필요합니다.
• 무중단 배포: docker compose up -d는 한 번에 컨테이너를 교체하므로 롤링 업데이트나 카나리 배포를 직접 제어하기 어렵습니다.
• 관찰 가능성 요구: 로그, 트레이싱, 메트릭을 한곳에 모으려면 Prometheus, Loki 같은 도구를 붙여야 하는데, Compose 파일이 금방 복잡해집니다.

이런 요구가 쌓이면 Docker Swarm, Kubernetes(k3s, k8s) 같은 클러스터 오케스트레이션을 검토해야 합니다. 하지만 "왜 필요한지"를 스스로 설명할 수 있을 때 넘어가야 도구가 짐이 되지 않습니다.

다음 학습 로드맵

1. 컨테이너 레지스트리: GitHub Container Registry 혹은 Docker Hub에 이미지를 올리고 docker compose pull 기반 배포를 연습합니다.
2. 자동 인증서: Nginx+Let's Encrypt 조합(Lego, Caddy, Certbot 등)으로 HTTPS를 자동화합니다.
3. 상태ful 서비스: PostgreSQL, Redis, MinIO 같은 서비스에 이름 있는 볼륨과 백업 전략을 붙입니다.
4. 경량 오케스트레이션: Docker Swarm이나 k3s로 넘어가 2~3대 서버를 묶어 보는 실습을 합니다.
5. 관찰 가능성: Loki+Promtail, Prometheus+Grafana로 로그·메트릭을 수집하고 대시보드를 만들어 봅니다.

각 단계를 프로젝트와 연결해 "왜 필요한지" 설명하면서 진행하면 도구가 단순 암기 과제가 아닌 성장 도구가 됩니다.

여러 프로젝트에 적용하는 대표 예시

Compose는 특정 레포에만 맞는 도구가 아닙니다. 예를 들면 아래 같은 프로젝트에서 많이 쓰입니다.

• 동아리 홈페이지: 정적 사이트 + 간단한 문의 API
• 학습용 웹 서비스: 프런트엔드 + 백엔드 + PostgreSQL
• 개인 블로그: 정적 사이트 + 댓글/분석 도구

이 레포의 mathbong도 그중 하나의 예시일 뿐입니다. 정적 사이트를 Nginx로 서빙하고, 필요하면 Compose로 개발용 컨테이너나 보조 서비스를 함께 묶는 방식은 아주 흔한 패턴입니다.

여러분의 프로젝트에서도 비슷한 패턴을 적용해 보고, 규모가 커질 때 어떤 부분부터 한계가 느껴지는지 기록해 보세요. 그 경험이 다음 단계 도구를 선택할 때 가장 중요한 자료가 됩니다. 지금까지 12편을 따라온 여러분은 이미 Docker/Compose를 활용해 학습용 또는 소규모 서비스를 스스로 설계하고 운영할 수 있는 수준에 도달했습니다. 이제는 자신만의 프로젝트에 적용하면서 필요할 때마다 새로운 인프라 기술을 추가해 보세요. 고생 많았습니다!