<aside> 🔗
목차
</aside>
기술 스택을 결정할 때, 단순히 유명하거나 유행하는 기술을 선택하는 것을 목표로 삼지는 않았다.
대신 우리 서비스의 성격과 팀의 현재 역량, 그리고 데모데이까지 주어진 시간 안에서 실제로 완주할 수 있는 선택이 무엇인지에 집중했다.
해당 기술이 우리 팀이 만들고자 하는 서비스에 얼마나 잘 맞는지,
그리고 현실적인 개발·운영 조건을 충족할 수 있는지를 기준으로 하나씩 검토했다.
Next.js에 대해 검토한 이유는 다음과 같다.
<aside> 🔗
Next JS 를 선택하지 않은 이유
React에 대한 이해를 충분히 쌓고 싶었다
이번 프로젝트를 시작하며 ****React를 ‘사용했다’고 말할 수는 있지만, ‘충분히 이해했다’고 말할 수 있을까라는 고민이 들었다. 그동안 React를 사용해왔지만 공식 문서를 깊이 있게 읽거나, 렌더링 흐름·상태 관리·성능 최적화 관점에서 React 자체를 충분히 알지 못하고 있다는 판단이 들었다.
그래서 지금 단계에서는 새로운 프레임워크를 추가로 도입하기보다, ****React 환경 안에서 최대한 많은 시도와 문제 해결을 경험하는 것이 더 의미 있다고 판단했다.
Next.js의 필요성을 ‘체감한 상태’는 아니라고 판단했다
Next JS 를 사용하는 이유에 대해 공부한 적이 있다. 기존의 CSR 이나 SPA 가 가지고 있던 고질적인 문제들 (SEO, 초기 로딩 속도) 을 해결하기 위해 SSR 방식의 Next JS 를 사용한다는 것이었다.
다만 이번 프로젝트에서는 SEO가 비즈니스 성과에 직접적인 영향을 주는 단계도 아니었고, 대규모 데이터를 초기 로딩 시 처리해야 하는 상황도 아니었기 때문에 ****CSR 구조의 한계를 실제로 체감하지는 못했다.
따라서, 이번 프로젝트에서는 SPA 환경에서 Lazy Loading, 이미지 최적화, 폰트 최적화 등🎨
프론트엔드 성능 최적화를 직접 수행하며 CSR 구조의 장단점을 명확히 이해하는 것을 목표로 삼았다.
저희 팀은 회의를 통해 런타임 스타일링 방식을 배제하기로 결정했다.
빌드 타임 스타일링과 런타임 스타일링의 장단점을 비교·분석한 이후의 판단이었다.
CSS-in-JS 방식은 빠른 개발과 높은 유연성을 제공하지만,