[OpenStack] OpenStack 환경에서 프로젝트 테넌트 마이그레이션 성공 사례

OpenStack 테넌트 마이그레이션은 이름만 보면 프로젝트 소유자만 바꾸는 일처럼 들리지만, 실제 운영에서는 그렇게 움직이지 않습니다. 제가 현장에서 여러 번 겪어보니 이 작업의 본질은 프로젝트를 옮기는 것이 아니라, Nova, Neutron, Cinder, Keystone에 흩어진 소유권과 의존 관계를 안전하게 다시 조립하는 것이었습니다. 같은 서버라도 image-backed인지 volume-backed인지에 따라 절차가 갈리고, 포트 하나에 allowed address pairs가 묶여 있으면 네트워크 검증 포인트가 완전히 달라지죠.

이번 글은 이론 설명보다 제가 실제로 운영/테스트 환경에서 실패를 줄이기 위해 어떤 판단 순서로 움직였는지에 초점을 맞췄습니다. 핵심은 세 가지였습니다. 첫째, DB 직접 수정으로 project_id를 바꾸지 않는다. 둘째, 리소스 존재 확인과 서비스 정상 확인을 분리한다. 셋째, 서버 단위가 아니라 종속성 단위로 이전 계획을 짠다. 이 기준만 잡아도 OpenStack 이전 작업의 절반은 정리됩니다.

기존 프로젝트에서 새 프로젝트로 컴퓨트, 네트워크, 스토리지, 권한이 어떻게 이동하는지 보여주는 개요 이미지입니다.

1. 왜 프로젝트 테넌트 마이그레이션이 생각보다 어렵나

실무에서 어려운 이유는 단순합니다. 프로젝트라는 이름 아래에 있는 리소스들이 한 시스템에서 일관되게 관리되지 않기 때문입니다. Nova는 서버와 attach 정보를 보고, Neutron은 포트와 보안 그룹, 라우터를 보고, Cinder는 볼륨 상태와 transfer 가능 여부를 따로 판단합니다. 그래서 화면상으로는 하나의 프로젝트처럼 보여도, 이전할 때는 서비스별 제약을 따로 통과해야 합니다.

• 인스턴스는 생성 시점의 flavor, image, port, volume 연결 정보를 함께 봐야 합니다.
• 포트는 fixed IP, security group, allowed address pairs, binding 정보가 남아 있으면 단순 재생성으로 끝나지 않습니다.
• 볼륨은 in-use, available, snapshot 종속 여부에 따라 transfer 가능 조건이 갈립니다.
• 권한은 사용자 추가만으로 끝나지 않고 role assignment와 quota가 실제 동작 조건을 결정합니다.

운영자가 많이 빠지는 함정은 여기입니다. “서버 목록이 보이니 다 옮길 수 있겠지”라고 생각하는 순간, 이미 계획이 서버 중심으로 기울어집니다. 하지만 실제 장애는 대부분 서버가 아니라 부팅 디스크, 추가 볼륨, 플로팅 IP, 포트 정책에서 터지곤 합니다. 제가 지금은 항상 먼저 묻는 질문도 이것뿐입니다. “이 서버는 무엇에 기대어 살아 있나?” 이걸 안 보고 진행하면, 마지막 검증에서 접속 불가나 데이터 불일치로 반드시 돌아오더라고요.

2. OpenStack 테넌트와 프로젝트 개념, 헷갈리면 여기서 정리

문서나 팀 대화에서 Tenant와 Project가 섞여 나오는 건 흔합니다. 다만 OpenStack 테넌트 마이그레이션 문서에서는 표현을 통일해야 작업 범위가 흐려지지 않습니다. 저는 실무 문서에서 무조건 old project / new project로 적습니다. 그래야 권한 이전인지, 리소스 재배치인지, 네트워크 재설계인지 문장만 봐도 구분이 됩니다.

이 구분이 중요한 이유는 명확합니다. 같은 프로젝트 이전이라고 해도, 동일 Domain 안에서 새 Project를 만드는 경우와 도메인 분리까지 포함되는 경우는 사용자 재할당과 인증 정책 검토 범위가 달라집니다. 저는 작업 요청서가 들어오면 가장 먼저 domain_id를 확인해요. 이유는 간단합니다. 프로젝트만 옮기는 줄 알았는데 실제론 사용자 소속 재설계까지 포함된 경우가 생각보다 많기 때문이죠.

3. OpenStack 이전 마이그레이션 전 체크리스트: 여기서 반은 끝납니다

제 경험상 성공률을 가르는 건 복사 명령이 아니라 사전 인벤토리의 밀도입니다. 단순 목록 추출이 아니라, 서버별로 어떤 볼륨이 붙어 있고 어떤 포트를 쓰는지, 그 포트에 어떤 보안 그룹과 IP가 걸려 있는지까지 묶어서 봐야 합니다. 저는 서버를 기준으로 보지 않고 서비스 단위 묶음으로 봅니다. 예를 들면 “웹 2대 + 공통 SG + 외부 FIP 1개 + DB 볼륨 2개”처럼요. 이렇게 봐야 컷오버 시점에 빠지는 자원이 줄어듭니다.

아래 명령은 제가 실제로 가장 먼저 실행하는 인벤토리 묶음입니다. 중요한 건 결과를 그냥 보는 게 아니라 파일로 남겨서 old project와 new project를 나란히 비교하는 겁니다.

# 기본 컨텍스트 확인
openstack token issue
openstack project show OLD_PROJECT -f yaml
openstack quota show OLD_PROJECT -f yaml

# 컴퓨트 / 스토리지 / 네트워크 인벤토리
openstack server list --project OLD_PROJECT --long -f yaml
openstack volume list --project OLD_PROJECT -f yaml
openstack volume snapshot list --project OLD_PROJECT -f yaml
openstack port list --project OLD_PROJECT -f yaml
openstack router list --project OLD_PROJECT -f yaml
openstack floating ip list --project OLD_PROJECT -f yaml
openstack security group list --project OLD_PROJECT -f yaml
openstack role assignment list --project OLD_PROJECT --names -f yaml

여기서 제가 꼭 확인하는 항목은 아래입니다.

• 서버가 image-backed인지 volume-backed인지
• 루트 디스크 외에 추가 데이터 볼륨이 있는지
• 포트에 고정 IP, allowed address pairs, custom DNS name이 있는지
• 보안 그룹이 이름만 같은 기본 그룹인지, 룰이 커스텀인지
• 플로팅 IP를 그대로 재사용해야 하는지, DNS 전환으로 대체 가능한지
• quota가 현재 사용량보다 낮아 새 프로젝트에서 생성 실패가 날 여지가 있는지

운영에서 자주 놓치는 것도 거의 정해져 있습니다. 추가 NIC, 부팅 볼륨 여부, 라우터 외부 게이트웨이, 모니터링 에이전트 재등록입니다. Horizon 화면만 보고 체크하면 빠지고, CLI로만 봐도 관계성이 안 보일 때가 있어요. 저는 그래서 서버 한 대를 샘플로 골라 server show, port show, volume show를 연결해서 한 번 끝까지 추적합니다. 이 한 대에서 구조를 파악하면 나머지 서버군도 비슷한 패턴으로 묶입니다.

# 샘플 서버 1대의 의존성 추적
openstack server show VM01 -f yaml
openstack server volume list VM01 -f yaml
openstack port list --server VM01 -f yaml

# 특정 포트 상세
openstack port show PORT_ID -f yaml

# 특정 볼륨 상세
openstack volume show VOLUME_ID -f yaml

이 단계에서 제 판단 기준은 분명합니다. 구조를 설명할 수 없으면 마이그레이션을 시작하지 않습니다. 나중에 문제가 생겼을 때 복구도 결국 구조를 이해한 사람만 할 수 있기 때문입니다.

4. 제가 선택한 방식: “새 프로젝트 생성 후 자원 재구성”

제가 운영 환경에서 가장 안정적으로 가져간 방식은 늘 비슷했습니다. 새 프로젝트를 생성하고, 권한과 quota를 먼저 맞춘 뒤, 리소스를 서비스별 지원 절차로 옮긴다. 작업량은 확실히 많습니다. 대신 롤백 지점이 명확하고, 감사 대응 문서가 남고, 중간 실패가 나도 어느 레이어에서 멈췄는지 추적하기 쉽습니다.

제가 이 방식으로 굳어진 이유는 장애 처리 때문입니다. 문제는 항상 이전 도중이 아니라 이전 직후 첫 장애에서 드러나거든요. 그때 중요한 건 “어떻게 옮겼는가”를 설명할 수 있는가입니다. 새 프로젝트 재구성 방식은 이 질문에 답하기 쉽습니다. 반대로 편법은 옮기는 순간은 빨라도, 장애 원인이 리소스 참조 꼬임인지 애플리케이션 문제인지 분리하기가 어렵습니다.

5. 실전 구현: 단계별 OpenStack 이전 절차

5-1. 신규 프로젝트와 권한 준비

저는 프로젝트를 만든 직후 바로 사용자부터 붙이지 않습니다. 먼저 quota를 설계합니다. 이유는 단순합니다. 권한을 준 다음 사용자가 접속해 리소스를 만들기 시작하면, 중간에 quota 수정이 운영 이슈로 변하기 때문입니다. 특히 ports, gigabytes, security-group-rules는 자주 빠집니다.

# 신규 프로젝트 생성
openstack project create NEW_PROJECT

# 현재 사용량을 보고 quota를 맞춤
openstack quota show OLD_PROJECT -f yaml

# 예시: 인스턴스/코어/RAM/볼륨/용량/포트 기준으로 선반영
openstack quota set \
  --instances 20 \
  --cores 40 \
  --ram 102400 \
  --volumes 20 \
  --gigabytes 2048 \
  --ports 100 \
  --security-groups 20 \
  --secgroup-rules 200 \
  NEW_PROJECT

# 사용자 및 관리자 역할 부여
openstack role assignment create --user USER_NAME --project NEW_PROJECT member
openstack role assignment create --user ADMIN_USER --project NEW_PROJECT admin

# 결과 재확인
openstack role assignment list --project NEW_PROJECT --names -f yaml
openstack quota show NEW_PROJECT -f yaml

여기서 제 기준은 간단합니다. 기존 사용량보다 같거나 높게 잡되, 무작정 크게 주진 않습니다. 운영팀이 나중에 프로젝트 격리 정책을 유지하려면 새 프로젝트 quota도 결국 **프로젝트 관리**의 중요한 대상이 되거든요. 특히 old project가 이미 quota 한계 근처까지 써온 상태라면, OpenStack 이전 전에 먼저 증설 승인 절차를 붙이는 편이 낫습니다. 새 프로젝트에서 서버 생성이 중간에 막히면 마이그레이션 창이 길어지기 마련이죠.

5-2. 보안 그룹과 네트워크 설계 복제

네트워크는 “같이 보이게 만드는 것”과 “같이 동작하게 만드는 것”이 다릅니다. 저는 기존 설정을 그대로 베끼기보다, 실제 통신에 필요한 정책만 재생성하는 방식을 선호합니다. 이유는 오래된 프로젝트일수록 쓰지 않는 보안 그룹 룰이 쌓여 있고, 그 쓰레기 규칙까지 같이 복제하면 새 프로젝트의 위험 면적도 그대로 옮겨가기 때문입니다.

# 기존 보안 그룹과 룰 확인
openstack security group list --project OLD_PROJECT -f yaml
openstack security group rule list SECURITY_GROUP_ID -f yaml

# 신규 프로젝트에 보안 그룹 생성
openstack security group create --project NEW_PROJECT web-sg
openstack security group create --project NEW_PROJECT app-sg

# 인바운드 규칙 예시
openstack security group rule create --protocol tcp --dst-port 22 web-sg
openstack security group rule create --protocol tcp --dst-port 80 web-sg
openstack security group rule create --protocol tcp --dst-port 443 web-sg

# remote group 참조 예시
openstack security group rule create \
  --protocol tcp \
  --dst-port 8080 \
  --remote-group app-sg \
  web-sg

여기서 흔한 실수는 --dst-port만 보고 규칙을 복사하는 겁니다. 실제로는 아래 항목까지 같이 봐야 합니다.

• remote_ip_prefix가 특정 관리망만 허용하는지
• remote_group_id로 내부 애플리케이션 간 통신을 열어뒀는지
• IPv4만 있는지, IPv6 규칙도 필요한지
• default security group에 기대는 통신이 있었는지

네트워크 재구성에서 제 원칙은 이렇습니다. 같은 이름을 만드는 게 목적이 아니라 같은 패킷 흐름을 재현하는 게 목적입니다. 그래서 저는 이전 후 검증 항목도 “보안 그룹이 붙었는가”가 아니라 “애플리케이션 포트가 실제로 열렸는가”로 잡습니다.

기존 프로젝트의 네트워크 정책을 새 프로젝트에 재구성하는 과정과 주요 확인 포인트를 보여주는 이미지입니다.

5-3. 인스턴스 이전: 이미지 기반인지 볼륨 기반인지 먼저 구분

여기서부터는 작업 방식이 분기됩니다. 저는 서버를 볼 때 이름보다 먼저 루트 디스크 타입을 봅니다. 이유는 이전 시간, 다운타임, 데이터 일관성, 검증 방식이 모두 여기서 달라지기 때문입니다.

• 이미지 기반(image-backed): 무상태 웹 서버, 배치 서버처럼 재생성이 쉬운 경우에 적합합니다.
• 볼륨 기반(volume-backed): 데이터가 붙어 있거나 루트 디스크 자체를 보존해야 하는 경우에 적합합니다.

이미지 기반이라면 절차는 비교적 단순합니다. 다만 저는 스냅샷 전에 최소한 서비스 쓰기 작업을 멈추거나, 애플리케이션 레벨 flush 시점을 맞춥니다. 이유는 OpenStack 스냅샷이 애플리케이션 일관성까지 보장해 주는 건 아니기 때문입니다.

# 기존 프로젝트에서 서버 스냅샷 생성
openstack server image create --name vm01-migrate-snap VM01

# 이미지 확인
openstack image list --private -f yaml
openstack image show vm01-migrate-snap -f yaml

# 새 프로젝트에서 인스턴스 재생성
openstack server create \
  --flavor m1.medium \
  --image vm01-migrate-snap \
  --network PRIVATE_NET \
  --security-group web-sg \
  vm01-new

# 부팅 후 상태 확인
openstack server show vm01-new -f yaml

하지만 stateful 서버는 다르게 접근합니다. DB, 큐, 파일 업로드 서버 같은 워크로드는 OS가 뜨는지보다 애플리케이션 데이터가 일관되게 살아 있는지가 더 중요합니다. 이런 경우 저는 이미지 기반을 우선순위에서 내리고, 볼륨 중심 이전이나 애플리케이션 레벨 백업/복원을 우선 검토합니다. 실제로 서버는 잘 떠도 DB recovery가 길어지거나 서비스가 dirty state로 시작되는 경우가 더 까다로웠습니다.

5-4. Cinder 볼륨 이전: transfer 기능 활용

Cinder transfer는 제대로 쓰면 깔끔합니다. 대신 조건을 만족해야 합니다. 제가 현장에서 가장 많이 본 실패는 detach가 끝나지 않았는데 운영자가 다음 단계로 넘어가는 경우였습니다. CLI 출력은 금방 끝난 것처럼 보여도, 백엔드 스토리지 반영이 늦으면 attachments가 남아 있는 상태가 있습니다. 저는 이럴 때 절대 감으로 넘기지 않고 volume show를 기준으로 판단합니다.

# 1) 인스턴스에서 볼륨 분리
openstack server remove volume VM01 DATA_VOLUME

# 2) 상태 확인: status=available, attachments=[] 이어야 다음 단계 진행
openstack volume show DATA_VOLUME -f yaml

# 3) transfer request 생성
openstack volume transfer request create DATA_VOLUME -f yaml

# 4) 출력값에서 id와 auth_key 확보 후 새 프로젝트에서 수락
openstack volume transfer request accept \
  --auth-key TRANSFER_AUTH_KEY \
  TRANSFER_REQUEST_ID

# 5) 새 프로젝트 인스턴스에 재연결
openstack server add volume VM01_NEW DATA_VOLUME

# 6) attach 결과 재확인
openstack server volume list VM01_NEW -f yaml
openstack volume show DATA_VOLUME -f yaml

제가 transfer를 쓸 때 지키는 기준은 분명합니다.

• status=available가 아니면 멈춥니다.
• attachments 필드가 비지 않았으면 detach가 완전히 끝난 게 아닙니다.
• snapshot 종속이 남아 있으면 먼저 관계를 확인합니다.
• 운영 중 데이터 볼륨이라면 OS 내부 unmount 또는 애플리케이션 정지 절차를 작업서에 반드시 넣습니다.

여기서 성패를 가르는 건 명령어 자체가 아니라 정지 창을 얼마나 잘 설계했는가입니다. 다운타임을 줄이겠다고 detach 직전까지 쓰기 트래픽을 열어두면, 이전은 끝나도 검증에서 파일시스템 체크나 애플리케이션 복구 시간이 길어지기 마련이죠. 제 경험상 데이터 서버는 짧은 이전보다 예측 가능한 일관성이 더 중요했습니다.

5-5. 플로팅 IP와 포트 처리

플로팅 IP는 환경 정책에 따라 이전 난이도가 크게 달라집니다. 어떤 환경은 같은 외부 네트워크 풀을 프로젝트 간 공유하지만, 어떤 환경은 프로젝트 소유 자원으로 강하게 묶여 있어서 재사용이 불가능합니다. 저는 그래서 제일 먼저 IP 재사용이 필수인지, DNS cutover로 충분한지를 사업 영향 기준으로 나눕니다.

포트는 더 까다롭습니다. 이름과 fixed IP만 같아도 같다고 보면 안 됩니다. 아래 항목이 남아 있으면 새 프로젝트에서 동일한 동작이 깨질 수 있습니다.

• allowed_address_pairs
• port_security_enabled
• custom DNS name 또는 extra DHCP option
• 다중 NIC 구성과 각 NIC별 라우팅 기대값

제가 실제로는 이렇게 판단합니다. 외부 공개 서비스면 플로팅 IP 정책 확인을 먼저 하고, 내부 연계가 많은 시스템이면 포트 상세와 라우팅 설계를 먼저 봅니다. 이유는 외부 IP는 우회 수단이 있어도, 내부 IP 충돌과 라우팅 문제는 이전 완료 후 장애로 더 오래 남기 때문입니다.

6. 실제로 겪은 문제와 해결 방법

현장에선 실패 원인이 늘 비슷한 곳에서 나옵니다. 중요한 건 증상만 적지 말고, 왜 그런 상태가 됐는지까지 작업 문서에 남기는 겁니다. 그래야 다음 이전에서 같은 실수를 줄일 수 있습니다.

문제 1. 볼륨 transfer가 실패함

증상은 transfer request create 실패, 또는 볼륨이 계속 in-use로 남는 형태가 많았습니다. 표면 원인은 detach 실패처럼 보여도, 근본 원인은 대개 리소스 상태 전이를 기다리지 않고 다음 단계로 넘어간 것이었습니다.

• 원인 1: 하이퍼바이저 또는 백엔드 스토리지에서 detach 반영이 늦음
• 원인 2: 게스트 OS에서 I/O가 남아 있어 상태 전이가 지연됨
• 원인 3: snapshot 또는 다중 attach 의존성이 남아 있음

저는 이럴 때 volume show 출력에서 status, attachments, multiattach 항목을 먼저 봅니다. 운영자가 놓치기 쉬운 포인트는 CLI 명령 성공과 상태 전이 완료가 같은 뜻이 아니라는 점이에요.

문제 2. 새 프로젝트에서 서버는 떴는데 통신이 안 됨

이건 정말 흔합니다. 서버 상태가 ACTIVE라고 해서 네트워크까지 정상이라는 뜻은 아닙니다. 제 경험상 근본 원인은 네 가지로 압축됐습니다.

• 보안 그룹 룰은 복제했지만 remote group 참조를 빠뜨림
• 포트는 붙었지만 기대하던 네트워크 세그먼트가 아님
• 라우터 외부 게이트웨이 또는 내부 라우팅이 재구성되지 않음
• 기존 포트의 allowed address pairs가 누락됨

openstack server show VM01_NEW -f yaml
openstack port list --server VM01_NEW -f yaml
openstack port show PORT_ID -f yaml
openstack security group rule list web-sg -f yaml
openstack router list -f yaml
openstack router show ROUTER_NAME -f yaml

이때 저는 “SSH가 안 된다”를 진단 기준으로 삼지 않습니다. 패킷이 어디서 끊기는가를 봅니다. 콘솔 접속은 되는데 외부 접속만 안 되면 Neutron 쪽, 애플리케이션 포트만 안 열리면 security group 또는 OS 방화벽 쪽, 내부 서비스 간 통신만 실패하면 라우팅이나 remote group 참조 쪽일 가능성이 큽니다.

문제 3. 이미지로 옮겼더니 애플리케이션 상태가 이상함

이 경우도 겉으로는 이미지 이관 실패처럼 보이지만, 실제로는 워크로드 성격에 맞지 않는 이전 방식을 선택한 것이 근본 원인인 경우가 많았어요. 특히 DB, 메시지 큐, 검색 엔진처럼 디스크 쓰기 타이밍에 민감한 시스템은 이미지 스냅샷이 편해 보여도 복구 시간이 더 길어질 수 있습니다.

• 무상태 웹 서버: 이미지 기반 이전이 대체로 효율적이었습니다.
• 상태 저장 DB 서버: 볼륨 일관성 확보 후 이전 또는 애플리케이션 레벨 백업/복원이 더 안전했습니다.
• 복잡한 미들웨어: 서버 이전보다 서비스 재배포가 낫다는 결론이 나온 경우도 있었고요.

제가 지금도 지키는 기준은 분명합니다. 부팅 성공이 아니라 업무 정상성을 기준으로 이전 방식을 고른다. 이 한 줄이 작업 방식을 가장 많이 바꿉니다.

볼륨 상태 확인, 포트 점검, 보안 그룹 검토 등 실제 장애 분석 흐름을 시각화한 이미지입니다.

7. 검증과 결과 확인: 여기서 끝내면 안 됩니다

마이그레이션은 리소스가 생성됐다고 끝나지 않습니다. 제가 운영 검증에서 가장 강조하는 건 리소스 확인과 서비스 확인을 분리하는 겁니다. OpenStack CLI는 인프라 상태를 보여주지만, 사용자가 느끼는 정상 여부는 애플리케이션 경로에서 결정됩니다.

1. 사용자 계정으로 Horizon 또는 CLI 로그인 가능 여부
2. 인스턴스가 ACTIVE이고 기대한 flavor, image, attached volume 구성이 맞는지
3. 볼륨이 붙어 있을 뿐 아니라 게스트 OS에서 실제 장치와 파일시스템으로 인식되는지
4. SSH 또는 서비스 포트 접근이 가능한지
5. 서버 간 내부 통신이 기대 경로로 흐르는지
6. 백업, 모니터링, 보안 에이전트가 새 프로젝트 기준으로 재등록됐는지

# 신규 프로젝트 기준 검증
openstack token issue
openstack server list -f yaml
openstack volume list -f yaml
openstack port list -f yaml
openstack floating ip list -f yaml

# 인스턴스 내부 검증 예시
ip addr
ip route
lsblk
mount
systemctl --failed

이 단계에서 제가 완료 판정을 내리는 기준은 아주 보수적입니다.

• ACTIVE여도 네트워크 미검증이면 미완료입니다.
• in-use여도 OS에서 장치가 안 보이면 미완료입니다.
• 플로팅 IP가 붙어 있어도 DNS 또는 외부 방화벽 반영 전이면 미완료입니다.
• 모니터링이 복구되지 않았으면 운영 전환 완료로 보지 않습니다.

실무에서는 이 마지막 한 끗이 중요합니다. 이전 직후에는 보통 운영팀이 안심하고 싶어서 “서버 떴다”에 집중합니다. 그런데 실제 장애는 그 다음날 백업 실패, 모니터링 누락, 로그 수집 누락으로 드러나는 경우가 많았거든요. 그래서 저는 항상 검증 항목에 인프라 레벨과 운영 레벨을 나눠 넣는 편입니다.

새 프로젝트에서 리소스 상태와 서비스 정상 여부를 확인하는 검증 결과 화면을 표현한 이미지입니다.

8. 이번 작업에서 얻은 교훈과 추천 시나리오

이번 OpenStack 테넌트 마이그레이션 사례를 다시 정리해보면, 핵심은 기술 스택을 많이 아는가보다 어떤 자원을 어느 경계에서 다시 묶을지 판단하는 능력이었습니다. 이런 복합적인 **클라우드 마이그레이션** 과정에서 저는 지금도 프로젝트 이전 요청이 오면 먼저 세 가지부터 고릅니다. 워크로드가 stateless인지 stateful인지, 플로팅 IP 유지가 필수인지, 네트워크 정책이 단순한지 복잡한지. 이 세 축만 정리해도 절차가 거의 결정됩니다.

• 테스트 환경이라면: 이미지 스냅샷 기반 재배포가 빠르고 관리가 쉽습니다. 단, 검증 범위는 OS 부팅이 아니라 서비스 기동까지 잡으셔야 합니다.
• 운영 환경의 데이터 서버라면: 볼륨 transfer 또는 애플리케이션 레벨 백업/복원이 더 안전합니다. 다운타임을 줄이는 것보다 데이터 일관성을 우선으로 두시는 편이 **더 안전하더라고요.**
• 네트워크 정책이 복잡한 환경이라면: 포트와 보안 그룹을 재생성하되, old project의 패킷 흐름을 먼저 문서화하고 들어가셔야 합니다. 이름 복제가 아니라 통신 재현이 목적입니다.
• 감사 대응이나 변경 이력 관리가 중요한 조직이라면: 새 프로젝트 생성 후 권한, quota, 네트워크, 스토리지를 순차적으로 재구성하는 방식이 가장 **깔끔했고요.**

제가 실제로는 이렇게 결론 냅니다. 빠른 이전이 목표면 이미지 기반, 데이터 무결성이 목표면 볼륨 중심, 장애 회피와 추적 가능성이 목표면 새 프로젝트 재구성입니다. 반대로 DB 직접 수정은 작업 시간은 줄여도 운영 리스크는 크게 키우는 선택이라 지금도 **절대 권하지 않습니다.**

한 번 해보면 느끼실 겁니다. 프로젝트를 옮긴다기보다, 서비스 관계를 다시 엮는 작업에 가깝습니다. 그래서 저는 늘 마지막에 이렇게 체크합니다. “리소스는 옮겨졌는가?”가 아니라 “사용자는 전과 같은 방식으로 서비스를 쓸 수 있는가?” 이 질문에 예라고 답할 수 있으면, 그때가 진짜 마이그레이션 완료 시점입니다.

다음 단계가 남아 있다면 제 추천은 분명합니다. 먼저 1대 샘플 서버로 전체 절차를 끝까지 검증하고, 그 결과를 표준 작업서로 만든 뒤 나머지를 확장하세요. OpenStack 이전은 명령어보다 순서가 중요하고, 순서보다 기준이 더 중요했습니다. 다른 OpenStack 관련 **프로젝트 관리** 팁이나 **클라우드 마이그레이션** 성공 사례가 궁금하시다면, 저희 블로그의 다른 글들도 참고해 보세요.

이미지 기반, 볼륨 기반, 네트워크 재구성 방식 중 어떤 상황에서 무엇을 선택할지 요약한 이미지입니다.

FAQ

프로젝트 이름만 바꾸면 되는 경우도 있나요?

이름 변경과 실제 자원 이전은 별개입니다. 권한 분리, 네트워크 정책 분리, quota 분리가 목적이라면 새 프로젝트를 만들고 리소스를 서비스별 절차로 재구성하는 편이 안전합니다.

운영 중단 없이 완전 이전이 가능한가요?

stateless 서비스는 비교적 유연하지만, stateful 서비스는 디스크 일관성 확보가 더 중요합니다. 제 기준으로는 “중단 없는 이전”보다 “예측 가능한 검증 가능한 이전”이 우선입니다.

가장 먼저 확인해야 할 한 가지는 뭔가요?

인스턴스가 image-backed인지 volume-backed인지입니다. 이 구분 하나가 스냅샷 전략, 다운타임 길이, 검증 방식, 실패 모드를 모두 바꿉니다.