Oracle에서 Amazon Aurora MySQL로: 여기어때의 6주간 데이터베이스 마이그레이션 여정

개요

여기어때컴퍼니는 대한민국 대표 여행 플랫폼 기업으로 운영하며 숙박·항공·레저까지 통합 여행 서비스를 제공하고 있습니다. 2025년 1월, 여기어때컴퍼니는 온라인투어를 인수하면서 항공 사업 영역을 확장했습니다. 이에 따라 항공 Global Distribution System(GDS)* 현대화 프로젝트가 시작되었으며, 그 첫 번째 과제는 오랜 기간 On-Premise 환경에서 운영되던 Oracle 데이터베이스를 Amazon Aurora MySQL로 전환하는 작업이었습니다.

*Global Distribution System (GDS)는 항공사, 호텔, 렌터카 등 여행 상품의 예약과 판매를 연결해주는 전산 네트워크 시스템입니다. 여행사가 이 시스템을 통해 전 세계 항공편, 숙박 등을 실시간으로 조회하고 예약할 수 있습니다. 대표적으로 Amadeus, Sabre, Travelport 등이 있습니다.

이기종 데이터베이스 마이그레이션은 데이터베이스 스키마 변환뿐만 아니라 애플리케이션 레벨의 SQL 구문 변환, 그리고 변환된 구문의 정합성 검증까지 포함하는 복잡한 프로세스입니다. 여기어때컴퍼니는 AWS와 협력하여 Amazon Q Developer 기반의 Oracle Modernization Accelerator(OMA) 프로그램을 활용함으로써, 당초 여러 명이 수개월간 투입돼야 할 대규모 작업으로 예상되었지만, 단 6주 만에 시스템 마이그레이션을 성공적으로 마쳤습니다.

[그림1. 이기종 데이터베이스 마이그레이션 작업 프로세스와 OMA 적용 영역]

이 블로그 포스트에서는 여기어때컴퍼니가 OMA 프로그램을 통해 Oracle to Aurora MySQL 마이그레이션을 수행한 과정과 실제로 직면한 기술적 과제들, 그리고 생성형 AI를 활용한 해결 방안을 공유합니다.

과제 및 목표

마이그레이션 배경

온라인투어 인수 이후, 여기어때컴퍼니는 항공 서비스의 클라우드 네이티브 전환을 추진했습니다. 기존 항공 시스템은 다음과 같은 특징을 가지고 있었습니다:

• 인프라: On-Premise, Oracle Database
• 애플리케이션: Java 기반, MyBatis Framework 사용
• 목표 : 항공 시스템을 Amazon EKS와 Amazon Aurora MySQL 기반의 플랫폼으로 전환

주요 도전과제

1. 이기종 데이터베이스 전환: Oracle과 MySQL의 문법 차이로 인한 광범위한 SQL코드 수정 필요
2. 검증 범위: 변환된 SQL의 기능적 정확성 및 데이터 정합성 보장
3. 프로젝트 기간: 서비스 연속성을 위한 단기간 전환 필요

Oracle Modernization Accelerator(OMA)

여기어때컴퍼니는 AWS와의 협업을 통해, 마이그레이션 과제 중 가장 많은 공수가 투입되고 난이도가 높았던 데이터베이스 마이그레이션을 효과적으로 해결하기 위한 방안으로 Oracle Modernization Accelerator(이하 OMA) 프로그램 도입을 결정했습니다. OMA는 Amazon Q Developer의 생성형 AI 기술을 활용하여 Oracle 데이터베이스를 Amazon Aurora로 마이그레이션을 가속화하는 프로그램입니다.

OMA 프로그램의 주요 특징

• 생성형 AI 기반 자동 변환: Amazon Q Developer를 통한 스키마 및 SQL 구문 자동 변환
• 체계적인 검증 프로세스: 문법 검증, 결과값 비교, 기능 테스트의 다단계 검증
• AWS DMS 통합: AWS Database Migration Service와 연계한 데이터 이관
• 검증된 사례: 다수 고객사의 성공적인 적용 실적

여기어때컴퍼니는 Schema와 SQL 코드를 수작업으로 수정하는 방식으로는 여러 명이 수개월간 투입돼야 할 것으로 예상되던 작업을, OMA라는 자동화·최적화 방식을 적용하면 소수 인력과 짧은 기간으로도 가능하다는 분석 결과를 바탕으로, 해당 프로그램 도입을 결정했습니다.

[그림2. OMA 환경 구성]

마이그레이션 프로세스

여기어때컴퍼니의 마이그레이션 프로젝트는 두 가지 핵심 트랙으로 구성되었습니다:

1. Database 변환: Oracle 스키마를 Aurora MySQL 호환 스키마로 전환
2. Application 변환: MyBatis Mapper 파일의 SQL 구문을 MySQL 호환 구문으로 전환

OMA의 전체 프로세스는 4개의 마이그레이션 단계로 구성되었으며, 6주간의 기간동안 다음과 같이 진행되었습니다.

주차별 진행 상황

1단계: Database 변환

주요 변환 작업

1) 데이터 타입 변환

Oracle과 MySQL의 데이터 타입 차이를 해결하기 위한 변환 작업이 수행되었습니다:

• Row Size 제한 대응: VARCHAR2(4000) → TEXT 또는 VARCHAR로 변환
• LOB 타입 처리: CLOB → LONGTEXT → LONGVARCHAR로 변환
  • MyBatis의 jdbcType에 LONGTEXT가 없어 LONGVARCHAR를 사용

[그림3. Amazon Q Developer를 통한 데이터베이스 스키마 추가 변환]

2) Oracle Sequence 처리

Oracle의 Sequence는 다음과 같은 전략으로 MySQL의 AUTO_INCREMENT로 전환되었습니다:

• 단일 PK 테이블: 해당 컬럼에 AUTO_INCREMENT를 적용하고 기존 PK 유지
• 복합 PK 테이블: AUTO_INCREMENT를 적용할 컬럼을 첫 번째 위치로 이동하여 PK 재조정
• 시작 값 설정: 현재 데이터의 MAX VALUE + 1로 AUTO_INCREMENT 시작 값 설정

2단계: Application 변환

Java Application 분석

여기어때컴퍼니의 항공 GDS 어플리케이션은 Java 기반으로 작성되었으며, MyBatis Framework를 통해 데이터베이스와 연동되고 있었습니다. Application 변환 프로세스는 다음 단계로 진행되었습니다:

1. Java Application 구조 분석
2. MyBatis Mapper 파일 추출
3. SQL 쿼리 추출 및 변환
4. 변환된 SQL 구문 검증

Amazon Q Developer의 역할

Application 변환 단계에서 Amazon Q Developer는 다음과 같은 기여를 했습니다:

• SQL 구문 자동 변환: Oracle 전용 함수 및 구문을 MySQL 호환 구문으로 자동 변환
• 사전 정의된 변환 규칙 적용: 일반적인 마이그레이션 패턴에 대한 모범 사례 적용
• 변환 정확도 향상: 반복적인 변환-검증 사이클을 통한 정확도 개선

3단계: SQL 단위 테스트 및 검증

검증 프로세스

변환된 SQL 구문이 원본과 동일한 결과를 생성하는지 확인하기 위해 다음과 같은 검증 프로세스가 수행되었습니다:

1. Oracle Database에서 원본 SQL 실행: 원본 데이터베이스에서 쿼리 실행 및 결과값 저장
2. Aurora MySQL에서 변환된 SQL 실행: 대상 데이터베이스에서 변환된 쿼리 실행 및 결과값 저장
3. 결과값 비교: 두 결과값이 완전히 일치하는지 자동 비교
4. 불일치 시 재변환: 결과가 다를 경우 Amazon Q Developer를 통해 구문 재변환 및 재검증

성능 검증 전략

소스 코드에서 전달되는 쿼리 조건이나 비즈니스 로직을 완전히 확인하는 데는 한계가 있어, 성능 검증은 차후 진행되는 애플리케이션 품질 검증(QA) 단계에서 수행하기로 결정했습니다.

4단계: Application 기능 테스트

UI 레벨 통합 테스트

SQL 단위 테스트는 구문의 기능적 정확성을 보장하지만, 실제 애플리케이션 런타임 환경에서 발생할 수 있는 모든 이슈를 발견하기는 어렵습니다. 따라서 Target 환경에서 Application을 직접 기동하고 UI 기능 테스트를 수행했습니다.

이 단계에서는 SQL 단위 테스트보다 실제 애플리케이션 동작을 통해 오류를 더 직관적으로 확인할 수 있었고, 자동 변환 과정에서 미처 발견하지 못했던 문제들도 함께 찾아낼 수 있었습니다.

Amazon Q Developer를 통한 런타임 오류 수정

Application 기능 테스트에서 발견된 오류는 다음과 같은 프로세스로 해결되었습니다:

1. 애플리케이션 로그 분석: 에러 로그 파일에서 오류 유형 자동 분류
2. Amazon Q Developer를 통한 원인 분석: 어느 Mapper의 어떤 SQL ID에서 오류가 발생했는지 식별
3. 수정 방안 제시 및 적용: AI가 제안한 수정 사항을 검토 후 적용
4. 재테스트: 수정된 구문으로 다시 테스트하여 정상 동작 확인

주요 기술적 과제 및 해결

1.Database 스키마 변환 시 이슈

과제: Oracle과 MySQL의 데이터 타입 차이

Oracle의 VARCHAR2(4000)은 MySQL의 최대 VARCHAR 길이를 초과할 수 있습니다. 또한 CLOB 타입은 MyBatis의 jdbcType에서 직접 매핑되지 않는 문제가 있었습니다.

해결:

• Row Size 제한을 고려하여 TEXT 또는 VARCHAR로 적절히 변환
• CLOB → LONGTEXT → LONGVARCHAR로 단계적 변환 수행

2.MyBatis Mapper 파일 변환 시 이슈

과제 1: 대소문자 구분

-- 문제 구문
SELECT A.UserInfo FROM CM_USERLog AS a

-- 원인
Oracle DB에서는 대소문자 구분을 하지 않으나,  MySQL에서는 대소문자를 구분하여 오류 발생

-- 해결
테이블 별칭을 대문자로 통일
SELECT A.UserInfo FROM CM_USERLog AS A

과제 2: 동적 쿼리 처리

-- 문제 구문
Unknown column 'ROWNUM' in 'orderby clause'

-- 원인
소스 코드에서 #{orderby} 조건을 동적으로 생성하여 완성되는 쿼리

-- 해결
해당 구문은 SQL 단위 테스트에서 제외하고, 애플리케이션 기능 테스트 단계에서 검증

과제 3: 숫자 문자열 변환 이슈

-- 문제 구문
WHERE _TAG_ IS NULL 
OR ('0' < _TAG_ AND _TAG_ <= '12')

-- 원인
일부 SQL 문에서 숫자를 문자열로 인식하여 의도와 다른 결과 발생

-- 해결
CONVERT 함수를 사용한 명시적 형변환
WHERE _TAG_ IS NULL
OR (CONVERT(#{rowstart,jdbcType=INTEGER}, UNSIGNED) < _TAG_ 
    AND _TAG_ <= CONVERT(#{rowfinish,jdbcType=INTEGER}, UNSIGNED))

성과

공수 절감 효과

주요 성과

• 단기간 전환 완료: 6주 만에 16,000여개의 SQL 구문, 1500여개의 Object에 대한 전체 마이그레이션 완료
• 검증된 정합성: SQL 단위 테스트 및 UI 기능 테스트를 통한 철저한 검증
• Cloud Native 기반 마련: On-premise 기반으로 운영되었던 여기어때컴퍼니의 항공 서비스를 클라우드 네이티브 인프라 기반으로 운영할 수 있는 기틀 마련

결론

여기어때컴퍼니의 항공 GDS 시스템 마이그레이션 및 현대화 과제의 핵심 영역인 Oracle to Aurora MySQL 마이그레이션은 Amazon Q Developer 기반의 Oracle Modernization Accelerator를 활용하여 예상 공수를 95% 이상 절감하며 성공적으로 완료되었습니다. 여기어때컴퍼니는 이번 경험을 바탕으로 클라우드 네이티브 환경에서 더욱 확장 가능하고 효율적인 항공 서비스를 제공할 수 있는 기반을 마련했습니다.