최대 768GiB 메모리 확장: 오로라 서버리스 384 ACU 증설이 AI 에이전트 인프라 계산기를 바꾸는 이유

512GiB 한계 넘은 클라우드 데이터베이스: 에이전트 AI 폭증을 겨냥한 AWS의 승부수

인공지능 모델이 스스로 웹을 검색하고, 코드를 짜고, 복잡한 비즈니스 워크플로우를 처리하는 ‘에이전트 AI’ 환경이 산업 전반으로 번지고 있다. 하지만 이 에이전트들을 뒷받침하는 클라우드 인프라 운영팀은 심각한 고민을 안고 있었다. 바로 ‘극단적으로 불규칙한 데이터베이스 부하’ 때문이다. 에이전트 수십 개가 동시에 수만 건의 벡터 검색과 트랜잭션을 몰아칠 때는 엄청난 컴퓨팅 파워와 메모리가 필요하지만, 작업이 끝나면 데이터베이스는 거짓말처럼 조용해진다.

과거에는 이런 폭발적인 순간 부하를 버티기 위해 값비싼 고사양 고정형 인스턴스를 24시간 내내 켜두어야 했다. 새벽 시간이나 유휴 시간에 서버가 놀고 있어도 매달 수천 달러의 청구서가 고스란히 날아왔다.

AWS가 아마존 오로라 서버리스(Amazon Aurora Serverless) 포스트그레SQL 호환 에디션의 최대 데이터베이스 용량을 기존 256 ACU(Aurora Capacity Unit)에서 384 ACU로 50% 전격 상향 조정했다. 1 ACU는 약 2기가바이트(GiB)의 메모리와 이에 상응하는 CPU 및 네트워크 대역폭을 제공한다. 즉, 단일 서버리스 데이터베이스 클러스터가 이제 필요에 따라 최대 768GiB의 메모리까지 자동으로 팽창했다가, 사용이 끝나면 ‘0 ACU(Scale down to zero)‘로 내려가 비용 지출을 완전히 멈출 수 있게 되었다.

이번 확장은 지원 엔진 버전인 포스트그레SQL(PostgreSQL) 18.4, 17.10, 16.14, 15.18, 14.23을 탑재하고 플랫폼 버전 4(Platform Version 4)에서 구동되는 클러스터에 즉시 적용된다. 이미 해당 플랫폼을 사용 중인 환경이라면 무중단으로 상한 설정값만 올려 바로 사용할 수 있다.

384 ACU의 실제 경제성: 고정 인스턴스 대비 실제 청구 비용 비교

서버리스 인프라는 ‘사용한 만큼만 낸다’는 강력한 장점이 있지만, 단위 시간당 단가는 고정 인스턴스보다 비싸다. 384 ACU까지 확장된 오로라 서버리스를 도입할 때 실무진이 가장 먼저 두드려봐야 할 것은 “과연 우리 서비스 부하 패턴에서 서버리스가 진짜 돈을 아껴주는가?”이다.

미국 동부(버지니아 북부) 리전 기준 1 ACU당 시간당 요금은 통상 약 0.12달러 수준이다. 384 ACU를 최대치로 가동하면 시간당 약 46.08달러가 발생한다. 반면 이와 유사한 사양의 고정형 프로비저닝 인스턴스인 db.r6g.16xlarge(64 vCPU, 512GiB 메모리)나 db.r6g.24xlarge(96 vCPU, 768GiB 메모리)는 시간당 약 10–15달러 선에서 상시 운영된다.

실무 시뮬레이션 결과에 따르면, 하루 중 대규모 연산이 집중되는 시간이 하루 8–10시간(가동률 약 35–42%) 이하라면 오로라 서버리스 384 ACU가 고정 인스턴스를 상시 켜두는 것보다 총비용을 확실히 낮춘다. 반대로 하루 12시간 이상 부하가 계속 유지되는 상시 서비스라면 고정 인스턴스에 예약(RI)이나 세이빙스 플랜을 거는 편이 훨씬 유리하다.

데이터베이스 운영팀과 비즈니스에 미치는 3대 직접적 파급력

1. 운영 비용(OPEX): 고정비의 변동비 전환과 유휴 누수 차단

많은 엔터프라이즈 기업의 데이터베이스 청구서에는 ‘혹시 모를 순간 부하’를 위해 예비로 켜둔 잉여 용량 비용이 최소 30–50% 이상 섞여 있다. 오로라 서버리스 384 ACU는 피크 타임 천장을 768GiB까지 대폭 높임으로써 엔지니어가 평소에 인스턴스를 크게 잡아둘 이유를 없앴다. 특히 배치성 머신러닝 임베딩 생성이나 월말 결산처럼 특정 주기에만 거대한 메모리가 필요한 작업에서 고정비를 순수 변동비로 완전히 전환할 수 있다.

2. 서비스 지연 및 확장 한계(Lead Time): 인스턴스 교체 다운타임의 종말

전통적인 클라우드 관계형 데이터베이스에서 인스턴스 크기를 두 배로 키우려면 읽기 전용 복제본을 만들고 장애 조치(Failover)를 유도하거나, 몇 분간의 연결 끊김 현상을 감수해야 했다. 오로라 서버리스 플랫폼 버전 4는 사용자의 연결을 끊지 않고 메모리와 CPU를 물 흐르듯 실시간으로 붙였다 뗀다. 512GiB를 넘어 768GiB까지 무중단 확장이 보장되므로, 급격한 트래픽 유입 시 서비스 점검 화면을 띄워야 했던 긴급 장애 상황이 획기적으로 줄어든다.

3. 공급 안정성: 복잡한 분할(샤딩) 설계 도입 시점 연기

데이터베이스가 버틸 수 있는 단일 머신의 한계를 넘어서면 개발팀은 데이터를 여러 서버로 쪼개는 ‘샤딩(Sharding)‘이나 복잡한 파티셔닝 설계를 시작해야 한다. 이는 애플리케이션 코드를 뒤흔들고 수개월의 개발 인력을 소모시킨다. 단일 엔드포인트에서 768GiB 메모리를 다룰 수 있게 되면서, 개발팀은 복잡한 아키텍처 개편 없이도 서비스 확장 시간을 1–2년 이상 추가로 벌 수 있게 되었다.

급변하는 AI 인프라 환경: 서버리스 DB와 모니터링 조합의 완충 효과

데이터베이스가 스스로 크기를 조절할 때 가장 큰 공포는 ‘월말 청구서의 예측 불가능성’이다. 의도치 않은 무한 루프 쿼리나 잘못 설계된 AI 에이전트의 반복 프롬프트가 실행되면, 데이터베이스는 최대치인 384 ACU까지 치솟은 채 내려오지 않아 하루 만에 수천 달러의 비용을 태워버릴 수 있다.

선도적인 테크 기업들은 이러한 충격을 흡수하기 위해 Datadog 같은 인프라 통합 모니터링 도구를 결합하여 실시간 방어 체계를 구축한다. ACU 사용량이 200 단위를 넘어서 30분 이상 유지될 경우 온콜 엔지니어에게 알림을 쏘거나, AWS 람다(Lambda)를 트리거하여 문제가 된 비정상 세션을 강제 종료하는 안전장치를 두는 식이다.

또한, 벡터 검색이나 임베딩 캐싱처럼 메모리를 극도로 소모하는 가벼운 읽기 작업은 오픈소스 분산 환경이나 전문 벡터 스토리지로 분리하고, 최종 트랜잭션과 메타데이터 검증만 오로라 서버리스 384 ACU에 맡기는 하이브리드 토폴로지가 표준으로 자리 잡고 있다.

인프라 의사결정: 지금 즉시 384 ACU로 올려야 할 환경 vs 보류해야 할 환경

이번 업데이트는 모든 조직에 무조건적인 축복은 아니다. 애플리케이션의 트래픽 패턴과 현재 아키텍처 상태에 따라 얻는 이점과 떠안아야 할 리스크가 명확히 갈린다.

지금 즉시 도입해야 할 기업 (Fit 조건 3가지)

• AI 에이전트 및 대규모 비정기 배치 워크로드를 운영하는 기업: 데이터 수집과 가공이 하루 중 특정 시간대에 몰아치며, 새벽이나 비업무 시간에는 트래픽이 거의 0에 수렴하는 비즈니스.
• 예측 불가능한 마케팅 이벤트나 바이럴 트래픽이 잦은 서비스: 순간적으로 500GiB 이상의 메모리를 점유하는 트랜잭션 폭증이 일어나지만 인스턴스 크기 변경을 위한 다운타임을 절대 낼 수 없는 이커머스.
• 이미 오로라 포스트그레SQL 플랫폼 버전 4를 사용 중인 조직: 별도의 유지보수 다운타임 없이 콘솔에서 최대 ACU 설정값만 384로 바꾸면 즉시 안전 마진을 확보할 수 있는 환경.

도입을 보류하고 지켜봐야 할 기업 (Non-Fit 리스크 3가지)

• 주 7일 24시간 트래픽이 균일하게 높은 글로벌 상용 서비스: 데이터베이스 사용률이 항상 70% 이상을 맴도는 경우, 오로라 서버리스의 단위 시간당 프리미엄 요금이 누적되어 고정 인스턴스 대비 청구액이 2–3배 폭증할 수 있다.
• 구형 플랫폼 버전(Platform Version 1–3)에 머물러 있는 레거시 DB: 플랫폼 버전 4로 이전하기 위해 별도의 엔진 업그레이드와 재부팅 유지보수 시간을 잡아야 하므로, 충분한 사전 스테이징 테스트 없이 설정을 건드려서는 안 된다.
• 내부 개발팀에 인프라 비용 상한선 감시 체계가 없는 조직: 384 ACU는 강력하지만 그만큼 통제되지 않은 쿼리가 돌았을 때 예산을 빠르게 갉아먹는다. 실시간 알림과 쿼리 타임아웃 규칙이 정비되지 않았다면 기존 상한선을 유지하는 것이 안전하다.