Skip to content
Ethan Sup's log
Github

프로젝트 시작하기 하루 전, 생각해볼 거리들

React, JavaScript2 min read

KOIN 서비스가 리액트가 떠오르는 당시 여타 다른 JS 배경지식도 없는 채 Vue에서 React로 리코드를 했었다. 이때는 React에 맞는 설계와 최적화된 코딩을 하기보다는 빠르게 React를 사용해보고 Vue에서 React로 리코드만 하였다. React를 완벽히 익히기 보다는 React를 사용하는 것에 의미를 두었었다.

이후를 고려하지 않고 빠르게 코딩하다 보니 지금 와서 문제가 생겼다. React가 발전해 오면서 패러다임과 라이브러리의 사용형태 모두 많이 변경되었다는 점에서 조금씩 리팩토링 해왔어야 할 것들이 프로젝트가 중단되면서 리팩토링 또한 중단되고, 그로 인해 레거시 코드들이 바뀌지 않고 쌓이고 패키지 업데이트 또한 늦어져 회사에서 흔히 보이는 레거시가 되어 버그만 고치는 코드 베이스가 되어버렸다.

많은 프로젝트가 거쳐가고 결국 KOIN 서비스를 발전시켜야 하는 시간이 왔다. 어떻게 할까 생각하던 도중 LINE에서 Recode로 코드베이스를 향상했다는 좋은 글을 접했다. 그래서 Recode 하는 방식으로 마음을 정했고, 동아리원을 설득하여 Recode를 하기로 결정하였다. 옛날 방식으로 만들어진 부분들이 많은 상태에서 리팩토링하면서 새 기능을 개발하는 방식도 있겠지만 제대로 된 설계가 없는 상태에서 서비스를 발전시키기에는 적용해야 할 패러다임이 너무 많았다.

  • Container/Presentational Pattern대신 Hooks를 활용하는 Hooks Pattern 사용을 권장
  • 비동기 fetching 방식이 redux-thunk / redux-saga에서 stale-while-revalidate 방식의 라이브러리 사용으로의 변경
  • react-router-dom 패키지의 버전업으로 인한 패턴 변경
  • SEO의 중요성 대두와 SSR 프레임워크 사용을 기본으로 두는 경우가 많아짐
  • TypeScript 역시 기본 스택으로 두는 경우가 많아짐
  • Form에서의 리렌더링 중요성 대두(react-hook-form, useImprativeHandle hook 사용)

그래서 이번 포스팅에서는 Recode하면서 프론트엔드 프로젝트를 만들기 전에 무엇을 고려해야 할 지에 대해 정리해보려고 한다.

가장 처음 결정해야 할 일

프론트엔드 프로젝트를 처음 만들 때에는 정말 많은 것들을 고려해야 한다. 가장 먼저 생각해보고 긴 시간을 들여 생각해볼 만한 것은 "현재 프로젝트에 맞는 프레임워크/라이브러리 베이스는 무엇일까"(Vue2, Vue3, React, Angular, Svelte....)가 있겠다.

이런 주 코드 베이스가 되는 프레임워크/라이브러리를 결정하기 위해서 구성원의 프레임워크/라이브러리을 사용하는 실력과 해당 프로젝트를 끝내야 하는 데드라인을 고려해야 한다.

리액트는 다음과 같은 장점이 있다.

  • 생태계가 매우 크다. 생태계가 크면 장점이 많다. 오류가 발생했을 때의 자료가 많다. 관련 라이브러리가 많아 서드파티 라이브러리를 잘 사용할 수 있다. 등등..
    • 새로운 인원이 들어왔을 때 해당 인원이 리액트를 알고 사용해봤을 가능성이 크다. 이 경우에는 새로운 프로젝트를 시작할 때 구성원과의 스터디에 시간을 쏟지 않아도 된다는 점에서 큰 장점으로 작용한다.
    • 위와 같은 이유에서 우리 동아리에서는 리액트를 무조건적으로 선택해야 한다. 새로 들어오는 인원들은 리액트를 배우는 기간을 마치고 프로젝트에 투입되기 때문이다.
  • 큰 어플리케이션에서 다른 라이브러리와 비교해서 "충분히" 빠르다. 요즘 나오는 프레임워크의 성능과 비교가 안될 정도로 느리지만.. 큰 어플리케이션에서는 수많은 회사에서 아직도 사용할 정도로 충분히 빠르다.
  • React를 기반으로 만든 서드파티 SSR 프레임워크인 Nextjs가 안정화되었다는 점과 빠르게 React 18에 대응했다는 점도 추가적인 점수를 줄 수 있겠다. 다른 예로 Vue의 Nuxt.js는 Vue 3에 빠르게 대응하지 못해 Vue 3으로 빠르게 넘어가지 못하고 새로운 API를 적용하지 못하는 결과를 낳았다.

이외에도 자신의 집단에 적용되는 다른 장점도 있을 것이다. React를 선택하지 않았다면 React를 선택하지 않은 것에 대한 장점이 있을 것이다. 그런 것에 대한 고민을 신중히 해보고 코드 베이스를 정하길 바란다.

리액트를 선택했는데..

안타깝게도 리액트만 선택했다고 프로젝트를 시작할 수 없다. 많은 선택지를 주지 않고 제작한 단체에서 모든 생태계를 제공하는 Angular와 주 생태계를 제공하는 Vue와 달리 React를 만든 Facebook에서는 커뮤니티를 기반으로 한 라이브러리가 많기에 모두 찾아보면서 적용해야 한다. 다른 프레임워크에도 적용되는 부분이 많이 있을것이다.

  • SSR을 적용해야 할까? 적용한다면 어떻게 적용해야 할까?
  • Routing 라이브러리로 어떤 라이브러리를 선택해야 하는가?
  • 전역 상태 관리 라이브러리가 필요할까? 필요하다면 어떤 라이브러리를 사용하는게 나을까?
    • 어떤 패턴의 상태관리 라이브러리가 적절할까? Flux? Proxy? Atom?
    • 최근에는 stale-while-revalidate 식 서버상태 관리 라이브러리를 채택을 하고있다.
  • 어떤 방식으로 CSS를 작성할까?
  • 테스트를 적용해야 할까? 테스트를 적용하면 어떤 테스트를 해야 할까?
    • 정적테스트로는 어떤 것까지 적용해야 할까? TypeScript? ReScript? Lint툴은 어떤 것을 선택해야 할까(ESLint, prettier)?
    • Jest + testing-library를 선택하여 Blackbox 테스팅을 할까 아니면 Jest + Enzyme을 선택하여 Whitebox 테스팅을 진행할까?
    • E2E 테스트를 진행해야 할까? 진행한다면 무엇을 선택해야 할까(Cypress, Playwright)?
  • 코드 컨벤션은 어떻게 정의해야 할까?
  • 디렉토리 구조는 어떻게 만들어놓아야 할까?

이 질문들도 많지만 이 질문들로 끝낼 수 없을 것이다. 프로젝트 특화 기술(WebGL, Map, Schema...)를 어떻게 적용하는가도 있겠고, 테스트 관련 기술을 더 적용할 수도 있고, CI/CD를 어떻게 적용할까도 있고... 끊임없이 만들어낼 수 있겠다.

마치며

나 말고 다른 사람이 프로젝트 베이스 라이브러리를 선택할 때 고려해 볼 만한 요소들을 정리해보았다. 2022년에 생각해 본 것이므로 나중이 되면 바뀔 수도 있겠지만 동아리의 다른 사람들이 주가 되어 프로젝트를 주도할 때 이 글을 참고하면 좋겠다는 생각이 들어 정리해보았다.

© 2023 by Ethan Sup's log. All rights reserved.
Theme by LekoArts