본문으로 건너뛰기
피드

안드로이드, 사진 위치 정보를 전방위로 차단 중 — 웹 개발자들 울상

frontend 약 5분
vote
0
댓글
북마크

구글 안드로이드가 사진의 EXIF 위치 정보를 웹 업로드, 블루투스, 이메일 등 거의 모든 경로에서 자동 제거하고 있음. 위치 기반 사진 서비스를 운영하는 개발자가 웹에서는 더 이상 사진 위치 정보를 받을 방법이 없어 네이티브 앱 개발이 불가피하다고 호소함.

  • 1

    안드로이드가 사진 피커, 파일 피커, PWA, 블루투스, 이메일 등 모든 경로에서 EXIF 위치 정보를 자동 제거

  • 2

    유일한 우회 방법은 USB로 PC에 복사 후 데스크톱 브라우저 업로드

  • 3

    네이티브 앱에서만 ACCESS_MEDIA_LOCATION 권한으로 위치 정보 접근 가능

  • 4

    사전 공지 없는 변경으로 기존 웹 서비스가 일방적으로 깨지는 문제

  • 안드로이드가 사진에서 위치 정보를 슬금슬금 다 벗기고 있음 — 웹 업로드, 블루투스, 이메일까지 전방위 차단

    • 예전에는 <input type="file" accept="image/jpeg">로 사진 피커 열면 EXIF 위치 정보가 그대로 넘어왔는데, 구글이 이걸 막아버림
    • 그다음엔 일반 파일 피커(<input type="file">)로 우회했더니 이것도 막힘
    • PWA(Progressive Web App)도 안 되고, 블루투스/QuickShare 전송도 위치 정보가 스트립됨
    • 심지어 이메일 첨부로 보내도 위치 정보가 사라짐
    • 유일한 방법은 USB 케이블로 PC에 복사한 뒤 데스크톱 브라우저로 업로드하는 것 — 2026년에 이게 말이 되나
  • 이 글의 저자는 OpenBenches라는 추모 벤치 사진+위치 공유 사이트를 운영 중

    • 사용자가 올린 사진의 EXIF 지오태그를 읽어서 지도에 표시하는 서비스인데, 안드로이드 변경으로 핵심 기능이 완전히 깨져버림
    • 사전 공지도 없었고, 사용자들은 사이트 탓을 하며 불만 메일을 보내는 상황
  • 구글의 의도 자체는 이해할 수 있음 — 프라이버시 보호

    • 아이 사진이나 귀중품 사진에 위치 정보가 묻어 있으면 스토킹이나 범죄에 악용될 수 있으니까
    • 페이스북, 마스토돈, 블루스카이, 왓츠앱 등 대부분의 소셜 미디어는 이미 업로드 시 위치 정보를 자동으로 제거하고 있음
    • 근데 문제는 사용자에게 선택권을 안 준다는 것. "이 웹사이트가 사진의 위치 정보를 요청합니다. 허용/거부" 같은 프롬프트 하나면 될 일임

중요

> 웹에서 사진 위치 정보를 활용하는 서비스라면 안드로이드 네이티브 앱 개발이 사실상 필수가 됨. 안드로이드 앱에는 이미지 지오로케이션 접근 전용 권한이 별도로 존재함.

  • 결국 저자의 결론은 네이티브 앱을 만들 수밖에 없다는 것

    • 안드로이드 앱은 이미지 지오로케이션 접근용 특별 퍼미션이 있어서 가능
    • 근데 그러면 iOS 앱도 만들어야 하고, 개발 비용·유지보수·앱스토어 관리까지 떠안게 됨
    • 웹 기술로 충분히 해결 가능한 문제를 플랫폼이 강제로 네이티브로 밀어내는 꼴
  • 더 큰 문제는 구글의 반경쟁적 행태 패턴

    • 지배적 모바일 OS에서 웹의 기능을 하나씩 제한하면서 네이티브 앱 생태계(= 구글 플레이스토어)로 유도하는 구조
    • 커뮤니티 사전 협의도 없이 일방적으로 변경하고, 개발자들은 사후에 깨진 기능을 수습해야 함

기술 맥락

  • 사진의 위치 정보는 EXIF(Exchangeable Image File Format) 메타데이터에 저장돼요. GPS 좌표, 촬영 시간, 카메라 정보 등이 들어있는 건데, 위치 정보가 특히 프라이버시 이슈가 되는 거예요
  • 웹 브라우저에서 <input type="file">로 파일을 받으면 원래는 원본 파일이 그대로 넘어왔거든요. 근데 안드로이드의 Photo Picker API가 중간에서 EXIF를 스트립하면서 웹앱이 위치 정보에 접근하는 경로가 전부 막힌 거예요
  • 이게 PWA에도 영향을 주는 이유는, PWA가 결국 브라우저 위에서 돌아가는 웹앱이라 네이티브 앱 수준의 퍼미션 모델을 쓸 수 없기 때문이에요. 안드로이드 네이티브 앱은 ACCESS_MEDIA_LOCATION 같은 별도 권한을 선언할 수 있지만, 웹에는 이에 대응하는 API가 없는 상황이에요
  • 이 변경은 "웹 vs 네이티브" 논쟁의 전형적인 사례이기도 해요. 플랫폼 벤더가 OS 레벨에서 웹의 기능을 제한하면, 아무리 웹 표준이 발전해도 네이티브 앱이 필요해지는 구조가 만들어지거든요

프라이버시 보호라는 명분 자체는 합리적이지만, 사용자에게 선택권을 주지 않고 일괄 차단한 건 웹 생태계를 네이티브 앱으로 강제 이주시키는 효과를 낳고 있음. 한국처럼 안드로이드 점유율이 높은 시장에서는 영향이 더 클 수 있음.

댓글

댓글

댓글을 불러오는 중...

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

frontend

“98% 지원”이 생각보다 별로 안 넉넉한 이유

브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.

frontend

메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개

메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.

frontend

shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.