DB 데이터이관시 테이블을 수정하는 방식? 신규 생성 방식?

질문

사이트 고도화 프로젝트에서 DB 데이터이관을 할때 컬럼변경이나 테이블 변경이 많은 경우 테이블을 수정하는 방식이 아닌 전체 테이블을 지우로 새로 생성하는 방법을 사용하나요?

 

사이트 고도화 프로젝트처럼 구조 변화가 큰(Major Change) 경우, 기존 테이블을 ALTER TABLE로 수정하기보다는 새로운 구조의 테이블을 생성(Create)하고 데이터를 부어넣는 방식을 훨씬 더 선호합니다.

그 이유와 구체적인 실행 전략을 정리해 드릴게요.

---

1. 왜 "새로 만들기" 방식을 사용할까요?

기존 테이블을 수정하는 방식은 데이터가 많을수록 리스크가 크고 제약이 많기 때문입니다.

• 정교한 데이터 매핑: 컬럼이 합쳐지거나(Merge), 쪼개지는(Split) 경우 단순 수정으로는 불가능합니다. 새로운 테이블에 정제된 데이터를 넣는 것이 훨씬 깔끔합니다.
• 서비스 다운타임 최소화: 운영 중인 테이블을 수정하면 Lock이 걸려 서비스가 멈출 수 있습니다. 신규 테이블(New_Table)을 미리 만들어 데이터를 다 옮겨두고, 오픈 직전에 이름만 바꾸는(Rename) 방식이 안전합니다.
• 성능 최적화: 테이블을 새로 만들면 데이터가 물리적으로 재정렬되어 **단편화(Fragmentation)**가 제거되고 조회 성능이 좋아집니다.
• 롤백(Rollback) 용이성: 신규 테이블에 문제가 생기면 그냥 삭제하고 다시 하면 되지만, 운영 테이블을 수정하다 꼬이면 복구가 매우 힘듭니다.

---

2. 실무에서 사용하는 "Shadow Table" 이관 전략

실제 대규모 프로젝트에서는 다음과 같은 순서로 진행합니다.

1. 신규 테이블 생성 (Shadow Table): 설계된 최신 구조로 TB_USER_NEW 같은 임시 테이블을 만듭니다.
2. 데이터 변환 및 이관 (ETL): 기존 TB_USER에서 데이터를 읽어와 로직(스냅샷 생성, 타입 변경 등)을 거쳐 TB_USER_NEW에 삽입합니다.
3. 검증: 데이터 건수와 값이 맞는지 확인합니다.
4. 전환 (Switching): 운영 점검 시간에 테이블 이름을 바꿉니다.
   • TB_USER → TB_USER_OLD (백업용)
   • TB_USER_NEW → TB_USER (실서비스 투입)

---

3. 테이블 변경이 많을 때 스크립트 작성 팁

컬럼 변경이 많다면 단순 INSERT INTO ... SELECT 만으로는 부족할 수 있습니다. 이때는 다음과 같은 처리가 스크립트에 포함되어야 합니다.

A. 데이터 정제 (Data Cleansing)

기존에 NULL이었던 컬럼이 신규 설계에서 NOT NULL이 되었다면, 기본값(Default)을 채워주는 로직이 필요합니다.

SQL

 

-- 예: 기존에 없던 '신청당시부서명'을 이력에서 찾아 채우기
INSERT INTO NEW_REQ_TABLE (REQ_ID, DEPT_NAME)
SELECT a.REQ_ID, ISNULL(b.DEPT_NAME, '소속없음')
FROM OLD_REQ_TABLE a
LEFT JOIN DEPT_HISTORY b ON a.DEPT_ID = b.DEPT_ID AND a.REQ_DATE BETWEEN b.START_DATE AND b.END_DATE;

B. 제약조건(Constraint) 관리

신규 테이블을 만들 때는 인덱스(Index)나 외래키(FK)를 일단 빼고 생성하세요. 데이터를 다 넣은 뒤에 인덱스를 생성해야 이관 속도가 10배 이상 빠릅니다.

C. 매핑 정의서(Mapping Sheet) 활용

스크립트를 짜기 전, 아래와 같은 표를 반드시 작성하여 팀원들과 공유해야 사고가 안 납니다.

기존 테이블	기존 컬럼	신규 테이블	신규 컬럼	변환 로직
TB_DEPT	DEPT_NM	TB_DEPT_HIST	DEPT_NAME	단순 복사
TB_REQ	-	TB_REQ	REQ_DEPT_NAME	REQ_DATE 기준 부서명 조회 후 삽입

---

4. 주의사항: 테이블을 아예 지우는(Drop) 행위

"전체 테이블을 지우고 새로 생성한다"는 말이 기존 데이터를 날려버린다는 의미는 아닙니다. * 백업 필수: 기존 데이터는 OLD_ 접두사를 붙여서라도 한동안 보관해야 합니다.

• 권한(Grant) 체크: 테이블을 새로 만들면 기존에 부여했던 조회 권한(Grant)이 사라집니다. 권한 부여 스크립트도 잊지 말고 준비해야 합니다.

결론적으로, **"신규 구조의 테이블을 따로 만들어서 데이터를 이관하는 방식"**이 고도화 프로젝트의 정석입니다.

 

 

※ 해당 내용은 Google Gmini3.0에서 작성되었습니다.