오픈 지도 프로젝트를 서비스에 쓸 때 생각할 것

 

지도를 서비스에 넣을 때 상용 지도 서비스만 선택지인 것은 아닙니다.
오픈스트리트맵처럼 전 세계 사람들이 함께 만들고 누구나 쓸 수 있게 공개하는 오픈 지도 프로젝트도 있어요.
이름만 들으면 무료에 자유로워서 좋아 보이는데, 실제로 서비스에 쓰려면 생각할 것이 꽤 많았습니다.
이번 글에서는 오픈 지도의 장점과 한계, 라이선스 고지, 품질 편차, 그리고 서비스에 적용하기 전에 확인할 목록을 정리해 보겠습니다.
라이선스의 세부 조건은 변경될 수 있어서, 실제로 쓰기 전에는 공식 문서를 꼭 확인해야 해요.

 

오픈 지도는 기업이 혼자 측량해서 만드는 것이 아니라, 많은 참여자가 데이터를 입력하고 고치면서 키워 가는 구조입니다.
길, 건물, 공원, 가게 같은 정보를 사람들이 직접 추가하거나 위성 사진을 보고 그려 넣기도 해요.
이렇게 모인 데이터는 정해진 조건 아래 누구나 내려받아 쓸 수 있습니다.
그래서 서비스 입장에서는 지도 위에 올리는 것뿐 아니라, 데이터를 직접 가공해서 우리만의 지도를 만들 수 있다는 점이 큰 장점이에요.

 

오픈 지도에는 쓰는 사람이 직접 고칠 수 있다는 특징도 있어요.
우리 서비스에서 발견한 오류를 우리가 직접 고치면 그 결과가 지도에 반영될 수 있다는 뜻이라, 상용 서비스에서는 드문 경험입니다.
제가 생각하는 오픈 지도의 장점은 이런 것들입니다.

• 데이터를 내려받아 원하는 방식으로 가공할 수 있다
• 사용량이 늘어도 건당 호출 과금 구조에 묶이지 않을 수 있다
• 특정 업체에 종속되는 부담이 상대적으로 적다
• 지도 스타일을 서비스 분위기에 맞게 바꾸기 쉽다
• 보행길이나 자전거길처럼 특정 목적의 정보가 풍부한 지역이 있다

특히 자유도는 기획자에게 큰 매력입니다.
예를 들어 가정해서 등산로와 산책로 중심의 서비스를 만든다면, 필요한 길만 골라 보여 주는 지도를 직접 만들 수 있어요.
이런 건 정해진 상용 지도의 틀 안에서는 하기 어려운 일이었습니다.

 

반면 오픈 지도의 가장 큰 특징은 품질이 지역마다 고르지 않을 수 있다는 점입니다.
참여자가 많은 지역은 상세하고 최신인데, 참여자가 적은 지역은 비어 있거나 낡은 정보가 남아 있을 수 있어요.
데이터를 입력하는 방식이 사람마다 달라서 같은 종류의 장소도 표기가 다를 때가 있습니다.
검색 품질도 따져 봐야 합니다.
주소를 입력했을 때 정확한 위치를 찾아 주는 기능은 상용 서비스에서 매우 다듬어져 있는 반면, 오픈 데이터로 검색을 직접 구성하려면 별도의 작업이 필요해요.
그리고 서버를 직접 운영한다면 데이터 갱신, 지도 이미지를 만드는 일, 속도 관리가 모두 우리 몫이 됩니다.
공개되어 있는 무료 서버를 쓰는 방법도 있지만, 이런 서버는 사용 규칙과 이용량 제한이 있는 것으로 알고 있어서 서비스의 기반으로 쓰기 전에 확인 필요입니다.

 

오픈이라고 해서 아무 조건 없이 쓸 수 있다는 뜻은 아닙니다.
오픈 지도 데이터에는 보통 사용 조건이 붙어 있고, 대표적인 것이 출처를 밝히는 의무예요.
지도 화면 어딘가에 데이터 출처와 라이선스를 알아볼 수 있도록 표시해야 한다는 식의 조건이 있는 것으로 알려져 있습니다.
또 데이터를 가공해 다시 공개할 때는 같은 조건을 따라야 하는 경우도 있다고 알고 있어요.
그래서 서비스에 적용할 때는 이렇게 점검합니다.

• 출처 표시를 화면 어디에, 어떤 문구로 넣을지 디자인에 반영했는가
• 우리가 가공한 데이터를 공개해야 하는 조건에 해당하는가
• 오픈 데이터와 우리 고유 데이터를 섞었을 때 권리 관계가 어떻게 되는가
• 상업적 서비스에서 쓸 때의 추가 제한은 없는가

출처 표시는 작은 글씨로 구석에 두어도 되는지, 지도를 이미지로 내보낼 때도 필요한지 같은 세부 규칙까지 확인해야 해요.
저는 이런 내용을 기획서의 요구사항 항목에 적어 두고, 개발과 디자인이 함께 보도록 합니다.
이 항목들은 법적 해석이 필요할 수 있어서, 중요한 서비스라면 전문가의 확인을 받는 편이 안전합니다.
기획 단계에서 출처 표시 자리를 화면에 미리 그려 두는 것만으로도 뒤늦은 수정을 많이 막을 수 있다고 봐요.

 

가정해서 동네 산책 코스를 소개하는 작은 앱을 만든다고 해 볼게요.
지도의 핵심은 걷기 좋은 길과 쉴 곳을 보여 주는 것이고, 가게 정보는 부차적입니다.
이 경우 오픈 지도의 장점인 보행길 정보와 스타일 자유도가 잘 맞아요.
다만 우리 동네에 보행길 데이터가 얼마나 잘 입력되어 있는지는 직접 열어 봐야 알 수 있습니다.
그래서 개발에 들어가기 전에 대상 지역 몇 곳의 지도를 직접 확인하고, 비어 있는 곳이 많다면 우리가 데이터를 보강할지, 다른 지도를 쓸지를 정해야 해요.
운영 부담도 같이 가정해 봅니다.
데이터를 내려받아 우리 서버에서 갱신하는 일을 한 달에 한 번 한다고 치면, 그 작업을 누가 맡고 실패하면 누가 알아차리는지도 정해 둬야 해요.
작은 팀에서는 이런 운영 일이 기능 개발보다 먼저 발목을 잡는 경우가 많다고 들었습니다.
검색 기능이 중요하지 않다면 오픈 지도로 가볍게 시작해 볼 수 있지만, 주소 검색이 핵심이라면 상용 서비스를 함께 쓰는 혼합 구성도 생각해 볼 수 있겠습니다.

 

오픈 지도는 공짜 지도가 아니라 자유를 얻는 대신 책임을 지는 선택이라고 느꼈어요.
품질을 직접 확인하고, 조건을 지키고, 운영을 감당할 수 있다면 좋은 선택지입니다.
남은 질문은 우리가 데이터를 개선했을 때 그것을 되돌려 주는 방식으로 참여할 수 있느냐, 그리고 그 참여가 서비스 운영과 어떻게 균형을 이룰 수 있느냐예요.
이 부분은 실제로 적용해 보며 더 배우고 싶습니다.