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

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

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

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	월 요청량	월 트래픽	GB 절감 비용 (0.15$/GB)	람다 비용
1,000	3M	300 GB	$ 9 /mo	$ 0.5 /mo
3,000	9M	900 GB	$ 27 /mo	$ 1.5 /mo
5,000	15M	1,500 GB	$ 45 /mo	$ 2.6 /mo
10,000	30M	3,000 GB	$ 90 /mo	$ 5.2 /mo
50,000	150M	15,000 GB	$ 450 /mo	$ 26.2 /mo
100,000	300M	30,000 GB	$ 900 /mo	$ 52.4 /mo

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

WebP/AVIF + 리사이징 + 캐싱만으로도 30~50% 트래픽 절감은 충분히 노려볼 수 있고,
Miss 비율을 낮게 유지하면 Lambda 비용은 전체 비용에서 아주 작은 비중을 차지합니다.

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

Lambda@Edge vs Managed CDN

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

직접 구축: CloudFront + Lambda@Edge
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 조합이 “비용·속도·운영” 밸런스가 가장 좋다.