[reinvent 2025] Oracle에서 Aurora PostgreSQL로 마이그레이션 하기 위한 핵심 가이드

들어가며

이번 세션은 Oracle에서 Amazon Aurora PostgreSQL로 이전할 때 반드시 고려해야 할 핵심 전략을 중심으로 진행되었습니다.

기존 Oracle 환경의 비용 구조, 아키텍처 제약, 운영 방식의 한계를 진단하고, Aurora PostgreSQL 전환 시 기대할 수 있는 성능·비용·운영 효율성 측면의 이점을 실무 관점에서 소개한 세션입니다.

실제 고객 사례 기반의 질문과 토론이 포함된 chalk talk 형식으로 진행되어, 마이그레이션 과정에서 자주 발생하는 문제와 실질적인 해결 방안이 공유되었습니다.

Oracle 마이그레이션 배경과 전략적 접근

Oracle에서의 마이그레이션은 단순한 기술 교체가 아니라 변화된 비즈니스 요구사항에서 출발한다는 점이 강조되었습니다.

특히 높은 상용 DB 라이선스 비용, 클라우드 네이티브 아키텍처로의 전환, 빠른 기능 출시 요구 등이 Aurora PostgreSQL 이전을 결정하는 주요 요인으로 소개되었습니다.

마이그레이션 과정에서 가장 흔한 실수는 기존 시스템을 그대로 복제하려는 접근입니다. 현재 사용 중인 기능의 필요성을 재검토하고, 데이터 타입과 구조가 적절한지 처음부터 다시 설계해야 합니다.

예를 들어 Oracle NUMBER 타입을 PostgreSQL NUMERIC으로 그대로 변환하면 정수 연산 성능 저하 및 저장 공간 비효율이 발생할 수 있어, 기본키는 BIGINT, 나이 등 범위가 작은 값은 SMALLINT처럼 의미 기반 타입 매핑이 필수라고 설명되었습니다.

스키마·코드 변환 전략과 생성형 AI 활용

Oracle 환경을 Aurora PostgreSQL로 전환할 때 활용할 수 있는 DMS Schema Conversion 기능이 소개되었습니다.

변환 과정은 Data Provider와 Instance Profile을 기반으로 수행되며, 규칙 기반으로 변환되지 않는 객체는 Amazon Bedrock의 생성형 AI가 보완 변환을 시도하는 구조로 설명되었습니다.

Oracle NUMBER 타입, PIVOT 절, PACKAGE 구조처럼 PostgreSQL에 직접 대응되지 않는 기능들은 변환 품질 차이가 크기 때문에, 생성형 AI와 전략적 변환 방식의 조합이 필요하다고 안내되었습니다.

Oracle PACKAGE 변환 사례에서는 패키지명을 PostgreSQL 스키마와 매핑해 기존의 패키지명.함수 호출 구조를 그대로 유지하는 기법이 소개되었습니다.

이를 통해 함수·프로시저의 위치만 스키마 단위로 재배치하여 애플리케이션 코드 수정 없이 패키지 구조를 이전할 수 있는 실용적인 전략임이 강조되었습니다.

또한 Java 코드 변환 데모에서는 Oracle 전용 구문(PIVOT 등)을 PostgreSQL에서 사용 가능한 CROSSTAB 형태로 재작성하는 과정이 생성형 AI를 통해 자동화되는 모습이 시연되었습니다.

이를 통해 스키마뿐 아니라 애플리케이션 계층에서도 AI 기반 코드 변환이 유용하게 활용될 수 있음을 확인할 수 있었습니다.

Aurora PostgreSQL 아키텍처 핵심 개념과 유의사항

이후 Aurora PostgreSQL의 아키텍처적 강점이 소개되었습니다.

Aurora는 데이터 페이지(block/page)의 플러시 없이 로그 레코드만 스토리지 계층으로 전송하는 구조를 사용하여 체크포인트 오버헤드를 최소화하고, 높은 처리량과 확장성을 제공합니다. 스토리지는 3개 AZ에 걸쳐 총 6개의 복제본을 유지해 높은 내구성과 가용성을 확보하며, Global Database는 최대 10개 리전에 스토리지 기반 복제를 제공해 비용 효율적인 DR 구성이 가능함이 강조되었습니다.

또한 PostgreSQL 특성을 고려한 성능 최적화 포인트가 함께 소개되었습니다.

• Vacuum/Autovacuum: MVCC 구조로 인해 발생하는 dead tuple 정리를 위해 Vacuum이 핵심이며, 대규모 테이블은 기본값(20%)보다 적극적인 튜닝이 필요.
  
• 인덱스 차이: PostgreSQL B-tree는 NULL도 인덱싱하며, Invisible Index는 없지만 트랜잭션 DDL로 유사 테스트 가능.
  
• IOT 및 Function Index 대응: IOT는 없지만 CLUSTER가 대안, Function-based Index는 Expression Index로 처리.
  
• 파티셔닝: 기본 기능은 제한적이며 pg_partman(extension)을 통해 자동 파티션 생성·보존 정책 구성 가능.
  
• 모니터링: CloudWatch Database Insights는 AWR·ADDM 대체 옵션으로 7일 무료 보존과 Top SQL·대기 이벤트 분석을 제공함

결론

Oracle에서 Aurora PostgreSQL로의 전환은 비용 절감뿐만 아니라 현대적 아키텍처 도입과 운영 효율화까지 동시에 달성할 수 있는 변화라고 요약할 수 있습니다.

생성형 AI 기반 스키마 변환, 로그 기반 스토리지 구조, Global Database 등 Aurora의 고유 기능들은 기존 Oracle 운영의 복잡성을 크게 단순화할 수 있는 실질적 대안으로 소개되었습니다.

이번 세션은 마이그레이션 과정에서 반드시 고려해야 할 데이터 타입 분석, 코드 검증, PostgreSQL 구조 이해 등 핵심 준비사항을 명확히 제시하며, Oracle → Aurora PostgreSQL 이전을 고민하는 조직이 실제 적용 가능한 전략을 수립하는 데 도움이 되는 실무 중심의 가이드를 제공했습니다.