Oracle Cloud A1 Flex 4 cpu / 24GB mem 성공기

오라클 클라우드에는 평생 무료로 쓸 수 있는 VM이 있다고 해서 Free Tier로 VM.Standard.E2.1.Micro 인스턴스를 하나 만들었다.
스펙은 AMD 1 OCPU / 1GB RAM.
생각보다 잘 돌아가서 열심히 쓰고 있었는데, 어느 날 커뮤니티에서 이런 이야기를 봤다.

ARM 인스턴스는 4 OCPU / 24GB RAM까지 무료로 쓸 수 있다.

사람들이 다들 그걸 쓰고 있다고 자랑하고 있었다.
“아니, 그런 게 있으면 나도 안 할 수 없지?”

그래서 기존에 쓰던 E2 인스턴스는 그대로 두고, A1 Flex 인스턴스를 새로 하나 만들어서 운영해보기로 했다.

그런데 막상 만들려고 보니 목표였던 4/24 스펙은 바로 잡히지 않았다.
OCI에서 흔히 보는 Out of capacity가 떴다.
말 그대로 그 시점에는 원하는 자원을 바로 할당받기 어렵다는 뜻이었다.

내가 사용 중인 춘천 리전에는 자리가 없다는 말이기도 했다.

그래서 이 이야기는 처음부터 “원하는 스펙을 한 번에 만들고 세팅 끝!” 같은 찬란한 이야기는 아니다.
이 이야기는 어떻게 원하는 스펙까지 결국 올렸는가에 대한 이야기다.

---

 

0. A1 Flex를 새로 만들기로 함

다른 블로그 글, Reddit, ChatGPT, Gemini 등 여러 채널을 돌아다니며 A1 Flex 인스턴스를 만드는 방법을 다시 찾아봤다.
방법 자체는 예전에 E2 인스턴스를 만들었던 것과 크게 다르지 않았다.
문제는 4 OCPU / 24GB RAM 스펙이 죽어도 생성되지 않는다는 점이었다.
오라클 데이터센터에 물리적인 가용량이 없어서 그렇고, 결국 될 때까지 시도해야 한다는 이야기가 많았다.
또 Pay-As-You-Go 계정으로 업그레이드하면 바로 만들 수 있다는 이야기도 있어서 계정도 업그레이드했다.

이때 오라클 결제 오류 때문에 마음고생한 이야기는 아직 진행 중이다. ㅠㅠ

문제는 여기서부터였다.
계정을 업그레이드했는데도 여전히 4/24 스펙은 가용량 부족으로 생성되지 않았다.
OCI 콘솔에서는 Out of capacity 메시지가 떴다.
실제로는 이것보다 훨씬 긴 메시지였지만, 요지는 간단했다.

지금 이 리전/가용성 도메인에는 해당 자원이 부족하다.

계정도 업그레이드했고, 결제 문제로 마음고생까지 했는데, 정작 원하는 스펙을 못 올리는 상황.
이쯤 되니 이상하게 승부욕이 생겼다.

그럼 전략을 바꿔야 했다.
군자의 도리는 그런 것이다.

처음부터 무리해서 4/24를 만들려고 하지 않고, 일단 생성 가능한 최소 수준으로 먼저 띄우는 방향으로 가기로 했다.

---

 

1. A1 Flex를 최소 스펙으로 먼저 만들었다

일단 A1 Flex를 최소 스펙으로 따로 만들었다.
1 OCPU / 6GB RAM
최소 스펙이라 그런지 이건 바로 만들어졌다. (운이 좋았던걸수도 있고)
그리고 확보된 인스턴스를 단계적으로 업그레이드하는 전략을 세웠다.
다행히 OCI는 인스턴스의 CPU와 메모리를 나중에 조정할 수 있는 기능을 제공한다.

---

2. 2/12, 3/18, 4/24로 단계적으로 올리기로 했다

그다음부터는 단계적으로 스펙을 올리기로 했다.
한 번에 4/24로 훅 올리는 게 아니라,
2/12 → 3/18 → 4/24
이렇게 나눠서 올리는 방식이다.

이렇게 한 이유는 단순했다.
VM.Standard.A1.Flex는 고정된 서버 상품을 하나 통째로 받는 구조가 아니라, 오라클의 ARM 호스트 풀에서 필요한 만큼 자원을 할당받는 구조라고 봤기 때문이다.

즉, 4 OCPU / 24GB RAM이 한 번에 비는 경우는 드물 수 있다.
하지만 이미 1/6 인스턴스를 만들어둔 상태에서 한 단계씩 올리면, 매번 추가로 필요한 자원은 1 OCPU / 6GB RAM뿐이다.
한 번에 큰 자리를 기다리는 것보다, 작은 빈자리를 여러 번 잡는 쪽이 가능성이 더 높을 거라고 생각했다.
그래서 일단 인스턴스를 만든 뒤, 인스턴스 편집 화면에서 2/12로 변경하고 저장을 눌렀다.

---

3. 웹 콘솔에서 CLI 자동화로 전환

처음에는 웹 콘솔에서 직접 시도했는데.대여섯 번쯤 누르니 이런 생각이 들었다.

이걸 언제까지 누르고 있어야 하지?

10번이 넘어가자 괜히 시작했다는 생각도 들었다.
분명 이걸 자동화하는 방법이 있을 것 같았다.
실제로 성공한 사람들의 이야기를 보면, 설정 스택을 저장해두고 Terraform을 이용해서 몇 분마다 4/24 생성 명령을 반복했다고 했다.
그때 본 것이 oci cli였다.
이걸 이용하면 Python이나 다른 스크립트로 자동화할 수 있겠다는 생각이 들었다.

Terraform은 잘 모르니까.
그래서 이번에는 OpenAI Codex와 연결된 내 에이전트에게 이 작업을 자동화하고, 로그까지 남기는 스크립트를 만들어달라고 했다.
시행착오는 있었지만, 최종적으로 정착한 조건은 다음과 같았다.

    재시도 주기: 3분
    성공 시 다음 단계 시도 간격: 30초
    텔레그램 보고: 08시 ~ 23시까지 매시 정각에 실행 상황 브리핑

중간 로그를 보면 재시도 흔적이 꽤 많이 남아 있다.
특히 2/12로 올라갈 때 정말 많이 시도했는데, 로그가 제대로 남아 있지 않은 게 조금 아쉽다.

 

4. 로그로 보면 시도는 꽤 많이 했다

이 과정에서 남은 로그를 정리해보면, 변경 시도만 해도 꽤 여러 번 반복됐다.

2/12로 올라갈 때 로그 정리가 잘 안 되어 있어서 정확히 보이지는 않지만, 체감상 거의 400번 넘게 시도했던 것 같다.

---

5. 결국 총 800번 정도의 시도 끝에 4 OCPU / 24GB에 안착

최종적으로는 4 OCPU / 24GB RAM까지 올리는 데 성공했다.
처음 1/6으로 시작했을 때는 금방 되겠지 싶었다.
하지만 2/12로 올라갈 때는 “이거 아닌가?” 싶을 정도로 오래 걸렸다.
그런데 3/18까지 올라간 뒤에는 생각보다 금방 4/24까지 올라갔다.
그 순간은 꽤 짜릿했다.

---

6. 정리

정리하면, 이번 작업은 OCI A1 Flex에서 원하는 스펙이 바로 잡히지 않을 때 사용한 단계적 확장기였다.
처음부터 4 OCPU / 24GB RAM을 만들려고 하면 Out of capacity에 막혔다.

그래서 먼저 가능한 최소 스펙인 1 OCPU / 6GB RAM으로 인스턴스를 만들고, 이후에 2/12 → 3/18 → 4/24 순서로 조금씩 키웠다.
한 번에 큰 자원을 기다리는 대신, 작은 단위의 빈자리를 여러 번 잡는 방식이었다.
결과적으로 약 800번 정도의 시도 끝에 원하는 스펙까지 도달했다.

OCI A1 Flex는 무료 스펙이 매력적이지만, 리전 상황에 따라 가용량 문제가 꽤 심하다.
그래도 바로 포기하지 않고, 가능한 스펙부터 확보한 뒤 단계적으로 올리는 방식은 충분히 시도해볼 만한 전략이었다.