Oracle의 무료 티어 리소스 축소가 시사하는 것
Oracle Cloud의 Always Free 티어는 개인 개발자나 소규모 팀이 비용 부담 없이 클라우드 인프라를 활용할 수 있는 수단으로 주목받아 왔다. 특히 Ampere A1 컴퓨트 인스턴스는 ARM 기반 아키텍처로 4 OCPU / 24GB RAM이라는 넉넉한 스펙 덕분에 개발 환경이나 사이드 프로젝트에 자주 활용되었다. 그런데 최근 Oracle이 아무런 공식 공지 없이 이 허용량을 2 OCPU / 12GB RAM으로 절반 삭감한 사실이 알려지면서 적지 않은 파장을 일으키고 있다.
문제는 단순히 스펙이 줄었다는 것이 아니다. 공지 없는 변경 자체가 인프라 운영의 신뢰성에 직접적인 타격을 준다. 이미 해당 리소스 위에 서비스를 올려둔 개발자라면, 예고 없는 자원 축소가 배포된 애플리케이션의 가용성이나 성능에 영향을 미칠 수 있기 때문이다.
혼란을 키운 내부 정보 불일치
더 심각한 문제는 Oracle 내부에서도 일관된 답변이 나오지 않는다는 점이다. 사용자들이 지원팀에 문의했을 때, 담당자에 따라 상충되는 답변을 받았다.
- 공식 문서: 새로운 제한이 "모든 테넌시(all tenancies)"에 적용된다고 명시
- 지원 이메일: 무료 티어 계정에만 해당하며, PAYG(종량제) 계정은 영향 없다고 안내
즉, 같은 회사의 문서와 지원 채널이 서로 다른 말을 하고 있는 상황이다. 이는 단순한 커뮤니케이션 실수를 넘어, 클라우드 벤더의 정책 변경이 얼마나 불투명하게 이루어질 수 있는지를 보여주는 사례다. PAYG 계정 사용자라면 자신의 인프라가 영향을 받는지 여부조차 명확하게 파악하기 어렵다.
실무적 관점에서의 교훈
이번 사례는 특정 클라우드 벤더의 문제라기보다, 무료 또는 저비용 클라우드 리소스에 의존하는 아키텍처 설계 방식 전반에 대한 경고로 읽어야 한다. Java 백엔드 개발자 입장에서 실무적으로 다음 사항을 점검할 필요가 있다.
- 프리 티어 리소스를 프로덕션 또는 준프로덕션 환경에 사용하고 있다면, 언제든 정책 변경으로 인한 장애 리스크를 안고 있는 셈이다.
- IaC(Infrastructure as Code) 기반으로 인프라를 정의하고 있더라도, 벤더가 허용 리소스 자체를 바꾸면 재프로비저닝 시 예상치 못한 오류가 발생할 수 있다.
- 멀티 클라우드 또는 클라우드-애그노스틱 설계가 단순한 이상론이 아니라 실질적인 리스크 분산 전략이 될 수 있음을 이 사례가 보여준다.
- 운영 중인 서비스가 클라우드 무료 티어에 의존한다면, 주기적으로 벤더의 정책 페이지나 릴리즈 노트를 직접 확인하는 루틴이 필요하다. 공지가 없더라도 변경은 일어날 수 있다.
# 현재 Oracle Cloud CLI로 인스턴스 shape 정보 확인
oci compute instance get \
--instance-id <your-instance-ocid> \
--query 'data.{Shape:shape, OCPUs:"shape-config".ocpus, RAM:"shape-config"."memory-in-gbs"}'
인프라 상태를 코드나 CLI로 주기적으로 검증하는 습관은, 이런 조용한 변경을 빠르게 감지하는 데 실질적인 도움이 된다.
정리
- Oracle이 공식 공지 없이 Always Free A1 컴퓨트 허용량을 4 OCPU/24GB에서 2 OCPU/12GB로 절반 축소했으며, 이는 운영 예측 가능성을 심각하게 해친다.
- 공식 문서와 지원팀의 답변이 상충되는 상황은, 클라우드 벤더 의존도가 높을수록 정보 불확실성 리스크도 함께 커진다는 점을 상기시킨다.
- 프리 티어나 특정 벤더 정책에 의존하는 인프라는 IaC와 모니터링으로 변경을 빠르게 감지할 수 있도록 설계해야 하며, 장기적으로는 벤더 종속성을 최소화하는 방향을 고려해야 한다.