남해독일마을 웹사이트 리뉴얼

02기술 결정

문제가 무엇이었고, 무엇을 골랐고, 그래서 어떻게 됐는지.

1. 결정 01

   필터 상태를 클라이언트가 아니라 URL에 둔다

   문제

   숙소·축제 목록에는 지역·유형·기간 필터가 있습니다. 처음에는 이것을 클라이언트 상태로 다뤘는데, 관광 사이트의 콘텐츠는 본질적으로 '공유되는' 것이라는 점을 놓친 설계였습니다. 누군가 '이 조건으로 찾은 펜션 목록'을 카톡으로 보내고 싶어도 링크에 담기지 않았습니다.

   선택

   모든 필터를 search params로 옮겼습니다. 상태 변경은 곧 URL 변경이고, 화면은 URL을 읽어 그립니다. 클라이언트 스토어는 UI 토글처럼 공유할 필요가 없는 것만 담당하게 했습니다.

   결과

   필터가 걸린 목록을 그대로 링크로 보낼 수 있게 됐습니다. 부수 효과로 각 조합이 고유 URL을 갖게 되어 검색 엔진이 색인할 수 있는 페이지 수 자체가 늘었고, 뒤로 가기도 사용자가 기대하는 대로 동작했습니다.

2. 결정 02

   ISR로 '자주 안 바뀌지만 가끔 바뀌는' 콘텐츠를 다룬다

   문제

   축제·숙소 정보는 하루에도 몇 번씩 바뀌지는 않지만, 재단 담당자가 수정하면 곧 반영되어야 합니다. 매 요청마다 서버에서 그리면 이미지 많은 페이지가 느려지고, 완전 정적으로 만들면 수정이 반영되지 않습니다.

   선택

   페이지 성격별로 revalidate 주기를 다르게 뒀습니다. 잘 안 바뀌는 소개 페이지는 길게, 축제 목록은 짧게 잡고, 관리자가 저장하는 시점에 on-demand revalidate를 호출해 즉시 갱신되게 했습니다.

   결과

   평상시에는 정적 페이지 수준의 응답 속도를 유지하면서, 담당자가 수정하면 바로 반영됩니다. 트래픽이 몰리는 축제 기간에도 서버 부담이 크게 늘지 않았습니다.

3. 결정 03

   이미지가 많은 페이지는 '빈 공간'부터 없앤다

   문제

   숙소 목록은 카드 하나마다 사진이 들어갑니다. 로딩 중에 이미지 영역이 비어 있다가 채워지면 레이아웃이 밀리고, 사용자는 페이지가 덜컹거린다고 느낍니다.

   선택

   모든 이미지에 고정 비율 컨테이너를 두고 Skeleton UI를 먼저 그렸습니다. `next/image`의 sizes를 화면 폭별로 지정해 모바일에서 데스크톱용 큰 이미지를 받지 않게 했습니다.

   결과

   레이아웃 이동이 사라졌고, 모바일에서 내려받는 이미지 용량이 크게 줄었습니다. 체감 속도가 실제 로딩 시간보다 훨씬 빨라졌습니다.

4. 결정 04

   PC용 인터랙티브 지역 지도를 직접 만든다

   문제

   마을 안의 시설 위치를 보여줘야 하는데, 일반 지도 API를 그대로 쓰면 마을의 분위기가 전혀 전달되지 않습니다. 관광 홍보 사이트에서 지도는 정보이자 비주얼입니다.

   선택

   디자이너가 그린 일러스트 지도 위에 SVG 좌표로 핫스팟을 얹었습니다. 마우스를 올리면 해당 구역이 강조되고 시설 정보가 뜹니다.

   결과

   지도가 정보 전달과 브랜드 표현을 동시에 합니다. 좌표를 데이터로 분리해 두어 시설이 추가돼도 이미지를 다시 만들 필요가 없습니다.

03주요 기능

• 파독 근로자 스토리텔링

  마을의 시작이 된 사람들의 이야기를 스크롤 흐름에 맞춰 풀어내는 섹션. 이 사이트의 정체성이 되는 부분입니다.

• 축제·숙소 통합 정보

  지역 축제와 호텔·펜션 정보를 조건으로 좁혀 볼 수 있고, 조건은 그대로 링크가 됩니다.

• 관리자 시스템 연동

  재단 담당자가 백오피스에서 수정하면 on-demand revalidate로 사이트에 즉시 반영됩니다.

• 인터랙티브 지역 지도

  일러스트 지도 위에 좌표 데이터로 핫스팟을 얹어 시설 위치와 정보를 함께 보여줍니다.

• 검색 노출 최적화

  이미지에 갇혀 있던 텍스트를 마크업으로 꺼내고, 메타데이터·사이트맵·구조화 데이터를 정비했습니다.

04화면

05회고