DEV Community

Cover image for 대규모 이미지 최적화에서 얻은 5가지 값진 교훈
Sungdong Jo
Sungdong Jo

Posted on

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

#webdev #frontend #devops

배경: 저는 이미지 최적화 서비스를 만드는 창업자입니다. 하지만 이 글은 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;
};
Enter fullscreen mode Exit fullscreen mode

교훈 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>
Enter fullscreen mode Exit fullscreen mode

교훈 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="반응형 이미지">
Enter fullscreen mode Exit fullscreen mode

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

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

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

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

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

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

  • 디자인 도구와 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
Enter fullscreen mode Exit fullscreen mode

2. 스마트 CDN 구성 

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

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']});
Enter fullscreen mode Exit fullscreen mode

결과: 중요한 수치들

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

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

핵심 요점

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

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

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

Top comments (0)