멋진 여행지도 링크 하나를 AI에게 보여줬더니, 내 11일 일정이 움직이는 지도가 됐다

📝 한줄 요약

다른 사람의 미 서부 여행지도를 그대로 베끼는 대신, 공개된 화면과 코드에서 스크롤 지도라는 구현 원리만 분석해 내 스페인·포르투갈 11일 일정과 연결했다. 첫 배포 뒤 “지도가 움직이지 않는다”는 실제 모바일 피드백까지 반영해, 날짜·카드·지도 카메라가 함께 움직이는 인터랙티브 여행지도로 고쳤다.

바쁘시면 이것만 읽어도 됩니다.

• 출발점은 마음에 든 여행지도 링크 하나였다.

• AI가 처음에는 그 지도를 내 여행으로 오해했지만, “콘텐츠가 아니라 구현기법을 참고하려는 것”이라고 바로잡았다.

• 공개 페이지의 구조를 분석해 지도, 스크롤 카드, 경로 진행선, 날짜 이동의 작동 원리를 분리했다.

• 기존 여행 일정 원장은 건드리지 않고, 같은 데이터에서 /map/ 화면이 자동 생성되도록 만들었다.

• 11일 일정, 105개 이벤트, 20개 경유 좌표가 하나의 스토리 지도에 연결됐다.

• 첫 완료 판정은 틀렸다. 날짜 버튼만 바뀌었을 뿐, 실제 모바일 지도는 손가락으로 움직이지 않았다.

• 실제 지도 중심 좌표가 바뀌는지까지 다시 측정하고 모바일 결함 다섯 가지를 수정했다.

• 최종 결과는 데스크톱·모바일·모션 감소·자바스크립트 실패·글자 200% 환경에서 검증했다.

🎯 이런 분들께 도움됩니다

• 마음에 드는 웹사이트를 발견했지만 무엇을 참고해야 할지 막막한 분

• 여행 일정표를 지도와 이야기 형식으로 보여주고 싶은 분

• AI에게 “비슷하게 만들어줘”라고 요청했다가 결과가 어긋난 경험이 있는 분

• 엑셀·JSON·노션 등 하나의 원본 데이터에서 여러 화면을 만들고 싶은 분

• AI가 “완료했다”고 했을 때 무엇을 검증해야 하는지 고민하는 분

😫 문제 상황: 일정은 있었지만, 여행의 흐름이 한눈에 보이지 않았다

스페인과 포르투갈 여행 일정은 이미 꽤 구체적으로 정리돼 있었다. 날짜별 이동, 숙소, 교통편, 관광 동선, 예약 상태를 확인하는 실행 관제판도 있었다.

하지만 실행 관제판은 정보를 확인하는 데는 강해도, 여행 전체를 하나의 이야기처럼 보여주지는 못했다. 바르셀로나에서 시작해 타라고나, 발렌시아, 쿠엥카, 마드리드, 코르도바, 말라가, 알헤시라스, 메리다, 리스본, 포르투로 이어지는 흐름을 보려면 날짜 카드를 하나씩 읽어야 했다.

그러던 중 다음 여행지도를 발견했다.

• 참고 지도: https://west-coast-2026.cmdspace.work/map/

화면을 내리면 일정 카드가 바뀌고, 그에 맞춰 지도 카메라와 경로가 움직였다. 단순한 장소 목록이 아니라 여행의 속도와 방향을 보여주는 지도였다.

ALT

캘리포니아 루트 - 스크린샷 미리보기 이미지

그림 1. 2026년 8월 9일 공개 URL에서 직접 캡처한 레퍼런스 첫 화면. 여행의 제목과 방향을 한 장면으로 제시한다.

ALT

한국에서 가장 분주한 공항의 위치를 ​​보여주는 지도

그림 2. 같은 공개 URL에서 첫 스크롤 뒤 직접 캡처한 장면. 지도, 현재 정류장 카드, 진행 점이 하나의 상태로 연결돼 있다.

처음 요청은 링크 하나뿐이었다.

https://west-coast-2026.cmdspace.work/map/

AI는 이 링크를 새로운 여행 일정으로 받아들였다. 인천에서 밴쿠버, 시애틀, 샌프란시스코, 로스앤젤레스로 이어지는 여정을 내 여행인 것처럼 설명했다.

그래서 작업의 목적을 바로잡았다.

아, 이건 내 여행이 아니야. 내 여행은 스페인, 포르투갈 여행인데,
이 여행에서 사용된 map 구현기법을 참고하기 위해 가져와봤어.

이 한 문장이 작업의 방향을 완전히 바꿨다.

다른 사람의 여행 콘텐츠를 가져오는 것이 아니라, 공개적으로 확인 가능한 상호작용 원리를 분석해 내 일정에 적용한다.

🌱 처음에는 무엇을 몰랐나

처음에는 “이 지도처럼 만들어줘”라고 말하면 충분할 것 같았다. 하지만 비슷해 보이는 결과를 만드는 일과, 실제로 같은 원리로 작동하는 결과를 만드는 일은 달랐다.

특히 다음을 구분해야 했다.

1. 콘텐츠: 도시, 날짜, 설명, 사진, 행사

2. 표현 방식: 지도와 카드의 배치, 색상, 타이포그래피

3. 상호작용: 스크롤 위치에 따라 활성 일정과 지도 카메라가 바뀌는 규칙

4. 데이터 구조: 일정 원본을 지도용 장면으로 바꾸는 방식

5. 검증 기준: 버튼 색이 바뀌는지와 실제 지도가 움직이는지는 다른 문제

가장 큰 오해는 마지막 항목이었다. 처음에는 날짜 버튼의 활성 상태가 바뀌고 화면이 그럴듯하게 보이면 인터랙티브 지도가 완성된 것으로 생각했다. 실제 휴대전화에서 손가락으로 지도를 움직일 수 있는지, 스크롤한 카드와 지도 중심이 정확히 일치하는지는 별도의 검증이 필요했다.

🛠️ 사용한 도구와 기술

• Hermes Agent의 타디스: 전체 분석, 구현, 검증, 배포 조율

• 브라우저 자동화: 공개 페이지 구조와 실제 동작 확인

• MapLibre GL JS: 인터랙티브 벡터 지도

• OpenFreeMap: 공개 지도 스타일과 타일

• IntersectionObserver: 어떤 일정 카드가 현재 장면인지 판단

• Python 생성기: 여행 일정 원본을 지도 데이터와 화면으로 변환

• Vite·GitHub·Vercel: 빌드, 버전 관리, 운영 배포

• Playwright 기반 브라우저 QA: 데스크톱·모바일·접근성·실패 모드 검증

참고 페이지에서 확인한 GSAP의 스크롤 연출은 분석했지만 그대로 복제하지 않았다. 내 지도에서는 강제 휠 제어 대신 브라우저 기본 스크롤과 IntersectionObserver를 사용했다. 멋진 효과보다 모바일 조작성과 접근성을 우선했기 때문이다.

🔧 작업 과정

1. 먼저 “무엇을 베끼지 않을지” 정했다

레퍼런스 페이지는 공개 브라우저가 내려받는 HTML, CSS, JavaScript 범위에서만 분석했다. 제작자의 내부 프롬프트나 비공개 서버 구조는 알 수 없으므로 추정하지 않았다.

대신 공개 코드와 실제 화면에서 다음 구조를 확인했다.

• 일정 데이터가 한곳에 모여 있음

• 지도 렌더링과 스크롤 제어가 분리돼 있음

• 현재 정류장과 전체 경로 진행률이 별도로 계산됨

• 스크롤이 바뀌면 사용자 정의 이벤트가 지도에 전달됨

• 지도 경로는 한 번에 나타나지 않고 여정 진행에 맞춰 공개됨

• 고정 지도 위로 일정 카드가 지나가는 시각 계층을 사용함

이 분석에서 가장 유용했던 것은 특정 라이브러리 이름이 아니었다.

일정 데이터, 스크롤 상태, 지도 표현을 서로 분리한 뒤 이벤트로 연결한다는 설계 원리였다.

그림 3. 공개 브라우저 전달 범위에서 확인한 구조를 정리한 X-Ray. data.js, 스크롤 제어, MapLibre 렌더링의 책임 분리를 보여준다.

2. 기존 여행 관제판을 덮어쓰지 않았다

새로운 지도를 만들 때 가장 먼저 세운 원칙은 기존 실행 관제판 보존이었다.

그렇게 진행해보자.

이 요청을 받은 뒤 기존 사이트의 첫 화면은 그대로 두고, 인터랙티브 지도는 별도의 /map/ 경로에 만들었다.

• / : 예약, 교통, 숙소, 실행 상태를 확인하는 관제판

• /map/ : 여행의 전체 흐름을 보는 인터랙티브 스토리 지도

같은 여행이라도 목적이 다른 두 화면을 하나로 억지로 합치지 않았다. 실행 정보는 정확성과 밀도가 중요하고, 스토리 지도는 흐름과 맥락이 중요하기 때문이다.

3. 지도용 데이터를 따로 손으로 입력하지 않았다

여행 일정은 이미 하나의 원본 데이터로 관리되고 있었다. 따라서 지도에 도시와 날짜를 다시 입력하면 두 데이터가 곧 어긋날 가능성이 컸다.

그래서 다음 파이프라인을 만들었다.

여행 일정 원본
→ 공개 가능한 일정만 추출
→ 날짜별 장면과 경유 좌표 생성
→ 지도용 데이터·HTML·CSS·JavaScript 생성
→ 공개 사이트 동기화
→ 검증 후 배포

지도는 원본이 아니라 파생 화면이 됐다. 일정이 바뀌면 원본을 수정하고 같은 배포 절차를 실행하면 지도도 다시 생성된다.

최초 구현에서는 다음 데이터가 연결됐다.

• 여행 장면: 11일

• 일정 이벤트: 105개

• 경유 좌표: 20개

• 날짜 이동 버튼: 11개

일정 카드에는 날짜, 도시, 숙소, 주요 이동과 상세 일정을 넣었다. 지도에는 현재 장면의 도시와 누적 경로를 표시했다.

4. 레퍼런스를 닮되, 불편함까지 복제하지 않았다

레퍼런스의 장점은 살리고 내 사용 환경에 맞지 않는 부분은 바꿨다.

이 과정에서 “참고한다”는 의미가 분명해졌다.

좋은 레퍼런스 활용은 화면을 복제하는 일이 아니라, 작동 원리를 분해한 뒤 내 데이터와 사용 조건에 맞게 다시 조립하는 일이다.

5. 첫 배포는 성공처럼 보였지만, 실제로는 실패였다

로컬 빌드와 여러 화면 검사를 통과한 뒤 지도를 배포했다. 날짜 버튼을 누르면 활성 상태가 바뀌고 해당 카드로 이동했다. 자동 검사도 통과했다.

하지만 실제 모바일에서 사용해 본 뒤 문제가 발견됐다.

그런데 실행해보니 지도가 움직이지 않아. interactive하지 않아.

이 피드백이 이번 작업의 가장 중요한 전환점이었다.

처음 완료 판정은 화면 상태의 변화만 확인했다. 날짜 숫자와 카드가 바뀌는지는 봤지만, 손가락 드래그 뒤 지도 중심 좌표가 실제로 변하는지는 측정하지 않았다.

즉, 인터랙티브처럼 보이는 것과 실제로 인터랙티브한 것은 달랐다.

이미지 근거 경계: 최초 장애 당시의 화면은 독립적으로 검증 가능한 원본 캡처가 보존돼 있지 않았다. 그래서 현재 화면을 과거의 “실패 화면”인 것처럼 재연해 넣지 않았다. 실패 서술은 당시 사용자 피드백, 수정 이력, 재검증 기록에 근거하고, 아래 이미지는 수정 후 운영 화면을 새로 캡처한 것이다.

6. 한 가지 버그가 아니라 다섯 가지 결함이 겹쳐 있었다

실제 모바일 환경을 다시 재현하자 여러 문제가 동시에 발견됐다.

1. 지도 자체가 직접 조작을 막는 설정으로 생성돼 있었다.

2. 화면에서는 투명해진 정적 SVG가 지도 위에 남아 터치 이벤트를 가로챘다.

3. 모바일 일정 카드가 고정 지도를 덮어, 카메라가 움직여도 사용자에게 보이지 않았다.

4. 현재 카드 판정이 한 장 늦게 바뀌었다.

5. 일정 카드용 스타일이 지도 출처 표시까지 펼쳐 화면을 가렸다.

문제를 고칠 때는 “지도가 움직이게 해줘”라는 한 문장을 기능 단위로 나눴다.

• 한 손가락으로 지도 이동

• 두 손가락으로 확대·축소

• + / − 버튼으로 직접 확대·축소

• 날짜 버튼을 누르면 해당 도시와 카드가 함께 보임

• 카드를 스크롤하면 지도 카메라가 같은 장면으로 이동

• 지도와 현재 카드가 한 화면에서 서로 가리지 않음

• 출처 표시는 작게 접히되 접근 가능함

7. 전환점: “완료 판정도 기능과 같은 수준으로 설계해야 한다”

수정 뒤에는 버튼 색이나 화면 캡처만 보지 않았다. 손가락 드래그 전후의 지도 중심 좌표를 직접 비교했다.

• 변경 전 지도 중심: [2.1734, 41.3851]

• 변경 후 지도 중심: [0.2898, 41.6022]

• 중심 좌표 변화량: 1.8961

이 글의 v2 이미지 캡처 때도 같은 검사를 다시 실행했다. 모바일 장면 3에서 지도 중심이 [-3.0500, 39.1000]에서 [0.0087, 38.7516]으로 바뀌었고, 변화량은 3.0785였다. 브라우저 예외는 0건이었다.

그림 4. 390×844 모바일 뷰에서 날짜 3, 경로, 지도 카메라, 현재 일정 카드가 함께 보이는 동기화 상태.

그림 5. 같은 장면에서 지도를 직접 드래그한 뒤의 화면. 일정 카드는 유지되지만 지도 중심은 지중해 쪽으로 실제 이동했다.

또한 2·4·6·8·11번째 카드로 이동했을 때 활성 날짜, 카드, 지도 장면이 정확히 일치하는지 확인했다. 지도와 카드의 실제 화면 위치도 측정해 서로 겹치지 않는지 검사했다.

여기서 얻은 가장 큰 교훈은 다음과 같다.

사용자가 체감하는 동작을 숫자로 읽어야 한다.
인터랙티브 지도라면 클래스 이름이나 버튼 상태가 아니라 카메라 중심이 실제로 변했는지를 검증해야 한다.

✅ 결과

완성된 지도

• 인터랙티브 여행지도: https://travel-spain-2026.vercel.app/map/

• 원래 실행 관제판: https://travel-spain-2026.vercel.app/

• 참고한 공개 지도: https://west-coast-2026.cmdspace.work/map/

그림 6. 1440×1000 데스크톱에서 10월 3일 장면을 선택한 운영 화면. 누적 경로, 지도, 현재 일정 카드, 날짜 이동 바가 한 화면에 보인다.

Before vs After

최종 검증 범위

• 데스크톱 1440×1000

• 모바일 390×844

• 모션 감소 설정

• JavaScript 차단

• 글자 크기 200%

• 날짜 버튼 44×44px

• 가로 넘침 0

• 콘솔·페이지 오류 0

• 운영 지도·데이터 URL 응답 확인

• 실제 터치 드래그 후 지도 중심 변화 확인

최종 운영 판정은 PRODUCTION_FINAL_PASS였다.

💬 이 과정에서 배운 AI 활용 팁

1. 레퍼런스는 “모양”보다 “책임 분리”를 분석한다

“이것처럼 만들어줘”만으로는 AI가 색상과 배치부터 따라갈 수 있다. 다음 질문을 함께 던지면 훨씬 재사용 가능한 결과가 나온다.

• 데이터의 원본은 어디인가?

• 스크롤 상태는 누가 결정하는가?

• 지도는 어떤 이벤트를 받는가?

• 화면이 깨질 때 어떤 폴백이 남는가?

• 사용자가 직접 조작할 수 있는가?

2. 레퍼런스 콘텐츠와 내 콘텐츠를 먼저 분리한다

처음 AI가 미 서부 일정을 내 여행으로 받아들인 것처럼, 링크 하나만 주면 대상과 목적이 섞일 수 있다.

따라서 초기에 다음을 명시하는 것이 좋다.

이 링크의 콘텐츠를 가져오려는 것이 아니다.
공개적으로 확인 가능한 구현기법만 분석하고,
실제 데이터는 [내 원본]을 사용한다.

3. 원본과 파생 화면을 분리한다

지도 화면을 직접 수정하면 일정이 바뀔 때마다 같은 내용을 여러 곳에서 고쳐야 한다. 원본 일정은 한곳에 두고 관제판, 지도, PDF 등을 파생시키면 서로 다른 화면의 내용이 어긋나는 문제를 줄일 수 있다.

4. “성공처럼 보이는 상태”를 경계한다

이번 첫 배포에서는 날짜 버튼과 카드가 바뀌었다. 자동 검사도 일부 통과했다. 그러나 핵심 기능인 직접 지도 조작은 실패했다.

완료 전에 다음을 묻는 것이 좋다.

• 사용자가 하려는 핵심 행동은 무엇인가?

• 그 행동 뒤 내부 상태가 실제로 바뀌었는가?

• 변화가 화면에서 보이는가?

• 실제 휴대전화에서도 같은가?

5. 사용자 현장 피드백은 회귀검사로 남긴다

한 번 고친 버그를 설명으로만 남기면 다시 생길 수 있다. 이번에는 지도 직접 조작, 투명 레이어의 터치 차단, 카드와 지도 겹침, 장면 지연, 출처 표시 문제를 공개 검증 스크립트의 검사 항목으로 추가했다.

⚠️ 이렇게 하면 안 됩니다

1. 링크를 주고 곧바로 복제부터 요청하기
   콘텐츠, 디자인, 상호작용, 데이터 구조가 섞인다.

2. 원본 데이터와 지도 데이터를 따로 관리하기
   일정 변경 뒤 두 화면이 서로 다른 내용을 보여줄 가능성이 커진다.

3. 스크린샷만 보고 인터랙션 완료라고 판단하기
   정적인 화면도 얼마든지 인터랙티브처럼 보일 수 있다.

4. 데스크톱 검사만 통과하고 모바일을 완료 처리하기
   터치 이벤트, 고정 레이어, 브라우저 UI 때문에 모바일에서만 생기는 결함이 있다.

5. 레퍼런스의 모든 효과를 그대로 가져오기
   강한 스크롤 연출은 멋질 수 있지만 사용자의 기본 조작과 접근성을 해칠 수 있다.

🌍 다른 업무에 적용한다면?

이 방식은 여행지도에만 쓸 수 있는 방법이 아니다.

프로젝트 진행 현황판

하나의 업무 원장에서 단계, 담당자, 상태를 읽어 타임라인·칸반·보고서 화면을 각각 만들 수 있다. 화면마다 데이터를 손으로 다시 입력하지 않아도 된다.

사건·법률 타임라인

계약 체결, 행위 시점, 법 개정, 처분, 불복, 판결을 하나의 원장으로 관리하고, 독자용 시간축과 쟁점별 화면을 파생할 수 있다.

강의·연구 탐색 지도

강의 순서나 연구 주제를 장면으로 만들고, 관련 문서·근거·개념 그래프가 현재 장면과 함께 바뀌도록 구성할 수 있다.

공통 원리는 같다.

하나의 검증된 원본
→ 용도별 파생 데이터
→ 서로 다른 화면
→ 실제 사용자 행동 기준 검증

🤝 배워서 남 주기

이번 결과에서 가장 재사용 가치가 큰 것은 특정 여행지도 코드가 아니다. 다음 세 가지 방법이다.

1. 레퍼런스를 콘텐츠·표현·상호작용·데이터 구조로 분해하는 질문법

2. 기존 원본을 보존하고 새 화면을 파생 뷰로 만드는 구조

3. 사용자 행동을 실제 상태 변화로 검증하는 완료 기준

누구나 마음에 드는 웹사이트를 발견할 수 있다. 중요한 것은 “똑같이 만들어줘”에서 멈추지 않고, 무엇이 좋은지 분해하고 자기 데이터에 맞게 다시 설계하는 것이다.

🕊️ 널리 도움이 되는 지점

개발 경험이 많지 않은 사람도 좋은 레퍼런스를 발견하고 AI와 함께 구조를 분석할 수 있다. 다만 AI의 첫 해석과 첫 완료 판정을 그대로 받아들이지 않고, 목적을 교정하고 실제 동작을 검증해야 한다.

이 과정을 공개하면 비개발자도 다음을 배울 수 있다.

• 링크 하나를 구현 요구사항으로 바꾸는 법

• 남의 콘텐츠를 복제하지 않고 원리만 참고하는 법

• 하나의 원본에서 여러 결과물을 만드는 법

• AI가 만든 결과를 실제 사용자 행동으로 검증하는 법

🚀 앞으로의 계획

현재 지도는 여행 일정의 흐름과 직접 조작에 초점을 맞췄다. 다음 단계에서는 필요에 따라 다음을 추가할 수 있다.

• 도시별 대표 사진과 장면별 시각 자료

• 이동 구간별 교통수단 표현

• 현장 음성 메모와 여행 기록

• 예약 상태와 위험 Gate의 선택적 표시

• 오프라인에서도 읽을 수 있는 경량 지도 패키지

다만 기능을 늘리기 전에 현재의 원본 파생 구조와 모바일 조작성을 계속 유지하는 것이 우선이다.

📋 재사용 가능한 프롬프트

프롬프트 1: 마음에 드는 웹사이트의 구현 원리 분석

다음 공개 웹페이지를 분석해 주세요: [레퍼런스 URL]
콘텐츠를 복제하지 말고, 브라우저가 공개적으로 내려받는 범위에서 데이터 구조, 화면 구성, 상호작용 상태, 사용 라이브러리, 이벤트 흐름, 모바일·접근성·실패 폴백을 분리해 설명해 주세요.
확인한 사실과 추정을 구분하고, 내 프로젝트 [프로젝트 설명]에 적용할 때 유지할 점·바꿀 점·버릴 점을 표로 정리해 주세요. 아직 구현하지 말고 먼저 적용 설계와 검증 기준을 제시해 주세요.

프롬프트 2: 기존 원본을 보존한 파생 화면 만들기

내 원본 데이터는 [원본 파일 또는 데이터베이스]입니다. 이 원본을 수정하거나 같은 정보를 새 화면에 다시 수동 입력하지 말고, [새 화면 목적]에 필요한 데이터만 자동 파생해 주세요.
기존 화면 [기존 화면 경로]은 보존하고 새 화면은 [새 경로]에 분리하세요. 원본 변경 시 새 화면도 재생성되는 단일 파이프라인을 만들고, 원본·파생 데이터·최종 화면의 일치 여부를 해시 또는 구조 검사로 검증해 주세요.

프롬프트 3: “보인다”가 아니라 “작동한다”를 검증하기

이 기능의 핵심 사용자 행동은 [예: 손가락으로 지도 이동]입니다. 버튼 활성화나 스크린샷만으로 완료 판정하지 말고, 행동 전후의 실제 내부 상태 [예: 지도 중심 좌표]가 변하는지 측정해 주세요.
데스크톱·모바일·터치·키보드·모션 감소·JavaScript 실패 환경을 구분해 검사하고, 실패가 발견되면 원인→수정→같은 검사 재실행 순서로 검증 영수증을 남겨 주세요.