앞 두 편은 얼마의 GB를 아꼈고, 얼마의 돈을 절약할 수 있는지를 계산한 것입니다. 이번 글은 계산표에 관한 이야기가 아닙니다. 사진가들이 진짜로 궁금해하는 질문 하나에만 집중합니다: ImgZilla에 JPEG 한 장을 넘기면 정확히 어떤 변화가 일어나는지, 그리고 이러한 변화가 Lightroom / Photoshop / Capture One에서 어떤 대가를 치르게 되는지에 대해 다룹니다. 데이터는 앞 두 편과 동일한 32,188장의 카메라/모바일 직출 JPEG 테스트 데이터와, 그중 200쌍 이상의 파일을 바이트 단위로 비교한 결과에서 나왔습니다.
1단계: 가장 날카로운 질문에 대한 답: 비트 깊이(bit depth)가 잘렸나?
사진계에서 '압축'에 대한 가장 흔한 우려는 내 12비트, 14비트가 8비트로 깎여버리지는 않을까입니다.
이 우려는 대상을 잘못 잡았습니다. 두 가지를 분리해야 합니다:
- 색상 비트 깊이(bit depth): 각 색상 채널이 몇 비트로 기록되는지입니다. 8비트 = 채널당 256단계, 14비트 = 16384단계입니다. 비트 깊이는 후반 작업에서 어둠 부분이나 하늘을 얼마나까지 밀어 올릴 수 있는지를 결정합니다.
- 파일 밀도(비트/픽셀, bpp): 파일 크기 ÷ 픽셀 수입니다. 앞편에서 bpp(비트/픽셀)별로 나누어 보았습니다—이것은 '이미지의 한 픽셀이 얼마의 바이트를 사용해 저장되는가'를 측정하는 것으로, 압축의 대상이며 색상 비트 깊이와는 별개입니다.
ImgZilla는 후자(밀도)를 압축하지만 전자(비트 깊이)는 건드리지 않습니다. 또한 JPEG의 경우 비트 깊이 문제는 본질적으로 존재하지 않습니다:
샘플링한 209쌍의 원본/압축 이미지에서 JPEG의 SOF 마크를 바이트 단위로 읽은 결과, 압축 전후의 정확도는 모두 8비트입니다.
이유는 간단합니다—베이스라인 JPEG은 표준으로 정의된 각 채널 8비트입니다. 카메라에서 직출하는 JPEG는 12비트라는 말이 없으며, ImgZilla가 '낮추기'할 대상도 없습니다.
그렇다면 12/14비트 데이터는 어디에 있나? RAW 파일에만 있습니다. ImgZilla가 지원하는 형식은 gif / png / jpg / jpeg / svg / heic / heif / webp / avif입니다—어떤 RAW 형식도 포함되어 있지 않습니다(CR2, CR3, NEF, ARW, RAF, DNG은 모두 목록에 없으며, 드래그 앤 드롭하면 무시됩니다). 디지털 필름 자체가 프로세스에 진입하지 않으므로 자연스럽게 안전합니다.
이 절의 결론: JPEG는 낮출 비트 깊이가 없으며, 8비트 입력 8비트 출력입니다. RAW는 건드려지지 않습니다. 비트 깊이는 이 글에서 걱정할 사항이 아닙니다—진짜 중요한 것은 아래 두 절입니다.
2단계: 정확히 무엇이 바뀌었나: 완전한 손실 재인코딩
ImgZilla가 JPEG를 처리하는 방식은 '원본 파일에서 무손실 최적화를 하는 것'이 아니라, 이미지를 전부 디코딩한 뒤 다시 인코딩하는 것입니다. 완전한 프로세스는 다음과 같습니다:
JPEG 읽기
→ 8비트 RGB 픽셀로 디코딩
→ 다시 YCbCr로 변환
→ 고정된 양자화 테이블로 다시 양자화(유효 품질 약 70)
→ 최적의 Huffman 테이블 다시 계산
→ 프로그레시브 JPEG로 출력
이 과정에서 '다시 양자화' 단계가 손실을 일으킵니다. 양자화 테이블이 거칠수록 손실되는 고주파 디테일이 많아지고 파일 크기가 작아집니다. 샘플링된 파일의 양자화 강도(양자화 단계의 합, 숫자가 클수록 양자화가 더 세다)로 측정해 보면:
| 양자화 테이블 강도(중앙값) | |
|---|---|
| 카메라/모바일 직출 원본 | 1858 |
| ImgZilla 압축 후 | 6852 |
양자화 강도는 원본의 약 3.7배입니다. 이것은 실제로 두 번째 양자화입니다—'무손실 재배열'이 아니라 고주파 정보를 다시 한 번 버린 것입니다.
두 가지는 변하지 않습니다:
- 해상도가 한 픽셀도 변하지 않습니다. 전체 32,188장의 이미지에서
dimensions_changed필드를 통계한 결과, 예외 없이false입니다. ImgZilla는 크기를 줄이지 않고, 자르지 않으며, 저장되는 공간은 모두 재인코딩 때문입니다. - 비트 깊이는 변하지 않습니다(위 절 참조), 8비트 입력 8비트 출력입니다.
한 가지는 변했지만 화질에는 영향을 주지 않습니다: 출력은 프로그레시브 JPEG(원본은 대부분 베이스라인)입니다. 프로그레시브는 웹 로딩 경험에 더 좋지만 화질에는 아무런 대가가 없으며, Lightroom / Photoshop / Capture One 모두에서 정상적으로 읽을 수 있습니다—오래된 소프트웨어 몇 개만 인식하지 못할 수 있습니다.
3단계: 후반 작업에 가장 큰 영향을 미치는 항목: 크로마 서브샘플링이 강제로 4:2:0으로 내려감
이것이 이 글 전체에서 사진가가 알아야 할 가장 중요한 사항 중 하나입니다.
JPEG는 공간을 절약하기 위해 '크로마 서브샘플링'을 사용합니다—인간의 눈은 밝기에 민감하고 색상 분해력에는 덜 민감하므로, 색상 정보의 분해력을 밝기보다 낮게 할 수 있습니다:
- 4:4:4: 색상과 밝기가 동일한 분해력, 색상 정보가 가장 완전합니다.
- 4:2:2: 색상 수평 방향 절반. 많은 카메라 및 일부 모바일의 직출 JPEG가 이를 사용합니다.
- 4:2:0: 색상 수평, 수직 방향 모두 절반, 밝기의 1/4 분해력입니다. 대부분 '용량 최적화'된 JPEG가 이를 사용합니다.
209쌍의 파일을 샘플링하여 압축 전후의 크로마 서브샘플링을 확인했습니다:
| 크로마 서브샘플링 | 원본 | ImgZilla 압축 후 |
|---|---|---|
| 4:4:4 | 1 | 0 |
| 4:2:2 | 128(61%) | 0 |
| 4:2:0 | 80(38%) | 209(100%) |
압축 후 100%가 4:2:0입니다. 그중 61%의 이미지는 4:2:2에서 떨어진 것—색상 수직 분해력이 절반으로 줄어들며, 되돌릴 수 없습니다.
이것이 후반 작업에서 어떻게 나타나나?
색상 분해력이 낮아지면, 편집하지 않은 이미지를 눈으로 직접 보면 대부분의 경우 차이를 알아차리지 못합니다. 문제는 편집을 할 때 발생합니다:
- 색상 보정 / 분리 톤: 채도 높이기, HSL 조절, 컬러 그레이딩을 할 때 색상 블록의 경계가 드러나기 시작합니다. 특히 피부의 명암 전환, 하늘에서 지평선까지의 그라데이션과 같은 넓은 평면 영역에서 더 두드러집니다.
- 색상 기반 선택 영역 / 마스크 / 키잉: Lightroom의 색상 범위 마스크, Photoshop의 색상 범위, 초록색 키잉 등—이들은 모두 색상 가장자리의 정밀도를 사용합니다. 4:2:0 이후 가장자리가 거칠어지고 울퉁불퉁해집니다.
- 고 대비의 컬러 테두리: 붉은-검은 글자, 네온사인, 나무가지 역광—4:2:0은 이러한 부분에서 컬러 '넘침'을 남깁니다.
누적 효과
유효 품질 약 70 + 4:2:0은 본질적으로 '상대적으로 압축된' 작업 포인트입니다. 원본 품질 92, 4:2:2였던 이미지가 후반 작업에서 견딜 수 있는 푸시/풀 범위는, 동일한 이미지가 품질 70, 4:2:0으로 압축된 후보다 훨씬 큽니다. '압축 후 편집하고 다시 저장'까지 합치면—두 번의 손실 재인코딩이 겹쳐집니다.
이 항목이 무의미한 경우
만약 원본이 이미 4:2:0인 경우(많은 중저가 모바일, 오래된 기기의 직출 및 이미지가 웹 최적화된 경우), ImgZilla의 재인코딩은 색상 측면에서 추가 손실을 주지 않습니다—이미지를 비슷한 작업 포인트로 수렴시킬 뿐입니다. 이것이 이러한 이미지의 압축률이 낮은 이유이기도 합니다(6단계 해상도별 분류 참조: iPhone 직출은 70.7%만 절약하며, 더 '비대한' 일반 12MP는 80%를 절약함).
4단계: 메타데이터: EXIF / XMP / ICC 모두 손실
ImgZilla는 기본적으로 메타데이터를 제거합니다. 209쌍의 파일을 샘플링하여 비교했습니다:
| 메타데이터 | 원본 포함 | 압축 후 보존 |
|---|---|---|
| EXIF(촬영 파라미터) | 204 | 0 |
| XMP(평점/키워드/저작권) | 134 | 0 |
| ICC(색상 프로필) | 2 | 0 |
각 항목별로 손실되는 내용을 명확히 합니다:
- EXIF: 조리개, 셔터, ISO, 초점 거리, 렌즈 모델, 바디 모델, 촬영 시간, GPS 좌표, 저작권 필드—모두 사라집니다. 그룹웨어 카탈로그, 촬영 파라미터로 복기, 또는 파일과 함께 저작권 정보를 가져가야 하는 사진가에게 이는 치명적인 결함입니다.
- 방향 마크(EXIF Orientation): 이 항목은 별도로 언급합니다. 이것은 표시에 직접적인 영향을 미치기 때문입니다. 많은 카메라와 오래된 모바일은 '픽셀을 물리적으로 회전하지 않고 방향 마크만 기록'합니다. 마크가 제거되면 세로 촬영 사진이 일부 소프트웨어에서 가로로 표시됩니다—libjpeg 재인코딩 시 픽셀을 자동으로 올바른 방향으로 바꿔주지 않습니다. 현대 플래그십 모바일 대부분은 이미 물리적 회전 + 마크 정리가 되어 있어 영향이 없습니다. 하지만 카메라를 사용하거나 오래된 기기를 사용하는 경우, 압축 전에 확인하는 것이 좋습니다.
- XMP: Lightroom / Bridge에서 매긴 별점, 깃발, 키워드, 제목, 저작권 선언—파일에 기록된 XMP(사이드카 파일이나 카탈로그 DB가 아닌 경우)는 압축 후 사라집니다.
- ICC 색상 프로필: 이 샘플에서는 거의 ICC가 내장되어 있지 않았습니다(대부분 표시용 sRGB), 따라서 이번 테스트에서는 이 항목이 거의 발동되지 않았습니다. 하지만 만약 Display P3 또는 Adobe RGB 광역 색상 공정을 사용하여 제공한다면, 내장된 ICC가 제거되어 재생 장치에서는 sRGB로만 해석하게 되어 색상이 차분하거나 오프셋될 수 있습니다. 광역 색상 워크플로는 이 항목에 특히 주의해야 합니다.
설정에 '메타데이터 보존' 옵션이 있지만, 메타데이터가 프로세스에 중요한 경우 가장 안전한 방법은: 메타데이터를 보존해야 하는 이미지는 ImgZilla로 직접 압축하지 말고—원본을 보존하는 것입니다.
5단계: 이러한 대가는 언제 받아들일 수 있나?
위 세 절을 종합하면, ImgZilla가 JPEG를 처리하는 방식은 다음과 같습니다: 8비트 불변, 해상도 불변, 색상을 4:2:0으로 강제 낮춤, 품질을 약 70으로 줄임, 메타데이터 삭제, 대신 평균 -76.8%의 용량 절약.
이 교환은 다음과 같은 상황에서 유리합니다:
- 고객에게 썸네일/작품집을 제공하거나 소셜 플랫폼에 제출. 이러한 이미지는 이미 플랫폼에서 한 번 더 압축될 것이며, 4:2:0 + 품질 70은 순수 시청 환경에서 거의 무의식적이며, 용량은 3분의 1로 줄어듭니다—업로드가 빠르고 로딩이 빠르며, 이미지 호스팅과 CDN 청구서가 낮아집니다(앞 두 편에서 계산함).
- 선별 후 장기 보관해야 하는 JPEG. 기록용으로 남겨두고, 다시 편집할 계획이 없는 이미지.
- 위챗/이메일로 이미지 전송, 동료에게 자료 전달—전송 시간은 용량에 비례하여 크게 단축됩니다.
전제는: 내장 비교 윈도우(⌘D)로 먼저 검사하는 것입니다. ImgZilla는 압축 전/후를 좌우 분할로 보여주며, 실제 픽셀까지 확대하여 각 포인트를 비교할 수 있습니다. 화질에 민감한 사람은 '차이가 없다'는 말을 듣지 말고, 100% 확대하여 가장 중요한 부분—피부, 하늘, 머리카락 가장자리—을 직접 확인하세요.
6단계: 언제 이 도구로 압축하지 말아야 하는가?
- Lightroom / Photoshop / Capture One에서 대폭 조정이 필요한 JPEG—특히 JPEG만 있고 RAW가 없는 이미지인 경우. 이러한 이미지의 각 편집 여유는 귀중하므로 미리 소모해서는 안 됩니다. 원본을 보존하고, 편집이 끝난 후 내보낼 때 압축 버전을 생성하세요.
- EXIF / 저작권 / GPS / 별점 키워드가 포함된 카탈로그 라이브러리가 필요한 경우.
- Display P3 / Adobe RGB 광역 색상으로 제공—ICC가 제거됩니다.
- RAW 파일—이것은 영향받지 않습니다(ImgZilla는 전혀 건드리지 않음), 하지만 이 도구가 RAW를 줄이는 데 도움을 기대해서도 안 됩니다—그것은 그 도구의 영역이 아닙니다.
한 마디로: ImgZilla는 '산출물'을 압축하는 데 적합하지만, '다시 편집해야 하는 중간 자료'를 압축하는 데는 적합하지 않습니다.
7단계: 데이터 부록: 이 32,188장의 직출 JPEG
앞 두 편과 동일한 샘플, 16개 하위 디렉토리, 필터링 없음, 원본 위치 그대로 압축.
전체
| 용량 | 원본 대비 | |
|---|---|---|
| 카메라/모바일 직출 원본 | 99.9 GB | — |
| ImgZilla 압축 후 | 23.1 GB | −76.8% |
평균 2.96 MB → 0.69 MB. 파일별 압축률의 산술평균은 76.6%, 중앙값은 77.3%이며, 전체 바이트를 기준으로 한 76.8%와 거의 일치합니다.
해상도별 분류: 다른 기기에서 남는 공간 차이 큼
| 출력 해상도 | 개수 | 비율 | 파일별 평균 절약 |
|---|---|---|---|
| 4000×3000(일반 12MP, 대부분 안드로이드/카메라) | 19867 | 61.7% | 80.1% |
| 4032×3024(iPhone 주 카메라 12MP 기본) | 3529 | 11.0% | 70.7% |
| 3456×4608(16MP 세로) | 2631 | 8.2% | 76.9% |
| 4608×3456(15.9MP) | 903 | 2.8% | 54.8% |
| 1600×1200 | 257 | 0.8% | 51.4% |
(기기는 출력 해상도를 통해 추정, EXIF 읽기는 아님—압축 데이터에서는 EXIF를 사용할 수 없음.)
같은 도구, 같은 원본, 전혀 건드리지 않은 이미지 중 가장 압축이 잘 되는 그룹(80%)과 가장 안 되는 그룹(55%)은 25%포인트 차이가 납니다. 차이는 원본 자체에 있습니다. 아이폰의 카메라 JPEG 파이프라인은 더 적극적인 양자화와 더 조인트한 인코딩을 사용하며, 출고 시점에서 이미 합리적인 하한에 가까운 상태입니다. 반면 대부분의 저렴/오래된 기기는 보수적인 고정 양자화 테이블을 사용하여 '비대한' 부분을 아직 건드리지 않았습니다. 더 새로운 대형 밉셋 플래그십 기기일수록 직출 이미지가 더 '마른' 상태로 나오며, 두 번째 압축에 남을 공간이 적습니다—이것은 나쁜 것이 아닙니다. 원본이 그만큼 낭비가 없기 때문입니다.
파일별 분포
| 절약 비율 | 개수 | 비율 |
|---|---|---|
| 90%–100% | 866 | 2.7% |
| 80%–90% | 11375 | 35.3% |
| 70%–80% | 15244 | 47.4% |
| 60%–70% | 3349 | 10.4% |
| 50%–60% | 398 | 1.2% |
| 50% 미만 | 956 | 3.0% |
82.7%의 사진이 70%–90%를 절약합니다. 사분위수별로: 절반 이상은 77% 이상을 절약하며, 최악의 10%도 약 68%를 절약하며, 약 1%(p99)만 40% 미만의 비율을 절약합니다.
극단적인 예
| 원본 | 압축 후 | 절약 | |
|---|---|---|---|
| 최고 압축 비율 | 3.55 MB(4000×3000) | 100 KB | 97.2% |
| 한 장당 최대 절약 | 17.9 MB(4000×3000) | 1.13 MB | 16.8 MB |
| 최소 절약 | 70 KB(1242×1242) | 68.8 KB | 2.1% |
8단계: 데이터 및 테스트 설명
- 샘플 범위: 전체 압축률, 해상도별 분류, 파일별 분포 수치는 이 32,188장의 카메라/모바일 직출 JPEG 테스트에서 나왔으며, 이 샘플 그룹의 결과를 반영합니다. 이것이 'ImgZilla가 평균 76.8%를 압축한다'는 것을 의미하지 않습니다. 다른 카메라, 기기, 내보내기 설정에 따라 결과는 다를 수 있습니다.
- 샘플 선택: 전체 파일은 필터링이나 클리닝 없이 원래의 16개 하위 디렉토리별로 전체 압축되었습니다.
- 기기归属: 해상도별 분류의 기기 판별은 출력 해상도를 기반으로 추정했으며, EXIF를 읽지 않았습니다(압축 후 데이터에서는 더 이상 EXIF를 사용할 수 없음). 동일한 해상도도 다양한 기기에서 올 수 있습니다.
- 바이트 비교는 샘플링: 크로마 서브샘플링, 비트 깊이, 양자화 테이블, 메타데이터에 대한 결론은 무작위 추출된 209쌍의 원본/압축 이미지를 바이트 단위로 JPEG 마크를 분석한 결과에서 나왔습니다. 이것은 샘플링 기준이며, 전체 32,188장에 대한 것은 아닙니다.
- 통계 기준: 전체 76.8%는 '총 절약 바이트 ÷ 총 원본 바이트'입니다. 파일별 압축률의 산술평균 76.6%, 중앙값 77.3%는 본문에 이미 나와 있습니다. 용량 단위는 1 GB = 10⁹ 바이트로 환산합니다.
- 압축 파라미터: 파라미터는 고정되어 있으며, UI에 품질/샘플링 슬라이더가 없습니다. 이것은 설계적 선택입니다—파라미터는 시각적으로 손실 없는 구간의 균형점에 조정되었습니다. 직접 품질/샘플링을 수동으로 조절하는 사진가에게 이 점에 유의해야 합니다.
- '시각적 무손실'은 '무손실'이 아님: 진정한 무손실(픽셀이 완전히 동일)은 PNG와 SVG뿐입니다. JPEG는 손실 재인코딩이며, 파라미터는 눈에 거의 구별되지 않는 구간에 선택되었습니다. 내장 비교 윈도우를 통해 픽셀별로 확인할 수 있습니다.
- 실행 환경: 전 과정은 로컬에서 완료되었으며, 이미지는 인터넷에 연결되지 않으며 업로드되지 않습니다(App Store 구매 확인 제외).
직접 검사해 보시겠습니까? ImgZilla 무료 버전은 하루 10장까지 압축 가능하며, 성공 시에만 할당량이 차감됩니다. 가장 까다로운 몇 장의 이미지—인물, 하늘, 역광 머리카락—을 압축하여 비교 윈도우로 100% 확대하여 직접 확인한 후, 전체 라이브러리를 넘길지 결정하세요.
Mac App Store: https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
더 알아보기: https://imagetool.app/ImgZilla
시스템 요구사항: macOS 12.3 또는 그 이상.