(2) 백엔드가 위치 기반 서비스 개발하며 알아야할 지오코딩

 

위치 기반 서비스를 개발하기 전 지오코딩과 리버스 지오코딩에 대해 알아보자.

• 지오코딩: 사용자가 입력한 주소를 정확한 위도와 경도의 좌표로 변환
• 리버스 지오코딩: 사용자가 입력한 위도와 경도의 좌표를 정확한 주소로 변환

이전 글에서 언급했듯, 위치 기반 서비스의 백엔드는 지역별 혹은 거리(반경) 내 데이터 조회를 고려해야한다.

지오코딩은 주소를 특정 위치의 좌표로 변환하므로, 반경 내 조회에 필수적이며,
리버스 지오코딩은 사용자의 현재 위치를 주소로 변환하므로, 사용자가 위치한 지역 내 조회에 필수적이다.

따라서, 위치 기반 서비스의 백엔드에서 위치 데이터를 효율적으로 관리하기 위해,
지오코딩과 리버스 지오코딩(이후, 지오코딩)이 매우 중요한 역할을 한다는 사실을 알 수 있다.

그렇다면, 이렇게 필수적인 기능인 지오코딩을 서비스에 어떻게 적용할 수 있을까?

 

1단계: 외부 API 를 활용하여 적용

가장 먼저 떠오르는 방법은 외부 API를 활용하는 방법이다.
국내외에 지도 관련 서비스들은 대부분 지오코딩의 API를 제공한다.

아래 표는 24년 3월 12일 기준으로 찾아본 API 현황이다.

	국도교통부 지오코더	네이버 Maps API	카카오 지도 API	Google Maps API	TMap API
무료 요청 건수	최대 40,000/일	최대 3,000,000/월	최대 100,000/일	* 조건부 무료	최대 20,000 / 일
저장가능 유무	불가	불가	불가	불가	** 조건부 가능

* 구글의 경우, 특정 요건을 만족하면 매월 200달러 상당의 크레딧 제공한다.
** TMap의 경우, API를 이용하여 얻어진 데이터를 저장 후 24시간 이내로 사용할 수 있다.

API를 통해 얻은 데이터의 사용과 관리 방법은 서비스의 특성에 따라 달라진다.

API를 통해 얻은 데이터를 저장할 필요가 없는 경우,
무료 요청 건수가 많고 안정적인 외부 API를 선택하면 된다.

그러나 API를 통해 얻은 데이터를 저장해야하는 경우, 추가적인 고민이 필요하다.

예를 들면, 해당 문제를 데이저 저장을 조건부로 허가하는 TMap API를 사용하여
데이터를 DB에 저장하고 24시간마다 한번씩 저장한 데이터를 갱신해서 해결할 수 있을 것이다.

그러나 24시간마다 데이터를 갱신하는 기능은 아래와 같은 문제가 있다.

1. 단일 서버 내에서 스케줄러를 통해 해당 작업을 진행할 경우,
   특정 시간대 서버에 부하가 커져서 사용자 경험을 떨어뜨릴 수 있다.
2. 별도의 서버(ex. AWS Lambda 등)을 이용하여 배치 작업을 진행할 경우,
   관리 포인트와 서버 비용이 늘어난다.
3. 해당 정책이 구현되지 않더라도, 사용자 경험에는 영향을 주지 않는다.

이와 같은 일이 발생한 이유는 무엇일까?
제공하는 API를 용도에 맞지 않게 사용하려했기 때문이다.
지금부터 외부 지오코딩 API를 "잘" 사용하기 위한 고민들을 작성해보겠다.

 

2단계: 지오 코딩의 사용 목적 구분

지오 코딩은 유용한 기능이기 때문에, 서비스 내에서도 여러가지 맥락 속에 사용된다.
그러나 각 맥락들이 같은 기능을 사용하긴 해도, 세부적인 요구 사항에 있어서는 차이가 발생할 수 있다.
이 지점을 명확히 파악하는 것이 외부 지오코딩 API를 "잘" 사용하는 첫걸음이다.

사용 목적에 따른 지오코딩

세부 요구사항을 분석한 위 표에 따라, 사용자 경험 향상을 위한 지오코딩을 위해서는
외부 API를 통한 리버스 지오코딩 제공이 가장 효율적임을 확인할 수 있다.
관리해야 하는 데이터의 양이나 업데이트 빈도에 비해
서비스 운영에 미치는 영향이 상대적으로 작기 때문이다.

앞서 살펴본 API 현황에서, 조건부 무료인 구글맵스 API를 제외하고
모든 API를 사용하면 하루 최대 26만건까지 무료로 호출할 수 있다.
무료 사용량, 호출 속도, 안정성 등을 고려하여 API를 동적으로 선택한다면,
직접 구현하는 것과 유사한 수준의 사용자 경험을 비용 없이,
변동사항을 가장 빠르게 반영하여, 지번주소든 도로명주소든 상관 없이 제공할 수 있을 것이다.

3단계: 비즈니스 로직용 지오 코딩 구현

비즈니스 로직을 위한 지오코딩을 직접 구현하기 위해
필요한 사항을 고려해보자.

앞서 사용 목적에 따른 지오코딩 분석에 따르면,
좌표 입력 시 법정동 코드를 제공하고 (리버스 지오코딩),
반대로 법정동 코드 입력 시 기준 좌표를 제공하는 기능(지오코딩)이 필수적임을 알 수 있다.

이를 고려하여 테이블 스키마를 설계한다면 다음과 같을 것이다.

CREATE TABLE legaldong (
    id VARCHAR(10) PRIMARY KEY,
    name VARCHAR(40),
    geom geometry(MultiPolygon),
    center_point geometry(Point)
);

위 legaldong 테이블의 칼럼은 다음과 같은 역할을 담당한다.

• id: 법정동 코드를 저장하며, LIKE 연산을 위해 10자리 문자열로 설정했다.
• name: 해당 지역의 주소명을 저장한다.
• geom: 지역의 경계를 나타내는 다각형(Polygon) 정보를 저장한다.
• center_point: 클라이언트에서 해당 지역을 지도상에 표시할 때 사용할 기준 좌표(폴리곤의 중심점)를 저장한다.

 

테이블 스키마 설계보다 더 중요한 과제는 필요한 지오코딩 데이터를 확보하는 것이다.
해당 데이터를 얻는 방법에 대한 해답은 우아한테크코스를 수료한 이후에나 발견할 수 있었다.

바로, 통계청에서 제공하는 지리정보 Shape File(SHP)과
행정안전부의 행정구역 분류체계 데이터를 결합해
지오코딩 데이터베이스를 구축하는 것이다.
해당 아이디어는 (빅데이터를 위한) 리버스 지오코딩 솔루션 개발기에서 얻을 수 있었다.

물론, 2019년도 글이기도 하고, 데이터를 얻은 곳의 URL이 없어서 그대로 따라하긴 쉽지 않다.
그래서 QGIS와 PostGIS의 사용법을 익혀, 지오코딩 데이터 베이스를 구축하는 방법에 대해 다시 정리해보았다.

1. 브이월드 (디지털 트윈국도)에서 최신 행정구역(SHP) 데이터 다운로드
2. 행정표준코드관리시스템에서 법정동 코드 전체 자료(TXT) 데이터 다운로드
3. TXT 파일을 처리하여, '폐지' 상태인 행을 제거하고, '폐지여부' 열을 삭제한 뒤 SQL로 변환
4. QGIS를 통해, SHP파일의 좌표체계를 WGS84 (EPSG:4326), 인코딩을 UTF-8로 설정
5. SHP 파일의 폴리곤에서 중심점 레이어를 생성
6. QGIS를 PostgreSQL 데이터베이스에 연결하여, SHP 파일들을 데이터베이스에 저장
7. SHP 테이블과 법정동 테이블은 법정동 코드를 공통 요소로 사용하므로, 이를 기준으로 지오코딩 데이터베이스 구축

 

서비스에서 PostgreSQL이 아닌 RDBMS를 운용한다면,
PG_DUMP로 SQL을 생성하기보다는
DBeaver와 같은 도구를 활용해 SQL Insert문으로 변환하여,
타겟 DB에 직접 insert 해주는 것이 호환성 측면에서 더 바람직하다.

그리고, RDBMS마다 공간데이터를 처리하는 방식이 다르기 때문에
Polygon이나 Point 데이터를 직접 Insert하는 것에 제한이 있다.

특히, Polygon 데이터는 대략 2.2MB 전후이므로,
초기에 MEDIUMTEXT 형식으로 데이터를 삽입한 뒤, 사용하는 RDBMS의 기능을 활용해
새로운 열에 ST_GeomFromText함수를 사용하여 공간 데이터 형식으로 변환하여 입력하는 Update가 효과적이다.
Point 데이터도 비슷한 접근 방식으로 처리하되, 데이터의 크기를 고려해 적절히 처리해주면 된다.

그외에도 PostgreSQL가 아닌 RDBMS에 직접 데이터를 입력하는 방법을 알아보려면,
ogr2ogr 키워드나, QGIS에서 ODBC 연결을 통한 저장 방법에 대해 검색해보자.
혹은 geotools를 이용하여 java 코드로 해결 가능하다.

위의 과정이 완료되었다면, 사용하는 RDBMS에 legaldong 테이블에
성공적으로 데이터를 추가되고, 법정동 단위의 지오코딩 구현을 완료할 수 있다.

 

더 정밀한 지오코딩(건물 단위)을 구현해야한다면 

대다수의 서비스에서는 법정동 단위 지오코딩을 구현하고,
필요시 외부 API를 호출하는 것으로 요구사항을 만족시킬 수 있을 것이다.
그러나 서비스의 특성에 따라, 건물 단위의 정밀한 지오코딩을 구현해야할 경우도 있다.

그럴 땐, 주소기반산업지원서비스에서 제공하는 건물단위 공간 정보와 도로명 주소 코드를 조합하여
건물 단위의 정밀한 지오코딩을 구현할 수 있다.

고정밀 지오코딩을 구현할 때, 대부분의 과정이 동 단위 지오코딩의 구현과
비슷하게 흘러가겠지만 몇가지 추가적으로 고려할 사항이 있다.
고정밀 지오코딩은 법정동 코드 데이터에 비해 처리해야 할 데이터량이 많고,
보안 측면에서도 데이터를 더 엄격히 다루어야된다는 점이다.

따라서, 고용량 데이터 처리와 보안 관리에 대한 전략을 수립하는 것이 중요하다.
데이터베이스 설계를 최적화하여 처리 효율을 높이고,
접근 제어 및 암호화 같은 보안 기술을 적용하여 데이터 보호를 강화해야 한다.

 

끝내며

지금까지 위치기반 서비스에서 가장 필수적인 기능인 지오코딩을 구현해보았다.
기능이 완성되었다면, 이제는 성능을 고려할 차례다.
다음번엔 저장되어 있는 위치 데이터를 빠르게 조회할 수 있게
인덱싱을 거는 방법에 대해 다루겠다.