2026-10-05

레딧이 사진의 GPS 데이터를 지워줄까요? 직접 업로드할 때만 — 링크를 올리면 아니고, 그 파이프라인은 이미 한 번 놓친 적이 있습니다

일상적인 사진 공유의 상당수가 레딧에서 일어납니다. r/hardwareswap에 올리는 중고 그래픽카드 사진, r/tretinoin의 "12개월차" 경과 인증샷, 동네 서브레딧의 잃어버린 고양이 전단지, r/HomeImprovement의 "이거 곰팡이인가요" 질문 글까지. 이 모든 경우에 같은 조용한 질문이 따라붙습니다 — 그 사진에 휴대폰이 촬영 순간 적어 넣은 GPS 좌표가 아직 남아 있다면, 레딧에 올리는 순간 그 글을 연 모든 사람에게 그 좌표가 넘어가는 걸까요? 정직한 답은 "당신의 게시물이 실제로 그 두 가지 중 어느 쪽인지에 전적으로 달려 있다"입니다 — 그리고 레딧 자체의 버그바운티 이력을 보면, 당신을 지켜줘야 할 쪽조차 이미 한 번 실패한 적이 있습니다.

사진을 실제로 레딧에 업로드하면 벌어지는 일

게시물 작성 화면의 업로드 버튼으로(붙여넣은 링크가 아니라) 사진을 올리면, 그 파일은 레딧의 자체 미디어 호스트(i.redd.it)로 전송되어 다시 인코딩된 뒤 서비스됩니다. 이 재인코딩은 주로 평범한 엔지니어링 이유 때문입니다 — 형식 통일, 파일 용량 축소, 사이트 CDN 전반의 로딩 속도 향상. 어디에도 프라이버시 기능이라고 광고돼 있지 않습니다. 하지만 이미지를 완전히 다시 인코딩하는 과정에서 GPS를 포함한 EXIF 데이터 대부분이 함께 떨어져 나가는 것은 예측 가능한 부수효과입니다 — 그래서 레딧에 직접 업로드한 사진은 보통 휴대폰을 떠날 때 있던 위치 태그 없이 다른 사람들의 화면에 도착합니다.

그 파이프라인이 GPS 태그를 오히려 남겨둔, 유일하게 기록된 사례

앞 문단의 "보통"이라는 말에는 무게가 실려 있습니다. 해커원(HackerOne)에 공개적으로 공개된 1069039번 보고서는 "Reddit: GPS metadata preserved when converting HEIF to PNG(레딧: HEIF를 PNG로 변환할 때 GPS 메타데이터가 보존됨)"라는 제목으로, 특정 변환 경로 하나를 기록하고 있습니다 — 설정 → 카메라 → 포맷을 "호환성 우선"으로 바꾸지 않은 아이폰이 기본으로 저장하는 형식인 HEIC/HEIF 사진의 경우, 레딧의 서버 측 PNG 변환 과정이 원래 지워야 할 GPS 좌표를 오히려 그대로 남겨둔 것입니다 — 파이프라인이 해야 할 일의 정반대였습니다. 레딧은 이를 수정했고 보고서는 종결됐습니다. 핵심은 이 특정 구멍이 지금도 열려 있다는 게 아닙니다 — 사람들이 "문제없다"고 믿고 의지하는 그 장치가 레딧이 어떻게 동작하는지에 새겨진 보장이 아니라, 자기만의 버그 이력을 가진 서버 소프트웨어 한 조각일 뿐이라는 점입니다.

이 두 경로 중 레딧이 실제로 처리하는 것은 하나뿐입니다. 링크 게시물은 파이프라인이 놓친 예외 상황이 아니라, 애초에 레딧에 파일 자체가 전달된 적이 없어서 다시 인코딩할 대상 자체가 없었던 것입니다.

링크 게시물은 파이프라인 버그와 무관하게 애초에 손댈 대상이 아니었다

이 절반은 레딧이 무엇을 고치느냐와 무관합니다. 게시물이(외부 이미지 URL을 똑같은 방식으로 렌더링하는 댓글도 마찬가지로) Imgur·개인 웹사이트·클라우드 저장소 공유 링크처럼 다른 곳에 있는 사진을 그저 가리키기만 할 때, 레딧은 그 파일을 전혀 전달받지 않습니다. 다시 인코딩할 것 자체가 없습니다 — 아무것도 업로드되지 않았고, 레딧은 그저 당신이 붙여넣은 URL을 보여주고 있을 뿐이기 때문입니다. 그 이미지를 링크하기 전부터 그 안에 있던 EXIF·GPS·XMP 데이터가 무엇이었든, 그 이미지를 여는 모든 사람에게 영원히 똑같이 전달됩니다 — 레딧의 업로드 파이프라인이 무엇을 지우고 무엇을 안 지우는지와는 완전히 무관하게 말입니다. 이는 파일 형식과 무관하게 모든 링크 게시물에 적용되며, 위의 해커원 버그가 수정됐는지 여부와도 무관합니다.

게시 전 제거가 여기서 실제로 바꾸는 것 — 그리고 손댈 수 없는 한 가지 형식

JPEG나 PNG를 EXIF/GPS·XMP 데이터를 지우는 클라이언트 측 제거 도구에 통과시키면 — NearScrub처럼 전부 브라우저 안에서, 업로드도 서버도 없이 — 어디에 게시하기 전에 그 파일 자체에서 좌표를 지우게 됩니다. 그 시점부터는 당신의 게시물이 위 두 경로 중 어느 쪽을 택하든 상관없습니다 — 직접 업로드하면 레딧의 파이프라인이 지우거나 지우는 데 실패할 대상 자체가 남아 있지 않고, 다른 곳에 링크해도 그 링크가 변하지 않은 채 실어 나를 대상 자체가 없습니다. 이 상황에 특정된 정직한 한계 하나: NearScrub은 JPEG·PNG·PDF·오피스 파일을 지원하며 HEIC는 지원하지 않습니다 — 그리고 HEIC/HEIF는 아이폰이 기본으로 저장하는 바로 그 형식(설정 → 카메라 → 포맷 → "고효율")이자, 위 해커원 보고서가 지목한 바로 그 형식입니다. 사진이 아직 .heic 파일이라면 먼저 JPEG로 변환해야 합니다 — 휴대폰 자체의 공유 시트나 사진 앱의 내보내기 기능으로 가능합니다 — 그래야 NearScrub이 지울 대상을 갖게 됩니다. 그리고 제거 도구는 당신이 직접 그 파일을 통과시키기로 선택한 그 순간에만 작동합니다 — 누군가 이미 올려버린 사진, 제거하기 전에 이미 공유해버린 사본, 또는 당신이 통제할 수 없는 서버에 있는 사진을 가리키는 링크에는 아무 영향을 주지 못합니다.