경도와 위도의 차이: GPS 좌표가 실제로 작동하는 방식

위도와 경도는 지구상의 모든 지점을 정의하는 두 숫자입니다. 위도는 얼마나 북쪽 또는 남쪽에 있는지를, 경도는 얼마나 동쪽 또는 서쪽에 있는지를 나타냅니다. 이 좌표 쌍은 지도, GPS 기기, 지오코딩 API, AI 어시스턴트가 모두 이해하는 공통 언어입니다.

대부분의 개발자는 버그가 나기 전까지 좌표를 깊이 생각하지 않습니다. 이 가이드에서는 위도와 경도가 각각 무엇을 측정하는지, 실무에서 만나는 형식 규칙, 그리고 지도 버그를 가장 많이 일으키는 실수인 위도와 경도 뒤바꾸기를 설명합니다.

위도가 측정하는 것

위도는 지표면의 한 점과 적도면 사이의 각도이며, 도 단위로 표시합니다. 적도가 0도, 북극이 +90도, 남극이 -90도입니다. 위도선(위선)은 지구를 가로로 감싸며, 어디서나 같은 간격을 유지합니다.

위도 1도는 어디에서든 지표에서 약 111km에 해당합니다. 이렇게 일정하기 때문에 위도는 항공 운항 계획부터 기후 과학까지 폭넓게 쓰입니다.

경도가 측정하는 것

경도는 한 점과 본초 자오선 사이의 각도입니다. 본초 자오선은 런던 그리니치를 지나는 경도 0도 선입니다. 경도는 -180도(서쪽)부터 +180도(동쪽)까지이며, 두 값은 지구 반대편의 180도 경선에서 만납니다. 이 선이 국제 날짜 변경선의 대부분을 이룹니다.

위도와 달리 경도 1도에 해당하는 지표 거리는 위치에 따라 다릅니다. 적도에서 경도 1도는 위도와 같은 약 111km입니다. 헬싱키에서는 약 56km이고, 극에서는 0이 됩니다. 모든 경도선이 극에서 한 점으로 모이기 때문입니다.

그래서 평면 지도 기준으로 거리를 계산하면 장거리 경로나 극지방 근처에서 결과가 틀립니다. 정확한 거리 함수는 지구의 곡률을 반영하는 하버사인 공식이나 빈센티 공식을 사용합니다.

위도와 경도를 뒤바꾸는 실수와 예방법

실서비스의 지리공간 코드에서 가장 흔한 실수 중 하나가 위도와 경도를 뒤바꾸는 것입니다. 형식마다 규칙이 다르기 때문입니다.

• 화면 표시, 주소, GPS 앱: 위도가 먼저입니다. 48.8584, 2.2945는 위도 48.8584, 경도 2.2945입니다.
• GeoJSON, WKT, 대부분의 지리공간 표준: 경도가 먼저입니다. [2.2945, 48.8584]가 같은 지점입니다.
• MapAtlas Geocoding API와 대부분의 "v1" REST API: JSON 키(lat, lng)에서는 위도가 먼저입니다. 다만 규칙이 제각각이므로 엔드포인트 문서를 확인하세요.

GeoJSON에서 피처를 꺼내 [lat, lng] 순서를 기대하는 지도 라이브러리에 넘긴다면 순서를 바꿔야 합니다. 잊으면 점이 엉뚱한 반구에 찍힙니다. 그리고 앞으로 이틀 동안 "파리"가 왜 아프리카 앞바다에 나타나는지 디버깅하게 됩니다.

안전한 규칙이 하나 있습니다. 좌표를 받는 함수에서는 매개변수 이름을 분명하게 지으세요. function distance(latA, lngA, latB, lngB)는 a와 b가 무엇인지 모호한 배열인 function distance(a, b)보다 잘못 쓰기 어렵습니다.

십진 도(DD)와 DMS의 차이

코드에서 가장 자주 보는 형식은 십진 도(DD)입니다. 48.8584, 2.2945 같은 형태이며, 최신 API와 라이브러리는 모두 이 형식을 기대합니다.

가끔은 도, 분, 초(DMS) 형식도 만납니다. 48 deg 51' 30" N, 2 deg 17' 40" E 같은 형태입니다. DMS는 오래된 항해와 항공 관행에서 왔고, 공식 종이 지도와 일부 GPS 단말기에서 아직 쓰입니다. DMS를 DD로 바꾸는 방법은 간단합니다. DD = degrees + (minutes / 60) + (seconds / 3600)으로 계산하고, 남위나 서경이면 음수로 바꿉니다.

저장할 때는 소수점 5~6자리의 십진 도면 현실적인 모든 용도를 다룰 수 있습니다. 6자리를 넘으면 겉보기만 정밀할 뿐입니다. 스마트폰 GPS의 정확도는 하늘이 탁 트인 곳에서 보통 약 4.9m 이내이고, 보정 서비스를 쓰는 측량용 수신기만 cm 수준에 가까워지기 때문입니다.

소수점은 몇 자리가 필요할까

위도나 경도의 소수점 자리가 하나 늘 때마다 위치는 약 10배씩 정밀해집니다.

• 0자리 (48): 약 111km, 국가 수준
• 1자리 (48.8): 약 11km, 도시 수준
• 2자리 (48.86): 약 1.1km, 동네 수준
• 3자리 (48.858): 약 110m, 거리 수준
• 4자리 (48.8584): 약 11m, 건물 수준
• 5자리 (48.85844): 약 1m, 출입문 수준
• 6자리 (48.858445): 약 11cm, 일반 소비자용 GPS를 훨씬 넘어서는 수준
• 7자리 이상: 실제 데이터 출처 대부분에서 의미 없는 정밀도

하려는 일에 맞는 정밀도를 고르세요. "이 동네로 배달" 같은 용도에 소수점 8자리를 저장하면 공간만 낭비하고, 데이터가 얼마나 정확한지 사용자에게 잘못된 인상을 줍니다.

좌표와 지도 투영

좌표 값 자체는 지표면 위의 각도이지만, 화면은 평평합니다. 지도 투영은 모두 위도와 경도를 화면 표시용 픽셀 x, y로 바꾸는 수학 함수입니다.

Web Mercator(EPSG:3857)는 Google Maps, OpenStreetMap, 그리고 거의 모든 인터랙티브 웹 지도가 쓰는 투영입니다. 모양과 방향은 유지하지만 면적을 왜곡합니다. 그린란드는 아프리카만큼 커 보이지만 실제로는 14분의 1 크기입니다. 실서비스 지도에서는 사용자가 장소를 알아볼 수 있다면 이 왜곡은 문제가 되지 않습니다. 반면 면적을 비교하는 주제도(인구, 선거 결과, 기후)에는 정적 도법(등면적 투영법)을 쓰세요.

저장하는 좌표 값은 언제나 WGS84 위도와 경도입니다. 투영은 렌더링할 때 적용합니다. 데이터베이스에 투영 좌표와 WGS84 좌표를 섞어 넣는 것도 대표적인 버그 원인입니다.

좌표 저장과 인덱싱

대부분의 데이터베이스에서는 위도와 경도를 숫자 컬럼 두 개로 저장하세요. PostGIS를 쓴다면 geometry(point, 4326)으로 저장합니다. 바운딩 박스 안의 점을 찾는 조회라면 컬럼마다 B-tree 인덱스를 두는 것으로 충분합니다. "가장 가까운 지점" 조회에는 공간 인덱스가 필요합니다. PostGIS GIST, MySQL SPATIAL, 또는 geohash 버킷을 쓰세요.

좌표를 문자열("48.8584,2.2945")로 저장하면, 필터링, 정렬, 거리 계산이 필요해지는 순간부터 계속 발목을 잡습니다. 문자열로 저장하지 마세요.

AI 어시스턴트가 좌표를 활용하는 방법

ChatGPT, Perplexity, Gemini 같은 최신 AI 어시스턴트도 일반 애플리케이션과 같은 방식으로 좌표를 통해 장소를 다룹니다. 사용자가 "근처 카페 찾아줘"라고 하면, 어시스턴트는 사용자 위치를 좌표로 바꾸고, 장소 API를 조회한 뒤, 하버사인 거리로 결과를 정렬합니다. 구조화된 데이터(JSON-LD geo 속성, GeoCoordinates 스키마)에 좌표를 제대로 넣어 두면, AI 어시스턴트가 텍스트에서 위치를 추측하지 않고 리스팅의 위치를 정확히 알 수 있습니다.

국경을 넘나들거나 여러 도시에 걸친 리스팅이라면, 좌표가 장소를 구분하는 기준이 됩니다. "파리"는 프랑스에도 있고 텍사스에도 있어 모호하지만, 좌표는 모호하지 않습니다.

MapAtlas를 선택하는 이유

MapAtlas는 AI 검색 시대에 맞춰 만든 유럽의 지도 플랫폼입니다. 지오코딩, 리버스 지오코딩, 등시선, 라우팅 호출은 모두 순서가 일관된 깔끔한 WGS84 좌표를 반환하며, GDPR을 준수하고 EU에서 호스팅됩니다. 좌표 조회 도구로 주소를 바로 위도와 경도로 바꿔 보세요. 지오코딩 API가 실서비스에서 어떻게 동작하는지 더 알고 싶다면 지오코드란 무엇인가 가이드를 읽어보세요.