문제
mbti 프로젝트에서 Docker를 도입하고 CI/CD부터 AWS 인프라까지 직접 구성을 했다.
과제 완료 후에 CI/CD 흐름을 이해하기 위해 그리면서 의문이 생긴것이다.
"Docker를 사용하면 개발자마다 동일한 환경을 만들 수 있다고 하지 않았나?"
그런데 막상 내가 구성한 환경을 돌아보니 조금 달랐다.
나는 Docker Image를 만들고, 이를 Docker Hub에 Push한 뒤 EC2에서 Pull해서 컨테이너를 실행하고 있었다.
Docker Image
↓
Docker Hub
↓
EC2
↓
Docker Container
애플리케이션을 배포하는 데에는 문제가 없었다.
하지만 여기서 이상한 점을 발견했다.
이것만으로는 여러 개발자가 동일한 개발 환경을 제공해준다고,,?
내가 처음 생각했던 Docker
처음에는 Docker Image 자체가 개발 환경을 통째로 공유하는 것이라고 생각했다.
예를 들어 Spring Boot 애플리케이션을 Docker Image로 만들면 그 안에는 다음과 같은 것들이 들어간다.
Docker Image
├── Java
├── Spring Boot Application
├── Dependency
└── Application 설정
그리고 이 이미지를 다른 개발자가 Pull해서 실행하면 같은 환경에서 실행할 수 있다고 생각했다.
이 생각은 완전히 틀린 것은 아니다.
Docker Image를 사용하면 애플리케이션이 실행되는 환경을 일정하게 만들 수 있다.
하지만 여기에는 중요한 전제가 빠져 있었다.
애플리케이션 하나만 실행하면 되는가?
Docker Image 하나로는 개발 환경이 완성되지 않는다
Docker를 사용하고 있지만 협업이었다면 개발 환경 전체가 동일하다고는 보장할 수 없다.
문제 A — 내 코드가 도는 환경 자체가 다름 (Java 버전 등)
Docker 이미지 하나로 끝난다. jar를 이미지로 말면 FROM amazoncorretto:17이 고정되니 누가 실행해도 같은 런타임이 보장된다. 내가 만든 Dockerfile이 정확히 이 범위만 해결하고 있었다.
문제 B — 내 코드가 의존하는 다른 서비스(DB 등)까지 사람마다 준비 상태가 다름
이미지 하나로는 안 풀린다.
MySQL은 내 코드 안에 포함된 것이 아니라, 애플리케이션이 실행되기 위해 필요한 외부 의존 서비스이기 때문에 사람마다
설치 버전·포트·DB 이름이 다르면 같은 Dockerfile을 써도 안 잡힌다.
여기서 내가 놓치고 있던 것이 Docker Compose였다.
Docker Compose는 무엇을 해결해주는가?
Docker Compose는 Docker Image를 대체하는 기술이라기보다,
여러 컨테이너를 하나의 애플리케이션 환경으로 묶어서 관리하기 위한 도구에 가깝다.
services:
app:
depends_on:
db:
condition: service_healthy
db:
image: mysql:8.4
이런식으로 작성하면 필요한 서비스에 대한 설정을 함께 관리할 수 있다.
그러면 새로운 개발자는 프로젝트를 받은 뒤
docker compose up
명령 하나로 Spring Boot와 MySQL을 함께 실행할 수 있다.
이 한 줄이 정확히 뭘 대체하는지는 아래 비교가 명확하다.
손으로 할 때 Compose가 해주는 일
| docker network create app-net | 프로젝트 전용 네트워크 자동 생성 |
| --name my-mysql로 이름 관리 | 서비스 이름이 곧 주소가 된다 (db:3306) |
| mysqladmin ping으로 수동 확인 | healthcheck + depends_on으로 자동 대기 |
| -e, -p, -v 매번 입력 | 파일 하나로 선언, Git으로 버전 관리 |
이렇게 보면, Docker Image는 앞서 말한 문제 A(실행 환경 고정)를 풀고, Docker Compose는 문제 B(주변 서비스까지 포함한 구성)를 푼다.
정작 mbti 프로젝트엔 Compose가 없었다
여기까지 정리하고 나니 의문이 하나 생겼다. 그럼 mbti 프로젝트는 문제 B를 어떻게 피해간 거지? mbti에는 docker-compose.yml이 없었다.
돌아보니 내 프로젝트에 Compose가 없었던 것 자체가 문제는 아니었다. 애초에 Compose가 풀어야 할 협업 문제가 발생하지 않았다. mbti는 나 혼자 처음부터 끝까지 만든 프로젝트다. 문제 B의 핵심은 "여러 개발자의 준비 상태가 서로 다를 수 있다"는 것인데, 비교 대상이 될 다른 개발자가 없으니 애초에 이 문제가 성립할 상황 자체가 아니었던 것이다.
(DB 구성도 참고할 만하다. 로컬은 H2, prod는 RDS라서 개발자가 로컬에서 MySQL을 직접 설치하고 버전이나 포트 등을 맞춰야 하는 상황도 없었다.
만약 로컬에서도 MySQL을 사용해야 했다면, Docker Compose를 통해 동일한 MySQL 환경을 제공할 수 있었을 것이다.
결국 Compose가 필요해지는 조건은 명확하다. 여러 사람이 같은 환경을 재현해야 하거나, 여러 컨테이너가 서로를 알아야 할 때다. mbti는 둘 다 해당하지 않았다.)
배포 구조와 개발 환경 구성은 다른 문제였다
처음에는 Docker Compose를 알고나서
"그럼 내가 지금까지 구성한 Docker → Docker Hub → EC2 구조는 잘못된 건가?"
라는 생각이 들었다.
하지만 다시 생각해보니 해결하려는 문제가 달랐다.
내가 구축한 구조는 다음과 같다.
GitHub
↓
CI/CD
↓
Docker Image
↓
Docker Hub
↓
EC2
↓
Docker Container
↓
ALB
↓
ASG
이 구조는 빌드된 애플리케이션을 운영 환경에 배포하고, AWS 인프라를 통해 트래픽을 분산하고 확장하는 문제를 해결한다.
반면 Docker Compose는 주로 다음과 같은 문제를 해결한다.
결국 Docker Image 와 AWS인프라는
서로 다른 문제를 해결하고 있었다.
Docker 구성 요소의 역할을 구분해보자
이번 경험을 통해 Docker를 단순히
"애플리케이션을 컨테이너로 만들어서 서버에 배포하는 기술"
로만 생각하면 부족하다는 것을 알게 되었다.
조금 더 나누어 보면 다음과 같다.
Dockerfile
↓
애플리케이션을 어떻게 이미지로 만들 것인가?
Docker Image
↓
어디서 실행하더라도 동일한 애플리케이션 환경 제공
Docker Compose
↓
애플리케이션 + DB 등
여러 서비스를 어떻게 함께 실행할 것인가?
Docker Hub
↓
Docker Image를 어디에 저장하고 공유할 것인가?
EC2 / ALB / ASG
↓
이 애플리케이션을 운영 환경에서
어떻게 배포하고 확장할 것인가?
이렇게 나누고 나니 각각의 기술이 왜 필요한지 조금 더 명확해졌다.
이번에 가장 크게 배운 것
사실 이번에 배운 것은 Docker Compose의 사용법 하나가 아니었다.
처음에는 기술을 하나씩 추가하면서
Docker
→ CI/CD
→ Docker Hub
→ EC2
→ ALB
→ ASG
이렇게 인프라를 확장해 나갔다.
그런데 실제로 구축해보니 기술 하나를 추가하는 것보다
"각 기술들이 해결하려는 문제가 무엇인가?" 를 정확히 아는 것이 중요하다는 것을 느꼈다.
Docker Image는 문제 A(내 애플리케이션의 실행 환경 고정)를 풀고,
Docker Compose는 문제 B(의존 서비스까지 포함한 환경 전체의 구성)를 푼다.
둘은 비슷해 보이지만 해결하려는 문제가 다르다.
이번에 직접 인프라를 구축해보지 않았다면 아마 Docker Compose를 단순히
"Docker를 편하게 실행하는 도구"
정도로 생각했을 것 같다.
하지만 실제로 Docker Image를 Docker Hub에 Push하고 EC2에서 Pull해서 운영해보면서,
"애플리케이션을 동일하게 만드는 것"과 "애플리케이션이 동작하는 전체 환경을 동일하게 만드는 것"은 다르다.
라는 것을 체감할 수 있었다.
앞으로는 기술을 공부할 때 단순히 "이 기술은 무엇인가?"
에서 끝내기보다,
"이 기술은 어떤 문제를 해결하기 위해 존재하는가?"
를 같이 생각해보려 한다면 좋을 것 같다,,
GitHub 링크
https://github.com/trex1004/mbti
GitHub - trex1004/mbti
Contribute to trex1004/mbti development by creating an account on GitHub.
github.com