2026-09-01

"어차피 SNS가 EXIF 지워주는데?" — 절반만 맞는 말: 플랫폼은 지우기 전에 먼저 읽는다

사진 메타데이터 이야기가 나오는 곳이면 어디든, 몇 개의 댓글 안에 같은 안심의 말이 등장합니다. "어차피 큰 플랫폼들이 업로드할 때 EXIF를 다 지워준다"는 말입니다. 이 문장의 절반은 사실이고, 그 절반은 다른 사용자들로부터 여러분을 지켜주는 부분입니다. 그런데 이 안심의 말이 조용히 건너뛰는 나머지 절반이 있습니다 — 그 '지우기'는 플랫폼의 서버에서, 여러분의 원본 파일이 이미 통째로 도착한 뒤에 일어난다는 사실입니다. 이 두 절반을 누구보다 잘 기록해 둔 두 조직이 있습니다. 하나는 보도사진 메타데이터 표준을 만드는 IPTC로, 2013년부터 소셜 플랫폼에 테스트 이미지를 올려 무엇이 살아남는지 측정해 왔습니다. 다른 하나는 페이스북 자신으로, 자사의 개인정보처리방침에 여러분이 건넨 파일에서 무엇을 수집하는지 평이한 문장으로 적어 두었습니다. 둘을 나란히 읽으면 "어차피 지워준다"는 말은 답이 아니라 질문이 됩니다 — 누구를 위해 지워준다는 것인가?

그 '지우기'가 실제로 보호하는 대상: 대체로, 보는 사람들

IPTC 사진 메타데이터 워킹그룹은 2013년, 2016년, 2019년 세 차례에 걸쳐 소셜 미디어 메타데이터 테스트를 진행했습니다. 표준 필드마다 알려진 값을 채운 기준 이미지를 업로드한 뒤, 보는 사람이 여전히 추출할 수 있는 것이 무엇인지 확인하는 방식입니다. 일관된 결과는 이렇습니다 — 대부분의 소셜 플랫폼은 다른 사람이 보거나 저장하는 사본에서 대부분의 내장 메타데이터를 제거합니다. 2019년 라운드에서 트위터는 저장된 파일에서 Exif와 IPTC 필드를 모두 제거했고, 인스타그램은 원본 다운로드 자체를 제공하지 않았으며, 페이스북은 XMP 메타데이터를 전부 삭제했습니다. 즉 이 안심의 말은 그 좁은 주장 자체에 대해서는 틀리지 않았습니다 — 낯선 사람이 여러분의 페이스북 사진을 우클릭해도 일반적으로 GPS 좌표는 얻지 못합니다. 이 뷰어 대상 제거가 실재하고 유용한 일을 한다는 점은 분명히 말해둘 가치가 있습니다. 플랫폼이 그 일을 하지 않았을 때 무슨 일이 벌어지는지는 2025년 10월의 파티풀(Partiful) 사례가 보여줬습니다. 흥미롭게도 IPTC 자신의 불만은 정반대 방향이었습니다 — 이 테스트는 애초에 플랫폼들이 사진가의 저작권·크레딧 정보까지 몽땅 지워버린다는 것을 보여주기 위해 만들어졌습니다.

'지우기'가 할 수 없는 일: 읽은 것을 무르기

업로드는 플랫폼에 정리된 사본을 보내는 것이 아니라 파일을 보내는 것이고, 그 파일은 카메라가 기록한 그대로입니다. IPTC가 측정한 제거는 플랫폼 자체의 처리 과정에서 일어나며, 이는 GPS 블록을 포함한 원본 바이트가 먼저 플랫폼의 인프라에 놓인다는 뜻입니다. 그리고 페이스북의 경우 그다음에 무슨 일이 일어나는지 추론할 필요가 없습니다. 데이터 정책이 대놓고 말하고 있기 때문입니다 — 회사는 "여러분이 제공하는 콘텐츠에 담긴, 또는 콘텐츠에 관한 정보(예: 메타데이터), 이를테면 사진의 위치나 파일이 생성된 날짜"를 수집합니다. 이것은 유출도 실험실의 발견도 아닙니다 — 고지 문서 그 자체입니다. EXIF 제거와 메타데이터 수집은 서로 모순되지 않습니다. 같은 파이프라인의 두 단계일 뿐입니다. 플랫폼은 메타데이터를 읽고, 정책이 다루는 것을 보관한 뒤, 다른 사용자들에게는 대부분이 제거된 사본을 내보냅니다. 다시 말해 '지우기'는 플랫폼이 여러분을 위해 다른 사람들에게 해주는 일이지, 플랫폼이 자기 자신에게 하는 일이 아닙니다.

페이스북은 메타데이터를 읽기만 하지 않는다 — 직접 써넣는다

2019년 7월, 소프트웨어 엔지니어 에딘 유수포비치(Edin Jusupovic)는 페이스북을 거친 사진의 헥스 덤프를 공개했습니다. 카메라가 쓴 적 없는 데이터 블록이 들어 있었고, 이 발견은 다운로드된 사진에 숨겨진 코드가 심어져 있다는 내용으로 포브스가 보도했습니다. IPTC는 자체 조사를 진행해 구체적인 내용을 발표했습니다. 페이스북은 자사 사이트에서 저장된 사진의 IPTC 필드 두 곳에 값을 삽입합니다. Instructions 필드에는 "FBMD"로 시작하는 값이 들어가는데 이 값은 같은 이미지를 다시 업로드해도 그대로 유지되고, Job ID 필드에는 업로드할 때마다 달라지는 식별자가 들어갑니다. 용도가 무엇일까요? IPTC는 신중했습니다 — "이 값들의 역할은 페이스북이 공개적으로 문서화하지 않았으며, 현재 상당한 추측의 대상"이라고만 적고, 스스로는 어떤 가정도 하지 않았습니다. 추측이 아닌 것은 메커니즘 자체입니다. 페이스북에서 저장한 사진은 플랫폼에서의 이력과 결부된 기계 판독용 코드를 지니고 있고, 그 파일을 다시 공유하면 코드도 어디든 함께 갑니다.

3번 단계조차 백지가 아니다

IPTC의 페이스북 조사에서 나온 반전이 하나 더 있습니다 — 제거는 전부가 아닙니다. 페이스북은 사람들이 저장하는 사본에서 권리 관련 필드들 — 제작자(Creator), 제작자 직함, 저작권 표시, 크레딧, 출처, 설명 작성자 — 을 보존합니다. 직업 사진가에게는 이 파이프라인 전체에서 유일하게 괜찮은 동작이고, IPTC가 10년 넘게 플랫폼들에 더 해달라고 요구해 온 바로 그것입니다. 하지만 사진 소프트웨어가 Creator 필드에 실명을 조용히 채워 넣은 사람에게는 반대로 작용합니다 — 모두가 "어차피 지워준다"고 서로를 안심시키는 바로 그 플랫폼에서, 그 이름이 이미지를 다운로드하는 사람에게까지 따라갈 수 있습니다. 이것이 세 차례 테스트 전체의 일반적인 교훈이기도 합니다. 업로드에서 무엇이 살아남는지는 플랫폼마다, 필드마다 다르고 2013년과 2016년, 2019년 사이에도 달라졌으며, 파일이 여러분의 기기를 떠난 뒤에는 그중 무엇도 여러분의 통제 아래 있지 않습니다.

업로드 전 스크러빙이 실제로 바꾸는 것

사진을 먼저 NearScrub에 통과시키면 위의 파이프라인은 다른 1번 단계에서 시작합니다. JPEG의 경우 EXIF 블록 전체 — GPS, 촬영 시각, 기기 식별자 — 와 XMP, IPTC/포토샵 세그먼트, 삽입된 코멘트가 브라우저 탭 안에서만 제거됩니다. 업로드도 서버도 없고, 픽셀 데이터는 손대지 않은 채 복사되며, 세로로 찍은 사진이 옆으로 눕지 않도록 화면 회전 플래그 하나만 다시 넣습니다. PNG도 텍스트·EXIF·타임스탬프 청크에 대해 같은 처리를 받고, 파일을 넣으면 무엇을 지우기 전에 각 파일이 실제로 담고 있는 것의 리포트를 먼저 볼 수 있습니다. 덜 알려진 용도가 하나 더 있습니다. 위의 FBMD 코드는 IPTC 필드에 사는데, JPEG에서 이 필드들은 정확히 NearScrub이 제거하는 포토샵/IPTC 세그먼트에 실려 다닙니다 — 그러니 페이스북에서 저장한 사진을 다른 곳에 공유하기 전에 스크러빙하면, 플랫폼이 발급한 코드는 함께 가지 않습니다. 그리고 공평하게 말해두자면 — Creator와 저작권 필드가 살아남기를 원하는 사진가라면 스크러버는 필요한 것과 정반대의 일을 합니다. 이 습관은 메타데이터가 여러분이 아니라 플랫폼에 봉사하는 사진을 위한 것입니다.

정직하게 말해, 바꾸지 못하는 것

업로드 전 스크러빙은 채널 하나를 닫는 것이고, 열려 있는 나머지 채널을 정확히 짚어둘 가치가 있습니다. 이미 업로드된 사진에는 아무 소용이 없습니다 — 정책에 적힌 수집은 업로드 시점에 일어났고, 소급해서 지우는 방법은 없습니다. 플랫폼 앱이 다른 경로로 위치를 아는 것도 막지 못합니다 — 위 정책 인용문은 파일 메타데이터에 관한 것이지만, 위치 권한을 받은 앱이나 IP 주소에는 여러분의 EXIF가 필요 없습니다. 픽셀에 보이는 것도 건드릴 수 없습니다 — 가게 간판이나 거리 표지판은 메타데이터 없이도 장소를 특정합니다. NearScrub 자체의 한계에서 오는 실용적인 메모도 두 가지 있습니다. 아이폰은 기본값으로 HEIC로 촬영하는데 NearScrub은 HEIC를 해석하지 않으므로 먼저 JPEG로 변환하거나 자동 변환되는 공유 경로를 거친 JPEG를 정리해야 하고, 플랫폼의 인앱 카메라로 찍은 사진은 앱으로 곧장 들어가므로 애초에 기기에 먼저 정리할 파일이 존재하지 않습니다.

누구를 위해 지워지는가

IPTC의 10년치 테스트는 뷰어 대상 제거가 대체로 작동한다고 말합니다. 페이스북의 자체 정책은 플랫폼이 지우는 것을 먼저 읽는다고 말합니다. FBMD 발견은 적어도 한 플랫폼이 나가는 길에 자기 메타데이터를 써넣는다고 말합니다. 이 세 가지 사실은 서로 모순되지 않으며, 셋을 합치면 실제 경계선이 그려집니다 — 플랫폼의 '지우기'는 플랫폼의 사용자들로부터 여러분을 보호하는 것이고, 그 파이프라인의 어디에도 플랫폼 자신으로부터 여러분을 보호하도록 설계된 부분은 없습니다. 업로드 전의 스크러빙을 할 수 있는 당사자는 한 명뿐입니다. 파일이 아직 그냥 파일일 때 그것을 쥐고 있는 사람이니까요. 플랫폼이 읽을 수도, 보관할 수도, 덮어쓸 수도 없는 메타데이터는 — 애초에 도착하지 않는 메타데이터입니다.