SEO(MPA), group route, 등 Next.js의 장점은 취하면서 비용은 최소화하기 위해 Next.js static 빌드를 S3 + CloudFront 로 배포하기로 하였습니다. 10일간 10만명 이상의 사용자, 운영 초반엔 시간당 1만+ 트래픽이 예상되는 상황이었습니다. 또한 필수 기능인 AI 이미지 생성에는 75원+ 의 비용이 발생 예정이었기 때문에 어떻게든 전체 비용을 최소화해야 했습니다. 프론트에서 시도할 수 있는 가장 좋은 방법은 SSR을 포기하는 것이었기에 정적 빌드를 선택하게 되었습니다. 하지만 응모와 관계없는 부분(콘서트 안내페이지)에서는 SEO도 중요했기 때문에 React 가 아닌 Next.js static out 으로 MPA 형태를 채택했습니다. 결과적으로 프론트 서버에서 발생하는 비용을 미약하게나마 아낄 수 있었고, 안정적인 형태로 운영이 가능했습니다.

아주 복잡한 프로젝트는 아니었지만, 그동안 스터디해왔던 FSD를 적용함으로서 각 레이어별 의존성을 유연하고 편리하게 관리할 수 있었습니다. 기능 단위로 폴더 구조를 분리하고, 공용 로직을 feature 레이어에 집약시켰습니다. 이를 통해 페이지 간 의존성을 줄이고, 유지보수 시 특정 기능만 독립적으로 수정할 수 있도록 구조를 단순화했습니다.

수시로 바뀌는 기획과 명확하지 않은 요구사항, 유저플로우 속에 마감 기한까지 촉박했습니다. 이에 따라 개발단에서 알아서 예외처리를 해야하는 경우가 많았고 백엔드와 프론트엔드 모두 대처에 어려움을 겪었습니다. 프론트에서는 브라우저 뒤로가기 버튼과 웹앱 내부의 뒤로가기 버튼동작을 예외처리하는데 어려움이 있었고, 응모 funnel 중 어떤 구간을 분리된 페이지로 처리해야 할지도 복잡한 구간이었습니다.

전체적으로 보면 큰 비용은 아니었지만, 다수의 사용자의 동작에서 발생가능한 fetch를 최적화해야 했습니다. 이를 위해 서버-클라이언트 상태의 적절한 관리가 필수였고, zustand를 통해 클라이언트 로컬 상태를 단일 스토어로 관리하고, tanstack query로 서버 상태를 캐싱하여 불필요한 fetch를 최소화했습니다. 결과적으로 렌더링 성능이 개선되고, 사용자 흐름 중 데이터 일관성을 유지할 수 있었습니다.