로그 보관비 잡는 AWS의 승부수: 오픈서치 서버리스 시계열 컬렉션과 100TB 웜 스토리지의 실익
서버 관리 없는 오픈서치 서버리스에 웜 스토리지 티어가 들어섰습니다. 컬렉션당 100TB 용량과 자동 계층화로 인프라 관측 비용을 얼마나 줄일 수 있는지 분석합니다.
발행일: 2026.10.29
공식 사이트 확인컬렉션당 고속 분석 지원
보관 일수 기준 자동 전환
별도 서드파티 도구 불필요
서버 관리 없는 로그 분석판의 지각변동: 핫-웜 분리 보관이 던진 승부수
기업이 서버를 운영하면서 남기는 로그와 성능 기록(메트릭)은 매일 엄청난 속도로 쌓인다. 문제는 이 데이터의 성격이다. 방금 발생한 오류 로그나 지난 한 시간 동안의 결제 시스템 트레이스는 1초라도 빨리 찾아내야 하지만, 두 달 전이나 반년 전의 접속 기록은 법적 증적용이나 분기별 통계 확인을 위해 남겨둘 뿐 매일 열어볼 필요가 없다.
지금까지 아마존웹서비스(AWS)의 검색·로그 엔진인 오픈서치 서버리스(Amazon OpenSearch Serverless)를 쓰던 엔지니어링 팀은 난감한 선택을 강요받았다. 서버 대수를 직접 계산하고 설정(프로비저닝)하지 않아도 트래픽에 맞춰 자동으로 크기가 조절되는 점은 편리했지만, 오래된 로그도 방금 들어온 최신 로그와 똑같이 비싼 고속 메모리·SSD 급인 핫(Hot) 스토리지 요금을 내며 보관해야 했기 때문이다. 로그 보관 기간을 90일 이상으로 늘리면 인프라 비용 청구서가 눈덩이처럼 불어나 결국 데이터를 강제로 삭제하거나, 서버 관리가 번거로운 프로비저닝 클러스터로 되돌아가는 일이 벌어졌다.
이번에 공개된 차세대 오픈서치 서버리스의 시계열 컬렉션(Time Series Collections)은 바로 이 묵은 비용 문제를 정면으로 겨냥했다. 하나의 컬렉션 안에서 자주 조회하는 최신 데이터는 핫 스토리지에 두고, 시간이 지난 데이터는 저렴한 웜(Warm) 스토리지로 자동으로 넘기는 2단계 계층화 구조를 서버리스 환경에 처음으로 적용했다. 수집 트래픽이 평소의 몇 배로 튀어 올라도 클러스터가 뻗지 않고 자동으로 이를 흡수하며, 컬렉션 하나당 최대 100TB에 달하는 대용량 핫 스토리지를 지원한다.
수집부터 장기 보관까지 단일 컬렉션 자동 처리
서버리스 수집 엔진이 트래픽 급증을 버퍼 없이 자동 흡수
최신 로그·메트릭을 실시간 검색하고 이상 징후 즉시 감지
설정한 보관 일수가 지나면 저비용 저장소로 자동 이전
데이터 위치 이동과 무관하게 단일 엔드포인트에서 검색
실제 숫자로 검증한 팩트: 전통적 클러스터 vs 차세대 서버리스 시계열 스펙
이번 업데이트의 실무적 핵심은 ‘운영 인력 투입 제로’와 ‘장기 보관 단가 인하’를 동시에 잡았다는 점이다. 기존에는 웜 스토리지를 쓰려면 EC2 인스턴스를 직접 고르고 샤드(Shard) 분할과 인덱스 수명 주기(ISM) 정책을 일일이 손으로 튜닝해야 했다. 반면 새로운 시계열 컬렉션은 보관 기간 조건만 지정하면 백그라운드에서 스토리지가 전환된다.
아래 표는 데이터 파이프라인 실무에서 가장 흔히 비교되는 3가지 운영 방식의 핵심 규격과 처리 한계를 정리한 내용이다.
| 평가 기준 | 자체 구축형 오픈서치 (EC2) | 기존 오픈서치 서버리스 | 차세대 서버리스 시계열 컬렉션 |
|---|---|---|---|
| 인프라 관리 부담 | 인스턴스 용량 산정, 패치 직접 수행 | 서버 관리 불필요, 자동 크기 조절 | 서버 관리 불필요, 완전 자동화 |
| 저장소 계층화 | 울트라웜(UltraWarm), 콜드 수동 구성 | 핫 단일 티어 (고비용 유지) | 핫 + 저비용 웜 자동 계층화 |
| 컬렉션당 핫 용량 | 디스크 볼륨 크기에 종속 | OCU(용량 단위) 소비량 기반 | 최대 100 TB 지원 |
| 수집 스파이크 대응 | 사전 증설 없으면 데이터 유실 위험 | 자동 OCU 확장 (지연 일부 발생) | 인제스트 스파이크 자동 흡수 |
| 분석 부가 기능 | 플러그인 별도 설치 및 관리 | 기본 검색 및 대시보드 위주 | 알림 및 이상 감지 기본 내장 |
| 적합한 데이터 성격 | 복합 전문 검색, 이커머스 상품 카탈로그 | 균등한 트래픽의 앱 검색 | 로그, 분산 트레이스, IoT 센서 메트릭 |
실무 관점에서 특히 주목할 부분은 단일 컬렉션이 소화하는 핫 스토리지 상한선인 100TB다. 하루에 1TB씩 로그가 쏟아지는 중견 플랫폼 기업이라도 100일 치의 원천 데이터를 고속 검색 영역에 담아둘 수 있다는 뜻이다. 여기에 웜 스토리지로의 전환 기준일을 14일이나 30일로 짧게 잡는다면, 핫 영역에는 최근 2주 치 데이터만 머물게 하고 나머지 수개월 치 기록은 저렴한 웜 영역으로 빼돌려 고정 지출을 가파르게 깎아낼 수 있다.
월간 30TB 로그 발생 인프라 기준 실무 시뮬레이션
엔지니어링 현장과 운영 예산에 미치는 3대 파급력
새로운 시계열 컬렉션은 클라우드 인프라를 운영하는 데브옵스(DevOps) 및 SRE(Site Reliability Engineering) 팀의 일하는 방식을 크게 바꾼다.
1. 운영 비용(OPEX): 로그 보관 정책의 손익분기점 재설정
지금까지 많은 개발팀이 비용 때문에 로그 보관 기간을 7일이나 14일로 억지로 줄였다. 보안 감사나 규제 준수를 위해 1년 치 로그를 의무 보관해야 할 때는 S3로 로그를 내보낸(Export) 뒤, 필요할 때마다 아테나(Athena)로 느리게 쿼리하거나 오픈서치에 임시 클러스터를 띄워 다시 밀어 넣는 비효율을 감수했다.
새로운 웜 스토리지 티어가 들어서면서 이러한 수작업 파이프라인이 사라진다. 같은 컬렉션 안에서 클릭 몇 번으로 전환 시점만 정해주면 데이터가 저렴한 저장소로 옮겨가면서도 오픈서치 대시보드에서 끊김 없이 검색된다. 데이터 보관 주기를 90일 이상으로 잡아야 하는 금융, 헬스케어, 결제 시스템 기업의 인프라 유지 비용이 즉각 낮아지는 계기가 된다.
2. 처리 시간과 운영 공수(Lead Time): 샤드 튜닝과 용량 산정의 종말
전통적인 엘라스틱서치나 오픈서치 클러스터를 운영할 때 엔지니어를 가장 괴롭히는 일은 샤드(Shard) 크기 관리였다. 시계열 데이터는 날마다 용량이 달라지기 때문에 인덱스가 너무 커지면 검색이 느려지고, 너무 잘게 쪼개면 마스터 노드의 메모리가 고갈된다. 블랙프라이데이나 대규모 이벤트로 로그가 갑자기 평소의 5배 이상 쏟아지면 클러스터가 멈추지 않도록 미리 서버 노드를 추가해야 했다.
차세대 시계열 컬렉션은 수집 급증(Spike)을 자체 버퍼로 흡수해 유실 없이 저장한다. 엔지니어가 야간 장애 알림을 받고 깨어나 클러스터 인스턴스를 늘리는 대신, 인프라가 알아서 부하를 견뎌낸다. 용량 예측과 샤드 리밸런싱에 쓰던 고급 엔지니어링 리소스를 본연의 제품 개발로 돌릴 수 있다.
3. 공급 안정성과 관측성: 서드파티 모니터링 도구 종속성 탈피
로그를 오픈서치에 모으더라도, 시스템 장애 징후를 감지하고 슬랙(Slack)이나 이메일로 경보를 쏘려면 별도의 경보 시스템을 붙이거나 Datadog 같은 유료 SaaS 모니터링 도구를 연동해야 했다. 호스트 대수가 늘어날수록 서드파티 관측 도구의 라이선스 비용은 기하급수적으로 커진다.
이번 업데이트로 시계열 컬렉션 내부에 이상 감지(Anomaly Detection)와 알림(Alerting) 기능이 기본 탑재되었다. 머신러닝 모델이 로그와 메트릭의 일반적인 발생 패턴을 학습한 뒤, 평소와 다른 에러 급증이나 트래픽 급락을 알아서 찾아내 담당자에게 알린다. 별도의 외부 분석 도구를 사서 붙이지 않아도 기본적인 보안 관제와 인프라 헬스체크 체계를 완성할 수 있다.
레거시 아키텍처를 대체하는 완충벽: SaaS 관측 플랫폼과의 실무 비교
로그 및 인프라 관측 시장은 크게 세 갈래로 나뉜다. 첫째는 모든 인프라를 직접 구성하는 자체 관리형 오픈서치, 둘째는 간편하지만 볼륨이 커질수록 청구서가 천문학적으로 치솟는 글로벌 상용 모니터링 SaaS, 셋째가 이번에 진화한 AWS 네이티브 서버리스 환경이다.
월간 로그 수집량 50TB 이상 대규모 시스템 기준 대조
- • 데이터 수집량과 호스트 수에 비례해 라이선스 급증
- • UI와 에이전트 설치가 매우 간편함
- • 30일 이상 장기 로그 보관 시 추가 과금 부담 큼
- • 사용한 스토리지 및 OCU 연산량에만 정밀 과금
- • 웜 스토리지 연동으로 수개월 치 데이터 저비용 유지
- • AWS 내부 인프라 및 VPC와의 완벽한 보안 연동
데이터 유출 위험에 민감한 금융권이나 공공 프로젝트에서는 데이터가 서드파티 SaaS 클라우드로 넘어가는 것 자체가 규제 위반이 되는 경우가 많다. 오픈서치 서버리스는 모든 데이터가 고객 소유의 AWS 계정과 VPC 경계 안에서 암호화되어 머물기 때문에 규제 검토 통과가 훨씬 수월하다.
이미 플루언트비트(Fluent Bit)나 오픈실시간 수집 데이터(OpenTelemetry) 같은 오픈소스 표준 수집 파이프라인을 갖춘 조직이라면, 전송 목적지(Sink) 엔드포인트만 시계열 컬렉션으로 변경하면 기존 시스템 구조를 흔들지 않고도 계층화 저장소를 즉시 적용할 수 있다.
우리 팀에 맞는 최적의 선택: 도입 적합 대상 vs 보류 대상 판정
새로운 시계열 컬렉션이 강력한 장점을 지녔지만, 모든 워크로드에 만능 열쇠가 되는 것은 아니다. 팀의 데이터 처리 패턴과 현재 인프라 구조를 냉정하게 따져보고 도입 여부를 결정해야 한다.
지금 즉시 도입해야 할 기업
- 로그 보관 규정(컴플라이언스) 때문에 60일–1년 치 데이터를 버리지 못하는 팀: 웜 스토리지 계층화를 통해 쿼리 성능을 희생하지 않으면서도 스토리지 청구 금액을 절반 가까이 즉시 낮출 수 있다.
- 수집 트래픽의 고저 차가 극심한 이커머스 및 게임 서비스: 주말이나 특정 이벤트 시간대에 평소 대비 트래픽이 수배 이상 폭증하더라도, 사전 용량 증설 없이 수집 스파이크를 안전하게 받아낼 수 있다.
- 클러스터 노드 관리와 샤드 리밸런싱에 지친 소규모 엔지니어링 조직: 인프라 관리 전담 엔지니어가 부족한 상황에서 관측 파이프라인 운영 부담을 제로에 가깝게 만들 수 있다.
도입을 보류하고 지켜봐야 할 기업
- 초당 쿼리(QPS)가 극도로 높고 마이크로초 단위 응답이 필요한 핵심 상품 검색: 시계열 컬렉션은 로그, 메트릭, 트레이스 같은 시간에 따라 쌓이는 데이터(Append-only)에 맞춰 최적화되어 있다. 데이터 수정과 잦은 업데이트가 발생하는 카탈로그 검색에는 기존 검색 컬렉션(Search Collection)이나 프로비저닝 클러스터가 적합하다.
- 이미 고정 예약 인스턴스(RI)나 절감 플랜(Savings Plans)으로 EC2 클러스터를 한계까지 쥐어짜 쓰고 있는 팀: 트래픽이 24시간 내내 일정하고 이미 최적화된 대규모 전용 인스턴스를 유지 중이라면, 서버리스 종량제 단가가 오히려 고정 인프라 비용보다 높게 책정될 수 있다.
- AWS 외부 멀티 클라우드(GCP, 온프레미스) 환경에 인프라가 흩어져 있는 시스템: 로그 분석 엔진이 AWS 리전에 완전히 결속되므로, 외부 클라우드에서 데이터를 넘겨올 때 발생하는 아웃바운드 네트워크 전송료(Data Transfer Out)가 스토리지 절감액보다 커질 위험이 있다.