매달 수천 달러 나오는 S3 트래픽 비용? R2로 이전해 3단계로 비용 90% 줄이기(실제 사례 포함)

AWS 청구서를 확인해 보니 스토리지 비용은 고작 $230인데 트래픽 비용은 무려 $4,500이었습니다. 50TB 트래픽이 발생하자 지갑이 순식간에 가벼워졌습니다. 동영상이나 이미지 호스팅 서비스를 운영하는 지인들과 이야기해 보니 모두 S3 트래픽 비용에 시달리고 있었습니다. SaaS를 운영하는 한 지인은 회사에서 매달 10TB의 트래픽이 발생해 S3 청구액이 $891인데, 스토리지 비용은 $15에 불과해 트래픽 비용이 98%를 차지한다고 했습니다.

Cloudflare R2로 바꾸면 어떨까요? 송신 트래픽 비용이 없으므로 똑같이 10TB의 트래픽이 발생해도 R2에는 스토리지 비용 $15만 내면 됩니다. 이 글에서는 실제 상황의 비용 계산, API 호환성 테스트, 30분 이전 튜토리얼과 직접 겪은 함정을 공유합니다. 애플리케이션의 트래픽이 많다면(월 500GB 초과) 이 글을 통해 매년 수천 달러에서 수만 달러를 절약할 수 있습니다.

S3에서 R2로 이전해야 하는 이유: 데이터로 확인하기

S3의 숨은 비용 함정

AWS의 요금 전략은 꽤 영리합니다. 스토리지 비용 $0.023/GB는 얼핏 매우 저렴해 보여 처음에는 가성비가 좋다고 생각합니다. 하지만 트래픽이 발생하기 시작하면 송신 트래픽 비용 $0.09/GB가 진짜 큰 부담이라는 사실을 알게 됩니다.
직접 계산해 보겠습니다. 동영상 사이트를 운영하며 동영상 10TB를 저장하고 사용자의 시청과 다운로드로 매달 50TB의 트래픽이 발생한다고 가정해 보겠습니다.

• 스토리지 비용: 10TB × $23/TB = 월 $230
• 트래픽 비용: 50TB × $90/TB = 월 $4,500
• 합계: 월 $4,730
  보이시나요? 트래픽 비용이 95%를 차지합니다. 이것도 $0.09/GB를 기준으로 계산한 것이며, 트래픽이 적은 사용자에게는 할인조차 없습니다.
  이미지 호스팅 서비스를 운영하는 지인은 월 트래픽이 20TB인데 S3에 1년 동안 $20,676을 지불했습니다. 그는 스토리지 비용은 $276뿐이고 나머지는 전부 트래픽 비용이라며 AWS를 위해 일하는 기분이라고 불평했습니다.

R2의 비용상 이점은 정확히 무엇인가

Cloudflare R2의 가장 강력한 무기는 송신 트래픽 비용이 없다는 것입니다.
단순한 할인이 아니라 완전히 무료입니다. 트래픽이 1TB든 100TB든 비용은 $0입니다. 트래픽이 많은 애플리케이션에는 그야말로 구명줄과 같습니다.
구체적인 비용은 다음과 같습니다.

• 스토리지 비용: $0.015/GB, 즉 $15/TB(S3보다 35% 저렴)
• 송신 트래픽 비용: $0(S3는 $90/TB)
• 작업 비용: Class A 작업은 백만 회당 $4.50, Class B 작업은 백만 회당 $0.36
  R2에는 무료 한도도 있습니다.
• 스토리지 10GB
• Class A 작업 100만 회(쓰기, 목록 조회)
• Class B 작업 1,000만 회(읽기)
  개인 블로그나 소규모 프로젝트라면 무료 한도 안에서 완전히 해결할 수도 있습니다.

실제 사례 비교: 계산만 보지 말고 데이터를 확인하세요

대표적인 상황 3개의 비용을 비교해 정리했습니다.

이전하지 않는 편이 나은 경우

장점을 많이 이야기했지만, R2가 적합하지 않은 상황도 알아야 합니다. 이전한 뒤 맞지 않는다는 사실을 발견해서는 안 되기 때문입니다.

1. AWS 생태계에 강하게 결합된 경우: 애플리케이션에서 Lambda, Athena, EMR 같은 AWS 서비스를 많이 사용한다면 R2로 이전할 때 코드를 대폭 수정해야 할 수 있어 가치가 없습니다.
2. 고급 규정 준수 기능이 필요한 경우: S3에는 Object Lock, Legal Hold 같은 규정 준수 기능이 있어 금융·의료 업계에서 필수로 요구될 수 있습니다. R2는 현재 이를 지원하지 않습니다.
3. 트래픽이 매우 적은 경우: 월 트래픽이 100GB 미만이면 절약할 수 있는 금액이 크지 않으므로 비즈니스에 집중하는 편이 낫습니다.
4. 데이터 지역 요구 사항이 엄격한 경우: S3는 33개 리전을 선택할 수 있지만 R2는 location hint를 제공하더라도 선택지가 상대적으로 적습니다. 중국이나 러시아처럼 특정 국가에 데이터를 저장해야 한다면 R2가 요구 사항을 충족하는지 먼저 확인해야 합니다.
   제 판단 기준은 월 트래픽이 500GB를 넘으면 이전 ROI가 충분하다는 것입니다. 그보다 적다면 비용에 얼마나 민감한지에 따라 결정하면 됩니다.

R2와 S3 API 호환성의 진실: 함정 회피 가이드

R2는 어느 정도까지 호환되는가

가장 궁금한 부분은 R2로 이전했을 때 애플리케이션이 중단되지는 않는지, 코드를 얼마나 수정해야 하는지입니다.
제가 직접 테스트한 결론은 R2가 S3 API 핵심 기능의 80~90%를 구현했으며, 일상적으로 사용하는 작업은 거의 모두 지원한다는 것입니다.
Cloudflare는 S3 API에서 가장 자주 쓰는 부분을 영리하게 구현했습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

• 기본 작업: PutObject, GetObject, DeleteObject, ListObjects(사용 사례의 99%를 차지)
• 고급 기능: Multipart Upload(대용량 파일 분할 업로드), Presigned URLs(사전 서명 URL), CORS 설정
• 권한 관리: Bucket policies, IAM-style access keys
  가장 편한 점은 endpoint URL과 credentials만 변경하면 되므로 코드를 거의 수정할 필요가 없다는 것입니다.
  예를 들어 AWS SDK for JavaScript를 사용하는 프로젝트를 R2로 이전할 때는 코드 3줄만 수정했습니다.

// 기존 S3 설정
const s3 = new AWS.S3({
  region: 'us-east-1'
});
// R2로 이전(endpoint와 credentials만 변경)
const r2 = new AWS.S3({
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  accessKeyId: R2_ACCESS_KEY_ID,
  secretAccessKey: R2_SECRET_ACCESS_KEY,
  signatureVersion: 'v4',
});

그 밖의 업로드, 다운로드, 삭제 코드는 전혀 수정하지 않고 그대로 실행했습니다. 2주 동안 테스트했지만 호환성 문제는 발견하지 못했습니다.

지원하지 않는 기능: 사전 주의 사항

R2는 S3를 완벽하게 대체하지 못하며 실제로 지원하지 않는 기능도 있습니다. 이전 전에 애플리케이션에서 다음 기능을 사용하는지 반드시 확인해야 합니다.
1. S3 Select(SQL 객체 쿼리)
S3 Select를 사용해 S3에서 직접 SQL 쿼리를 실행한다면 R2에서는 지원되지 않습니다. 데이터를 먼저 다운로드한 뒤 쿼리하거나 다른 방법을 사용해야 합니다.
2. Object Lock과 Legal Hold(규정 준수 잠금)
금융·의료 업계에서는 규정 준수 요구 사항(WORM - Write Once Read Many)을 충족하기 위해 이 기능을 자주 사용합니다. R2에는 아직 이 기능이 없으므로 규정 준수 감사에서 이를 요구한다면 이전하지 마세요.
3. Versioning(버전 관리)
R2에서는 S3의 버전 관리 기능을 제한적으로 지원합니다. 애플리케이션이 버전 롤백에 크게 의존한다면 신중하게 테스트해야 합니다.
4. 일부 고급 쿼리와 분석 기능
S3 Inventory, S3 Object Lambda 같은 기능도 R2에서는 지원하지 않습니다.
제 권장 사항은 이전 전에 애플리케이션이 사용하는 S3 기능을 목록으로 정리한 뒤 Cloudflare 공식 문서의 API 호환성 목록과 대조하는 것입니다. 대부분의 애플리케이션은 기본 기능만 사용하므로 문제가 없습니다.

도구 호환성 테스트

자주 쓰는 도구 몇 가지를 테스트해 본 결과, 거의 모두 원활하게 전환할 수 있었습니다.

직접 겪은 함정

제가 이전 중 겪은 문제를 하나 소개하겠습니다. 한 애플리케이션에서 S3의 ListObjectsV2 API를 사용했고 페이지네이션에 StartAfter 매개변수를 적용했습니다. 그런데 R2로 이전한 뒤 페이지네이션 동작이 조금 달라 일부 데이터가 누락되었습니다.
조사 결과 R2의 페이지네이션 동작이 S3와 약간 다르다는 사실을 발견했습니다. ContinuationToken 매개변수를 사용하도록 바꾸자 정상적으로 작동했습니다.
여기서 얻은 교훈은 이전 후 정상 흐름만 확인하지 말고 경계 사례까지 충분히 테스트해야 한다는 것입니다.

3가지 이전 방식 비교: 상황에 맞는 방법 선택하기

Cloudflare는 Super Slurper와 Sippy라는 공식 도구 두 개를 제공하며, 커뮤니티에는 rclone 같은 오픈 소스 대안도 있습니다. 어떤 방법을 선택할지는 상황에 따라 달라집니다.

방식 1: Super Slurper(초보자에게 권장하는 일회성 이전)

Super Slurper는 Cloudflare의 원클릭 공식 이전 도구로, 데이터를 전부 한 번에 옮기고 싶을 때 적합합니다.
분명한 장점:

• 양식 몇 개만 입력하면 이전을 시작할 수 있을 정도로 간단함
• 모든 메타데이터(metadata, content-type 등) 보존
• 원본 데이터를 삭제하지 않아 위험이 없음
• 무료로 사용할 수 있고 저렴한 R2 Class A 작업 비용만 발생
• 2024년 업그레이드 후 속도가 5배 향상
  알아야 할 단점:
• 일회성 이전만 가능하며 증분 동기화는 불가능
• 이전 중 사용자가 S3에 새 파일을 업로드하면 R2로 자동 동기화되지 않음
• 객체 하나가 50GB 미만인 경우에 적합하며 초대형 파일에는 문제가 생길 수 있음
  적합한 대상:
• 데이터가 10TB 미만
• 짧은 중단을 감수할 수 있음(또는 서비스 출시 전)
• 이전 후 S3를 더 이상 사용하지 않고 R2로 완전히 전환
  첫 번째 프로젝트를 이전할 때 Super Slurper를 사용했는데 100GB의 데이터를 약 30분 만에 처리했습니다. 당시 새벽 3시로 유지 보수 시간을 잡았고 사용자는 거의 알아차리지 못했습니다.

방식 2: Sippy(무중단 점진적 이전)

Sippy는 Cloudflare가 제공하는 지능형 이전 방식이며, 가장 큰 특징은 서비스를 중단할 필요가 없다는 것입니다.
작동 원리:
애플리케이션이 R2를 가리키도록 설정하면 사용자가 파일을 요청할 때 다음과 같이 처리됩니다.

1. R2가 먼저 해당 파일이 있는지 확인합니다.
2. 파일이 있으면 즉시 반환합니다.
3. 파일이 없으면 S3에서 가져오는 동시에 R2에 복사하므로 다음 요청부터 R2에서 바로 읽습니다.
   이렇게 요청에 따라 데이터가 이전되므로 자주 쓰는 핫 데이터부터 옮겨지고 콜드 데이터는 천천히 이전됩니다.
   장점:

• 완전한 무중단으로 사용자가 이전을 체감하지 못함
• 핫 데이터가 이전된 뒤 트래픽이 R2를 통하므로 S3 트래픽 비용 절감
• 이전과 관찰을 동시에 진행할 수 있고 마음에 들지 않으면 언제든 S3로 되돌릴 수 있음
  단점:
• 특정 파일에 처음 접근할 때 S3에서 가져와야 하므로 다소 느림
• 애플리케이션 설정을 변경해야 해 구성이 비교적 복잡함
• 핫 데이터와 콜드 데이터가 명확한 접근 패턴에 적합
  CDN 가속 서비스를 운영하는 지인은 Sippy로 50TB의 데이터를 이전했습니다. 사용자에게 서비스를 제공하는 동시에 백그라운드에서 천천히 이전해 전부 옮기는 데 두 달이 걸렸지만 비즈니스에는 전혀 영향이 없었습니다.

방식 3: rclone(기술 전문가를 위한 가장 유연한 선택)

rclone은 오픈 소스 클라우드 스토리지 동기화 도구로 기능이 가장 강력하지만 명령줄을 사용해야 합니다.
장점:

• 완전 무료 오픈 소스
• 중단 지점부터 재개 가능(네트워크가 불안정해도 안전)
• 예약 동기화 가능(예: 매일 새벽 증분 데이터 자동 동기화)
• 데이터 무결성 검증(MD5, SHA256) 지원
• 대역폭을 모두 차지하지 않도록 속도 제한 가능
  단점:
• 명령줄 조작과 학습이 필요함
• 이전 진행 상황을 관리하는 스크립트를 직접 작성해야 함
• 전송 중 S3 송신 트래픽 비용 발생(다행히 AWS는 2024년 3월부터 외부 이전 트래픽을 무료로 제공)
  적합한 대상:
• 기술 역량이 높고 이전 과정을 완전히 제어하고 싶은 경우
• 지속적인 동기화가 필요한 경우(예: 일정 기간 S3와 R2에 이중 쓰기)
• 데이터 무결성이 매우 중요한 경우
  저도 자동화 스크립트를 작성하고 자세한 로그를 확인할 수 있어 rclone을 선호합니다. 이전할 때는 다음 명령을 사용했습니다.

rclone copy s3:my-bucket r2:my-bucket \
  --progress \
  --checksum \
  --transfers 32 \
  --s3-chunk-size 64M

--checksum 매개변수는 각 파일의 MD5를 검증해 데이터 무결성을 보장합니다. --transfers 32는 동시 전송 32개를 열어 속도를 크게 높입니다.

빠른 결정: 어떤 방식을 선택해야 할까

다음 결정 트리를 참고하세요.

서비스를 중단할 수 있는가?
├─ 가능 → 데이터가 10TB 미만인가?
│      ├─ 예 → Super Slurper(가장 간단)
│      └─ 아니요 → rclone(빠르고 제어 가능)
└─ 불가능 → Sippy(무중단)
기술 역량이 높고 완전히 제어하고 싶음 → rclone

제 권장 사항은 대부분의 사용자에게 Super Slurper면 충분하다는 것입니다. 서비스가 단 한순간도 중단되어서는 안 되거나 데이터가 매우 큰 경우(50TB 초과)가 아니라면, Super Slurper의 간편함이 다른 방식의 유연성보다 훨씬 가치 있습니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

실전: Super Slurper로 30분 만에 위험 없이 이전하기

이론은 충분히 살펴봤으니 이제 직접 따라 할 수 있도록 설명하겠습니다. Super Slurper를 예로 들며, 전송 시간을 제외하면 30분 안에 설정을 마칠 수 있습니다.

1단계: 준비 작업(5분)

1. Cloudflare 계정에 가입하고 R2 활성화
Cloudflare 공식 사이트에서 계정을 만든 뒤 사이드바에서 “R2 Object Storage”를 찾아 활성화합니다.
주의: R2를 사용하려면 신용카드를 등록해야 하지만 무료 한도가 있어 소규모 프로젝트라면 비용을 한 푼도 내지 않을 수 있습니다.
2. R2 bucket 생성
“Create bucket”을 클릭하고 다음 항목을 입력합니다.

• Bucket 이름(관리하기 쉽도록 S3와 같은 이름 권장)
• Location hint(규정 준수 요구가 있다면 EU를 선택하고, 그렇지 않으면 Automatic 선택)
  ⚠️ 중요: Location hint와 jurisdictional restrictions(관할 제한)는 한 번 선택하면 변경할 수 없으므로 신중하게 결정하세요. 대부분은 Automatic이면 충분합니다.
  3. AWS에서 읽기 전용 IAM 사용자 생성
  이 단계는 매우 중요합니다. 보안 위험이 크므로 기본 계정 키를 사용하지 마세요.
  AWS IAM 콘솔 → Users → Add User로 이동합니다.
• 사용자 이름: r2-migration-readonly
• Access type: Programmatic access
• Permissions: Attach existing policies directly → “AmazonS3ReadOnlyAccess” 선택
  또는 더 안전하게 특정 bucket에만 권한을 부여하는 사용자 지정 정책을 사용합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

생성이 끝나면 Access Key ID와 Secret Access Key가 제공됩니다. 한 번만 표시되므로 반드시 복사해 안전하게 보관하세요.
4. R2 API Token 생성
Cloudflare R2 페이지 → Manage R2 API Tokens → Create API Token으로 이동합니다.

• Token 이름: migration-token
• Permissions: Object Read & Write
• 앞서 생성한 bucket 선택
  여기에서도 Access Key ID와 Secret Access Key가 제공되므로 저장해 둡니다.

2단계: 이전 실행(설정에 15분)

1. Data Migration 화면으로 이동
R2 콘솔에서 오른쪽 위의 “Data Migration” → “Migrate Files”를 클릭합니다.
2. Super Slurper 선택
Super Slurper와 Sippy라는 두 가지 옵션이 표시됩니다. 일회성 이전을 위한 Super Slurper를 선택합니다.
3. 원본 bucket 정보(S3) 입력

• Provider: Amazon S3
• Bucket name: S3 bucket 이름(예: my-images)
• Bucket region: S3가 위치한 리전(예: us-east-1, S3 콘솔에서 확인 가능)
• Access Key ID: 앞서 생성한 IAM 사용자의 Access Key
• Secret Access Key: 해당 Secret Key
  “Verify Connection”을 클릭하면 연결 성공 시 녹색 체크 표시가 나타납니다.
  4. 대상 bucket 정보(R2) 입력
• Bucket name: R2에서 생성한 bucket 이름
• R2 Access Key ID: R2 API Token의 Access Key
• R2 Secret Access Key: 해당 Secret
  5. 이전 옵션 설정
• Overwrite existing objects: 기존 파일을 덮어쓸지 여부(선택 권장)
• Path prefix(선택 사항): S3의 특정 폴더만 이전하려면 images/ 같은 접두사를 입력
  6. 검토 후 이전 시작
  설정을 꼼꼼히 확인한 다음 “Start Migration”을 클릭합니다.
  7. 전송 완료 대기
  다음과 같은 이전 진행 상황이 표시됩니다.
• 전송 속도
• 이전된 파일 수
• 예상 남은 시간
  예상 시간:
• 100GB → 약 30분
• 1TB → 약 4~6시간
• 10TB → 약 2~3일
  페이지를 닫아도 백그라운드에서 이전이 진행됩니다. 언제든 돌아와 진행 상황을 확인할 수 있습니다.

3단계: 이전 결과 검증(10분)

이전이 끝나도 S3 데이터를 곧바로 삭제하지 말고 먼저 검증하세요.
1. 객체 수 확인
R2 콘솔에서 bucket을 열고 다음 수치를 비교합니다.

• S3 객체 수: X개
• R2 객체 수: X개
  수가 같으면 됩니다. 다르다면 이전 실패 로그를 확인하세요.
  2. 파일 무결성 표본 검사
  파일 몇 개를 무작위로 다운로드한 뒤 MD5를 비교합니다.

# S3 파일의 MD5
aws s3api head-object --bucket my-bucket --key test.jpg --query 'ETag' --output text
# R2 파일의 MD5(rclone을 사용하거나 직접 다운로드해 비교)
rclone md5sum r2:my-bucket/test.jpg

ETag가 같으면 파일이 온전한 것입니다.
3. 파일 접근 테스트
R2 Public URL 또는 API로 파일 몇 개에 접근해 정상적으로 다운로드되는지 확인합니다.
4. 메타데이터 확인
사용자 지정 metadata가 누락되지 않았는지 확인합니다.

aws s3api head-object --bucket my-bucket --key test.jpg
# R2의 metadata와 비교

4단계: 애플리케이션을 R2로 전환

검증에 문제가 없다면 애플리케이션 전환을 시작할 수 있습니다. 한 번에 모두 바꾸기보다 점진적으로 배포하는 것이 좋습니다.
1. 애플리케이션 설정 변경
애플리케이션이 환경 변수로 S3를 설정한다고 가정해 보겠습니다.

# 기존 S3 설정
S3_ENDPOINT=https://s3.amazonaws.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=xxx
S3_SECRET_KEY=xxx
S3_REGION=us-east-1
# R2 설정으로 변경
S3_ENDPOINT=https://YOUR_ACCOUNT_ID.r2.cloudflarestorage.com
S3_BUCKET=my-bucket
S3_ACCESS_KEY=R2_xxx
S3_SECRET_KEY=R2_xxx
S3_REGION=auto  # R2에서는 auto 사용

2. 점진적 테스트
먼저 트래픽 10%로 오류가 없는지 테스트합니다.

• 애플리케이션 로그 확인
• 오류율 모니터링
• 사용자 피드백 관찰
  문제가 없으면 10% → 50% → 100% 순서로 점차 확대합니다.
  3. 핵심 지표 모니터링
  이전 후 다음 항목을 면밀히 관찰합니다.
• API 오류율
• 응답 시간
• 크게 낮아져야 하는 트래픽 비용
  4. S3 백업 유지
  R2가 안정적인지 확인할 수 있도록 S3 데이터를 30일간 유지한 뒤 삭제하는 것이 좋습니다. AWS는 2024년 3월부터 외부로 이전하는 트래픽을 무료로 제공하므로 삭제하는 데 비용이 들지 않습니다.
  자동으로 정리하려면 다음 S3 수명 주기 정책을 설정할 수 있습니다.

{
  "Rules": [
    {
      "Status": "Enabled",
      "Expiration": {
        "Days": 30
      }
    }
  ]
}

30일 뒤 모든 객체가 자동으로 삭제됩니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

이전 후 최적화와 모니터링 권장 사항

이전 완료는 끝이 아니라 최적화의 시작입니다. R2의 성능과 가성비를 최대한 끌어내는 방법을 알아보겠습니다.

성능 최적화: R2를 더 빠르게 만들기

1. Cloudflare CDN 가속 활성화
R2 자체가 Cloudflare의 글로벌 네트워크에 있지만 CDN과 함께 사용하면 효과가 더 좋습니다.

• R2 bucket 설정 → Public Access → Connect Domain으로 이동
• 도메인 연결(도메인이 Cloudflare에서 호스팅되어야 함)
• CDN 캐시 자동 활성화
  이렇게 하면 사용자가 접근할 때 가장 가까운 CDN 노드에서 콘텐츠를 반환해 속도가 매우 빨라집니다.
  2. 적절한 Cache-Control 설정
  파일을 업로드할 때 Cache-Control header를 설정해 CDN에 캐시 기간을 알려 줍니다.

// 정적 리소스(이미지, 동영상)는 1년 동안 캐시
s3.upload({
  Bucket: 'my-bucket',
  Key: 'image.jpg',
  Body: fileBuffer,
  CacheControl: 'public, max-age=31536000, immutable'
});
// 자주 바뀌는 콘텐츠는 1시간 동안 캐시
s3.upload({
  // ...
  CacheControl: 'public, max-age=3600'
});

3. R2 사용자 지정 도메인 사용
기본 R2 URL은 보기 좋지 않습니다. https://xxx.r2.cloudflarestorage.com/file.jpg
사용자 지정 도메인을 설정하면 다음처럼 바뀝니다. https://cdn.yoursite.com/file.jpg
URL이 더 보기 좋아질 뿐 아니라 CDN 성능도 향상됩니다.

비용 최적화: 절약할 수 있는 부분은 절약하기

1. 콜드 데이터에는 Infrequent Access 스토리지 클래스 사용
R2가 새로 출시한 Infrequent Access(IA) 스토리지 클래스는 자주 접근하지 않는 데이터에 적합합니다.

• 스토리지 비용이 더 저렴함($0.01/GB, 표준은 $0.015/GB)
• 접근 시 추가 비용 발생($0.01/GB 읽기 비용)
  과거 아카이브, 백업 데이터, 콜드 데이터에 적합합니다.
  2. Multipart Upload의 part size 최적화
  대용량 파일을 업로드할 때 part size는 Class A 작업 비용에 영향을 줍니다. 각 part 업로드가 Class A 작업 한 번으로 계산되기 때문입니다.
• Part size가 너무 작음 → 작업 수 증가 → 비용 증가
• Part size가 너무 큼 → 실패 시 재전송 비용 증가
  다음과 같이 설정하는 것을 권장합니다.
• 100MB 미만 파일 → 한 번에 업로드
• 100MB~1GB 파일 → part size 64MB
• 1GB 초과 파일 → part size 128MB
  rclone에서는 다음과 같이 설정할 수 있습니다.

rclone copy s3:bucket r2:bucket --s3-chunk-size 64M

3. Class A/B 작업 비용 모니터링
트래픽은 무료지만 작업 비용은 발생합니다.

• Class A(쓰기): 백만 회당 $4.50
• Class B(읽기): 백만 회당 $0.36
  R2 콘솔에서 월별 작업 수를 확인할 수 있습니다. Class A 작업이 특히 많다면 중복 업로드나 무효 요청이 없는지 점검하세요.

모니터링 설정: 문제를 빠르게 발견하기

1. Cloudflare Analytics
R2에 내장된 Analytics에서 다음 항목을 확인할 수 있습니다.

• 요청 수
• 트래픽 크기
• 오류율
• 인기 파일
  R2 bucket → Analytics로 이동해 확인합니다.
  2. 비용 알림
  비용 임계값을 설정해 초과 시 자동 알림을 받습니다.
  Cloudflare Dashboard → Notifications → Add → “R2 storage usage”를 선택합니다.
  예를 들어 월 비용이 $50를 넘으면 이메일로 알리도록 설정하면 예상치 못한 청구액을 방지할 수 있습니다.
  3. 애플리케이션 계층 모니터링
  애플리케이션에서 R2의 핵심 지표를 모니터링합니다.
• API 오류율(목표 0.1% 미만)
• 평균 응답 시간(목표 100ms 미만)
• P99 지연 시간(목표 500ms 미만)
  Sentry, Datadog 같은 APM 도구를 사용하면 문제를 발견했을 때 즉시 롤백할 수 있습니다.
  4. S3 비용과 정기적으로 비교
  매월 다음 항목을 비교합니다.
• 이전 전 S3 청구액
• 이전 후 R2 청구액
• 절약한 금액(팀에 식사를 대접해도 되겠네요 😄)
  저는 Excel 표에 매달 기록하고 있습니다. 절약한 금액이 계속 늘어나는 모습을 보면 큰 성취감을 느낄 수 있습니다.

결론: R2로 이전할 가치가 있는가

제 답은 명확합니다. 애플리케이션 트래픽이 월 500GB를 넘는다면 R2로 이전할 가치가 충분합니다.
이전의 세 가지 핵심 이점을 다시 정리해 보겠습니다.

1. 실제로 비용 절감: 송신 트래픽 비용이 없어 클라우드 청구액을 50~90%까지 바로 줄일 수 있습니다. SaaS 애플리케이션에서 연간 $10,000 이상, 동영상 플랫폼에서 연간 $50,000 이상을 절약하는 것도 드문 일이 아닙니다.
2. 간단한 이전: Super Slurper는 설정에 30분이 걸리고 API 호환성은 80~90%이며, 대부분의 애플리케이션은 endpoint만 바꾸면 작동합니다. 직접 테스트해 보니 생각만큼 복잡하지 않았습니다.
3. 통제 가능한 위험: 이전 과정에서 원본 데이터를 삭제하지 않고 점진적 배포로 천천히 전환할 수 있으며, 문제가 생기면 언제든 롤백할 수 있습니다. 이제 AWS가 이전 트래픽을 무료로 제공하므로 시도에 따르는 비용도 거의 없습니다.
   하지만 R2가 만능은 아닙니다.

• AWS 생태계(Lambda, Athena 등)에 강하게 결합되어 있다면 이전 비용이 큼
• S3의 고급 규정 준수 기능(Object Lock)이 필요하다면 R2는 현재 지원하지 않음
• 트래픽이 매우 적다면(월 100GB 미만) 이전 ROI가 뚜렷하지 않음
  제 권장 사항은 먼저 R2 무료 한도로 성능과 안정성을 테스트하고 문제가 없음을 확인한 뒤 대규모로 이전하는 것입니다. Sippy로 점진적으로 이전하면 위험을 가장 낮출 수 있습니다.
  마지막으로 짧은 사례를 하나 소개하겠습니다. 이미지 호스팅 서비스를 운영하는 지인은 매달 S3에 $1,800을 지불했지만 R2로 이전한 뒤에는 스토리지 비용 $18만 내게 되었습니다. 그는 절약한 돈으로 디자이너를 채용해 제품을 개선했고 사용자 경험도 크게 향상했습니다. 이것이 비용 최적화의 가치입니다. 단지 돈을 아끼는 것이 아니라 더 가치 있는 곳에 돈을 쓰는 것입니다.
  지금 바로 시작하세요.

1. R2 계산기에서 얼마나 절약할 수 있는지 계산하기
2. 무료 한도로 R2 성능 테스트하기
3. 적절한 이전 방식 선택하기(Super Slurper/Sippy/rclone)
4. 점진적으로 이전하며 안정성 검증하기
5. 완전히 전환해 비용 절감 효과 누리기
   이전 중 문제가 생기면 댓글로 함께 이야기해 주세요. 성공적으로 이전하고 청구액도 크게 줄이시길 바랍니다!