2025년 8월 23일·7분
마이크 보스토크와 D3.js: 웹이 데이터를 보는 법을 배운 이야기
마이크 보스토크의 D3.js를 실용적으로 살펴봅니다: 무엇인지, 왜 중요한지, 핵심 개념들, 그리고 팀들이 명확한 웹 시각화를 만드는 방법을 설명합니다.
마이크 보스토크의 D3.js를 실용적으로 살펴봅니다: 무엇인지, 왜 중요한지, 핵심 개념들, 그리고 팀들이 명확한 웹 시각화를 만드는 방법을 설명합니다.
마이크 보스토크는 단순히 인기 있는 자바스크립트 라이브러리를 만든 사람이 아닙니다—그는 웹 시각화의 관점을 재정립했습니다. 그의 핵심 아이디어는 **“데이터 기반 문서(data-driven documents)”**라는 문구에 담겨 있습니다. 간단하지만 강력합니다: 데이터를 페이지를 직접적으로 형성하는 것으로 다루라는 것입니다. 차트를 어딘가 검은 상자에서 그리는 대신, 데이터를 DOM의 요소들(예: SVG 도형, HTML 노드, Canvas 픽셀)에 바인딩하고 브라우저가 결과를 렌더링하게 둡니다.
D3 이전에는 많은 차트 도구가 기성 출력물에 집중했습니다: 차트 유형을 선택하고, 데이터를 넣고, 옵션을 조금 조정하면 디자인이 스토리와 맞기를 바라는 식이었습니다. D3는 다릅니다. D3는 근본적으로 “차트 라이브러리”가 아니라 시각화를 구축하기 위한 도구 상자입니다.
이 차이는 중요합니다. 실제 데이터와 제품 요구는 거의 예외 없이 단일 템플릿에 딱 들어맞지 않습니다. D3로 할 수 있는 일:
이 글은 개념적 가이드입니다. 단계별 튜토리얼이 아닙니다. 복붙으로 완성되는 차트를 제공하진 않지만, D3가 데이터·시각·상호작용을 어떻게 사고하는지에 대한 명확한 정신 모델을 드려 스스로 도구를 현명하게 선택하고 더 빨리 배울 수 있게 합니다.
제품 팀, 인사이트를 전달하려는 애널리스트, 데이터가 어떻게 느껴져야 하는지를 설계하는 디자이너, 또는 인터랙티브 UI를 만드는 개발자라면 D3의 영향력을 이해할 가치가 있습니다—실제 D3 코드를 한 줄도 쓰지 않더라도요.
D3 이전의 많은 “웹 차트”는 인터페이스라기보다 그림에 가까웠습니다. 팀들은 Excel이나 R에서 그래프를 PNG로 내보내 페이지에 박아 넣는 식이었고, 서버에서 차트를 생성하더라도 출력은 종종 여전히 정적인 이미지였습니다—게시하긴 쉬웠지만 탐색하기는 어려웠습니다.
사람들은 웹처럼 동작하는 차트를 원했습니다: 클릭 가능하고 반응형이며 업데이트 가능해야 했습니다. 그러나 당시의 선택지는 몇 가지 예측 가능한 한계가 있었습니다:
부족했던 건 단지 라이브러리만이 아니었습니다—플랫폼 자체가 따라왔습니다. 브라우저 표준이 성숙해졌습니다:
이 기술들은 그래픽을 내보낸 산출물이 아니라 실제 UI 구성 요소처럼 다루게 만들었습니다.
D3는 “차트 빌더”로 등장한 것이 아닙니다. D3는 데이터를 네이티브 웹 프리미티브(DOM, SVG, Canvas)에 연결해 필요한 그래픽을 정확히 설계하고, 그것을 인터랙티브하고 적응 가능하게 만드는 방법으로 등장했습니다. “차트 이미지”와 “데이터 기반 인터페이스” 사이의 갭을 D3가 닫아준 것입니다.
D3의 핵심 전제는 단순합니다: 차트를 ‘어딘가’ 그리는 대신 데이터를 페이지상의 실제 요소들과 바인딩합니다. 즉 각 데이터 행은 화면상의 요소(막대, 점, 레이블 등)와 짝을 이루고, 데이터의 변화는 곧바로 보이는 것의 변화를 이끌어냅니다.
유용한 멘탈 모델은: 데이터 행이 화면상의 마크가 된다 입니다. 데이터셋에 50행이 있으면 SVG에 50개의 원(circle)이 만들어질 수 있습니다. 60행으로 늘어나면 60개가 보이고, 40으로 줄어들면 10개가 사라져야 합니다. D3는 이 관계를 명시적으로 만들도록 설계되었습니다.
선택은 D3가 요소를 찾아 어떤 작업을 할지 정하는 방법입니다.
circle).선택은 기본적으로: “이 차트의 모든 점을 찾아서, 각 점이 자신의 데이터와 일치하도록 만들어라”입니다.
유명한 D3의 “업데이트 패턴”은 DOM 요소를 데이터와 동기화 상태로 유지하는 워크플로입니다:
이 때문에 D3는 차트 생성기라기보다 살아 있는 시각화를 유지하는 방식처럼 느껴집니다—기저 데이터가 변해도 시각화가 정확하게 유지됩니다.
D3 차트는 기본적으로 변환 기계입니다. 데이터셋은 값(매출, 온도, 투표 등)으로 시작하지만 화면은 픽셀만 이해합니다. D3의 “데이터 → 스케일 → 픽셀” 파이프라인은 이 두 세계 사이를 깔끔하게 이어주는 다리입니다.
스케일은 데이터 값을 시각적 값으로 변환하는 함수입니다.
예를 들어 월별 매출이 0에서 50,000 사이일 때 이를 0에서 300픽셀 높이의 막대로 매핑할 수 있습니다. 스케일은 수학을 처리해주므로 코드에 “/50000 * 300” 같은 계산을 흩뿌리지 않게 해줍니다.
중요한 점: 스케일은 역변환(픽셀 → 데이터)도 지원해 정밀한 상호작용(커서 아래의 정확한 값 표시 등)이 가능합니다.
축은 장식 그 이상입니다: 축은 보는 이와 차트 사이의 계약입니다. 적절한 눈금은 오독을 막습니다. 눈금이 너무 적으면 차이를 숨기고, 너무 많으면 시각적 노이즈가 생깁니다. 특히 막대 차트에서는 0을 포함하는 등 일관된 눈금 간격과 합리적 끝점이 사람들이 차트를 신뢰하도록 돕습니다.
형식화는 명확함이 결정되는 지점입니다. 날짜는 문맥에 맞아야 합니다(예: “2025년 1월” vs “2025-01-15”). 숫자는 반올림, 구분자, 단위가 필요합니다(“12,400”과 “$12.4k”는 다른 의미를 전달합니다). D3의 포맷 유틸리티는 라벨을 일관되게 만들어 차트가 대충대충 보이지 않도록 합니다.
D3는 특정 렌더링 기술에 묶어두지 않습니다. D3는 데이터→요소 로직(조인, 스케일, 상호작용)에 집중하고, 마크가 어디에 위치할지는 당신이 선택합니다: SVG, Canvas, 또는 일반 HTML. 어떤 것을 선택할지는 주로 그려야 할 요소 수와 스타일/접근성이 얼마나 중요한지에 달려 있습니다.
SVG는 DOM 기반 드로잉 표면입니다: 각 원, 경로, 레이블은 CSS로 스타일링 가능한 요소이며 개발자 도구로 검사할 수 있습니다.
SVG가 빛나는 경우:
대안 비용: 수천 개의 SVG 요소는 DOM 부담을 키워 브라우저에 무거울 수 있습니다.
Canvas는 픽셀 기반입니다: “페인팅”을 하고 브라우저가 각 포인트를 DOM 노드로 관리하지 않습니다. 수만 점의 산점도, 밀집 히트맵, 실시간 렌더링에 적합합니다.
단점은 실무적입니다: 스타일링이 수동이고, 선명한 텍스트는 추가 작업이 필요하며 상호작용은 히트 테스트(hit-testing) 로직을 직접 구현해야 합니다.
시각화가 실제로 UI 구성 요소(정렬 가능한 표, 툴팁, 필터, 카드형 요약 등)인 경우 HTML이 이상적입니다. 또한 SVG나 Canvas 차트와 HTML 컨트롤을 혼합하는 경우가 흔합니다.
D3는 데이터를 SVG/HTML 요소에 바인딩하거나, 당신이 Canvas에 렌더링할 스케일·레이아웃·상호작용을 계산할 수 있게 해줍니다. 이 유연성 때문에 D3는 제약이 아니라 도구상자로 느껴집니다.
D3에서 “레이아웃”은 데이터에서 기하를 계산하는 함수(또는 소규모 시스템)를 뜻합니다: x/y 위치, 각도, 반지름, 경로, 부모/자식 관계 같은 수치입니다. 레이아웃 자신이 픽셀을 렌더링하진 않고, 그 수치를 산출해 당신이 그 값을 바인딩해 그리게 합니다.
과거 D3는 named layouts(포스, 팩, 트리, 클러스터, 코드 등)을 제공했지만, 최신 버전에서는 많은 아이디어를 모듈화해 노출합니다. 그래서 종종 예제에서 d3-force(네트워크)나 d3-geo(지도)를 직접 사용하는 모습을 보게 됩니다.
흥미로운 차트 대부분은 ‘수학 문제의 변장’입니다. 충돌 회피, 노드 위치 지정, 직사각형 타일링, 위도/경도 투영 같은 것을 직접 쓰지 않으면 일이 번거롭습니다. 레이아웃은 그 작업을 설정(config)으로 줄여줍니다:
그 결과 디자인 선택(색, 레이블, 상호작용)에 더 빨리 반복할 수 있습니다.
네트워크 그래프: d3.forceSimulation()은 반복적으로 노드와 링크를 배치해 각 노드의 x/y를 제공합니다.
트리맵: 계층 레이아웃은 값에 따라 크기가 정해진 중첩 사각형을 계산해 파트-투-홀 관점에 적합합니다.
지도: d3.geoPath()는 GeoJSON을 투영(Mercator, Albers 등)해 SVG 경로로 변환합니다.
핵심 아이디어는 반복 가능합니다: 레이아웃은 원시 숫자를 그릴 수 있는 기하로 변환하고, D3의 데이터 바인딩은 그 기하를 페이지의 마크로 바꿉니다.
상호작용은 단순한 ‘추가 요소’가 아닙니다—사람들이 확인하는 방식입니다. 밀집된 차트는 설득력 있어도 오해를 낳을 수 있습니다. 사용자가 호버로 값을 확인하고, 필터로 세그먼트를 격리하고, 줌으로 밀집 클러스터를 검사할 수 있을 때 그래픽은 그림이 아니라 사고 도구가 됩니다.
D3 스타일의 상호작용에서 가장 알아보기 쉬운 것은 툴팁입니다. 차트는 깔끔하게 유지하고 필요할 때만 정확한 값을 제공하죠. 좋은 툴팁은 축 레이블을 단순 반복하지 않고 단위, 기간, 출처, 순위 같은 문맥을 더하며 마크를 가리지 않게 위치합니다.
브러싱—클릭하고 드래그해 영역을 선택하는 동작—은 “이 기간에 무슨 일이 있었나?” 또는 “이 클러스터에 어떤 점들이 있나?” 같은 질문을 직접 묻는 방법입니다. D3는 특히 시계열 차트와 산점도에서 이 패턴을 웹에서 접근 가능하게 만들었습니다.
필터링과 결합하면(선택 항목 강조, 다른 항목 희미화, 혹은 재렌더링) 브러싱은 정적인 뷰를 탐색형 뷰로 바꿉니다.
D3는 한 동작이 여러 차트를 가로질러 영향을 미치는 대시보드를 널리 보급했습니다. 막대를 클릭하면 지도가 업데이트되고, 타임라인을 브러싱하면 표가 갱신되며, 점에 호버하면 대응하는 행이 강조됩니다. 이런 링크된 뷰는 사람들로 하여금 범주·지리·시간을 강제로 하나의 과도하게 복잡한 차트에 집어넣지 않고 연결하도록 돕습니다.
대부분의 상호작용은 클릭, mousemove, mouseenter/mouseleave, 그리고 터치 이벤트로 귀결됩니다. D3의 접근법은 비주얼 요소(막대, 점, 레이블)에 직접 동작을 연결하도록 권장해 상호작용이 그래픽에 ‘본래부터 붙어있는 듯’ 느껴지게 합니다.
인터랙티브 차트는 마우스 외 다른 입력 방식에서도 동작해야 합니다. 키보드를 통한 주요 동작(포커스 가능 요소, 명확한 포커스 상태)을 제공하고, 스크린리더용 텍스트 대체(레이블과 설명)를 제공하며 색만으로 의미를 전달하지 마세요. 또한 reduced-motion 선호도를 존중해 툴팁·하이라이트·전환이 방해가 되지 않도록 하세요.
D3는 단순한 아이디어를 대중화했습니다: 전환(transition)은 상태들 사이의 애니메이션 변화입니다. 차트를 통째로 다시 그리는 대신 마크가 이전 위치에서 목표 위치로 움직이게 하여 막대가 자라거나 점이 미끄러지며 레이블이 갱신됩니다. 그 ‘중간 상태’의 움직임은 무엇이 바뀌었는지를 추적하게 해줍니다.
신중하게 쓰인 전환은 명확함을 더합니다:
애니메이션은 데이터와 경쟁할 때 노이즈가 됩니다:
간단한 규칙: 관객이 모션 없이도 즉시 이해할 수 있다면 전환은 은근하게 하거나 생략하세요.
전환은 공짜가 아닙니다. 성능을 위해:
마지막으로 사용자 편의를 기억하세요. reduced-motion 설정을 존중하고(지속 시간 단축 또는 전환 끔), “애니메이션 일시정지” 토글이나 애니메이션을 즉시 업데이트로 대체하는 설정을 제공하면 좋습니다. 시각화에서 모션은 이해를 돕기 위해 있어야지 주목을 강요하면 안 됩니다.
많이 오해되지만 D3는 “차트 라이브러리”가 아닙니다. D3는 기성 바 차트 컴포넌트를 주는 대신 차트를 구성할 수 있는 저수준 빌딩 블록(스케일, 축, 도형, 레이아웃, 선택, 동작)을 제공합니다. 그래서 D3는 엄청나게 유연하지만 때로는 예상보다 더 공이 들게 느껴질 수 있습니다.
“차트를 박아 넣고 띄우기”를 원한다면 보통 상위 수준 라이브러리를 선택합니다. D3는 정밀 도구 세트에 가깝습니다: 어떤 차트인지, 어떻게 그릴지, 어떻게 동작할지를 당신이 결정합니다.
이 선택은 의도적입니다. D3가 비판적 판단을 내리지 않음으로써 고전 차트부터 커스텀 지도, 네트워크 다이어그램, 편집용 그래픽까지 모두 지원할 수 있습니다.
현대 팀에서는 D3를 UI 프레임워크와 같이 사용하는 패턴이 자주 보입니다:
이 하이브리드 접근은 D3가 앱 전체를 관리하게 강요하지 않으면서도 D3의 강점을 활용하게 해줍니다.
실용적 규칙: 프레임워크가 DOM 생성·업데이트를 담당하게 하고, D3는 위치와 도형을 계산하게 하세요.
예를 들어 D3로 값을 픽셀로 매핑(스케일)하고 SVG 경로를 생성하게 하되, 컴포넌트가 <svg> 구조를 렌더링하고 사용자 입력에 반응하게 하세요.
자주 보이는 실수 두 가지:
D3를 특정 작업을 위해 호출하는 툴킷으로 다루면 코드가 명확해지고 차트 유지보수가 쉬워집니다.
D3의 가장 큰 유산은 특정 차트 유형이 아니라, 웹 그래픽이 정확하고 표현력이 있으며 데이터에 밀접하게 연결될 수 있다는 기대를 심어준 것입니다. D3가 널리 퍼진 이후 많은 팀이 시각화를 페이지에 붙인 부차적 요소가 아니라 인터페이스의 일급 구성으로 대하기 시작했습니다.
D3는 데이터 저널리즘에서 초기에 많이 쓰였는데, 그 이유는 워크플로와 잘 맞았기 때문입니다: 기자와 디자이너는 표준 템플릿에 억지로 맞추지 않고 이야기별로 맞춤형 비주얼을 만들 수 있었습니다. 인터랙티브한 선거 지도, 스크롤 기반의 설명 그래픽, 주석이 달린 차트가 더 흔해진 것은 D3 덕분인데, D3가 ‘쉽게 만들었기’ 때문이 아니라 ‘웹 네이티브 빌딩 블록으로 가능하게 했기’ 때문입니다.
공공 데이터 프로젝트에서도 유연성이 큰 이점이었습니다. 공공 데이터는 지저분하고 질의는 도시·정책·청중에 따라 달라집니다. D3의 접근법은 단순히 주의 깊은 라벨링의 간단 차트부터 더 탐색적인 인터페이스까지 데이터에 맞춰 적응하는 프로젝트를 장려했습니다.
팀들이 직접 D3를 쓰지 않더라도, D3가 보편화한 많은 관행은 표준으로 자리잡았습니다: 스케일과 좌표계로 사고하기, 데이터 변환을 렌더링과 분리하기, DOM(또는 Canvas)을 프로그래밍 가능한 그래픽 표면으로 사용하기 등입니다.
D3의 영향은 커뮤니티를 통해서도 확산됐습니다. 한 번에 하나의 아이디어를 보여주는 작은 예제를 게시하는 관습은 초심자가 리믹스하며 배우기 쉽게 했습니다. Observable 노트북은 라이브 코드와 즉각적인 피드백, 공유 가능한 스케치북 형태로 이 전통을 확장했습니다. 라이브러리와 주변 문화가 결합되어 현대 웹 시각화 작업의 모습을 정의하는 데 기여했습니다.
D3는 도구를 설계 도구로 생각할 때 선택하기 쉽습니다. D3는 데이터가 마크(선, 막대, 영역, 노드)로 바뀌는 방식을 세밀하게 제어하게 해주며, 마크가 입력에 어떻게 반응하고 시간이 지남에 따라 어떻게 업데이트되는지를 관리합니다. 그 자유는 대가를 수반합니다: 차트 라이브러리가 대신 결정해줄 많은 선택을 당신이 책임져야 합니다.
도구를 고르기 전 네 가지를 명확히 하세요:
탐색이 필요하고 차트 유형이 ‘기성품’이 아니라면 D3가 설득력을 갖습니다.
D3는 맞춤형 상호작용(브러싱, 링크드 뷰, 진보적 공개), 독특한 디자인(비표준 인코딩, 맞춤 레이아웃 규칙), 또는 렌더링·성능에 대한 정밀 제어(SVG와 Canvas 혼합 등)이 필요할 때 빛을 발합니다. 시각화가 제품 기능이며 팀이 반복적으로 다듬을 대상일 때도 좋습니다.
목표가 공통 차트로 구성된 표준 대시보드이고 빠른 출시가 중요하며 일관된 테마와 접근성 규칙이 필요하다면 상위 수준 라이브러리나 BI 도구가 더 빠르고 안전합니다. 축·범례·반응성·접근성 패턴을 기본으로 제공하므로 직접 구현할 부담이 줄어듭니다.
상당한 가이드를 만들거나 프로젝트를 계획한다면(예: 프로덕션 시각화) 다음을 위해 시간을 배정하세요: 선택과 조인 학습, 스케일, 이벤트 처리, 엣지 케이스 테스트. 최고의 D3 작업은 코딩뿐 아니라 디자인 반복을 포함하므로 양쪽에 시간을 할당하세요.
D3는 실습 학습에 보상이 큽니다. D3 마인드셋을 빠르게 익히는 가장 빠른 방법은 작은 차트 하나를 끝까지 만들어보고, 그걸 단계적으로 개선하는 것입니다.
작고 단순한 데이터셋(10–50행)을 골라 하나의 막대차트나 선차트를 만드세요. 첫 버전은 일부러 단조롭게 유지하세요: 하나의 SVG, 하나의 그룹(<g>), 하나의 시리즈. 올바르게 렌더링되면 개선을 하나씩 추가하세요—호버 툴팁, 하이라이트 상태, 필터링이나 정렬. 이 순서는 업데이트가 신비롭지 않게 자연스레 작동하는 법을 가르쳐줍니다.
참고 포인트를 유지하려면 팀 위키에 진행 노트를 적고 /blog의 예제를 링크하세요.
간단한 규칙: 업데이트하지 못하면 아직 완전히 이해한 것이 아닙니다.
첫 차트 후에는 재사용 가능한 “차트 패턴”(구조, 마진, 업데이트 함수, 이벤트 핸들러)을 문서화하세요. 프레임워크를 쓰지 않더라도 작은 내부 컴포넌트 라이브러리처럼 다루면 시간이 지날수록 공용 어휘와 더 빠른 전달이 가능해집니다.
내부 분석 도구를 만든다면(한 번 짜고 끝내는 차트가 아니라) 주변 앱(인증, 라우팅, 표, 필터, API 엔드포인트)을 프로토타입하는 것이 시각화 작업에 투자하기 전에 도움이 됩니다. Koder.ai 같은 플랫폼은 여기에 유용할 수 있습니다: 채팅으로 React 기반 웹앱을 바이브-코딩하고, 플래닝 모드에서 반복한 뒤 호스팅과 커스텀 도메인으로 배포할 수 있습니다. 다른 상호작용 디자인을 실험할 때 스냅샷과 롤백은 특히 실용적입니다—새 브러싱/줌 흐름을 시도해도 정상 동작 버전을 잃지 않게 해주니까요.
더 깊은 안내는 /docs를, 도구와 지원을 평가할 때는 비교 페이지를 /pricing에 두세요.
마이크 보스토크가 제시한 명확한 사고 모델입니다: 데이터를 DOM에 바인딩하여 각 데이터 항목이 화면상의 ‘마크’(막대, 점, 레이블, 경로 등)에 대응하게 만듭니다. 차트를 봉인된 이미지로 생성하는 대신, SVG/HTML 같은 실제 웹 요소를 업데이트하거나 Canvas에 데이터 기반 로직으로 그립니다.
기존 도구들은 보통 바/선/파이 같은 템플릿을 먼저 제공하고 옵션을 조정하는 방식이었습니다. 반면 D3는 웹 프리미티브(DOM, SVG, Canvas)를 출발점으로 삼고, 스케일, 도형, 축, 레이아웃, 동작 같은 빌딩 블록을 제공합니다. 그 덕분에 맞춤형 상호작용이나 비표준 레이아웃을 직접 설계할 수 있습니다.
브라우저가 다음과 같은 그래픽/구조 기능을 갖추면서 때가 무르익었습니다:
D3는 이 시점에 데이터를 이 네이티브 기능들과 연결하는 방식으로 등장했기 때문에 정적 이미지 대신 웹 고유의 그래픽을 자연스럽게 만들 수 있었습니다.
선택(selection)은 D3가 요소를 찾고 그에 동작을 적용하는 방식입니다. 실무적으로는 컨테이너(예: SVG 그룹)를 선택하고, 만들거나 업데이트할 요소들(예: circle)을 선택한 뒤, 바인딩된 데이터에 따라 x/y, r, fill, 텍스트 등을 설정하는 흐름입니다.
시각화를 데이터와 동기화된 상태로 유지하는 작업 흐름입니다:
이 패턴 덕분에 필터, 실시간 업데이트, 인터랙티브한 정렬 등이 전체를 다시 그리지 않고도 구현됩니다.
D3의 스케일은 데이터 값을 시각적 값(보통 픽셀)으로 변환하는 함수입니다: 데이터 → 스케일 → 화면. 도메인과 레인지를 중앙에서 관리해 코드 곳곳에 수학식을 흩뿌리지 않게 해주며, 많은 스케일은 픽셀을 데이터로 되돌리는 역변환도 지원하므로 호버 값 표시, 브러싱, 줌과 같은 정밀한 상호작용에 필수적입니다.
일반적으로 다음을 기준으로 선택합니다:
D3는 이들 셋 모두를 구동할 수 있도록 데이터-연결과 수학적 계산을 제공합니다.
D3에서 레이아웃은 데이터로부터 기하(geometry) 를 계산해내는 함수나 소규모 시스템을 의미합니다. 스스로 픽셀을 렌더링하진 않고, x/y 위치, 각도, 반지름, 경로, 부모/자식 관계 같은 수치를 생성합니다.
예:
d3.forceSimulation()은 네트워크 노드의 x/y를 계산합니다.D3가 보편화한 상호작용 패턴들입니다:
좋은 규칙은 상호작용을 데이터 업데이트에 연결하고, 다시 렌더링해 시각화가 일관되고 설명 가능하도록 만드는 것입니다.
D3를 선택하세요, 만약:
반면 표준 대시보드용 일반 차트가 빠르게 필요하다면, 상위 수준의 차트 라이브러리나 BI 도구가 더 빠르고 안전한 선택일 수 있습니다.
d3.geoPath()는 GeoJSON을 프로젝션을 통해 SVG 경로로 변환합니다.