운영 중 데이터베이스 마이그레이션의 정답은 ‘한 번에 바꾸지 않는 것’입니다. 컬럼 추가, 테이블 구조 변경, 데이터 이전, 인덱스 생성은 모두 SQL 한 줄처럼 보이지만 실제로는 애플리케이션 코드, 배포 순서, 기존 데이터, 백업·복구, 모니터링이 함께 움직입니다. 특히 외주 개발 후 유지보수 단계에 들어간 SaaS, 커머스, 예약, 업무관리 서비스라면 마이그레이션 파일을 작성하는 것보다 먼저 ‘이 변경이 운영 중 구버전 코드와 동시에 살아남을 수 있는가’를 봐야 합니다.
실무 기준으로는 데이터베이스 변경을 스키마 변경 + 애플리케이션 호환성 + 데이터 백필 + 검증 + 복구 시나리오로 분해해야 합니다. 단순히 Laravel Migration, Prisma Migrate, TypeORM migration, Flyway, Liquibase 중 무엇을 쓰느냐보다 중요한 것은 변경을 어떤 순서로 쪼개고, 어느 시점에 되돌릴 수 있으며, 실패했을 때 고객 데이터가 손상되지 않는지입니다.
1. 먼저 판단할 것: 이 마이그레이션은 위험한 변경인가
마이그레이션 위험도는 테이블 수가 아니라 운영 트래픽이 있는 데이터에 쓰기 잠금, 데이터 손실, 코드 불일치가 생기는지로 판단합니다. 초기 MVP에서는 관리자 1명이 쓰는 테이블에 컬럼을 추가하는 정도로 끝날 수 있지만, 결제·주문·예약·고객사별 데이터가 쌓인 뒤에는 같은 작업도 장애 원인이 됩니다.
| 변경 유형 | 대표 예시 | 운영 기준 | 주의할 점 |
|---|---|---|---|
| 낮은 위험 | nullable 컬럼 추가, 작은 코드성 테이블 추가 | 배포 전 SQL 확인, 운영 DB 버전 확인, 코드 하위 호환성 확보 | 기본값·NOT NULL·인덱스를 한 번에 묶지 않는다 |
| 중간 위험 | 인덱스 추가, 기본값 변경, 외래키 추가 | 온라인 생성 가능 여부, 락 시간, 쿼리 플랜, 트래픽 시간대 확인 | 대형 테이블에서는 생성 중 I/O 증가와 지연을 모니터링한다 |
| 높은 위험 | 컬럼명 변경, 타입 변경, 컬럼 삭제, 테이블 분리 | Expand-Backfill-Switch-Contract 방식으로 여러 배포로 분리 | 기존 코드가 새 스키마를 모르면 즉시 오류가 난다 |
| 데이터 위험 | JSON 컬럼을 별도 테이블로 이전, 중복 제거 후 unique 제약 추가 | 배치 처리, 재시도 가능성, 진행률, 검증 쿼리, 중단 재개 기준 필요 | 한 트랜잭션으로 전체 UPDATE를 실행하지 않는다 |
| 사업 위험 | 결제 상태, 예약 상태, 고객사 테넌트 키, 권한 테이블 변경 | 기술 검증 외에 운영팀·CS·정산 기준까지 함께 확인 | 데이터가 맞아도 업무 기준이 틀리면 장애로 본다 |
좋은 마이그레이션 계획은 ‘어떤 SQL을 실행할까’가 아니라 ‘구버전 코드, 신버전 코드, 기존 데이터, 신규 데이터가 함께 존재하는 시간을 어떻게 통제할까’에서 출발합니다.
2. 무중단 변경의 기본 패턴: Expand, Backfill, Switch, Contract
운영 DB에서 가장 피해야 할 방식은 기존 컬럼을 바로 rename 하거나 drop 하는 것입니다. 롤링 배포, 오토스케일링, 큐 워커, 배치 서버가 있는 환경에서는 모든 프로세스가 동시에 새 코드로 바뀌지 않습니다. 어느 순간에는 구버전 코드와 신버전 코드가 같은 DB를 함께 사용합니다. 그래서 파괴적 변경은 다음 네 단계로 나누는 것이 안전합니다.
- Expand: 새 컬럼이나 새 테이블을 기존 구조 옆에 추가합니다. 기존 코드는 계속 동작해야 하므로 old 컬럼은 남겨둡니다.
- Backfill: 기존 데이터를 새 구조로 복사합니다. 한 번에 전체 UPDATE 하지 않고 id 범위, 생성일, 테넌트 단위 등으로 나눕니다.
- Switch: 애플리케이션 읽기·쓰기 경로를 새 구조로 전환합니다. 필요하면 feature flag나 환경변수로 점진 적용합니다.
- Contract: 더 이상 old 구조를 참조하는 코드와 쿼리가 없음을 확인한 뒤, 별도 배포에서 old 컬럼·테이블·코드를 제거합니다.
예를 들어 예약 서비스에서 reservation_status 문자열 컬럼을 정규화된 상태 테이블로 분리한다고 가정해보겠습니다. 안전한 순서는 새 상태 테이블과 reservation_status_id를 먼저 추가하고, 신규 예약 생성 시 두 컬럼을 함께 쓰게 만든 뒤, 기존 예약 데이터를 배치로 채우고, 관리자·고객 화면의 조회를 새 컬럼으로 바꾸고, 마지막으로 충분한 관측 기간 후 old 컬럼을 제거하는 것입니다. 이 과정에서 어느 한 단계가 실패해도 이전 단계가 남아 있으므로 코드 롤백이나 재처리가 가능합니다.
3. 변경 유형별 실행 전략
3-1. 컬럼 추가: nullable부터 시작한다
운영 중 컬럼 추가는 비교적 쉬운 작업으로 여겨지지만 조건이 붙으면 위험도가 올라갑니다. 새 컬럼을 NOT NULL로 추가하면서 기본값을 부여하거나, 동시에 인덱스와 외래키를 붙이면 DB 엔진이 테이블을 다시 쓰거나 장시간 잠금을 잡을 수 있습니다. MySQL 계열은 버전과 스토리지 엔진에 따라 INSTANT, INPLACE, COPY 동작이 달라지고, PostgreSQL도 제약조건 검증과 인덱스 생성 방식에 따라 운영 영향이 달라집니다.
안전한 기본안은 nullable 컬럼 추가 → 애플리케이션이 새 컬럼을 쓰도록 배포 → 기존 데이터 백필 → 검증 → NOT NULL 또는 기본값 제약 추가입니다. 이 순서를 쓰면 구버전 코드가 새 컬럼을 몰라도 문제가 적고, 백필 속도를 조정할 수 있습니다.
3-2. 컬럼명 변경과 타입 변경: 직접 변경보다 새 컬럼 전환
컬럼명 변경은 SQL로는 간단하지만 애플리케이션 입장에서는 API 계약 변경과 비슷합니다. 구버전 코드가 여전히 old 컬럼명을 조회하면 즉시 오류가 발생합니다. 타입 변경도 기존 값이 모두 변환 가능한지, 인덱스와 외래키가 영향을 받는지, ORM 캐시가 새 타입을 인식하는지 확인해야 합니다.
따라서 운영 서비스에서는 ALTER TABLE ... RENAME COLUMN을 바로 실행하기보다 새 컬럼을 추가하고, dual write 또는 변환 함수를 통해 양쪽 값을 일정 기간 맞춘 뒤, 읽기 경로를 옮기는 방식이 안전합니다. API 응답 필드까지 바뀐다면 DB 변경만 볼 것이 아니라 API 버전 관리 가이드에서 다룬 하위 호환성 기준도 함께 점검해야 합니다.
3-3. 데이터 백필: 빠르게 끝내는 것보다 멈췄다 재개할 수 있어야 한다
백필은 운영 DB 마이그레이션에서 가장 과소평가되는 작업입니다. 10만 건까지는 단순 UPDATE로 끝난 경험이 있더라도, 수백만 건 이상이거나 주문·로그·메시지처럼 계속 쓰이는 테이블에서는 전체 UPDATE가 락, WAL/binlog 증가, replica lag, CPU·I/O 상승을 만들 수 있습니다.
- idempotent: 같은 배치가 두 번 실행돼도 결과가 깨지지 않아야 합니다.
- checkpoint: 마지막 처리 id, 처리 건수, 실패 건수를 기록해야 합니다.
- throttle: 배치 크기와 sleep 간격을 조절할 수 있어야 합니다.
- 관측성: rows per second, 오류 수, DB 부하, 지연 쿼리를 볼 수 있어야 합니다.
- 검증: old 값과 new 값의 불일치 건수를 배포 전후로 확인해야 합니다.
GitLab 같은 대형 서비스가 배경 마이그레이션과 post-deployment migration을 분리해 문서화하는 이유도 이 지점에 있습니다. 작은 팀이 같은 수준의 시스템을 모두 만들 필요는 없지만, 최소한 백필을 큐 작업 또는 CLI job으로 분리하고, 중단·재개·진행률 확인이 가능하게 만드는 것이 좋습니다.
3-4. 인덱스 생성: 성능 개선 작업이 장애가 될 수 있다
느린 쿼리를 개선하려고 인덱스를 추가했다가 쓰기 요청이 막히는 사례가 많습니다. PostgreSQL에서는 일반 CREATE INDEX가 쓰기를 막을 수 있으므로 운영 테이블에는 CREATE INDEX CONCURRENTLY 사용을 검토합니다. 다만 이 방식은 더 오래 걸릴 수 있고, 트랜잭션 블록 안에서 실행할 수 없으며, 실패 시 invalid index가 남을 수 있습니다. MySQL도 보조 인덱스 추가는 온라인으로 가능한 경우가 있지만 FULLTEXT, SPATIAL, primary key, 타입 변경 등은 조건이 다릅니다.
실무에서는 인덱스 생성 전 다음을 확인합니다. 첫째, 실제 느린 쿼리와 WHERE, JOIN, ORDER BY 조건이 무엇인지 봅니다. 둘째, 생성 후 쿼리 플랜이 바뀌는지 staging 데이터로 확인합니다. 셋째, 운영에서는 낮은 트래픽 시간대에 실행하고 lock wait, replication lag, CPU, I/O를 봅니다. 넷째, 실패하면 재시도 전에 미완성 인덱스를 정리하는 절차를 문서화합니다.
3-5. 외래키와 unique 제약: 데이터 청소가 먼저다
외래키나 unique 제약은 데이터 품질을 높이지만, 기존 데이터가 이미 규칙을 어기고 있으면 배포 시점에 실패합니다. 특히 외주 개발 초기에는 애플리케이션 코드에서만 검증하고 DB 제약은 느슨하게 둔 경우가 있습니다. 나중에 unique index를 추가하려면 중복 값 제거 기준, 고객 영향, 운영팀 확인 절차가 필요합니다.
권장 순서는 위반 데이터 조회 → 업무 기준으로 정리 → 필요한 임시 인덱스 생성 → 제약 추가 → 애플리케이션 예외 처리 확인입니다. 고객사별 데이터가 섞이는 SaaS라면 unique 기준도 전역인지 테넌트별인지 분명해야 합니다. 이 부분은 다중 테넌시 데이터 모델링 가이드와 함께 검토하는 것이 좋습니다.
4. Laravel Migration과 ORM 도구가 해결하지 못하는 것
Laravel Migration은 팀이 DB 변경 이력을 공유하는 좋은 출발점입니다. php artisan migrate --pretend로 실행 SQL을 확인하고, 여러 서버에서 동시에 마이그레이션이 돌지 않도록 --isolated를 사용할 수 있으며, 운영에서는 --force를 명시해야 합니다. 그러나 이런 기능이 운영 안전성을 자동으로 보장하지는 않습니다.
예를 들어 migrate:rollback은 최근 batch를 되돌리는 데 유용하지만, 이미 새 컬럼에 고객 데이터가 쌓였다면 단순 rollback이 데이터 손실을 만들 수 있습니다. migrate:fresh처럼 테이블을 모두 drop 하는 명령은 로컬 개발과 테스트에서는 편하지만 운영 DB에서는 별도의 보호 장치 없이 접근하지 못하게 해야 합니다. Node 백엔드의 TypeORM, Sequelize, Prisma, Java의 Flyway, Liquibase도 마찬가지입니다. 도구는 변경 순서를 기록하지만, 그 변경이 운영 트래픽에서 안전한지는 사람이 설계해야 합니다.
| 도구·방식 | 잘 맞는 상황 | 운영 주의점 |
|---|---|---|
| Laravel Migration | Laravel 기반 MVP, 관리자, 업무 SaaS의 스키마 이력 관리 | 대형 테이블 인덱스, concurrent index, 온라인 DDL은 raw SQL과 배포 절차를 별도로 검토 |
| Flyway | SQL 중심의 백엔드, Java·Node 등 프레임워크 독립적 배포 | 스크립트 순서와 schema history 관리는 강점이나, DB별 트랜잭션 제한을 확인해야 함 |
| Liquibase | changeset, rollback, 감사 이력을 중시하는 조직 | 자동 rollback이 안 되는 변경은 수동 rollback SQL을 작성하고 검증해야 함 |
| gh-ost, pt-online-schema-change | MySQL 계열 대형 테이블 온라인 변경 | 권한, replica, trigger 또는 binlog 방식, 외래키, unique 변경 위험을 사전 검증해야 함 |
| 커스텀 백필 job | 업무 규칙이 섞인 데이터 이전, 단계적 전환 | 재시도 가능성, 진행률, 중복 실행 안정성, 중단 기준을 직접 구현해야 함 |
5. 배포 순서와 롤백 기준을 먼저 문서화한다
마이그레이션 배포 문서는 길 필요는 없지만 순서는 명확해야 합니다. 특히 외주 개발 후 다른 개발사나 내부 개발자가 이어받는 상황에서는 ‘migration 파일이 있다’는 사실보다 ‘어떤 배포에서 무엇을 먼저 실행해야 하는가’가 더 중요합니다.
- 사전 점검: 운영 DB 종류·버전, 테이블 row 수, 인덱스 현황, slow query, 백업 상태를 확인합니다.
- 리허설: staging 또는 운영과 유사한 복제 데이터에서 실행 시간과 실패 케이스를 확인합니다.
- 백업·복구 준비: 백업 생성 시각, 복구 담당자, 예상 복구 시간, 복구 후 검증 항목을 기록합니다.
- 호환 스키마 배포: nullable 컬럼이나 새 테이블처럼 구버전 코드와 호환되는 변경을 먼저 적용합니다.
- 애플리케이션 배포: 신버전 코드가 old와 new 구조를 함께 처리하도록 배포합니다.
- 백필 실행: 배치 크기, 중단 기준, 진행률, 오류 대응 기준을 두고 실행합니다.
- 검증: row count, checksum 또는 업무별 비교 쿼리로 old/new 데이터가 맞는지 확인합니다.
- 전환: 읽기 경로를 새 구조로 바꾸고 오류율, 응답 시간, 주요 업무 지표를 봅니다.
- 정리: 충분한 관측 기간 후 old 컬럼·코드·인덱스를 별도 배포에서 제거합니다.
롤백은 하나가 아니다
| 상황 | 가능한 대응 | 판단 기준 |
|---|---|---|
| 스키마 추가 후 앱 배포 실패 | 앱 코드만 이전 버전으로 롤백 | 새 스키마가 구버전 코드와 호환되면 DB rollback 불필요 |
| 백필 job 실패 | job 중단 후 수정, checkpoint부터 재개 | 데이터가 중복 처리돼도 안전한 구조인지 확인 |
| 새 읽기 경로 오류 | feature flag off, old 읽기 경로로 복귀 | dual write와 old 데이터 유지 기간이 있어야 가능 |
| 제약조건 추가 실패 | 위반 데이터 정리 후 재시도 | 실패 원인이 데이터인지 잠금인지 구분 |
| 데이터 손상 의심 | 쓰기 중단, 영향 범위 산정, 백업 복구 또는 보정 스크립트 | 복구 시간이 고객 영향보다 작은지, 새로 들어온 데이터 손실을 어떻게 처리할지 판단 |
운영 DB에서 rollback은 단순히 down migration 실행을 뜻하지 않습니다. 오히려 많은 경우에는 되돌리는 것보다 앞으로 고치는 forward fix가 더 안전합니다. 중요한 것은 어느 지점까지 코드 롤백만으로 해결되는지, 어느 지점부터 데이터 보정이 필요한지 미리 정해두는 것입니다.
6. 외주 개발 후 인수인계에서 반드시 받아야 할 DB 문서
서비스를 외주로 만든 뒤 기능 추가를 시작하면 DB 마이그레이션 이력의 품질이 유지보수 비용을 크게 좌우합니다. 저장소에는 migration 파일이 있지만 운영 DB에는 수동으로 적용된 컬럼이 있거나, 반대로 migration 파일은 삭제됐는데 운영 DB에는 흔적이 남아 있는 경우가 있습니다. 이런 상태에서 새 개발사가 기능을 추가하면 배포 때마다 불안정해집니다.
인수인계 시에는 최소한 다음 자료를 받아야 합니다. 이미 산출물 점검 단계라면 외주개발 인수인계 체크리스트와 함께 DB 항목을 별도로 확인하는 것이 좋습니다.
- 현재 운영 DB 기준 ERD 또는 주요 테이블 설명서
- migration 파일 목록과 운영 DB의 적용 상태
- 수동 SQL 실행 이력과 사유
- 주요 테이블의 row 수, 증가 속도, 보관 정책
- 인덱스 목록과 인덱스를 만든 쿼리 목적
- 외래키, unique, NOT NULL 등 제약조건의 업무 의미
- 백업 방식, 보관 기간, 복구 테스트 이력
- 배포 시 migration 실행 위치와 담당자
- 테스트 seed 데이터와 개인정보 마스킹 기준
- 다음 기능 추가 시 따라야 할 migration 작성 규칙
이 문서가 없으면 새 개발팀은 실제 운영 데이터의 의미를 추측하게 됩니다. DB는 코드보다 더 오래 남습니다. 화면은 새로 만들 수 있지만, 고객 데이터의 구조와 이력은 한 번 어긋나면 바로잡는 데 훨씬 많은 시간이 듭니다.
7. 운영 배포 전 체크리스트
| 구분 | 확인 질문 | 완료 기준 |
|---|---|---|
| 변경 분류 | 이 변경은 추가형인가, 파괴형인가, 데이터 이전이 필요한가 | 위험도와 배포 단계가 문서화됨 |
| 호환성 | 구버전 앱이 새 스키마에서 동작하는가 | 롤링 배포 중 mixed version 상태를 설명할 수 있음 |
| SQL 확인 | 실행될 SQL과 락 특성을 확인했는가 | staging에서 dry run 또는 리허설 완료 |
| 백업 | 복구 가능한 백업이 있고 복구 절차를 아는가 | 백업 시각, 담당자, 복구 예상 시간이 기록됨 |
| 백필 | 배치 크기, 재시도, 중단·재개 기준이 있는가 | checkpoint와 진행률 조회 방법이 있음 |
| 검증 | 마이그레이션 성공을 어떤 쿼리로 판단하는가 | row count, 불일치 조회, 업무 검증 쿼리 준비 |
| 모니터링 | 배포 중 어떤 지표를 볼 것인가 | DB CPU, I/O, lock, slow query, 오류율 확인 채널 준비 |
| 롤백 | 실패 시 코드 롤백인지, job 중단인지, 복구인지 구분했는가 | 상황별 의사결정 기준이 문서화됨 |
| 정리 | old 컬럼과 임시 코드는 언제 제거하는가 | Contract 배포 일정과 제거 조건이 있음 |
8. AgentMit이 보는 데이터베이스 마이그레이션의 범위
AgentMit은 DB 마이그레이션을 단순한 개발 작업이나 SQL 작성으로 보지 않습니다. 특히 BizMit 같은 업무 SaaS, 관리자 대시보드, 자동화 기능, AI 연동 서비스, 정부지원사업 MVP 이후의 기능 확장에서는 DB 구조가 곧 운영 프로세스와 연결됩니다. 고객사별 권한, 결제 상태, 신청서 단계, 첨부파일, 정산 데이터, AI 처리 이력은 화면보다 데이터 기준이 먼저 안정되어야 합니다.
그래서 AgentMit이 백엔드 유지보수나 기능 확장을 맡을 때는 migration 파일만 보는 것이 아니라 운영 DB 스키마, Laravel·Node 백엔드 코드와의 호환성, 배포 순서, 백필 스크립트, 검증 쿼리, 백업·복구 기준, 인수인계 문서를 함께 확인합니다. 필요하다면 기존 외주 개발 산출물을 기준 스키마로 재정리하고, 이후 변경부터는 운영 가능한 마이그레이션 규칙을 세웁니다.
이미 서비스가 운영 중이고 기능 추가 때마다 DB 변경이 부담된다면, 먼저 최근 3개월 안에 추가하려는 기능 목록과 관련 테이블을 정리해보는 것이 좋습니다. 이후 AgentMit 제작 문의를 통해 현재 구조를 공유하면, 단순 견적이 아니라 어떤 변경을 쪼개야 하고 어떤 배포 순서가 필요한지부터 검토할 수 있습니다.
참고한 공식 문서와 읽는 방법
이 글은 특정 도구를 무조건 권장하기보다, 운영 중 스키마 변경을 판단하는 기준을 세우기 위해 공식 문서를 참고했습니다. Laravel 문서는 migration 실행·rollback·운영 강제 실행 옵션을 확인하는 데 유용하고, PostgreSQL과 MySQL 문서는 인덱스 생성과 Online DDL의 실제 잠금 특성을 판단할 때 필요합니다. Flyway와 Liquibase는 프레임워크 독립적인 DB 변경 이력 관리 관점에서 참고할 수 있으며, gh-ost와 pt-online-schema-change는 MySQL 대형 테이블 변경을 검토할 때 운영 위험까지 함께 봐야 합니다.
- Laravel Database Migrations: 프레임워크 migration 명령과 운영 옵션 확인
- PostgreSQL CREATE INDEX: concurrent index 생성의 장점과 제한 확인
- MySQL InnoDB Online DDL: 변경 유형별 INSTANT, INPLACE, COPY 동작 확인
- GitLab Database Migration Docs: post-deployment migration과 batched background migration 패턴 참고
- Flyway, Liquibase: 버전 관리형 migration과 rollback 설계 비교
- gh-ost, pt-online-schema-change: MySQL 온라인 스키마 변경 도구의 사용 조건과 위험 요소 확인
FAQ
Q1. 운영 중 컬럼 하나 추가하는 것도 꼭 무중단 마이그레이션으로 해야 하나요?
모든 컬럼 추가가 고위험은 아닙니다. 다만 테이블 크기, DB 엔진과 버전, 기본값 여부, NOT NULL 여부, 인덱스·외래키 동시 추가 여부를 확인해야 합니다. 실무에서는 nullable 컬럼을 먼저 추가하고, 애플리케이션을 호환되게 배포한 뒤, 필요하면 백필과 제약조건 추가를 별도 단계로 나누는 방식이 안전합니다.
Q2. Laravel migration rollback만 잘 작성하면 운영 DB 롤백이 가능한가요?
부분적으로만 가능합니다. 인덱스 추가나 nullable 컬럼 추가처럼 구조만 되돌리면 되는 변경은 rollback이 도움이 됩니다. 하지만 이미 새 컬럼에 데이터가 쓰였거나, 컬럼 삭제·타입 변경처럼 데이터 손실 가능성이 있는 작업은 단순 down 메서드로 안전하게 되돌리기 어렵습니다. 운영에서는 코드 롤백, forward fix, 백업 복구, 데이터 보정 스크립트를 각각 구분해야 합니다.
Q3. 대용량 테이블에 인덱스를 추가할 때 가장 중요한 기준은 무엇인가요?
인덱스 생성 중 쓰기 작업이 막히는지, 생성 시간이 얼마나 걸리는지, 추가 I/O가 서비스 지연을 만들지, 실패 시 invalid 또는 미완성 인덱스가 남는지를 봐야 합니다. PostgreSQL은 CREATE INDEX CONCURRENTLY, MySQL은 Online DDL 또는 gh-ost, pt-online-schema-change 같은 도구를 검토하되, 사전 테스트와 모니터링 기준이 먼저입니다.
Q4. 외주 개발사가 바뀌었는데 기존 DB 마이그레이션 이력이 불분명하면 어떻게 시작해야 하나요?
먼저 운영 DB의 실제 스키마와 저장소의 migration 파일을 대조해야 합니다. 적용된 migration 테이블, 누락된 파일, 수동 변경 흔적, 외래키·인덱스 현황, 주요 테이블 row 수, 백업·복구 절차를 확인한 뒤 기준 스키마를 다시 문서화합니다. 그다음부터 새 변경은 버전 관리된 migration으로만 진행하는 것이 좋습니다.
Q5. 마이그레이션 작업 전 백업만 있으면 충분한가요?
백업은 필수지만 충분조건은 아닙니다. 복구 시간이 서비스 허용 중단 시간 안에 들어오는지, 특정 시점 복구가 가능한지, 복구 후 애플리케이션 버전과 데이터 정합성이 맞는지 테스트해야 합니다. 운영 배포에서는 백업 생성 시각, 복구 담당자, 복구 예상 시간, 롤백 의사결정 기준까지 같이 정리해야 합니다.
