이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
지도 편집기 프로젝트에서 Leaflet.js와 OpenLayers를 비교한 뒤 Leaflet을 선택했습니다. OpenLayers는 기능이 많지만 초기 로딩 크기와 학습 곡선이 프로젝트 규모에 비해 컸고, Leaflet은 플러그인 생태계가 풍부해 편집 기능을 빠르게 붙일 수 있었습니다. 폴리곤 편집에는 Leaflet.draw 플러그인을 썼고, 레이어 관리는 직접 구현했습니다. 라이브러리 선택에서 기능보다 팀 규모와 유지보수 비용을 먼저 고려하는 습관을 이 프로젝트에서 갖게 됐습니다. 이후 추가 요구사항으로 클러스터링이 필요했을 때 Leaflet.markercluster를 빠르게 붙일 수 있었던 게 선택을 잘했다는 확인이 됐습니다.
라이브러리 선택은 기능보다 팀 규모와 유지보수 비용을 먼저 고려해야 하며, 플러그인 생태계의 확장성이 이후 요구사항 대응에 결정적이었습니다.
지도 편집기 개발에서 Mapbox GL JS를 선택한 경험이 있습니다. 선택 이유는 WebGL 기반 렌더링으로 래스터 방식보다 확대·축소 시 끊김이 없고, 벡터 타일 방식을 지원해서 네트워크 사용량이 적고 클라이언트 사이드에서 스타일을 동적으로 변경할 수 있기 때문이었습니다. 편집기에서 사용자가 레이어를 추가하거나 마커 스타일을 바꾸는 기능이 필요했는데, 벡터 타일 + 동적 스타일링 조합이 이 요구사항에 가장 적합했습니다. 반면 라이선스 이슈로 오픈소스 대안이 필요할 때는 MapLibre GL JS(Mapbox GL의 오픈소스 포크)로 전환 가능한 구조로 설계해두었습니다.
렌더링 방식이 편집기 성능을 결정합니다. 벡터 타일이 편집 기능의 유연성을 높입니다. 라이선스와 기능 요구사항을 함께 고려해야 합니다.
지도 편집기에서 사용자가 직접 폴리곤이나 선을 그릴 수 있는 드로잉 기능이 필요했을 때, 라이브러리 선택이 구현 난이도에 큰 영향을 줬습니다. Leaflet.draw 플러그인과 Turf.js를 조합하는 방식과, OpenLayers의 내장 드로잉 기능을 비교했습니다.
Leaflet.draw는 커뮤니티 지원이 많고 사용법이 직관적이어서 프로토타입 속도가 빨랐지만, 복잡한 공간 분석이 필요할 때 Turf.js를 별도로 연결해야 하는 번거로움이 있었습니다. OpenLayers는 공간 연산 기능이 내장되어 있어 복잡한 편집 기능에 적합하지만 학습 비용이 높았습니다.
요구사항이 단순 드로잉 중심이었기 때문에 Leaflet.draw를 선택했고, 이후 분석 기능이 추가됐을 때 Turf.js를 붙이는 방식으로 확장했습니다. 요구사항 범위가 라이브러리를 결정합니다. 확장 가능성을 열어두고 선택해야 합니다. 학습 비용과 기능 커버리지의 균형이 선택 기준입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.