
이번 AWS Summit에서 가장 인상 깊게 들었던 세션 중 하나는 여기어때의 Oracle → Aurora MySQL 마이그레이션 사례였다.
현재 나도 사내 시스템에서 Stored Procedure 기반 구조를 JPA 기반 구조로 점진적으로 전환하는 작업을 진행하고 있어서 그런지 단순 사례 발표보다는 실제 현업 관점에서 공감되는 부분이 많았다.
발표를 들으면서 가장 크게 느낀 건 생각보다 변환 자체는 더 이상 가장 어려운 영역이 아니라는 점이었다.
예전에는 Oracle SP를 사람이 직접 해석하고 MyBatis나 JPA 코드로 하나씩 옮기는 작업 자체가 큰 비용이었다면,
지금은 Claude나 Amazon Q 같은 생성형 AI를 활용하면 기본적인 변환 속도 자체는 상당히 빨라졌다.
실제로 반복적인 패턴이나 단순 CRUD 성격의 로직들은 꽤 높은 수준으로 변환해준다.
하지만 직접 SP → JPA 전환 작업을 진행하면서 느끼는 건 결국 어려운 건 코드 작성이 아니라 검증이라는 점이다.
특히 레거시 Stored Procedure는 단순 SQL 집합이라기보다 운영 과정에서 누적된 비즈니스 정책 그 자체에 가까운 경우가 많다.
코드만 보면 왜 이렇게 작성되어 있는지 이해되지 않는 부분들도 실제 운영 데이터와 함께 보면 이유가 보이는 경우가 많다.
예를 들자면
- 특정 상태값을 중복으로 체크하는 로직
- 순서가 비효율적으로 보이는 처리
- 오래된 예외 분기
- 의미를 알 수 없는 조건문
같은 부분들도 실제로는 장애 대응이나 운영 중 발생했던 특정 케이스들을 처리하기 위해 유지된 경우가 많다.
이런 부분은 결국 정적 분석만으로는 파악이 어렵다.
AI 전환 시
- SQL 구조 분석
- 문법 변환
- 반복 패턴 처리
에는 강점을 보이지만, 운영 환경에서 누적된 데이터 흐름과 비즈니스 맥락까지 완전히 이해하지는 못한다.
그래서 결국 마지막 검증 책임은 개발자가 가져갈 수밖에 없다는 생각이 들었다.
현재 일부 로직들은 Shadow Test 형태로 비교 검증을 진행하고 있다.
조회성 로직은 비교적 접근이 단순하다.
기존 SP 결과와 신규 JPA 결과를 동일 조건으로 조회한 뒤 결과를 비교하면 어느 정도 검증이 가능하기 때문이다.
하지만 실제로 어려운 영역은 CUD(Create / Update / Delete) 쪽이다.
특히 UPDATE 계열 로직들은 단순 데이터 수정 수준이 아니라:
- 여러 테이블 동시 갱신
- 상태 변경
- 누적 계산
- 후처리
- 커서 기반 순차 처리
등이 하나의 트랜잭션 안에서 함께 수행되는 경우가 많다.
문제는 이런 로직들을 코드 레벨에서 Shadow Test 방식으로 검증하기가 생각보다 쉽지 않다는 점이다.
인프라 레벨 Shadow Traffic처럼 요청 자체를 복제하는 구조와는 다르게 지금 진행 중인 작업은 코드 자체를 교체하는 작업에 가깝기 때문이다.
현 시점은
- 롤백 기반 비교
- 특정 키 기준 정합성 검증
- SP 결과와 JPA 결과 대조
- 케이스별 데이터 비교
같은 방식들을 계속 고민하며 검증 범위를 넓혀가고 있다.
최근 가장 크게 느끼는 건 결국:
동작한다와
운영 가능한 수준으로 안전하다는 완전히 다른 문제라는 점이다.
로컬 환경에서는 정상 동작하더라도 실제 운영 환경에서는...
- 데이터 정합성
- 동시성
- Lock
- 순서 보장
- 타이밍 이슈
같은 문제들이 계속 발생한다.
특히 몇 년 이상 운영된 Stored Procedure들은 이미 수많은 장애와 예외 상황을 거치며 높은 확률로 안정화된 코드들이기 때문에
단순히 JPA로 다시 작성하는 것만으로는 해결되지 않는 경우가 많다.
요즘은 이 작업이 단순 리팩토링이라기보다 운영 중인 비즈니스 로직을 재현하는 작업에 더 가깝다는 생각이 든다.
이번 세션도 단순히 Oracle DB 에서 Aurora Mysql DB로 이전했다는 성공 사례보다는 실제 운영 환경에서 어떤 방식으로 검증하고 안정성을 확보했는지에 대한 이야기가 많아서 더 인상 깊게 남았다.
Ref.
https://aws.amazon.com/ko/blogs/tech/oracle-to-amazon-aurora-mysql-migration-journey/
Oracle에서 Amazon Aurora MySQL로: 여기어때의 6주간 데이터베이스 마이그레이션 여정 | Amazon Web Services
개요 여기어때컴퍼니는 대한민국 대표 여행 플랫폼 기업으로 운영하며 숙박·항공·레저까지 통합 여행 서비스를 제공하고 있습니다. 2025년 1월, 여기어때컴퍼니는 온라인투어를 인수하면서 항
aws.amazon.com
https://aws.amazon.com/ko/events/summits/seoul/agenda/
강연 목록 | AWS Summit Seoul 2026
2026년 5월 20-21일 오전 8시 30분: 등록 시작 오전 9시 30분 - 오전 10시 40분: 기조연설 오전 11시 10분 - 오후 4시 50분: 브레이크아웃 세션 오전 10시 - 오후 5시 30분: 엑스포
aws.amazon.com
'변소' 카테고리의 다른 글
| 헬스장가기싫은날 루틴 (2) | 2026.05.06 |
|---|---|
| chat gpt - 계속하려면 challenges.cloudflare.com 차단을 해제하십시오. (1) | 2025.11.18 |
| 단말기 결제 VAN 결제 데이터 동기화 하여 회계 전표 자동 생성 시스템화까지 ...☠️ (8) | 2025.03.27 |
| window 10 enterprise 라이센스 만료 후 일정 사용 시간 지나면 강제 종료 되는 현상 해결 방법 (1) | 2024.12.19 |
| outlook 자격 증명 팝업이 반복해서 나올 경우 😡 (2) | 2024.08.23 |