OCI A1 무료 한도 축소? 2 OCPU·12GB와 4 OCPU·24GB 계정별 비교

클라우드 2026년 8월 19일

3줄 요약

Oracle의 Always Free 문서는 A1 무료 범위를 1,500 OCPU-시간·9,000 GB-시간, 즉 2 OCPU·12GB로 안내합니다.

반면 Arm 안내는 3,000 OCPU-시간·18,000 GB-시간을, 가격표는 이를 paid tenancy(유료 테넌시)의 무료량으로 안내합니다.

모든 계정의 한도가 일괄 축소됐다는 뜻은 아닙니다. 먼저 백업하고 계정 유형·무료 체험 종료일·콘솔 경고를 확인한 뒤 필요한 조치를 결정하세요.

오라클 클라우드 무료 티어에서 OCI Ampere A1 인스턴스를 사용하고 있다면 갑자기 보이는 2 OCPU·12GB라는 수치가 당황스러울 수 있습니다. 그동안 A1 무료 범위를 4 OCPU·24GB로 알고 사용한 사람이 많기 때문입니다.

2026년 8월 19일 Oracle 공식 문서를 다시 확인해 보니, 페이지와 계정 유형에 따라 안내가 달랐습니다. Always Free 전용 문서에는 월 1,500 OCPU-시간과 9,000 GB-시간, 즉 2 OCPU·12GB가 적혀 있습니다. 반면 Arm 기반 컴퓨트 안내에는 월 3,000 OCPU-시간과 18,000 GB-시간이 무료라고 나오고, OCI 가격표는 같은 수치를 각 paid tenancy에 제공되는 무료량으로 설명합니다.

먼저 결론부터 말하면, 이 문서 차이만으로 A1 무료 한도가 모든 계정에서 축소됐다고 확정할 수는 없습니다. 오히려 Always Free 계정과 유료 테넌시의 무료 제공량을 구분해 읽어야 합니다. 장기간 운영 중인 기존 4 OCPU·24GB 인스턴스에 새 기준이 소급 적용되는지에 관한 별도 설명도 확인하지 못했습니다. 따라서 기존 서버를 서둘러 중지하거나 삭제하기보다 자신의 계정 유형과 OCI 콘솔 상태를 먼저 확인하는 편이 안전합니다.

이 글은 2026년 8월 19일에 확인한 Oracle 공식 문서를 기준으로 작성했습니다. 이후 문서와 정책이 수정될 수 있으므로 실제 변경 전에는 OCI 콘솔의 최신 표시와 계정 유형별 지원 경로를 다시 확인하세요.

계정 유형에 따라 달라 보이는 세 가지 공식 안내

Always Free Resources 문서: 2 OCPU·12GB

Oracle의 Always Free Resources 문서는 VM.Standard.A1.Flex 가상머신에 대해 매월 다음 사용량이 무료라고 안내합니다.

1,500 OCPU-시간
9,000 GB-시간
Always Free 계정 기준 환산값: 2 OCPU와 12GB 메모리
A1 인스턴스는 한 대 또는 두 대로 나눌 수 있지만 합계는 2 OCPU

31일은 744시간이므로 2 OCPU를 한 달 내내 사용하면 1,488 OCPU-시간이 됩니다. 메모리 12GB는 8,928 GB-시간이어서 문서의 월 무료 사용량 안에 들어갑니다.

이 페이지는 Always Free 컴퓨트 인스턴스는 테넌시의 홈 리전에 만들어야 한다고 안내합니다. 또한 여러 가용성 도메인이 있는 리전의 A1 생성 규칙에서 South Korea North(Chuncheon)를 예외로 명시하고 있습니다.

다만 이 문구만으로 이미 춘천에서 실행 중인 A1 인스턴스가 중지되거나 삭제된다고 해석해서는 안 됩니다. 해당 페이지에는 기존 인스턴스에 대한 소급 조치가 적혀 있지 않습니다.

Arm-Based Compute 문서: 3,000·18,000

반면 Oracle의 Arm-Based Compute 문서는 유료 계정과 평가판을 포함한 모든 A1 테넌시에 매월 다음 사용량이 무료라고 안내합니다.

3,000 OCPU-시간
18,000 GB-시간

이 수치는 31일 기준으로 계산해도 4 OCPU와 24GB 메모리를 한 달 내내 실행할 수 있는 양입니다.

4 OCPU × 744시간 = 2,976 OCPU-시간
24GB × 744시간 = 17,856 GB-시간

OCI 가격표: paid tenancy에 3,000·18,000

OCI Cloud Price List의 Compute 관련 안내는 각 paid tenancy에 처음 3,000 OCPU-시간과 18,000 GB-시간을 무료로 제공한다고 적고 있습니다. 이 무료량은 베어메탈, VM, Container Instances에서 함께 계산됩니다.

세 페이지를 간단히 정리하면 다음과 같습니다.

Always Free Resources: Always Free 계정에 1,500 OCPU-시간·9,000 GB-시간, 즉 2 OCPU·12GB
Arm-Based Compute: 유료·평가판을 포함한 A1 테넌시에 3,000 OCPU-시간·18,000 GB-시간
OCI 가격표: 각 paid tenancy에 3,000 OCPU-시간·18,000 GB-시간

수치만 비교하면 정확히 두 배 차이지만, 문서가 설명하는 계정 유형과 페이지 목적이 같지 않습니다. 따라서 이를 곧바로 동일한 대상에 상충하는 정책이나 모든 계정의 일괄 축소로 해석해서는 안 됩니다.

또한 4 OCPU·24GB는 Arm 문서와 가격표에 그대로 쓰인 표현이 아니라 월 시간 한도를 31일 상시 실행 기준으로 계산한 값입니다. 반면 Always Free 문서는 1,500·9,000을 2 OCPU·12GB와 동등한 범위라고 직접 설명합니다.

지금 확정할 수 있는 것과 없는 것

공식 문서로 확인되는 내용

Always Free 전용 페이지에는 A1 무료 제공량이 1,500 OCPU-시간과 9,000 GB-시간으로 표시됩니다.
같은 페이지는 이를 2 OCPU와 12GB 메모리로 설명합니다.
Arm-Based Compute 페이지에는 3,000 OCPU-시간과 18,000 GB-시간이 표시됩니다.
OCI 가격표는 3,000·18,000을 각 paid tenancy의 무료량으로 설명합니다.
Always Free 페이지는 A1 생성 규칙에서 춘천 리전을 예외로 명시합니다.
세 페이지는 수치와 적용 대상을 서로 다르게 설명합니다.

아직 단정하면 안 되는 내용

전 세계 모든 OCI 계정의 A1 무료 한도가 실제로 절반으로 줄었다는 결론
기존 4 OCPU·24GB 인스턴스에도 새 기준이 소급 적용된다는 주장
이번 문서 변경만으로 장기 기존 계정이 특정 날짜부터 자동 과금되거나 중지된다는 주장
춘천에서 현재 실행 중인 A1 인스턴스가 곧 회수된다는 주장
어느 페이지의 표현이 단순 오기인지, 정책 전환 과정인지에 대한 추측

Oracle이 장기간 운영 중인 기존 Always Free 계정의 별도 시행일이나 처리 방침을 명시하기 전까지는 위 내용을 사실처럼 퍼뜨리지 않는 것이 좋습니다.

무료 체험 종료 계정은 별도 주의

Oracle Free Tier FAQ에는 무료 체험이 끝날 때 Always Free 허용량보다 많은 A1 자원을 사용 중이면 모든 A1 인스턴스가 비활성화되고, 유료 계정으로 업그레이드하지 않으면 30일 뒤 삭제될 수 있다는 별도 규칙이 있습니다.

이는 장기간 운영해 온 기존 Always Free 계정에 새 한도가 소급 적용된다는 증거가 아닙니다. 다만 무료 체험 종료를 앞둔 계정이라면 백업을 먼저 만들고, 현재 OCPU·메모리 합계가 Always Free 허용량 안에 있는지 즉시 확인해야 합니다.

내 OCI 계정에서 직접 확인하는 방법

공식 문서의 기본값보다 내 테넌시에 실제로 표시되는 한도와 사용량을 먼저 확인해야 합니다.

1. A1 서비스 한도와 사용량 확인

OCI 콘솔에서 다음 경로로 이동합니다.

왼쪽 상단 탐색 메뉴를 엽니다.
Governance & Administration을 선택합니다.
Tenancy Management → Limits, Quotas and Usage로 이동합니다.
서비스는 Compute, 리전은 자신의 홈 리전으로 선택합니다.
필요하면 가용성 도메인과 컴파트먼트도 각각 바꿔 확인합니다.
검색창에서 A1, standard-a1-core-count, standard-a1-memory-count 관련 항목을 찾습니다.
Service Limit, Usage, Available 값을 기록합니다.

Oracle의 테넌시 한도 확인 문서에 따르면 콘솔은 리전별 한도와 사용량을 표시하지만, 일부 서비스나 자원이 나타나지 않을 수도 있습니다. 또한 서비스 한도는 생성 가능한 자원 범위를 뜻하므로, 그 숫자가 곧바로 Always Free 과금 기준과 같다고 단정해서는 안 됩니다. 특히 Pay As You Go 계정은 한도가 무료 범위보다 클 수 있습니다.

2. 현재 인스턴스 사양 확인

Compute → Instances에서 실행 중인 각 인스턴스를 열고 다음 정보를 적어 둡니다.

리전과 가용성 도메인
Shape: VM.Standard.A1.Flex인지 여부
할당한 OCPU
할당한 메모리
연결된 부트 볼륨과 블록 볼륨 크기

여러 A1 인스턴스를 사용한다면 OCPU와 메모리를 각각 합산해야 합니다.

3. 계정 유형에 맞게 비용 확인

Pay As You Go 또는 무료 체험 계정이라면 Billing & Cost Management → Cost Management → Cost Analysis에서 기간을 이번 달로 설정하고, 서비스 필터를 Compute로 좁혀 확인합니다. 필요하면 리전·컴파트먼트·Resource OCID 또는 제품 설명별로 그룹화합니다.

Oracle Cost Analysis 문서는 비용 데이터가 표시되기까지 최대 48시간이 걸릴 수 있다고 안내합니다. 지금 비용이 0으로 보이더라도 변경 직후라면 하루나 이틀 뒤 다시 확인하는 것이 좋습니다.

반면 Oracle의 Billing Details 문서에 따르면 Always Free 계정에는 청구·사용량 정보가 표시되지 않습니다. 이 경우 Cost Analysis가 비어 있는 것을 비용 0의 증거로 보지 말고, Limits, Quotas and Usage와 콘솔 경고, Oracle이 보낸 이메일, 인스턴스 상태를 함께 확인해야 합니다.

유료 또는 평가판 계정이라면 작은 금액의 Budget과 알림도 설정할 수 있습니다. 다만 Budget은 지출을 차단하는 기능이 아닌 soft limit이며, 알림 평가는 약 24시간마다 이뤄집니다. 실시간 과금 차단 장치로 생각해서는 안 됩니다.

기존 A1 사용자가 지금 피해야 할 행동

문서가 불일치한다는 이유만으로 운영 중인 서버를 바로 변경하면 장애나 데이터 손실 위험이 더 커질 수 있습니다.

인스턴스를 무작정 종료하지 않기

OCI에서 Terminate는 단순한 전원 끄기가 아니라 인스턴스를 영구 삭제하는 작업입니다. Oracle 종료 문서에 따르면 부트 볼륨은 기본적으로 보존되지만, 종료 과정에서 함께 영구 삭제하도록 선택할 수도 있습니다. 중요한 데이터와 설정을 먼저 백업해야 합니다.

중지와 OS 종료를 같은 것으로 생각하지 않기

서버 안에서 운영체제 명령으로 종료하는 것과 OCI 콘솔에서 인스턴스를 Stop하는 것은 과금 처리상 같지 않습니다. Oracle의 중지 인스턴스 과금 문서는 OS에서만 종료하면 인스턴스 과금이 멈추지 않는다고 안내합니다. 반면 Standard shape는 콘솔이나 API에서 중지하면 컴퓨트 과금이 일시 중지되지만 서비스 한도에는 계속 포함됩니다.

확인 없이 4 OCPU·24GB를 2 OCPU·12GB로 축소하지 않기

VM.Standard.A1.Flex는 사양을 조정할 수 있지만, 웹 서버·DB·Docker 컨테이너를 함께 돌리는 환경에서 메모리를 절반으로 줄이면 OOM이나 서비스 중단이 발생할 수 있습니다. 변경 전에는 다음 순서가 안전합니다.

부트 볼륨과 애플리케이션 데이터를 백업합니다.
현재 CPU·메모리 사용량을 확인합니다.
OCI 콘솔의 한도를 확인하고, 유료·평가판 계정은 Cost Analysis도 확인합니다.
유료·평가판 계정은 Oracle Support에 문의하고, Always Free 계정은 공식 커뮤니티와 콘솔 경고·이메일을 확인합니다.
축소가 필요하다는 답변을 받은 뒤 유지보수 시간을 잡고 변경합니다.

그래서 A1 무료 한도는 축소된 걸까?

현재 가장 정확한 표현은 “모든 계정의 한도가 축소됐다”가 아니라 계정 유형과 공식 페이지에 따라 A1 무료 제공량 안내가 다르다는 것입니다.

Always Free 전용 페이지는 2 OCPU·12GB를 명시하고, 가격표는 paid tenancy에 그 두 배의 월 시간 무료량을 안내합니다. Arm 문서의 대상 표현은 더 넓어 보이므로, 제목이나 숫자만 보고 자신의 계정에 그대로 적용하면 안 됩니다. 특히 새 A1 인스턴스를 만들거나 춘천 리전을 홈 리전으로 사용하는 사람은 콘솔 상태를 더 주의해서 확인해야 합니다.

따라서 당장은 다음 원칙이 현실적입니다.

Always Free 계정의 신규 구성은 2 OCPU·12GB 문서를 기준으로 보수적으로 계산합니다.
paid tenancy는 가격표의 3,000 OCPU-시간·18,000 GB-시간 안내와 실제 비용을 함께 확인합니다.
기존 4 OCPU·24GB 운영자는 백업을 준비하되, 확인 없이 서버를 중지·삭제·축소하지 않습니다. 단, 무료 체험 종료 전 한도 초과 계정은 축소 또는 유료 업그레이드가 필요할 수 있습니다.
무료 체험 종료를 앞뒀다면 Always Free 허용량 초과 여부와 30일 삭제 경고를 우선 확인합니다.
Oracle 문서가 정리되거나 공식 공지가 나오면 그때 운영 구성을 다시 판단합니다.

자주 묻는 질문

오라클 클라우드 A1 무료 한도가 4 OCPU·24GB에서 2 OCPU·12GB로 줄어든 것이 확정됐나요?

모든 계정에서 줄었다고 말하기 어렵습니다. Always Free 문서는 2 OCPU·12GB를 안내하지만, OCI 가격표는 각 paid tenancy에 4 OCPU·24GB로 환산되는 월 시간 무료량을 안내합니다. Arm-Based Compute 문서도 3,000·18,000을 안내해 계정 유형과 페이지 목적을 함께 봐야 합니다.

지금 4 OCPU·24GB를 사용하면 바로 과금되나요?

공식 문서의 숫자만으로 바로 과금된다고 단정할 수 없습니다. 유료·평가판 계정은 OCI Cost Analysis와 실제 청구 내역을 확인해야 하며, 비용 정보는 최대 48시간 늦게 반영될 수 있습니다. Always Free 계정은 청구·사용량 화면이 제공되지 않을 수 있으므로 콘솔 한도·경고·이메일도 확인해야 합니다.

무료 체험이 끝나면 기존 A1 인스턴스는 어떻게 되나요?

Oracle FAQ는 체험 종료 시 A1 사용량이 Always Free 허용량을 넘으면 모든 A1 인스턴스가 비활성화되고, 업그레이드하지 않으면 30일 뒤 삭제될 수 있다고 안내합니다. 체험 종료 전 백업과 총 OCPU·메모리 확인이 필요합니다. 이 규칙을 장기 기존 계정에 대한 소급 정책으로 확대 해석해서는 안 됩니다.

기존 A1 인스턴스를 2 OCPU·12GB로 바로 줄이는 것이 안전한가요?

권장하지 않습니다. 운영 중인 서비스의 메모리 사용량과 백업 상태를 먼저 확인해야 합니다. 특히 Docker, 데이터베이스, 프록시를 한 서버에서 실행한다면 갑작스러운 축소로 서비스가 중단될 수 있습니다.

춘천 리전에서는 A1 인스턴스를 더 이상 만들 수 없나요?

Always Free 문서는 여러 가용성 도메인이 있는 리전의 A1 생성 규칙에서 South Korea North(Chuncheon)를 예외로 표시합니다. 다만 이 한 문구만으로 모든 계정에서 신규 생성이 완전히 차단됐거나 기존 인스턴스가 회수된다고 확대 해석할 수는 없습니다. 자신의 홈 리전 콘솔에서 생성 가능 여부와 한도를 확인해야 합니다.

서비스 한도가 4 OCPU 이상이면 그만큼 무료인가요?

반드시 그렇지는 않습니다. 서비스 한도는 자원을 만들 수 있는 최대 범위이고, 무료 제공량은 과금되지 않는 범위입니다. Pay As You Go 계정에서는 무료 범위를 넘어서는 자원도 생성할 수 있으므로 한도 화면과 Cost Analysis를 함께 봐야 합니다.

1,500 OCPU-시간은 어떻게 2 OCPU 한 달 사용량이 되나요?

31일은 744시간입니다. 2 OCPU를 744시간 실행하면 1,488 OCPU-시간이므로 1,500시간 안에 들어갑니다. 메모리도 12GB × 744시간 = 8,928 GB-시간으로 9,000 GB-시간 이내입니다.

참고한 Oracle 공식 문서

이 글은 Oracle 공식 문서를 바탕으로 수치를 비교한 개인 기술 기록입니다. Oracle과 제휴하거나 후원받지 않았으며, 요금·정책은 변경될 수 있습니다.

Ghost·Mailgun 보안 점검 실전편: 서버 명령어와 대시보드

Mailgun 잠재적 침해 경고 후 Ghost EAUTH 535 점검과 복구

Ghost 관리자 로그인이 안 될 때: EAUTH·ESOCKET Gmail SMTP 해결