2026-07-31

왜 어떤 곳에서는 사진이 똑바로, 어떤 곳에서는 옆으로 나올까 — 영구히 고치는 법

같은 파일인데 어디서 열어보느냐에 따라 똑바로 나오기도 하고 옆으로 누워 나오기도 합니다 — 그 사이에 아무것도 편집한 게 없는데도요. 무작위처럼 느껴지지만 사실은 그렇지 않습니다. 그 뒤에는 구체적인 메타데이터 하나가 있고, 어떤 도구는 그걸 지키고 어떤 도구는 무시하는 구체적인 이유가 있으며, NearIMG를 거치면 이 문제가 다른 곳으로 옮겨가는 게 아니라 아예 영구히 고쳐지는 구체적인 이유도 있습니다.

카메라는 픽셀을 실제로 돌리지 않고, 메모만 남깁니다

풍경 사진을 찍으려고 폰을 옆으로 돌려도 카메라 센서 자체는 물리적으로 회전하지 않습니다. 센서는 항상 고정된 방향으로 픽셀을 읽어냅니다. 저장하기 전에 픽셀을 전부 재배열하는 대신, 카메라는 파일의 EXIF 메타데이터에 플래그 하나 — Orientation 태그 — 를 기록해서 "이 이미지를 제대로 보려면 이만큼 돌려야 한다"는 정보만 남깁니다. 사진 전체를 그 자리에서 다시 인코딩할 필요 없이 "90도 돌려야 함"을 기록하는 값싸고 즉각적인 방법입니다. 문제는 나중에 이 파일을 여는 쪽이 그 태그를 실제로 읽어주느냐에 전적으로 달려 있다는 점입니다.

같은 파일이 장소마다 다르게 동작하는 이유

이 부분은 실제로 일관성이 없고, 거기엔 확인 가능한 진짜 이유가 있습니다. 적어도 웹에서는 이게 동전 던지기이던 시절이 꽤 지났습니다 — CSS image-orientation 속성의 초기값은 from-image이고, MDN에 따르면 2020년 4월부터 주요 브라우저 전반에서 "널리 사용 가능한" Baseline 상태입니다. 스펙은 이게 정확히 뭘 하는지도 설명합니다 — "이미지에 담긴 EXIF 정보를 이용해 이미지를 적절히 회전시킨다." 브라우저가 쓰는 자바스크립트 레벨 디코더인 createImageBitmap()도 기본값이 같습니다 — imageOrientation 옵션의 기본값이 from-image이며, 이는 "EXIF 방향 메타데이터가 있으면 그에 따라 이미지 방향을 맞춘다"는 뜻입니다. 그래서 요즘은 사진을 최신 브라우저나 최신 사진 뷰어에서 직접 열면 대개 문제가 없습니다.

백엔드 도구는 얘기가 다르고, "찍을 땐 멀쩡했는데 사이트가 처리하고 나니 옆으로 누웠다"는 사례 상당수가 바로 여기서 나옵니다. 서버 쪽 리사이즈에 정확히 이런 용도로 가장 널리 쓰이는 파이썬 이미지 라이브러리 중 하나인 Pillow는, 파일을 열 때 EXIF 방향을 자동으로 적용하지 않습니다. Pillow 공식 문서는 이걸 고치는 방법을 구체적으로 명시합니다 — ImageOps.exif_transpose() 함수는 "이미지에 1이 아닌 EXIF Orientation 태그가 있으면, 그에 맞게 이미지를 변환(transpose)하고 방향 데이터를 제거한다"고 되어 있습니다. 이건 존재를 알고 있어야 하고, 일부러 호출해야 하는 함수입니다 — Image.open() 하나만으로는 되지 않습니다. 업로드 파이프라인이나 썸네일 생성기, 간단한 리사이즈 스크립트 상당수가 바로 이 라이브러리 위에 만들어져 있고, 그 한 줄을 건너뛰는 경우가 많습니다.

더 조용한 원인: 태그가 고쳐지는 게 아니라 지워지는 경우

이 문제가 생기는 덜 눈에 띄는 두 번째 경로도 있습니다. 개인정보를 신경 쓰는 업로드 폼, 일부 이미지 최적화 도구, "메타데이터 제거" 유틸리티들은 대개 타당한 이유(EXIF에는 GPS 좌표 등 공개 사진에 붙이고 싶지 않은 정보가 들어있을 수 있으니까요)로 EXIF 데이터를 일부러 지웁니다. 이때 Orientation 태그가 말하는 대로 픽셀을 먼저 회전시키지 않은 채로 태그만 지워버리면, 보정 정보가 태그와 함께 통째로 사라지고 사진은 센서가 원래 기록한 그대로 — 옆으로 누운 상태였다면 그대로 — 되돌아갑니다.

사진이 NearIMG를 거칠 때 실제로 일어나는 일

이 부분은 "아무 온라인 도구나 다 그렇다"는 일반론이 아니라, NearIMG가 실제로 어떻게 만들어져 있는지에 대한 구체적인 이야기입니다. HEIC가 아닌 모든 이미지는 브라우저 자체 createImageBitmap()으로 디코딩되는데, imageOrientation 옵션을 따로 지정하지 않으므로 브라우저의 기본값(from-image)이 자동으로 적용됩니다 — NearIMG의 어떤 도구가 실행되기도 전에요. 즉 NearIMG가 다루는 비트맵은 이미 시각적으로 올바른 방향의 픽셀을 가지고 있습니다.

그 다음부터는 이 글이 다루는 범위의 모든 도구 — 압축, 리사이즈, 크롭, 회전, JPG/PNG/WebP 포맷 변환 — 가 내부적으로 같은 방식으로 동작합니다: 새 캔버스에 그린 뒤 canvas.convertToBlob({ type, quality })로 인코딩합니다. 이 메서드가 받는 옵션은 출력 포맷과 압축 품질 두 개뿐입니다 — EXIF를 포함해 메타데이터를 넘겨줄 매개변수 자체가 없습니다. 실제로 벌어지는 일은 이렇습니다: NearIMG가 내놓는 파일은 나중에 어떤 앱이 무시할 수도 있는 "올바른 방향 태그"를 갖고 있는 게 아니라, 그냥 처음부터 올바른 픽셀을 갖고 있고 의존할 태그 자체가 없습니다. 이 도구들 중 아무거나 한 번만 거치면 충분합니다 — 그 시점부터는 이후에 무엇으로 파일을 열든 이 수정이 영구적으로 유지됩니다.

EXIF 태그에 의존하면 같은 파일도 앱마다 다르게 보일 수 있습니다. NearIMG는 올바른 방향을 픽셀 자체에 영구히 반영하므로, 이후 어떤 프로그램도 잘못 읽을 태그 자체가 남지 않습니다.

그래도 Rotate 도구가 필요한 경우

애초에 올바른 방향 정보를 복원할 수 없는 경우라면 이 모든 게 도움이 되지 않습니다 — 예를 들어 파일을 받기 전에 이미 상위 어딘가에서 메타데이터가 지워져서, 디코딩 시점에 읽을 Orientation 태그가 아예 남아있지 않은 사진이라면요. 이럴 땐 from-image가 참고할 정보 자체가 없으므로, 사진은 실제 픽셀이 배열된 그대로 디코딩됩니다. 이게 바로 NearIMG의 Rotate 도구가 존재하는 이유입니다 — 어떤 자동 단계도 잡아낼 수 없었던 사진을 90도 단위(180도·270도도 동일하게 가능)로 수동으로 한 번에 돌려 고치는 용도입니다.

솔직한 한계

Rotate는 고정된 90도 단위로만 돌아갑니다, 임의의 각도가 아닙니다. 사진이 4분의 1바퀴나 반 바퀴 잘못 돌아간 경우를 고쳐줍니다. 몇 도쯤 기울어진 수평선을 바로잡아주지는 않습니다 — 그건 방향(orientation) 문제가 아니라 수평 맞추기 문제이고, 다른 종류의 해결책이 필요합니다.
이 글은 구체적으로 JPEG 방식 EXIF 방향에 관한 내용입니다. 여기서 설명한 동작 — 디코더가 from-image를 기본값으로 쓰고, 인코더가 메타데이터를 아예 버리는 것 — 은 NearIMG가 실제로 호출하는 브라우저 API를 기준으로 검증한 내용입니다. HEIC 파일은 이와는 별개의 자체 메타데이터 방식을 쓰는데, 이건 여기서 함부로 단정하지 않고 별도의 글에서 다룬 주제입니다.
픽셀 자체가 잘못돼 있고 바로잡을 태그도 없다면, 어떤 소프트웨어도 정답을 자동으로 추측할 수 없습니다 — NearIMG의 자동 디코딩 단계도 예외가 아닙니다. 이건 조용히 메울 수 있는 빈틈이 아니라, 수동 Rotate 버튼이 여전히 존재해야 하는 정확한 이유입니다.

한 줄 요약

"옆으로 누운" 사진은 거의 항상 파일이 손상된 게 아니라, 카메라가 물리적으로 회전시키지 않은 픽셀 그리드에 "이렇게 보여줘야 한다"는 EXIF 태그가 붙어 있는 것뿐이고, 그 태그를 어떤 소프트웨어는 제대로 읽고 어떤 소프트웨어는 무시하거나 버립니다. 최신 브라우저는 이제 이걸 자동으로 처리하지만, 그렇지 않은 도구 위에 세워진 백엔드 리사이즈 파이프라인은 여전히 많습니다. NearIMG의 압축, 리사이즈, 크롭, 회전, 포맷 변환 도구 중 무엇이든 한 번 거치면 그 태그가 이미 적용된 상태로 디코딩되고 잃어버릴 태그 없이 재인코딩됩니다 — 그때부터는 수정이 다음에 파일을 여는 프로그램이 무엇인지에 더 이상 좌우되지 않습니다.