---
title: "온프레미스에서 클라우드로: 우당탕탕AWS 마이그레이션 실전기"
description: "온프레미스에서 AWS 클라우드로 이전하며 멀티 VPC·EKS·RDS·MSK를 적용한 올라핀테크 데이터엔지니어링팀의 클라우드 마이그레이션 사례입니다. 가용성 99.95% 달성, 배포 시간 1시간→10분 단축, 보안·운영 자동화·비용 최적화까지 정리했습니다. “작은 불편에"
canonical_url: "https://allrafintech.co.kr/blog/125"
category: "데이터"
publisher: "올라핀테크"
date_published: "2026-07-21 17:30:20"
date_modified: "2026-07-21 17:30:20"
language: "ko-KR"
image: "https://static.revn.co.kr/in-blog/prod/20260721_172232_33a18cc9.jpg"
---
# 온프레미스에서 클라우드로: 우당탕탕AWS 마이그레이션 실전기
올라핀테크 · 데이터 · 2026-07-21 17:30:20
원문(HTML): https://allrafintech.co.kr/blog/125
---
> 온프레미스에서 AWS 클라우드로 이전하며 멀티 VPC·EKS·RDS·MSK를 적용한 올라핀테크 데이터엔지니어링팀의 클라우드 마이그레이션 사례입니다. 가용성 99.95% 달성, 배포 시간 1시간→10분 단축, 보안·운영 자동화·비용 최적화까지 정리했습니다.
***“작은 불편에서 출발해, 모두가 편해지는 순간까지. 올라핀테크 팀의 이야기를 공유합니다.”***
AWS클라우드 마이그레이션은 선택이 아닌 필수
## 클라우드 마이그레이션은 필수
디지털 전환의 시대에서 클라우드 마이그레이션은 더 이상 선택이 아닌 필수입니다. 특히 저희처럼 핀테크 서비스를 운영하고 있다면 안정성과 확장성, 그리고 보안성이 더더욱 중요한데요. 이는 클라우드 전환 자체가 곧 비즈니스 성장에 직결되는 핵심 동력이라는 말이기도 합니다.
저희가 운영하고 있는 당시 “[올라 선정산](https://allra.co.kr/)” 서비스 또한 2025년 내 기존 선정산 서비스의 편의성 및 안정성 극대화부터 초간편 자금관리 서비스로의 확장까지 계획되어 있었는데요. 다양하고 빠른 변화가 필요한 환경에 맞춰 대응하기 위해 기존의 온프레미스 환경에서 AWS 클라우드로의 전환을 결정했습니다.
### 마이그레이션 전 온프레미스 아키텍처
저희가 운영하는 프로덕트의 온프레미스 인프라 구성은 아래와 같았어요.
* 웹 서버: Nginx 기반 Load Balancer
* 애플리케이션 서버: Spring Boot 기반 Java 애플리케이션 (다중 인스턴스)
* 데이터베이스: MariaDB
* 캐시: Redis
이 구성은 서비스의 초기 운영에는 적합했지만, 트래픽 증가와 함께 다음과 같은 한계가 드러나게 됩니다.
* **확장성 부족:** 순간적인 자원 사용량 증가에 대응이 어려움
* **운영 복잡성:** 배포 및 패치 시 수동 절차 다수
* **비용 비효율성:** 유휴 자원에 대한 고정 비용 발생
* **보안 관리 부담:** 주기적인 패치 및 보안 업데이트의 복잡성
AWS클라우드 마이그레이션 계획 과정
## AWS 클라우드 마이그레이션 전환 계획
데이터 엔지니어링 팀은 정확한 목표를 가지고 계획을 수립해나갔습니다. 내용이 방대할 수 있습니다. 가독성이 좋게 정리했지만 참고 부탁드립니다!
### #1 전환 목표
클라우드 마이그레이션을 통해 아래 네 가지 목표를 달성하고자 했어요.
1. **고가용성 확보:** 99.9% 이상의 서비스 가용성 달성
2. **운영 효율화:** DevOps 자동화를 통한 배포 및 운영 간소화
3. **보안 강화:** 관리형 인스턴스 활용으로 보안 패치 부담 완화
4. **비용 최적화:** 사용량 기반 과금으로 유휴 자원 최소화
### #2 아키텍처 설계
보안 정책을 고려하여 다음과 같은 멀티 VPC 아키텍처를 설계했습니다.
**VPC 구성**
* **Security VPC**: 사무실과 Site-to-Site VPN 연결, 보안 관리 중앙화
* **Production VPC**: 운영 환경, Security VPC와 피어링 연결
* **Development VPC**: 개발/테스트 환경, Security VPC와 피어링 연결
**VPC별 구성사항**
**Security VPC**
* **네트워크 프록시:** 내부서비스 접속을 위한 단일 프록시 서버
* **내부 전용 DNS 서버:** 내부서비스 도메인 질의를 위한 전용 DNS 서버
**Production VPC**
* **EKS 클러스터**: Kubernetes 기반 컨테이너 오케스트레이션
* **RDS MariaDB**: Multi-AZ 구성으로 고가용성 확보
* **ElastiCache Redis**: 캐시 및 세션 관리
* **MSK (Managed Streaming for Kafka)**: 메시지 스트리밍
* **Application Load Balancer**: L7 로드밸런싱 및 SSL 터미네이션
**Development VPC**
* Production과 동일한 구성의 축소 버전
* 개발 및 스테이징 환경용
### #3 마이그레이션 전략
마이그레이션 전략은 총 5단계, 준비기간까지 합하면 3개월 정도지만 계획은 약 1.5개월을 잡고 진행했어요.
1. **Phase 1(2주)**: 인프라 구축 (VPC, EKS, RDS 등)
2. **Phase 2(3주)**: 애플리케이션 컨테이너화 및 배포
3. **Phase 3(1주)**: 데이터 마이그레이션
4. **Phase 4(1일)**: DNS 전환 및 서비스 오픈
5. **Phase 5(유지)**: 모니터링 및 최적화
### #4 주요 고려사항
**1. 리소스 확보**
* 서비스 오픈 시 자원 부족으로 인한 장애 방지
* 기존 온프레미스 대비 120% 이상의 여유 자원 확보
**2. 외부 연동 호환성**
* 금융기관 API 등 핵심 외부 서비스와의 원활한 통신 보장
* 기존 IP 화이트리스트 기반 연동의 새로운 IP 대역 등록
* SSL/TLS 인증서 갱신 및 도메인 설정
**3. 보안 정책 준수**
* 금융 서비스 특성상 엄격한 클라우드 보안 요구사항 충족
* 개인정보보호법, 전자금융거래법 등 관련 법규 준수
* 네트워크 분리 및 접근 제어 정책 적용
**4. 서비스 중단 최소화**
* 완전 무중단 마이그레이션보다는 계획된 다운타임 활용
* 주말 시간대 활용으로 사용자 영향 최소화
* 빠른 롤백 계획 수립
추가로 기술적인 고려 사항은 다음과 같았습니다.
**컨테이너화 전략**
* Spring Boot 애플리케이션의 Docker 이미지 최적화
* 멀티 스테이지 빌드를 통한 이미지 크기 최소화
**데이터 마이그레이션**
* 서비스 규모 대비 데이터 크기가 적어 단순 백업/복원 방식 선택
* 마이그레이션 전 데이터 정합성 검증 절차 수립
* 테스트 환경에서의 사전 검증
AWS 클라우드 마이그레이션 전략
## AWS 클라우드 마이그레이션 단계별 전환 과정
### **Phase 1: 인프라 구축 (2주)**
**AWS 기본 인프라 설정**
\- Security, Production, Development VPC 생성
\- 각 VPC별 public, private 서브넷 설정
\- VPC Peering 연결 설정
\- Site-to-Site VPN 구성 및 연동
**EKS 클러스터 구축**
* 용도별 관리형 노드 그룹 구성
* AWS Load Balancer Controller 설치
**데이터베이스 및 캐시 구성**
* RDS MariaDB 구성
* ElastiCache Redis 7 구성
### **Phase 2: 애플리케이션 컨테이너화 (3주)**
**Kubernetes 매니페스트 작성**
* Deployment, Service, Ingress 리소스 정의
* ConfigMap 및 Secret을 통한 설정 관리
**CI/CD 파이프라인 구축**
* 각 서비스별 Dockerfile, Jib을 이용한 컨테이너화
* GitHub Actions를 통한 자동 빌드/테스트
* ECR (Elastic Container Registry)을 통한 이미지 관리
* ArgoCD를 통한 GitOps 방식 배포
### **Phase 3: 데이터 마이그레이션 (1주)**
**데이터베이스 마이그레이션**
1. 온프레미스 MariaDB 백업 생성
2. AWS RDS로 데이터 복원
3. 애플리케이션 설정 변경 (데이터베이스 연결 정보)
4. 데이터 정합성 검증
**캐시 및 설정 마이그레이션**
* Redis 데이터 동기화
* 환경별 일부 설정 값 ConfigMap으로 이관
### **Phase 4: DNS 전환 및 서비스 오픈 (1일)**
**전환 당일 프로세스**
1. 서비스 점검 공지 (토요일 오전 11시\~자정까지)
2. 최종 데이터 동기화
3. DNS 레코드 AWS ALB로 변경
4. 서비스 정상 확인
5. 모니터링 강화
### **Phase 5: 모니터링 및 최적화 (지속적)**
**모니터링 체계 구축**
* 데이터독 오퍼레이터를 통한 연동
* 알람 및 대시보드 구성
**성능 최적화**
리소스 사용량 분석 및 인스턴스 타입 최적화
AWS클라우드 마이그레이션의 성과
## AWS 클라우드 마이그레이션의 성과
기존 온프레미스에서 클라우드 전환을 마치고 저희는 아래와 같은 성과를 얻을 수 있었어요.
* **가용성 향상**: 99.9% → 99.95% 서비스 가용성 달성
* **배포 효율성**: 배포 시간 1시간 → 10분으로 단축
* **개발 생산성**: DevOps 자동화로 개발팀 효율성 향상
* **서비스 안정성**: 장애 복구 시간 대폭 단축
## 마이그레이션 과정에서 겪은 문제와 해결책
단순히 성과만 얻을리가 만무하죠. AWS 클라우드로 마이그레이션하면서 겪은 문제 그리고 해결한 방법 두 가지를 소개하려고 합니다.
#### **예상치 못한 프록시 서버 발견**
**문제 상황**
* 오픈 전 테스트 과정에서 특정 외부 연동 서비스가 동작하지 않는 현상 발견
* 기존 온프레미스에서 특정 도메인의 특정 경로로 들어오는 연결을 내부 서버로 프록시하는 웹서버가 존재했음을 뒤늦게 발견
**해결 방안**
```ts
# ALB Ingress Rule 추가 설정
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: proxy-ingress
annotations:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
alb.ingress.kubernetes.io/group.name: 'example-alb'
alb.ingress.kubernetes.io/group.order: 1 # 다른 ingress보다 우선순위 높여주기
spec:
rules:
- host: external-service.domain.com
http:
paths:
- path: /specific-path/*
pathType: Prefix
backend:
service:
name: forward-target
port: 1234
```
### **서비스 오픈 후 예상보다 높은 트래픽으로 인한 병목 현상**
**문제 상황**
* 과소 측정된 사용량으로 인해 특정 서버(API 서버)에 과부하 발생
* 응답 시간 증가 및 일부 타임아웃 에러 발생
**해결 방안**
\- 즉시 병목이 발생하는 서버의 Pod 수를 증가시켜 트래픽 분산 처리
### 값진 교훈
이번 클라우드 마이그레이션 프로젝트에서도 값진 교훈들을 얻을 수 있었어요.
1. **철저한 사전 조사의 중요성**: 기존 시스템의 모든 구성 요소를 상세히 파악해야 함
2. **충분한 여유 자원 확보**: 예상보다 넉넉한 리소스 할당의 필요성
3. **단계별 검증**: 각 단계별 충분한 테스트와 검증 과정의 중요성
4. **모니터링 체계**: 실시간 모니터링과 알람 시스템의 필수성
클라우드 마이그레이션은 기술적 전환을 넘어 조직의 개발 문화를 현대화하고, 비효율적인 절차를 간소화할 수 있는 중요한 계기가 되었습니다. 비록 그 과정에서 예상치 못한 문제들을 마주했지만, 이를 통해 더욱 견고하면서 향후 유연하게 확장이 가능한 시스템을 구축할 수 있었습니다.
***“올라핀테크 팀은 앞으로도 문제를 해결한 과정을 꾸준히 기록하고 나누겠습니다!”***
> write. 데이터엔지니어링팀 임종원
### 올라핀테크 팀의 이전 이야기👇
* [유저가 떠나는 순간을 붙잡다: 탈퇴율 17% 감소 UX 개선 사례](https://allrafintech.co.kr/blog/124 "유저가 떠나는 순간을 붙잡다: 탈퇴율 17% 감소 UX 개선 사례")
* [사내 AI 챗봇 도입 사례 — 올라핀테크의 챗봇 “올챙이” 구축기 🐸](https://allrafintech.co.kr/blog/120 "사내 AI 챗봇 도입 사례 — 올라핀테크의 챗봇 “올챙이” 구축기 🐸")
* [올라핀테크의 첫 인상, 기업 홈페이지 제작기](https://allrafintech.co.kr/blog/121 "올라핀테크의 첫 인상, 기업 홈페이지 제작기")