OpenShip v0.4.7 서버 이전 검수 목록

대상 컨테이너가 실행 중이어도 데이터베이스와 백그라운드 작업이 통과하지 않았다면 OpenShip v0.4.7 서버 이전은 운영 승인하면 안 됩니다. 새 노드에서 각 서비스와 데이터 볼륨을 다시 검증하고, 이전 서버로 되돌리는 절차까지 확인한 뒤에만 DNS를 전환하십시오.

이 글은 기존 Docker 애플리케이션을 옮기는 개발자, 운영 서버를 교체하는 운영 담당자, 새 노드를 지속적으로 확보하려는 기술 책임자를 위한 내용입니다. 단순 배포 성공이 아니라 실제 서비스 전환이 가능한지 판단하는 검수 기준에 집중합니다.

마지막 업데이트: 2026년 8월 3일. 버전 정보는 같은 날짜에 확인한 OpenShip 공식 변경 기록과 공식 설치 문서를 기준으로 정리했습니다. 다음 마이그레이션 버전이 나오거나 컨테이너 인계, 데이터 볼륨, 인증서 처리 방식이 바뀌면 다시 검수해야 합니다.

이전 범위와 승인 기준을 먼저 고정합니다

OpenShip v0.4.7은 원격 Docker 이전 흐름의 안정성을 개선한 버전으로 확인되지만, 제품 화면의 이전 완료 표시와 운영 서비스의 정상 작동은 같은 의미가 아닙니다. 공식 안내에서도 자체 서버에 연결하고, 컨테이너를 배포하고, 인증서와 라우팅을 처리하는 흐름을 설명하지만 실제 데이터 보존과 애플리케이션별 정상 여부는 환경에서 별도로 확인해야 합니다. (openship.io)

특히 다음 세 가지 문제가 자주 승인 시점을 흐립니다.

• 실행 상태와 준비 상태의 차이: 컨테이너가 실행 중이어도 데이터베이스 연결, 외부 API 접근, 초기화 작업이 끝나지 않았을 수 있습니다. Compose는 기본적으로 컨테이너가 실행되었다고 해서 애플리케이션이 요청을 받을 준비가 끝날 때까지 기다리지 않습니다. (docs.docker.com)
• 컨테이너와 데이터의 분리: 컨테이너를 새로 만드는 과정은 이미지와 설정을 복원할 뿐입니다. 데이터 볼륨은 별도 자원이며, 컨테이너를 삭제해도 남을 수 있지만 새 서버에 자동으로 존재한다는 뜻은 아닙니다. (docs.docker.com)
• 관리 화면과 실제 Docker 상태의 차이: 화면에 남은 캐시보다 새 노드에서 직접 확인한 컨테이너, 이미지, 네트워크, 볼륨 정보가 우선입니다. docker inspect는 컨테이너와 볼륨의 상세 정보를 직접 출력하므로 증거 보관에 적합합니다. (docs.docker.com)
• 권한과 외부 의존성의 누락: 새 서버의 환경 변수에 값이 있어도 저장소 접근 권한, 결제 연동, 메일 발송, 작업 큐 연결이 빠지면 핵심 경로가 실패할 수 있습니다.
• 되돌리기 불가능한 전환: 예전 서버를 바로 삭제하면 문제가 발견돼도 서비스와 데이터의 기준점을 복구하기 어렵습니다.

이전 전 기록해야 할 항목

첫 단계는 새 서버에 설치하는 일이 아니라 이전 범위를 고정하는 일입니다. 저장소의 Compose 정의와 현재 실행 목록을 나란히 놓고 다음 자료를 남기십시오.

1. 실제 실행 중인 OpenShip 버전과 설치 방식
2. 이전 서버 주소, 새 서버 주소, 운영 도메인
3. 저장소의 Compose 파일, 오버라이드 파일, 활성 프로필
4. 현재 컨테이너 이름, 서비스 이름, 이미지 이름과 태그
5. 데이터베이스, 업로드 파일, 캐시, 작업 큐에 연결된 데이터 볼륨
6. 환경 변수 이름, 비밀값의 보관 위치, 외부 서비스별 접근 권한
7. 현재 이미지와 설정 파일의 보관 위치
8. 장애 발생 시 예전 서버로 접속할 수 있는 관리 경로

docker compose config는 여러 Compose 파일을 합치고 변수를 적용한 실제 구성을 출력합니다. 이전 전에 이 결과를 파일로 저장하면, 저장소에 적혀 있지 않은 오버라이드나 변수 누락을 비교할 수 있습니다. --services, --images, --volumes 옵션으로 서비스와 이미지, 볼륨 목록도 따로 남길 수 있습니다. (docs.docker.com)

docker compose config > resolved-before.yaml
docker compose config --services > services-before.txt
docker compose config --images > images-before.txt
docker compose config --volumes > volumes-before.txt
docker ps -a > containers-before.txt
docker volume ls > volumes-host-before.txt

여기서 중요한 점은 현재 실행되지 않는 서비스도 제외하지 않는 것입니다. 예약 작업, 관리자 화면, 데이터베이스 초기화용 서비스, 대기 중인 작업 소비자는 평소에는 보이지 않아도 생산 환경에 필요할 수 있습니다.

OpenShip v0.4.7 서버 이전 통과 지표

아래 표를 검수 회의의 승인 도구로 사용하십시오. 각 행에서 증거 위치가 비어 있으면 통과로 처리하지 않는 것이 원칙입니다.

OpenShip 공식 안내는 자체 서버에 SSH로 연결하고 새 컨테이너를 시작하며, 라우팅과 인증서를 처리하는 작업 흐름을 설명합니다. 그러나 위 표의 통과 여부는 공식 기능 설명이 아니라 네 환경에서 수집한 실행 증거로 판정해야 합니다. (openship.io)

첫 번째 검수: 이미지와 컨테이너를 다시 만들 수 있나요?

새 노드에서 대시보드 상태만 보지 말고 직접 실행 목록을 확인하십시오.

docker ps -a
docker image ls
docker network ls
docker volume ls
docker compose ps -a

그다음 통제된 재배포를 한 번 진행합니다. build 서비스는 새 컨테이너를 만들 수 있어야 하고, image 서비스는 필요한 이미지를 다시 받을 수 있어야 합니다. 배포 직후 다음 항목을 확인하십시오.

• 같은 서비스에 컨테이너가 두 개 생기지 않았는가
• 이전 서비스 이름과 새 서비스 이름의 연결이 바뀌지 않았는가
• 포트가 다른 서비스에 잘못 연결되지 않았는가
• 재시작 뒤에도 같은 컨테이너 수와 네트워크 구성이 유지되는가
• 종료된 예전 컨테이너가 새 요청을 처리하고 있지 않은가

docker compose restart는 설정 파일의 변경 내용을 다시 반영하는 명령이 아닙니다. 환경 변수나 서비스 구성을 수정한 뒤 단순 재시작만 하면 새 설정이 들어가지 않을 수 있으므로, 변경 후에는 재생성 또는 재배포 결과를 확인해야 합니다. (docs.docker.com)

두 번째 검수: 데이터베이스와 데이터 볼륨은 살아 있나요?

Docker 마이그레이션에서 가장 위험한 착시는 컨테이너가 정상인데 애플리케이션 자료가 비어 있는 상태입니다. 다음 순서로 확인하십시오.

1. 이전 서버와 새 서버에서 볼륨 이름과 연결 경로를 비교합니다.
2. 데이터베이스의 핵심 테이블이나 컬렉션을 조회합니다.
3. 최근 자료와 오래된 자료를 각각 읽습니다.
4. 테스트용 자료를 쓰고 애플리케이션 화면에서 다시 읽습니다.
5. 컨테이너를 재시작한 뒤 같은 자료를 다시 조회합니다.
6. 백업 성공 기록과 별도로 격리된 위치에 복구합니다.
7. 복구된 데이터베이스에 애플리케이션을 연결해 실제 요청을 보냅니다.

파일 개수만 같다고 통과시키면 안 됩니다. 데이터베이스는 파일 구조가 남아 있어도 권한, 로그 재생, 스키마 상태, 연결 문자열이 맞지 않을 수 있습니다. 데이터 볼륨 역시 볼륨 자체가 존재하는지보다 애플리케이션이 올바른 경로에 연결되어 있는지가 중요합니다.

주의: 백업 작업이 성공으로 표시된 것은 복구 가능성이 확인됐다는 뜻이 아닙니다. 격리 복구에서 로그인, 최근 자료 조회, 새 자료 저장 중 하나라도 실패하면 DNS 전환을 보류하십시오.

Docker 공식 문서도 볼륨을 백업하고 복원하는 방법과 별도의 복구 테스트를 안내합니다. 따라서 이전 작업에서는 백업 파일의 존재, 복원 명령, 복원 뒤 애플리케이션 조회 결과를 한 묶음으로 보관해야 합니다. (docs.docker.com)

세 번째 검수: 비밀값, 인증서와 외부 연결은 준비됐나요?

환경 변수 파일을 복사했다고 끝나지 않습니다. 새 서버에서 실제로 다음 연결을 테스트하십시오.

• 데이터베이스와 캐시 연결
• 저장소 또는 객체 보관소 업로드와 다운로드
• 메일 발송
• 결제나 인증 API 호출
• 작업 큐 등록과 소비
• 저장소에서 이미지 또는 코드를 받는 권한
• 인증서 발급과 갱신에 필요한 도메인 접근

비밀값은 화면 캡처나 평문 로그에 남기지 말고, 변수 이름과 검수 결과만 기록하십시오. 배포 계정은 필요한 저장소와 서버 작업만 수행하도록 제한하고, 관리 포트는 외부에 열지 않는 편이 좋습니다. Compose 구성에는 호스트 접근 권한을 넓히는 설정이 들어갈 수 있으므로, 최종 적용 구성을 직접 검토해야 합니다. (docs.docker.com)

도메인 전환은 다음 순서가 안전합니다.

1. 테스트 도메인 또는 로컬 이름 해석으로 새 노드에 접속합니다.
2. HTTP 응답과 HTTPS 인증서의 대상 이름을 확인합니다.
3. 웹소켓 연결과 프록시 전달 헤더를 확인합니다.
4. 인증서 자동 갱신에 필요한 포트와 권한을 점검합니다.
5. DNS 변경 시각과 예전 노드 유지 종료 시각을 기록합니다.
6. 전파 중에는 새 노드와 예전 노드의 접근 로그를 함께 비교합니다.

네 번째 검수: 백그라운드 작업과 되돌리기를 어떻게 승인하나요?

웹 요청이 정상이어도 예약 작업과 큐 소비자가 이전 노드와 새 노드에서 동시에 실행되면 메일 중복 발송, 같은 작업의 이중 처리, 데이터 충돌이 발생할 수 있습니다. 전환 직전에는 예약 작업과 소비자의 실행 주체를 하나로 정하고, 예전 노드에서 더 이상 새 작업을 집지 않는지 확인하십시오.

트래픽 전환 후에는 다음 사용자 경로를 실제로 실행합니다.

• 로그인과 권한 확인
• 새 자료 작성과 조회
• 파일 업로드와 다운로드
• 비동기 작업 등록과 완료
• 관리자 화면 접근
• 오류 발생 시 알림과 로그 기록

되돌리기는 문서가 아니라 실행 가능한 상태여야 합니다. 예전 서버가 켜져 있고, 필요한 이미지와 설정이 남아 있으며, 데이터 쓰기 경계를 알고 있어야 합니다. 새 노드에서 이미 처리한 주문, 사용자 변경, 큐 작업을 예전 노드로 그대로 되돌릴 수 없는 구조라면, 복귀 전에 데이터 병합 또는 쓰기 중지 계획을 정해야 합니다.

Docker의 재시작 정책은 컨테이너가 종료된 뒤 자동 재시작을 제어하지만, 애플리케이션이 올바른 데이터를 사용한다는 보장은 하지 않습니다. unless-stopped나 on-failure가 설정되어 있어도 데이터베이스 연결 오류가 반복될 수 있으므로, 재시작 결과와 애플리케이션 로그를 함께 보관하십시오. (docs.docker.com)

승인 직전 빠른 판단

다음 조건을 모두 만족하면 DNS 전환을 진행할 수 있습니다.

• 새 노드의 모든 필수 컨테이너가 올바른 이미지로 실행됩니다.
• 재배포와 재시작 뒤에도 서비스 수와 연결 관계가 유지됩니다.
• 데이터베이스 읽기와 쓰기, 데이터 볼륨의 실제 자료 조회가 성공합니다.
• 백업을 격리된 위치에서 복구했습니다.
• 비밀값과 외부 API 권한이 필요한 범위로 제한되어 있습니다.
• 테스트 도메인에서 HTTPS와 웹소켓이 정상입니다.
• 예약 작업과 큐 소비자의 실행 주체가 하나로 정리됐습니다.
• 예전 노드 접속과 복귀 명령을 실제로 확인했습니다.

하나라도 빠졌다면 OpenShip v0.4.7 서버 이전은 기술적으로 끝난 것이 아니라 검수 대기 상태입니다. 운영 서버를 닫는 것보다 실패 지점을 남겨 두고 다시 검증하는 편이 비용이 적습니다.

자주 묻는 내용

OpenShip로 Docker 서버를 옮길 때 데이터가 사라질 수 있나요?

가능합니다. 컨테이너는 다시 만들 수 있지만 데이터 볼륨, 데이터베이스 파일, 업로드 저장소가 별도로 이전되지 않으면 새 컨테이너가 빈 환경에서 시작합니다. 이전 서버와 새 서버의 볼륨 목록을 비교하고, 실제 업무 자료를 일부 읽고 쓴 뒤 재시작 후에도 남아 있는지 확인해야 합니다.

이전 뒤 예전 컨테이너는 멈췄는데 서비스가 계속 열리면 어떻게 해야 하나요?

오래된 컨테이너가 아니라 새 노드의 컨테이너가 요청을 처리하는지 먼저 확인해야 합니다. DNS 캐시, 프록시, 외부 로드 밸런서 또는 예전 서버의 포트가 남아 있을 수 있습니다. 응답 헤더와 접근 기록을 비교하고, 새 노드에서 고유한 확인용 값을 반환한 뒤 트래픽 경로를 확정하십시오.

OpenShip로 서버를 바꿀 때 도메인과 인증서는 어떻게 전환하나요?

공개 전환 전에 테스트 도메인이나 로컬 이름 해석으로 새 노드의 HTTP, HTTPS, 웹소켓을 먼저 확인합니다. 인증서 발급 권한과 자동 갱신 조건도 검수해야 합니다. 이후 DNS 변경 시각과 예전 노드의 서비스 유지 종료 시각을 기록하고, 전파 중에는 양쪽 로그를 함께 확인하는 편이 안전합니다.

데이터베이스와 데이터 볼륨 이전이 끝났는지 어떻게 확인하나요?

파일 개수만 비교해서는 부족합니다. 핵심 테이블 조회, 최근 자료 읽기, 테스트 자료 쓰기, 애플리케이션 재시작 뒤 재조회까지 진행해야 합니다. 백업 작업이 성공했다고 표시되어도 격리된 위치에서 실제 복구를 한 번 수행하고, 복구된 데이터로 애플리케이션이 연결되는지 확인해야 승인할 수 있습니다.

OpenShip 서버 이전이 실패하면 예전 노드로 되돌릴 수 있나요?

되돌릴 수 있지만 사전에 경계를 정해야 합니다. 예전 노드가 아직 실행 가능하고, 새 노드에서 발생한 쓰기 작업을 어떻게 처리할지 정리되어 있어야 합니다. 이전 서버의 주소, 데이터베이스 백업, DNS 변경 전 상태와 복귀 명령을 기록한 뒤 실제 복귀 연습까지 마쳐야 운영 서버를 종료할 수 있습니다.

이번 검수에서 중요한 것은 새 서버가 켜졌는지가 아니라, 실패했을 때 예전 환경과 데이터 경계를 다시 사용할 수 있는지입니다. 기존 서버를 바로 폐기해야 하거나 병렬 검증을 할 공간이 없다면, 현재 환경은 DNS 전환과 복구 테스트를 동시에 수행하기 어렵습니다. 그런 경우에는 임시 독립 노드를 확보해 새 환경을 검증한 뒤 운영 서버를 바꾸는 편이 더 안전합니다.

kvmboot의 도움말 센터에서 원격 운영 환경을 먼저 확인하고, 기존 장비를 유지한 채 별도 노드에서 검수해야 한다면 미국 동부 서버 이용 안내를 비교해 보십시오. 장기 고정 부하가 아니라 이전 기간의 테스트, 복구, 이중 운영이 목적이라면 임시 서버 임대가 전체 장애 비용을 낮추는 선택이 될 수 있습니다.