팀프로젝트 프론트엔드 기술 스택에 관한 짧은 고찰

어떤 글을 쓸 거냐면

팀 프로젝트 프론트엔드 단에서 해당 기술 스택을 사용하기로 결정한 이유와 사용하면서 느꼈던 점을 회고해보고자 한다.

Next.js

선정 이유

• 리액트의 CSR을 사용해봤기 때문에 Next.js을 사용하면서 SSR을 사용해보자는 의견
• 폴더 방식 라우팅의 편리함에 대한 필요성 참고
• 13.1 버전의 최신 버전을 사용함으로써 최근 현업에서 적용되는 기술들에 대해 미리 예습할 수 있다.
• 또한 타입 스크립트 사용이 가능하고 바벨이나 웹팩 설정을 자유자재로 커스텀할 수 있다는 장점이 있었다.
• 백엔드와 협업 시의 장점도 물론 있지만 프론트엔드 스택만으로 웹 페이지를 제작할 때 API 서버 사용부터 배포까지 풀스택으로 활용할 수 있다는 장점도 있었다.

회고

• 폴더 방식 라우팅 사용
  Next.js의 여러 장점이 있는데 아무래도 첫 프로젝트에 기능 구현에 중점을 두다 보니 다양한 기능을 사용해보지 못했던 것 같다. 물론 폴더 방식 라우팅 덕분에 라우팅 관련해서는 리액트와 비교해서 별다른 고민 없이 편리하게 쓸 수 있었기 때문에 상태 전역 관리나 타입 관련해서 더 공부해볼 수 있었다.
• next.js 서버를 활용하지 못했던 점 결과적으로 서버사이드렌더링은 많이 활용하지 못하였고 기존 리액트 csr을 많이 사용했다.
  SSR을 사용하려면 그런 점에서 next.js의 장점을 십분 활용하지 못했다는 점이 아쉬웠다. 다음에 Next.js를 활용해본다면 좀 더 공부를 해보고 업데이트된 부분이나 getServerSideProps 같은 함수들도 잘 활용해보고 싶다.

TypeScript

선정 이유

• 자바스크립트에서 안정적인 타입을 사용함으로써 웹 개발을 쉽게 하기 위해 사용
• 컴파일 과정에서 미리 에러를 잡아내어 개발자의 의도가 정확하게 반영된 코드를 작성하고자 하는 필요성을 느낌
• 타입 스크립트를 사용했을 때와 그렇지 않았을 때 개발의 장단점과 차이점을 알고 싶다는 의견

회고

• 생각보다 타입을 지정하는 데 있어 많은 공부가 필요했다.
• 배열과 객체를 사용할 때 필요한 타입을 미리 지정해야하는 번거로움은 있지만 지정하고 난 후 사용할 때 편리함을 느꼈다.

Redux-toolkit

선정 이유

• 이미 새롭게 배우는 프레임워크인 Next.js를 사용하기 때문에 상태관리도 다 처음 써보는 도구를 사용한다면 개발 기간에 차질이 생길 것으로 예상, 따라서 다양한 상태관리 중 경험해보았던 도구를 사용하면 좋겠다는 의견
• 현업에서는 아직 redux를 활발히 사용하고 있기 때문에 리덕스 상태 관리에 대해 공부하면 유익할 것 같다는 의견이 있었다.
• redux-toolkit을 사용하면 리덕스 문법을 좀 더 간편하게 사용 가능하다는 장점

회고

• 기존 react query 와 Context API를 사용하던 내게 리덕스의 문법이 좀 많이 복잡하게 느껴졌다.
• 비동기 상태 관리
  나는 기존 컴포넌트 내에서 비동기 로직을 활용하여 받아온 결과를 리덕스에 저장하는 방식을 사용했다. Thunk 비동기를 사용하기 위해 기본 이론을 공부를 했지만 제대로 활용해보지 못했다. 다른 팀원들의 코드를 보고 더 분발해야겠다는 생각이 들었다..!

CSS

css에 가장 많은 관심을 갖고 있었기 때문에 사실 가장 정리가 덜 되고 아쉬움이 많이 남은 스택이 CSS 관련이었다..!

의논 과정

• 프론트 팀원은 3명
• 3명이 사용해온 css 스택과 선호도가 다 달랐음
• 예시로 나는 tailwind를 선호하지만 팀플에서 사용하기에는 내부 로직이 길어지고 지저분해질 것 같다는 의견이 있고 또 이에 동의하기에 채택하지 못했다.

결정된 스택

그래서 실제로 결정된 도구는
Module CSS(Post CSS) 였다.
그 후 예외적으로 필요한 컴포넌트에는 styled-component를 사용하기도 하였다.

사용하면서 좋았던 점과 아쉬웠던 점

좋았던 점

• 모듈 css로 스타일 파일을 분리
  한 컴포넌트 당 필요한 스타일 파일을 따로 지정할 수 있어서 깔끔하게 스타일만 관리하여 볼 수 있었던 점이 좋았다. 해당 컴포넌트 스타일을 수정해야 할 때 같은 이름의 스타일 파일을 금방 찾을 수 있기 때문에 편리함 측면에서는 단순하게 사용할 수 있어서 간편했다.
• 따라서 부득이하게 다른 팀원이 작성한 스타일을 보완하거나 수정할 때도 편리했다.

아쉬웠던 점

• 모듈과 스타일드 컴포넌트를 혼용해서 사용하다보니 css가 통일되었으면 한다는 생각이 들었다.
• 모듈 css 같은 경우 장점도 있지만 단점도 있었다.
  컴포넌트 파일 하나당 하나의 스타일 파일을 저장하여 사용하기 때문에 컴포넌트가 많아질수록 css파일도 많아진다는 점이.. 생각보다 번거롭게 느껴졌다. 이 점은 팀원들도 공통적으로 불편함을 느꼈던 부분이다. 이 점을 어떻게 개선할 수 있을까 오랜 시간 회의를 거쳤다.
• 하지만 이미 상당 부분 진행된 css 툴을 고친다는 것은 한정된 시간 안에서 개발을 완성하기에 불가하다고 판단했기 때문에 그대로 진행이 되었다.
• 회의에서 추가적으로 나온 의견은 나중에 리팩토링이나 활용이 가능하다면 css를 MUI(Material UI)나 emotion을 함께 사용해보면 좋겠다는 의견이 있었다.