AWS에서 OCI로 데이터베이스 마이그레이션할 때 놓치기 쉬운 체크리스트
핵심 요약: AWS에서 OCI로 DB를 옮길 때 TCO, Cloud Connect, PoC, 보안, 실행 단계를 점검하는 체크리스트예요. 20% 이상 절감, 30초 이내 Failover 같은 Go 기준을 함께 제시해요.
AWS에서 OCI로 데이터베이스를 옮기겠다는 결정은 보통 비용 절감에서 시작돼요. 그런데 실제로 프로젝트를 진행해 보면, 비용보다 더 복잡한 의사결정이 줄줄이 기다리고 있어요. 네트워크 연결 방식은 뭘로 할지, PoC는 어디까지 해야 충분한지, 보안 요구사항은 어떻게 맞출지. 저희가 국내 식품 이커머스 고객사의 AWS→OCI 마이그레이션을 진행하면서 정리한 의사결정 프레임워크를 공유할게요.
마이그레이션을 결정하기 전에 물어야 할 질문들
마이그레이션 프로젝트에서 가장 비용이 큰 실수는 "왜 옮기는가"에 대한 합의 없이 시작하는 거예요. 기술팀은 성능 개선을 기대하고, 경영진은 비용 절감을 기대하고, 보안팀은 컴플라이언스 강화를 기대하는데 이 세 가지가 동시에 충족되지 않는 경우가 많아요.
저희가 고객사와 킥오프 미팅에서 반드시 확인하는 질문이 있어요.
- 현재 AWS 비용 중 가장 큰 비중을 차지하는 항목이 무엇인가요?
- 마이그레이션 후 기대하는 TCO 절감률의 최소 기준은 얼마인가요?
- 서비스 다운타임 허용 범위는 어느 정도인가요?
- 현재 AWS에서만 사용 가능한 서비스(Lambda, SQS 등)에 대한 대체 전략이 있나요?
- 데이터 주권 요구사항이 있나요? (한국 리전 필수 여부)
이 질문들에 대한 답이 명확하지 않으면, 프로젝트 중간에 스코프가 흔들려요. 실제로 저희 고객사도 처음에는 "DB만 옮기자"로 시작했다가, 요구사항 분석을 하면서 컴퓨팅, 스토리지, 네트워킹까지 전체 아키텍처 재설계로 범위가 확장됐어요.
TCO 비교, 제대로 하는 방법
TCO 비교에서 가장 흔한 실수는 인스턴스 단가만 비교하는 거예요. 실제 운영 비용에는 눈에 보이지 않는 항목이 많아요.
비교해야 할 비용 항목
| 비용 카테고리 | AWS 항목 | OCI 대응 항목 |
|---|---|---|
| 컴퓨팅 | EC2, ECS/EKS, Auto Scaling | OCI Compute, OKE, Instance Pools |
| 데이터베이스 | RDS MySQL (Multi-AZ + Read Replica) | MySQL HeatWave (HA + Replica) |
| 스토리지 | S3, EBS, RDS Storage I/O | Object Storage, Block Volume |
| 네트워크 | Data Transfer Out, NAT Gateway, VPN | Outbound Transfer, NAT, VPN Connect |
| 부가 서비스 | CloudWatch, RDS Proxy, Database Insights | OCI Monitoring (기본 포함) |
| 보안 | WAF, Shield, KMS | WAF, DDoS Protection, Vault |
숨겨진 비용을 놓치지 않으려면
저희 고객사 사례에서 TCO 분석 시 가장 큰 차이를 만든 항목은 네트워크 전송 비용이었어요. AWS는 아웃바운드 데이터 전송에 GB당 과금이 발생하는데, OCI는 월 10TB까지 무료예요. 트래픽이 많은 이커머스 서비스에서는 이 차이만으로도 월 수백만 원이 절감돼요.
I/O 과금 구조도 달라요. RDS MySQL은 읽기/쓰기 I/O 요청 건수에 따라 별도 과금이 발생하지만, MySQL HeatWave는 I/O 과금이 없어요. 트래픽 스파이크가 잦은 서비스일수록 이 차이가 커져요.
운영하면서 계속 느낀 건, TCO 비교는 "현재 청구서 기준"이 아니라 "향후 12개월 예상 워크로드 기준"으로 해야 정확하다는 거예요. 현재 비용만 보면 마이그레이션 비용 대비 절감 효과가 작아 보이지만, 성장하는 서비스라면 OCI의 과금 구조가 스케일링에 유리한 경우가 많아요.
Cloud Connect 옵션 비교. 어떤 벤더를 선택할까
AWS에서 OCI로 마이그레이션할 때 네트워크 연결 방식은 크게 세 가지예요. 공용 인터넷(VPN), 전용 회선(Cloud Connect), 그리고 하이브리드 운영 기간 동안의 임시 연결이에요.
전용 회선은 마이그레이션 기간 동안 대량 데이터 전송에 필수적이고, 마이그레이션 완료 후에도 멀티클라우드 운영을 계획한다면 유지해야 해요. 국내에서 선택할 수 있는 주요 Cloud Connect 벤더를 비교했어요.
벤더별 특징 비교
| 항목 | KT Cloud Connect | KINX 클라우드허브 | Equinix Fabric |
|---|---|---|---|
| 연결 방식 | KT PoP 기반 전용 회선 | IX 기반 클라우드 허브 | 글로벌 Fabric 메시 |
| 대역폭 옵션 | 100M–10G | 100M–10G | 50M–10G |
| AWS 연결 | Direct Connect 연동 | Direct Connect 연동 | Direct Connect 연동 |
| OCI 연결 | FastConnect 연동 | FastConnect 연동 | FastConnect 연동 |
| 국내 PoP | 목동, 분당, 용산 | 가산, 목동 | 서울 (상암) |
| 적합한 상황 | KT 회선 기존 사용 고객 | 중립 IX 선호, 다중 CSP 연결 | 글로벌 멀티클라우드, 해외 리전 연결 |
선택 기준
처음에는 가격만 보고 결정하려 했어요. 하지만 실제로 비교해 보니 가격보다 중요한 요소가 있었어요.
첫째, 기존 네트워크 인프라와의 호환성이에요. 고객사가 이미 KT 전용 회선을 사용하고 있다면 KT Cloud Connect가 추가 구축 없이 연결 가능해요. 새로 회선을 끌어야 하면 구축 기간이 4–8주 추가돼요.
둘째, 마이그레이션 이후 운영 계획이에요. 마이그레이션 기간에만 사용할 거라면 월정액이 낮은 옵션을 선택하면 되지만, 이후에도 멀티클라우드로 운영할 계획이라면 확장성과 다중 CSP 연결 지원 여부가 중요해요.
셋째, SLA와 이중화 구성이에요. 마이그레이션 중 네트워크 장애가 발생하면 데이터 정합성 문제로 이어질 수 있어요. 이중 경로 구성이 가능한지 반드시 확인해야 해요.
PoC, 어디까지 해야 충분한가
PoC 없이 마이그레이션을 결정하는 고객사는 거의 없어요. 문제는 PoC의 범위와 판단 기준이 모호한 경우가 많다는 거예요. "잘 되는 것 같다"는 느낌으로 Go 결정을 내리면, 본 마이그레이션에서 예상치 못한 문제가 터져요.
PoC에서 반드시 검증해야 할 항목
저희가 고객사 PoC를 설계할 때 사용하는 프레임워크예요.
성능 검증
- OLTP 워크로드: 현재 AWS 환경 대비 동등 이상의 TPS/QPS 확인
- 분석 쿼리: HeatWave 가속 적용 시 응답 시간 비교
- 피크 시간대 시뮬레이션: 실제 트래픽 패턴을 재현한 부하 테스트
호환성 검증
- MySQL 버전 호환성: 8.0 계열 간 DDL/DML 완전 호환 확인
- 애플리케이션 레벨: ORM 쿼리, Stored Procedure, 트리거 동작 확인
- 문자셋/콜레이션: utf8mb4 기반 데이터 무결성 확인
운영 검증
- 백업/복구: 자동 백업 주기, Point-in-Time Recovery 동작 확인
- HA 전환: 장애 시나리오에서 Failover 시간 측정
- 모니터링: 기존 Grafana/Datadog 연동 가능 여부
Go/No-Go 판단 기준
| 판단 항목 | Go 기준 | No-Go 기준 |
|---|---|---|
| OLTP 성능 | AWS 대비 90% 이상 | AWS 대비 70% 미만 |
| 분석 쿼리 성능 | HeatWave 적용 시 5배 이상 향상 | 2배 미만 향상 |
| 호환성 | 애플리케이션 수정 없이 동작 | 핵심 기능 수정 필요 |
| Failover 시간 | 30초 이내 | 5분 초과 |
| TCO 절감 | 20% 이상 절감 | 10% 미만 절감 |
여기서 주의할 점은 "90% 이상"이라는 기준이에요. 100%가 아닌 이유는, 마이그레이션 직후에는 캐시 워밍업, 통계 수집 등으로 일시적 성능 저하가 발생할 수 있기 때문이에요. 2–4주 안정화 기간을 거치면 대부분 동등 이상으로 올라와요.
마이그레이션 실행 단계별 체크리스트
오래된 건물을 리모델링하려다 벽 안에 배선이 얼마나 복잡한지 뒤늦게 발견하는 것처럼, 마이그레이션도 실행 단계에 들어가면 예상치 못한 의존성이 드러나요. 단계별로 놓치기 쉬운 항목을 정리했어요.
Phase 1. 사전 준비 (2–4주)
- OCI 테넌시 구성: Compartment 구조, IAM 정책, 네트워크(VCN/Subnet) 설계
- Cloud Connect 개통: 벤더 선정 → 회선 신청 → 개통 테스트 (4–8주 소요 가능)
- 마이그레이션 도구 선정: OCI Database Migration Service, MySQL Shell, 또는 Replication 기반
- Rollback 계획 수립: 어떤 조건에서 원복할지, 원복 시 데이터 정합성 보장 방법
Phase 2. 데이터 동기화 (2–4주)
- 초기 풀 덤프: mysqldump 또는 MySQL Shell의 dumpInstance로 전체 데이터 이관
- Replication 설정: AWS RDS → OCI MySQL HeatWave 간 비동기 복제 구성
- 복제 지연 모니터링: Seconds_Behind_Master가 안정적으로 0에 수렴하는지 확인
- 스키마 변경 동결: 복제 기간 중 DDL 변경 금지 (또는 pt-online-schema-change 활용)
Phase 3. 검증 및 최적화 (1–2주)
- 데이터 정합성 검증: 테이블별 row count 비교, checksum 비교
- 성능 베이스라인 측정: 주요 쿼리 응답 시간, TPS 측정
- HeatWave 클러스터 로딩: 분석 대상 테이블을 HeatWave 메모리에 적재
- 애플리케이션 연결 테스트: 엔드포인트 변경 후 전체 기능 테스트
Phase 4. 커트오버 (수 시간)
- 트래픽 차단: 소스 DB 쓰기 중지
- 최종 동기화 대기: 복제 지연 0 확인
- DNS 전환: 애플리케이션 DB 엔드포인트를 OCI로 변경
- 서비스 재개: 트래픽 유입 후 에러율, 응답 시간 모니터링
- Go/No-Go 판단: 30분 내 이상 없으면 Go, 이상 발생 시 Rollback
보안 요구사항 체크리스트
마이그레이션에서 보안은 "나중에 하자"가 통하지 않는 영역이에요. 특히 개인정보를 다루는 이커머스 서비스라면, 마이그레이션 설계 단계부터 보안 요구사항을 반영해야 해요.
네트워크 보안
- Private Subnet 배치: DB 인스턴스는 반드시 Private Subnet에 위치
- Security List/NSG: 필요한 포트만 허용 (MySQL 3306, 모니터링 에이전트 포트)
- 마이그레이션 기간 임시 규칙: 복제용 포트 개방 후 커트오버 완료 시 즉시 제거
- Cloud Connect 구간 암호화: 전용 회선이라도 TLS 암호화 적용 권장
데이터 보안
- 전송 중 암호화: TLS 1.2 이상 필수 (MySQL HeatWave 기본 지원)
- 저장 시 암호화: AES-256 기반 Transparent Data Encryption
- 키 관리: OCI Vault(KMS)를 통한 고객 관리형 키(CMK) 사용
- Data Masking: 개발/테스트 환경에 복제 시 개인정보 마스킹 적용
접근 제어
- IAM 정책: 최소 권한 원칙 적용, DB 관리자와 애플리케이션 계정 분리
- MFA: 관리 콘솔 접근 시 다중 인증 필수
- 감사 로깅: OCI Audit 서비스로 모든 관리 작업 기록
- 세션 관리: 유휴 세션 타임아웃, 동시 접속 제한
컴플라이언스
- 개인정보보호법: 한국 리전(서울/춘천) 내 데이터 저장 확인
- 로그 보존: 접근 로그 최소 6개월 보존 (법적 요구사항에 따라 조정)
- 백업 정책: RPO 1시간 이내, RTO 4시간 이내 (서비스 등급에 따라 조정)
- 정기 취약점 점검: 마이그레이션 완료 후 30일 이내 보안 점검 수행
실수하기 쉬운 부분 5가지
마이그레이션 프로젝트를 여러 번 진행하면서 반복적으로 발견한 실수 패턴이 있어요.
1. 서버리스 함수 대체 전략 누락 AWS Lambda로 구현된 로직이 생각보다 많아요. 이벤트 트리거, 스케줄러, API Gateway 연동 등. OCI Functions로 전환하려면 SDK 교체와 트리거 방식 변경이 필요한데, 이걸 마이그레이션 범위에서 빠뜨리는 경우가 많아요.
2. DNS TTL 미조정 커트오버 전에 DNS TTL을 낮춰두지 않으면, 전환 후에도 구 엔드포인트로 트래픽이 계속 흘러요. 최소 48시간 전에 TTL을 60초 이하로 낮춰야 해요.
3. 타임존 설정 불일치 AWS RDS의 기본 타임존과 OCI MySQL HeatWave의 기본 타임존이 다를 수 있어요. 애플리케이션에서 UTC를 사용하지 않는다면, 마이그레이션 후 시간 관련 데이터가 어긋날 수 있어요.
4. 모니터링 공백 기존 CloudWatch 대시보드를 그대로 쓸 수 없으니, OCI Monitoring으로 전환하거나 Grafana/Datadog 같은 서드파티 도구로 통합해야 해요. 커트오버 시점에 모니터링이 비어 있으면 장애 감지가 늦어져요.
5. 비용 알림 미설정 마이그레이션 직후에는 양쪽 환경이 동시에 돌아가면서 비용이 일시적으로 증가해요. OCI Budget Alert를 설정해두지 않으면, 예상치 못한 청구서를 받을 수 있어요.
마이그레이션 의사결정 프레임워크 요약
결국 중요한 것은 "옮길 수 있느냐"가 아니라 "옮겨야 하느냐"를 먼저 판단하는 거예요. 기술적으로 가능하더라도 비즈니스 임팩트가 충분하지 않으면 마이그레이션은 비용만 소모하는 프로젝트가 돼요.
저희가 사용하는 의사결정 흐름을 정리하면 이래요.
이 프레임워크에서 핵심은 각 단계마다 "No"일 때의 대안이 명확하다는 거예요. 마이그레이션이 답이 아닐 수도 있고, 전체가 아닌 일부만 옮기는 게 최적일 수도 있어요. 의사결정의 유연성을 유지하는 게 프로젝트 성공의 열쇠예요.
핵심 요약
- TCO 비교는 인스턴스 단가가 아닌 네트워크 전송, I/O 과금, 부가 서비스까지 포함한 전체 운영 비용으로 해야 정확해요
- Cloud Connect 벤더 선택은 가격보다 기존 인프라 호환성과 마이그레이션 이후 운영 계획을 기준으로 판단해요
- PoC는 "잘 되는 것 같다"가 아닌 정량적 Go/No-Go 기준을 사전에 정의하고 측정해야 해요
- 보안 요구사항은 마이그레이션 설계 단계부터 반영해야 하며, 커트오버 후 추가하면 아키텍처 변경이 필요할 수 있어요
- 마이그레이션이 답이 아닐 수도 있어요. 의사결정 프레임워크를 통해 각 단계에서 Go/No-Go를 판단하는 게 중요해요
FAQ
Q. AWS에서 OCI로 MySQL 마이그레이션 시 다운타임은 얼마나 발생하나요?
Replication 기반 온라인 마이그레이션을 사용하면 커트오버 시점에 수 분 이내의 다운타임으로 전환할 수 있어요. 초기 풀 덤프 단계에서는 소스 DB에 부하가 발생할 수 있지만, 서비스 중단 없이 진행 가능해요. 데이터 규모가 수 TB를 넘으면 초기 동기화에 수일이 걸릴 수 있으므로, 충분한 리드타임을 확보해야 해요.
Q. Cloud Connect 없이 인터넷 VPN으로 마이그레이션해도 되나요?
기술적으로 가능하지만 권장하지 않아요. 대량 데이터 전송 시 인터넷 VPN은 대역폭 변동이 크고, 전송 중 패킷 손실로 인한 재전송이 발생할 수 있어요. 특히 Replication 기반 동기화에서 네트워크 불안정은 복제 지연으로 직결돼요. 마이그레이션 기간에만 한시적으로 전용 회선을 사용하는 것도 방법이에요.
Q. MySQL HeatWave로 전환하면 기존 애플리케이션 코드를 수정해야 하나요?
MySQL 8.0 호환이므로 대부분의 경우 애플리케이션 코드 수정 없이 엔드포인트만 변경하면 돼요. 다만 AWS 전용 기능(RDS Proxy, IAM 인증, Aurora 전용 파라미터)을 사용하고 있다면 해당 부분은 OCI 방식으로 전환해야 해요. PoC 단계에서 전체 기능 테스트를 통해 호환성을 사전 검증하는 게 중요해요.
Q. 마이그레이션 중 AWS와 OCI를 동시에 운영하면 비용이 두 배로 나오나요?
하이브리드 운영 기간에는 양쪽 비용이 동시에 발생해요. 하지만 OCI 쪽은 PoC/검증 단계에서는 최소 스펙으로 운영하고, 커트오버 직전에 프로덕션 스펙으로 스케일업하면 중복 비용을 최소화할 수 있어요. 일반적으로 하이브리드 기간은 4–8주 정도이며, 이 기간의 추가 비용은 마이그레이션 프로젝트 예산에 포함시켜야 해요.
Q. PoC에서 성능이 기대에 못 미치면 어떻게 하나요?
PoC 결과가 Go 기준에 미달하더라도 바로 포기할 필요는 없어요. MySQL HeatWave의 Autopilot 기능으로 쿼리 최적화를 시도하거나, 인스턴스 스펙 조정, 인덱스 튜닝 등으로 개선 여지가 있는지 확인해요. 그래도 기준에 못 미치면 부분 마이그레이션(분석 워크로드만 이관)이나 현행 유지 + 비용 최적화를 대안으로 검토해요.