docker compose up을 쳤더니 정작 필요한 앱·DB 말고도 디버깅용 어드민 도구, 모니터링, 시드 컨테이너까지 전부 떠서 메모리를 잡아먹은 적 있을 겁니다. 환경마다 compose 파일을 따로 두고 -f로 갈아끼우는 방식은 중복이 쌓여 관리가 어려워집니다. profiles는 하나의 파일 안에서 서비스마다 "어느 상황에서 뜰지" 라벨을 붙여, 평소엔 핵심만 띄우고 필요할 때만 추가 서비스를 켜는 기능입니다.
profile 없는 서비스 vs 있는 서비스
services:
app: # profile 없음 → 항상 뜸
image: myapp:1.0
ports: ["8080:8080"]
db: # profile 없음 → 항상 뜸
image: postgres:16
adminer: # dev 프로파일에서만
image: adminer
profiles: ["dev"]
prometheus: # monitoring 프로파일에서만
image: prom/prometheus
profiles: ["monitoring"]
profile이 없는 서비스는 항상 뜹니다. profile이 붙은 서비스는 그 profile을 명시적으로 켜야만 뜹니다.
켜는 방법
# 핵심만 (app, db)
docker compose up
# dev 도구까지 (app, db, adminer)
docker compose --profile dev up
# 여러 개 동시에
docker compose --profile dev --profile monitoring up
환경변수로도 켤 수 있어 .env에 COMPOSE_PROFILES=dev를 두면 매번 플래그를 안 붙여도 됩니다.
상황별 사용 패턴
| 상황 | profile 구성 | 띄우는 명령 |
|---|---|---|
| 평소 개발 | 없음(app·db) | docker compose up |
| DB 들여다볼 때 | dev(adminer) | --profile dev up |
| 부하·지표 확인 | monitoring | --profile monitoring up |
| 초기 데이터 주입 | seed(1회성 job) | --profile seed up seed |
흔한 함정
① 의존 서비스가 안 떠서 실패 — profile이 걸린 서비스가 depends_on으로 다른 profile 서비스를 참조하면, 그 의존 대상도 활성화돼야 합니다. 같은 profile로 묶거나 의존 대상을 profile 없는 핵심으로 두면 해결됩니다.
② 특정 서비스만 켜고 싶을 때 — docker compose up <서비스명>으로 이름을 직접 지정하면, 그 서비스에 걸린 profile은 자동으로 활성화됩니다. seed 같은 1회성 작업에 유용합니다.
③ down이 profile 서비스를 안 내림 — --profile을 안 붙이고 docker compose down을 치면 profile 서비스가 남을 수 있습니다. 내릴 때도 같은 profile을 붙이거나 down --remove-orphans를 씁니다.
확인
docker compose config --profile dev # 활성 서비스 목록 미리보기
docker compose ps # 실제로 뜬 서비스 확인
config로 어떤 서비스가 포함되는지 먼저 보면, 의도한 환경 그대로 뜨는지 실행 전에 검증할 수 있습니다.
profile로 dev·prod 서비스를 나눠 띄워 보며 차이를 확인하는 실습은 도커 트랙에서 무료로 할 수 있습니다.