Cloudflare R2로 이미지 서버 만들기

이 글의 결론부터 — R2는 헤르메스 홈페이지 파일 서버로 좋은가

결론부터 말하면, Cloudflare R2는 헤르메스 홈페이지의 이미지 서버, 첨부 파일 서버, 다운로드 파일 저장소로 매우 좋은 선택지입니다. 특히 블로그형 사이트, AI 에이전트 운영 문서, 튜토리얼 이미지, 스크린샷, 생성 이미지, PDF, 음성 파일, 작은 동영상 파일처럼 읽기 트래픽이 많고 파일 자체는 정적인 경우에 잘 맞습니다.

다만 표현을 정확히 해야 합니다. R2는 흔히 "무제한 트래픽"이라고 불리지만, 이것은 인터넷 egress 요금이 무료라는 뜻에 가깝습니다. 저장 용량, 요청 수, Infrequent Access 검색 처리비 같은 비용은 여전히 존재합니다. 그러므로 "트래픽 비용 때문에 갑자기 수십만 원이 나오는 구조를 피하고 싶다"에는 강하지만, "아무 사용량이나 전부 무료"는 아닙니다.

헤르메스 홈페이지 기준으로 추천하는 구조는 다음과 같습니다.

즉 헤르메스 홈페이지를 장기 운영한다면, Vercel이나 앱 서버에는 코드와 페이지 렌더링만 맡기고, 이미지와 파일은 R2로 분리하는 것이 안전합니다. 이렇게 하면 사이트가 커져도 서버 디스크, 배포 용량, 이미지 트래픽, 백업 정책을 훨씬 단순하게 관리할 수 있습니다.

---

Cloudflare R2를 한 문장으로 이해하기

Cloudflare R2는 AWS S3와 비슷한 객체 스토리지인데, Cloudflare 네트워크와 붙어 있고 인터넷 egress 비용이 없는 파일 저장소입니다.

객체 스토리지는 폴더처럼 보이지만 실제로는 key와 object의 조합입니다. 예를 들어 다음과 같은 주소를 생각하면 됩니다.

일반 웹 서버의 파일 시스템과 다른 점은, 디렉터리에 파일을 저장하는 느낌이 아니라 이름표가 붙은 파일 덩어리를 저장하고 HTTP 또는 S3 API로 꺼내 쓰는 구조라는 점입니다. 그래서 이미지, 문서, 백업 파일, 동영상 조각, 데이터셋, AI 결과물처럼 "한 번 저장한 뒤 여러 번 읽는 파일"에 적합합니다.

R2의 핵심 포인트는 네 가지입니다.

헤르메스 홈페이지처럼 공개 글과 이미지가 계속 늘어나는 사이트에서는 이 네 가지가 모두 중요합니다. 글은 Next.js가 렌더링하고, 이미지는 R2가 들고 있고, Cloudflare가 전 세계 엣지에서 캐시해 주면 구조가 깔끔해집니다.

---

무제한 트래픽이라는 말의 정확한 의미

R2를 설명할 때 가장 많이 나오는 말이 "egress fee 없음"입니다. 이것을 한국어로 쉽게 말하면 파일을 밖으로 내보내는 데이터 전송량에 대해 별도 요금을 받지 않는다는 뜻입니다.

예를 들어 2MB짜리 이미지를 100만 번 다운로드하면 단순 계산으로 약 2TB의 트래픽이 생깁니다. AWS S3나 다른 클라우드에서는 이 egress가 비용의 핵심이 될 수 있습니다. R2는 이 부분을 무료로 내세웁니다. 그래서 이미지 서버, 파일 배포 서버, 정적 자산 서버에서 매력적입니다.

하지만 다음 비용은 남아 있습니다.

그러므로 실전 표현은 이렇게 잡는 것이 정확합니다.

헤르메스 홈페이지 운영 관점에서 중요한 것은 "트래픽이 터져도 egress 폭탄을 피할 수 있다"는 점입니다. AI 글이 갑자기 공유되어 이미지 조회가 늘어도 저장소 egress 때문에 큰 비용이 튀는 구조를 피할 수 있습니다.

---

가격 구조와 무료 한도

2026년 4월 기준 공식 문서의 R2 가격 구조는 다음과 같이 이해하면 됩니다. 실제 과금은 Cloudflare의 최신 가격표와 계정 플랜에 따라 달라질 수 있으므로 운영 전 반드시 대시보드에서 다시 확인해야 합니다.

Class A와 Class B는 요청 종류입니다. 아주 단순하게 보면 다음처럼 이해하면 됩니다.

이미지 서버에서는 보통 GET 요청이 많으므로 Class B가 중요합니다. 다만 커스텀 도메인과 Cloudflare Cache를 잘 쓰면 같은 이미지를 매번 R2 원본에서 읽지 않고 엣지 캐시에서 처리할 수 있습니다. 그러면 R2 요청 수와 원본 부하도 줄어듭니다.

무료 한도는 작은 개인 사이트에는 꽤 넉넉합니다. 예를 들어 헤르메스 홈페이지에 글 이미지와 작은 첨부 파일을 올리는 정도라면 처음에는 무료 한도 안에서 시작할 가능성이 큽니다. 하지만 다음 상황에서는 비용을 다시 계산해야 합니다.

운영 팁은 단순합니다. 처음에는 Standard로 시작하고, 정말 오래 보관하지만 거의 읽지 않는 백업성 파일만 Infrequent Access를 검토하는 것이 좋습니다. 홈페이지 이미지처럼 언제든 읽힐 수 있는 자산은 Standard가 더 안전합니다.

---

헤르메스 홈페이지에 R2가 잘 맞는 이유

헤르메스 홈페이지는 일반 블로그보다 파일 서버 분리가 더 중요합니다. 이유는 글만 올라가는 사이트가 아니라, AI 에이전트가 계속 이미지, 스크린샷, 로그, 리포트, 음성, PDF 같은 결과물을 만들 수 있기 때문입니다.

상황별로 보면 더 명확합니다.

특히 Next.js 프로젝트를 Vercel에 배포할 때는 이미지와 파일을 Git 저장소에 계속 넣는 방식이 장기적으로 좋지 않습니다. 파일이 늘수록 repository가 무거워지고, 빌드 시간이 늘고, 롤백과 캐시 관리도 복잡해집니다. R2를 쓰면 사이트 코드는 Git/Vercel에, 파일은 R2/Cloudflare에 분리됩니다.

권장 사고방식은 다음과 같습니다.

헤르메스 AI 에이전트와도 궁합이 좋습니다. Hermes가 글을 만들고, 이미지 파일을 압축하고, R2에 올리고, URL을 포스트 markdown에 삽입하는 운영 루프를 만들 수 있습니다. 사람은 최종 검수와 승인만 맡으면 됩니다.

---

처음 설정 순서 — 계정, 버킷, 토큰, 도메인

초기 설정은 크게 네 단계입니다.

R2 활성화

Cloudflare 대시보드에서 Storage & databases 메뉴의 R2로 들어가 활성화합니다. 무료로 시작할 수 있지만, 계정과 지역에 따라 결제수단 등록이 필요할 수 있습니다. 무료 한도 안에서는 보통 실제 청구가 발생하지 않지만, 결제수단 등록은 Cloudflare가 사용량 초과 과금을 처리하기 위해 요구할 수 있습니다.

운영 전 확인할 것:

버킷 생성

버킷 이름은 나중에 바꾸기 어렵다고 생각하고 정하는 것이 좋습니다. 헤르메스 홈페이지라면 다음처럼 분리할 수 있습니다.

처음에는 하나의 public assets 버킷으로 시작해도 됩니다. 하지만 사용자 업로드나 비공개 자료가 생기는 순간 공개 버킷과 비공개 버킷은 분리해야 합니다.

API 토큰 발급

R2 Overview에서 Manage R2 API Tokens로 들어가 토큰을 발급합니다. 중요한 원칙은 권한을 최소화하는 것입니다.

Access Key ID와 Secret Access Key는 생성 직후 한 번만 제대로 볼 수 있다고 생각하고 안전하게 보관해야 합니다. Git, 클라이언트 코드, 공개 문서, 이미지에 절대 넣으면 안 됩니다.

S3 endpoint 확인

R2의 S3 호환 endpoint는 다음 형태입니다.

AWS SDK를 사용할 때 region을 auto로 넣는 것이 기본입니다. 일부 호환 도구에서는 us-east-1 또는 빈 값도 동작할 수 있지만, 새 설정은 auto로 통일하는 것이 이해하기 쉽습니다.

---

이미지 서버로 공개하는 방법 — r2.dev와 커스텀 도메인

R2 버킷은 기본적으로 비공개입니다. 웹사이트 이미지로 쓰려면 공개 접근 방식을 정해야 합니다.

r2.dev 개발 URL

r2.dev는 Cloudflare가 제공하는 개발용 공개 URL입니다. 대시보드에서 Public Development URL을 켜면 https://pub-xxxx.r2.dev/... 형태로 접근할 수 있습니다.

장점은 간단합니다.

하지만 프로덕션에는 권장하지 않습니다.

따라서 r2.dev는 "업로드 테스트용"으로만 쓰고, 실제 헤르메스 홈페이지에는 커스텀 도메인을 붙이는 것이 좋습니다.

커스텀 도메인

프로덕션 추천 방식은 assets.vibecoding365days.com 같은 서브도메인을 R2 버킷에 연결하는 것입니다. 조건은 해당 도메인의 DNS가 Cloudflare에서 관리되고 있어야 한다는 점입니다.

설정 순서:

커스텀 도메인을 쓰면 Cloudflare의 장점이 살아납니다.

헤르메스 홈페이지 추천 도메인은 다음 중 하나입니다.

개인적으로는 assets.vibecoding365days.com을 추천합니다. 이미지뿐 아니라 PDF, 썸네일, 음성, 작은 다운로드 파일까지 자연스럽게 포괄할 수 있기 때문입니다.

---

업로드 방법 5가지 — 대시보드, Wrangler, Python, JavaScript, rclone

R2 업로드 방법은 운영 단계에 따라 달라집니다.

대시보드 UI

버킷에 들어가 Upload를 누르고 파일을 드래그하면 됩니다. 가장 쉽지만 반복 운영에는 적합하지 않습니다. 글 하나 작성하면서 대표 이미지 하나를 올리는 정도는 괜찮습니다.

실전 팁:

Wrangler CLI

Cloudflare 개발 환경을 이미 쓰고 있다면 Wrangler가 편합니다.

명령 예시:

wrangler r2 bucket create hermes-public-assets

wrangler r2 object put hermes-public-assets/images/posts/r2-guide/hero.webp --file=hero.webp --content-type=image/webp

wrangler r2 object get hermes-public-assets/images/posts/r2-guide/hero.webp --file=downloaded-hero.webp

Wrangler는 사람이 직접 관리하는 개발자 작업에 좋습니다. 다만 대량 파일 동기화는 rclone이 더 편할 때가 많습니다.

Python boto3

Hermes Agent와 가장 잘 맞는 방식은 Python입니다. Hermes가 파일을 만들고, 압축하고, R2에 올리고, URL을 포스트에 삽입하는 자동화를 만들기 쉽습니다.

개념 예시:

Python에서 boto3 client를 만들고 upload_file 또는 put_object를 호출하면 됩니다. 대용량 파일은 upload_file이 내부적으로 멀티파트 업로드를 처리할 수 있어 편합니다.

Hermes 자동화에 넣을 때는 다음 규칙을 권장합니다.

JavaScript AWS SDK

Next.js API route나 Node.js 서버에서 R2에 파일을 올릴 때는 @aws-sdk/client-s3를 사용하면 됩니다.

개념 예시:

브라우저에서 직접 R2 Secret을 사용하면 절대 안 됩니다. 프론트엔드가 업로드해야 한다면 서버가 presigned URL을 만들어 주고, 브라우저는 그 URL로 PUT만 해야 합니다.

rclone

이미지 폴더가 수천 개 있거나 기존 서버에서 R2로 옮길 때는 rclone이 강합니다.

명령 예시:

rclone copy ./public/images r2:hermes-public-assets/images --transfers=16 --checkers=32

rclone sync ./public/downloads r2:hermes-public-assets/downloads --transfers=8 --checkers=16

주의할 점은 sync입니다. sync는 대상에만 있는 파일을 지울 수 있습니다. 처음에는 copy로 이전하고, 운영이 안정된 뒤에 sync를 쓰는 것이 안전합니다.

---

대용량 파일과 멀티파트 업로드

R2는 큰 파일도 다룰 수 있습니다. 공식 제한 기준으로 객체 최대 크기는 약 5TiB이고, 단일 업로드 파트는 5GiB 제한이 있습니다. 멀티파트 업로드를 사용하면 큰 파일을 여러 조각으로 나누어 병렬 업로드하고 실패한 부분만 다시 시도할 수 있습니다.

헤르메스 홈페이지에서는 대용량 파일이 아주 많지는 않겠지만, 다음 경우 멀티파트가 유용합니다.

주의점도 있습니다. 멀티파트 업로드가 중간에 실패하고 완료되지 않으면 미완료 업로드 상태가 남을 수 있습니다. R2에는 기본적으로 생성 후 7일 뒤 미완료 멀티파트 업로드를 정리하는 lifecycle 규칙이 있지만, 대량 업로드를 자주 한다면 직접 모니터링하는 것이 좋습니다.

---

Presigned URL — 서버를 거치지 않는 직접 업로드

사용자 업로드를 구현할 때 가장 피해야 할 구조는 브라우저가 큰 파일을 Next.js 서버로 올리고, Next.js 서버가 다시 R2로 올리는 방식입니다. 이렇게 하면 서버가 중간에서 파일을 두 번 처리해야 하고, timeout과 메모리 문제가 생기기 쉽습니다.

더 좋은 구조는 presigned URL입니다.

흐름:

presigned URL의 장점:

주의점:

헤르메스 홈페이지에 Q&A 이미지 첨부나 사용자 자료 업로드를 넣는다면, presigned URL + private bucket + 검수 후 public bucket 복사 구조를 추천합니다.

---

캐시 전략 — 이미지 서버 성능을 제대로 뽑는 법

R2를 이미지 서버로 쓴다고 해서 자동으로 모든 것이 최적화되는 것은 아닙니다. 커스텀 도메인을 붙이고 Cloudflare Cache 정책을 잘 잡아야 합니다.

기본 원칙

이미지 서버의 캐시 전략은 두 가지 중 하나입니다.

추천은 첫 번째입니다. 파일명에 날짜, 버전, 해시를 넣고 Cache-Control을 길게 잡습니다.

권장 예시:

Cloudflare Cache Rules

커스텀 도메인을 쓰면 Cloudflare Cache Rules를 사용할 수 있습니다. 기본적으로 Cloudflare는 특정 확장자 중심으로 캐시합니다. 모든 파일을 캐시하고 싶다면 Cache Everything 규칙이나 확장자별 규칙을 검토해야 합니다.

헤르메스 assets 도메인 추천 규칙:

중요한 것은 바뀌는 파일과 안 바뀌는 파일을 URL 레벨에서 분리하는 것입니다. 글 이미지처럼 한 번 발행 후 거의 안 바뀌는 파일은 긴 캐시가 좋고, 매일 바뀌는 통계 JSON은 같은 방식으로 캐시하면 안 됩니다.

이미지 최적화와 R2의 역할 구분

R2는 객체 스토리지이지 이미지 변환 서비스가 아닙니다. 이미지 리사이징, 포맷 변환, 썸네일 생성은 별도 단계가 필요합니다.

선택지는 다음과 같습니다.

헤르메스 홈페이지는 글 중심 사이트이므로 처음에는 업로드 전 변환 + R2 정적 서빙이 가장 단순합니다. 즉 원본 이미지를 1600px webp, 800px webp, 400px webp로 만들어 R2에 올리고, 페이지에서는 필요한 크기를 직접 참조합니다.

---

권장 폴더 구조와 파일 이름 규칙

R2에는 실제 폴더가 있는 것은 아니지만 key에 슬래시를 넣으면 폴더처럼 관리할 수 있습니다. 처음부터 규칙을 잡아야 나중에 수천 개 파일이 생겨도 관리가 됩니다.

헤르메스 홈페이지 추천 구조:

파일 이름 규칙:

추천 예시:

이렇게 하면 나중에 Hermes에게 "2026년 4월 R2 글에 들어간 이미지 목록 정리해줘"라고 지시했을 때도 규칙적으로 찾을 수 있습니다.

---

Next.js 홈페이지에서 쓰는 실전 구조

헤르메스 홈페이지가 Next.js 기반이라면 R2는 다음 세 지점과 연결됩니다.

공개 이미지 참조

가장 단순한 방식은 markdown 또는 TS 포스트 데이터에 R2 URL을 직접 넣는 것입니다.

예시 URL:

https://assets.vibecoding365days.com/images/posts/2026/04/cloudflare-r2-hermes-file-server/hero-1600.webp

이 방식은 빠르고 단순합니다. 단, 파일이 삭제되면 글 이미지도 깨집니다. 그래서 발행된 글에 쓰인 이미지는 lifecycle로 자동 삭제하지 않는 것이 좋습니다.

Next Image와 remotePatterns

Next.js의 Image 컴포넌트를 쓴다면 R2 커스텀 도메인을 허용해야 합니다. 프로젝트 버전에 따라 next.config 작성 방식이 달라질 수 있으므로 현재 프로젝트의 Next.js 문서를 확인하고 설정해야 합니다.

개념은 다음과 같습니다.

다만 R2 + Cloudflare Cache에서 이미 최적화된 webp/avif를 제공한다면, 모든 이미지를 Next Image 최적화 파이프라인에 다시 태울 필요는 없습니다. 정적 글 이미지는 일반 img 태그나 커스텀 렌더러로 충분할 수 있습니다.

업로드 API route

사용자 업로드가 필요하다면 API route는 파일 본문을 받기보다 presigned URL을 발급하는 역할만 맡기는 것이 좋습니다.

권장 흐름:

이 구조를 쓰면 서버리스 환경에서도 큰 파일 업로드를 안정적으로 처리할 수 있습니다.

---

Hermes Agent로 R2 운영 자동화하기

R2의 진짜 장점은 Hermes Agent와 결합할 때 커집니다. 파일 서버를 사람이 수동으로 관리하는 대신, Hermes가 규칙에 따라 업로드, 검증, URL 삽입, 캐시 정책 점검, 오래된 임시 파일 정리를 처리할 수 있습니다.

가능한 자동화 예시는 다음과 같습니다.

Hermes에게 줄 수 있는 운영 지시 예시:

중요한 운영 원칙은 Hermes에게 Secret을 출력하게 하지 않는 것입니다. R2 Access Key와 Secret은 환경변수로만 주입하고, 로그에는 endpoint, bucket, key, public URL 정도만 남깁니다. 실패 로그에도 Secret이 찍히면 안 됩니다.

---

보안 설정 — 절대 공개하면 안 되는 것

R2는 파일 서버로 쓰기 쉽지만, 공개 범위를 잘못 잡으면 사고가 납니다. 특히 사용자 업로드와 내부 산출물을 다룰 때 조심해야 합니다.

공개 버킷과 비공개 버킷 분리

가장 중요한 원칙은 공개와 비공개를 버킷 단위로 분리하는 것입니다.

"나중에 경로로 막으면 되겠지"보다 버킷 자체를 분리하는 편이 안전합니다. 공개 버킷에는 공개되어도 되는 파일만 들어가야 합니다.

Secret 관리

절대 하면 안 되는 것:

권장 방식:

업로드 검수

사용자 업로드를 받는다면 R2에 올렸다고 끝이 아닙니다. 최소한 다음 검사가 필요합니다.

홈페이지에 단순 운영자 업로드만 있다면 복잡한 검수는 줄일 수 있습니다. 하지만 공개 사용자 업로드가 들어오는 순간 private bucket, presigned URL, 검수 queue, public 복사 구조를 갖추는 것이 좋습니다.

---

운영 모니터링과 비용 폭주 방지

R2는 egress가 무료라서 안심할 수 있지만, 요청 수와 저장 용량은 계속 쌓입니다. 운영자는 월 1회 이상 다음 항목을 확인해야 합니다.

비용 폭주를 줄이는 규칙:

Hermes 자동 리포트 예시:

이런 리포트는 Hermes의 cron 기능과 잘 맞습니다. 월요일 오전에 R2 점검 요약을 텔레그램으로 받게 하면, 파일 서버가 조용히 망가지는 일을 줄일 수 있습니다.

---

S3, Supabase Storage, Vercel Blob, Backblaze B2와 비교

R2가 항상 정답은 아닙니다. 선택은 사이트의 구조와 운영 방식에 따라 달라집니다.

헤르메스 홈페이지의 추천 결론:

R2가 특히 빛나는 지점은 트래픽 예측이 어렵고, 공개 파일 조회가 많고, Cloudflare 도메인을 이미 쓰는 사이트입니다. 이 조건이면 R2는 운영 난이도와 비용 사이의 균형이 좋습니다.

---

장점, 단점, 실제 평판을 균형 있게 보기

공식 문서와 커뮤니티 반응을 종합하면 R2의 평판은 대체로 "egress 비용을 없애고 S3 호환으로 쉽게 붙일 수 있는 매우 매력적인 객체 스토리지"에 가깝습니다. 특히 개인 개발자, 스타트업, 정적 사이트 운영자, 파일 다운로드가 많은 서비스에서 좋은 평가를 받습니다.

장점:

단점과 주의점:

운영자가 특히 조심해야 할 오해:

헤르메스 홈페이지 운영 관점에서 R2는 "강력 추천하지만, 공개/비공개 분리와 캐시 정책을 같이 설계해야 하는 도구"입니다. 그냥 버킷 하나 만들고 모든 파일을 넣는 방식보다, 운영 규칙을 먼저 정하고 시작해야 오래 갑니다.

---

헤르메스 홈페이지 추천 아키텍처

최종 추천 구조는 다음과 같습니다.

가장 단순한 1단계 구조

처음에는 이렇게 시작합니다.

이 단계는 설정이 쉽고 사고 가능성이 낮습니다. 공개되어도 되는 파일만 넣는 것이 핵심입니다.

운영 자동화 2단계 구조

글과 이미지가 늘어나면 Hermes 자동화를 붙입니다.

이 단계부터는 사람이 파일을 직접 올리는 일이 줄어듭니다.

사용자 업로드 3단계 구조

나중에 Q&A 이미지 첨부, 자료 제출, 커뮤니티 기능이 들어가면 다음처럼 확장합니다.

이 구조는 조금 복잡하지만 공개 사이트에서는 안전합니다. 특히 AI 에이전트가 자동으로 파일을 다루는 경우, 비공개 원본과 공개 결과물을 분리하는 습관이 중요합니다.

---

Cache-Control, CORS, Smart Tiered Cache 실전 설정

R2를 파일 저장소로만 쓰면 절반만 쓰는 것입니다. 이미지 서버로 제대로 쓰려면 업로드 시 HTTP 메타데이터를 넣고, Cloudflare Cache Rules를 만들고, 브라우저 직접 업로드가 필요하면 CORS까지 설정해야 합니다.

업로드 시 Cache-Control 헤더 설정

이미지처럼 한 번 발행하면 거의 바뀌지 않는 파일은 업로드 순간부터 긴 캐시를 붙이는 것이 좋습니다. 핵심은 파일명에 날짜, 버전, 해시를 넣고 Cache-Control을 길게 주는 것입니다.

Python boto3 개념 예시:

실제 코드 형태로 쓰면 다음 의미입니다.

s3.put_object에 Bucket, Key, Body, ContentType, CacheControl을 함께 전달합니다. CacheControl 값은 public, max-age=31536000, immutable처럼 둡니다. 31536000초는 약 1년이고, immutable은 이 URL의 파일이 바뀌지 않는다는 신호입니다.

주의할 점은 같은 URL로 파일을 자주 덮어쓰면 1년 캐시가 오히려 문제가 된다는 것입니다. 그래서 대표 이미지를 바꿀 가능성이 있으면 hero.webp를 덮어쓰기보다 hero-20260426-v1.webp, hero-20260426-v2.webp처럼 새 key를 쓰는 방식이 좋습니다.

Cloudflare Cache Rules 설정

커스텀 도메인을 붙인 뒤에는 Cloudflare 대시보드에서 Cache Rules를 설정합니다. 대표적인 흐름은 다음과 같습니다.

헤르메스 홈페이지라면 다음 규칙이 현실적입니다.

캐시가 잘 작동하면 R2까지 도달하는 GET 요청, 즉 Class B operation을 크게 줄일 수 있습니다. 커뮤니티에서는 매우 높은 캐시 히트율을 구성해 수억 요청 중 R2 원본까지 도달하는 요청을 극히 낮게 만든 사례가 공유됩니다. 다만 이런 수치는 사이트 구조, 파일명 전략, 캐시 규칙, 사용자 지역, Cloudflare 플랜에 따라 달라지므로 그대로 보장되는 값은 아닙니다.

Smart Tiered Cache 활성화

Smart Tiered Cache는 Cloudflare가 R2 오리진에 가까운 상위 데이터센터를 경유하게 해 원본 히트를 줄이는 방식입니다. 대시보드에서는 Caching 메뉴의 Tiered Cache에서 Smart Tiered Cache를 활성화할 수 있습니다.

효과는 다음과 같습니다.

이미지 서버가 커질수록 Smart Tiered Cache는 켜두는 편이 좋습니다. 특히 assets 도메인이 전 세계에서 조회되는 구조라면 R2 원본을 보호하는 완충층 역할을 합니다.

CORS 설정 — 브라우저 접근 허용

브라우저가 R2 파일을 직접 읽거나 presigned URL로 업로드하려면 CORS 정책이 필요합니다. 단순히 img 태그로 공개 이미지를 보여 주는 것만으로는 CORS가 항상 필요한 것은 아니지만, JavaScript fetch, canvas 처리, presigned PUT 업로드에는 필요해지는 경우가 많습니다.

권장 CORS 정책 개념:

중요한 실수는 AllowedOrigins에 경로를 넣는 것입니다. Origin은 스킴, 호스트, 포트까지만 포함합니다.

운영 팁은 개발 origin과 운영 origin을 분리해 명시하는 것입니다. 모든 origin을 허용하는 별표는 공개 다운로드에는 편할 수 있지만, 사용자 업로드나 인증 흐름에는 신중해야 합니다.

---

Lifecycle Rules와 Infrequent Access 운영법

R2에는 객체를 일정 기간 뒤 자동 삭제하거나 Standard에서 Infrequent Access로 전환하는 lifecycle rule이 있습니다. 파일 서버를 오래 운영하면 임시 업로드, 로그, AI 산출물, 오래된 백업이 계속 쌓이므로 lifecycle이 중요합니다.

자동 삭제 규칙

예를 들어 logs/ 아래 파일은 90일 뒤 삭제하도록 만들 수 있습니다. 대시보드에서는 버킷 Settings의 Object Lifecycle Rules에서 Add rule을 선택하고 prefix와 만료 기간을 지정합니다.

권장 삭제 규칙:

가장 중요한 원칙은 공개 글에 이미 연결된 이미지는 lifecycle로 삭제하지 않는 것입니다. 발행된 포스트 이미지가 사라지면 SEO, 사용자 경험, 아카이브 품질이 모두 나빠집니다.

Infrequent Access 전환

Infrequent Access는 저장 단가가 낮지만 읽을 때 retrieval 비용이 있고 30일 최소 보관 기간이 있습니다. 그래서 무조건 싸지 않습니다.

30일 전에 삭제해도 30일분 비용이 청구될 수 있으므로, 임시 파일을 Infrequent Access로 보내는 것은 보통 좋지 않습니다. 임시 파일은 짧게 삭제하고, 장기 보관 파일만 IA 전환을 검토합니다.

버킷당 rule 수와 운영 원칙

공식 제한 기준으로 lifecycle rule은 버킷당 최대 1,000개까지 가능합니다. 하지만 rule이 많다고 좋은 것은 아닙니다. prefix 설계를 잘해서 적은 rule로 넓게 관리하는 편이 낫습니다.

좋은 설계:

나쁜 설계는 글 slug마다 lifecycle rule을 따로 만드는 것입니다. 나중에 rule 관리가 어려워집니다. 처음부터 prefix 정책을 크게 잡는 것이 운영에 유리합니다.

---

Event Notifications와 Workers Binding 자동화

R2는 단순 파일 저장소를 넘어 이벤트 기반 자동화를 만들 수 있습니다. 오브젝트가 생성되거나 삭제될 때 Cloudflare Queues로 이벤트를 보내고, Consumer Worker가 후속 작업을 처리하는 구조입니다.

Event Notifications

업로드 이벤트를 Queue로 보내면 다음 작업을 자동화할 수 있습니다.

이 구조는 AWS의 S3 Event Notification과 SNS/SQS/Lambda 조합에 가깝게 이해하면 됩니다. Cloudflare에서는 R2 이벤트가 Queue로 들어가고, Worker가 메시지를 소비합니다.

이벤트 메시지에는 보통 계정, action, bucket, object key, object size, eTag, eventTime 같은 정보가 들어갑니다. 이 정보로 어떤 파일이 올라왔는지 파악하고 후속 처리를 시작할 수 있습니다.

헤르메스 홈페이지에서 유용한 활용:

Workers Binding

Cloudflare Workers에서는 R2 버킷을 binding으로 연결해 S3 API 없이 직접 접근할 수 있습니다. wrangler 설정의 r2_buckets에 binding 이름과 bucket_name을 지정한 뒤, Worker 코드에서 env.MY_BUCKET.get, env.MY_BUCKET.put 같은 API를 쓰는 방식입니다.

개념 구조:

Workers Binding의 장점은 Cloudflare 네트워크 내부에서 R2에 접근한다는 점입니다. 인증 프록시, private 파일 다운로드, 이미지 접근 제어, 간단한 리다이렉트, signed cookie 검증 같은 일을 Worker에서 처리하고 R2를 원본 저장소로 둘 수 있습니다.

예를 들어 비공개 파일 다운로드는 이렇게 설계할 수 있습니다.

이 구조를 쓰면 private bucket을 공개하지 않고도 필요한 사람에게만 파일을 제공할 수 있습니다.

R2 이벤트와 Hermes Agent 조합

Event Notifications와 Hermes를 조합하면 파일 서버가 자동 운영 체계가 됩니다.

이렇게 하면 파일 업로드가 단순 저장으로 끝나지 않고, 사이트 운영 작업으로 이어집니다. 특히 헤르메스 홈페이지처럼 AI 에이전트가 콘텐츠와 이미지 자산을 계속 생성하는 사이트에서는 이 이벤트 기반 구조가 장기적으로 유리합니다.

---

커뮤니티 후기와 레딧 평판 종합

공식 문서만 보면 R2는 거의 완벽해 보입니다. 하지만 실제 운영에서는 커뮤니티 후기가 중요합니다. 공개 커뮤니티와 레딧 후기를 종합하면 평가는 대체로 긍정적이지만, 결제와 고객지원에 대한 불만은 반복적으로 보입니다. 아래 내용은 특정 개인 사례를 그대로 보장된 사실로 받아들이기보다, 운영자가 참고할 리스크 신호로 보는 것이 좋습니다.

긍정적 평가

긍정적 후기는 주로 비용 절감과 안정성에 집중됩니다.

이미지 서버 관점에서는 이 후기가 중요합니다. 헤르메스 홈페이지의 글 이미지, 스크린샷, 다운로드 자료처럼 "저장량보다 읽기 트래픽이 더 걱정되는" 워크로드라면 R2의 장점이 크게 살아납니다.

부정적 평가와 가장 큰 리스크

가장 반복적으로 언급되는 불만은 고객지원과 결제 문제입니다. 일부 사용자는 결제 실패, 카드 문제, 청구 상태 오류가 생겼을 때 R2나 다른 Cloudflare 서비스 접근이 빠르게 제한됐고 지원 응답이 늦었다고 보고합니다.

운영자가 받아들여야 할 교훈은 다음입니다.

AWS와 비교할 때 일부 커뮤니티 사용자는 "AWS는 결제 문제가 있어도 경고와 유예가 긴 편인데, Cloudflare는 더 빠르게 제한될 수 있다"고 느낍니다. 이 평가는 개인 경험에 따라 다르지만, 운영자는 최악의 상황을 가정해야 합니다.

R2 평판 종합 점수

결론은 단순합니다. R2는 기술적으로 훌륭하지만, 결제수단 관리와 백업 전략 없이 핵심 파일을 단독 보관하는 것은 좋지 않습니다. egress가 무료이므로 다른 스토리지로 백업을 빼는 비용 부담이 작다는 점을 적극 활용해야 합니다.

---

경쟁사 비교 상세 — 비용, egress, 기능

R2의 경쟁력은 저장 단가 하나가 아니라 저장 비용, 요청 비용, egress, CDN 결합, 운영 난이도를 합친 결과입니다.

저장 비용 비교

순수 백업 저장만 보면 R2가 항상 가장 싸지는 않습니다. Backblaze B2나 Wasabi가 더 저렴할 수 있습니다. 하지만 공개 파일을 많이 읽는 순간 egress 비용이 결정적인 차이를 만듭니다.

10TB 전송 시 egress 비용 감각

정확한 금액은 리전, 플랜, 할인, CDN 조합에 따라 달라집니다. 중요한 것은 이미지 서버처럼 트래픽 예측이 어려운 서비스에서 R2가 egress 비용 리스크를 크게 줄인다는 점입니다.

기능 비교

규정 준수, Object Lock, 딥 아카이브가 중요하면 S3가 더 맞을 수 있습니다. 반대로 공개 이미지와 다운로드 파일이 많고 Cloudflare를 이미 쓰고 있다면 R2가 단순하고 경제적입니다.

---

현재 프로젝트 적용 비용 시나리오

헤르메스 홈페이지가 이미지 자동 생성, 글 발행, 스크린샷 저장, 다운로드 자료 배포를 한다고 가정하면 R2는 매우 적합합니다.

대략적인 저장량별 감각은 다음과 같습니다. 무료 10GB를 제외한 단순 저장 비용 감각이며, 실제 비용은 요청 수, 캐시 hit, IA 사용 여부에 따라 달라집니다.

R2의 가치는 "한 번 저장하고 많이 읽는" 워크로드에서 큽니다. 헤르메스 홈페이지의 글 이미지와 AI 산출물은 이 패턴에 가깝습니다.

추천 운영 결론

가장 중요한 운영 원칙은 세 가지입니다.

1. 공개 파일과 비공개 파일을 버킷 단위로 분리합니다.
2. 이미지 URL은 버전 파일명과 긴 캐시를 전제로 설계합니다.
3. Cloudflare 계정/결제 문제가 생겨도 복구할 수 있도록 정기 백업과 대체 경로를 둡니다.

---

최종 체크리스트

R2를 헤르메스 홈페이지 파일 및 이미지 서버로 도입하기 전 체크리스트입니다.

계정과 버킷

도메인과 공개 설정

업로드와 파일 규칙

보안

운영

최종 판단은 간단합니다.

헤르메스 홈페이지가 글, 이미지, 자료실, AI 산출물을 계속 쌓아갈 계획이라면 R2는 지금 붙여도 좋은 파일 서버입니다. 처음에는 public assets 버킷 하나와 커스텀 도메인으로 시작하고, 사용자 업로드가 생기면 private bucket과 presigned URL 구조로 확장하면 됩니다.

---

참고한 공식 문서

이 글은 2026년 4월 기준 Cloudflare 공식 문서와 공개 자료를 바탕으로 정리했습니다. Cloudflare의 가격, 제한, 기능은 변경될 수 있으므로 실제 도입 전에는 최신 문서를 다시 확인해야 합니다.