소속감 하나로 직접 팀을 꾸리고, 사용자 피드백과 기술 전환으로 두 차례 고도화를 이끈 웹사이트
Overview
동아리의 역사, 활동 내용, 주요 성과를 정리해 제공
과거 연주회 정보와 포스터 제공
악기 심리 테스트, 클래식 이상형 월드컵, 클래식 능력고사 등 게임형 콘텐츠 제공
메인 배너와 팁, 연주회 정보, 연혁, 신입 모집 포스터 등 운영 콘텐츠 관리
Technology
동아리 소개와 연주회 정보를 SSG와 ISR로 사전 렌더링해 검색 엔진이 수집할 수 있는 구조로 전환했습니다. Express 서버의 데이터 조회와 통계 기록을 Route Handler와 서버 컴포넌트로 옮겨 서버 하나로 운영했습니다.
연주회와 게임마다 필요한 데이터와 전달할 값을 타입으로 명시했습니다. 잘못된 데이터 사용이나 누락된 값을 실행 전에 확인해 마이그레이션 과정의 실수를 방지했습니다.
EC2에 직접 설치한 MySQL의 관리 부담을 줄이기 위해 관리형 데이터베이스로 전환했습니다. 연주회와 연주곡, 월드컵과 후보 목록처럼 함께 조회하는 데이터 단위가 명확해 문서 기반 구조가 적합했습니다.
게임 데이터 조회의 로딩 상태, 오류 상태, 캐시를 일관되게 관리했습니다. 게임별로 캐시를 구분하고, 변경 빈도가 낮은 후보와 문제 데이터는 불필요한 자동 재조회를 억제했습니다.
기존 styled-components에서는 스타일을 위한 컴포넌트를 별도로 정의해야 했지만, Tailwind는 마크업 안에서 스타일을 바로 확인하고 수정할 수 있습니다. 간격이나 색상 같은 값을 정해진 유틸리티 기준으로 적용할 수 있어 스타일의 일관성을 유지하기 좋다고 판단했습니다.
관리자 페이지 접근을 Google 로그인으로 인증하고, 서버에서 세션 쿠키를 발급해 관리자 요청을 검증했습니다.
CRA 프론트엔드와 Express 백엔드로 분리된 기존 프로젝트의 페이지, 컴포넌트, API 흐름을 분석하고, 반복적인 코드 변환 작업에 활용했습니다. 렌더링 방식, 서버와 클라이언트의 역할 구분, 데이터 구조는 직접 설계하고, AI가 작성한 코드는 검토한 뒤 반영했습니다.
Key Points
클래식 이상형 월드컵에서 새 이미지가 등장할 때마다 로딩이 발생해 선택 흐름이 끊겼습니다.
64강의 32개 대결에서 새 이미지 요청이 반복되며, 대결마다 최대 약 2초의 대기가 발생했습니다. 반면 32강부터는 이미 불러온 이미지를 재사용해, 캐시에서 약 2ms에 처리됐습니다.
이미 불러온 이미지가 캐시에서 빠르게 처리되는 점을 활용해, 선정된 64장을 게임 시작 전에 병렬로 로딩했습니다. 이미지의 onload 이벤트로 준비 상태를 확인하고, 대기 중에는 로딩 UI를 제공했습니다. 게임 진행 중에는 미리 받아 둔 이미지를 사용하도록 구성했습니다.
대결마다 반복되던 대기를 게임 시작 전 한 번의 준비 과정으로 옮겼습니다. 측정 환경에서 사전 로딩은 약 2초, 이후 캐시된 이미지의 리소스 처리 시간은 약 2ms였습니다.
다운로드 속도 자체를 높인 것이 아니라, 대기 시점을 조정해 게임 흐름을 개선했습니다.
기존 CRA 기반 사이트는 JavaScript 실행 후 콘텐츠가 표시되어 초기 HTML에 동아리 소개와 연주회 정보가 담기지 않았습니다.
또한 robots 정책이 홈을 제외한 대부분의 경로를 차단해 검색 엔진이 공개 콘텐츠를 수집하기 어려웠습니다.
Next.js App Router로 전환해 공개 콘텐츠를 SSG와 ISR로 사전 렌더링했습니다.
경로별 title, description, Open Graph, canonical을 설정하고, 실제 연주회 상세 페이지를 sitemap에 포함했습니다. 주요 이동 요소를 링크로 구성해 검색 엔진이 페이지 간 경로를 따라갈 수 있도록 했고, 공개 경로의 크롤링을 허용하도록 robots 정책도 수정했습니다.
공개 페이지와 연주회 상세 페이지를 포함한 약 50개 URL을 sitemap에 등록했습니다. Google에서 특정 연주회를 검색했을 때 해당 상세 페이지가 노출되는 것을 확인했습니다.
Gallery
