오라클 DB를 PostgreSQL로 마이그레이션하는 절차: 무중단 전환까지 실무 체크리스트

서론: 오라클 → PostgreSQL 전환은 “DB 교체”가 아니라 “시스템 이식”이다

오라클을 PostgreSQL로 바꾸는 작업은 단순히 데이터 덤프를 떠서 넣는 수준이 아니다.
스키마, SQL, 트랜잭션, 인덱스, 배치, 운영 도구까지 모두 영향을 받는다.

특히 운영 시스템이라면 “언제 어떻게 끊김 없이 바꿀 것인지”가 핵심이다.
이 글에서는 실무에서 가장 많이 쓰는 방식으로
사전 분석 → 변환 → 이관 → 검증 → 전환(컷오버) → 안정화 절차를 정리한다.

※ 대규모 시스템 기준으로 작성했으며, 소규모 시스템도 이 체크리스트를 축약해 적용하면 된다.

 

---

1) 마이그레이션 방식 3가지 중 무엇을 택할까?

먼저 전환 목표(RTO/RPO)와 서비스 중단 허용 시간을 확정해야 한다.
그에 따라 방식이 갈린다.

방식 A. 오프라인(다운타임) 이관

• 장점: 구조가 단순, 비용이 낮음
• 단점: 긴 점검 시간이 필요
• 추천: 내부 시스템/야간 점검 가능한 서비스

방식 B. 온라인(저다운타임) 이관

• 초기 전체 이관 후, 변경분만 재적재(incremental) 반복
• 컷오버 시점만 짧게 중단

방식 C. 무중단(near-zero downtime) 이관

• CDC(Change Data Capture)로 오라클 변경분을 실시간 반영
• 애플리케이션을 점진적으로 전환(Expand→Migrate→Contract)
• 추천: 중단이 거의 허용되지 않는 서비스

실무에서 가장 현실적인 선택은 대개 B(저다운타임) 또는 C(무중단에 가까운 방식)이다.

---

2) 0단계: 사전 진단(이 단계에서 성패가 결정된다)

“오라클 기능을 얼마나 쓰고 있느냐”를 정확히 파악해야 한다.
다음 항목은 반드시 인벤토리로 만든다.

• 테이블/컬럼/PK/FK/인덱스/제약조건 목록
• 시퀀스, 트리거, 뷰, 머티리얼라이즈드 뷰
• 프로시저/패키지(PL/SQL) 사용량
• JOB 스케줄러(DBMS_SCHEDULER) 사용 여부
• 대용량 테이블(Top N), 파티션 사용 여부
• SQL 패턴(특히 분석함수, MERGE, CONNECT BY 등)

이 자료는 “변환 난이도”와 “일정/리스크” 산정의 근거가 된다.
그리고 여기서 자주 나오는 함정이 있다.

• DATE/TIMESTAMP/타임존 처리 방식 차이
• NULL 정렬 규칙 차이
• 문자셋(UTF-8)과 정렬(collation)
• 오라클의 NUMBER를 Postgres의 어떤 타입으로 갈지

---

3) 1단계: 스키마 변환(Oracle → PostgreSQL)

스키마 변환은 크게 3가지 접근이 있다.

• 자동 변환 도구로 1차 생성 후 수작업 보정
• DDL을 직접 재설계(권장: 운영 품질 최고)
• 혼합(핵심 테이블은 수작업, 나머지는 자동)

실무에서는 “혼합”이 가장 일반적이다.

대표적인 타입 매핑 예시

• VARCHAR2 → varchar
• CLOB → text
• BLOB → bytea(또는 외부 스토리지)
• NUMBER(p,s) → numeric(p,s) 또는 bigint/int
• DATE → timestamp(주의: 오라클 DATE는 시간 포함)

특히 오라클의 DATE가 “날짜만”이 아니라 “시간까지 포함”이라는 점은 이관 장애의 단골 원인이다.
사전에 컬럼 사용처를 샘플링하고, 변환 정책을 확정해두는 것이 좋다.

---

4) 2단계: 데이터 이관(초기 Full Load)

초기 전체 이관(Full Load)은 대부분 아래 흐름을 따른다.

• 오라클에서 데이터를 추출(테이블별 덤프/CSV 등)
• PostgreSQL에 로드(COPY, bulk insert)
• 인덱스/제약조건은 “나중에” 생성(속도 최적화)

대용량 테이블은 인덱스/제약조건을 잠시 끄고 로딩한 뒤,
로딩이 끝나면 인덱스를 생성하는 것이 일반적으로 빠르다.

PostgreSQL에서는 대량 적재 시 COPY가 핵심이다.

COPY target_table (col1, col2, col3)
FROM STDIN WITH (FORMAT csv, HEADER true);

초기 적재 후, 반드시 “행 수/해시/샘플링 비교”로 1차 검증을 한다.

---

5) 3단계: SQL/애플리케이션 변경(가장 시간이 오래 걸린다)

실무에서 가장 오래 걸리는 구간은 스키마가 아니라 SQL과 PL/SQL이다.

다음 항목은 미리 “치환 규칙”을 정해놓으면 속도가 급격히 빨라진다.

• SYSDATE → now()
• NVL → coalesce
• DECODE → case when
• ROWNUM 페이징 → limit/offset 또는 keyset pagination
• MERGE → INSERT...ON CONFLICT 또는 UPSERT 패턴

PL/SQL 패키지를 많이 쓰는 시스템은 다음 중 하나로 전략을 잡는다.

• 로직을 애플리케이션 레이어로 이동(권장)
• Postgres 함수/프로시저(PL/pgSQL)로 재작성
• 당장 치환이 어려운 일부는 오라클 유지(하이브리드)

---

6) 4단계: 변경분 동기화(저다운타임/무중단의 핵심)

운영 전환을 빠르게 하려면 “초기 이관 이후 발생하는 변경분”을 따라잡아야 한다.
여기서 핵심이 CDC(Change Data Capture) 또는 증분 적재다.

저다운타임(B) 접근

• 밤에 전체 덤프 + 로딩
• 그 이후 일정 주기로 변경분을 재적재
• 컷오버 직전에 마지막 동기화 후 짧게 중단

무중단에 가까운(C) 접근

• 오라클의 변경 로그(redo/archivelog) 기반으로 CDC
• PostgreSQL에 지속적으로 반영
• 전환 시점은 라우팅만 바꿈

CDC는 시스템 규모에 따라 도구/구성이 달라지므로,
실무에서는 “중단 허용 시간”과 “비용”을 기준으로 결정하는 것이 좋다.

---

7) 5단계: 검증(이 단계가 없으면 사고가 난다)

컷오버 전에 다음 검증을 통과해야 한다.

• 테이블별 row count 비교
• 핵심 테이블 checksum/해시 비교(부분 샘플링)
• 주요 API 시나리오 회귀 테스트
• 성능 테스트: 평균/95p/99p 응답시간 비교
• 락/트랜잭션 격리 수준 검증

특히 “성능은 이관 후 좋아질 것”이라는 기대는 위험하다.
실제로는 인덱스/쿼리/통계 설정 차이로 느려지는 경우가 많다.
따라서 컷오버 전, 최소한 핵심 쿼리는 실행계획(EXPLAIN) 수준까지 확인해야 한다.

---

8) 6단계: 컷오버(전환 당일 절차)

전환 당일에는 절차가 명확해야 한다.
아래는 가장 일반적인 순서다.

• 쓰기 트래픽 중지(필요 시 Read-only 모드)
• 마지막 증분 동기화 수행
• 검증 스크립트 실행(행 수/샘플 값)
• 애플리케이션 DB 연결을 PostgreSQL로 전환
• 모니터링(에러율, 지연, 커넥션, 락)을 집중 관찰

이 단계에서 가장 중요한 것은 롤백 계획이다.
롤백은 “필요하면 하자”가 아니라, “언제든 즉시 가능해야 한다.”
따라서 일정 시간(예: 2시간) 동안은 오라클을 그대로 유지하는 것이 일반적이다.

 

---

9) 7단계: 안정화(전환 이후 1~2주가 진짜 시작)

전환 후에는 운영 튜닝이 필요하다.

• VACUUM / ANALYZE 자동화 점검
• 인덱스 재평가(불필요 인덱스 제거)
• 커넥션 풀(HikariCP) 튜닝
• slow query 로그 기준 재설정
• 백업/복구 시나리오 재정립(pg_dump, PITR 등)

PostgreSQL은 “통계(ANALYZE)”와 “VACUUM” 운영이 성능에 큰 영향을 준다.
오라클과 운영 철학이 다르므로, 이 부분을 초기부터 체계화해야 한다.

---

결론: 성공하는 DB 전환은 ‘절차’가 아니라 ‘체계’가 만든다

오라클에서 PostgreSQL로의 마이그레이션은 충분히 가능하다.
다만 성공의 핵심은 도구가 아니라 다음 3가지다.

1) 사전 진단(기능 사용량)
2) 단계적 이관(동기화 전략)
3) 검증/롤백(절차의 자동화)

이 3가지만 제대로 잡으면, 다운타임을 최소화하면서도 안정적으로 전환할 수 있다.