AWS EC2 인프라 철수기 - 2. 대안 분석, 결정, 그리고 회고

7 분 소요

이전 글에서 AWS EC2 사용 현황을 분석하고, 왜 철수를 고민하게 되었는지 문제를 제기했다. 이 글에서는 구체적인 대안을 검토하고, 최종 결정을 내리기까지의 과정을 다룬다. 그리고 전체 의사결정 과정을 돌아보며 배운 점도 함께 정리한다.

대안 검토

문제를 인식한 후, 세 가지 방향의 대안을 검토했다.

클라우드 유지 + 최적화: EC2 Right-sizing, 과금 방식 변경
클라우드 프로바이더 변경: 타 클라우드로 이전
온프레미스 이전: 클라우드 탈출

대안 1: 클라우드 유지 + 최적화

Right-sizing

현재 c5.4xlarge(16 vCPU, 32GB)가 과도하게 큰 인스턴스인지 검토했다. 문제는 CPU/메모리 사용률 데이터를 확인해 본 적이 없다는 것이다. CloudWatch로 볼 수 있었지만 확인하지 않았다.

그럼에도 워크로드 특성상 추정해 보면, Frontend 서빙만 하는 상황에서 16 vCPU는 과도해 보인다. 절반 수준인 c5.2xlarge(8 vCPU, 16GB)로도 충분할 가능성이 높다.

인스턴스 타입	vCPU	메모리	시간당 비용	월 비용 (730h 기준)	절감률
c5.4xlarge (현재)	16	32GB	$0.768	약 $560	-
c5.2xlarge	8	16GB	$0.384	약 $280	50%
t3.xlarge	4	16GB	$0.166	약 $121	78%

비용은 AWS 서울 리전(ap-northeast-2) On-Demand 기준이며, 월 730시간(24시간 × 약 30일) 운영을 가정했다. 실제 비용은 EBS, 네트워크 등 추가 요소에 따라 달라질 수 있다.

Right-sizing만으로도 상당한 비용 절감이 가능하다.

과금 방식 변경

현재 On-Demand 방식을 사용하고 있다. 24시간 풀가동하는 워크로드라면 Reserved Instance(RI)나 Savings Plan이 더 적합했을 것이다.

Reserved Instance: 1-3년 약정, 30-70% 할인
Savings Plan: 시간당 금액 약정, RI보다 유연하지만 할인율 낮음
Spot Instance: 최대 90% 할인, 하지만 언제든 회수 가능하여 Frontend 서빙에는 부적합

다만, 지금 시점에서 RI를 구매하는 것은 오히려 손해다. 클라우드 탈출을 고려하고 있기 때문이다.

대안 2: 클라우드 프로바이더 변경

타 클라우드로 이전하면 비용이 나아질까?

프로바이더	리전	동급 인스턴스	예상 비용	비고
AWS	서울	`c5.4xlarge`	기준	현재
Azure	Korea Central	`F16s v2`	비슷	유의미한 차이 없음
GCP	asia-northeast3	`n2-standard-16`	약간 비쌈	스토리지 비용 높음
국내 클라우드	한국	동급	약 30% 저렴	마이그레이션 비용 고려 필요

글로벌 클라우드 간에는 유의미한 가격 차이가 없다. 국내 클라우드가 다소 저렴하지만, 마이그레이션 비용과 학습 곡선을 고려하면 매력적이지 않다.

대안 3: 온프레미스 이전

가장 근본적인 대안은 클라우드를 떠나는 것이다.

비용을 비교해 보았다.

현재 AWS: 월 약 80만 원, 연간 약 1,000만 원
온프레미스 이전 시: 초기 서버 구매 비용 외에는 전력/관리비 정도

동급 사양 서버를 새로 구매한다면 비용은 일회성이다. 1년이면 본전, 2년차부터는 연간 1,000만 원 가까이 절감 가능하다.

다만, 이미 사내에 유휴 리소스가 있다면 이야기가 달라진다. 서버를 새로 구매할 필요가 없으니, 이전하는 즉시 월 80만 원이 절감된다.

결정 근거

근본적인 문제

인스턴스 타입을 낮추거나, 저렴한 타 클라우드로 이동하는 방향도 있다. 하지만 근본적인 문제는 해결되지 않는다.

“이 워크로드는 클라우드에 부적합하다.”

클라우드의 핵심 가치는 탄력성과 글로벌 확장성이다. 우리는 이 가치를 활용하지 못하고 있다. 비용만 낮춘다고 해서 이 본질적인 미스매치가 해결되지는 않는다.

온프레미스 이전 결정

최종적으로 온프레미스 이전을 결정했다. 근거는 다음과 같다.

워크로드 특성: 사내 연구자 중심, 예측 가능한 트래픽, 확장 필요성 낮음
인프라 역량: 이미 사내에서 쿠버네티스 클러스터를 운영하고 있음
비용 효율: 장기적으로 상당한 비용 절감 가능
클라우드 이점 미활용: 현재 탄력성, 글로벌 확장성 등 핵심 가치를 활용하지 못함

예상 문제점 및 대안

EC2 철수 시 예상되는 문제점과 대안을 정리했다.

문제 1: Frontend 서빙

문제: AWS EC2 노드에서 Frontend 파드가 서빙되고 있다.

대안: 사내망에서 외부 접근 가능한 서버로 이전하면 된다. 이미 Backend는 온프레미스 클러스터로 이전한 상태이므로, Frontend도 동일한 방식으로 처리 가능하다.

문제 2: Model Repository 외부 접근

문제: 외부 Edge 장비에서 Triton Model Repository(MinIO)에 접근해야 한다. 현재는 AWS Elastic IP를 통해 접근하고 있다.

이 문제가 핵심이다. AWS를 떠나면 외부에서 사내망 MinIO에 어떻게 접근할 것인가?

검토한 대안:

MinIO를 외부 접근 가능한 서버로 이전
MinIO Reverse Proxy 구성
AWS S3 사용

AWS를 떠나면서 왜 S3는 고려하는가? EC2를 떠나려는 이유는 “24시간 풀가동 컴퓨팅 리소스에 클라우드가 맞지 않다”는 것이었다. 반면 S3는 성격이 다르다. 사용한 만큼만 과금되고, 외부 접근 가능한 오브젝트 스토리지라는 클라우드 고유의 이점을 그대로 활용할 수 있다. 매니지드 서비스라 유지보수 부담도 없다.

S3 비용 예측

S3를 사용하면 비용이 얼마나 들까? 현재 사용량 기준으로 예측해 보았다.

S3 비용 구성 요소:

스토리지 비용: GB-월 단위
요청 비용: GET, PUT 등 요청당 과금
데이터 전송 비용: Outbound 트래픽

현재 MinIO 사용량 (2025년 12월 기준):

저장 용량: 약 32GB (모델 파일 + 이벤트 데이터)
요청 횟수: 월 약 800건 수준

사용량이 적은 이유: 현재 사내 엔지니어들이 주로 사용하는 시스템이라 트래픽이 많지 않다. 서비스 사용이 활발해지면 달라질 수 있지만, 현 시점 기준으로 예측한다.

S3 Standard 기준 예상 비용:

스토리지: 32GB × $0.025/GB = 약 $0.8/월
요청 비용: 거의 무시 가능한 수준
─────────────────────────────────
총 예상 비용: 월 $1 미만

예상보다 훨씬 저렴하다. S3는 EC2처럼 On-Demand로 시간당 과금되는 것이 아니라, 순수하게 사용한 만큼만 과금된다. 소규모 사용량에서는 극적으로 저렴해질 수 있다.

사용량 증가 시나리오:

현재 사용량이 대폭 증가해도 비용이 감당 가능한지 확인해 보았다.

$51 / $0.025/GB = 약 2,000GB 저장 가능
현재 사용량: 32GB
여유: 약 60배 증가해도 동일 비용

현재 사용량의 60배가 증가해도 월 $51 수준이다. 물론 요청 비용과 데이터 전송 비용이 추가되지만, 현재 규모에서는 무시 가능한 수준이다.

MinIO 유지보수 모드 전환 리스크

S3를 고려하게 된 또 다른 이유가 있다. MinIO 커뮤니티 에디션이 2025년 12월 유지보수 모드로 전환되었다.

2025년 MinIO 정책 변화:

2025년 2월: 웹 콘솔 관리 기능 제거
2025년 10월: Docker 이미지 배포 중단
2025년 12월: 유지보수 모드 전환 (새 기능 개발 중단, 보안 패치도 사안별 평가)

사실상 커뮤니티 버전의 개발이 중단된 것이다. 새로운 인프라에 MinIO를 선택하는 것은 기술 부채를 쌓는 결정이 될 수 있다.

참고: MinIO 유지보수 모드 공지

물론 기존에 운영 중인 MinIO를 당장 마이그레이션해야 하는 것은 아니다. 하지만 새로운 Model Repository를 구축한다면, MinIO보다는 S3나 다른 대안(Ceph, SeaweedFS 등)을 고려하는 것이 현명해 보인다.

최종 결정

팀 내 논의를 거쳐 다음과 같이 결정했다.

EC2 철수: 온프레미스로 완전 이전
Frontend: 사내망 외부 접근 가능 서버로 이전
Model Repository: AWS S3 사용

S3는 월 $1 미만의 비용으로 외부 접근 가능한 Model Repository를 제공한다. MinIO 유지보수 부담도 사라지고, HTTPS 인증서 관리도 AWS가 해준다. 보안적으로도 사내망을 직접 열 필요가 없어 더 안전하다.

후속 조치

S3 사용 시 장점

보안: 사내망을 외부에 노출하지 않아도 됨
HTTPS: AWS가 제공하는 인증서 사용 가능
유지보수 부담 감소: MinIO 구축/운영/메모리 누수 이슈 등 관리 포인트 없음
종량제: 사용한 만큼만 비용 발생

마이그레이션 계획

Frontend 이전: 사내망 외부 접근 가능 노드로 이동
S3 버킷 생성: Model Repository용 버킷 구성
데이터 마이그레이션: 기존 MinIO 데이터 중 필요한 것만 S3로 이전
애플리케이션 설정 변경: Triton 등 Model Repository 접근 주소 변경
AWS 리소스 정리: EC2, EBS, VPN 등 삭제

AWS 리소스 정리

마이그레이션 완료 후:

EC2 인스턴스 종료 및 삭제
EBS 볼륨 삭제 (필요한 데이터 백업 후)
Elastic IP 해제
Site-to-Site VPN 연결 해제
리셀러 계약 검토

S3 도입 시 고려사항

비용 최적화:

S3 Intelligent-Tiering: 접근 패턴에 따라 자동 최적화
태깅 전략: 리소스별 태그로 비용 추적
예산 알림 설정: 예상치 못한 비용 증가 방지

보안:

IAM 정책 최소 권한 원칙
버킷 정책 설정
접근 로깅 활성화

현재 데이터 규모는 작지만, 향후 확장을 대비해 처음부터 좋은 관행을 적용해 두는 것이 좋다.

의사결정 과정 돌아보기

초기 검토 문서를 다시 찾아보았다. 당시 CPU/GPU 노드 구성을 검토한 흔적이 있었지만, 실제 결정 근거는 남아 있지 않았다. 인스턴스 타입 변경 이력도 마찬가지였다.

초기에는 빠른 실행이 우선이었다. 비즈니스 방향이 여러 번 바뀌는 과정에서 인프라 재점검 타이밍을 놓쳤고, 리셀러를 통해 사용하다 보니 비용 가시성도 낮았다. 결과적으로, 현재 단계에 맞지 않는 비용을 지속적으로 지불해 왔다.

배운 점

1. 인프라 구축 의사결정이 너무 중요하다

인프라 결정은 한번 내리면 쉽게 바꾸기 어렵다. 특히 클라우드는 시간이 지날수록 비용이 누적되기 때문에, 초기 결정이 더욱 중요하다.

앞으로 인프라 결정 시 반드시 해야 할 것을 정립하고자 한다.

워크로드 특성 분석: 클라우드가 정말 필요한가?
비용 예측: 월별/연별 비용을 구체적으로 산정
대안 비교: 온프레미스, 타 클라우드 등 대안과 비교
결정 근거 문서화: 왜 이 선택을 했는지 기록

2. 모니터링과 관측 가능성의 중요성

이번 분석에서 가장 아쉬웠던 것은 CPU/메모리 사용량 데이터가 없다는 것이다.

실제 사용률 데이터가 있었다면:

Right-sizing을 훨씬 정확하게 할 수 있었다
16 vCPU 중 실제로 몇 %를 사용했는지 알 수 있었다
의사결정에 명확한 근거를 제시할 수 있었다

CloudWatch로 CPU/메모리 사용률을 볼 수 있었는데, 확인하지 않았다. 도구가 없어서가 아니라 보는 습관이 없었던 것이 문제였다.

3. 클라우드가 능사는 아니다

클라우드를 떠나는 것이 트렌드에서 후퇴하는 것 아닌가? 처음에는 그런 생각이 들기도 했다. 하지만 그렇지 않다.

Right-sizing infrastructure to business stage.

이번 경험을 통해 느낀 것은, 비즈니스 단계에 맞는 인프라를 선택하는 것이 중요하다는 점이다. 적어도 우리 케이스에서는, 클라우드의 핵심 가치(탄력성, 글로벌 확장성)를 활용하지 못하면서 비용만 지불하고 있었다. 그렇다면 굳이 클라우드에 남아 있을 이유가 없었다.

4. 클라우드 네이티브 사고방식은 유지하자

클라우드를 떠나더라도, 클라우드 네이티브 사고방식은 여전히 유효하다.

Infrastructure as Code: Terraform 등으로 인프라 코드화
컨테이너 기반 배포: 쿠버네티스 유지
자동화된 CI/CD: 배포 파이프라인 자동화
관측 가능성: 모니터링, 로깅, 트레이싱

이런 원칙들은 온프레미스에서도 동일하게 적용된다. 인프라가 어디에 있느냐보다, 어떻게 운영하느냐가 더 중요하다.

마무리

이번 경험은 많은 것을 가르쳐 주었다. 비즈니스 탐색 단계에서는 빠른 실행이 중요하지만, 어느 시점에서는 인프라 비용도, 의사결정 근거도, 모니터링도 점검해야 한다는 것을 배웠다.

초기에 클라우드를 선택한 것 자체가 잘못은 아니었다. 당시 비즈니스 방향에는 맞는 선택이었다. 다만, 비즈니스 방향이 바뀌었을 때 인프라도 함께 재점검했어야 했다. 늦게라도 문제를 인식하고 개선한 것에 의미를 두고 싶다.

앞으로는 인프라 결정에 더 신중해지고, 모니터링을 게을리하지 않고, 비용과 효용의 균형을 지속적으로 점검할 것이다.

Twitter Facebook LinkedIn

Eraser