한 줄로 쉽게 올리는 서비스 – Docker Compose 이야기

서론

서비스 하나를 띄운다는 건 생각보다 많은 일을 수반합니다.

백엔드 서버 하나만 있어도 DB가 필요하고, 캐시가 필요하고, 때로는 메시지 큐나 외부 API 목업 서버까지 붙어야 하죠.

 

그때마다 우리는 명령어를 반복합니다.

docker run ...
docker run ...
docker run ...

처음엔 재밌을 수 있지만, 곧 지칠겁니다.

"이 많은 걸 왜 매번 따로 띄워야 하지?"
"내가 띄운 환경을 다른 팀원도 그대로 재현하려면 어떻게 하지?"

 

이런 반복적인 부분 뿐만이 아닙니다.

팀원들의 다양한 요구사항을 관리하기에는 쉽지 않았기 때문입니다.

"내 애플리케이션은 DB 없이는 작동하지 않아요."
"Redis도 필요하고, Celery도 있어야 해요."
"그러면 그걸 다 띄우는 스크립트라도 줘야 하나요?"

 

Docker만으로는 시스템 전체 구성을 담기 어려웠던 겁니다.

그렇게 나타난 게 Docker Compose입니다.

---

Docker와 차이점

Docker가 개별 컨테이너에 집중한 도구라면, Docker Compose는 시스템 전체 구성을 바라봅니다.

마치 오케스트라에서 각각의 악기가 연주되는 순서와 볼륨을 조율하듯, Compose는 컨테이너들이 언제, 어떤 설정으로, 어떻게 연결되어야 하는지를 한 파일에 정리해 줍니다.

 

바로 docker-compose.yml 하나의 파일에서 서비스들을 정의하고 관리하게 됩니다.

version: '3'
services:
  db:
    image: postgres
  app:
    build: .
    depends_on:
      - db

그리고 하나의 명령어를 통해 모든 서비스들을 다루게 됩니다.

docker compose up

위의 명령어를 통해 여러 개의 컨테이너가 함께 구동하게 됩니다.

---

docker-compose 활용

현업에서는 docker-compose가 생각보다 더 다양한 상황에서 사용됩니다. 

1. 로컬 개발 환경

새로운 개발자가 입사했습니다.

온보딩 문서를 펼치자마자 이렇게 적혀 있네요.

 

1. MySQL 설치
2. Redis 설치
3. 백엔드 서버 실행 방법
4. 프론트엔드 npm 빌드…
5. .env 설정

"…? 어디서부터 해야 하죠?"
"Redis 포트는 로컬이랑 운영이 다른데요?"
"왜 제 환경에선 안 되는 거죠…?"

 

이건 새로운 사람만의 문제가 아닙니다.

팀 전체가 ‘누구는 되고 누구는 안 되는’ 개발 환경을 계속 떠안고 있는 상황이 되는 거죠.

 

하지만, docker-compose 면 쉽게 해결이 가능합니다.

git clone [Remote Repository URL]
docker compose up

 

단 2줄이면 됩니다. 환경 차이? OS 호환성? 거의 걱정 없죠.

MySQL, Redis, 백엔드, 프론트엔드까지 모두 정해진 버전, 설정, 포트로 올라옵니다.

 

심지어,

• OS가 Windows든 Mac이든 관계없이
• 설치 순서를 몰라도 되고
• Redis 설정이 다르다고 삽질하지 않아도 됩니다

그냥 브라우저를 열고 localhost:3000에 접속하면 됩니다.

그리고 백엔드에 요청을 보내보면, 이미 DB와 연결된 상태죠.

 

개발자가 ‘개발’에 집중할 수 있는 환경.

docker-compose의 진짜 가치는 바로 여기에 있습니다.

2. CI/CD 파이프라인

개발할 때는 잘 작동하던 코드가, 막상 GitHub Actions 같은 CI에서 테스트가 실패할 때가 있습니다. 대부분은 외부 종속 서비스가 빠져서 그렇죠.

 

예를 들어, 백엔드 개발자가 API를 작성하면서 PostgreSQL에 의존하고 있다고 가정해볼게요.

로컬에서는 Docker로 DB 띄워두고 테스트가 잘 돌아갔습니다. 하지만 CI 환경에서는 PostgreSQL 컨테이너가 없기 때문에 테스트가 전부 실패합니다.

 

이럴 때 docker-compose.yml을 같이 포함해놓으면 아주 간단해집니다.

# docker-compose.test.yml
version: '3.8'
services:
  db:
    image: postgres:14
    environment:
      POSTGRES_USER: test
      POSTGRES_PASSWORD: test
      POSTGRES_DB: testdb
    ports:
      - "5432:5432"

그리고 GitHub Actions에서 이렇게 실행하죠.

- name: 테스트 환경 구성
  run: docker compose -f docker-compose.test.yml up -d

- name: 유닛 테스트 실행
  run: pytest tests/

DB를 수동 설치할 필요 없고, 테스트 환경을 로컬과 동일하게 구성 가능하게 됩니다.

또한, QA/운영과 동일한 DB 버전 사용 가능하고 실패 원인을 환경이 아닌 코드에만 집중 가능하게 만들죠.

하지만 여기엔 놓치기 쉬운 중요한 고민거리가 하나 있습니다.

"우리가 실제 운영에서는 RDS 같은 Managed DB 서비스를 쓰고 있는데, 로컬 컨테이너 DB에서 테스트하는 게 과연 의미 있을까?"

 

docker-compose DB는 진짜 환경을 얼마나 반영할까? 를 고민해보면,

• 운영에서는 AWS RDS(PostgreSQL), CI에선 Docker 컨테이너 PostgreSQL 15
• 운영은 strict 모드 ON, CI는 기본 설정
• 운영은 다중 AZ 구성, CI는 단일 컨테이너

이렇게 다르다면, CI에서의 테스트는 단순 유닛 테스트 이상은 보장하기 어렵습니다.

즉, 로직은 검증해도, 운영 환경과의 호환성이나 성능 이슈는 놓칠 수 있다

그렇다면 어떻게 해야 할까요?

아마 현실적인 답은 “용도에 따라 Compose와 Managed DB를 잘 분리해서 사용하자”로 귀결시킬 수 있을 것 같습니다.

• 로컬 / PR 단위 테스트 : 빠른 테스트, 단순 CRUD 로직 확인 → docker-compose로 컨테이너 사용
• 통합 테스트 / staging 환경 : 운영과 유사한 환경 → 실제 RDS를 복제한 인프라 구성, 또는 테스트 전용 RDS 인스턴스 사용

3. QA 및 시연 환경

"이 기능 릴리즈되면 어떻게 동작하나요?"

 

QA팀이나 PO(기획자)가 기능을 눈으로 보고 싶을 때, 보통 이렇게 하죠:

1. 로컬에 DB, 백엔드, 프론트엔드 각각 세팅
2. config 수정하고 실행
3. 외부 서비스는 목서버로 대체하거나 수작업 설정…

한마디로, 빠르게 시연 환경을 만든다는 건 쉬운 일이 아닙니다.

 

하지만 docker-compose를 쓰면 얘기가 달라져요.

git clone [Remote Repository URL for QA]
docker compose -f docker-compose.qa.yml up -d

몇 줄이면 QA 테스트를 위한 독립적인 시연 환경이 바로 생성됩니다.

 

예를 들어, docker-compose.qa.yml에 이런 구성이 있다고 가정해보면,

services:
  db:
    image: postgres:14
  backend:
    image: myorg/backend:qa-feature-branch
    environment:
      - SPRING_PROFILES_ACTIVE=qa
  frontend:
    image: myorg/frontend:qa-feature-branch
    ports:
      - "3000:80"

QA팀은 localhost:3000에 접속해서 실제 UI를 체험하고,

백엔드는 qa 프로필로 동작하며, QA 전용 PostgreSQL 인스턴스를 사용할 수 있습니다.

 

즉, 기능 단위의 독립적인 검수 환경을 누구나 쉽게 띄울 수 있다는 것.

GitHub 링크 하나, Compose 파일 하나만 공유하면 끝입니다.

 

"이거 괜찮네. 이 상태로 릴리즈하면 좋겠어요."

라는 피드백을 받는 순간, Compose 덕을 톡톡히 보게 되는 거죠.

---

결론

현대 개발은 팀 단위로 움직입니다.

"나만 되는 코드"는 이제 의미가 없습니다.

누구나, 어디서나, 쉽게 띄울 수 있는 환경.

그게 진짜 개발 생산성을 높이는 방법이죠.

 

docker-compose는 이 문제를 너무도 우아하게 해결합니다.

 

단지 "편한 툴”이 아니라, 팀과 협업을 가능하게 해주는 도구라고 생각해보면 좋을 것 같다는 말을 남기며,

글을 마무리 하겠습니다.