David.Cheon
UIpac
David.Cheon
  • UIpac (647) N
    • Planning · PM (227)
      • 프로젝트 · PM (58)
      • UX · Product (49)
      • 서비스 기획 (40)
      • Business · Growth (60)
      • 일하는 방법 (20)
    • AI (64) N
      • AI Product (13)
      • AI 활용 · 자동화 (7)
      • AI Technology (11)
      • AI Trend (33) N
    • Projects · Tech (2)
      • Toy Project (1)
      • Web · IT (1)
      • Tools (0)
    • Archive (352) N
      • Weekly Curation (251)
      • Performing Arts (17) N
      • Collection (6)
      • Books (0)
      • Life (78) N

인기 글

Tags

  • 기획참고
  • 세계 게임시장 규모
  • UX
  • 디자인
  • Mreport
  • 가트너
  • 사이트
  • 유니티
  • trend
  • Curation
  • 벤치마킹
  • UI
  • 분석
  • 트렌드
  • 큐레이션
  • 반응형웹
  • 디자인참고
  • 2015
  • 트랜드
  • Gartner
  • daumkakao
  • 사물인터넷
  • 웨어러블
  • 2014
  • 인공지능
  • 애플리케이션
  • 기획
  • 동향
  • 모바일
  • 다음카카오

최근 댓글

방명록

전체 방문자
오늘
어제
hELLO · Designed By 정상우.
David.Cheon

UIpac

Planning · PM/서비스 기획

글로벌 지도 서비스를 비교하는 관점

2018. 7. 21. 16:12

 

서비스에 지도를 넣어야 할 때, 가장 먼저 나오는 질문은 어떤 지도를 쓸 것인가예요.
이때 저는 이름을 하나씩 나열해 비교하기보다 비교하는 관점부터 정해 두는 편이 낫다고 생각합니다.
지도 서비스는 겉으로는 비슷해 보여도 데이터를 어디서 가져오는지, 얼마나 자주 고치는지, 어떤 조건으로 쓰게 해 주는지가 서로 많이 다르기 때문이에요.
이 글에서는 특정 서비스의 장단점이 아니라, 어느 서비스든 들이댈 수 있는 관점 네 가지를 정리해 보겠습니다.
세부 조건은 시기마다 바뀌므로, 실제 도입할 때는 각 서비스의 최신 공식 문서를 꼭 확인해야 합니다.

먼저 왜 관점부터 정해야 하는지 이야기해 볼게요.
지도는 한 번 서비스에 넣으면 바꾸기가 쉽지 않은 부품입니다.
화면 구성, 검색, 길 안내, 데이터 저장 방식이 지도 서비스에 맞춰 만들어지기 때문이에요.
그래서 처음 선택할 때 비교 기준이 없으면, 데모가 예쁘다거나 지인이 추천했다는 이유로 정하게 됩니다.
기준이 먼저 있으면 서비스 목적에 맞는 선택을 설명할 수 있고, 나중에 바꿔야 할 때도 어디가 부족했는지 말할 수 있어요.
저는 데이터 출처, 업데이트, 라이선스와 비용, 개발자 연동 이 네 가지를 기본 틀로 씁니다.

 

 

관점 1. 데이터 출처

 

지도 데이터는 어디선가 만들어져 온 것입니다.
자체 측량이나 차량 촬영으로 모으는 곳도 있고, 위성 이미지와 공공 데이터, 파트너사 데이터를 합치는 곳도 있고, 이용자들이 직접 입력하는 방식도 있어요.
출처가 다르면 강한 지역과 약한 지역이 달라집니다.
대도시는 상세한데 소도시나 해외 일부 지역은 비어 있는 경우도 있고, 건물 정보는 풍부한데 보행자 길 정보는 약한 경우도 있습니다.
그래서 비교할 때는 전체 평가보다 우리 서비스가 쓰는 지역과 정보 종류를 기준으로 봐야 해요.
출처를 알기 어려운 경우에는 샘플 지역을 몇 곳 정해서 직접 열어 보는 방법이 가장 확실했습니다.
핵심 지역 세 곳 정도를 골라 길, 건물, 가게 정보를 눈으로 비교해 보면 소개 자료로는 알 수 없는 차이가 보여요.

 

 

관점 2. 업데이트의 속도와 방식

 

새로 생긴 길, 사라진 가게, 바뀐 이름이 얼마나 빨리 반영되는지도 서비스마다 다릅니다.
업데이트는 누가 고치는지, 제보를 어떻게 받는지, 반영까지 얼마나 걸리는지를 같이 봐야 해요.
가정해서 맛집 서비스를 만든다고 하면 폐업한 가게가 지도에 남아 있는 일은 사용자 신뢰에 직접 타격이 됩니다.
반대로 산책로 안내 서비스라면 가게 정보보다 길의 변화가 훨씬 중요하겠지요.
우리 서비스에서 어떤 정보가 낡았을 때 가장 아픈지를 먼저 정해 두면, 업데이트를 볼 때 무엇을 확인할지 분명해집니다.
사용자 제보를 받는 창구가 있는지도 같이 보세요.
서비스에서 오류를 발견한 사용자가 쉽게 알릴 수 있으면 낡은 정보가 오래 남는 일을 줄일 수 있어요.

 

 

관점 3. 라이선스와 비용

 

여기가 기획자가 가장 놓치기 쉬운 부분이라고 느껴요.
지도는 쓸 수 있느냐보다 어떤 조건으로 쓸 수 있느냐가 중요합니다.
확인할 것은 대략 이런 항목들이에요.

  • 무료로 쓸 수 있는 범위와, 넘었을 때의 과금 방식
  • 출처 표시를 반드시 해야 하는지
  • 지도 데이터를 내려받아 저장하거나 가공해도 되는지
  • 서비스의 형태(웹, 앱, 사내용, 상업용)에 따른 제한
  • 지도 위에 올린 우리 데이터의 권리

특히 사용량이 늘면 비용 구조가 달라질 수 있다는 점을 처음부터 계산해 두는 게 좋아요.
구체적인 요금과 조건은 시기마다 바뀌는 것으로 알고 있어서, 여기서는 확인할 항목만 적어 두고 요금 부분은 모두 확인 필요로 남겨 둡니다.

 

 

관점 4. 개발자 연동

 

같은 지도라도 연동하는 방식이 쉽고 어려운 정도가 다릅니다.
웹과 모바일 앱 양쪽에서 같은 경험을 만들 수 있는지, 문서와 예제가 충분한지, 검색과 경로, 위치 변환 같은 기능을 함께 주는지를 봐야 해요.
개발자와 이야기할 때 기획자가 던지면 좋은 질문은 이런 것들입니다.

  • 우리가 필요한 기능이 기본 제공인지, 따로 만들어야 하는지
  • 지도 위에 마커와 경로를 많이 올렸을 때 성능은 어떤지
  • 서비스가 바뀌었을 때 다른 지도로 옮기기 쉬운 구조로 짤 수 있는지

마지막 질문이 은근히 중요한 것 같아요.
지도 관련 코드를 한곳에 모아 두면 나중에 교체할 때 부담이 줄어듭니다.

 

 

가정해서 동네 반려동물 동반 카페를 소개하는 서비스를 만든다고 해 볼게요.
핵심 정보는 가게 위치와 영업 여부, 그리고 길 찾기입니다.
이 경우 비교표의 행은 서비스 이름이 아니라 아래 질문들이 됩니다.

  • 우리가 다룰 지역의 가게 정보가 충분한가
  • 폐업과 이전이 얼마나 빨리 반영되는가
  • 하루 이용량이 늘면 비용은 어떻게 변하는가
  • 가게 정보를 따로 저장해 두고 지도 위에 올려도 되는가

후보 서비스마다 이 네 줄을 채워 보면, 같은 후보라도 서비스 성격에 따라 평가가 달라지는 것을 볼 수 있습니다.
정답이 하나 있기보다, 우리 서비스에 덜 아픈 선택이 있을 뿐이라고 생각해요.
표를 만들 때는 점수를 매기기보다 우리에게 치명적인지를 표시하는 편이 낫더라고요.
점수를 합산하면 중요한 약점이 평균에 묻혀 버리기 때문이에요.

 

지도 선택은 기능 비교가 아니라 우리 서비스의 약점이 어디인지 아는 일에 더 가깝다고 느꼈어요.
관점을 먼저 정리해 두니 후보를 볼 때 질문이 선명해졌습니다.
남은 질문은 국가마다 지도 데이터 관련 규정과 환경이 다를 때, 해외까지 서비스를 넓히면 어떻게 대응하느냐입니다.
이 부분은 법규와 사용 조건이 얽혀 있어서 확인 필요로 남겨 두고, 공부하면서 보강하겠습니다.

저작자표시 비영리 변경금지 (새창열림)

'Planning · PM > 서비스 기획' 카테고리의 다른 글

챗봇 vs 콜센터, 고객 응대 채널 전환 기준  (0) 2020.08.09
글로벌 서비스 기획 시 고려사항  (0) 2020.06.13
오픈 지도 프로젝트를 서비스에 쓸 때 생각할 것  (0) 2018.05.11
일상을 포인트로 바꾸는 서비스, 왜 사람들은 모으나  (0) 2018.04.28
Kakao TOROS  (0) 2017.12.10

티스토리툴바