2026-09-27

아이폰 "위치" 삭제 토글과 윈도우 "속성 및 개인 정보 제거" 버튼은 이름이 약속하는 것을 지우지 못합니다

사진 프라이버시를 조금이라도 신경 쓰는 사람이라면 이미 해결책이 기기 안에 내장돼 있다고 믿는 경우가 많습니다. 아이폰 공유 시트에는 "위치" 토글이 있고, 구글 포토에는 사진의 위치를 편집하는 기능이 있으며, 윈도우에는 마우스 오른쪽 버튼을 누르면 나오는 "속성 및 개인 정보 제거"라는 메뉴가 있습니다. 이름만 보면 스위치 하나만 켜면 파일이 깨끗해질 것 같습니다. 그러나 애플과 구글 자신의 공식 문서, 그리고 윈도우 기능을 바이트 단위로 실측한 한 보안 연구자의 결과는 모두 그보다 훨씬 좁은 범위를 가리킵니다.

애플 스스로도 이 토글을 "위치" 기능이라고만 설명한다

iOS 사진 앱에서 사진을 공유할 때 "옵션"을 누르면 위치 토글이 나옵니다. 이를 끄면 화면에 "위치 포함 안 됨"이 버튼 위에 표시됩니다 — 애플의 공식 개인 안전 가이드에 나온 그대로입니다. 이 가이드도, 토글의 이름 자체도 이 기능을 딱 한 가지로만 설명합니다 — 사진을 받는 사람이 촬영 장소를 볼 수 있는지 여부입니다. 라벨도 애플의 문서도 파일의 나머지 EXIF 항목에 대해서는 아무 말도 하지 않습니다 — 카메라 제조사·모델명, 렌즈, 노출값, 정확한 촬영 일시는 모두 GPS 태그와 같은 EXIF 블록 안에 있지만, 이 토글이 이름으로 삼은 적 없는 별개의 항목들입니다. 이 설정은 유지되지도 않습니다 — iOS에는 자동으로 항상 적용되는 전역 기본값이 없어서, 공유할 때마다 매번 다시 꺼야 합니다. "위치" 토글이라는 이름 그대로 위치만 다루고 나머지 블록은 그대로 두는 것 자체는 과장된 약속이 아닙니다 — 다만 "메타데이터를 지운다"는 것과 같은 말이라고 생각했다면 그것과는 다릅니다.

구글 포토는 내 카메라가 직접 기록한 위치는 아예 건드리지도 못한다

구글은 한발 더 나아가 이 경계를 자사 도움말 문서에 직접 명시하고 있습니다. 구글의 사진 위치 관련 지원 페이지는 이렇게 설명합니다: "추정된 위치나 직접 추가한 위치만 변경하거나 삭제할 수 있습니다... 카메라가 자동으로 추가한 위치는 구글 포토에서 업데이트하거나 삭제할 수 없습니다." 이는 알려지지 않은 버그가 아니라 구글이 자기 제품의 기능 범위를 스스로 설명한 것입니다. 구글 포토의 위치 편집 기능은 파일보다 한 층 위에서 작동합니다 — 구글의 화면과 앨범·공유 링크가 다른 열람자에게 무엇을 보여줄지를 바꿀 뿐, 촬영 순간 휴대폰이 JPEG 안에 새겨 넣은 GPS 태그 자체를 바꾸지는 않습니다. 같은 페이지는 사진이 구글 포토 바깥으로 — 예를 들어 이메일 첨부로 — 나갈 경우 "기기가 저장한 원래 위치가 구글 포토에서 한 편집과 무관하게 그대로 표시된다"고 덧붙입니다. 앱 안에서 한 편집은 파일을 따라가지 않습니다. 원본에 내장된 데이터가 그 자리를 지킵니다.

윈도우의 "속성 및 개인 정보 제거"는 실제 바이트를 파일 안에 그대로 남긴다

윈도우는 다르게, 어떤 면에서는 더 나쁘게 같은 불완전함에 도달합니다. 사진에서 마우스 오른쪽 버튼 → 속성 → 세부 정보 → "속성 및 개인 정보 제거"를 누르면, 탐색기는 카메라 제조사·카메라 모델 같은 항목을 제거했다고 알려주는 대화상자를 띄웁니다. 보안 연구자 디디에 스티븐스(Didier Stevens)는 이진 템플릿 편집기와 자신이 만든 JPEG 분석 도구를 이용해, 최신 패치가 적용된 윈도우 7·10·11에서 이 대화상자가 실제로 무엇을 만들어내는지 바이트 단위로 확인했습니다. 결과는 이랬습니다 — 탐색기는 속성 시스템이 항목을 가리키는 참조 구조(DIRENTRY)는 지우지만, 실제 문자열 값(StrAscii)은 파일의 APP1 세그먼트 안에 물리적으로 그대로 남겨둡니다. 그의 실험에서 탐색기는 카메라 제조사·모델·소프트웨어를 "제거됨"으로 표시했지만, "Canon"이라는 문자와 GIMP 소프트웨어 태그는 여전히 파일 안에 남아 있었고, 탐색기의 속성 인덱스를 믿는 대신 원시 세그먼트 바이트를 직접 읽는 도구라면 누구나 복구할 수 있었습니다. 법률사무소용 메타데이터 제거 도구를 만드는 회사인 디지털 컨피던스(Digital Confidence)의 별도 검토는 같은 기능의 허점을 더 많은 파일 형식에서 정리했습니다 — 워드 문서의 추적된 변경 내용·댓글·숨겨진 텍스트는 이 기능으로 전혀 지워지지 않고, PDF나 WAV 파일은 아예 지원 대상도 아닙니다. 두 검토 모두 이후 윈도우 버전에서 고쳐졌다는 내용은 없습니다.

공통된 패턴 — 참조는 지워져도 그 뒤의 데이터까지 지워지는 것은 아니다

세 사례는 구체적인 허점은 다르지만 같은 모양을 하고 있습니다. 애플과 구글의 도구는 애초에 위치만 다루도록 설계됐고 스스로 그렇게 밝히고 있습니다. 윈도우의 도구는 속성 전반을 제거한다고 주장하지만, 스티븐스의 실측에 따르면 그마저 온전히 해내지 못합니다. 이는 깨진 약속이라기보다 UI 토글이 설계된 범위와 "파일을 깨끗하게 만든다"는 말이 주는 인상 사이의 어긋남에 가깝습니다. 완전한 제거가 단순히 "더 꼼꼼하게"가 아니라 다른 방식으로 작동해야 하는 이유도 여기에 있습니다 — JPEG과 PNG의 경우 NearScrub은 메타데이터 항목에 대한 참조를 지우는 것이 아니라, 파일의 실제 세그먼트·청크 구조를 따라가며 남길 부분만으로 출력 파일을 다시 만듭니다. 지워지는 EXIF나 IPTC 세그먼트는 옆에 고아 바이트를 남긴 채 참조만 끊긴 것이 아니라, 애초에 출력에 복사되지 않은 바이트입니다. PDF의 Info 딕셔너리 항목과 XMP 스트림, 오피스 파일의 docProps 부분에서도 마찬가지입니다. 이 모든 과정은 파일이 어디로도 가기 전에, 브라우저 안에서 이뤄집니다.

그래도 닿지 않는 부분

완전한 제거가 어디까지 닿는지를 정확히 말하려면, 어디까지 닿지 않는지도 정확히 말해야 합니다. 이 작업은 파일에 내장된 메타데이터를 지울 뿐, 사진 자체에 보이는 것에는 아무 영향이 없습니다 — 프레임 안의 표지판이나 집 번지수는 처리 전후가 똑같이 보입니다. 최신 아이폰의 기본 촬영 형식인 HEIC나 영상 파일은 현재 처리하지 못하므로, HEIC 사진은 먼저 JPEG이나 PNG로 내보내거나 변환해야 합니다. 그리고 이미 스크럽하기 전에 보낸 사본에는 소급해서 닿지 않습니다 — 고쳐야 할 시점은 파일을 보내기 전이지 보낸 뒤가 아닙니다. 이 작업이 바꾸는 것은 실제로 내가 통제할 수 있는 단 한 부분입니다 — 전송 버튼을 누르기 직전, 파일 안에 아직 무엇이 남아 있는가입니다.