일본 철도 지도 프로젝트에서 배우는 작은 웹 도구의 차별화

개인 프로젝트를 생각하다가 비슷한 서비스가 있다는 이유로 접는 경우가 있습니다. 이미 검색도 되고 지도도 있는데 내가 하나 더 만들어야 할 이유를 찾기 어려워서입니다. 하지만 같은 데이터를 다루더라도 사용자가 무엇을 바라보게 하는지에 따라 도구의 인상은 달라질 수 있습니다.

2026년 10월 5일 일본의 제작자 ‘地図とかデザインとか’는 약 600개 철도 노선의 조감도를 볼 수 있는 사이트 제작기를 공개했습니다. 옛 조감도 화가 요시다 하쓰사부로의 표현에서 출발한 작업입니다. 이 글에서는 그 제작기를 읽고, 작은 도구를 기획할 때 가져올 수 있는 판단 방법을 정리합니다.

저도 서비스를 만드는 개발자이지만 이 지도 프로젝트의 구현이나 성능을 직접 검증한 것은 아닙니다. 제작자가 밝힌 사실과 제 기획 제안을 구분하겠습니다. 원작의 화면과 이미지를 복제하는 튜토리얼이 아니라, 자기 관심사를 어떤 규칙으로 바꿀지에 관한 이야기입니다.

기능 목록보다 바라보는 방식을 먼저 정합니다

제작기는 철도 주변을 한 장의 그림처럼 보여 주려는 의도에서 출발합니다. 실제 지형 데이터를 변형해 그리며, Three.js를 사용했다고 설명합니다. 제작자가 기획과 시각적 판단을 맡고 Claude가 계산·구현·데이터 처리를 도운 역할 분담도 소개합니다.

제가 주목한 부분은 지도라는 익숙한 분류 안에서도 목표가 충분히 구체적이라는 점입니다. 모든 목적의 지도와 경쟁하기보다 특정한 시선으로 노선 주변을 보게 합니다. 작은 도구의 차이는 기능의 개수보다 사용자가 첫 화면에서 이해하는 질문에 있을 수 있습니다.

자기 프로젝트에 적용한다면 ‘독서 도구를 만든다’보다 ‘읽다가 멈춘 책에서 다시 시작할 위치를 찾는다’가 더 분명한 목표입니다. ‘사진을 정리한다’보다 ‘같은 장소의 계절 차이를 한 화면에서 본다’도 좋습니다. 이 정도로 질문을 좁히면 무엇을 크게 보여 주고 무엇을 덜어낼지 결정하기 쉬워집니다.

기획 문장은 기능명 없이 써 보는 편이 도움이 됩니다. 누가 어느 순간 무엇을 이해하거나 결정해야 하는지 적습니다. ‘검색, 필터, 공유’는 구현 항목이지만 ‘낯선 노선이 어떤 풍경을 지나는지 살펴본다’는 사용 목적입니다. 목적이 정해져야 기능을 빼도 되는 이유를 설명할 수 있습니다.

취향을 재현 가능한 표현 규칙으로 바꿉니다

보기 좋은 화면을 만들고 싶다는 생각만으로는 결과를 평가하기 어렵습니다. 색을 바꿀 때마다 더 나아진 것 같다가도 다음 날 원래 모습이 나아 보입니다. 개인의 취향을 버릴 필요는 없지만, 반복해서 적용할 수 있는 규칙으로 적어 두면 판단이 흔들리는 범위를 줄일 수 있습니다.

예를 들어 독서 기록이라면 책 표지를 가장 크게 보여 줄지, 마지막으로 남긴 문장을 먼저 보여 줄지 정합니다. 사진 비교라면 촬영 날짜를 정렬 기준으로 삼을지 같은 구도로 묶을지 고릅니다. 두 방법 모두 가능하지만 사용 목적과 연결되지 않으면 화면은 정보가 많은 보관함에 머물기 쉽습니다.

기획 질문	규칙으로 적는 예시
처음 무엇을 알아야 합니까?	중단한 위치와 다음 행동을 첫 화면에 둡니다.
무엇을 비교합니까?	같은 기준으로 묶인 자료만 나란히 놓습니다.
어떤 정보를 줄입니까?	현재 판단에 필요 없는 상세 항목은 접습니다.
예외는 어떻게 보입니까?	자료가 없거나 기준에 맞지 않으면 이유를 표시합니다.

규칙에는 적용하지 않을 상황도 필요합니다. 자료가 한 건뿐인데 비교 화면을 억지로 만들거나, 제목이 긴 자료를 잘라서 뜻을 바꾸면 목적을 해칩니다. 정상적인 예시만 골라 완성도를 판단하지 말고 빈 값, 긴 이름, 중복 항목을 함께 놓아 보는 편이 좋습니다.

화면에 사실을 단순화하거나 변형한 부분이 있다면 사용자가 그 성격을 이해할 수 있게 해야 합니다. 개념을 설명하는 그림과 정확한 측정 도구는 기대가 다릅니다. 어느 범위까지 믿고 사용할 수 있는지 짧게 알려 주는 설명 역시 디자인의 일부라고 생각합니다.

데이터가 들어오는 순간 검수할 일이 생깁니다

제작자는 공개 데이터의 역명·좌표·명소 선택에서 생긴 오류와 모바일 메모리 문제도 기록했습니다. 멋진 결과 뒤에 데이터를 고르고 바로잡는 과정이 있었다는 뜻입니다. 이 사례를 ‘AI가 한 번에 완성해 준 지도’로 줄이면 정작 재사용할 만한 작업은 빠집니다.

내 도구의 데이터도 예외가 아닙니다. 이름이 같아도 다른 대상일 수 있고, 철자가 달라도 같은 대상일 수 있습니다. 최신이라고 표시된 자료가 모든 항목에서 동시에 갱신되는 것도 아닙니다. 항목을 많이 가져오는 일과 같은 기준으로 읽을 수 있게 만드는 일을 구분해야 합니다.

처음에는 전체 데이터를 모으기보다 열 건 정도의 작은 묶음으로 표현 규칙을 확인할 수 있습니다. 서로 비슷한 정상 자료만 고르지 말고 경계에 있는 자료를 섞습니다. 이름이 긴 항목, 빠진 값이 있는 항목, 같은 이름이 반복되는 항목에서 도구의 약속이 유지되는지 살펴봅니다.

• 원본 출처와 확인 날짜를 항목에 연결합니다.
• 원본 값과 표시용으로 정리한 값을 구분합니다.
• 자동으로 합치거나 제외한 기준을 문장으로 남깁니다.
• 사용자가 잘못된 정보를 발견했을 때 알려 줄 경로를 둡니다.
• 수정이 원본 갱신에 덮어쓰이지 않도록 처리 방식을 정합니다.

공개된 데이터라는 이유만으로 출처 표시나 이용 조건을 생략해서는 안 됩니다. 가져온 자료마다 조건을 확인하고 실제 사용하는 범위에 맞춰 기록합니다. 원작자의 이미지를 소개하고 싶을 때도 데이터 이용 조건과 이미지 재사용 조건을 같은 것으로 취급하지 않아야 합니다.

AI에는 작업을 맡기고 판단 기준은 남깁니다

AI에게 작은 도구를 만들어 달라고 요청할 때 화면 설명만 주면 그럴듯한 결과는 빨리 나올 수 있습니다. 그러나 어떤 자료를 제외하고 어떤 오류를 드러내야 하는지는 생략되기 쉽습니다. 결과를 확인하는 사람에게 필요한 것은 코드 전체를 외우는 능력보다 성공과 실패를 구분할 기준입니다.

저라면 첫 요청에 입력 예시, 표시 규칙, 예외 세 가지를 넣겠습니다. ‘책 열 건을 보여 주세요’에서 멈추지 않고 ‘날짜가 없으면 마지막으로 배치하고, 중복 제목은 합치지 말고 저자로 구분해 주세요’처럼 적습니다. 이 규칙이 있어야 다음 수정에서 무엇이 좋아졌고 무엇이 깨졌는지 설명할 수 있습니다.

검수도 한 번에 모든 화면을 둘러보는 대신 목적을 따라 진행할 수 있습니다. 사용자가 첫 자료를 열고, 비교하고, 다음 행동을 결정하는 흐름을 따라가 봅니다. 데이터가 많아질 때의 부담은 별도 항목으로 남기고, 작은 표본이 잘 보였다는 사실을 전체 규모의 성능으로 확대하지 않습니다.

처음부터 계정, 결제, 커뮤니티를 붙일 필요는 없습니다. 화면 하나가 사용자의 질문에 답하는지 먼저 설명할 수 있어야 합니다. 다만 범위를 작게 한다는 말이 오류 안내와 출처를 빼라는 뜻은 아닙니다. 결과를 신뢰할 수 있게 만드는 최소한의 정보는 처음부터 도구 안에 있어야 합니다.

마치며: 내 관심사에서 한 가지 관찰을 고릅니다

작은 웹 도구가 반드시 새로운 데이터나 거대한 기능에서 출발하는 것은 아닙니다. 익숙한 자료에서 다른 사람이 지나친 관계를 보고, 그 관찰을 일관된 화면으로 만드는 방법도 있습니다. 차별화라는 말이 막막하다면 내가 무엇을 오래 들여다보는 사람인지부터 생각해 볼 수 있습니다.

오늘은 관심 있는 자료 열 건과 보여 주고 싶은 관계 한 가지를 적어 보시길 권합니다. 그다음 첫 화면에서 사용자가 알게 될 사실을 한 문장으로 써 봅니다. 구현 기술을 선택하기 전에 그 문장이 분명하다면 만들다가 범위가 커졌을 때도 돌아올 기준이 생깁니다.

출처: 제작자 ‘地図とかデザインとか’의 철도 조감도 제작기(2026-10-05, 확인 2026-10-11). 원작 사이트도 함께 남깁니다. 본문 기획표는 제작기 전체의 번역이 아닌 개인 프로젝트용 제안입니다.