웹사이트가 위치를 판단하는 방법

독일 IP로 인도 매장이 열리는 이유

인도 고객이 독일로 표시된 프록시로 온라인 매장을 연다고 가정해 보겠습니다. 이 예시에서는 매장도 IP를 독일로 인식합니다. 그런데 페이지 위의 국가 선택기는 여전히 인도이고 카탈로그도 인도 고객용입니다.

고객이 이전 방문에서 해당 메뉴로 인도를 선택했습니다. 매장은 선택을 저장해 다음 방문에도 사용합니다. 현재 요청은 독일로 인식하는 IP에서 왔으며 고객은 이전에 인도 시장에서 쇼핑하기를 원했다는 두 정보를 갖고 있습니다. 선택한 시장을 유지하는 것은 이 매장의 의도된 동작입니다.

따라서 IP 국가와 선택한 매장은 서로 다른 질문에 답합니다. 하나는 요청의 출발지 주소이고 다른 하나는 쇼핑 경험을 제어합니다. 날씨 사이트에서 고른 도시나 호텔 검색의 목적지도 마찬가지입니다. 사이트가 그 장소의 정보를 보여 준다고 방문자가 실제 그곳에 있다고 판단한 것은 아닙니다.

웹사이트에 어떤 정보가 전달되나요?

페이지 요청을 처리하는 서버는 연결 IP를 봅니다. 프록시로 보낸 요청이라면 프록시가 서비스에 연결하는 데 쓰는 주소입니다. IP 위치 데이터는 그 주소를 국가나 지역에 연결합니다. 사이트 자체나 대신 요청을 처리하는 서비스가 조회할 수 있습니다.

요청에는 언어 기본값과 사이트에 저장돼 있던 쿠키도 포함될 수 있습니다. 페이지 로딩 후 JavaScript가 추가 브라우저 설정을 읽고 브라우저 권한 체계를 통해 기기 위치를 요청할 수 있습니다. 로그인하면 또 다른 정보 경로가 생깁니다. 사이트가 계정에 저장된 정보를 가져올 수 있습니다.

사이트는 기능에 필요한 정보를 사용합니다. 간단한 페이지는 IP만 쓸 수 있지만 계정, 지역 카탈로그, 배송 옵션이 있는 매장은 여러 출처를 쓸 이유가 있습니다. 모든 웹사이트가 표의 모든 정보를 수집해야 하는 것은 아닙니다.

사이트는 선택한 국가를 어떻게 기억하나요?

쿠키는 브라우저가 보관하고 해당 사이트의 후속 요청에 보내는 작은 데이터입니다. 국가 설정을 직접 담거나 서버가 저장된 세션과 설정을 찾는 식별자를 담을 수 있습니다. localStorage 같은 다른 브라우저 저장소에도 사이트 스크립트가 읽을 설정을 보관할 수 있습니다.

프록시 변경은 후속 요청의 연결을 바꿉니다. 저장된 값은 지우지 않습니다. 쇼핑 예시에서 독일 IP의 요청에 이전과 같은 세션 쿠키가 포함되면 매장이 인도 선택을 복원할 수 있습니다.

계정 설정은 브라우저와 기기가 바뀌어도 유지될 수 있습니다. 집 주소, 배송지, 선호 지역을 사이트 서버에 보관할 수 있습니다. 로그인하면 다시 사용할 수 있습니다. 로컬 사이트 데이터를 지워도 계정 기록은 삭제되지 않습니다.

여는 링크가 지역을 선택할 수도 있습니다. 매장이 시장마다 별도 도메인이나 경로를 둘 수 있습니다. 인도 매장 링크를 따르면 즉시 해당 버전이 열릴 수 있습니다. 이 경우 선택한 URL이 이미 어느 버전을 요청했는지 알려 줍니다.

이전 활동도 중요할 수 있습니다. 예를 들어 Google은 검색에 적합한 위치를 추정할 때 IP 정보, 기기 위치, 저장된 집·직장 주소, 이전 활동을 사용한다고 설명합니다. 이는 Google 서비스의 설명이며 아무 사이트나 전체 브라우저 기록을 읽을 수 있다는 뜻은 아닙니다.

브라우저는 기기 위치를 어떻게 공유하나요?

Geolocation API는 페이지가 기기의 지리적 위치 추정값을 요청하는 브라우저 기능입니다. 일반 공개 사이트에서는 보통 HTTPS인 보안 컨텍스트에서 제공되며 위치 권한이 필요합니다. 결과에는 위도, 경도, 정확도 추정값, 위치를 얻은 시각이 포함됩니다. 페이지가 허용한다면 권한을 받은 요청도 캐시된 위치를 쓸 수 있으므로 지도를 열었다고 반드시 새로 측정하지는 않습니다.

추정값을 얻는 방법은 브라우저와 기기의 위치 서비스가 결정합니다. GPS, 주변 Wi-Fi, 모바일 네트워크 정보, IP 정보 등을 쓸 수 있습니다. 따라서 GPS 없는 노트북도 위치를 제공할 수 있습니다. API는 특정 출처를 강제하거나 페이지에 출처를 알려 주지 않습니다. 브라우저 좌표를 자동으로 GPS 좌표나 정확한 물리적 위치라고 부르면 안 됩니다.

인도 고객이 매장의 기기 위치 확인을 허용했고 브라우저가 인도 좌표를 반환했다고 가정해 보겠습니다. 페이지는 독일 프록시를 통해 좌표를 매장에 보낼 수 있습니다. 요청에는 독일 IP에서 도착했다는 사실과 내용에 인도 위치가 포함됐다는 두 사실이 담깁니다. 프록시는 정보를 전송할 뿐 제공된 좌표를 독일 좌표로 바꾸지 않습니다.

매번 새 권한 창이 나타나는 것은 아닙니다. 이전에 부여한 권한이 아직 유효할 수 있습니다. 브라우저 설정에서 해당 사이트의 위치 권한을 확인할 수 있으며 운영체제가 브라우저에 부여한 권한도 영향을 줄 수 있습니다.

권한을 거부하면 거부 상태가 유지되는 동안 해당 API로 새 위치를 얻지 못합니다. IP 추정값과 사이트에 이미 저장된 정보는 별도 출처로 남습니다. 따라서 기기 위치 요청을 허용하지 않았어도 사이트에 위치가 표시될 수 있습니다.

언어와 시간대는 무엇을 알려 주나요?

브라우저는 Accept-Language 요청 헤더로 선호 언어를 보낼 수 있습니다. 페이지 스크립트도 언어 설정을 읽을 수 있습니다. 이는 방문자가 이해하는 언어를 선택하도록 돕습니다. 기기 위치 확인에 쓰는 권한은 필요하지 않습니다.

소유자가 여러 나라를 여행하거나 독일 프록시를 사용해도 영어 브라우저는 영어를 유지할 수 있습니다. 독일 매장이 영어를 지원하면 연결은 독일로 취급하면서 영어를 표시할 수 있습니다. en-US 같은 설정도 언어의 변형을 나타낼 뿐 검증된 미국 위치가 아닙니다.

JavaScript는 예를 들어 Intl.DateTimeFormat().resolvedOptions().timeZone으로 브라우저가 공개하는 시간대도 읽을 수 있습니다. 사이트가 방문자 현지 시각으로 약속을 표시하는 데 쓸 수 있습니다. 보통 브라우저 환경을 반영하며 시간대가 자동 또는 수동 설정돼 있을 수 있습니다.

시간대 이름과 UTC 오프셋은 다릅니다. 오프셋은 특정 시점의 UTC와의 차이이며 여러 국가가 공유할 수 있습니다. 어느 값도 독립적으로 기기의 실제 위치를 입증하지 않습니다. 사이트가 언어·시간대를 다른 정보와 비교할 수는 있지만 프록시 국가와 다르다는 사실만으로 다른 IP가 공개됐다고 볼 수 없습니다.

웹사이트가 다른 IP를 알아낼 수 있나요?

프록시 설정은 브라우저가 해당 프록시로 보내는 트래픽에 적용됩니다. 브라우저나 기기의 모든 연결이 그 경로를 쓴다는 뜻은 아닙니다. 실시간 음성·영상·데이터 교환에 쓰는 WebRTC는 연결 준비 중 주소를 발견할 수 있습니다. 브라우저 규칙과 네트워크 설정이 직접 검사를 허용하면 고객 인터넷 연결 주소 같은 다른 공인 IP가 공개될 수 있습니다.

결과는 브라우저 개인정보 규칙과 네트워크 설정에 달려 있습니다. WebRTC가 모든 사이트에서 고객 공인 IP를 알아내는 보편적인 방법은 아닙니다. 192.168.1.10 같은 로컬 사설 주소도 다른 결과입니다. 관계없는 여러 로컬 네트워크에 같은 주소가 존재할 수 있으므로 그것만으로 국가를 알 수 없습니다.

DNS는 도메인 이름을 네트워크 주소로 바꿉니다. 전용 DNS 테스트는 조회를 처리하는 리졸버를 식별할 수 있습니다. 리졸버의 국가는 그 서버의 위치이며 고객·프록시 양쪽에서 멀 수 있습니다. 일부 리졸버는 선택 기능인 EDNS Client Subnet으로 DNS 요청 클라이언트의 IP 일부를 추가로 보냅니다. 따라서 다른 국가의 리졸버가 보이는 것과 클라이언트 네트워크 정보 노출은 다른 결과입니다.

이러한 방식은 일반 페이지 요청 외에 확인 가능한 네트워크 정보와 관련됩니다. 예상 밖 공인 주소나 다른 네트워크 데이터가 테스트에 나타나면 조사해야 합니다. 페이지 언어가 다르다는 사실만으로 그런 연결이 발생했다고 볼 수는 없습니다.

사이트는 어떤 정보를 우선하나요?

어떤 판단을 내리는지에 따라 다릅니다. 지도의 ‘내 주변’ 기능은 허가받은 기기 위치를 쓸 수 있습니다. 매장은 재방문 고객이 선택한 국가를 유지할 수 있습니다. 배송 계산에는 소포의 목적지가 필요합니다. 같은 방문에서도 이러한 기능이 서로 다른 정보를 사용할 수 있습니다.

GPS가 항상 IP보다 우선하거나 계정 국가가 항상 둘보다 우선한다는 보편적 규칙은 없습니다. 사이트가 기능별로 어떤 출처를 사용할 수 있고 무엇이 적절한지 결정합니다. 하나를 쓰거나 다른 출처로 대체하거나 여러 출처를 비교할 수 있습니다.

결제 단계에서 차이가 특히 잘 보입니다. 독일 카탈로그를 보던 고객이 인도 배송지를 입력할 수 있습니다. 매장은 배송을 다시 계산하거나 상품 구성을 바꾸거나 목적지 규칙을 적용할 수 있습니다. 예를 들어 Shopify는 결제 시 배송 주소가 최종 시장 경험을 결정한다고 설명합니다. 전자상거래 시스템의 규칙이며 프록시 IP를 새로 측정한 결과가 아닙니다.

접속 허용은 또 다른 판단입니다. 국가를 정확히 식별해도 계정, 네트워크, 제공 가능 범위 규칙 때문에 동작을 거부할 수 있습니다. 일반적인 거절만으로 어떤 정보가 원인인지 알 수는 없습니다. 중요한 증거는 거절했다는 사실보다 서비스가 제공하는 구체적인 설명입니다.

어떤 정보가 결과에 영향을 줬는지 확인하는 방법

먼저 확인할 기능을 정확히 정하세요. 연결 국가, 지역 카탈로그, 주변 검색 결과, 언어, 배송 가능 여부 등은 서로 다른 정보에 의존할 수 있습니다. 유용하게 비교하려면 프록시 IP와 페이지 주소는 유지하고 관련 조건 하나만 바꾸세요. 설정이 그대로라고 믿지 말고 테스트마다 실제 주소를 기록하세요. 그렇지 않으면 확인하려던 설정과 동시에 순환으로 IP도 바뀔 수 있습니다.

1. 사이트 자체 설정을 살펴보세요. 국가 선택기, 검색 구역, 배송지, URL의 지역 버전을 확인하세요. 눈에 보이는 선택만으로 결과가 설명될 수도 있습니다.
2. 재방문과 새로 만든 비로그인 세션을 비교하세요. 사이트 데이터가 없는 별도 테스트 프로필로 저장 상태의 영향을 확인할 수 있습니다. 먼저 같은 프록시 IP를 사용하는지 확인하세요. 새 비공개 세션은 일반 탐색과 별도 사이트 데이터를 쓰지만 연결이나 모든 브라우저 설정을 자동으로 바꾸지는 않습니다.
3. 로그인 후 바뀌는 것을 확인하세요. 계정과 함께 이전 지역이 돌아온다면 지역·주소 설정을 보세요. 계정 관련 정보의 영향을 시사하지만 사이트의 전체 판단 과정이 드러나는 것은 아닙니다.
4. 현재 위치가 필요한 기능이라면 기기 위치를 검토하세요. 사이트의 위치 권한과 위치 추정 출처에 대한 설명을 확인하세요. 주변 검색 결과와 저장된 배송 국가는 검사 방법이 달라야 합니다.

쇼핑 예시에서 국가 메뉴의 독일 선택은 저장된 매장 기본값을 해결합니다. 인도로 배송하는 작업이라면 인도 목적지는 여전히 중요합니다. 사이트가 프록시 IP 자체를 잘못된 국가로 명시한다면 해당 주소의 위치 데이터에 관한 문제입니다. 필요한 결과를 정확히 정해야 다음 조치가 구체적이 됩니다.