안녕하세요 YoursAI 개발진 pomiboy 입니다.
저희 팀은 YoursAI라는 서비스를 시작하기 전 줄 곧 Next.js를 웹 개발에 사용해왔었어요. 하지만 이번 서비스에는 Next.js를 사용하지 않기로 했습니다. 요즘 핫함을 넘어 거진 웹개발의 표준이 되어가는, 안쓰는 곳 없고 안쓰는 개발자 없는 것 같은 Next.js, 이 친구를 왜 놔줘야했을까요? 이번 포스트에선 그 이유와 고민을 공유하고자 합니다.
Next.js의 등장배경과 장점
어떤 도구를 사용할 지 안할 지를 결정하기 위해선 그 도구가 가지는 이점과 한계점들을 우선 명확히 알아야해요. 따라서 우선 Next.js가 등장하게 된 배경과 그것이 가져다주고자한 이점들을 살펴볼게요.
Next.js는 왜 등장하게 되었어?
Next.js는 React를 기반으로 하는, 말 그대로 React 위에 만들어진 프레임워크에요. 단순히 말해 Next.js는 React를 활용하여 더 나은 개발환경을 제공하는 툴인 것이죠. React가 가진 단점과 한계를 보완하고, 더 나은 개발 경험과 사용자 경험을 제공하기 위해 개발되었어요.
React가 뭐, 문제가 있었어?
React는 2013년 등장하여 컴포넌트 기반의 개발 패턴을 도입하면서 웹개발 환경에 혁신을 가져왔어요. 하지만 React 자체는 CSR(Client Side Rendering)만을 제공합니다.
CSR이란 SSR(Server Side Rendering)의 반대 개념으로 클라이언트(브라우저)가 Javascript 번들 파일을 다운로드한 후 브라우저에서 컴포넌트를 렌더링하는 방식을 말해요. 쉽게 말해 화면의 UI를 '브라우저'가 렌더링한다는 것이죠. 하지만 이 CSR 방식은 몇 가지 문제점이 있었어요.
- 초기 로딩 속도 저하
CSR 방식에서는 '이 페이지 보여줘~'라는 브라우저의 요청이 날라오면 서버가 브라우저에 비어있는 혹은 최소한의 구조로만 구성된 HTML 파일을 전달해요. 이 HTML 파일은 실질적인 콘텐츠가 없는, 말 그대로 '틀'만 갖춰져 있는 파일이며, 이 것을 받은 브라우저가 이후 Javascript 파일을 다운로드하고 실행해야 실질적인 콘텐츠가 HTML에 입혀지며 렌더링돼요.
즉, Javascript 파일이 로드되고 실행되기 전까지 사용자는 plain HTML (빈 페이지)을 보게되고, 로드가 완료되어야지만 화면이 구성되기 때문에 CSR은 초기로딩을 완료하기 위해 거쳐야할 산들이 많아요. 상당히 귀찮죠. 이로 인해 서버에서 완성된 HTML파일을 바로 내려주는 SSR보다 초기로딩이 느리다는 단점을 갖게 되는 것이에요.
또한 CSR 방식에서는 페이지 로딩 시 Javascript 파일과 함께 다른 리소스 (CSS, 폰트, 이미지 등)들도 동시에 요청되어요. 이 경우 네트워크 자원이 경쟁적으로 사용되기 때문에 리소스 로드 속도가 전체적으로 저하될 수 있습니다.
결론적으로, CSR에서 초기 로딩속도가 느린 이유는 브라우저가 HTML을 받아 Javascript 파일을 로드, 파싱, 실행하고 렌더링까지 하는 모든 과정이 전적으로 클라이언트 측에서 이뤄지기 때문이에요.
- SEO 최적화의 어려움
위 한계점에서 언급했듯이 CSR에서의 초기 HTML 파일은 비어있는 plain 상태에요. 이로 인해 검색 엔진 크롤러가 페이지의 콘텐츠를 제대로 인덱싱하지 못하는 문제가 발생하게 돼요. 이는 SEO가 중요한 웹사이트에서는 치명적으로 작용하게 됩니다.
- 동적 데이터 처리의 복잡성
CSR에서 클라이언트가 API 요청을 통해 데이터를 받아와 렌더링하는 과정을 비동기로 이루어지기 때문에 코드의 복잡성이 증가하게 돼요.
예를 들면, 클라이언트가 서버로부터 데이터를 요청하면 시간이 걸리게 돼요(당연히?ㅋㅋㅋ). 네트워크 지연, 데이터 용량 등 요인에 따라 데이터가 언제 도착할지는 언제나 다릅니다. 이로 인해 '로딩 상태 처리'가 구현돼야하며 데이터가 아직 도착하지 않은 상태에서 UI를 어떻게 처리할지 신경써야해요. 할 일이 많아지는 것이죠,,,
또한 CSR에서 데이터를 요청하고 받아오는 과정에서 네트워크 에러나 서버 에러가 발생할 가능성이 큽니다(물론 최대한 안나도록 잘 개발해야겠지만요). 이를 처리하여야 사용자 경험을 온전히 유지할 수 있겠죠. 따라서 CSR에서는 '에러 처리 로직'을 구현해줘야하는데 이 과정 또한 까다롭고 복잡하죠.
허나 웹개발에서 빠른 초기 로딩속도와 SEO 최적화는 매우 중요한 요소로 자리 잡았어요. 이 흐름에 맞춰 많은 기업들과 개발자들이 SSR과 SSG로 눈을 돌리게 되었고 이를 React로 구현할 방법이 필요해진 것이죠.
이에 대한 해결책으로 등장한 것이 바로 Next.js에요. Next.js는 SSR, SSG를 기본적으로 지원함으로써 CSR이 가지고 있는 문제점을 개선하고자 하였어요.
이 뿐만 아니라 웹앱을 만들기 위해 필수적이지만 구현하기 복잡했던 기능들(라우팅, Webpack/Babel 등의 기본 Configuration 등)을 쉽게 추상화여 사용할 수 있게 제공해줘요. React가 가지고 있는 장점을 유지하면서도 부족했던 부분들을 보완해 훨씬 나은 개발자 경험을 제공하는 것이죠.
이 글은 Next.js 소개글이 아니니까 구체적인 기능 소개는 하지 않겠습니다. 궁금하신 분들은 여기서 확인해보세요!
우리가 Next.js를 필요로 하지 않았던 이유
YoursAI는 AI 채팅 프론트엔드 툴이에요. AI 모델을 기반으로한 캐릭터와의 대화를 깔끔한 UI에 담아 여러분께 제공하려고 하고 있어요.
하지만 한 가지 특이한 점이 있다면 '로컬' 기반의 툴이라는 것이에요. 쉽게 말해 모든 데이터는 로컬(자신의 컴퓨터) 안에서만 관리되며 서버에서 관리되는 것은 아무 것도 없다는 거죠.
그 누구도 (심지어 개발자도) 유저의 채팅 내역 및 사용 내역을 트래킹할 수 없고, 오로지 그 컴퓨터의 주인 즉 해당 유저만 데이터에 접근할 수 있어요. 저희가 이런 방식을 택한 데에는 AI 채팅을 즐기고 이로부터 행복과 재미를 얻는 여러분들에게 온전한 자유를 드리기 위해서에요. 그 누구도 간섭할 수 없는 나만의 세계를 구축할 수 있게 되는 것이죠.
즉, YoursAI는 서버가 필요 없답니다. 모든 데이터는 유저 브라우저 내의 indexedDB에 담아지게 되어요.
Next.js의 가장 핵심 강점이 SSR을 가능케한다는 점인데 YoursAI는 서버없이 로컬환경에서만 작동하므로 이러한 서버 관련 기능들을 전혀 필요로 하지 않게 되었어요. 또한 SSR 이외에 Next.js가 제공하는 많은 기능들이 잇지만 로컬에서만 작동하는 프론트엔드 툴이라면 이런 기능들은 불필요한 복잡성만 더하게 됩니다.
이런 상황에서 Next.js를 고집한다는 것은 마치 배보다 배꼽이 더 큰 상황이 되는 것이죠. 따라서 저희는 Next.js를 내려놓기로 하였습니다.
대안은 뭔데?
저희는 로컬을 기반으로 한 '가볍'고 '쾌적'하고 '빠르게' 구동되는 채팅툴을 만들고자 합니다. 이런 목적에 맞게 React 웹앱을 만들기 위한 도구로 두 가지 중 고민하였는데요, 전통의 CRA(Create React App)과 비교적 최신기술인 Vite입니다.
CRA는 React 애플리케이션을 쉽게 시작할 수 있는 CLI 도구로, 복잡한 빌드 설정 없이 바로 React 프로젝트를 시작할 수 있게 도와줘요.
Vite는 현대적인 빌드 도구로 매우 빠른 빌드 속도와 개발 서버 성능을 제공하는 것이 특징이에요. 이 두 도구는 여러 차이점을 갖고 있지만 가장 핵심적인 차이는 '개발 속도'라고 할 수 있어요.
CRA의 개발 서버와 빌드는 Webpack을 기반으로 하여 속도가 느린 편이에요. 개발 서버가 느리다는 것은 처음 npm run start 명령을 실행했을 때 localhost에 서버가 열리는 속도가 느리다는 것이고, 이에 따라 코드를 수정했을 때 변경사항이 적용되는 (핫 리로딩) 속도 또한 느림을 의미해요.
이에 반해 Vite는 ESM(ECMAScript Modules)을 기반으로 개발 서버를 열어요. 덕분에 서버가 매우 빠르게 열리며 중간에 코드를 수정하였을 때도 그 수정된 파일(모듈)만 빠르게 불러오므로써 즉각적인 핫 리로딩을 보여줘요. 이는 결과적으로 개발속도에 큰 향상을 가져다줍니다.
또한 Vite는 유용한 Configuration(설정)을 제공해요. 프로젝트의 요구 사항에 맞게 플러그인을 자유로이 추가할 수도 있구요. 이에 반해 CRA에서 Config를 만지기 위해선 별도의 'eject' 과정이 필요하고 이후에는 빌드 설정을 직접 관리해야 하기 때문에 복잡도 증가한다는 제한점이 있어요.
무조건 Vite 아님?
이렇게만 봤을 땐 CRA가 Vite보다 나은 점이 없다고도 느낄 수 있을 것 같아요. 하지만 꼭 그렇지만은 않아요.
CRA는 오랫동안 사용된 도구이자 React를 만드신 분들이 직접 만든 도구이기에 매우 넓은 커뮤니티와 풍부한 자료를 가지고 있어요. 더욱 안정적이다라고도 할 수 있겠네요.
또한 Jest와 React Testing Library를 기본적으로 포함하고 있어 테스트 환경 설정을 별도로 필요로 하지 않아요. 이로 인해 테스트 작성과 관련된 설정 부담이 적어져요. 반면, Vite에서 테스트 환경을 설정하려면 Vitest와 같은 추가적인 도구 설치 및 설정이 필요해요.
우리의 선택은 Vite
그래서 뭐 쓸건데 빨리 말해 라고 하신다면 저희는 Vite를 선택했습니다.
첫번째로 CRA는 오랜 연혁으로 뒷받침된 안정성이라는 강점이 있지만 Vite도 충분한 안정성을 지닌 도구라고 판단했어요.
Remix, Astro, Vue/Nuxt, Svelte, SolidJS 등 많은 프레임워크들이 Vite를 기반으로 하여 만들어졌죠. 이 프레임워크들은 수많은 거대 기업들의 핵심 프레임워크로 사용되고 있구요.
이 정도면 충분히 안정성을 이유로 배척당할 수준은 절대 아니라고 생각하였어요. Vite를 기반으로 하는 프레임워크들, 그리고 그 프레임워크들을 사용 중인 기업들에 어떤 곳들이 있는지 궁금하다면 여기를 확인해주세요!
두번째로, 스타트업이라는 조직 특성 상 빠른 시간 내에 개발과 배포가 주기적으로 이뤄져야해요. 이를 위해선 빠르고 쾌적한 개발환경과 빌드 속도가 뒷받쳐주어야하는데 이에 걸맞는 도구 Vite라고 생각이 들었어요. 빠른 핫 리로딩을 통한 빠르고 쾌적한 개발 환경, 그리고 빠른 빌드를 통한 원활한 배포는 우리의 요구사항에 아주 적합한 특성들이라고 생각합니다.
마치며
이로써 저희는 Vite를 기반으로 앞으로의 YoursAI 개발을 진행하게 되었어요. 이를 통해 빠르게 서비스를 내놓고 개선해 나아가는 조직이 되었으면 좋겠습니다.
감사합니다.