최신 트렌드인 Next.js를 학습하고 적용했던 적용기입니다.
블로그를 만들며 Next.js를 맛본 뒤, 이거 물건이다라는 생각이 들었다.
배포도 빠르고 리액트랑도 비슷해서, 바로 다음 프로젝트 프레임워크로 선택했다.
그렇게 2명이서 야심차게 시작한 타자 연습 사이트 사이드 프로젝트 TYLE
처음엔 모든 게 순조로웠다.
Vercel에서의 배포는 순식간이었고, 리액트 했던대로 구현도 빠르게 했다.
하지만 프로젝트가 진행될수록 뭔가 이상함을 느꼈다.
1. 이거 use Client 이렇게 많이 쓰면 안될 것 같은데
Next.js가 서버 사이드 렌더링SSR에 강점이 있음에도 사이트 초기 메인화면 렌더링 속도가 너무 길었다.
타자 연습 특성상 실시간 키보드 이벤트와 상태 업데이트가 70% 이상이었기 때문에 화면에 거의 모든 곳에 use client가 필요했다!
2. SEO 쓸데가 없네
검색 엔진 최적화가 장점이라지만, 타자 연습 사이트엔 텍스트 콘텐츠가 없기 때문에
키보드와 글귀만 있는 서비스에서 장점을 발휘 할 수가 없었다.
3. 한글 입력과 렌더링
한글 입력은 자+모음이 합쳐지는 형태라 특수한 경우였는데..
조합 중인 글자가 상태와 동기화될 때마다 불필요한 리렌더링이 빈번하게 발생했다. 또한 엔터 키 입력 시 이벤트가 중복으로 발생하는 등 클라이언트 측에서 처리해야 할 엣지 케이스가 많았다.
결국 서비스의 핵심인 타이핑 로직은 순수 클라이언트 영역이었고 성능 최적화의 핵심 또한 클라이언트 측에 있었다. Next.js의 장점을 살리지 못하고 오히려 아키텍처만 복잡해지는 결과였다.
기술은 도구일 뿐이다!
고민 없는 기술 도입은 오히려 설계의 복잡도를 높이고 개발 생산성을 저해한다. 트렌드에 따라 Next.js를 선택했지만, 타자 연습과 같이 실시간 인터랙션 비중이 높은 프로젝트에서는 더 가벼운 클라이언트 중심의 환경이 적합했다.
결국 개발자의 진정한 실력은, 프로젝트의 성격에 맞는 적절한 기술을 선택하는 안목인 것이다. 이러한 깨달음을 새기고, 다음 프로젝트에서는 SEO와 초기 로딩 속도라는 목표를 설정하고, Next.js의 기능을 제대로 활용할 수 있는 서버 컴포넌트 우선 설계를 중심에 두기로 했다.
다음 글 : 한번 깨지고 다시 다진 Next.js