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

자주 묻는 질문(FAQ)

WebP란 무엇인가요? 왜 사용해야 하나요?

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

WebP 형식은 기본적으로 더 작고 보기 좋은 이미지를 만들어 웹을 더 빠르게 만드는 것을 목표로 합니다.

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

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

WebP 손실 지원
- Chrome (데스크톱) 17 이상
- Android용 Chrome 버전 25 이상
- Microsoft Edge 18 이상
- Firefox 65 이상
- Opera 11.10 이상
- 기본 웹브라우저, Android 4.0 이상 (ICS)
- Safari 14 이상 (iOS 14 이상, macOS Big Sur+)
WebP 손실, 무손실 및 알파 지원
- Chrome (데스크톱) 23 이상
- Android용 Chrome 버전 25 이상
- Microsoft Edge 18 이상
- Firefox 65 이상
- Opera 12.10 이상
- 기본 웹브라우저, Android 4.2 이상 (JB-MR1)
- 페일 문 26 이상
- Safari 14 이상 (iOS 14 이상, macOS Big Sur+)
WebP 애니메이션 지원
- 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는 웹브라우저에서 HTML5 및 CSS3 기능 지원을 편리하게 감지하는 자바스크립트 라이브러리입니다. Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha, Modernizr.webp.animation 속성을 찾습니다.

HTML5 `<picture>` 요소

HTML5는 <picture> 요소를 지원합니다. 이 요소를 사용하면 여러 대체 이미지 타겟을 우선순위에 따라 나열할 수 있습니다. 그러면 클라이언트가 올바르게 표시할 수 있는 첫 번째 후보 이미지를 요청할 수 있습니다. HTML5 Rocks에 관한 이 논의를 참조하세요. <picture> 요소는 항상 더 많은 브라우저에서 지원됩니다.

자체 자바스크립트

또 다른 감지 방법은 특정 기능을 사용하는 매우 작은 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를 사용하면 누구나 형식을 사용하고 개선사항을 제안할 수 있습니다. Google은 여러분의 입력과 제안을 통해 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 오픈소스 프로젝트 페이지의 다운로드 섹션에서 확인할 수 있습니다. 경량형 디코더 및 VP8 사양에 관한 코드는 WebM 사이트에 있습니다. 컨테이너 사양은 RIFF 컨테이너 페이지를 참고하세요.

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

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

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

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

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

WebP 이미지를 소스 이미지보다 더 크게 늘릴 수 있나요?

예. 일반적으로 손실(lossy) 형식에서 WebP 무손실로 변환하거나 그 반대로 변환할 때가 있습니다. 이는 주로 색공간 차이 (YUV420과 ARGB)와 이 간의 변환으로 인해 발생합니다.

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

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

JPEG 소스를 손실(lossy) WebP로 변환하거나 PNG 소스를 무손실 WebP로 변환하면 놀라울 정도로 큰 파일 크기가 발생하지 않습니다.

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

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

평균적으로 프로그레시브 JPEG 이미지를 디코딩하는 것은 기준을 3번 디코딩하는 것과 같습니다.

또는 WebP는 사용 가능한 모든 비트스트림의 수신 바이트를 사용하여 표시 가능한 샘플 행을 최대한 빨리 생성하려고 시도하는 증분 디코딩을 제공합니다. 이렇게 하면 다운로드 상태에 관한 시각적 신호를 제공하는 동시에 클라이언트의 메모리, CPU 및 다시 페인트 작업을 절약할 수 있습니다. 증분 디코딩 기능은 Advanced Decoding API를 통해 사용할 수 있습니다.

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

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

Eclipse에서 라이브러리 빌드:

ADT 플러그인이 NDK 도구와 함께 설치되어 있고 NDK 경로가 올바르게 설정되어 있는지 확인합니다(환경설정 > Android > NDK).
File > New > Project > Android Application Project를 선택하여 새 프로젝트를 만듭니다.
새 프로젝트의 jni라는 폴더에 libwebp를 클론하거나 압축해제합니다.
LOCAL_SRC_FILES 목록에 swig/libwebp_java_wrap.c를 추가합니다.
새 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 Android Tools > Add Native Support ...를 선택하여 라이브러리를 빌드에 포함합니다.
프로젝트 속성을 열고 C/C++ Build > Behavior로 이동합니다. 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을 빌드합니다. 이렇게 하면 WEBP_EXTERN이 올바르게 설정되어 API 함수를 내보냅니다.
```
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는 손실(lossy) 압축과 무손실 압축을 모두 지원합니다. 실제로 단일 애니메이션에서 손실이 있는 프레임과 무손실 프레임을 결합할 수 있습니다. 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를 더 많이 사용합니다. 손실(lossy) WebP는 GIF보다 디코딩 시간이 2.2배 길고 무손실 WebP는 1.5배 더 오래 걸립니다.
WebP 지원은 사실상 보편적인 GIF 지원만큼 광범위하지 않습니다.
브라우저에 WebP 지원을 추가하면 코드 공간과 공격 표면이 증가합니다. Blink에서 추가된 코드는 약 1,500줄의 추가 코드입니다 (WebP demux 라이브러리 및 Blink-side WebP 이미지 디코더 포함). WebP와 WebM이 더 일반적인 디코딩 코드를 공유하거나 WebP 기능이 WebM의 기능에 포함되면 이 문제가 향후 줄어들 수 있습니다.

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

<img> 태그 내에서 동영상 형식을 지원하는 것이 장기적으로 타당할 수 있습니다. 그러나 이제 이렇게 하면 <img>의 WebM이 애니메이션 WebP의 제안된 역할을 채울 수 있다는 인텐트 때문에 다음과 같이 문제가 있습니다.

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

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

² 디코딩 시간은 2013년 10월 8일 벤치마크 도구를 사용하여 최신 libwebp + ToT 깜박임을 사용하여 계산되었습니다. '탐색으로 시간 디코딩'은 '처음 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 이상이 필요합니다.