⟨혹성의 아이⟩ 홈페이지

배경과 문제

친구의 졸업작품인 단편영화 ⟨혹성의 아이⟩를 소개하고 영화와 관련 상품을 홍보하기 위해 시작한 홈페이지입니다. 첫 버전은 HTML, CSS와 바닐라 JavaScript로 화면을 만들고 Flask, Gunicorn과 Nginx를 이용해 제공했습니다.

영화 촬영을 마치고 작품 공개와 상품 출시를 준비하면서 콘텐츠의 종류와 양이 늘어났습니다. 1.0에는 없었던 영상 영역도 2.0에서 YouTube 임베드 형태로 새롭게 추가했습니다. 한 파일에서 시작한 Flask 애플리케이션은 화면 구조를 파악하고 반복되는 요소를 관리하기 어려워졌고, Azure 서버 환경을 직접 관리하며 변경 사항을 반영하는 방식은 잦은 콘텐츠 갱신과는 맞지 않았습니다.

담당 범위

초기 Flask 홈페이지부터 2.0 마이그레이션까지 웹 개발 전반을 담당했습니다. 작품과 상품, 콘텐츠와 소셜 영역의 정보 구조를 정리하고 Next.js 프론트엔드, Flask 방명록 API, 이미지와 YouTube 임베드의 로딩 최적화, Cloudflare Pages 배포 환경을 구성했습니다.

핵심 기술적 결정

콘텐츠가 많은 프론트엔드를 Next.js로 재구성

페이지별 템플릿과 스크립트가 얽힌 기존 구조를 React 컴포넌트와 파일 시스템 기반 라우팅으로 다시 나눴습니다. 상품과 포스터, YouTube 영상 임베드처럼 공개 시점에 계속 추가되는 콘텐츠를 독립된 화면 단위로 관리하고, Tailwind CSS를 이용해 페이지마다 반복되는 간격과 색상, 타이포그래피 규칙을 일관되게 적용했습니다.

마이그레이션의 목적은 프레임워크 자체를 바꾸는 데 있지 않았습니다. 콘텐츠 구조가 코드 구조에 드러나게 만들고, 프론트엔드 패키지와 빌드 도구를 한 환경에서 관리해 이후 변경 비용을 낮추는 것이 기준이었습니다. 선택 과정은 Next.js를 선택한 이유에 별도로 기록했습니다.

정적 홍보 화면과 방명록 API 분리

영화 정보와 상품, 이미지 콘텐츠는 Cloudflare Pages에서 제공하고 사용자 입력과 데이터 저장이 필요한 방명록은 기존 Flask 서버에서 프론트엔드를 제거한 API로 유지했습니다. 모든 기능을 한 번에 다시 작성하기보다 변경이 잦은 공개 화면과 서버 상태가 필요한 기능을 나눠, 마이그레이션 범위를 통제하면서 기존 데이터를 계속 사용할 수 있게 했습니다.

필요할 때만 YouTube 플레이어 로드

영상 콘텐츠를 추가할 때, 영상 파일을 홈페이지로 직접 전송하지 않고 YouTube로 임베드했습니다. 다만 iframe이 YouTube 플레이어 스크립트와 외부 리소스를 첫 화면부터 불러오며 성능을 떨어뜨렸습니다. 브라우저의 홈페이지 로드 성능을 개선하기 위해, 최초에는 YouTube 영상 섬네일만 표시하고 사용자가 동영상 재생을 선택한 시점에 iframe을 생성하도록 변경했습니다. 또한, 홈페이지가 직접 제공하는 이미지는 별도로 WebP로 변환해 전송량을 줄였습니다.

이 방식으로 Lighthouse 성능 점수가 약 10점 상승했고, 초기 페이지가 내려받는 외부 리소스의 양은 약 1MB 줄었습니다. 사용자가 아직 요청하지 않은 외부 기능은 뒤로 미룬다는 원칙을 실제 수치로 확인했습니다. 자세한 과정은 YouTube 임베드 개선 기록에 남겼습니다.

콘텐츠 배포를 서버 운영에서 분리

Cloudflare Pages가 Git 변경 사항을 빌드하고 배포하도록 구성해, 콘텐츠를 수정할 때마다 Azure 서버의 배포 환경을 직접 관리하고 변경 사항을 반영하던 과정을 없앴습니다. 배포 이력과 롤백을 플랫폼에서 관리하고 Cloudflare의 CDN, 캐시와 Web Analytics를 함께 사용할 수 있다는 점도 선택 기준이었습니다.

반면 Next.js 기능 중 Edge Runtime과 호환되지 않는 부분은 빌드 단계에서 제약이 있었고, 당시에는 같은 조합의 문제 해결 자료가 많지 않았습니다. 정적 프론트엔드에 필요한 기능과 플랫폼 제약을 함께 확인하며 적용했습니다. 관련 판단은 Cloudflare Pages 배포 기록에서 확인할 수 있습니다.

결과

작품 소개와 영화 스틸, 상품, 포스터와 콘셉트 아트, YouTube 영상과 방명록을 하나의 홈페이지로 연결했습니다. 공개 콘텐츠는 Git 기반의 자동 배포 흐름으로 옮기면서도 기존 방명록 데이터와 API는 유지했습니다. 이미지와 외부 플레이어의 로딩 방식을 개선해 Lighthouse 성능 점수를 약 10점 높이고 초기 페이지가 내려받는 리소스의 양을 약 1MB 줄였습니다.

완성된 홈페이지는 grnplnt.99haus.net에서 확인할 수 있습니다.

회고

마이그레이션은 기존 코드를 모두 새 기술로 치환하는 작업이 아니었습니다. 변경 주기와 실행 환경이 다른 부분을 구분하고, 정적인 콘텐츠는 CDN에 가깝게 두면서 상태가 필요한 기능은 API로 남기는 편이 이 프로젝트에는 더 현실적이었습니다. 화면 구조와 배포 방식, 외부 미디어의 로드 시점까지 함께 다루며 콘텐츠 중심 사이트에서도 프론트엔드 구조와 운영 설계가 사용자 경험에 직접 영향을 준다는 점을 배웠습니다.