이 페이지는 Cloud Translation API를 통해 번역되었습니다.

자주 묻는 질문(FAQ)

WebP란 무엇인가요? 사용해야 하는 이유

WebP는 웹에서 볼 수 있는 다양한 사진, 반투명 이미지, 그래픽 이미지에 사용할 수 있는 손실 및 무손실 압축 방법입니다. 손실 압축 정도를 조정할 수 있으므로 사용자는 파일 크기와 이미지 품질 간의 절충점을 선택할 수 있습니다. WebP는 일반적으로 이미지 품질 손실 없이 JPEG 및 JPEG 2000보다 평균 30% 더 압축합니다 (비교 연구 참고).

WebP 형식은 기본적으로 웹 속도를 높이는 데 도움이 되는 더 작고 보기 좋은 이미지를 만드는 데 목적이 있습니다.

어떤 웹브라우저가 WebP를 기본적으로 지원하나요?

사이트 성능을 개선하려는 웹마스터는 현재 이미지의 최적화된 WebP 대안을 쉽게 만들고 WebP를 지원하는 브라우저에 타겟팅된 방식으로 제공할 수 있습니다.

WebP 손실 지원
- Chrome (데스크톱) 17 이상
- Android용 Google Chrome 버전 25 이상
- Microsoft Edge 18 이상
- Firefox 65 이상
- Opera 11.10 이상
- 네이티브 웹브라우저, Android 4.0 이상 (ICS)
- Safari 14 이상 (iOS 14 이상, macOS Big Sur 이상)
WebP 손실, 무손실 및 알파 지원
- Google Chrome (데스크톱) 23 이상
- Android용 Google Chrome 버전 25 이상
- Microsoft Edge 18 이상
- Firefox 65 이상
- Opera 12.10 이상
- 기본 웹브라우저, Android 4.2 이상 (JB-MR1)
- Pale Moon 26 이상
- Safari 14 이상 (iOS 14 이상, macOS Big Sur 이상)
WebP 애니메이션 지원
- Google Chrome (데스크톱 및 Android) 32 이상
- Microsoft Edge 18 이상
- Firefox 65 이상
- Opera 19 이상
- Safari 14 이상 (iOS 14 이상, macOS Big Sur 이상)

브라우저의 WebP 지원을 감지하려면 어떻게 해야 하나요?

WebP 이미지는 제대로 표시할 수 있는 클라이언트에만 제공하고, 표시할 수 없는 클라이언트에는 기존 형식으로 대체하는 것이 좋습니다. 다행히 클라이언트 측과 서버 측 모두에서 WebP 지원을 감지하는 방법이 몇 가지 있습니다. 일부 CDN 제공업체는 서비스의 일부로 WebP 지원 감지를 제공합니다.

Accept 헤더를 통한 서버 측 콘텐츠 협상

웹 클라이언트는 응답으로 수락할 콘텐츠 형식을 나타내는 'Accept' 요청 헤더를 전송하는 것이 일반적입니다. 브라우저가 image/webp 형식을 '허용'한다고 미리 표시하면 웹 서버는 WebP 이미지를 안전하게 전송할 수 있다는 것을 알게 되어 콘텐츠 협상이 크게 간소화됩니다. 자세한 내용은 다음 링크를 참고하세요.

Modernizr

Modernizr는 웹브라우저에서 HTML5 및 CSS3 기능 지원을 편리하게 감지하는 JavaScript 라이브러리입니다. Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha, Modernizr.webp.animation 속성을 찾습니다.

HTML5 `<picture>` 요소

HTML5는 <picture> 요소를 지원하므로 클라이언트가 제대로 표시할 수 있는 첫 번째 후보 이미지를 요청하도록 우선순위 순서로 여러 대체 이미지 타겟을 나열할 수 있습니다. HTML5 Rocks의 이 토론을 참고하세요. <picture> 요소는 항상 더 많은 브라우저에서 지원됩니다.

자체 JavaScript

또 다른 감지 방법은 특정 기능을 사용하는 매우 작은 WebP 이미지를 디코딩하여 성공 여부를 확인하는 것입니다. 예:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

이미지 로드는 차단되지 않고 비동기식입니다. 즉, WebP 지원에 종속된 코드는 콜백 함수에 배치하는 것이 좋습니다.

Google이 WebP를 오픈소스로 출시한 이유는 무엇인가요?

Google은 오픈소스 모델의 중요성을 깊이 신뢰합니다. 오픈소스 WebP를 사용하면 누구나 이 형식을 사용하고 개선사항을 제안할 수 있습니다. 여러분의 의견과 제안을 바탕으로 WebP가 시간이 지날수록 그래픽 형식으로 더욱 유용해질 것이라고 생각합니다.

개인 이미지 파일을 WebP로 변환하려면 어떻게 해야 하나요?

WebP 명령줄 유틸리티를 사용하여 개인 이미지 파일을 WebP 형식으로 변환할 수 있습니다. 자세한 내용은 WebP 사용을 참고하세요.

변환할 이미지가 많은 경우 플랫폼의 셸을 사용하여 작업을 간소화할 수 있습니다. 예를 들어 폴더의 모든 jpeg 파일을 변환하려면 다음을 시도하세요.

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

WebP 이미지 품질을 직접 판단하려면 어떻게 해야 하나요?

현재는 WebP 파일을 PNG와 같은 무손실 압축을 사용하는 일반 형식으로 변환한 후 브라우저나 이미지 뷰어에서 PNG 파일을 보는 방식으로 WebP 파일을 볼 수 있습니다. WebP 품질을 빠르게 파악하려면 이 사이트의 갤러리에서 나란히 표시된 사진을 비교해 보세요.

소스 코드는 어떻게 가져오나요?

변환기 코드는 WebP 오픈소스 프로젝트 페이지의 다운로드 섹션에서 확인할 수 있습니다. 경량 디코더와 VP8 사양에 관한 코드는 WebM 사이트에 있습니다. 컨테이너 사양은 RIFF 컨테이너 페이지를 참고하세요.

WebP 이미지의 최대 크기는 얼마인가요?

WebP는 VP8과 비트스트림 호환되며 너비와 높이에 14비트를 사용합니다. WebP 이미지의 최대 픽셀 크기는 16383x16383입니다.

WebP 형식은 어떤 색상 공간을 지원하나요?

VP8 비트스트림과 마찬가지로 손실 WebP는 8비트 Y'CbCr 4:2:0 (YUV420이라고도 함) 이미지 형식에서만 작동합니다. 자세한 내용은 RFC 6386, VP8 데이터 형식 및 디코딩 가이드의 섹션 2, '형식 개요'를 참고하세요.

무손실 WebP는 RGBA 형식에서만 작동합니다. WebP 무손실 비트스트림 사양을 참고하세요.

무손실 WebP 파일이 원본과 다른 이유는 무엇인가요?

Simple Encoding API 함수 (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA())는 라이브러리의 기본 설정을 사용합니다. 무손실의 경우 '정확'이 사용 중지됨을 의미합니다. 완전히 투명한 영역 (즉, 알파 값이 0인 영역)의 RGB 값은 압축을 개선하기 위해 수정됩니다. 이를 방지하려면 WebPEncode()를 사용하고 WebPConfig::exact를 1로 설정하세요. 고급 인코딩 API 문서를 참고하세요.

WebP 이미지가 소스 이미지보다 커질 수 있나요?

예, 일반적으로 손실 형식에서 WebP 무손실로 또는 그 반대로 변환할 때 발생합니다. 이는 주로 색상 공간 차이 (YUV420 대 ARGB)와 이들 간의 변환 때문입니다.

일반적으로 세 가지 상황이 있습니다.

소스 이미지가 무손실 ARGB 형식인 경우 YUV420으로의 공간 다운샘플링은 원래 색상보다 압축하기 어려운 새로운 색상을 도입합니다. 이 상황은 일반적으로 소스가 색상이 적은 PNG 형식인 경우에 발생할 수 있습니다. 손실 WebP (또는 손실 JPEG와 유사)로 변환하면 파일 크기가 커질 수 있습니다.
소스가 손실 형식인 경우 손실 소스의 특성을 캡처하기 위해 무손실 WebP 압축을 사용하면 일반적으로 파일이 더 커집니다. 이는 WebP에만 해당되는 것이 아니며 JPEG 소스를 무손실 WebP 또는 PNG 형식으로 변환할 때도 발생할 수 있습니다.
소스가 손실 형식인데 더 높은 품질 설정으로 손실 WebP로 압축하려고 하는 경우 예를 들어 품질 80으로 저장된 JPEG 파일을 품질 95의 WebP 파일로 변환하려고 하면 두 형식이 손실 형식이더라도 일반적으로 파일이 더 커집니다. 소스의 품질을 평가하는 것은 불가능한 경우가 많으므로 파일 크기가 일관되게 큰 경우 타겟 WebP 품질을 낮추는 것이 좋습니다. 품질 설정을 사용하지 않고 대신 cwebp 도구의 -size 옵션이나 이에 상응하는 API를 사용하여 특정 파일 크기를 타겟팅할 수도 있습니다. 예를 들어 원본 파일 크기의 80% 를 타겟팅하는 것이 더 안정적일 수 있습니다.

JPEG 소스를 손실 WebP로 변환하거나 PNG 소스를 무손실 WebP로 변환하는 경우에는 파일 크기가 예상치 못하게 커지는 경우가 거의 없습니다.

WebP는 프로그레시브 또는 인터레이스 디스플레이를 지원하나요?

WebP는 JPEG 또는 PNG 의미에서 프로그레시브 또는 인터레이스 디코딩 새로고침을 제공하지 않습니다. 각 새로고침 이벤트에는 압축 해제 시스템을 통한 전체 패스가 포함되므로 디코딩 클라이언트의 CPU와 메모리에 너무 많은 부담이 가해질 수 있습니다.

점진적 JPEG 이미지를 디코딩하는 것은 평균적으로 기준 이미지를 3번 디코딩하는 것과 같습니다.

또는 WebP는 증분 디코딩을 제공합니다. 여기서 비트 스트림의 사용 가능한 모든 수신 바이트는 가능한 한 빨리 표시 가능한 샘플 행을 생성하는 데 사용됩니다. 이렇게 하면 클라이언트에서 메모리, CPU, 다시 그리기 노력을 절약하면서 다운로드 상태에 관한 시각적 신호를 제공할 수 있습니다. 증분 디코딩 기능은 고급 디코딩 API를 통해 사용할 수 있습니다.

Android 프로젝트에서 libwebp Java 바인딩을 사용하려면 어떻게 해야 하나요?

WebP에는 swig/ 디렉터리의 간단한 인코더 및 디코더 인터페이스에 대한 JNI 바인딩 지원이 포함됩니다.

Eclipse에서 라이브러리 빌드:

NDK 도구와 함께 ADT 플러그인이 설치되어 있고 NDK 경로가 올바르게 설정되어 있는지 확인합니다(환경설정 > Android > NDK).
새 프로젝트를 만듭니다(파일 > 새로 만들기 > 프로젝트 > Android 애플리케이션 프로젝트).
새 프로젝트에서 libwebp를 jni라는 폴더에 클론하거나 압축을 해제합니다.
swig/libwebp_java_wrap.c를 LOCAL_SRC_FILES 목록에 추가합니다.
새 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 Android 도구 > 네이티브 지원 추가 ...를 선택하여 빌드에 라이브러리를 포함합니다.
프로젝트 속성을 열고 C/C++ 빌드 > 동작으로 이동합니다. ENABLE_SHARED=1를 Build (Incremental build) 섹션에 추가하여 libwebp를 공유 라이브러리로 빌드합니다.

참고 NDK_TOOLCHAIN_VERSION=4.8를 설정하면 일반적으로 32비트 빌드 성능이 향상됩니다.
swig/libwebp.jar를 libs/ 프로젝트 폴더에 추가합니다.
프로젝트를 빌드합니다. 그러면 libs/<target-arch>/libwebp.so가 생성됩니다.
System.loadLibrary("webp")를 사용하여 런타임에 라이브러리를 로드합니다.

라이브러리는 ndk-build 및 포함된 Android.mk을 사용하여 수동으로 빌드할 수 있습니다. 이 경우 위에서 설명한 단계 중 일부를 재사용할 수 있습니다.

C#으로 libwebp를 사용하려면 어떻게 해야 하나요?

WebP는 libwebp API를 내보내는 DLL로 빌드할 수 있습니다. 그런 다음 이러한 함수를 C#으로 가져올 수 있습니다.

libwebp.dll을 빌드합니다. 이렇게 하면 API 함수를 내보낼 수 있도록 WEBP_EXTERN이 올바르게 설정됩니다.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

프로젝트에 libwebp.dll을 추가하고 원하는 함수를 가져옵니다. 간단한 API를 사용하는 경우 반환된 버퍼를 해제하기 위해 WebPFree()를 호출해야 합니다.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

애니메이션 WebP를 사용해야 하는 이유는 무엇인가요?

애니메이션 GIF와 비교한 애니메이션 WebP의 장점

WebP는 GIF의 8비트 색상과 1비트 알파에 비해 8비트 알파 채널이 있는 24비트 RGB 색상을 지원합니다.
WebP는 손실 및 무손실 압축을 모두 지원합니다. 실제로 단일 애니메이션에서 손실 및 무손실 프레임을 결합할 수 있습니다. GIF는 무손실 압축만 지원합니다. WebP의 손실 압축 기술은 실제 동영상에서 만든 애니메이션 이미지에 적합하며, 이는 애니메이션 이미지의 점점 더 인기 있는 소스입니다.
WebP는 GIF보다 바이트 수가 적습니다¹. 손실 WebP로 변환된 애니메이션 GIF는 64% 더 작고 무손실 WebP는 19% 더 작습니다. 이는 모바일 네트워크에서 특히 중요합니다.
WebP는 탐색이 있는 경우 디코딩하는 데 시간이 덜 걸립니다. Blink에서 스크롤하거나 탭을 변경하면 이미지가 숨겨지거나 표시될 수 있으므로 애니메이션이 일시중지된 후 다른 지점으로 건너뛸 수 있습니다. 프레임이 삭제되는 과도한 CPU 사용량으로 인해 디코더가 애니메이션에서 앞으로 탐색해야 할 수도 있습니다. 이러한 시나리오에서 애니메이션 WebP는 GIF보다 총 디코딩 시간이 0.57배 더 걸리므로² 스크롤 중에 끊김 현상이 줄어들고 CPU 사용량 급증에서 더 빠르게 복구됩니다. 이는 GIF에 비해 WebP가 갖는 두 가지 이점 때문입니다.
- WebP 이미지는 각 프레임에 알파가 포함되어 있는지에 관한 메타데이터를 저장하므로 이 결정을 내리기 위해 프레임을 디코딩할 필요가 없습니다. 이렇게 하면 특정 프레임이 의존하는 이전 프레임을 더 정확하게 추론할 수 있으므로 이전 프레임의 불필요한 디코딩이 줄어듭니다.
- 최신 동영상 인코더와 마찬가지로 WebP 인코더는 정기적으로 키프레임을 휴리스틱하게 추가합니다 (대부분의 GIF 인코더는 이렇게 하지 않음). 이렇게 하면 긴 애니메이션에서 탐색이 크게 개선됩니다. 이미지 크기를 크게 늘리지 않고 이러한 프레임을 삽입하기 위해 WebP는 GIF에서 사용하는 프레임 삭제 방법 외에 각 프레임에 '혼합 방법' 플래그를 추가합니다. 이를 통해 이전 프레임을 전체 크기로 강제하지 않고도 전체 이미지가 배경 색상으로 지워진 것처럼 키프레임을 그릴 수 있습니다.

애니메이션 GIF와 비교한 애니메이션 WebP의 단점

탐색이 없는 경우 WebP의 직선 디코딩은 GIF보다 CPU 집약적입니다. 손실 WebP는 GIF보다 2.2배 더 많은 디코딩 시간이 걸리고 무손실 WebP는 1.5배 더 많은 시간이 걸립니다.
WebP 지원은 사실상 보편적인 GIF 지원만큼 널리 퍼져 있지 않습니다.
브라우저에 WebP 지원을 추가하면 코드 설치 공간과 공격 표면이 증가합니다. Blink에서는 WebP demux 라이브러리와 Blink 측 WebP 이미지 디코더를 포함하여 약 1,500줄의 코드가 추가됩니다. 향후 WebP와 WebM이 더 일반적인 디코딩 코드를 공유하거나 WebP의 기능이 WebM에 포함되면 이 문제가 줄어들 수 있습니다.

<img>에서 WebM을 지원하지 않는 이유는 무엇인가요?

장기적으로는 <img> 태그 내에서 동영상 형식을 지원하는 것이 좋습니다. 하지만 <img>의 WebM이 제안된 애니메이션 WebP 역할을 할 수 있다는 의도로 지금 이렇게 하는 것은 문제가 있습니다.

이전 프레임에 의존하는 프레임을 디코딩할 때 WebM은 이전 프레임의 최소 개수³를 유지하기 위해 애니메이션 WebP보다 50% 더 많은 메모리가 필요합니다.
동영상 코덱 및 컨테이너 지원은 브라우저와 기기에 따라 크게 다릅니다. 자동 콘텐츠 트랜스코딩 (예: 대역폭 절약 프록시)을 용이하게 하려면 브라우저에서 이미지 태그가 지원하는 형식을 나타내는 accept 헤더를 추가해야 합니다. 'video/webm' 또는 'video/mpeg'과 같은 MIME 유형은 코덱 지원 (예: VP8 대 VP9)을 나타내지 않으므로 이 방법도 충분하지 않을 수 있습니다. 반면 WebP 형식은 사실상 고정되어 있으며 이를 제공하는 공급업체가 애니메이션 WebP를 제공하는 데 동의하는 경우 모든 UA에서 WebP의 동작이 일관되어야 합니다. 또한 'image/webp' accept 헤더는 이미 WebP 지원을 나타내는 데 사용되므로 새로운 accept 헤더 변경이 필요하지 않습니다.
Chromium 동영상 스택은 원활한 재생에 최적화되어 있으며 한 번에 재생되는 동영상이 하나 또는 두 개라고 가정합니다. 따라서 구현은 재생 품질을 극대화하기 위해 시스템 리소스 (스레드, 메모리 등)를 적극적으로 소비합니다. 이러한 구현은 많은 동시 동영상으로 확장되지 않으며 이미지 중심 웹페이지와 함께 사용하기에 적합하도록 재설계해야 합니다.
WebM은 현재 WebP의 모든 압축 기술을 통합하지 않습니다. 따라서 이 이미지는 대안보다 WebP로 훨씬 더 잘 압축됩니다.

¹ 애니메이션 GIF와 애니메이션 WebP 간의 모든 비교에서 웹에서 무작위로 가져온 약 7, 000개의 애니메이션 GIF 이미지 코퍼스를 사용했습니다. 이 이미지는 2013년 10월 8일 기준 최신 libwebp 소스 트리에서 빌드된 기본 설정을 사용하여 'gif2webp' 도구를 사용하여 애니메이션 WebP로 변환되었습니다. 비교 수치는 이러한 이미지의 평균값입니다.

² 디코딩 시간은 2013년 8월 10일 현재 최신 libwebp + ToT Blink를 사용하여 벤치마크 도구를 통해 계산되었습니다. '탐색을 통한 디코딩 시간'은 '처음 5개 프레임 디코딩, 프레임 버퍼 캐시 지우기, 다음 5개 프레임 디코딩 등'으로 계산됩니다.

³ WebM은 메모리에 4개의 YUV 참조 프레임을 유지하며 각 프레임은 (너비+96)*(높이+96) 픽셀을 저장합니다. YUV 4:2:0의 경우 6픽셀당 4바이트 (또는 픽셀당 3/2바이트)가 필요합니다. 따라서 이러한 참조 프레임은 4*3/2*(width+96)*(height+96)바이트의 메모리를 사용합니다. 반면 WebP는 이전 프레임 (RGBA)만 사용할 수 있으면 되므로 4*width*height바이트의 메모리가 필요합니다.

⁴ 애니메이션 WebP 렌더링에는 Chrome 버전 32 이상이 필요합니다.

자주 묻는 질문(FAQ) 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.