이미지 크기 조절

한 번에 축소하면 보기 흉한 이유

브라우저가 큰 이미지를 훨씬 작은 공간에 한 번에 그리면, 원본 픽셀 중 제한된 수만 샘플링하고 나머지는 무시합니다. 샘플 사이에 있던 디테일은 평균되지 않고 버려지며, 그 결과가 에일리어싱입니다. 들쭉날쭉한 대각선, 세밀한 질감의 깜빡임, 노이즈로 변한 글자 같은 것이죠. width 속성만으로 줄인 이미지가 이미지 편집기로 줄인 같은 이미지보다 대개 더 나빠 보이는 이유입니다.

여기서 쓰는 해결책은 이미지를 반복해서 절반으로 줄이고, 마지막 작은 단계만 끝에 처리하는 것입니다. 절반으로 줄일 때마다 픽셀 네 개씩을 평균하므로, 목표 크기에 도달할 즈음에는 모든 출력 픽셀이 그 안의 임의의 한 샘플이 아니라 자신이 나타내는 영역 전체에서 만들어집니다. 그래픽스의 밉매핑과 같은 원리이며, 크게 축소할 때 그 차이는 결코 미묘하지 않습니다.

전문 도구는 Lanczos 같은 필터로 한 걸음 더 나아가, 더 넓은 주변 픽셀에 가중치를 주어 체감 선명도를 조금 더 살립니다. 단계적 절반 축소도 충분히 가까워 사진에서는 차이를 알아보기 어렵고, 휴대폰에서도 즉시 미리 볼 수 있을 만큼 빠르게 동작합니다.

목표 크기 정하기

이미지가 표시될 곳에 맞춰 크기를 정한 뒤 픽셀 밀도를 고려하세요. 페이지에서 폭 800 CSS 픽셀로 보이는 사진이 CSS 픽셀 하나에 기기 픽셀 두 개가 있는 최신 휴대폰이나 노트북에서 선명하게 보이려면 약 1600픽셀이 필요합니다. 2배를 넘으면 눈에 보이는 이득은 거의 없고 파일 크기 비용만 크게 늘어납니다.

여러 기기에 제공하는 페이지라면 여러 크기를 준비하고 srcset 속성으로 브라우저가 고르게 하는 것이 더 좋습니다. 640, 960, 1280, 1920 같은 흔한 폭이면 대부분의 레이아웃을 감당할 수 있습니다. 이메일은 600픽셀 정도로 유지하세요. 문서나 슬라이드는 배치할 크기의 2배에 맞추세요.

목표에 맞추려고 확대하지는 마세요. 확대는 촬영되지 않은 픽셀을 지어낼 뿐이며, 흐린 이미지를 더 크고 더 흐리게 만들고, 아무 이득 없이 파일만 키웁니다. 원본보다 커야 한다면 바꿔야 할 것은 원본입니다.

상한선과 그 이유

파일은 30MB까지, 이미지는 약 1,670만 픽셀까지 받습니다. 대략 4000×4000이거나, 전체 면적이 같은 다른 비율입니다.

이 한도는 임의로 정한 규칙이 아니라 브라우저 canvas의 한계입니다. 특히 iOS의 Safari는 canvas가 차지할 수 있는 면적을 제한하며, 그것을 넘었을 때의 실패 방식이 최악입니다. 오류도 예외도 없이, 모든 것이 잘된 것처럼 빈 흰색 이미지를 돌려줍니다. 그런 일이 없도록 한도를 넘는 이미지는 설명과 함께 거절합니다. 5천만 화소 RAW 내보내기 파일을 줄여야 한다면 데스크톱 이미지 편집기가 알맞은 도구입니다.

일괄 처리를 병렬이 아니라 한 장씩 하는 이유도 같습니다. 디코딩된 이미지는 압축 파일이 아무리 작아도 메모리에서 폭×높이×4바이트를 차지하므로, 큰 이미지 여러 장을 한꺼번에 처리하면 휴대폰 브라우저가 탭을 닫아 버립니다.

크기 조절, 자르기, 압축

셋은 서로 다른 문제를 해결하며, 실제 목표가 파일을 작게 만드는 것일 때 자주 혼동됩니다.

크기 조절은 픽셀 수를 바꾸며, 파일 크기에 가장 효과적인 수단입니다. 효과가 제곱으로 나타나기 때문인데, 폭과 높이를 절반으로 줄이면 픽셀 수는 4분의 1이 됩니다. 원래 크기에서 보이는 것은 달라지지만 프레임 전체는 유지됩니다.

자르기는 프레임 안에 무엇이 들어가는지를 바꿉니다. 이것도 픽셀을 줄이지만 기술적 결정이 아니라 구도에 관한 결정이며, 되돌릴 수 없습니다.

압축은 기존 픽셀을 얼마나 정밀하게 저장할지를 바꾸며, 이미지 변환 도구의 화질 설정이 여기에 해당합니다. 크기는 그대로 두고 충실도를 내주는 대신 용량을 줄입니다.

웹 페이지에 쓰기에 너무 무거운 사진이라면, 먼저 표시 크기로 크기를 조절한 뒤 적당한 화질의 WebP나 JPG로 인코딩하는 순서가 효과적입니다. 뒤의 것만 하면 대개 줄일 수 있는 용량의 대부분을 놓칩니다.

축소에 필터가 필요한 이유

이미지를 줄인다는 것은 출력 픽셀마다 원본의 이 영역을 어떤 색이 대표하느냐는 물음에 답하는 일입니다. 가장 가까운 원본 픽셀 하나만 집고 이웃을 무시하는 방식이 가장 값싼 답이자 가장 나쁜 답인데, 표본 지점 사이에 놓인 디테일이 평균되지 않고 그냥 버려지기 때문입니다. 그리고 버려진 디테일은 원래 사진에 없던 무늬가 되어 되살아납니다.

그것이 에일리어싱이며, 영화에서 마차 바퀴가 거꾸로 도는 것처럼 보이는 현상과 같은 원리입니다. 디테일이 요구하는 것보다 낮은 속도로 표본을 뜨면 디테일이 조용히 사라지는 것이 아니라, 더 낮은 주파수의 거짓 무늬가 되어 이미지 속으로 접혀 들어옵니다. 가는 질감은 일렁이고, 사선은 계단처럼 끊기고, 작은 글자는 잡음으로 변합니다.

해법은 각 출력 픽셀이 대표하는 영역 전체를 평균하는 것이고, 필터마다 그 평균에 주는 가중치가 다릅니다. 박스 평균은 단순하고 결과가 약간 무릅니다. Lanczos는 sinc 기반 곡선으로 더 넓은 이웃에 가중치를 주어 체감 선명도를 더 많이 지키지만, 단단한 경계 근처에 옅은 링잉이 생깁니다. 여기서 쓰는 절반씩 연속 축소는 훨씬 적은 비용으로 그에 가까운 결과를 냅니다.

크기, 화면비, 그리고 자르기

리사이즈는 화면 전체를 그대로 두고 그것을 몇 개의 픽셀로 나타낼지를 바꿉니다. 크롭은 화면 자체를 바꿉니다. 이 둘을 혼동하면 허술하게 만든 사이트에서 흔히 보는 찌그러진 이미지가 나옵니다. 가로로 긴 사진을 정사각형 컨테이너에 밀어 넣으려고 가로세로를 따로 지정한 결과죠.

레이아웃이 고정된 모양을 요구한다면 늘리지 말고 의도를 가지고 잘라 내십시오. CSS object-fit의 cover가 브라우저에서 이 일을 해 주며 장식용 이미지라면 그것으로 충분합니다. 하지만 피사체가 중요한 이미지라면 미리 잘라 두는 편이 무엇을 남길지 통제할 수 있습니다. 자동 중앙 크롭은 단체 사진에서 사람 머리를 어김없이 잘라 냅니다.

한 가지 크롭으로 부족한 경우가 바로 아트 디렉션입니다. 데스크톱에서 잘 작동하는 가로로 긴 히어로 이미지는 휴대폰에서 같은 화면을 줄인 것이 아니라 더 좁은 세로 크롭이 필요한 경우가 많습니다. 미디어 조건을 곁들인 picture 요소가 그것을 위한 것이며, 같은 크롭을 여러 크기로 제공하는 srcset과는 쓰임이 다릅니다.

이미지 용량이 페이지에 치르게 하는 값

이미지는 보통 페이지가 내려받는 것 중 가장 덩치가 크고, 구글이 Core Web Vitals에서 보고하는 지표 가운데 하나인 Largest Contentful Paint도 아주 흔히 이미지입니다. 그 한 파일에 들어간 불필요한 킬로바이트 하나하나가 페이지가 다 로드된 것처럼 보이는 순간을 늦춥니다.

현실적인 예산은 히어로 이미지를 200 KB 안팎으로 유지하고 첫 화면 아래의 것들은 그보다 훨씬 작게 두는 것이며, 크기만 제대로 잡으면 평범한 품질 설정으로도 충분히 가능합니다. 3 MB짜리 사진을 그대로 내보내고 CSS로 줄여 보여 주는 것은 콘텐츠 사이트에서 가장 흔한 성능 문제이며, 방문자의 시간뿐 아니라 데이터 요금까지 축냅니다.

나머지 절반은 레이아웃 안정성입니다. width와 height를 선언하지 않은 이미지는 자리를 잡아 두지 않으므로 이미지가 도착하는 순간 그 아래 글이 튀어 오릅니다. 두 속성을 설정하거나 CSS에서 aspect-ratio를 주는 것은 한 줄짜리 수정이지만, 눈에 보이는 결함 한 갈래를 통째로 없애 줍니다.

많은 이미지를 한꺼번에 줄이기

파일이 몇 개뿐이라면 브라우저 도구가 가장 빠른 길입니다. 수십 개를 넘어가거나 빌드 과정의 일부라면 스크립트로 다룰 수 있는 도구가 낫습니다. ImageMagick의 mogrify -resize 1600x -quality 82 *.jpg는 명령 한 줄로 디렉터리 하나를 처리하고, sharp와 libvips, Pillow는 Node나 Python 파이프라인 안에서 같은 일을 하면서 소문보다 훨씬 적은 메모리만 씁니다.

흔한 사고를 막아 주는 습관이 둘 있습니다. 하나는 사본을 대상으로 작업하는 것입니다. mogrify는 기본적으로 원본을 덮어쓰고 되돌릴 방법이 없습니다. 다른 하나는 고정된 가로세로 대신 1600x처럼 너비만 제한하는 조건을 쓰는 것입니다. 그래야 세로 사진과 가로 사진이 모두 왜곡 없이 처리됩니다.

사용자 업로드를 받는 사이트라면 리사이즈는 요청마다가 아니라 받아들이는 시점에 한 번만 해야 하며, 나중에 다른 크기가 필요할 수 있다면 원본을 보관해 둡니다. 이미지 CDN을 통해 필요할 때 크기를 파생시키는 것도 합리적인 구조입니다. 페이지 안에서 CSS로 줄이는 것은 합리적이지 않은데, 어느 쪽이든 전체 파일은 이미 내려받아지기 때문입니다.

확대, 그리고 AI 도구가 바꾼 것

이미지를 키운다고 애초에 담기지 않은 디테일이 되살아나지는 않습니다. 쌍선형, 바이큐빅, Lanczos 같은 고전적 보간은 같은 정보로 매끄럽고 더 큰 이미지를 만들어 내며, 그것이 물러 보이는 이유는 실제로 무르기 때문입니다. 알고리즘의 결함이 아니라 정보가 정말로 없는 것입니다.

머신러닝 업스케일러는 이전에 본 것을 바탕으로 그럴듯한 디테일을 지어내어 더 선명한 결과를 만듭니다. 배경화면이나 여행 사진 인화라면 대개 그것이 바로 원하는 바입니다. 하지만 증거로 쓰이는 것, 이를테면 문서 스캔본이나 고객이 믿고 판단할 제품 사진, 보도 기사에 실리는 이미지라면 심각한 문제가 됩니다. 덧붙여진 디테일은 추측인데도 진짜 픽셀과 똑같은 확신을 띠고 제시되기 때문입니다.

믿을 만한 원칙은 늘 같습니다. 원본을 고치십시오. 원본 파일에서 다시 내보내거나, 더 높은 해상도로 다시 스캔하거나, 필요한 크기로 소재를 다시 받으십시오. 그 밖의 모든 방법은 지어낸 재료로 하는 수선입니다.