By 37Design |

iPhone HEIC 사진과 WordPress: 변환 없이 업로드하는 방법

2017년 이후 출시된 모든 iPhone은 기본값으로 HEIC 포맷으로 사진을 찍는다. 그리고 2024년 이전에 만들어진 거의 모든 WordPress 사이트는 HEIC 파일 업로드를 거부해 왔다. 15년 동안 WordPress 사이트를 만들어오면서 내가 가장 많이 겪은 포맷 관련 혼란은 단연 이것이었다.

2024년 말 WordPress 6.7이 HEIC 네이티브 지원을 추가하면서 상황은 나아졌다. 하지만 "나아짐"과 "해결됨"은 같은 말이 아니다. 여전히 HEIC 업로드가 조용히 실패하는 호스팅 환경이 있고, 이 포맷에서 막히는 플러그인도 있고, 포럼에는 모순된 조언이 가득하다.

여기서는 수십 개의 클라이언트 사이트에서 이 문제를 직접 다루며 배운 것을 정리한다.

HEIC가 정확히 뭔가

HEIC(High Efficiency Image Container)는 HEIF 이미지 포맷에 H.265 압축을 적용한 것이다. Apple이 iOS 11에서 채택한 이유는 같은 시각적 품질에서 JPEG보다 대략 40~50% 작은 파일을 만들 수 있기 때문이다. JPEG라면 6MB일 일반적인 iPhone 사진이 HEIC라면 약 3MB로 끝난다.

이 크기 차이는 모바일 회선으로 업로드할 때 중요하고, WordPress 서버 저장공간에도 영향을 준다. 같은 화질, 더 작은 파일. 포맷 자체에는 단점이 없다.

단점은 호환성에 있다. 오랫동안 Apple 생태계 밖에서는 HEIC 파일을 거의 아무것도 열지 못했다. Windows는 2018년에 지원을 추가했다. Android는 2019년에. WordPress는 2024년 말 버전 6.7이 되어서야 추가했고, 그조차 서버에 적절한 이미지 처리 라이브러리가 설치되어 있어야 한다는 전제가 붙는다.

HEIC는 또한 JPEG보다 풍부한 메타데이터를 저장한다. 8비트가 아닌 10비트 색심도, sRGB만 지원하는 대신 더 넓은 Display P3 색역, 그리고 모던 디스플레이가 하이라이트를 더 강하게 표현하도록 해주는 HDR 게인 맵이 그것이다. JPEG로 평탄화하면 이 세 가지가 모두 사라진다.

WordPress가 기본적으로 HEIC를 거부하는 이유

WordPress 6.7 이전에는 미디어 라이브러리에 .heic 파일을 떨어뜨리면 그 악명 높은 "죄송합니다, 보안상의 이유로 이 파일 유형은 허용되지 않습니다" 메시지가 떴다. 그 이유는 사실 멀웨어 차원의 보안이 아니다. 화이트리스트의 문제다.

WordPress는 모든 업로드를 wp_check_filetype_and_ext()로 검증하며, 확장자와 MIME 타입을 get_allowed_mime_types()의 하드코딩된 목록과 대조한다. 조합이 목록에 없으면 미디어 라이브러리에 도달하기도 전에 거부된다. "보안"이라는 표현이 쓰이는 것은 임의의 파일 형식을 허용하면 공격자가 이미지로 위장한 실행 파일을 업로드할 수 있기 때문이지만, 실제로는 단지 엄격한 허용 목록일 뿐이다.

HEIC의 경우 역사적 문제는 두 가지였다. 첫째, image/heic이 기본 목록에 없었다. 둘째, 필터로 강제 허용해도 기반이 되는 PHP 이미지 라이브러리(GD와 ImageMagick)가 대부분의 서버에서 이 포맷을 디코딩하지 못했다. WordPress는 정직했다. 시스템이 처리할 수 없는 파일을 받아도 의미가 없으니 거부한 것이다. WordPress 6.7은 image/heicimage/heif를 허용 목록에 추가하고, libheif가 사용 가능할 때 이미지 에디터 클래스가 HEIC를 ImageMagick으로 디스패치하도록 가르치는 방식으로 두 부분을 모두 고쳤다.

WordPress 6.7의 HEIC 지원: 무엇이 바뀌었는가

6.7 이전의 우회책은 모든 사진을 업로드 전에 JPEG로 변환하거나(번거로움), functions.php에 스니펫을 추가해 MIME 타입을 화이트리스트에 올리거나(서버가 실제로 파일을 처리할 수 없다면 위험함) 둘 중 하나였다. 두 접근 모두 사이트를 미묘한 방식으로 망가뜨리는 것을 봐 왔다. 화이트리스트 방식은 썸네일을 깨뜨리고, 수동 변환 방식은 메타데이터를 조용히 잃는다.

WordPress 6.7은 HEIC를 허용 파일 형식 목록에 추가했고 HEIC 파일에서 썸네일을 생성하는 기본 지원도 포함시켰다. 서버의 ImageMagick이 HEIF 지원으로 컴파일되어 있다면(또는 GD에 libheif가 있다면), WordPress는 이제 HEIC를 네이티브로 다룰 수 있다.

그 "있다면"이 큰 갈림길이다.

잘 되는 곳

최신 매니지드 호스팅 제공업체(Cloudways, Kinsta, 신형 인프라의 SiteGround 등) 대부분은 HEIF 지원이 들어간 ImageMagick을 갖추고 있다. 이런 호스트에서 WordPress 6.7 이상을 쓰고 있다면 HEIC 업로드는 그냥 동작해야 한다.

잘 안 되는 곳

오래된 인프라의 공유 호스팅은 복불복이다. 저가 호스트 다수는 HEIF 지원이 빠진 구버전 ImageMagick을 돌린다. 업로드 자체는 성공할 수도 있지만(파일이 서버에 도달함) WordPress가 썸네일을 생성하지 못한다. 결국 미디어 라이브러리에 풀사이즈 HEIC 파일이 놓이고 썸네일 자리표시자가 여기저기 깨진 채로 남는다.

이때 깔끔한 에러 메시지는 나오지 않는다. 미디어 라이브러리에 미리보기 대신 일반 아이콘이 보일 뿐이다. 클라이언트들이 "사진이 업로드 안 돼요"라고 보고하지만 사실 사진은 정상 업로드되었고 그저 관리자 화면에서 깨져 보일 뿐인 경우가 여러 번 있었다. 모든 게 정상 동작할 때 미디어 라이브러리가 어떻게 동작해야 하는지 더 깊이 알고 싶다면 내가 쓴 WordPress 미디어 라이브러리 가이드를 참고하시라.

호스팅사별 HEIC 지원 비교표

같은 iPhone HEIC 파일을 주요 5개 호스트에서 테스트해, 깔끔하게 처리하는 호스트와 썸네일을 조용히 깨뜨리는 호스트를 주말 내내 가려냈다. 결과는 2026년 초 기준이다.

호스트 HEIC 업로드 수용 썸네일 생성 ImageMagick + libheif 비고
Kinsta 가능 가능 있음 (ImageMagick 7 + libheif) 가장 깔끔. AVIF도 동작.
Cloudways (Vultr/DO) 가능 가능 있음 스택 버전 의존. 신형 서버는 문제 없음.
WP Engine 가능 가능 있음 2024년 플랫폼 업데이트로 네이티브 HEIC 지원 추가.
SiteGround 가능 부분적 혼재 신형 플랜은 동작. 구형 공유 환경은 썸네일 실패.
Bluehost (공유) 가능 불가 없음 (구버전 ImageMagick) 업로드는 완료되지만 썸네일 깨짐. 사전 변환 권장.

패턴은 분명하다. 프리미엄 매니지드 WordPress 호스트는 최신 이미지 라이브러리에 투자해 왔지만, 저가 공유 호스팅은 여전히 구식 스택을 돌리고 있어 HEIC 지원이 잘해야 들쑥날쑥하다. Bluehost 공유나 비슷한 가격대의 제공업체에 있고 HEIC가 워크플로에서 중요하다면, 서버와 싸우느니 업로드 전에 변환하는 편이 낫다.

서버가 HEIC를 지원하는지 확인하는 방법

WordPress 관리자에서 도구 > 사이트 상태 > 정보 > 미디어 처리로 이동한다. ImageMagick 버전과 지원 포맷을 확인한다. 목록에 "HEIC"나 "HEIF"가 있으면 OK다.

없거나 ImageMagick이 아니라 GD를 사용 중이라면 HEIC 썸네일은 생성되지 않는다. 선택지는 두 가지다. 호스팅사에 ImageMagick 업그레이드를 요청하거나, 업로드 전에 사진을 변환하는 것이다.

"업로드 전에 변환"의 함정

"일단 HEIC를 JPEG로 변환해 두라"는 WordPress 포럼에서 가장 흔한 조언이다. 일견 그럴듯하다. 하지만 화질이 중요하다면 이는 할 수 있는 가장 나쁜 선택 중 하나다. iPhone의 기본 변환 경로는 대부분의 사람이 알아채지 못하는 방식으로 손실을 일으키기 때문이다.

iOS에 HEIC에서 JPEG로의 자동 변환을 맡길 때(Windows로 가는 AirDrop 경로, Mail Drop 첨부 경로, 공유 시트에서 대부분의 앱으로 보내는 경로) 일어나는 일은 다음과 같다.

  • 색역 압축. 원본 HEIC는 sRGB보다 약 25% 넓은 Display P3로 저장된다. JPEG 내보내기는 sRGB로 클램프된다. 채도 높은 빨강, 주황, 초록이 눈에 띄게 평탄해진다.
  • 비트 깊이 축소. HEIC는 10비트 컬러(채널당 1024단계)를 보유한다. JPEG는 8비트(256단계)에 고정된다. 매끄러운 하늘 그라데이션이 변환 후 가시적인 밴딩으로 나타날 수 있다.
  • HDR 게인 맵 손실. iOS는 SDR 픽셀 데이터와 함께 HDR 게인 맵을 임베드해 대응 디스플레이가 더 밝은 하이라이트를 표현하도록 한다. JPEG에는 등가물이 없다. 내보내기 과정에서 그림자와 하이라이트의 디테일이 뭉개진다.
  • EXIF 제거(경우에 따라). 변환을 어느 앱이 처리하느냐에 따라 GPS 좌표, 렌즈 정보, 촬영 설정이 떨어져 나갈 수 있다. 정리나 지오태깅에 메타데이터를 활용한다면 일괄 변환 전에 반드시 확인하라.
  • 파일 크기 비대화. HEIC가 존재하는 이유 자체가 압축이다. 3MB짜리 HEIC는 품질 85의 JPEG로 변환하면 보통 6~8MB로 부풀어, 저장공간 사용량이 두 배가 된다.

함정은 이 모든 손실이 썸네일 크기에서는 보이지 않는다는 것이다. 누군가 확대하거나, 인쇄하거나, 광색역 디스플레이에서 봤을 때 비로소 알아챈다. 그때는 이미 늦었고, JPEG가 손에 든 파일이다.

현명한 방식은 게시 순간에 변환하는 것이다. 지킬 것은 지키고, WordPress가 평탄화해야 할 것만 평탄화하는 도구를 쓰는 것. 이게 쓸 만한 전용 업로드 도구 모두의 설계 원칙이다.

iPhone 자체에서의 변환 문제

HEIC를 JPEG로 변환한 뒤 업로드한다는 게 듣기엔 단순하다. 노트북에서는 정말 그렇다. macOS의 미리보기는 몇 초 만에 일괄 변환해 주고, Windows의 사진 앱도 처리해 준다.

iPhone에서는 이야기가 다르다. 내장 일괄 변환 기능이 없다. HEIC가 아닌 JPEG로 촬영하도록 카메라 설정을 바꿀 수는 있지만(설정 > 카메라 > 포맷 > 호환성 우선), 그러면 WordPress로 보내는 사진뿐 아니라 찍는 모든 사진에서 40~50%의 파일 크기 이점을 잃게 된다.

일부 사람들은 단축어 앱으로 HEIC→JPEG 변환기를 만든다. 동작은 한다. 하지만 워크플로에 수동 단계가 하나 더 늘고, 변환된 파일은 더 크다. 한 문제를 다른 문제로 바꿨을 뿐이다.

진짜 짜증 나는 것은 iPhone이 어떤 상황에서는 이 변환을 자동으로 처리한다는 점이다. 메일로 사진을 보낼 때, Windows PC로 AirDrop 할 때 iOS는 알아서 JPEG로 변환한다. 하지만 브라우저나 WordPress 앱을 통해 업로드할 때는 원본 HEIC를 그대로 보낸다. 업로드에 대해 이 동작을 바꿀 수 있는 설정은 없다. iPhone에서 WordPress로 한 번에 10~20장을 자주 보낸다면, iOS의 별난 동작들을 우회하는 기법을 정리한 휴대폰에서 이미지 일괄 업로드 메모도 살펴보시라.

SnapPress가 HEIC를 다루는 방식

SnapPress를 만들 때 HEIC 처리는 가장 먼저 풀어야 했던 문제 중 하나였다. 접근은 단순하다. 앱이 원본 HEIC 파일을 읽어 iPhone에서 로컬로 JPEG로 변환한 뒤 JPEG를 WordPress로 업로드한다.

이는 서버 구성에 관계없이 모든 WordPress 사이트에서 동작한다는 뜻이다. 호스트에 ImageMagick의 HEIF 지원이 필요 없다. WordPress가 6.7 버전일 필요도 없다. 서버에 도달하는 파일은 표준 JPEG이고, 이는 1.0 버전 이래의 모든 WordPress 설치가 다룰 수 있다.

변환은 기기에서 일어나고 사진 한 장당 찰나의 시간이면 끝난다. 변환을 보지도 않고, 설정하지도 않는다. 사진을 선택하고 업로드를 누르면 미디어 라이브러리에 썸네일도, 미리보기도, 모든 게 정상으로 동작하는 JPEG가 나타난다.

이 방식이 "옳은" 방식인가? 무엇을 중시하느냐에 따라 다르다. 절대적으로 가장 작은 파일 크기를 원한다면 지원되는 서버에 네이티브 HEIC를 업로드하는 게 기술적으로 더 낫다. 서버 구성을 일일이 확인하지 않고도 모든 WordPress 사이트에서 동작하는 것을 원한다면 자동 변환이 더 안전한 선택이다. SnapPress가 다른 선택지에 비해 어떻게 자리매김하는지 보고 싶다면 경쟁 iOS 앱들을 비교한 WordPress 사진 업로드 앱 베스트 글을 참고하시라.

나는 이론적 최적화보다 신뢰성을 골랐다. 경험상 대부분의 WordPress 사용자는 자기 호스트의 ImageMagick 버전 따위는 모르고 신경도 쓰지 않는다. 그저 사진이 제대로 보이기를 원할 뿐이다.

Jetpack과 WordPress 공식 모바일 앱은 어떨까?

WordPress 공식 모바일 앱(많은 기능을 Jetpack에 의존한다)은 수년간 HEIC를 일관되지 않게 다뤄왔다. 최근 버전들은 SnapPress가 하는 것과 비슷하게 업로드 전에 HEIC를 JPEG로 변환하지만, 그 변환은 Jetpack의 이미지 처리 파이프라인을 거치므로 Jetpack 연결과 사이트에 연결된 활성 WordPress.com 계정이 필요하다.

이미 Jetpack을 쓰고 있다면 문제없다. 쓰지 않는다면 짜증 난다. 연결이 없으면 앱이 아예 업로드를 거부할 때가 있기 때문이다. 좀 더 간결한 스택을 원하는 독자를 위해 별도로 Jetpack 없이 WordPress에 사진 업로드하기 가이드를 썼다. 핵심은 이렇다. Jetpack이 워크플로의 일부가 아니라면 WordPress REST API에 직접 말 거는 서드파티 앱을 쓰라. WordPress.com 의존을 통째로 건너뛸 수 있다.

마주치게 될 또 하나의 포맷: HEIF와 AVIF

HEIC는 기술적으로 HEIF 이미지를 감싸는 컨테이너 포맷이다. 가끔 .heic 대신 .heif 확장자 파일을 보게 된다. WordPress 6.7은 둘을 동일하게 다룬다.

AVIF는 웹에서 입지를 넓혀가는 신형 포맷이다(Netflix와 다수의 CDN이 이미지 배포에 사용한다). WordPress는 6.5 버전에서 AVIF 지원을 추가했다. 일부 신형 iPhone은 AVIF로 촬영할 수 있지만 아직 기본값은 아니다.

지금으로서는 iPhone 사진을 업로드한다면 99%의 경우 상대는 HEIC다. 하지만 AVIF는 주시하라. HEIC보다도 더 높은 압축률을 자랑하고, 크로스플랫폼 지원도 더 넓다.

iPhone 16의 AVIF 대응: 이제 무엇이 오는가

iPhone 16은 iOS 18 전체에서 완전한 AVIF 지원을 탑재한다. 사진 앱은 AVIF 파일을 읽고, Safari는 인라인으로 렌더링하며, 공유 시트도 일급 시민으로 취급한다. 카메라는 여전히 HEIC가 기본값이지만, 렌더링과 디코드 파이프라인은 끝단까지 AVIF를 인식한다.

WordPress 측 준비도 끝났다. 6.5 버전이 2024년 3월에 image/avif를 허용 MIME 타입에 추가했고, 6.7은 이미지 처리 로직을 확장해 AVIF 파일이 적절한 썸네일을 생성하도록 했다. 서버에 비교적 최신의 ImageMagick + libavif가 들어 있다면 설정 없이도 파이프라인 전체가 동작한다.

퍼블리셔에게 AVIF가 중요한 이유는 이렇다. 동등한 체감 품질에서 HEIC보다 약 20%, JPEG보다 약 50% 더 작게 압축된다. 그리고 브라우저 보급도가 끝내 보편화되지 않았던 HEIC와 달리 모든 주요 모던 브라우저(Chrome, Firefox, Safari, Edge)에서 동작한다. 또한 AV1 덕분에 로열티 프리이며, HEIC가 올라타 있던 HEVC의 얽힌 특허 라이선스도 없다.

실무상의 차이: HEIC는 입구에서 씨름해야 하는 캡처 포맷, AVIF는 출구에서 방문자에게 전달하는 배포 포맷이다. 많은 워크플로는 카메라에서 나온 HEIC 원본 → 미디어 라이브러리 안의 JPEG 또는 AVIF 중간 파일 → CDN이나 ShortPixel 같은 플러그인을 거쳐 브라우저로 전달되는 AVIF, 라는 흐름으로 정착한다. Apple이 카메라 기본값을 AVIF로 바꾸는 것은 ProRAW와 Live Photos가 마이그레이션을 마친 뒤일 가능성이 높고, 이는 수년에 걸친 프로젝트다. 지금은 들어오는 HEIC 처리를 최적화하고, 배포 측 AVIF는 CDN에 맡겨두면 된다.

나의 추천

호스팅이 HEIC를 지원하고(사이트 상태에서 확인) WordPress 6.7 이상을 쓰고 있다면 HEIC 파일을 그대로 업로드하라. 더 작은 파일 크기의 혜택을 누리면 된다.

호스팅이 HEIC를 지원하지 않거나, 여러 호스트에 흩어진 사이트들을 운영하면서 하나하나 확인하기 싫다면 자동 변환해 주는 도구를 써라. SnapPress가 자동으로 그 일을 해준다. SnapPress Connect 플러그인이 사이트 연결을 담당하고, 앱이 포맷 변환을 뒤에서 처리한다.

WordPress에서 한 번 트러블이 났다고 해서 iPhone의 카메라 포맷을 JPEG로 바꾸지는 말자. HEIC가 더 나은 포맷이다. 적응해야 하는 쪽은 업로드 도구이지, 카메라 설정이 아니다.