[1편] DB 데이터 이전(Migration) 전략

 

안녕하세요 makeviibe 입니다.

 

과거에 진행한 리뉴얼 프로젝트에서, 기능 개발보다 더 많은 시간을 차지한 부분이 바로 데이터 이전(Migration)이었어요.

겉으로 보면 “DB만 옮기면 되는 거 아닌가요?”라고 생각하기 쉽지만,

실제로는 서비스 안정성과 직결되는 민감한 작업이라서 치밀한 전략이 필요합니다.

 

오늘은 저희가 실무에서 적용하는 데이터 이전 전략을 정리해서 공유할게요.

---

1. 사전 분석(Pre-Migration Analysis)

 

1-1. 데이터 구조 파악

• • 기존 DB 스키마 문서화 (테이블, 컬럼, 인덱스, 제약조건)
  • 데이터 타입 및 제약 조건 분석 (NULL, DEFAULT, FOREIGN KEY 등)
  • 외부 스토리지(이미지, 첨부파일, CDN 경로 등)도 함께 체크해요

 

1-2. 데이터 품질 점검

• • 중복 데이터, 누락 데이터, 잘못된 포맷 확인
  • 삭제 플래그(is_deleted) 데이터 처리 기준 정하기
  • 테스트 환경에서 샘플 쿼리로 통계 확인

 

💡 Tip: 이 단계에서 DB 문서화 도구(예: dbdiagram.io, DBeaver Export)로 ERD를 만들어두면 이후 매핑 설계가 훨씬 수월해져요.

---

2. 매핑 설계(Field Mapping Plan)

 

2-1. 컬럼 매핑 표 작성

 

2-2. 데이터 변환 로직 정의

• • 날짜/시간 포맷 변환
  • ENUM → String / String → ENUM 변환
  • Boolean ↔ Integer 값 매핑 (예: 1 → true)

---

3. Dry Run (부분 테스트 이전)

 

3-1. 샘플 이전

• • 데이터의 1~5% 정도만 테스트 환경에 옮겨서 실행 시간과 오류 발생 여부를 체크해요
  • 인덱스 생성·삭제 타이밍도 테스트해둬야 해요

 

3-2. 자동화 스크립트 점검

• • ETL 툴(Extract → Transform → Load) 사용 여부 결정
  • 단순 구조면 SQL 스크립트로
  • 복잡 변환이면 Python + Pandas, Node.js 등 활용
  • 성공·실패 건수, 실패 원인 등을 로그로 남겨두면 좋아요

 

💡 Tip: Dry Run 로그를 남겨두면 본 이전 때 장애 대응 속도가 훨씬 빨라져요.

---

4. 본 이전(Migration Execution)

 

4-1. Downtime 최소화 전략

• • Dual Write 전략: 일정 기간 신규·구DB에 동시에 쓰기
  • Read-Only 모드: 이전 중에는 데이터 변경을 막아요
  • 배치 처리: 대용량 데이터는 Chunk 단위로 나눠서 이전

 

4-2. 병렬 처리

• • 회원 → 게시글 → 댓글 순으로 참조 관계를 맞춰 순차 이전
  • 독립적인 데이터(로그, 통계)는 병렬로 처리

 

4-3. 이미지·파일 이전

• • 스토리지 Sync (AWS S3 → S3, 로컬 → CDN)
  • 이미지 경로 업데이트 스크립트 실행

---

5. 검증 & QA(Post-Migration Validation)

 

5-1. 샘플링 검증

• • 회원 수, 게시글 수, 거래 건수 등 총합 비교
  • 랜덤 샘플 100~1000건을 뽑아 데이터가 일치하는지 확인

 

5-2. 기능 테스트

• • 로그인, 결제, 검색 등 주요 기능이 정상 동작하는지 확인
  • 관리자 페이지 통계도 비교해요

 

💡 Tip: QA 팀뿐만 아니라 실제 운영팀에도 검증을 부탁하면 누락된 케이스를 빨리 찾을 수 있어요.

---

 

6. 롤백 플랜(Rollback Plan)

• • 이전 직전 상태로 복원할 백업 파일을 꼭 준비해둬요
  • 복원 스크립트도 사전에 테스트해야 해요
  • 롤백 시 서비스 중단을 최소화하는 시나리오를 작성해두면 좋아요

---

🧭 마무리

 

데이터 이전은 개발 일정에서 가장 과소평가되기 쉬운 작업이지만, 실제로는 프로젝트 성공에 직접적인 영향을 줘요.

저희는 프로젝트마다 사전 분석 → 매핑 설계 → Dry Run → 본 이전 → 검증 → 롤백 플랜 6단계를 표준 프로세스로 삼고 있어요.

 

이 방식 덕분에 리뉴얼 이후 데이터 오류로 인한 장애를 거의 0에 가깝게 유지할 수 있었어요.