Chrome 144에서 등장한 <geolocation> HTML 요소 정리("<geolocation> HTML 요소 소개" 요약)

웹에서 위치정보는 여전히 민감하고 실패하기 쉬운 기능이다.
기존 navigator.geolocation 기반 구현은 의도 없는 권한 프롬프트, 자동 차단, 복구 불가 UX라는 구조적 한계를 안고 있었다.

Chrome 144부터 도입된 <geolocation> HTML 요소는 이 문제를 API 레벨이 아니라 상호작용 모델 자체를 바꾸는 방식으로 해결한다.

이 글은 다음을 명확히 정리한다.

• 왜 기존 Geolocation API가 실패하는 구조였는가
• <geolocation> 요소가 무엇을 바꿨는가
• 실제 구현에서 무엇이 단순해졌는가
• 언제 써야 하고, 언제 쓰지 말아야 하는가

---

1. 기존 Geolocation API의 구조적 문제

기존 방식은 다음 흐름에 의존했다.

navigator.geolocation.getCurrentPosition(...)

이 구조의 핵심 문제는 명확하다.

① 사용자 의도와 트리거가 분리됨

• 페이지 로드 시
• 특정 로직 진입 시
• 혹은 비가시적인 이벤트에서
  → 브라우저 권한 프롬프트가 갑자기 등장

사용자는 왜 지금 위치 권한을 묻는지 이해하지 못한 채 차단을 선택한다.

---

② 브라우저의 자동 차단 정책

Chrome은 동일한 권한 프롬프트를 여러 번 무시/차단하면:

• 1주 이상 무음 차단
• 개발자는 실패 원인을 알기 어려움
• 사용자는 복구 경로를 알 수 없음

즉, 기존 방식은 한 번의 실수로 영구적으로 망가지는 UX를 만든다.

---

③ 권한 + 데이터 접근 + 오류 처리의 혼합

개발자는 다음을 모두 직접 처리해야 했다.

• 권한 요청
• 성공 / 실패 콜백
• 에러 타입 분기
• 재시도 UX 설계

보일러플레이트가 많고, 실수 가능성이 높다.

---

2. <geolocation> 요소의 핵심 전환점

<geolocation>은 명령형 API → 선언적 UI 요소로의 전환이다.

가장 중요한 변화는 이것이다.

권한 요청은 반드시 “사용자 클릭”으로만 발생한다

즉:

• 스크립트가 권한을 요청하지 않는다
• 브라우저가 의도를 검증 가능한 UI 컨트롤을 제공한다

---

3. <permission>에서 <geolocation>으로

초기에는 범용 <permission type="geolocation"> 요소가 제안되었다.
그러나 브라우저 벤더들의 공통된 결론은 다음이었다.

• 권한마다 행동, 데이터, 오류 모델이 다르다
• 하나의 범용 요소는 복잡도만 키운다

그 결과:

• 위치 전용 <geolocation>
• 카메라·마이크 전용 <usermedia>
  라는 기능별 요소 전략으로 전환되었다.

---

4. <geolocation>은 “권한 중재자”가 아니라 “데이터 중재자”

이 차이가 핵심이다.

구분	기존 Geolocation API	<geolocation>
트리거	JS 호출	사용자 클릭
브라우저 역할	프롬프트 결정	데이터 중재
개발자 책임	콜백·에러 직접 처리	이벤트 수신
UX 복구	거의 불가	요소 클릭으로 가능

---

5. 실제 사용 예시

<geolocation
  onlocation="handleLocation(event)"
  autolocate
  accuracymode="precise">
</geolocation>

function handleLocation(event) {
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log(latitude, longitude);
  } else if (event.target.error) {
    console.error(event.target.error.message);
  }
}

중요한 점

• position, error는 DOM 요소의 상태
• JS는 결과를 소비만 한다
• 권한 상태 분기 로직이 사라진다

---

6. 주요 속성 정리

autolocate

• 이미 권한이 허용된 경우에만 자동 요청
• 새 프롬프트를 절대 띄우지 않음

accuracymode

• "precise" / "approximate"
• 기존 enableHighAccuracy 대체

watch

• watchPosition()과 동일
• 이동 시 지속 이벤트 발생

상태 속성

• position: GeolocationPosition
• error: GeolocationPositionError

---

7. UX 관점에서의 결정적 이점

① 명확한 사용자 의도

• “지금 위치를 쓰겠다”는 클릭
• 브라우저 자동 차단 회피

② 복구 가능한 흐름

• 과거에 차단했어도
• 요소 클릭 → 복구 UI 제공

③ 권한 허용 후 재사용

• 이미 허용된 상태라면
• 클릭 즉시 새 데이터 획득 (프롬프트 없음)

---

8. 스타일링 제약이 있는 이유

<geolocation>은 일반 버튼이 아니다.
브라우저는 기만적 UI를 방지하기 위해 제약을 둔다.

• 최소 대비 비율 보장
• 투명도 강제 불가
• 최소·최대 크기 제한
• 음수 마진 금지
• 왜곡 변형 제한
• :granted 상태 스타일 지원

이 제약은 단점이 아니라 신뢰 모델의 일부다.

---

9. 점진적 적용 전략 (중요)

브라우저 미지원 시

• <geolocation>은 HTMLUnknownElement
• 내부 fallback 콘텐츠가 렌더링됨

<geolocation onlocation="updateMap()">
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Use my location
  </button>
</geolocation>

기능 감지

if ('HTMLGeolocationElement' in window) {
  // modern path
} else {
  // legacy path
}

---

10. 언제 써야 하는가

적합한 경우

• 지도
• 매물 검색
• 근처 매장
• 날씨
• 배달 / 모빌리티
• 위치 기반 개인화

부적합한 경우

• 백그라운드 자동 수집
• 사용자 개입 없는 위치 추적
• 빈번한 polling 기반 로직

---

결론

<geolocation>은 단순한 문법 추가가 아니다.

• 권한 모델
• 사용자 의도
• 실패 복구 UX
• 브라우저 개입 정책

이 모든 것을 HTML 레벨에서 재설계한 요소다.

앞으로 웹 권한 API는 다음 방향으로 간다.

“스크립트가 요청하지 말고
사용자가 직접 행동하게 하라”

Chrome 144의 <geolocation>은 그 전환의 시작점이다.

---

• 참고: <geolocation> HTML 요소 소개