MapConductor왜 MapConductor인가
지도 기능을 가진 앱의 코드는, 대개 특정 지도 SDK에 깊이 묶여 있습니다. 갈아타고 싶어졌을 때 다시 쓰는 것은 지도 주변만으로 끝나지 않고, 화면의 로직에까지 미칩니다. MapConductor는 그 묶임을 한 장의 공통 API로 바꿔 놓습니다.
01 · 무엇이 문제인가
요금과 계약이 바뀐다
지도 API의 과금 체계는 바뀝니다. 갈아타고 싶은데, 앱의 코드가 그것을 허락하지 않는 상황이 일어납니다.
같은 기능을 3번 쓴다
Android・iOS・Web에서 각각 다른 지도 SDK를 쓰면, 마커의 취급도 카메라의 의미도 맞지 않습니다. 사양의 논의가 3번 필요해집니다.
수치가 일치하지 않는다
줌 14가 가리키는 축척도, 2점 사이의 거리도, SDK의 유틸리티에 맡기면 환경마다 어긋납니다. QA에서 「어느 쪽이 옳은가」를 매번 정하게 됩니다.
건수가 늘면 파탄난다
마커가 수천을 넘으면, 소박한 구현에서는 카메라 조작이 무거워집니다. 대책은 프로바이더마다 다르고, 그때마다 다시 쓰게 됩니다.
02 · MapConductor의 답
앱은 통일 API에만 의존합니다. 프로바이더마다의 차이는 드라이버가 흡수하고, 전환은 의존 모듈과 뷰의 타입을 교체하기만 하면 됩니다.
좌표도 상태도 공통
GeoPoint・MarkerState・MapCameraPosition은 3개 플랫폼에서 같은 이름・같은 의미입니다. 프로바이더마다의 타입은 나오지 않습니다.
줌도 거리도 일치한다
줌은 공통의 척도로 정규화되고, 거리・방위・면적은 SDK 자체의 구현으로 계산됩니다. 같은 입력이라면, 어느 프로바이더에서도 같은 값이 반환됩니다.
상태를 넘기기만 하면 된다
「지금 있어야 할 상태의 배열」을 넘기면, Core가 지난번과의 차분을 구해 필요한 만큼만 지도에 반영합니다. 추가・갱신・삭제를 직접 관리할 필요는 없습니다.
건수의 문제는 SDK 쪽에서 푼다
마커가 2,000개를 넘으면, 내부의 렌더링 엔진이 그리는 방식을 래스터 타일로 자동으로 전환합니다. 수만 건이어도 카메라 조작은 매끄러운 채로, 앱 쪽의 코드는 한 줄도 달라지지 않습니다. 기준값은 지도 뷰의 옵션으로 바꿀 수 있습니다.
03 · 얇은 래퍼가 아니다
각 SDK의 메서드를 나눠 호출하기만 하는 래퍼라면, 할 수 있는 것은 「가장 기능이 적은 SDK」에 맞춰지고 맙니다. MapConductor는 부족한 기능을 스스로 그려서 메우기 때문에, 프로바이더를 바꿔도 겉모습과 거동이 맞춰집니다.
04 · 팀에 효과가 나타나는 것
공통 API를 한 장 끼우면, 쓸 수 있는 코드의 성질이 달라집니다. 지도 SDK의 이름이 나오지 않는 코드는, 프로바이더를 바꿔도, 다른 플랫폼으로 옮겨도, 그대로 남습니다.
외울 API는 1개
지도 SDK는 벤더마다 개념도 명명도 다르기 때문에, 프로바이더를 바꿀 때마다, 플랫폼을 옮길 때마다 다시 외우는 일이 생깁니다. MapConductor에서 외우는 것은 1개의 API뿐이고, Android・iOS・React 어디에서도 같은 이름・같은 의미인 채로 쓸 수 있습니다. 어떤 플랫폼에서 얻은 지식은 그대로 다른 플랫폼에서 통용되고, 팀에 사람이 들어올 때 읽어야 할 대상이 프로바이더의 수만큼 늘어나는 일도 없습니다.
지도 SDK에 의존하지 않는 코드
GeoPoint나 MarkerState는, 어느 지도 SDK에도 속하지 않는 타입입니다. 경로를 조립한다, 범위에 들어가는지를 판정한다, 무엇을 표시할지를 정한다 ── 이러한 로직을 지도 SDK의 타입에서 떼어 내어 쓸 수 있기 때문에, 프로바이더를 바꿔도 다시 쓰지 않아도 됩니다. 지도 주변의 공통 부품을, 프로바이더마다 따로 만들지 않고 라이브러리로 잘라낼 수도 있습니다.
05 · 데이터를 배포하는 쪽에서 보면
여기까지는 지도를 넣는 쪽의 이야기입니다. MapConductor가 목표로 하는 것은 벤더 락인으로부터의 해방만이 아니라, 어느 벤더에 기댈지를 지도 SDK의 선택과 떼어 놓고 정할 수 있게 하는 것이기도 합니다.
상용 SDK를 쓰게 된다
완전히 오픈된 지도를 쓰는 경우를 빼면, 실운용에서는 어딘가의 상용 지도 SDK를 쓰게 됩니다. 계약이나 조달의 사정으로, 그 선택지가 처음부터 하나뿐인 경우도 있습니다. MapConductor가 효과를 내는 것은, 그런 상황에서도 가지고 있는 리소스를 버리지 않아도 된다는 점입니다.
지도 SDK와 데이터를 떼어 놓는다
지도 데이터・지오코딩・타일 같은 리소스는, 그것을 제공하는 벤더의 지도 SDK와 세트로 쓰는 것이 전제였습니다. 양쪽을 나눌 수 있다면, 예를 들어 ArcGIS에 축적한 콘텐츠를 다른 지도 SDK의 화면 위에서 쓰는 것 같은 일이 성립합니다.
지오코딩만, 데이터만
지오코딩만, 특정 분야의 데이터만 가진 제공자는, 자체 지도 SDK를 갖지 않기 때문에 쓰이는 장면이 한정되어 왔습니다. 표시 쪽과 떼어 놓을 수 있다면, 어느 지도 위에서도 써 주게 됩니다.
06 · 지도 SDK 프로바이더에서 보면
공통 레이어는, 지도 SDK를 제공하는 쪽에게는 자신의 존재를 옅게 만드는 것으로 보일지도 모릅니다. MapConductor는 그렇게 설계하지 않았습니다. 공통화하는 것은 어느 프로바이더에나 있는 부분뿐이고, 각 사의 강점은 그대로 밖으로 내놓고 있습니다.
밖에서 오는 고객
여러 프로바이더를 같은 작성법으로 다룰 수 있게 되면, 타사의 SDK로 만들어진 앱에서도 후보로 봐 주게 됩니다. 갈아타기의 문턱이 낮아지는 것은 기존 고객을 붙잡는 힘을 약하게 하는 방향으로도 작용하지만, 그만큼 선택되는 이유가 「갈아탈 수 없으니까」가 아니라 가격・커버리지・렌더링 품질 그 자체가 됩니다.
강점은 숨기지 않는다
공통화하고 있는 것은, 어느 프로바이더에도 존재하는 기본적인 기능뿐입니다. 상태 객체의 getMapViewHolder()를 호출하면 네이티브의 지도 뷰와 지도 인스턴스를 그대로 꺼낼 수 있으므로, 그 프로바이더에만 있는 기능은 각 사의 API로 직접 쓸 수 있습니다. 완전히 덮어 가리는 래퍼라면 차별화 요인이 사라지지만, 그렇게는 하지 않았습니다.
공통의 토대 위에서 경쟁한다
브라우저가 HTML5로 구현을 맞춘 뒤, 각 브라우저는 호환성을 지키는 것 자체가 아니라 속도나 기능 그 자체로 경쟁하게 되었습니다. 지도 SDK도 같아서, 공통의 인터페이스가 정해지면 그 위에서 얼마나 빠르게・정확하게・넓은 지역을 그릴 수 있는지가 물어지게 됩니다. 공통화는 개별 SDK의 진화를 멈추게 하는 것이 아니라, 진화의 방향을 맞추는 것이라고 생각합니다.
07 · 맞는 경우・맞지 않는 경우
- 여러 플랫폼에서 같은 지도 경험을 내고 싶다
- 장래에 프로바이더를 바꿀 가능성을 남겨 두고 싶다
- 마커・도형・카메라 같은 표준적인 지도 표현이 중심
- 수천〜수만의 마커를 다룬다
- 거리나 면적의 표시에 일관성이 요구된다
- 특정 프로바이더 고유의 고도한 표현이 주역(독자 셰이더, 벤더 전용 레이어)
- 턴바이턴 내비게이션 등, SDK의 전용 기능 그 자체가 목적
- 1개 플랫폼・1개 프로바이더로 완결되고, 앞으로도 바꿀 예정이 없다
다만 부분적인 병용은 가능합니다. 네이티브의 지도 인스턴스에는 항상 손이 닿으므로, 특수한 부분만 프로바이더 고유의 코드로 쓰는 구성이 가능합니다.