CloudFront + AWS Lambda@Edge 이미지 리사이징: 성능·비용·운영까지 완전 정리

Q1. On-the-fly 이미지 리사이징이 왜 필요한가요?
원본 이미지는 용량이 크고 규격이 제각각이라 그대로 제공하면 로딩 속도 저하, 트래픽 비용 증가, UI 품질 저하가 발생합니다. On-the-fly 리사이징은 요청 시점에 이미지를 가공하여 전달하므로 디바이스에 맞춰 최적화가 간편합니다.

Q2. Lambda@Edge로 이미지 리사이징을 하면 비용이 더 들지 않나요?
대부분 그렇지 않습니다. Cache Miss 5% 기준으로 MAU 1만 서비스는 월 CDN 트래픽 비용을 약 $90 절감하는 반면, Lambda 실행 비용은 약 $5 수준입니다. 캐시가 안정적으로 유지되면 전체 비용은 오히려 줄어드는 구조입니다.

Q3. Lambda@Edge를 사용할 때 주의해야 할 점은 무엇인가요?

1MB 응답 제한, 30초 실행시간, 글로벌 배포·로그 분산 등 운영 난이도를 고려해야 합니다.

Q4. 소규모 서비스도 On-the-fly 방식으로 비용 절감이 가능한가요?

가능합니다. MAU 1천~10만 규모에서도 WebP/AVIF 적용과 캐싱으로 30~50% 트래픽 절감을 기대할 수 있습니다.

Q5. Lambda@Edge 대신 Managed CDN을 선택하는 이유는 무엇인가요?

운영 부담 없이 리사이징·포맷 변경·모니터링을 즉시 적용할 수 있어 개발·운영 리소스를 크게 절약할 수 있습니다. 추가로 AI 쿼리, 사용량 대시보드 등 다양한 사용 및 관리이점이 존재합니다.

On-the-fly 이미지 리사이징이란?

On-the-fly 이미지 리사이징은 이미지가 요청되는 그 순간, 필요한 크기(예: 200×200)나 포맷(WebP, AVIF 등)으로 변환해 전달하는 방식입니다.
미리 여러 규격의 파일을 만들어 둘 필요가 없기 때문에:

• 스토리지 비용 절감

• 운영 구조 단순화

• 새로운 디바이스·규격 대응이 쉬움

같은 장점이 있습니다.

왜 중요해졌을까?

넷플릭스 서비스는 TV, 스마트폰, 태블릿 등 다양한 디바이스에서 시청하는데, 같은 서비스를 서로 다른 디바이스에서 보여주기에 다양한 이미지 규격이 필요합니다.

옛날에는 보통 두 가지 방식으로 대응했습니다.

• 1) 큰 이미지를 불러와 클라이언트에서 줄이는 방법

• 2) 각기 다른 규격의 이미지를 저장해 놓는 방법

1) 큰 이미지를 내려주고 클라이언트에서 줄이는 방식

• 항상 큰 원본을 다운로드해야 해서
  → 로딩 속도가 느려지고
  → 트래픽을 불필요하게 많이 씁니다.

• 화면 크기에 맞게 줄이기 위해 브라우저·앱에서 연산을 더 수행해야 해서
  → 저사양 기기·저속 네트워크 환경에서 체감 성능이 떨어집니다.

결론적으로, 속도·비용·경험 측면에서 비효율적인 방식입니다.

2) 여러 규격의 이미지를 미리 생성해 저장하는 방식

• 원본 + 다양한 사이즈를 모두 보관해야 해서
  → 스토리지 비용이 2배 이상으로 불어날 수 있습니다.

• 새로운 레이아웃이나 해상도가 필요해지면
  → 기존 이미지를 다시 생성하는 배치 작업이 필요합니다.

• 운영 기간이 길어질수록
  → “어디에 어떤 규격이 필요한지” 관리가 점점 더 복잡해집니다.

결론적으로, 규격·디바이스가 계속 늘어나는 현대 서비스에는 잘 안 맞는 구조입니다.

이 문제를 해결하기 위해 클라우드 환경에 맞는 새로운 Best Practice가 등장했습니다.

Lambda@Edge 리사이징 아키텍처 구성

바로 요청 시점에 필요한 이미지 규격을 생성하고 캐싱하는 On-the-fly 방식 입니다. 저장 공간과 트래픽, 운영 부담을 동시에 줄여 주기 때문에, 오늘날 클라우드 환경에서는 사실상 표준 이미지 처리 방식으로 자리잡은 방법입니다.

이를 기존 방법과 대조해 보면 다음과 같습니다.

• 기존 방식:
  → 여러 크기의 파일을 미리 만들어 S3에 저장해두고 요청이 올 때마다 그 파일을 그대로 반환

• On-the-fly 방식:
  → 원본 이미지만 저장해두고
  → ?s=200x200&q=80 같은 파라미터 기준으로
  → 요청 시점에 필요한 규격만 생성하고, 그 결과를 CDN에 캐싱

이 구조 덕분에:

• 스토리지는 원본 위주로 관리하고

• 트래픽은 최적화된 결과만 전달합니다.

호출마다 컴퓨팅(람다)을 사용하니 서버 비용이 더 드는 것 아닐까요?

그렇지 않습니다, 그 이유는 CDN 캐시 구조에 있는데요,

이미지 요청에는 크게 두 가지가 있습니다.

• Viewer Request: 사용자가 CDN에 보내는 요청

• Origin Request: CDN에 캐시가 없어서, S3나 Lambda 쪽으로 다시 보내는 요청

캐시 관점에서 보면:

• Cache Hit: CDN에 결과가 있어서 Lambda를 아예 타지 않음

• Cache Miss: 처음 한 번만 Lambda가 실행되어 원본을 가공하고, 그 결과를 CDN에 저장

즉:

• 첫 요청: Lambda 실행 + S3/스토리지 접근 + 결과 캐싱

• 그 이후 동일한 URL: CDN에서 바로 응답 (Lambda 비용 없음)

그래서 Miss 비율만 잘 관리하면 Lambda 비용은 전체 비용에서 매우 작은 비중을 차지하고,

대부분의 비용 절감은 “더 가벼운 이미지 + 더 적은 대역폭”에서 나옵니다.

참고 -> CDN 이란?

실제 사례: 당근마켓의 On-the-fly 도입

당근마켓은 한국의 대표적인 중고거래 플랫폼으로, 사용자가 직접 사진을 올리는 UGC(User Generated Content) 구조입니다.

한 번 데이터를 살펴봤습니다:

• 하루 이미지 업로드: 50만 건

• 하루 이미지 요청: 2억 건

• 하루 이미지 트래픽: 16,000 GB

이 정도 규모에서 원본 이미지를 그대로 전달하면:

• 서버·CDN 비용이 크게 증가하고

• 로딩 속도가 느려져 사용자 경험이 나빠집니다.

그래서 당근마켓은 필요할 때만 변환하고, 결과를 바로 캐싱하는 On-the-fly 방식을 Lambda@Edge 기반으로 도입했고,
결과적으로:

• 트래픽 약 20% 절감

• 중복 저장 이미지 제거로 월 수천 달러 수준의 비용 절감

이라는 효과를 얻었습니다.

이 사례는 “대규모 UGC 서비스에서 On-the-fly가 어떻게 비용과 성능을 동시에 잡는지”를 잘 보여줍니다.

소규모 서비스에서는 어떤 의미가 있을까?

On-the-fly는 대형 플랫폼만의 이야기가 아닙니다. 예를 들어, 이미지 사용량이 많은 UGC 기반 서비스를 가정해보면:

• 사용자 1명당 월 수천 회 이미지 요청

• 1명당 수백 MB 이미지 트래픽

정도를 추산할 수 있는데요,

이 기준을 MAU 1천~10만 수준에 적용하면:

• WebP/AVIF + 리사이징 + 캐싱만으로도 30~50% 트래픽 절감은 충분히 노려볼 수 있고,

• Miss 비율을 낮게 유지하면 Lambda 비용은 전체 비용에서 아주 작은 비중을 차지합니다.

즉, 소규모라도 이미지 비중이 크면 On-the-fly는 꽤 매력적인 선택지가 됩니다.

Lambda@Edge vs Managed CDN

On-the-fly 이미지를 구현하는 방법은 크게 두 가지입니다.

1. 직접 구축: CloudFront + Lambda@Edge
2. Managed CDN 사용: Cloudinary, Fastly, Weekerp 등

1) Lambda@Edge 직접 구축

장점:

• CloudFront 캐시와 가장 긴밀하게 붙어 동작

• 잘 설계하면 지연 최소화 + 글로벌 스케일 + 비용 효율

단점:

• 전 세계 POP에 배포되는 코드 버전 관리

• 캐싱 정책·URL 설계·리사이징 규칙 설정

• 로그 수집, 모니터링, 장애 대응 등 운영 복잡도가 꽤 높음

• Lambda의 응답 크기·실행 시간 제약 등 고려할 포인트가 많음

2) Managed CDN 사용

장점:

• 리사이징, 포맷 변경, 썸네일, 크롭 등 기능을
  → URL 파라미터만으로 바로 사용 가능

• 캐시·인프라·장애 대응·버전 배포 등을 위임
  → 개발팀은 비즈니스 로직에 집중

• 대시보드, 로그, 통계 등 운영 도구가 기본 제공

단점:

• 서비스마다 요금 체계가 다르므로
  대역폭·요청 수·이미지 수 기준으로 가격 비교가 필요

• 커스텀한 특수 로직은 제한될 수 있음

선택 기준은 단순합니다.

• 인프라를 직접 다루는 게 익숙하고, 규모가 크며, 운영 리소스가 충분한 팀
  → Lambda@Edge 직접 구축도 좋은 선택

• 프론트/백엔드에 집중하고 싶고, 이미지 인프라는 맡기고 싶은 팀
  → Managed CDN이 훨씬 편하고 안전한 선택

위커프 이미지(Weekerp Image)의 포지션

Weekerp Image는 "지금 쓰고 있는 스토리지는 그대로, 운영은 더 간단하게"를 목표로 만든 Managed CDN입니다.

핵심 특징을 정리하면 다음과 같습니다.

• 1MB 응답 제한 없음
  → 큰 이미지도 제약 없이 처리 가능

• 실행 시간 제한에서 자유로움
  → 고해상도·고품질 변환 작업도 안정적으로 수행

• 캐싱율·대역폭·국가별 요청량 대시보드 제공
  → 실제 트래픽 흐름을 보면서 캐시 전략을 조정 가능

• 자연어 기반 변환 파라미터 (예: dog.jpg?ai="200px로 줄여줘" )
  → 개발자가 아니어도 쉽게 변환 규칙을 시도해볼 수 있는 인터페이스

• S3, GCP, Azure 같은 기존 스토리지 그대로 연결
  → 마이그레이션 없이 지금 구조 그대로 연결해 사용

즉, 위커프 이미지는 Lambda@Edge가 가진 구조적 장점은 유지하면서,
“직접 운영할 때 생기는 피로감”을 없애는 쪽에 포지셔닝된 Managed CDN입니다.

결론: 어떤 팀에게 어떤 방식이 맞을까?

On-the-fly 이미지 리사이징은 이제 선택이 아니라,
디바이스 다양성과 사용자 기대 수준이 높아진 시대의 기본 전략에 가깝습니다.

정리하면:

• 이미지 트래픽이 많고, 다양한 디바이스·화면 규격을 지원해야 하는 서비스라면
  → On-the-fly는 거의 필수에 가깝다.

• 인프라 운영 경험이 충분하고, 장기적으로 세밀한 컨트롤이 필요한 팀이라면
  → CloudFront + Lambda@Edge 직접 구축도 좋은 선택.

• 개발 리소스를 아끼고, 빠르게 적용하고, 운영 부담을 줄이고 싶다면
  → Managed CDN이 현실적인 선택.

• 특히 UGC 서비스, 이미지 위주의 SaaS, 커머스, 플랫폼 서비스라면
  → On-the-fly + Managed CDN 조합이 “비용·속도·운영” 밸런스가 가장 좋다.