CloudFront를 걷어내고 Cloudflare로. Worker + R2 CDN 전환 삽질기

안녕하세요. 노머스에서 백엔드 개발을 하고 있는 지승보입니다.

얼마 전 찬희님이 CloudFront + Lambda@Edge to Cloudflare Worker + R2 PoC 글에서 “AWS 미디어 스택을 Cloudflare로 옮길 수 있는가”라는 질문에 답을 내려주셨습니다. 결론은 이미지·일반 VOD는 옮길 만하고, 4K·AES-128은 MediaConvert를 유지하는 하이브리드였습니다.

이 글은 그 PoC의 후속편입니다. “옮길 수 있다”와 “이미 트래픽이 흐르고 있는 운영 서비스를 안 끊고 옮긴다”는 다른 이야기였고, 그 사이에서 제가 밟은 삽질들을 정리했습니다.

TL;DR

• 가능한가? 안 끊기고 어떻게?: 파일 URL은 RDS·Firestore 여기저기에 저장돼 있습니다. 신규 파일만 R2용 별도 도메인으로 빼두면, 나중에 완전히 R2로 넘어갈 때 이미 저장된 URL을 전부 찾아 바꿔야 합니다. 그래서 URL은 손대지 않고, S3 → R2 동기화를 먼저 돌린 뒤 DNS만 Cloudflare로 바꿔 뒤에서 오리진만 갈아끼우는 쪽으로 갔습니다.
• Cloudflare 캐시는 CloudFront처럼 동작하지 않는다: 비용을 잡으려면 캐시로 R2 접근을 줄여야 하는데, CloudFront에서 알던 캐시 상식이 Cloudflare엔 그대로 통하지 않았습니다. 문서와 실제 동작을 직접 찍어보며 캐시 구조를 다시 익혔습니다.
• egress 0원이 전부가 아니다: R2는 데이터 전송(egress)은 공짜지만, 파일을 읽는 접근(Class B operation) 자체에는 과금됩니다. Worker 캐시로 R2 도달 횟수를 줄이지 못하면 egress를 0원으로 만들어놓고도 전환 이득이 사라집니다.
• private vs public 딜레마: 사용자별 권한이 다른 콘텐츠라 클라이언트에는 Cache-Control: private으로 응답해야 합니다. CloudFront는 오리진이 private을 줘도 알아서 캐싱해줬기에 Cloudflare도 그러려니 했는데, Worker 캐시(caches.default)는 private 응답을 조용히 저장 거부했습니다. 결국 저장할 땐 public, 응답할 땐 다시 private으로 되돌리는 방법으로 풀었습니다.

---

목차

1. PoC와 실전 사이의 간극
2. 마이그레이션 전략
3. 삽질 1 — Cloudflare 캐시는 CloudFront처럼 동작하지 않았다
4. 삽질 2 — egress 0원의 함정, R2도 접근하면 돈이다
5. 삽질 3 — private으로 응답해야 하는데 캐시는 public만 저장한다
6. Worker 하나에 눌러 담은 자잘한 처리들
7. CloudFront 포맷 그대로 검증하기
8. 마치며

---

PoC와 실전 사이의 간극

찬희님 PoC에서 다음과 같은 것들을 미리 알 수 있었습니다.

• R2는 S3 SDK를 그대로 쓸 수 있다.
• Worker는 Lambda@Edge가 하던 일(쿠키 발급, Cache-Control 부여)을 대체할 수 있다.
• egress 0원 덕분에 비용 임팩트가 크다.

“옮길 수 있는가”에 대한 답은 이걸로 나온 셈입니다. 제 몫은 이 결론을 이미 사용자 트래픽이 흐르고 있는 운영 미디어 스택에 실제로 태우는 일이었습니다. 개념을 검증하는 것과, 그 개념을 트래픽 끊김 없이 운영에 태우는 것은 결이 다른 문제라, 실제로 옮기는 과정에서 이런 것들을 하나씩 마주했습니다.

• 어떤 순서로 배포해야 다운타임 없이 넘어가는가 — 배포 전략
• 이미 쌓여 있는 기존 파일 전체를 어떻게 R2로 옮기는가
• RDS·Firestore 여기저기에 저장된 URL은 어떻게 처리하는가
• “캐시가 진짜로 먹긴 하나?” 처럼, 실제 트래픽에서만 확인되는 가정들

이 글의 대부분은 이렇게 딸려 온 것들과의 씨름입니다.

마이그레이션 전략

가장 먼저 세운 계획은 단순했습니다.

“앞으로 업로드되는 파일은 R2로 올리고, 주소는 R2용 별도 도메인으로 저장하자. 기존 파일은 나중에 옮기면 되지.”

그런데 이게 은근한 부채가 됐습니다. 신규 파일만 별도 도메인으로 저장해두면, 나중에 기존 파일까지 R2로 마이그레이션할 때 한 서비스 안에 두 개의 미디어 도메인이 섞이게 됩니다. 게다가 인프라 계획상 최종적으로는 R2가 기존 도메인을 그대로 넘겨받아 서빙하게 될 수 있었습니다. 그렇게 되면 애써 나눠둔 별도 도메인 URL들을 다시 전부 되돌려야 합니다.

문제는 그 URL들이 한 곳에 있지도 않다는 점이었습니다. RDS에도, Firestore에도 흩어져 있고, 콘텐츠 종류마다 저장 위치와 포맷이 달랐습니다. 이걸 전부 찾아 원자적으로 바꾸는 건 그 자체로 또 하나의 위험한 대형 마이그레이션이었습니다.

그래서 방향을 뒤집었습니다. “URL은 처음부터 건드리지 않는다.” 신규 파일도 별도 도메인으로 나누지 않고, 기존 도메인을 그대로 쓰되 뒤에서 오리진만 바꾸는 쪽으로요.

1. 기존 파일을 통째로 R2로 옮긴다. 이미 S3에 쌓여 있는 파일은 Cloudflare가 제공하는 마이그레이션 도구인 Super Slurper로 R2에 복사했습니다. 우리 쪽 파일은 대부분 10MB 미만(주로 이미지)이라 파일당 2~3초면 복사가 끝났고, 이 동안 서비스 트래픽은 여전히 100% CloudFront → S3로 흐릅니다.
2. R2 → S3 역방향 sync를 먼저 깔고, 그다음 업로드 대상을 S3에서 R2로 바꾼다. 순서가 중요했습니다. 업로드를 R2로 돌리는 순간에도 DNS는 아직 CloudFront(=S3 오리진)를 보고 있으니, R2에 올라온 파일이 S3에도 있어야 화면에 뜹니다. 그래서 R2에 파일이 생기면 곧바로 S3로 되돌려 복제하는 sync를 먼저 배포해뒀습니다. 이 sync는 이미 S3에 같은 파일이 있으면 아무것도 하지 않도록 해서, 앞서 Super Slurper로 옮겨둔 파일과 부딪히지 않게 했습니다. R2 → S3 복제는 대략 6초쯤 걸렸습니다.
3. 이 짧은 창 안에서 DNS를 CloudFront에서 Cloudflare로 넘긴다. 전환 창 동안에는 유저가 이미지를 올린 뒤 그게 보이기까지 6초 정도 지연이 생길 수 있었습니다. 장애는 아니고, 새로고침이나 앱 내 재시도로 흡수되는 수준이었습니다. 마침 DNS 레코드의 TTL이 60초라, 오리진을 넘긴 뒤 전 세계 리졸버가 새 주소를 물어가는 데 길어야 1분이면 충분했습니다.
4. DNS가 넘어가면 Worker + R2가 직접 서빙한다. 도메인은 그대로라 클라이언트가 보는 URL은 하나도 바뀌지 않고, 뒤에서 오리진만 갈아끼워진 셈입니다.

이 R2 → S3 백업 경로는 롤백 시 S3가 원본을 그대로 갖고 있도록 하기 위한 용도입니다. R2로 넘어간 뒤 문제가 생겨도 DNS만 되돌리면 됩니다. 전체 구조를 그림으로 보면 이렇습니다.

읽기 경로는 Client → Worker → caches.default → R2. 백업 경로는 R2에 파일이 생기면 R2 ObjectCreated → Cloudflare Queue → consumer Worker → AWS SQS → Lambda → S3로 되돌려 복제합니다. 실제 consumer Worker는 이렇게 생겼습니다.

// R2 ObjectCreated → SQS SendMessage (S3 백업 큐)
export default {
    async queue(batch: MessageBatch<R2EventNotification>, env: Env): Promise<void> {
        for (const message of batch.messages) {
            try {
                await processMessage(message, env);
            } catch (error) {
                message.retry();
            }
        }
    }
};

// MediaConvert 결과물처럼 이미 S3에 존재하는 prefix는 되돌릴 필요가 없어 제외
const EXCLUDED_PREFIXES: Record<string, string[]> = {
    'fromm-channel-contents': ['fromm_channel/', 'live/']
    // ...
};

코드에서 특정 prefix를 제외하는 건 MediaConvert 때문입니다. 찬희님 PoC의 결론대로, 인코딩(MediaConvert)은 옮기지 않고 AWS 것을 그대로 쓰기로 했습니다. Cloudflare Stream이 4K·AES-128 같은 옵션을 대부분 지원하지 못하기 때문입니다. 그래서 업로드는 R2로 바꿨어도, MediaConvert만은 예외로 결과물을 여전히 S3로 출력하고 그걸 R2로 sync하는 방향을 택했습니다. 즉 MediaConvert 결과물은 처음부터 S3에 원본이 있으니, R2 → S3 백업 대상에서 빼도 됩니다. 위 EXCLUDED_PREFIXES가 그 예외를 걸러내는 부분입니다.

@pulumi/cloudflare가 아직 R2 Event Notification 리소스를 지원하지 않아, 이벤트 알림 → 큐 연결만 대시보드에서 수동으로 걸어줘야 했던 건 덤이었습니다. IaC로 다 감싸고 싶었지만, 지원되지 않는 부분은 인정하고 README에 “여기는 손으로 설정해야 함”을 명시해두는 편을 택했습니다.

삽질 1 — Cloudflare 캐시는 CloudFront처럼 동작하지 않았다

이번 마이그레이션의 가장 큰 목표는 비용 절감이었습니다. Cloudflare의 egress가 무료라는 점을 최대한 살리는 게 목표였습니다. 그런데 egress가 공짜여도 R2는 파일에 접근할 때마다 operation 비용이 붙습니다. 실질적인 비용은 결국 여기서 난다고 봤고(자세한 숫자는 다음 장에서 다룹니다), 그래서 캐시로 R2 접근 횟수를 최대한 줄이는 게 이 전환의 핵심 과제였습니다.

문제는 “CloudFront가 해주던 서빙과 캐싱을 Worker + R2에서 어떻게 똑같이 재현하지?”였는데, 여기서부터 예상이 어긋났습니다. 캐시 구조를 조사하던 중 AI가 “응답에 Cache-Control: public을 주면 Cloudflare CDN이 캐싱해서 그다음부터는 Worker까지 요청이 오지 않는다”고 알려줬습니다. 그럴듯해서 그대로 붙여봤는데, Worker는 매 요청 계속 호출됐습니다. 다시 확인해보니 그런 동작은 없었고, 이걸 붙잡고 잠깐 헤맸습니다. 문서와 실제 동작은 직접 찍어보며 가야겠다고 마음먹은 계기이기도 했습니다.

직접 확인해보니 Cloudflare의 caches.default는 CloudFront처럼 “Worker 앞단에서 알아서 걸러주는 자동 CDN 캐시”가 아니었습니다. 이건 Worker 코드 안에서 내가 직접 cache.match()로 조회하고 cache.put()으로 저장하는 수동 캐시입니다. 캐시 내용이 전 세계 엣지로 자동 복제되지도 않습니다.

그러니까 실제 모델은 이렇습니다.

Client → Worker(실행됨) → caches.default(match/put) → R2

Worker는 어차피 매 요청 실행됩니다. 대신 그 안에서 캐시를 잘 활용하면 R2 접근을 줄이는 구조입니다. “Worker를 안 거치게 만든다”가 아니라 “Worker는 거치되 R2는 안 건드리게 만든다”가 목표였던 겁니다. 이 지점에서 접근 방식이 완전히 바뀌었습니다.

삽질 2 — egress 0원의 함정, R2도 접근하면 돈이다

R2를 선택한 이유는 “egress 비용이 없다” 입니다. CloudFront 청구서의 90% 이상이 데이터 전송 비용이었으니, 여기가 0원이 되는 건 큰 임팩트였습니다.

그런데 저는 그 문장에 취해서 “R2 접근 자체도 돈이 든다” 는 걸 한동안 잊고 있었습니다.

R2는 egress는 공짜지만, 오퍼레이션에는 과금합니다. GetObject, HeadObject 같은 읽기는 Class B operation으로 분류되고, 2026년 4월 기준 백만 요청당 $0.36입니다. 여기서 짚어둘 게, 이 단가는 S3와 거의 같습니다. S3 Standard의 GET 요청도 백만 건당 $0.40 수준이라, 스토리지를 R2로 옮긴다고 요청 단가 자체가 싸지는 건 아니에요. R2가 이기는 지점은 어디까지나 egress 한 곳뿐입니다.

미디어 트래픽에 대입해보면 감이 옵니다. (아래 숫자는 이해를 돕기 위한 예시이며, 실제 서비스 트래픽 기준은 아닙니다.)

• 하루 1,000만 건 읽기 × 30일 = 3억 건
• (3억 - 무료 1,000만 건) / 100만 × $0.36 = $104.40 / 월

이건 “캐시가 하나도 안 먹었을 때”의 숫자입니다. egress를 0원으로 만들어놓고도 캐시로 R2 도달을 막지 못하면, S3에서 내던 것과 별로 다르지 않은 operation 비용이 그대로 새어 나갑니다. 그러면 굳이 마이그레이션을 감행할 이유가 없을 만큼 비용 개선폭이 작아집니다. 전환의 진짜 이득은 “egress 0원”이 아니라 “R2 접근을 캐시로 얼마나 틀어막느냐” 에 달려 있었던 겁니다.

이 깨달음이 이후 모든 설계의 기준이 됐습니다. 모든 요청은 R2에 도달하지 않는 걸 기본값으로 삼는다. HEAD 요청 하나까지도요.

삽질 3 — private으로 응답해야 하는데 캐시는 public만 저장한다

여기가 이번 전환에서 가장 오래 붙잡고 있었던 지점입니다. 두 요구사항이 정면으로 충돌했습니다.

요구사항 A. 클라이언트에는 private으로 응답해야 한다. 저희 미디어는 사용자별 권한이 다른 콘텐츠입니다. 만약 Cache-Control: public으로 내려보내면, 중간의 다운스트림 프록시나 Next.js 서버 같은 공유 캐시가 A 사용자의 응답을 B 사용자에게 재사용해버릴 위험이 있습니다. 그래서 클라이언트 계약은 무조건 private이어야 했습니다.

요구사항 B. 캐시에 저장하려면 public이어야 한다. 문제는 여기서 드러났습니다. 요구사항 A를 지키려고 private으로 응답하게 했더니, 시간이 지나도 캐시가 계속 MISS로만 잡혔습니다. 알고 보니 caches.default는 Cache-Control: private 응답을 cache.put() 해도 에러도 로그도 없이 조용히 저장을 건너뛰었습니다. 이 사실을 모른 채 한참을 붙들고 있었습니다.

캐시가 MISS로만 잡힌다는 걸 눈으로 확인할 수 있었던 건, Worker에서 응답을 캐시로 내줄 땐 X-Cache: HIT, R2까지 다녀왔을 땐 X-Cache: MISS를 커스텀 헤더로 붙여둔 덕분입니다. curl -I로 찍어보면 아무리 다시 요청해도 HIT이 뜨질 않았습니다.

정리하면 이렇습니다.

• private으로 응답해야 → 보안 계약 지킴 → 하지만 캐시 저장 실패
• public으로 응답하면 → 캐시 저장 성공 → 하지만 보안 계약 깨짐

한동안 답이 없어 보였습니다. 팀원과 화이트보드 앞에서 한참 이야기하다, 반쯤 농담처럼 나온 아이디어가 결국 채택됐습니다.

“그럼… 저장할 때는 public으로 속여서 넣고, 꺼내서 응답할 때 다시 private으로 되돌리면 되는 거 아냐?”

처음엔 이걸 제대로 된 방법이라고 생각하진 않았습니다. 그런데 이것 말고는 두 요구사항을 동시에 만족시킬 길이 없었습니다. 핵심은 원본 Cache-Control을 별도 헤더에 백업해두고, 캐시에는 public으로 저장한 뒤, HIT되어 꺼낼 때 백업해둔 값으로 복원하는 겁니다.

// 저장용: 원본 CC를 X-Original-Cache-Control 에 보존하고, 저장본은 public 으로 우회
function buildCacheEntry(response: Response, isSigned: boolean): Response {
    const cloned = response.clone();
    const toCache = new Response(cloned.body, {
        status: cloned.status,
        headers: new Headers(cloned.headers)
    });

    if (isSigned) {
        toCache.headers.set('X-Original-Cache-Control', toCache.headers.get('Cache-Control') ?? '');
        toCache.headers.set('Cache-Control', 'public, max-age=86400');
    }
    return toCache;
}

// 응답용: HIT 시 원본 CC 를 그대로 복원 → 클라이언트는 여전히 private 을 수신
function restoreFromCacheEntry(cached: Response): Response {
    const response = new Response(cached.body, {
        status: cached.status,
        headers: new Headers(cached.headers)
    });

    if (response.headers.has('X-Original-Cache-Control')) {
        response.headers.set('Cache-Control', response.headers.get('X-Original-Cache-Control') ?? '');
        response.headers.delete('X-Original-Cache-Control');
    }
    return response;
}

이렇게 하니 계층마다 보는 값이 정확히 갈립니다.

계층	보이는 Cache-Control	의도
클라이언트/브라우저	private, max-age=86400	브라우저 로컬 캐시는 허용, 공유 캐시 재사용은 차단
중간 프록시/CDN	private	사용자 간 응답 재사용 방지
Worker Cache API	public, max-age=86400	cache.put() 저장 활성화
Worker 인증	매 요청 수행	signed cookie/query 검증 보장

caches.default라는 내부 저장소에만 잠깐 public이라는 가면을 씌우고, 밖으로 나가는 순간 다시 private 얼굴로 돌려놓는 셈입니다. private 경로(signed)는 Edge 자동 캐시를 타지 않으니 Worker가 매 요청 실행되어 인증은 항상 보장되고, 그러면서도 Worker Cache로 R2 접근은 줄어듭니다.

Worker 하나에 눌러 담은 자잘한 처리들

캐시 딜레마를 풀고 나서도, “CloudFront가 아무 말 없이 해주던 것들”을 하나하나 손으로 되살려야 했습니다. 삽질 2에서 정한 기준 — 기본값은 R2에 도달하지 않는 것 — 을 지키기 위한 디테일들입니다.

Signed URL 캐시 키 정규화. Signed URL은 사용자마다 ?Policy=...&Signature=... query가 다릅니다. 이걸 그대로 캐시 키로 쓰면 같은 파일인데도 사용자마다 캐시가 따로 잡혀서 히트율이 바닥을 칩니다. 캐시 키에서는 query를 버리고 pathname만 쓴 이유입니다.

// signed URL 의 토큰 query 제거 → 동일 파일이 같은 캐시 엔트리를 공유
function signedRequestToCacheKey(request: Request): Request {
    const url = new URL(request.url);
    return new Request(`${url.origin}${url.pathname}`);
}

HEAD 요청도 GET 캐시로 때운다. HEAD 요청 역시 R2 입장에선 Class B operation, 곧 돈입니다. 그런데 HEAD가 필요로 하는 건 ETag·Last-Modified·Content-Type·Content-Length 같은 메타데이터뿐이고, 이건 이미 저장해둔 GET 캐시 안에 다 있습니다. HEAD가 오면 GET 캐시를 헤더 소스로 재사용해 R2까지 안 갑니다 (Cache API는 GET만 매칭하므로 조회 시 키도 GET으로 만들어 넘깁니다).

조건부 요청 304를 Worker에서 끝낸다. If-None-Match / If-Modified-Since가 붙은 요청이 오면, 캐시된 응답의 ETag·Last-Modified만으로 Worker가 직접 304를 만들어 돌려줍니다. 변경이 없다는 걸 확인하려고 R2까지 다녀올 필요가 없습니다.

Range 요청은 정직하게 우회한다. 동영상 seek처럼 Range(206 Partial Content) 요청은 Cache API가 206을 저장하지 못합니다. 이건 억지로 캐싱하려 하지 않고 R2로 직접 서빙하되, 응답에 X-Cache: BYPASS를 박아 “얘는 의도적으로 캐시를 우회했다”를 명시했습니다.

그래서 디버깅용으로 모든 응답에 X-Cache 헤더를 남겼습니다.

• HIT — Worker Cache에서 찾음 (R2 안 감)
• MISS — R2에서 읽어옴 (그리고 캐시에 저장)
• BYPASS — Range 등으로 의도적 우회

운영에서 캐시가 도는지 아닌지를 curl -I로 한 번에 확인할 수 있어서, 이 헤더 하나가 두고두고 밥값을 했습니다.

CORS 오염 방지. CORS 응답은 요청 Origin에 따라 Access-Control-Allow-Origin 값이 달라집니다. 이걸 캐시가 무심코 재사용하면 A 도메인용 ACAO가 B 도메인에 응답되어 CORS 에러가 터집니다. 그래서 Vary: Origin을 붙여 “이 응답은 Origin마다 다를 수 있다”를 명시했습니다.

CloudFront 포맷 그대로 검증하기

찬희님 PoC에서는 접근 제어를 “Worker에서 JWT 같은 걸 새로 설계할 수 있다”는 가능성으로 열어뒀습니다. 자유도는 높지만, 실전에서 그 길로 가면 클라이언트(앱/웹)를 전부 새 토큰 방식으로 재배포해야 합니다. 이미 많은 앱들이 CloudFront Signed Cookie/URL을 쓰고 있는 상황에서, 그건 전환의 리스크를 키우는 선택이었습니다.

그래서 정반대로 갔습니다. 클라이언트는 아무것도 바꾸지 않는다. 클라이언트가 지금 보내는 CloudFront Signed Cookie/URL을, Worker가 CloudFront인 척 그대로 검증하게 만들었습니다.

문제는 CloudFront의 서명이 표준 JWT가 아니라는 점이었습니다. 서명 알고리즘도, base64 인코딩 방식도 CloudFront 고유 규격이라 표준 라이브러리로는 검증이 되지 않았습니다. 이 부분은 AI의 도움을 받아 CloudFront 포맷을 그대로 검증하는 인증 로직을 설계하고 구현했습니다. 덕분에 웹에서 오는 Signed Cookie도, 안드로이드 외부 플레이어처럼 쿠키 전달이 까다로운 환경에서 오는 Signed URL도 Worker가 그대로 받아 검증할 수 있게 됐습니다.

마치며

이번 전환에서 몸으로 배운 건 몇 가지였습니다. egress가 0원이라는 것만 보고 들어갔지만, 실제로는 R2 접근을 캐시로 얼마나 줄이느냐가 관건이었습니다. CloudFront에서 되던 게 Cloudflare에서 그대로 되지 않아, 문서보다 직접 찍어본 값을 믿어야 했던 것도 컸고요.

buildCacheEntry / restoreFromCacheEntry 같은 코드는 처음 보면 “왜 Cache-Control을 두 번 바꾸지?” 싶습니다. 이건 실수로 생긴 게 아니라, caches.default가 private을 거부한다는 제약과 클라이언트에 private을 보장해야 한다는 요구가 만나는 지점에 일부러 그어둔 경계입니다. 그래서 주석을 유난히 길게 달아뒀습니다. 다음 사람이 “이거 왜 이렇게 짰지?” 할 때 코드가 스스로 대답할 수 있도록요.

찬희님 PoC가 “옮길 수 있다”의 지도를 그려줬다면, 이 글은 그 지도를 들고 실제로 걸어보며 만난 웅덩이들의 기록입니다. 4K·AES-128을 MediaConvert에 남긴 하이브리드 결론은 그대로 유지되고 있고, 이미지·일반 VOD 라인은 이제 Cloudflare 위에서 돌아가고 있습니다.

긴 글 읽어주셔서 감사합니다.