무슨 일이 있었나요?
“Where the Romans Fought”, 우리말로 ‘로마인들은 어디서 싸웠나’라는 이름의 인터랙티브 지도 프로젝트가 공개됐어요. 이름 그대로 로마가 벌인 전투들을 지도 위에서 살펴볼 수 있는 웹페이지이고, GitHub Pages에 올라간 개인 프로젝트예요. 거창한 서비스가 아니라 한 사람이 자기 관심사를 데이터로 풀어낸 사이드 프로젝트라는 점이 오히려 매력이에요.
역사 좋아하는 분은 구경만 해도 재밌을 거고, 개발자라면 “이거 나도 만들 수 있겠는데?” 싶을 거예요. 그래서 이번 글에서는 이런 역사 데이터 지도를 직접 만든다면 어떻게 구성하면 좋을지 단계별로 풀어볼게요. 이 프로젝트가 실제로 어떤 스택을 썼는지와는 별개로, 이런 지도에 흔히 쓰는 방법을 소개하는 거예요.
왜 지도로 보면 다를까
연표로 ‘기원전 216년 칸나이 전투, 서기 9년 토이토부르크 숲 전투…’를 읽으면 숫자와 지명이 줄줄이 이어질 뿐이에요. 그런데 같은 정보를 지도에 찍으면 패턴이 보이기 시작해요. 이탈리아 반도에서 시작해 지중해 전체로 퍼져 나가는 확장 흐름이라든지, 후기로 갈수록 라인강·도나우강 같은 국경 지대와 동방에 전투가 몰리는 모습 같은 거요. 텍스트로는 머릿속에서 조립해야 했던 공간 정보를 바로 눈으로 보여주는 것, 이게 데이터 시각화의 힘이에요.
직접 만든다면: 4단계 구성
1단계: 데이터 모으기 — Wikidata SPARQL
전투 데이터를 하나하나 손으로 입력할 필요는 없어요. Wikidata는 위키백과 뒤에 있는 구조화된 데이터베이스인데, SPARQL이라는 질의 언어로 조회할 수 있어요. SQL처럼 생겼지만 ‘주어-술어-목적어’ 관계로 데이터를 찾는 방식이에요. 예를 들면 이렇게요.
SELECT ?battle ?battleLabel ?coord ?date WHERE {
VALUES ?side { wd:Q17167 wd:Q2277 }
?battle wdt:P31 wd:Q178561 ;
wdt:P710 ?side ;
wdt:P625 ?coord .
OPTIONAL { ?battle wdt:P585 ?date . }
SERVICE wikibase:label { bd:serviceParam wikibase:language 'en'. }
}
풀어서 읽으면 “‘전투’의 인스턴스(P31)이면서 참가자(P710)에 로마 공화정이나 로마 제국이 있고, 좌표(P625)가 있는 항목을 찾아줘”라는 뜻이에요. 항목 번호는 query.wikidata.org에서 직접 확인하면서 다듬어 보세요.
함정: 고대 데이터는 불확실해요
데이터를 받았다고 끝이 아니에요. 고대 전투는 위치 자체가 학계에서 논쟁 중인 경우가 많거든요. 토이토부르크 숲 전투는 오랫동안 위치가 불분명했고, 20세기 후반 독일 칼크리제 발굴로 유력한 후보지가 생겼지만 지금도 이견이 있어요. 그래서 좋은 역사 지도는 ‘추정 위치’와 ‘확정 위치’를 구분해서 보여주는 장치가 있으면 좋아요.
날짜도 함정이에요. 역사학 표기에는 0년이 없는데 ISO 8601의 천문학식 연도 표기에는 0년이 있어요. 그래서 -0215가 기원전 216년을 뜻하는 식으로 1년씩 어긋나요. 데이터 소스마다 어떤 규칙을 쓰는지 꼭 확인하고, 자바스크립트 Date 객체 대신 연도를 정수로 따로 저장하는 편이 훨씬 안전해요.
2단계: 지도 그리기
- Leaflet: 가장 가볍고 배우기 쉬워요. 포인트가 수백~수천 개 정도면 충분해요.
- MapLibre GL JS: WebGL 기반 벡터 타일 지도라 확대나 회전이 부드러워요.
- deck.gl: 그려야 할 데이터가 수십만 개쯤 될 때 꺼내는 도구예요.
3단계: 시간 축 넣기
역사 지도의 핵심은 시간이에요. 연도 슬라이더를 두고 그 구간의 전투만 보여주면 로마가 넓어졌다가 줄어드는 모습이 애니메이션처럼 보이거든요. 점이 겹치는 지역은 마커 클러스터링으로 묶어주면 깔끔해요.
4단계: 배포 — 서버 없이 GitHub Pages
이런 형태의 프로젝트가 가진 가장 큰 장점이 바로 여기 있어요. SPARQL 질의는 빌드할 때 한 번만 돌려서 결과를 GeoJSON 파일로 저장하고, 페이지는 그 정적 파일만 읽게 하면 서버가 아예 필요 없어요. 페이지를 열 때마다 Wikidata를 호출하면 느리고 요청 제한에도 걸리니까요. 호스팅 비용 0원에 유지보수 부담도 거의 없어요.
업계 맥락
이런 디지털 인문학 프로젝트는 생각보다 역사가 깊어요. 스탠퍼드의 ORBIS는 로마 시대 도로와 바닷길 네트워크를 모델링해서 그 시절 로마에서 각 도시까지 가는 데 며칠이 걸리고 비용이 얼마나 들었을지 계산해줘요. 이번 같은 개인 프로젝트는 학술 프로젝트보다 규모는 작지만, 공개 데이터와 무료 호스팅만으로 누구나 비슷한 결과물을 낼 수 있다는 걸 보여줘요.
한국 개발자에게 주는 시사점
이건 사이드 프로젝트 주제로 정말 좋아요. 데이터 수집, 정제, 시각화, 배포까지 작아도 완결된 한 사이클을 해볼 수 있거든요. 한국사 버전도 얼마든지 가능해요. 국사편찬위원회 한국사데이터베이스나 공공데이터포털에서 자료를 모으고, 국토교통부 공간정보 오픈플랫폼 브이월드(VWorld) 지도를 배경으로 깔면 ‘임진왜란 전투 지도’나 ‘삼국시대 산성 지도’를 만들어볼 수 있어요. 포트폴리오에 “지도 하나 만들었어요”라고 쓰는 것보다 “흩어진 데이터를 모아 공간적 패턴을 드러냈어요”라고 쓸 수 있는 프로젝트가 훨씬 인상적이겠죠.
마무리
한줄 정리: 공개 데이터, 정적 지도, 무료 호스팅. 이 세 가지만 있으면 누구나 역사를 눈에 보이게 만들 수 있어요.
여러분은 지도 위에 어떤 데이터를 찍어보고 싶으세요? 역사든 맛집이든 출퇴근 경로든, 떠오르는 아이디어를 나눠주세요!
🔗 출처: Hacker News