DEV Community: Sungdong Jo

대규모 이미지 최적화에서 얻은 5가지 값진 교훈

Sungdong Jo — Fri, 12 Sep 2025 15:53:57 +0000

배경: 저는 이미지 최적화 서비스를 만드는 창업자입니다. 하지만 이 글은 5년 이상의 대규모 이미지 애플리케이션 개발 경험에서 얻은 진솔한 기술적 인사이트를 공유하는 데 초점을 맞췄습니다.

기능을 배포한 후 이미지가 끔찍하게 느리게 로딩된다는 걸 깨닫거나, 최적화하지 않은 에셋 때문에 AWS 비용이 두 배로 뛰어오른 경험이 있으신가요? 핀테크와 여행 회사에서 프론트엔드 엔지니어로 일하면서, 이미지 최적화와 관련된 모든 실수를 다 해봤습니다. 힘들게 배운 교훈들을 공유합니다.

월 $2,500 추가 비용: "내 컴퓨터에서는 잘 되는데"의 함정

상상해보세요. 이해관계자들에게 새로운 제품 기능을 시연하고 있습니다. 맥북 프로와 광랜에서 이미지들이 선명하게 보입니다. 모두가 인상 깊어합니다. 그런데 사용자들이 모바일에서 이미지가 흐리다고 불만을 제기하기 시작하고, AWS 청구서가 월 $500에서 $3,000으로 뛰어오릅니다.

이게 바로 고해상도 여행지 사진을 제공하던 여행 회사에서 제가 겪은 현실이었습니다. 3G 연결을 사용하는 모바일 사용자들에게 4K 이미지를 제공하고 있었죠. 비즈니스 임팩트가 심각했습니다:

이미지 중심 플로우에서 20% 사용자 이탈
최적화된 버전 대비 6배 높은 클라우드 저장/대역폭 비용
Core Web Vitals 점수로 인한 낮은 검색 순위

핵심 문제는? 이미지 최적화를 기본 요구사항이 아닌 부차적인 것으로 취급했다는 점이었습니다.

교훈 1: 네트워크 속도 가정은 당신을 태워버릴 것입니다

페이지 로딩이 1초 지연될 때마다 전환율이 최대 20% 감소할 수 있습니다(Google/SOASTA 연구). 하지만 연구에서 말해주지 않는 것은, 지역과 기기에 따라 임팩트가 다르게 복합된다는 점입니다.

우리 서비스의 실제 데이터:

도시 지역 (빠른 광랜): 사용자의 95%가 2-3초 이미지 로딩을 견뎠음
신흥 시장: 동일한 로딩 시간에 60% 이탈률
모바일 우선 시장: 1초 지연도 상당한 이탈 유발

해결책: 항상 현실적인 네트워크에서 테스트하세요. Chrome DevTools의 "Slow 4G"가 우리의 기본 개발 설정이 되었습니다. 또한 점진적 이미지 로딩을 구현했습니다:

// 우리가 사용한 점진적 JPEG + WebP 폴백 전략
const loadOptimizedImage = (src, element) => {
  const webpSrc = src.replace(/\.(jpg|png)$/, '.webp');
  const img = new Image();

  img.onload = () => {
    element.src = webpSrc;
    element.classList.add('loaded');
  };

  img.onerror = () => {
    // 원본 포맷으로 폴백
    element.src = src;
    element.classList.add('loaded');
  };

  img.src = webpSrc;
};

교훈 2: 포맷 선택은 단순히 파일 크기의 문제가 아닙니다

처음에는 파일 크기를 줄이는 것에만 집중해서 모든 것을 WebP로 변환했습니다. 큰 실수였죠. 각각의 포맷은 서로 다른 목적을 가지고 있습니다:

WebP: 사진에 좋음, JPEG보다 25-35% 작음

사용처: 제품 사진, 사용자 아바타, 마케팅 이미지
제한사항: 일부 구형 브라우저에서 여전히 지원 안 됨

AVIF: 더욱 작음 (최대 50% 감소), 하지만 디코딩이 느림

사용처: 로딩 시간이 디코딩 속도보다 중요한 히어로 이미지
제한사항: 인코딩이 계산적으로 비쌈

PNG: 투명도가 있는 그래픽에 여전히 필요

사용처: 아이콘, 로고, 날카로운 가장자리가 있는 일러스트레이션

우리에게 효과적이었던 제공 전략입니다:

<!-- 적절한 폴백과 함께 다중 포맷 지원 -->
<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="구형 브라우저용 폴백">
</picture>

교훈 3: 반응형 이미지는 생각보다 어렵습니다

"그냥 srcset을 사용하면 되잖아?" 틀렸습니다. 기기, 화면 밀도, 아트 디렉션에서 실제로 작동하는 진정한 반응형 이미지를 구현하려면 신중한 계획이 필요합니다.

서로 다른 이미지 요구사항을 가진 세 플랫폼(iOS, Android, Web)을 지원하면서 이를 배웠습니다:

<!-- 실제로 우리에게 효과적이었던 것 -->
<img 
  srcset="
    image-320w.webp 320w,
    image-640w.webp 640w,
    image-960w.webp 960w,
    image-1280w.webp 1280w"
  sizes="
    (max-width: 320px) 280px,
    (max-width: 640px) 580px,
    (max-width: 960px) 860px,
    1200px"
  src="image-640w.webp" 
  alt="반응형 이미지">

프로 팁: sizes 속성은 중요하지만 종종 간과됩니다. 이것은 뷰포트 크기가 아닌 이미지의 실제 표시 크기를 브라우저에 알려줍니다.

교훈 4: 디자이너-개발자 핸드오프는 병목을 만듭니다

전통적인 워크플로우가 우리의 속도를 죽였습니다:

디자이너가 Figma에서 에셋 생성
개발자가 다양한 크기/포맷 다운로드
수동 최적화 및 CDN 업로드
코드에서 이미지 URL 업데이트
기기별 테스트

이는 기능당 몇 시간이 걸렸고 오류가 발생하기 쉬웠습니다.

우리의 해결책: 이 워크플로우를 자동화했습니다. 수동 다운로드 대신:

디자인 도구와 CDN 간 API 통합 구축
포맷 변환 및 최적화 자동화
반응형 변형 자동 생성
즉시 사용 가능한 직접 CDN URL 제공

시간 절약 효과가 극적이었습니다: 2-3시간이 걸리던 작업이 이제 5분이면 됩니다.

교훈 5: 자체 구축 vs 서드파티는 기회비용의 문제입니다

한 스타트업에서 3주 동안 내부 이미지 최적화 시스템을 구축했습니다. 두 명의 시니어 개발자가 작업했지만, 여전히 불완전했고 지속적인 유지보수가 필요했습니다.

숨겨진 비용들:

개발 시간: 초기 개발에 6인주
유지보수 오버헤드: 주당 약 4시간 지속
기회비용: 경쟁사가 출시하는 동안 핵심 기능 지연

한편, 핵심 비즈니스에는 관심이 필요했습니다. 고객 획득 문제, 제품-시장 적합성 질문, 기능 백로그가 있었죠.

깨달음: 이미지 처리가 핵심 비즈니스 차별화 요소가 아니라면, 이를 인프라로 취급하세요. 엔지니어링 자원을 제품을 독특하게 만드는 것에 집중하세요.

이 경험 후, 우리는 빌드 vs 구매를 더 체계적으로 평가했습니다:

빌드할 때: 가치 제안의 핵심일 때
구매할 때: 필요하지만 차별화되지 않을 때

기술적 구현: 실제로 효과적이었던 것들

모든 프로젝트에서 지금 따르고 있는 이미지 최적화 체크리스트입니다:

1. 자동화된 최적화 파이프라인

# 우리의 일반적인 최적화 워크플로우
convert original.jpg -quality 85 -strip optimized.jpg
cwebp optimized.jpg -q 80 -o optimized.webp
avifenc --min 20 --max 30 optimized.jpg optimized.avif

2. 스마트 CDN 구성

// 자동 포맷 제공을 위한 CloudFront 구성
const cloudFrontConfig = {
  originRequestPolicy: {
    headers: ['Accept', 'CloudFront-Is-Mobile-Viewer'],
    queryStrings: ['w', 'h', 'q', 'format']
  },
  // 지원하는 브라우저에 WebP 자동 제공
  responseHeadersPolicy: {
    customHeaders: {
      'Vary': 'Accept'
    }
  }
};

3. 성능 모니터링

// Core Web Vitals 임팩트 추적
const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    if (entry.entryType === 'largest-contentful-paint') {
      // 최적화 후 LCP 개선 추적
      analytics.track('lcp_score', entry.startTime);
    }
  });
});

observer.observe({entryTypes: ['largest-contentful-paint']});

결과: 중요한 수치들

여러 프로젝트에서 이러한 교훈들을 구현한 후:

로딩 속도: 3-5배 빠른 이미지 로딩
대역폭 비용: CDN 비용 60-80% 감소
사용자 참여도: 이미지 중심 페이지 완료율 25% 증가
SEO 임팩트: Core Web Vitals 점수 개선, 검색 순위 향상

핵심 요점

첫날부터 현실적인 네트워크에서 테스트하세요, 빠른 사무실 와이파이가 아니라
전략적으로 포맷 선택하세요, 단순히 파일 크기만이 아니라
올바른 sizes 속성과 함께 적절한 반응형 이미지 구현
속도 유지를 위해 디자이너-개발자 핸드오프 자동화
금전적 비용이 아닌 기회비용을 기반으로 빌드 vs 구매 평가

이미지 최적화는 간단해 보이지만, 대규모에서 올바르게 하는 것은 수많은 엣지 케이스와 트레이드오프를 포함합니다. 이러한 교훈들은 우리에게 시간, 돈, 사용자 만족도를 비용으로 치렀습니다 - 여러분이 같은 실수를 피할 수 있기를 바랍니다.

이러한 문제들을 반복적으로 겪은 후, 결국 다른 개발팀들을 위해 정확히 이런 문제들을 해결하는 Snapkit을 만들게 되었습니다. 하지만 어떤 도구를 사용하든 상관없이, 위의 핵심 원칙들은 여러분에게 도움이 될 것입니다.

5 Hard-Learned Lessons About Image Optimization at Scale

Sungdong Jo — Fri, 12 Sep 2025 09:20:21 +0000

Disclosure: I'm the founder of an image optimization service, but this post focuses on sharing genuine technical insights from my 5+ years of experience building image-heavy applications at scale.

Have you ever deployed a feature only to realize your images are loading painfully slow, or discovered your AWS bill doubled because of unoptimized assets? After working as a frontend engineer at fintech and travel companies, I've made every possible image optimization mistake. Here's what I learned the hard way.

The $5K Monthly Surprise: When "It Works on My Machine" Goes Wrong

Picture this: You're demoing your new product feature to stakeholders. The images look crisp on your MacBook Pro with fiber internet. Everyone's impressed. Then users start complaining that images are blurry on mobile, and your AWS bill jumps from $500 to $3,000 monthly.

This was my reality at a travel company where we served high-resolution destination photos. We were serving 4K images to mobile users on 3G connections. The business impact hit us hard:

20% user drop-off during image-heavy flows
6x higher cloud storage/bandwidth costs compared to optimized versions
Poor search rankings due to Core Web Vitals scores

The core problem? We treated image optimization as an afterthought instead of a fundamental requirement.

Lesson 1: Network Speed Assumptions Will Burn You

Every 1-second page loading delay can reduce conversion rates by up to 20% (Google/SOASTA study). But here's what the studies don't tell you: the impact compounds differently across regions and devices.

Real data from our services:

Urban areas (fast fiber): 95% of users tolerated 2-3 second image loads
Emerging markets: 60% bounce rate with same loading times
Mobile-first markets: Even 1-second delays caused significant churn

The fix: Always test on realistic networks. Chrome DevTools' "Slow 4G" became our default development setting. We also implemented progressive image loading:

// Progressive JPEG + WebP fallback strategy we used
const loadOptimizedImage = (src, element) => {
  const webpSrc = src.replace(/\.(jpg|png)$/, '.webp');
  const img = new Image();

  img.onload = () => {
    element.src = webpSrc;
    element.classList.add('loaded');
  };

  img.onerror = () => {
    // Fallback to original format
    element.src = src;
    element.classList.add('loaded');
  };

  img.src = webpSrc;
};

Lesson 2: Format Choice Isn't Just About File Size

We initially focused only on reducing file sizes, converting everything to WebP. Big mistake. Different formats serve different purposes:

WebP: Great for photos, 25-35% smaller than JPEG

Used for: Product photos, user avatars, marketing images
Limitation: Still not supported by some older browsers

AVIF: Even smaller (up to 50% reduction), but slower decode

Used for: Hero images where loading time matters more than decode speed
Limitation: Encoding is computationally expensive

PNG: Still necessary for graphics with transparency

Used for: Icons, logos, illustrations with sharp edges

Here's the serving strategy that worked for us:

<!-- Multiple format support with proper fallbacks -->
<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Fallback for older browsers">
</picture>

Lesson 3: Responsive Images Are Harder Than They Look

"Just use srcset, right?" Wrong. Implementing truly responsive images that work across devices, screen densities, and art direction requires careful planning.

We learned this supporting three platforms (iOS, Android, Web) with different image requirements:

<!-- This is what actually worked for us -->
<img 
  srcset="
    image-320w.webp 320w,
    image-640w.webp 640w,
    image-960w.webp 960w,
    image-1280w.webp 1280w"
  sizes="
    (max-width: 320px) 280px,
    (max-width: 640px) 580px,
    (max-width: 960px) 860px,
    1200px"
  src="image-640w.webp" 
  alt="Responsive image">

Pro tip: The sizes attribute is crucial and often overlooked. It tells the browser the actual display size of the image, not just the viewport size.

Lesson 4: Designer-Developer Handoff Creates Bottlenecks

The traditional workflow killed our velocity:

Designer creates assets in Figma
Developer downloads various sizes/formats
Manual optimization and upload to CDN
Update image URLs in code
Test across devices

This took hours per feature and was error-prone.

Our solution: We automated this workflow. Instead of manual downloads, we:

Built API integration between design tools and our CDN
Automated format conversion and optimization
Generated responsive variants automatically
Provided direct CDN URLs for immediate use

The time savings were dramatic: what took 2-3 hours now takes 5 minutes.

Lesson 5: In-House vs. Third-Party Is About Opportunity Cost

At one startup, we spent 3 weeks building an internal image optimization system. Two senior developers worked on it, but it was still incomplete and required ongoing maintenance.

The hidden costs:

Development time: 6 person-weeks initial development
Maintenance overhead: ~4 hours/week ongoing
Opportunity cost: Delayed core features while competitors shipped

Meanwhile, the core business needed attention. We had customer acquisition challenges, product-market fit questions, and feature backlogs.

The realization: Unless image processing is your core business differentiator, treat it as infrastructure. Focus engineering resources on what makes your product unique.

After this experience, we evaluated build vs. buy more systematically:

Build when: It's core to your value proposition
Buy when: It's necessary but not differentiating

Results: The Numbers That Matter

After implementing these lessons across multiple projects:

Loading speed: 3-5x faster image loading
Bandwidth costs: 60-80% reduction in CDN bills
User engagement: 25% increase in image-heavy page completion rates
SEO impact: Improved Core Web Vitals scores, better search rankings

Key Takeaways

Test on realistic networks from day one, not just fast office wifi
Choose formats strategically, not just for file size
Implement proper responsive images with correct sizes attributes
Automate the designer-developer handoff to maintain velocity
Evaluate build vs. buy based on opportunity cost, not just monetary cost

Image optimization seems straightforward, but doing it right at scale involves numerous edge cases and trade-offs. These lessons cost us time, money, and user satisfaction - hopefully they can save you from the same mistakes.

After going through all these challenges repeatedly, I ended up building Snapkit to solve these exact problems for other development teams. But regardless of what tools you use, the core principles above will serve you well.

If you've faced similar challenges or have questions about implementation details, I'd love to discuss in the comments. What image optimization problems are you currently wrestling with?