스테이징 환경을 만들어 업데이트를 시험하는 방법

이런 상황일 때

업데이트를 시험해 보고 올리라는 말은 알겠는데, 그러자고 서버를 하나 더 두기는 부담스럽습니다. 집에 있는 장비 하나로 어떻게든 해 보고 싶습니다.

한 줄 결론

같은 장비에서 됩니다. 프로젝트 이름을 갈라 주면 컨테이너 이름도 볼륨 이름도 따로 만들어집니다. 포트만 겹치지 않게 바꾸면 운영 중인 것과 나란히 띄울 수 있습니다.

핵심 개념

프로젝트 이름이 경계를 만든다

Compose 는 프로젝트 이름을 앞에 붙여 컨테이너와 볼륨을 만듭니다. 이름을 다르게 주면 볼륨까지 따로 생기므로, 시험하다 데이터를 건드려도 운영 쪽은 그대로입니다.

포트는 반드시 갈라야 한다

같은 포트를 두 번 잡을 수 없습니다. 시험용은 다른 번호로 두고, 되도록 127.0.0.1 에만 묶어 밖에서 닿지 않게 합니다.

데이터는 복사해 넣는다

빈 상태로 시험하면 “켜지긴 하네” 이상을 알 수 없습니다. 운영 데이터의 사본을 넣어야 실제로 무엇이 깨지는지 보입니다.

스테이징이 재현하지 못하는 것

데이터 양(운영에는 몇 년치가 쌓여 있습니다), 외부 연동(다른 서비스가 부르는 부분), 인증서와 도메인. 이 셋은 시험 환경에서 잘 되고도 운영에서 깨지는 대표적인 자리입니다.

이런 분에게 해당됩니다

• Docker 로 홈서버를 꾸린 분
• NAS 한 대로 여러 서비스를 돌리는 분
• 메이저 업데이트를 앞두고 미리 확인하고 싶은 분

확인해야 할 항목

• 시험용 프로젝트 이름을 운영과 다르게 두었는가
• 포트가 운영과 겹치지 않는가
• 볼륨이 따로 만들어졌는가
• 운영 데이터의 사본을 넣었는가
• 시험이 끝난 뒤 정리할 방법을 정해 두었는가

잘못 이해하기 쉬운 부분

안전한 행동 순서

1. 운영에서 쓰는 compose 파일을 복사합니다.
2. 포트를 다른 번호로 바꾸고 127.0.0.1 에 묶습니다.
3. 프로젝트 이름을 다르게 주어 띄웁니다.
4. 볼륨이 정말 따로 만들어졌는지 확인합니다.
5. 운영 데이터의 사본을 넣고 실제로 쓰는 기능을 해 봅니다.
6. 새 판으로 올려 보고 무엇이 달라지는지 봅니다.
7. 끝나면 반드시 정리합니다.

시험용으로 띄우기 (프로젝트 이름을 갈라 준다)

docker compose -p stagetest up -d
docker compose -p stagetest ps

컨테이너 이름이 stagetest- 로 시작하면 제대로 갈린 것입니다 · 확인: 2026-08-05 · wp3 VM (Debian, Docker Compose v2)

볼륨이 정말 따로 만들어졌는지 확인

docker volume ls --format '{{.Name}}'

stagetest_ 로 시작하는 볼륨이 따로 보이면 운영 볼륨과 섞이지 않은 것입니다 · 확인: 2026-08-05 · wp3 VM (Debian, Docker Compose v2)

시험이 끝나면 정리

docker compose -p stagetest down

볼륨은 남습니다. 볼륨까지 지우려면 -v 를 붙이는데, 그때는 지우려는 것이 시험용 볼륨이 맞는지 위 목록으로 먼저 확인하세요 · 확인: 2026-08-05 · wp3 VM (Debian, Docker Compose v2)

확인 체크리스트

• 프로젝트 이름을 운영과 다르게 주었다
• 포트를 바꾸고 127.0.0.1 에 묶었다
• 볼륨이 따로 만들어진 것을 확인했다
• 운영 데이터 사본으로 시험했다
• 시험이 끝난 뒤 정리했다

관련 도구와 버전 페이지

• 컨테이너 최신 버전 정리
  Docker Compose·Portainer·containerd 의 현재 판을 정리해 두었습니다. 시험 환경을 만들기 전에 Compose 판부터 확인하세요.

자주 묻는 것

포트를 몇 번으로 잡아야 하나요?

쓰이지 않는 높은 번호면 됩니다. 중요한 것은 번호보다 127.0.0.1 에 묶어 밖에서 닿지 않게 하는 것입니다.

운영 데이터를 복사해도 되나요?

사본을 쓰는 것이 핵심입니다. 운영 볼륨을 시험 쪽에 그대로 물리면 시험이 운영 데이터를 바꿔 버립니다.

가상 머신으로 하는 것과 무엇이 다른가요?

가상 머신 쪽이 더 실제에 가깝습니다. 대신 자원을 많이 쓰고 준비가 오래 걸립니다. 대부분의 업데이트 확인에는 여기 방식으로 충분합니다.