Windows에서 오프라인으로 JPG를 WebP로 변환하는 방법

용량이 큰 사진은 나머지 디자인이 제 역할을 하기도 전에 웹페이지를 느리게 느껴지게 할 수 있습니다. JPG를 WebP로 변환하면 방문자가 다운로드하는 이미지 바이트 수를 줄일 수 있지만, 중요한 질문은 WebP가 최신 형식인지가 아닙니다. 변환한 WebP가 실제로 더 작고, 보기에도 만족스러우며, 웹사이트에서 올바르게 제공되는지가 중요합니다.

Windows 11의 LocalFlux에서는 하나 이상의 JPG 파일을 추가하고 WebP를 선택해 이미지를 온라인 서비스로 보내지 않고 변환할 수 있습니다.빠른 결과를 열고웹사이트용으로 준비를 선택합니다.

인터페이스 스크린샷은 문서에 기록된 LocalFlux 1.0.10.0 릴리스 소스로 재구성한 빌드를 사용해 2026년 10월에 다시 촬영했습니다. 기존 측정값과 다운로드 자료는 원래 테스트 범위를 유지합니다. 촬영 기록: 1

테스트한 웹사이트 이미지 일괄 작업은 로컬에서 완료되었습니다. WebP 파일 3개는 LocalFlux에 표시된 JPG 입력보다 각각 66%, 67%, 75% 작았습니다. 이 측정치는 이 테스트 파일 세트에 관한 결과이지, 모든 WebP에 보장되는 수치가 아닙니다.

적합한 용도: 다운로드 용량이 중요한 랜딩 페이지, 글 이미지, 제품 페이지, 포트폴리오 및 기타 웹 게시 작업에 사용하는 사진형 JPG.

JPG 원본 보관: 이 WebP 작업은 손실 인코딩을 한 번 더 수행합니다. JPG 압축으로 이미 사라진 세부 정보를 복원할 수 없으며, 소스 파일은 편집용 및 대체용 사본으로 보관하는 편이 더 안전합니다.

2026년 10월 13일 재확인: 재구성한 1.0.10.0의 웹사이트 설정으로 생성한 출력 30개의 해시가 과거 웹용 WebP와 일치했습니다. 아래 표와 직접 변환 다운로드는 1.0.7 비교 결과입니다. 직접 변환 출력은 다시 생성하지 않고 디코딩과 재측정을 진행했습니다. 세 이미지의 픽셀 크기는 유지됐습니다. EXIF가 있다고 모든 필드가 보존됐다는 뜻은 아닙니다. 파일 검증

요약

1. Windows 11에서 LocalFlux를 엽니다.
2. 하나 이상의 .jpg 또는 .jpeg 파일을 추가합니다.
3. 변환을 선택한 상태로 두고 출력 형식으로WebP를 선택합니다.
4. 빠른 결과를 열고웹사이트용으로 준비를 선택합니다.
5. 대규모 일괄 작업을 실행하기 전에 크기 조정과 품질 설정을 확인합니다.
6. 변환을 선택합니다.
7. 새 WebP 파일을 열어 세부 영역을 JPG와 비교하고 실제 바이트 수를 측정합니다.
8. 호환성 요구 사항에 따라 명시적인 크기와 JPG 대체 파일을 함께 지정해 WebP를 게시합니다.

Microsoft Store에서 LocalFlux를 받거나 시작하기 전에 현재 지원되는 형식과 변환 경로를 확인하세요.

JPG를 WebP로 변환하면 웹사이트에 도움이 되는 이유

이미지 요청은 대역폭을 사용하고 페이지의 다른 요소와 경쟁합니다. 바이트 수가 적으면, 특히 느린 휴대전화나 네트워크에서 전송 시간이 짧아질 수 있습니다. 그렇다고 확장자만 바꾸면 자동으로 성능이 좋아지는 것은 아닙니다. 인코딩 결과, 표시 크기, 캐싱, 반응형 변형, 요청 우선순위, 페이지 내 위치가 모두 영향을 줍니다.

Google의 이미지 형식 안내는 적절한 품질 대비 용량 결과를 제공하는 경우 WebP나 AVIF 같은 최신 형식을 사용하되, 필요할 때는 이전 형식 경로도 유지하도록 권장합니다. Google 검색의 이미지 SEO 안내 역시 특정 형식을 순위 상승의 지름길로 취급하기보다 고품질 이미지와 속도를 강조합니다.

JPG와 손실 WebP는 모두 사진 콘텐츠의 전송 형식입니다. WebP의 실질적인 장점은 만족할 만한 시각적 품질을 유지하면서 더 작은 전송용 사본을 만드는 데 있습니다. 품질이 낮은 JPG를 다시 선명하게 만드는 데 있지 않습니다. JPG가 미세한 질감을 버리거나 가장자리 주변에 링잉을 만든 뒤에는, 트랜스코딩으로 남아 있는 픽셀만 다시 인코딩할 수 있습니다.

흔히 혼동되는 다음 세 가지 작업도 구분해야 합니다.

작업	관련 동작
브라우저 전송 형식 변경	JPG를 WebP로 변환
지나치게 큰 픽셀 크기 축소	레이아웃에 실제로 표시되는 최대 크기로 조정
위치, 기기, 작성자 또는 날짜 메타데이터 제거	지원되는 메타데이터 제거 작업을 사용하고 사본 검증

웹사이트용으로 준비 템플릿은 앞의 두 작업을 보수적으로 결합하지만,안전하게 공유를 활성화하지 않으며 목표 바이트 수를 보장하지도 않습니다.

테스트에 사용한 파일

이 안내에서는 C:\tmp\LocalFluxJpgToWebPBlog에 있는 권리 문제가 없는 JPG 3개를 사용합니다.

• 1440 × 960 크기의 산 풍경 사진
• 1320 × 940 크기의 LocalFlux 인터페이스 스크린샷
• 1920 × 1080 크기의 LocalFlux 홍보 이미지

사진은 자연스러운 질감과 그라데이션을 테스트합니다. 인터페이스 캡처는 작은 글자와 선명한 가장자리를 테스트하는데, 이런 부분에서는 두 번째 손실 인코딩이 더 눈에 띌 수 있습니다. 홍보 이미지는 넓고 평평한 영역과 섬세한 그라데이션을 테스트합니다. 세 파일 모두 불투명하므로, 이 글에서는 PNG-WebP 안내의 투명도 및 그래픽 중심 조언을 반복하지 않습니다.

입력 파일은 사진, 선명한 UI 콘텐츠, 넓은 웹사이트형 히어로 이미지를 포함합니다. 중립적인 작업 경로와 저장소에서 관리하는 미디어를 사용해 개인 Windows 계정이나 고객 자산이 노출되지 않도록 했습니다.

과거 비교 이미지입니다. 영어 UI는 테스트 이미지의 내용이며 현재 변환 절차가 아닙니다. “KB” 수치는 이진 단위(KiB)입니다.

1단계: JPG 파일 추가

JPG 파일을 LocalFlux로 끌어다 놓거나 파일 추가를 선택합니다. 변환하기 전에 대기열의 각 행에JPG → WebP가 표시되는지 확인하세요. 일괄 작업에서는 하나의 출력 형식과 하나의 시각적 설정 세트를 사용하므로, 필요한 전송 크기나 품질 수준이 다르면 파일을 서로 다른 작업으로 나누세요.

일괄 작업 전체에 대해 WebP를 한 번 선택합니다. LocalFlux는 JPG 파일을 대체하지 않고 소스 옆에 새 사본을 저장합니다.

익숙하지 않은 이미지 모음이라면 전체 보관함 대신 대표적인 일부 파일로 시작하세요. 세부 묘사가 많은 사진, 컬렉션에 인물이 있다면 얼굴, 그라데이션, 글자나 로고가 있는 이미지를 포함하세요. 나뭇잎에서 괜찮아 보이는 품질 설정이 글자에서는 지나치게 부드러울 수 있습니다.

2단계: 직접 변환 또는 웹사이트 템플릿 선택

유용한 시작점은 두 가지입니다.

직접 변환은 크기를 원래 값으로 유지하고 인코더의 기본 품질 동작을 사용하면서 형식만 WebP로 바꿉니다. 형식 변경의 영향만 분리해 유용한 기준 결과를 만들 수 있습니다.

빠른 결과를 열고웹사이트용으로 준비를 선택합니다. 재구성한 1.0.10.0에서는 다음 설정이 적용됩니다.

• 출력: WebP
• 품질: 82%
• 크기 조정 규칙: 긴 변 1920픽셀 이내에 맞춤
• 종횡비: 잠금
• 확대: 안 함
• 메타데이터 제거: 꺼짐

선택한 결과는 옵션 패널에 표시됩니다. 안전하게 공유는 꺼져 있으며 메타데이터는 유지됩니다.

1920픽셀 규칙은 상한선이지 모든 이미지를 1920픽셀로 늘리라는 명령이 아닙니다. 테스트 파일 3개 중 상한을 넘는 파일은 없었고, 1920 × 1080 히어로 이미지는 이미 정확히 그 상한에 맞았습니다. 따라서 웹사이트 템플릿 출력 3개 모두 JPG 크기를 유지했습니다. 직접 변환보다 더 많이 절감된 것은 크기 조정이 아니라 품질 설정 덕분이었습니다.

3단계: 실제 적용 옵션 확인

옵션을 열고고급 조정을 펼칩니다. 모든 향후 릴리스에서 템플릿 이름이 항상 동일한 구현을 뜻한다고 가정하지 말고 값을 확인하세요.

요약에는 WebP, 최대 1920 × 1920, 품질 82%가 표시됩니다. 웹 사전 설정은 종횡비를 유지하고 확대하지 않습니다. 나머지 설정은 패널 안에서 스크롤해 확인하세요.

품질은 형식을 초월하는 보편적인 척도가 아닙니다. 한 WebP 인코더의 값 82가 다른 도구의 품질 82와 같다고 보장할 수 없으며, 특정 바이트 수를 약속하지도 않습니다. 이 작업 과정 안에서 재현 가능한 시작점으로 사용하세요. 통념에 따라 숫자를 고르기보다 결과를 비교하세요.

레이아웃에서 이미지를 너비 800픽셀로만 표시한다면 1920픽셀 파일은 여전히 불필요하게 클 수 있습니다. 실제로 렌더링되는 최대 크기에 맞추거나 여러 레이아웃 너비에 사용할 반응형 변형을 만드세요. 반대로 파일 크기 비교에서 이기려고 필요한 고밀도 디스플레이 크기보다 소스를 작게 축소하지 마세요.

4단계: 변환하고 사본 검토

3 파일 변환을 선택합니다. LocalFlux는 별도 이름의 .webp 파일을 만들고 JPG는 그대로 둡니다. 완료 후 브라우저에서 출력 파일을 열어 100% 배율로 확인하세요. 다음 부분을 자세히 살펴보세요.

• 머리카락, 나뭇잎, 직물 및 기타 미세한 질감
• 작은 글자와 1픽셀 인터페이스 선
• 대비가 높은 가장자리 주변의 후광이나 링잉
• 하늘과 어두운 그라데이션의 밴딩
• 색상과 방향
• 기록된 정확한 크기와 바이트 수

이미지 비교표만 보고 판단하지 마세요. 아래 표시 크기에서는 쌍들이 비슷해 보입니다. 원래 크기에서는 웹사이트 WebP가 2세대 손실 사본이기 때문에 가장 까다로운 미세 디테일과 인터페이스 영역이 눈에 띄게 조금 더 부드럽습니다. 전송용으로는 합리적인 절충일 수 있지만, JPG는 소스 또는 대체 파일로 남겨 두어야 합니다.

웹사이트 WebP 3개 모두 원래 크기를 유지했으며 이 테스트에서 훨씬 작았습니다. 이 비교는 픽셀이 동일하거나 변환이 무손실이라고 주장하지 않습니다.

측정 결과

직접 변환과 웹사이트 템플릿 작업에는 동일한 소스 파일 3개와 동일하게 패키징된 LocalFlux 1.0.7 빌드를 사용했습니다.

테스트 파일	JPG 입력	직접 WebP	직접 변환 변화	웹사이트 WebP	웹사이트 변화	크기
산 사진	274,913바이트	169,980바이트	38.2% 작음	92,448바이트	66.4% 작음	1440 × 960
LocalFlux UI	126,755바이트	64,626바이트	49.0% 작음	42,334바이트	66.6% 작음	1320 × 940
LocalFlux 히어로 아트	67,861바이트	28,880바이트	57.4% 작음	17,216바이트	74.6% 작음	1920 × 1080
합계	469,529바이트	263,486바이트	43.9% 작음	151,998바이트	67.6% 작음	해당 없음

이 측정에 사용한 정확한 산 JPG, 직접 변환한 산 WebP, 웹사이트용 산 WebP, UI JPG, 직접 변환한 UI WebP, 웹사이트용 UI WebP, 히어로 아트 JPG, 직접 변환한 히어로 아트 WebP, 웹사이트용 히어로 아트 WebP가 인계 자료에 포함되어 있습니다.

웹사이트 템플릿 일괄 작업은 직접 WebP 일괄 작업보다 합계 기준 42.3% 작았습니다. 그렇다고 품질 82가 모든 사이트에 적합하다는 뜻은 아닙니다. 웹사이트에 맞춘 품질 결정이 WebP를 선택하는 것만큼 중요할 수 있음을 보여 줍니다.

번들 검사 도구는 모든 출력을 예상 크기의 유효한 불투명 정적 WebP 파일로 보고했습니다. 산 JPG에서는 EXIF 프로필이 발견되었고, 직접 변환 및 웹사이트 템플릿 WebP에서도 모두 EXIF 프로필이 발견되었습니다. 다른 두 입력과 출력에서는 프로필이 발견되지 않았습니다. 두 작업 후에도 소스 SHA-256 해시는 바뀌지 않았습니다.

이 결과는 의도적으로 테스트 파일에 한정됩니다. 이미 최적화된 JPG는 절감 폭이 더 작거나 전혀 없을 수 있고, 높은 품질 설정에서는 WebP가 오히려 더 커질 수도 있습니다. 출력을 측정하고, 또 다른 사본을 만들 만큼 전송 자산이 충분히 개선되지 않았다면 그 변환을 사용하지 마세요.

백분율을 맥락과 함께 읽기

백분율은 기준값이 보일 때만 유용합니다. 아주 작은 썸네일에서 70%를 줄여도 큰 히어로 이미지에서 20%를 줄인 것보다 절약되는 바이트가 적을 수 있습니다. 이 일괄 작업에서 웹사이트 템플릿은 총 317,531바이트를 줄였습니다. HTTP 압축과 전송 오버헤드를 제외하면 약 310KiB입니다. 산 사진이 가장 큰 소스였으므로 절대적인 감소량의 대부분을 차지했습니다.

또한 파일 크기와렌더링 크기를 구분하세요. 브라우저는 1920 × 1080 파일을 너비 600 CSS 픽셀로 표시할 수 있지만, 반응형 선택이 더 작은 후보를 제공하지 않는 한 전체 인코딩 자산을 다운로드합니다. 반대로 CSS로 600픽셀 파일을 1200픽셀로 늘려도 사라진 디테일은 복원되지 않습니다. 게시 파이프라인에는 적절한 인코딩과 적절한 고유 크기가 모두 필요합니다.

재현 가능한 성능 감사를 위해 원본과 출력 바이트를 기록하고 프로덕션 URL을 확인한 다음, 대표적인 모바일 연결 환경에서 페이지를 테스트하세요. 로컬 파일 크기 비교만으로 일정한 로딩 시간 개선을 주장하지 마세요. 지연 시간, 캐시 상태, 서버 위치, 요청 우선순위, 경쟁 리소스가 모두 방문자의 경험에 영향을 줍니다.

WebP를 올바르게 게시하기

WebP 파일 생성은 작업의 절반에 불과합니다. 페이지에는 여전히 유효한 마크업, 안정적인 레이아웃 크기, 유용한 대체 텍스트, 적절한 대체 파일 정책이 필요합니다.

HTML의 <picture> 요소를 사용하면 브라우저가 지원되는 소스를 선택하면서 <img> 대체 파일도 유지할 수 있습니다.

<picture>
  <source srcset="mountain-photo.webp" type="image/webp">
  <img
    src="mountain-photo.jpg"
    width="1440"
    height="960"
    alt="해 질 무렵 산속 초원"
    decoding="async">
</picture>

여기서 <img>는 적합한 <source>가 없을 때 형식을 선택하는 대체 경로입니다. WebP 요청이 HTTP 404 등으로 실패해도 JPG를 자동으로 다시 요청하지 않습니다. 두 URL을 각각 확인하세요.

선호하는 WebP 소스를 먼저 배치하고 <img> 요소를 마지막에 두세요. width와 height 특성은 다운로드 전에 이미지 종횡비를 브라우저에 알려 레이아웃이 올바른 공간을 확보하도록 돕습니다. CSS로 렌더링된 이미지를 반응형으로 만들 수 있습니다.

img {
  max-width: 100%;
  height: auto;
}

디자인에서 의미 있게 다른 너비를 제공한다면 실제 변형을 만들고 srcset과 sizes를 사용해 좁은 뷰포트가 데스크톱 크기 파일을 다운로드하지 않도록 하세요. 여러 너비 설명자가 동일한 실제 이미지를 가리키는 srcset을 만들지 마세요.

스크롤해야 보이는 이미지에는 기본 loading="lazy"를 사용해 이미지가 뷰포트에 가까워질 때까지 작업을 피할 수 있습니다. 첫 화면에 있을 가능성이 높은 히어로 이미지나 Largest Contentful Paint 이미지는 지연 로드하지 마세요. web.dev의 브라우저 수준 지연 로딩 안내는 첫 뷰포트에 보이는 이미지를 지연시키면 오히려 렌더링이 늦어질 수 있으므로 즉시 로드하도록 권장합니다.

마지막으로 서버나 정적 호스트가 WebP를 image/webp로 보내도록 구성하고, 버전이 지정된 자산에는 수명이 긴 캐시 헤더를 사용하며, 브라우저 개발자 도구에서 프로덕션 응답을 확인하세요. 잘못된 MIME 유형, 깨진 URL, 캐시 정책 부재가 있는 완벽하게 인코딩된 파일은 최적화가 끝난 것이 아닙니다.

이미지 게시가 끝났다고 보기 전에 다음 간단한 프로덕션 체크리스트를 확인하세요.

• WebP URL이 성공적으로 응답하고 image/webp로 보고됨
• JPG 대체 URL도 정상적으로 응답함
• 렌더링된 종횡비가 파일 크기와 일치함
• 모바일 레이아웃이 적절한 크기의 후보를 받음
• 히어로 이미지가 지연되지 않고 일찍 요청됨
• 스크롤해야 보이는 이미지가 시작 시 중요 콘텐츠와 모두 경쟁하지 않음

메타데이터와 개인정보 보호는 별개의 문제

WebP로 변환한다고 사진이 자동으로 정리되지는 않습니다. 안전하게 공유가 꺼져 있었으므로 EXIF가 있는 산 이미지는 테스트한 두 작업 모두에서 EXIF 프로필을 유지했습니다. 이는 웹사이트 템플릿의 표시 요약과 일치합니다. 메타데이터가 유지됩니다.

이미지를 공개적으로 게시할 때 포함된 위치, 기기, 작성자 또는 날짜 정보가 우려된다면 지원되는 메타데이터 제거 작업을 사용하고 이후 출력을 검사하세요. 형식 변경과 비공개 메타데이터 제거의 차이는 파일 변환으로 EXIF 메타데이터가 제거되나요?에서 확인할 수 있습니다.

메타데이터를 제거하면 바이트가 조금 줄어들 수 있지만, 개인정보 보호는 숨겨진 성능 기법이 아니라 명시적인 게시 결정이어야 합니다. 법률, 편집, 접근성 또는 자산 관리 작업에 실제로 필요한 메타데이터는 유지하세요.

통제력을 잃지 않는 일괄 변환

LocalFlux는 준비된 행마다 하나의 출력을 저장합니다. 실패하거나 손상된 파일은 모든 .jpg 확장자가 정상적인 JPEG를 뜻한다고 가정하지 말고 개별적으로 검토해야 합니다. 더 폭넓은 이미지 라이브러리 작업은 Windows에서 이미지를 일괄 압축하는 방법을 참조하세요.

JPG가 여전히 더 나은 선택일 때

JPG가 이미 충분히 작거나, 필요한 대상에서 WebP를 받지 않거나, 다른 WebP 사본이 의미 있는 바이트 감소 없이 운영 복잡성만 늘린다면 JPG를 계속 제공하세요. 현재 주류 브라우저가 WebP를 지원하더라도 오래된 내장 웹뷰, 이메일 클라이언트, 콘텐츠 수집 시스템 또는 후속 도구를 위해 대체 파일이 유용할 수 있습니다.

편집 과정에서 JPG를 WebP로 변환했다가 다시 JPG로 바꾸지 마세요. 반복적인 손실 인코딩은 손상을 누적합니다. 가능한 최상의 소스에서 편집하고 게시 파이프라인 끝 무렵에 전송 자산을 한 번 생성하세요.

로고, 아이콘, 투명 누끼, 선명한 도표에는 필요한 가장자리와 알파 채널을 보존하는 소스 형식으로 시작하세요. 해당 작업은 기존 PNG-WebP 안내에서 다룹니다. WebP 파일을 열고 변환하는 방법을 더 폭넓게 알아보려면 WebP 활용 가이드를 참조하세요.

자주 묻는 질문

WebP는 항상 JPG보다 작아지나요?

아니요. 테스트한 이미지 3개는 모두 작아졌지만, 콘텐츠, 소스 품질, 출력 품질, 크기, 프로필, 인코더 동작에 따라 결과가 달라집니다. 실제 바이트를 비교하세요.

JPG를 WebP로 변환하면 이미지 품질이 좋아지나요?

아니요. 손실 WebP는 효율적인 전송용 사본이 될 수 있지만 JPG에서 이미 버려진 디테일은 복원할 수 없습니다. 인코딩을 한 번 더 거치므로 게시 전에 미세한 부분을 확인하세요.

웹사이트 템플릿이 이 파일들의 크기를 조정했나요?

아니요. 입력 파일 3개 모두 긴 변 1920픽셀 상한 이하였습니다. 크기는 1440 × 960, 1320 × 940, 1920 × 1080으로 유지되었습니다.

변환하면 EXIF 메타데이터가 제거되나요?

그렇다고 가정하지 마세요. EXIF가 있는 산 JPG와 테스트한 WebP 출력 2개 모두 EXIF 프로필이 발견되었습니다. 메타데이터 제거는 꺼져 있었으며 별도로 검증된 단계로 처리해야 합니다.

원본 JPG를 덮어쓰나요?

이 작업에서는 아닙니다. LocalFlux는 소스 옆에 새 WebP 사본을 저장했고, 변환 후 JPG 3개의 해시는 변환 전 해시와 일치했습니다.

모든 웹사이트에서 JPG 대체 파일을 사용해야 하나요?

꼭 그렇지는 않습니다. 현재 주류 브라우저는 WebP를 지원하지만, 사용자 중 오래된 웹뷰나 브라우저가 아닌 시스템을 사용하는 사람이 있을 수 있습니다. 호환성 정책에서 요구한다면 <picture> 패턴으로 간단하게 대체 파일을 제공할 수 있습니다.

WebP만 사용하면 페이지가 빨라지나요?

아니요. 적절한 크기의 반응형 이미지, 명시적인 크기, 효과적인 캐싱, 합리적인 로딩 우선순위를 함께 사용하세요. 이미지 형식은 전송 성능의 한 부분일 뿐입니다.

WebP를 만들고 측정한 다음 게시하세요

안정적인 작업 과정은 간단합니다. JPG를 보존하고, WebP 전송용 사본을 로컬에서 만들고, 원래 크기로 결과를 비교한 다음, 프로덕션 페이지가 올바른 자산을 제공하는지 확인하세요. 이 테스트에서 웹사이트용 일괄 작업은 이미지 크기를 조정하지 않고 입력 469,529바이트를 151,998바이트로 줄였습니다. 측정된 절감치는 유용한 증거이며, 원본 보관과 정직한 품질 검토가 이 작업을 안전하게 만듭니다.

Microsoft Store에서 LocalFlux를 받거나 지원되는 형식과 변환 경로를 확인하세요.