Cloudflare R2 저장 비용을 Object Lifecycle Rules로 관리하는 방법

Cloudflare R2에 이미지나 로그, 임시 산출물을 계속 쌓다 보면 저장 비용이 눈에 띄게 늘어납니다. Object Lifecycle Rules는 오래된 객체를 자동으로 정리하거나 더 저렴한 저장 등급으로 옮겨 이 비용을 관리하는 기능입니다. 다만 이 규칙은 되돌릴 수 없는 삭제를 자동으로 실행하는 기능이기도 해서, 어떤 객체에 적용할지를 잘못 정하면 보존해야 할 파일이 조용히 사라질 수 있습니다.

이 글은 Lifecycle 규칙의 종류와 동작 방식, Standard와 Infrequent Access 저장 등급의 실제 비용 차이를 정리합니다. 실제 버킷에 규칙을 적용하는 것은 이 글의 범위가 아니며, 확인된 동작과 가격만 다룹니다.

R2 저장 비용은 처음에는 작게 느껴지다가, 버킷에 쌓이는 객체 수와 보관 기간이 늘어날수록 서서히 커지는 성격을 가지고 있습니다. 한 번에 큰 금액이 청구돼 바로 눈에 띄는 것이 아니라, 매달 조금씩 늘어나는 저장 요금으로 나타나기 때문에 뒤늦게 발견하는 경우가 많습니다. Lifecycle 규칙은 이런 성격의 비용을 미리 관리하는 도구이지만, 동시에 사람이 직접 지켜보지 않아도 자동으로 객체를 지우는 기능이기도 해서, 설계를 잘못하면 비용 절감과 데이터 손실이 함께 일어날 수 있습니다. 그래서 이 기능은 “일단 걸어 두고 지켜본다”보다 “어떤 객체가 어떤 조건에서 사라지는지 미리 정확히 이해하고 건다”는 태도로 접근하는 것이 중요합니다.

순서

1. Lifecycle 규칙 세 종류를 구분합니다.
2. 규칙이 실제로 언제 적용되는지 확인합니다.
3. Standard와 Infrequent Access의 비용을 비교합니다.
4. 버킷의 용도별로 규칙 적용 범위를 나눕니다.
5. 실제로 규칙을 설계하기 전에 확인할 것들을 정리합니다.

Lifecycle 규칙 세 종류

R2의 Object Lifecycle Rules는 세 가지 동작으로 나뉩니다.

버킷을 만들면 멀티파트 업로드를 7일 뒤 자동으로 만료시키는 기본 규칙이 하나 들어가 있습니다. 완료되지 않은 업로드가 쌓여 공간을 차지하는 것을 막기 위한 기본값입니다.

규칙은 버킷 전체가 아니라 Prefix(접두사) 단위로 범위를 지정할 수 있습니다. 예를 들어 logs/나 useruploads/처럼 특정 경로로 시작하는 객체에만 규칙을 적용하는 식입니다. 이렇게 Prefix로 범위를 좁혀 두면, 같은 버킷 안에 보존해야 할 파일과 정리해도 되는 파일이 섞여 있어도 원하는 쪽에만 규칙을 걸 수 있습니다. 버킷 하나당 만들 수 있는 Lifecycle 규칙은 최대 1,000개입니다.

규칙이 실제로 언제 적용되는가

Lifecycle 규칙을 설정했다고 바로 그 순간 객체가 사라지거나 등급이 바뀌는 것은 아닙니다. 신규로 업로드되는 객체는 규칙에 따른 만료 시점이 즉시 정해지지만, 실제 삭제는 보통 그 시점으로부터 24시간 안에 일어납니다. 이미 있던 객체의 등급 전환도 비슷하게 보통 24시간 안에 적용되지만, 버킷 안에 객체가 많으면 더 걸릴 수 있습니다. “규칙을 걸었는데 왜 아직 안 지워졌지”라는 의문이 든다면, 설정 자체가 잘못된 것이 아니라 아직 반영 시간이 지나지 않았을 가능성부터 봐야 합니다.

같은 객체에 전환 규칙과 만료 규칙이 24시간 이내에 겹쳐 적용되면, 삭제가 등급 전환보다 우선합니다. 즉 “30일 뒤 Infrequent Access로 전환하고, 60일 뒤 삭제”처럼 두 시점이 충분히 떨어져 있다면 문제가 없지만, 두 규칙의 적용 시점이 하루 안으로 가깝게 설계되면 전환은 일어나지 않고 그대로 삭제됩니다. 서로 다른 시점에 적용되도록 설계한 두 규칙이 단지 같은 Prefix 아래 있다는 이유만으로 충돌하는 것은 아니며, 실제로 겹치는지는 두 규칙의 적용 시점이 24시간 이내로 가까운지로 판단해야 합니다. 이 우선순위를 모르고 설계하면 “등급만 바뀔 줄 알았는데 파일이 사라졌다”는 상황이 생길 수 있습니다.

Infrequent Access로의 전환 조건은 업로드 후 경과일 기준으로만 동작합니다. 최근에 다시 읽혔는지, 즉 “마지막 접근 시각”은 전환 여부에 영향을 주지 않습니다. 오래됐지만 자주 조회되는 파일도 경과일 조건만 맞으면 Infrequent Access로 전환되고, 그 뒤로는 읽을 때마다 검색 요금이 붙기 시작합니다.

Standard와 Infrequent Access 비용 비교

두 저장 등급의 공식 가격(2026-11-02 기준)은 다음과 같습니다.

표에서 가장 눈여겨봐야 할 두 가지는 검색 요금과 최소 보관 기간입니다. Infrequent Access는 저장 단가만 보면 Standard보다 싸지만, 파일을 읽을 때마다 GB당 $0.01가 추가로 붙습니다. 자주 읽히는 파일이라면 이 검색 요금이 저장 단가 차액보다 커져서 오히려 전체 비용이 늘어날 수 있습니다.

최소 보관 기간 30일도 중요합니다. Infrequent Access로 전환한 객체를 30일이 되기 전에 삭제하거나 다시 Standard로 옮겨도, 30일치 저장 요금은 그대로 청구됩니다. 수명이 짧은 임시 파일을 Infrequent Access로 전환하도록 설정하면, 어차피 곧 지울 파일에 30일치 요금을 낸 뒤 지우는 셈이 되어 비효율적입니다.

무료 사용량도 Standard에만 적용됩니다. Infrequent Access에는 저장이든 요청이든 무료 구간이 전혀 없습니다. 이 점까지 고려하면, Infrequent Access는 “자주 읽지 않고, 적어도 30일 이상은 보관할 파일”이라는 조건을 모두 만족할 때만 비용상 이득이 있는 저장 등급입니다.

Standard에서 Infrequent Access로 전환할 때마다 Class A 작업 1건이 과금된다는 점도 놓치기 쉽습니다. 전환 대상 객체 수가 많다면, 전환 자체의 작업 비용도 함께 계산에 넣어야 합니다.

버킷 용도별로 규칙 적용 범위 나누기

같은 버킷 안에서도 객체의 용도는 서로 다를 수 있습니다. 예를 들어 공개 서비스에 계속 노출되는 이미지나 문서는 보존 대상이고, 업로드 처리 중에만 잠깐 필요한 임시 파일이나 완료된 백업 작업 중 실패해서 남은 조각은 정리 대상입니다. 이 둘을 같은 기준으로 다루면 안 됩니다.

보존 대상 파일에는 애초에 Expiration 규칙을 걸지 않는 것이 원칙입니다. “나중에 지워도 되겠지”라는 판단으로 만료 규칙을 걸어 두면, 시간이 지나 그 판단을 내린 사람도 잊어버린 채 파일이 자동으로 사라질 수 있습니다. 반대로 실패한 작업의 조각처럼 명확히 임시적인 객체는 별도 Prefix로 분리해 두고, 그 Prefix에만 좁혀서 Expiration 규칙을 적용하는 것이 안전합니다.

이런 정리 작업을 Lifecycle 규칙이 아니라 애플리케이션 코드로 직접 구현하는 방법도 있습니다. 예를 들어 일정 시간이 지나도 완료 표시가 없는 폴더만 선별해서 지우는 식의 로직은, 단순히 “경과일”만으로는 표현할 수 없는 조건(완료 여부 등)을 판단해야 할 때 Lifecycle 규칙보다 유연합니다. 다만 이 경우 그 정리 코드 자체가 버킷 전체를 나열하고 지우는 권한을 가지므로, 코드의 삭제 조건이 잘못되면 Lifecycle 규칙보다 더 광범위한 실수를 낼 수 있다는 점도 함께 고려해야 합니다.

규칙을 설계하기 전에 확인할 것

실제로 Lifecycle 규칙을 적용하기 전에는 다음을 먼저 확인하는 것이 안전합니다.

1. 버킷 안의 객체를 용도별로 분류합니다. 어떤 Prefix가 보존 대상이고, 어떤 Prefix가 정리해도 되는 임시 파일인지 먼저 표로 정리합니다.
2. 각 객체의 실제 읽기 빈도를 파악합니다. Infrequent Access 전환을 고려한다면, 그 파일이 정말 자주 읽히지 않는지, 전환 후 30일 안에 다시 필요해질 가능성은 없는지 확인합니다.
3. 전환과 만료 규칙이 같은 객체에 24시간 이내로 겹쳐 적용되지 않는지 확인합니다. 겹치면 삭제가 우선하므로, 의도한 대로 등급만 바뀌는지 두 규칙의 적용 시점 차이를 다시 검토합니다.
4. 먼저 좁은 범위에서 읽기 전용으로 현재 설정을 확인합니다. 버킷 설정 화면에서 기존에 걸려 있는 규칙이 있는지부터 보고, 의도하지 않은 규칙이 이미 걸려 있지 않은지 점검합니다.
5. 실제로 규칙을 적용하기 전에 되돌릴 수 없는 범위를 명확히 합니다. Expiration 규칙으로 삭제된 객체는 복구할 수 없으므로, 정말 지워도 되는 범위인지 한 번 더 확인한 뒤에만 적용합니다.
6. 규칙을 적용한 뒤에도 주기적으로 다시 점검합니다. 처음에는 명확히 임시 파일이던 Prefix가 시간이 지나면서 다른 용도로도 쓰이게 될 수 있습니다. 애플리케이션 구조가 바뀌었는데 예전에 걸어 둔 Lifecycle 규칙을 그대로 두면, 처음 설계할 때는 없었던 보존 대상 파일이 같은 Prefix 아래 섞여 들어가 의도치 않게 삭제될 수 있습니다.

보존이 꼭 필요한 공개 자산을 관리하는 버킷이라면, 애초에 삭제 규칙 자체를 만들지 않고 Standard 등급만 쓰는 선택이 가장 단순하고 안전합니다. 저장 비용을 줄이는 것과 데이터를 안전하게 보존하는 것 중 어느 쪽이 더 중요한 버킷인지부터 구분하면, 어떤 Prefix에 어떤 규칙을 걸어야 할지가 훨씬 명확해집니다.

content-addressed 방식으로 객체 키를 설계하는 것도 보존과 삭제를 구분하는 데 도움이 됩니다. 객체의 내용 자체(파일 바이트)로부터 계산한 값을 키의 일부로 쓰면, 내용이 바뀔 때마다 새로운 키가 생기고 기존 키는 그대로 유지됩니다. 이렇게 하면 “같은 경로의 파일을 덮어써서 실수로 이전 버전을 잃는” 위험이 사라집니다. 키 자체가 내용에 따라 바뀌고 같은 키의 내용은 절대 바뀌지 않으므로, CDN이나 브라우저 캐시를 영구에 가깝게 길게 걸어 둘 여지가 생기는데, 이는 R2나 Lifecycle Rules가 보장하는 기능이 아니라 이 방식이 가능하게 해 주는 설계상의 이점이고, 실제 요청 비용 절감 효과는 캐시 설정과 실제 캐시 적중률에 따라 달라집니다. 다만 이 방식은 같은 내용이 쌓일수록 과거 버전이 계속 버킷에 남는다는 뜻이기도 해서, 정말 더 이상 참조되지 않는 과거 버전을 정리하려면 애플리케이션이 직접 “어떤 키가 지금도 쓰이고 있는지”를 판단하는 별도 로직이 필요합니다. Lifecycle 규칙의 단순한 경과일 조건만으로는 이 판단을 대신할 수 없습니다.

숫자로 보는 예시

전환이 오히려 손해가 되는 상황을 숫자로 짚어 보겠습니다. Cloudflare의 가격 정책은 사용량을 다음 과금 단위로 올려서 청구합니다. 예를 들어 Class A·B 작업이 100만 1건이면 200만 건으로 청구되고, 저장·검색 용량도 소수점 GB 단위는 올림됩니다. 아래 두 예시는 각각 저장·전환·검색·요청 요금을 행별로 나눠 계산하며, 요청 건수는 이미 올림 단위(100만 건)의 정수배로 가정해 이 올림 규칙이 결과를 바꾸지 않도록 단순화했습니다. 실제 요청 수가 100만 건의 정수배가 아니라면, 다음 단위까지 올려서 청구된다는 점을 감안해야 합니다. 또한 아래 표의 무료 사용량(저장 10GB-월, Class A·B 월 한도)은 이 예시의 객체만을 위한 것이 아니라 같은 계정의 다른 R2 사용량과 함께 나눠 쓰는 한도입니다. 계정에 이미 다른 버킷·객체가 그 한도를 일부 쓰고 있다면, 이 예시에서 가정한 무료 사용량만큼 깎이지 않을 수 있습니다.

예시 1 — 매주 다시 읽는 로그 100GB (전환 후 안정 상태 한 달)

업로드 후 20일이 지나 이미 Infrequent Access로 전환이 끝난 100GB짜리 로그 묶음을 한 달 동안 그대로 유지하면서, 매주 한 번씩(한 달에 4회) 분석 작업에서 전체를 다시 읽는다고 가정합니다. 비교 대상은 “같은 100GB를 한 달 내내 Standard에 그대로 뒀을 경우”입니다.

Standard는 무료 사용량(저장 10GB-월, Class B 월 1,000만 건) 안에 들어와 저장 요금 일부와 요청 요금이 깎이지만, Infrequent Access는 같은 사용량에도 무료 사용량이 전혀 없어 그대로 청구됩니다. 저장 단가는 Infrequent Access가 더 싸지만(월 $1.00 vs $1.35), 검색 요금과 요청 요금을 더하면 Infrequent Access 쪽이 한 달에 $8.60으로 Standard의 $1.35보다 훨씬 비쌉니다. 이 표는 전환 작업 자체가 이 한 달 이전에 이미 끝났다고 가정하므로, 전환 시점의 Class A 작업 비용은 표에 포함하지 않았습니다.

예시 2 — 연 1회만 읽는 과거 로그 1TB (1년 전체)

이번에는 1TB(1,000GB) 분량의 오래된 로그를 1년 내내 보관하다가 연말 감사 때 딱 한 번만 전체를 다시 읽는 경우입니다.

이 경우에는 반대로 Infrequent Access가 연간 $130.90으로 Standard의 $178.20보다 쌉니다. 이 표도 예시 1과 마찬가지로 전환 작업이 이 1년 비교 기간보다 앞서 끝났다고 가정했습니다. 만약 전환 자체가 이 1년 안에 일어난다면, 전환 건수가 아무리 적어도 Cloudflare의 올림 규칙 때문에 그달의 Infrequent Access Class A 작업이 최소 100만 건 단위로 청구됩니다. 그 전환이 그달의 유일한 Infrequent Access Class A 작업이라면 추가되는 금액은 $9.00이지만, 같은 달에 다른 전환이나 쓰기형 작업이 이미 있었다면 그 사용량과 합쳐서 올림되므로 실제로 추가되는 금액은 상황에 따라 달라집니다. 전환 객체 수가 수백~수천 개뿐이라도 “소액이라 무시할 수 있다”고 가정하면 안 되는 이유입니다.

두 예시는 용량과 기간 자체가 다릅니다(예시 1은 100GB·한 달, 예시 2는 1,000GB·1년). 그런데도 결과가 반대로 나오는 핵심 원인은 읽는 빈도입니다. 매주 다시 읽는 파일은 검색 요금과 요청 요금이 저장 단가 차익을 넘어서 전환이 손해지만, 1년에 한 번만 읽는 파일은 저장 요금 절감이 검색·요청 요금을 압도해 전환이 이득입니다. 그래서 일괄로 “오래된 파일은 전부 Infrequent Access로 전환”하는 규칙을 걸기 전에, 실제 읽기 빈도와 전환 작업이 비교 기간 안에 들어가는지를 먼저 확인해야 합니다.

Prefix 설계가 비용에 미치는 영향

Lifecycle 규칙이 Prefix 단위로 적용된다는 점은 단순히 “일부만 선택할 수 있다”는 뜻을 넘어, 버킷을 처음 설계할 때 폴더 구조 자체를 비용 관리에 맞춰 짜야 한다는 뜻이기도 합니다. 보존 대상과 정리 대상이 같은 Prefix 아래 뒤섞여 있으면, 둘을 나중에 분리하기가 까다로워집니다.

예를 들어 업로드 처리 중 생성되는 임시 변환 파일과, 처리가 끝난 뒤 실제로 서비스에 쓰이는 최종 파일을 같은 경로 아래 저장하면, 임시 파일에만 만료 규칙을 걸고 싶어도 Prefix만으로는 구분할 수 없습니다. 이런 상황을 피하려면 처음부터 tmp/나 processing/처럼 임시 산출물임을 나타내는 Prefix를 따로 두고, 완료된 최종 파일은 별도 Prefix(assets/, public/ 등)로 옮기는 식으로 폴더 구조를 설계하는 것이 좋습니다. 이렇게 나눠 두면 임시 Prefix에만 공격적인 Expiration 규칙을 걸고, 최종 Prefix에는 아예 규칙을 걸지 않는 식으로 명확하게 분리할 수 있습니다.

이미 보존 대상과 임시 파일이 섞여 있는 버킷이라면, 규칙을 걸기 전에 먼저 객체를 올바른 Prefix로 옮기는 마이그레이션 작업이 선행돼야 합니다. 이 이동 작업 자체도 쓰기형 작업(Class A)으로 과금되므로, 객체 수가 매우 많다면 이동 비용과 향후 절감되는 저장 비용을 비교해 실제로 이득이 되는지 가늠해 보는 것이 좋습니다.

대시보드에서 규칙을 추가하는 절차

실제로 규칙을 적용하는 화면은 다음 순서로 들어갑니다.

1. Cloudflare 대시보드의 R2 object storage 개요 화면에서 규칙을 적용할 버킷을 선택합니다.
2. 버킷 화면에서 Settings 탭으로 이동합니다.
3. Object Lifecycle Rules 항목에서 Add rule을 선택합니다.
4. 규칙을 적용할 Prefix를 지정하고(비워 두면 버킷 전체에 적용되므로, 그럴 의도라면 저장 후 적용 범위를 화면에서 다시 확인합니다), Expiration·Transition·AbortIncompleteMultipartUpload 중 원하는 동작을 고릅니다. Expiration은 경과일 또는 특정 날짜 중 하나로, Transition과 AbortIncompleteMultipartUpload는 경과일로만 조건을 입력합니다.
5. 마지막으로 Save changes를 눌러 저장합니다.

실제 설정 화면은 버킷의 Settings 탭 안에 있으며, 저장된 규칙은 이름·Prefix·동작·상태가 표로 표시됩니다.

버킷 하나에는 최대 1,000개까지 규칙을 만들 수 있습니다. 규칙을 저장한 뒤에는 바로 다음 섹션에서 설명한 24시간 반영 시간을 감안하고 기다려야 하며, 저장 직후 객체 목록을 다시 확인해도 상태가 그대로일 수 있다는 점은 설정이 잘못된 오류가 아닙니다.

대시보드 화면 대신 명령줄로도 버킷에 걸린 규칙을 확인할 수 있습니다. wrangler r2 bucket lifecycle list <버킷 이름>을 실행하면 현재 저장된 규칙이 그대로 출력됩니다.

규칙이 의도한 대로 적용됐는지는 버킷의 객체 목록에서 개별 객체의 저장 등급(Storage Class) 표시나, 결제·사용량 화면의 Class A 집계 변화로 가늠합니다. 다만 이 집계는 다른 Class A 작업과 화면에서 구분되지 않는 간접 지표라, 집계 변화만으로 전환 규칙의 작동을 단독으로 증명하지는 못합니다. 전환 규칙을 처음 걸었다면 적용 범위가 넓은 Prefix에 바로 걸기보다, 객체 수가 적고 영향이 제한적인 테스트용 Prefix 하나에 먼저 걸어 결과를 확인합니다. 문제가 없음을 눈으로 확인한 뒤 범위를 점진적으로 넓히면, 의도한 Prefix 바깥의 객체가 실수로 함께 전환되거나 삭제되는 설정 오류를 되돌릴 수 없는 전체 버킷 적용 전에 발견할 수 있습니다.

실제 버킷 사용량 조회 결과

이론적인 가격 계산이 실제 버킷에서는 어느 정도 규모로 체감되는지 확인하려고, WEFTWARE 블로그 이미지가 들어 있는 운영 버킷(weftware-blog-images-apac)을 wrangler r2 bucket info로 읽기 전용 조회했습니다. 이 명령은 용량·객체 수·설정을 보여 줄 뿐 실제 청구액은 알려 주지 않으므로, 아래 값은 사용량 기준이고 비용은 다음 문단에서 범위를 나눠 설명합니다.

171MB는 Standard의 무료 저장 용량(10GB-월)의 2%도 안 되는 크기입니다. 다만 이 무료 사용량은 이 버킷만을 위한 것이 아니라 같은 계정의 다른 R2 버킷·객체와 함께 나눠 쓰는 한도이므로, 이 버킷의 용량만으로 저장 요금이 $0이라고 확정할 수는 없고 계정 전체 Standard 저장량과 실제 청구 내역을 함께 봐야 정확합니다. 2,307개라는 숫자도 객체 수일 뿐 Class A·B 요청 수와는 다른 값입니다. 객체가 적어도 같은 파일을 반복해서 내려받으면 Class B(읽기형) 요청은 그만큼 쌓이므로, 이 버킷을 자주 조회하는 트래픽이 있다면 월 1,000만 건의 무료 한도에 실제로 얼마나 가까운지는 결제·사용량 화면의 요청 집계로 따로 확인해야 합니다. 분명한 것은 객체 수와 용량 자체는 작아서, 이 버킷만 두고 보면 Infrequent Access 전환으로 얻을 저장 비용 절감은 크지 않다는 점입니다. Lifecycle 규칙을 설계하기 전에 wrangler r2 bucket info <버킷 이름>으로 버킷 용량을, Cloudflare 대시보드의 사용량 화면으로 계정 전체 저장량과 요청 수를 함께 확인하는 것이 순서입니다.

마무리 정리

• Lifecycle 규칙은 Expiration(삭제), Transition(등급 전환), AbortIncompleteMultipartUpload(미완료 업로드 정리) 세 종류이며, Prefix 단위로 적용 범위를 좁힐 수 있습니다.
• 규칙 적용은 즉시가 아니라 보통 24시간 안에 반영되고, 전환과 만료가 24시간 이내로 겹치면 삭제가 우선합니다.
• Infrequent Access는 저장 단가는 낮지만 검색 요금과 30일 최소 보관 기간이 있어, 자주 읽거나 수명이 짧은 파일에는 오히려 불리합니다. 무료 사용량도 Standard에만 적용됩니다.
• 보존해야 하는 공개 자산에는 Expiration 규칙을 걸지 않고, 정말 임시적인 파일만 별도 Prefix로 분리해 좁은 범위로 규칙을 적용하는 것이 안전합니다.
• 규칙을 실제로 적용하기 전에는 객체를 용도별로 분류하고, 읽기 빈도와 규칙 간 겹침을 확인한 뒤 되돌릴 수 없는 삭제 범위를 분명히 하고 나서 적용합니다.
• wrangler r2 bucket info <버킷 이름>으로 버킷 용량을 먼저 확인합니다. 다만 무료 사용량은 버킷 하나가 아니라 계정 전체 Standard 사용량이 함께 쓰는 한도이므로, 이 버킷이 10GB-월보다 작다고 해서 Lifecycle 규칙의 절감 효과가 없다고 단정할 수는 없고, 계정 전체 사용량과 실제 청구 내역을 함께 봐야 정확합니다.