이미지 형식 완전 가이드: PNG, JPG, WebP, AVIF, SVG

JPG / JPEG  Joint Photographic Experts Group

1992년 Joint Photographic Experts Group이 만든 JPG는 사진을 효율적으로 압축하기 위해 설계됐습니다. 이미지를 8×8 픽셀 블록으로 나눈 뒤 이산 코사인 변환(DCT)을 적용해 각 블록을 주파수의 조합으로 바꾸고, 사람 눈이 잘 못 느끼는 고주파 성분을 버립니다. 그래서 손실 압축입니다. 원본 데이터의 일부는 영영 사라집니다.

사진에 잘 맞는 이유: 사진은 색이 부드럽게 이어지는데, 바로 그런 정보를 JPG가 가장 잘 압축합니다. 품질 80%로 저장한 풍경 사진은 무압축 파일보다 10배 작아지면서도 화면에서는 차이를 알아보기 어렵습니다.

약한 곳: 8×8 블록 방식은 또렷한 경계선, 글자, 색이 균일한 면에서 눈에 띄는 깨짐을 만듭니다. 흰 배경 위의 검은 로고를 JPG로 저장하면 글자 둘레에 회색 얼룩이 생깁니다. 흔히 말하는 "JPEG 아티팩트"입니다. JPG는 알파 채널(투명도)도 지원하지 않습니다.

쓸 때: 웹, 인쇄, 이메일용 사진. 상품 사진, 배너, 블로그 이미지. 색 변화가 많고 투명도가 필요 없는 모든 이미지.

쓰지 말아야 할 때: 로고, 아이콘, 글자가 있는 스크린샷, 배경이 투명한 이미지, 경계가 또렷한 일러스트, 여러 번 다시 편집하고 저장할 이미지.

PNG  Portable Network Graphics

특허 제약이 있던 GIF의 대안으로 1996년에 나온 PNG는 무손실 압축을 씁니다. 어떤 데이터도 버리지 않습니다. DEFLATE 알고리즘(LZ77과 허프만 부호화의 조합)이 픽셀 데이터를 더 효율적으로 재배열할 뿐입니다. 그래서 몇 번을 다시 저장하든 압축을 풀면 원본과 픽셀 단위로 똑같습니다.

알파 채널: PNG는 RGB 외에 픽셀당 네 번째 채널을 지원합니다. 0(완전 투명)부터 255(완전 불투명)까지 불투명도를 조절하는 알파 채널입니다. 덕분에 완전 투명, 반투명, 그리고 어떤 배경 위에서든 매끄럽게 처리된 가장자리가 가능합니다.

PNG-8, PNG-24, PNG-32의 차이: PNG-8은 GIF처럼 최대 256색 팔레트를 씁니다. 단순한 아이콘이나 색 수가 적은 이미지에 알맞습니다. PNG-24는 1600만 색을 모두 쓰되 투명도가 없습니다. PNG-32는 전체 색에 알파 채널까지 더한 것으로, 흔히 말하는 "투명 PNG"가 여기에 해당합니다.

약한 곳: 사진에는 비효율적입니다. 사진을 PNG로 저장하면 같은 사진의 JPG보다 3~10배 커질 수 있습니다. 무손실 압축으로는 사진의 색 변화를 효율적으로 줄일 수 없기 때문입니다.

쓸 때: 배경이 투명한 로고와 아이콘, 글자가 있는 스크린샷, 인포그래픽, 색이 균일한 면이 많은 이미지, 경계가 또렷한 디지털 아트, 손실이 쌓이지 않게 여러 번 편집해야 하는 이미지.

쓰지 말아야 할 때: 웹용 사진(JPG나 WebP를 쓰세요), 용량을 줄여야 하는 이미지, JPG 호환성이 더 나은 이메일 마케팅.

WebP  Web Picture format

구글이 VP8 영상 코덱을 바탕으로 만들어 2010년에 내놓은 WebP는 웹에서 JPG와 PNG를 모두 대신할 후계자를 목표로 했습니다. 사진용 손실 모드(VP8 기반)와 그래픽용 무손실 모드(자체 알고리즘)를 함께 지원합니다. 손실 모드에서는 블록 예측과 적응형 변환을 쓰는데, JPG의 DCT보다 정교한 방식이라 같은 화질에서 파일이 25~35% 작아집니다.

두 세계의 장점을 한 번에: 손실 모드로 사진에서 JPG를 대신하는 동시에, 알파 채널을 갖춘 무손실 모드로 로고와 그래픽에서 PNG도 대신합니다. 보통 20~30% 더 작습니다. JPG와 PNG의 쓰임을 하나로 묶으면서 양쪽 모두에서 더 효율적인 유일한 형식입니다.

2026년 호환성: 크롬, 파이어폭스, 사파리(14부터), 엣지, 오페라가 지원해 웹 사용자의 97% 이상을 덮습니다. 주된 예외는 오래된 메일 클라이언트(특히 Outlook)와 IE11이 남아 있는 기업 내부 시스템입니다.

쓸 때: 사진, 로고, 아이콘, 배너까지 웹에 올라가는 거의 모든 이미지. 요즘 사이트에 업로드하는 이미지의 기본 형식으로 권장됩니다. 구글 PageSpeed Insights도 WebP를 쓸 수 있는 자리에 JPG나 PNG가 있으면 콕 집어 WebP를 권합니다.

쓰지 말아야 할 때: 이메일 마케팅(지원이 들쭉날쭉함), 인쇄물 제작, 유튜브 썸네일(WebP를 받지 않음), 오래된 시스템에서 직접 열게 될 다운로드용 파일.

AVIF  AV1 Image File Format

AVIF는 AV1 영상 코덱에서 나왔습니다. 구글, 모질라, 넷플릭스, 아마존 등이 참여한 Alliance for Open Media가 개발했습니다. 웹 이미지 형식 중 가장 최신이자 기술적으로 가장 앞서 있으며, 많은 경우 같은 화질에서 WebP보다 파일이 20~50% 작습니다. 특히 WebP가 깨짐을 드러내기 시작하는 낮은 품질 구간에서 차이가 큽니다.

이렇게 효율적인 이유: AV1은 WebP의 VP8보다 훨씬 정교한 압축 기법을 씁니다. 화면 내 예측 모드, 크기가 바뀌는 변환, 루프 필터 등이 들어갑니다. 복잡한 사진과 미묘한 그러데이션에서 특히 인상적인 결과가 나옵니다.

인코딩이라는 문제: AVIF로 변환하는 속도는 WebP보다 크게 느립니다. 같은 이미지를 처리하는 데 10배에서 100배까지 걸리기도 합니다. 이미지가 많은 사이트나 빌드 과정에서 이미지 버전을 실시간으로 만들어 내는 환경에서는 이 계산 비용이 무시하기 어렵습니다.

2026년 호환성: 크롬 85 이상, 파이어폭스 93 이상, 사파리 16 이상에서 지원합니다. IE11과 대부분의 메일 클라이언트에서는 쓸 수 없습니다. 지원 범위가 아직 WebP보다 좁으므로, AVIF를 먼저 내보내고 WebP와 JPG로 폴백하도록 구성하는 편이 좋습니다. 이때 쓰는 것이 <picture> 태그입니다.

쓸 때: 1KB를 아끼는 것이 트래픽 비용으로 곧바로 돌아오는 대형 사이트, WebP와의 화질 차이가 눈에 보이는 고품질 이미지, 빌드 과정이 이미 AVIF를 지원하는 신규 프로젝트.

쓰지 말아야 할 때: 인코딩 시간이 결정적인 경우. ImageTools 변환 도구에서도 권하지 않습니다. 브라우저의 Canvas API를 통한 AVIF 인코더는 최적화돼 있지 않아 원본보다 큰 파일이 나오기도 합니다. 제대로 된 AVIF가 필요하면 sharp 같은 서버 측 도구를 쓰세요.

SVG  Scalable Vector Graphics

SVG는 이 목록의 다른 형식들과 근본적으로 다릅니다. 픽셀을 저장하는 대신 수학 명령을 XML로 적어 둡니다. "X,Y 위치에 너비 200짜리 사각형을 #3ecf8e 색으로 그려라" 하는 식입니다. 브라우저나 프로그램이 필요한 해상도에 맞춰 실시간으로 픽셀을 계산합니다. 5KB짜리 SVG 하나가 16픽셀 파비콘에서도, 20미터 옥외 광고판에서도 완벽하게 보입니다.

로고와 아이콘에 최적인 이유: 로고와 아이콘은 사각형, 원, 베지어 곡선, 글자 같은 도형으로 이루어집니다. SVG는 그 도형을 정보 손실 없이 그대로 기술합니다. 200픽셀로 만든 PNG 로고는 2000픽셀에서 깨지지만, 같은 로고의 SVG는 어떤 크기에서도 멀쩡합니다.

CSS와 자바스크립트로 편집 가능: HTML에 인라인으로 넣은 SVG 요소는 다른 DOM 요소와 똑같이 다룰 수 있습니다. CSS로 색을 바꾸고, CSS 전환이나 자바스크립트로 움직임을 넣고, 마우스 이벤트로 상호작용을 붙일 수 있습니다. 이미지판 HTML인 셈입니다.

약한 곳: 사진처럼 색이 많고 그러데이션이 복잡한 이미지는 감당 못 할 크기의 SVG가 됩니다. 게다가 화질도 JPG보다 못합니다. SVG는 애초에 사진 데이터를 표현하려고 만들어진 형식이 아니기 때문입니다.

쓸 때: 로고, 아이콘, 도형 일러스트, 데이터 그래프, 지도, 여러 크기로 확대·축소해야 하는 모든 그래픽, 웹 인터페이스의 상호작용 아이콘.

쓰지 말아야 할 때: 사진, 색과 질감이 많은 이미지, SNS(대부분 SVG 업로드를 받지 않습니다), 이메일 마케팅.

GIF  Graphics Interchange Format

1987년 CompuServe가 만든 GIF는 LZW(Lempel-Ziv-Welch) 알고리즘으로 무손실 압축을 합니다. 다만 프레임당 256색만 지원한다는 근본적인 한계가 있습니다. 픽셀마다 최대 256개짜리 팔레트의 색인을 담는 구조라, 수백만 색을 가진 사진에는 비효율적이고 색이 적은 단순한 이미지에는 알맞습니다.

GIF가 지금까지 살아남은 이유: 널리 호환되는 래스터 형식 중 여러 프레임의 애니메이션을 기본으로 지원하는 유일한 형식이기 때문입니다. 기술적으로 앞선 형식이 나온 뒤로도 수십 년을 버티게 한 특징입니다. 애니메이션 WebP와 AVIF가 더 효율적인 대안이지만, GIF 애니메이션의 호환성과 문화적 자리는 여전히 굳건합니다.

부분 투명도: GIF는 프레임당 하나의 색만 "투명"으로 지정할 수 있습니다. 반투명도, 부드러운 경계 처리도 없습니다. 그래서 곡선 가장자리가 계단처럼 각져 보이며, 색 있는 배경 위에서 특히 두드러집니다.

쓸 때: 애니메이션 WebP나 MP4를 받지 않는 곳에서의 단순한 움직임, 색이 적은 움직이는 아이콘, GIF가 당연하게 여겨지는 밈과 SNS 콘텐츠.

쓰지 말아야 할 때: 정지 사진(JPG나 WebP를 쓰세요), 정지 로고(PNG나 SVG를 쓰세요), 웹용 복잡한 애니메이션(훨씬 효율적인 MP4나 애니메이션 WebP를 쓰세요).

BMP  Bitmap

BMP는 마이크로소프트가 만든 윈도우의 비트맵 형식입니다. 대부분의 설정에서 압축을 하지 않고 픽셀마다 색 값을 그대로 저장합니다. 그래서 파일이 아주 큽니다. 1920×1080 이미지를 24비트 BMP로 저장하면 내용과 상관없이 언제나 정확히 5.93MB입니다.

아직 남아 있는 이유: 윈도우, 오피스, 프린터, 오래된 편집 프로그램까지 마이크로소프트 생태계 전반에서 호환이 보장됩니다. 단계마다 압축 깨짐이 끼어들지 않는 것이 장점이 되는 내부 이미지 처리 과정에서는 BMP가 여전히 쓸모가 있습니다.

쓸 때: 특정 시스템, 특히 오래된 시스템이 BMP를 요구할 때. 압축 깨짐이 곤란한 처리 과정의 중간 형식으로. 일부 산업용 인쇄 시스템에서.

쓰지 말아야 할 때: 웹, 이메일, SNS 등 파일 크기가 중요한 모든 곳.