[사이드 플젝] 프론트 개발 협업 시 논의 사항은 뭐가 있을까?

기운찬곰·2023년 2월 20일
사이드 프로젝트협업
1

Overview

최근의 사이드 프로젝트를 시작하게 되었다. '비사이드' 라는 곳에서 신청을 통해 참여하게 되었는데 아직은 초기단계이지만 만족하고 있는 상태이다. 현재는 아이템 논의와 개발 협의사항 논의를 진행 중이다.

오늘 이야기 하고 싶은 거는 프론트 개발 협업 시 무엇을 논의하면 좋을지에 대해 나와 프론트엔드 개발자 한 분이 나눈 내용을 작성해보려고 한다.


내가 생각했던 논의 사항 리스트

회의 전에 주말에 무엇을 논의하면 좋을까 내 생각을 리스트로 작성해봤다. 굵직한 것부터 시작해서 자잘한 것까지 그냥 나열해본 것이다. 그리고 나서 굵직한 내용 위주로 세부 사항을 다시 생각해봤다.


논의사항 1. 사용할 프레임워크? 라이브러리 정하기 (Next.js, Remix, Sveltekit 등)

참고 : https://blog.logrocket.com/react-remix-vs-next-js-vs-sveltekit/

일단 제일 중요한 프레임워크 정하기 이다. React를 베이스로 깔고 SSR을 기본으로 사용하고 있는 현 트렌드를 반영하면 당연히 Next.js가 좋은 선택지이다. 하지만, 성능이 더 뛰어나다고 평가받는 Remix나 최근의 정식 버전이 릴리즈 된 SvelteKit도 알아볼 필요가 있었다.

시간이 별로 없던 관계로 Remix나 SvelteKit을 직접 사용해보지는 못했고 잠시 알아봤는데 역시 npm 트렌드나 깃허브 스타수, 이슈 수를 봐도 Next.js가 압도적이었다. 이게 중요한 이유는 그만큼 커뮤니티가 크고 어려운 문제를 만나도 물어보고 해결할 수 있을 가능성이 많다는 것이다.

그래서 이번 프로젝트는 Next.js로 가는 것에는 별다른 이견이 없었다. 근데 Next 13 experimental 버전을 사용할 것인지에 대해서는 살짝 염려스러운 부분도 있었지만 이제는 발표된지 어느정도 지난 상태이고, 앞으로는 이런 트렌드로 바뀌게 될 것이므로 Next 13 experimental 버전을 사용하기로 결정되었다.


논의사항 2. Storybook 사용 여부 검토

Storybook은 내가 회사에서 사용해보려고 했다가 실패한 경험이 있기 때문에… 일단 실패했던 이유는 흠.. 뭘까? 뭐였더라. 처음 시작은 Atom Design 방식으로 CDD(컴포넌트 주도 개발) 방법론에 따라 스토리북을 제대로 사용해볼 생각이었는데.

일단, 나 포함해서 스토리북을 제대로 사용할 줄 아는 개발자 부재가 제일 컸던거 같고. Atom Design 방식으로 버튼 하나를 만들려고 해도 재사용 가능한 여러가지 종류의 버튼을 하나로 만드는게 쉽지 않았다. 버튼 하나를 만들더라도 props만 바뀌면 여러가지 버튼 조합을 가능도록 만들려고 시도했는데 막상해보니까 고작 버튼 하나때문에 너무 어려워지는거 같다는 생각이 들었다. 그리고 그 때는 CSS Module 방식을 사용해서 props에 따라 조건문 주기도 어렵기도 했고.

막상 해보면 굳이 Storybook 안 써도 잘 사용했던거 같음. 너무 지나치게 유행을 따라가도 좋지 않다는 생각도 들면서 한편으로는 초기에 조금 시간이 걸리더라도 잘 사용했으면 하는 생각도 있더라. 그래서 이번에는 스토리북을 제대로 사용해봤으면 좋겠다고 생각.

카카오엔터테이먼트 기술블로그

그 외 기술 블로그


논의사항 3. CSS 스타일 방식에 대하여

프론트엔드 개발자에게 있어 CSS 스타일 방식은 매우 중요한 협의사항 주제이다. CSS 스타일 방식은 각자 스타일이 다르며 사용할 수 있는 옵션이 많기 때문이다.

  1. 전통적인 CSS(SCSS)방식
  2. CSS(SCSS) Module 방식
  3. CSS-in-JS 방식 (styled-component, emotion)
  4. Tailwind 와 같은 방식 (plus. daisyui)
  5. 그 외 chakra, mui, ant 등 React Component 방식. 음 근데 이건 좀 그렇다. 디자인 분들이 있는데 이걸 쓸 이유는 없지…

여전히 많이 쓰이는 전통적인 CSS(SCSS) 방식, 한 때 큰 주목을 받았던 CSS-in-JS 방식, 그리고 현재 가장 큰 인기를 얻고 있는 Tailwind 방식이 있다.

내 생각은 카카오 엔터테이먼트 기술 블로그처럼 Tailwind를 기본으로 사용하고 나머지 복잡한 CSS나 애니메이션은 전역 CSS(SCSS)나 CSS Module 를 사용해서 쓰는것이 나쁘지 않다고 생각한다. Next.js와 Tailwind 호환성도 좋고, 익숙해지기만 하면 참 좋은게 Tailwind이기 때문이다.

그렇지만 Tailwind는 호불호가 심한 편이며 협업하는 분 입장을 존중해서 결정해야 한다.

카카오 엔터테이먼트 기술 블로그

그 외 참고 블로그


논의사항 4. TDD 사용 여부 검토

일단 나는 TDD를 제대로 사용해본 적이 없다. 회사에서 재작년에 새 프로젝트를 개발하면서 테스트 코드를 도입해볼까 생각했었는데 무슨 간단한 테스트코드를 실행하는데도 오래걸리고, 상태 변경에 따른 테스트 코드 작성도 못하고… Cypress 사용하려고 했더니 무슨 보안 때문에 막히고… 그리고 굳이 테스트 코드가 필요 있어보이지 않은 서비스였기 때문에 사용하려다가 포기했다.

하지만, 만약 사용자 인풋이 많은 서비스였다면? 예를 들어 설문조사라던가… 뭔가 절차가 있는 서비스? 가 있다면 개발자가 테스트 할 때마다 직접 해봐야 될 것이다. 이런 번거로운 작업을 TDD를 사용하면 해줄 수 있지 않을까? 그니까 내 생각은 서비스에 따라 TDD가 정말 있으면 좋겠다는게 있고, 있어도 그만 없어도 그만인 서비스가 있지 않을까 라는 것이 내 생각이다.

어쨌거나 이번 프로젝트에서는 TDD를 정말 제대로 사용해보고 싶은 마음이 있다. 근데 내가 테스트 전략 방식을 잘 몰라서… 공부를 좀 해봐야 된다. (Jest, React testing library, Cypress...)

카카오엔터테이먼트 기술블로그

기타 기술 블로그


논의사항 5. CI / CD 어떻게 할 것인지 - git branch 전략, Deploy 환경

회사에서 나 혼자 할 수 없었던 (=바꿀 수 없었던) CI/CD를 제발... 사이드 프로젝트에서 제대로 적용해보고 싶었다. 그래서 git branch 전략에 따라 github actions 설정을 통해 특정 브랜치 머지 시 자동으로 테스트 해서 테스트 통과된 것만 올라가도록 해서 CI / CD까지 완벽하게 구현하는 것이 목표였음.

배포환경은 도커 컨테이너로 이미지를 만들어서 쿠버네티스나 GKS? 를 사용해서 배포하기도 하는 듯. 근데 간단한 경우라면 Vercel이나 CloudFlare Pages를 사용하는게 좋긴한듯.

카카오엔터테이먼트 기술블로그

기타 기술 블로그


그 외 논의사항

  • API 호출 방식 : 그냥 axios 쓸건지, fetch를 쓸 건지, react-query 를 쓸 건지

  • 전역 상태관리 : 필요하다면 사용. recoil 이 무난하다는 평가

  • MSW (Mock API) : 백엔드 개발이 될 때까지 프론트가 기다리는 것이 아닌 미리 협의된 사항으로 Mock API를 만들어서 동시 개발 가능하도록 하는 방법. 그리고 요즘에는 MSW + Storybook, 테스트 코드 전략도 많이 보이는 듯 하다. 이 부분은 좀 더 알아봐야 될 듯.

  • 에러 모니터링(Sentry) : 나중에 기회가 되면 사용해보는 것도 나쁘지 않겠다라고 협의. 지금 단계에서 적용하기에는 오버 플로우 스택? 이 될 듯.

  • 패키지 관리자 npm, yarn, yarn berry, pnpm : 나도 사실 딥하게 알아보지 못해서 그냥 이번 기회에 pnpm으로 사용해보면 어떨까 생각만 해봤음. 따로 적용하기 전에 공부가 필요한 부분.

  • BFF(Backend For Frontend) : Backend와 Frontend 사이에 중간 서버를 하나 두는 방식. 이렇게 사용 하는 이유는 어댑터 패턴이라고 보면 됨. 중간의 형식 차이가 있을 수 있고, 특정 환경(웹, 안드로이드, ios)마다 전달되는 데이터가 다를 수도 있기도 하고... 그런것 때문에 쓰인다고 함.

profile
기운찬곰
배움을 좋아합니다. 새로운 것을 좋아합니다.
이전 포스트

[백준 추천문제] 11066 - 파일 합치기

다음 포스트

JavaScript Package Managers - npm, yarn, pnpm 에 대해

0개의 댓글