오라클 A1 한도 축소, 24GB 서버를 12GB로 줄인 실전 기록

오라클 클라우드 Always Free A1 한도가 4 OCPU/24GB에서 2 OCPU/12GB로 줄었습니다.

돌리고 있던 제 서버도 결국 손수 다운그레이드했습니다.

먼저 결론부터 — 인스턴스를 지우지 않고 셰이프만 줄이는 게 제일 안전했습니다.

백업부터 콘솔 편집, 메뉴가 안 보일 때 CLI 우회까지 실제로 밟은 순서를 그대로 담았습니다.

핵심은 하나입니다. 인스턴스를 삭제하지 말고,
백업 후 셰이프를 2 OCPU / 12GB로 편집하세요.
A1 자리는 한 번 놓치면 다시 잡기 어렵습니다.

왜 이 이야기를 다시 쓰나

지난 글에서 오라클이 사전 공지 없이 A1 무료 한도를 절반으로 줄였다는 소식을 다뤘습니다.

2026년 6월경 Linuxiac, TerminalBytes, GeekNews에서 공통으로 확인된 내용입니다.

그런데 소식만 전하고 끝내기엔 찜찜했습니다.

저부터가 최대 한도인 4 OCPU/24GB 인스턴스를 실제로 돌리고 있었거든요.

새 한도를 넘는 인스턴스는 중지될 수 있다고 하니, 언제 멈출지 모르는 채로 두느니 먼저 줄이기로 했습니다.

구분	축소 전	축소 후
A1 최대 사양	4 OCPU / 24GB	2 OCPU / 12GB
월 OCPU 시간	3,000시간	1,500시간
월 메모리 시간	18,000 GB시간	9,000 GB시간
블록 스토리지	총 200GB	변경 확인 안 됨 (발행 전 공식 확인 필요)

---

제 서버 구성 — 4 OCPU / 24GB / 100GB

제 서버는 A1 4 OCPU, 램 24GB, 블록 스토리지 100GB 구성이었습니다.

램이 반토막 나니 돌리던 것들 중 뭘 남기고 뭘 접을지부터 정리해야 했습니다.

12GB에서도 개인용 서비스 몇 개는 넉넉히 돌아갑니다.

다만 24GB만 믿고 여유롭게 얹어둔 것들은 우선순위를 다시 매길 수밖에 없죠.

그나마 스토리지는 이번 축소 대상이 아니었습니다.

이번 조치는 컴퓨트 한도 얘기라, 100GB에 쌓아둔 데이터는 그대로 두고 CPU와 램만 손보면 됩니다.

스토리지 정책까지 바뀔지는 발행 전 공식 문서 확인이 필요합니다.

---

다운그레이드 실제 진행 순서

1단계 — 백업부터, 편집은 그다음

셰이프를 바꾸면 재부팅이 따라옵니다.

편집 버튼을 누르기 전에 부트 볼륨 백업이나 스냅샷부터 만들어 두세요.

서비스가 잠깐 멈추니, 트래픽 적은 시간대로 계획을 잡으면 마음이 편합니다.

☐ 부트 볼륨 백업 또는 스냅샷 생성
☐ 중요 데이터 별도 백업 확인
☐ 재부팅에 따른 중단 시간대 결정

2단계 — 콘솔에서 셰이프 편집

콘솔에서 Compute → Instances → 인스턴스 → Actions → More Actions → Edit로 들어갑니다.

Shape 섹션을 펼쳐 OCPU를 2, 램을 12GB로 고치면 됩니다.

실행 중이라 편집이 안 되면 인스턴스를 중지한 뒤 편집하고 다시 켜세요.

⚠️ 가장 조심할 부분은 "중지(Stop)"와 "종료(Terminate)"의 혼동입니다.

종료는 삭제입니다.

실제로 이 둘을 헷갈려 인스턴스를 날린 사례가 보고되고 있습니다.

A1은 "Out of host capacity" 문제로 재배정이 어려워, 한 번 지우면 같은 자리를 다시 잡기 매우 힘듭니다.

3단계 — Shape 항목이 안 보이면 CLI로

계정에 따라 편집 화면에 Shape 항목이 아예 안 보이기도 합니다.

이럴 땐 콘솔 상단의 Cloud Shell을 열고 아래 명령으로 직접 바꾸면 됩니다.

oci compute instance update \
  --instance-id [인스턴스 OCID] \
  --shape-config '{"ocpus": 2, "memoryInGbs": 12}'

재부팅 후 접속해서 free -h로 램이 12GB로 잡혔는지 확인하면 끝입니다.

✅ 백업 완료 → ✅ 셰이프 2 OCPU/12GB 변경 → ✅ 재부팅 후 서비스 정상 확인

---

솔직히 아쉬운 점

작업 자체는 어렵지 않았습니다.

아쉬운 건 다른 데 있습니다.

사전 공지 없이 조용히 한도가 줄었다는 점이 제일 큽니다.

"평생 무료 4코어 24기가"를 보고 서버를 꾸린 입장에선, 어느 날 그 절반이 기준이 되어 있으면 신뢰가 흔들립니다.

콘솔 UI가 계정마다 다르게 보이는 것도 불편했습니다.

누구는 편집 화면에서 바로 바꾸는데, 누구는 CLI까지 열어야 하니까요.

그리고 언제 또 바뀔지 모른다는 불안이 남습니다.

무료 인프라에 핵심 서비스를 올려두는 것 자체가 리스크라는 걸 다시 실감했습니다.

---

짚어야 할 핵심 4가지

체크 포인트	이유
1. 새 한도(2/12) 초과 여부 지금 확인	초과 인스턴스는 중지될 수 있음
2. 삭제 금지, 다운그레이드로 대응	재배정이 어려워 인스턴스 자리 자체가 자산
3. 백업 먼저, 편집은 그다음	재부팅 수반, 중지·종료 혼동 사고 방지
4. 스토리지 유지, 유료 전환은 신중히	스토리지·유료 한도 축소는 아직 미확정

4번을 덧붙이면, 유료(PAYG) 한도 축소는 아직 루머 수준이지 확정이 아닙니다.

유료로 4/24를 유지하면 월 27달러 안팎이라는 추정이 돌지만 단일 소스라, 발행 전 공식 확인이 필요합니다.

확정되기도 전에 급하게 카드부터 등록할 이유는 없다고 봅니다.

[이미지 4 자리]

---

결론 — 자리를 지키는 다운그레이드

이번 대응을 한 문장으로 줄이면 "지우지 말고 줄여라"입니다.

백업 먼저, 그다음 콘솔이나 CLI로 셰이프를 2 OCPU/12GB로 편집하세요.

데이터와 IP, 그리고 다시 잡기 힘든 A1 자리를 고스란히 지킬 수 있습니다.

램이 절반이 됐으니 서비스 우선순위 정리는 피할 수 없지만, 개인 서버라면 12GB도 결코 작지 않습니다.

다만 이번 일을 계기로, 무료 한도에 전부를 걸지 않고 백업과 이전 계획을 늘 챙기게 됐습니다.

이 글은 직접 진행한 다운그레이드 경험과 현재까지 확인 가능한 공개 정보를 기준으로 정리했으며, 강제 적용 일정, 스토리지 정책, 유료 한도와 요금 수치는 발행 전 공식 문서 확인이 필요합니다.