[AWS KRUG] #frontend 소모임 24.02.14

 

작년 AWS Summit을 통해 AWS KRUG 라는 AWS 사용자 커뮤니티가 있다는 것을 알게 되었다.

대부분의 모임이 서울에서 열렸기 때문에 대전에 거주하는 나는 참여하지 못했다.

최근 용인 본가로 돌아오면서 AWS KRUG 모임에 참여할 수 있게 되었다.

 

https://www.meetup.com/ko-KR/awskrug/

AWSKRUG - AWS한국사용자모임 | Meetup

 

 

오늘 참여한 커뮤니티는 frontend 소모임이었고

오늘의 주제는 프론트엔드 개발을 하면서 생기는 고민에 대해 토론하는 것이었다.

 

가장 기억에 남는 것은 CI/CD 담당자와 프론트엔드 개발자와의 갈등이다.

모노레포라는 방식으로 프론트엔드 개발을 하면 용량이 점점 커진다.

용량이 커지면 CI/CD에서 빌드할 때 몇 GB를 잡아먹어서 속도가 느려진다고 한다.

 

그래서 CI/CD 담당자의 입장에서는 용량을 낮춰서 개발할 수 있으면 그렇게 해달라고 하는데

프론트엔드 쪽과 협상이 안됐다고 했다.

 

내가 알기로 프론트엔드는 node_modules 용량이 커서, 처음 install 할 때 부담이 있다.

node_modules 첫 install 이후에는 새로운 부분만 update 하는 걸로 알고 있다.

그리고 프론트엔드쪽 용량이 백엔드보다 크기에 Build 과정에서도 시간이 더 걸린다.

 

나도 SSAFY에서 프로젝트를 진행했을 때 CI/CD 과정에서 서버 컴퓨터의 작동이 멈춘 적이 있었다.

내가 겪었던 어려움을 현업에 계신 분들도 똑같이 겪는 것을 보니까 신기했다.

내가 경험했던 어려움들은 쉽게 해결하고 다음 step으로 넘어갈 것이라고 생각하고 있었기 때문이다.

물론 내가 사용했던 기술 스택 이상으로 새로운 용어들이 등장했고, 그렇기에 내용을 전부 이해하지는 못했다.

 

토론이 끝나고는 피자를 먹으며 이야기를 나눴다.

내가 Jenkins를 사용하냐고 여쭈어보았고, Jenkins는 CI/CD에서 기본으로 깔고 간다고 한다.

거기에 spinnaker라는 tool도 사용한다고 한다.

그리고 이런 커뮤니티 활동을 많이 하면 기회가 더 많이 생겨서 좋을 거라는 조언도 들었다.

안그래도 #network, #security, #study, #architecture에 관심이 있다.

 

오늘의 토론 내용을 간단하게 정리하고, 자볼까 한다.

---

Q. Recoil은 github 토론에서 대화 나누는 걸 보니, 더 이상 Facebook에서 유지 관리에 대한 업데이트 할 가능성이 낮다고 하던데 많이들 제외하시는지 궁금해요.

• zustand[슈스타드,독일어로 상태]보다 20배, jotai(일본어로 상태)보다 10배 용량이 큽니다.
  (외국영상에서는 주스탠다드라고 많이 불리움)
• zustand, jotai 만든 사람이 같음. zustand가 제일 가벼움
• zustand 를 선호하는 참여자 있음
• jotai가 소스코드 보기가 편하다고..
• Recoil -> jotai , redux -> zustand

 

Q. 컴포넌트를 잘 설계했다는건 무엇일까요?
(전임자가 짠 코드보고 짜증내고.. 싶지 않아요)

A. 개발 기능별 잘개 쪼개도 재사용이 어려운 코드가 많아서 비즈니스 중심으로 재사용 여부를 구분하는 것도 잘 설계하는 기준점 중 하나인 것 같다.

- 기능적으로만 추상화 시키고 재사용 가능하게 변경하는 것.

- 도메인과 데이터 중심으로 컴포넌트를 나누고 뭉쳐 놓는 것

- FEConf 원지혁님 발표 - 컴포넌트 설계 > 당근 graphQL 예시가 도움이 되었다. UI는 비슷하나 다루는 데이터가 다를 때 어떻게 하지?에 대한 고민. 데이터에 의한 관심사 분리를 발표함. 어떤 컴포넌트에서 어느 수준의 도메인 데이터까지 다룰것인가를 고민했다.

- 토스에서 우아하게 비동기 처리 발표 > 도움이 되었음.

 

Q. 어떻게 하면 graphql을 잘 쓸 수 있을까(스키마를 어떻게 짜는 것이 좋을까)

A. 

- 리소스 기반 모델링을 하고 리소스끼리 relation을 스키마에서 최대한 표현한다

- UI와 결합도가 높다보니 프론트 내에서 처리는 힘들것 같고,
도메인 측에서 가치분석 먼저 하고 스키마를 짜는 것이 좋지 않을까

- 리소스 베이스로 스키마 짜고, Relay-resolver를 이용해서 클라이언트 스키마  <-> bff스키마
표현을 구분을 지었던 적이 있음

 

Q. UI에 너무 많은 로직이 있는 걸 분리해내서 어떤 UI든지(web, react, cli..등등) 상관없이 동작하는 비즈니스 로직을 작성할 수 있을까

A.

- 한 회사에선 프론트가 비즈니스 로직을 담당하지 않고 백엔드가 담당한다.(사용자가 악의적으로 수정할까 봐)

- 백엔드 마인드로 프론트 코드를 작성하면 어떨까(API 구현 하듯이). 비즈니스 로직과 UI 를 구분해 보기.

- 이전회사에서는 클린아키텍쳐를 프론트에 도입을 했었는데, 도메인 단위의 비즈니스 로직이 필요한 경우에는 usecase 에서 처리하고  여러 도메인 로직을 사용하는 한 화면일 경우에는 viewmodel이라는 중간에서 비즈니스 로직을 관리시킨 후 컴포넌트에 내려받는 식으로 관리했었기 때문에 컴포넌트 안에서는 비즈니스 로직을 따로 관리하지 않게 되었던 것 같습니다.

 

Q. Typescript. 어떻게 쓰시나요?
Q-1. 함수의 return type 항상 정의 해야한다 vs 아니다

A.

• 라이브러리라면 하고 아니면 안해도 된다!
  • 다음 변경이 있을 때에 리턴 타입을 제한하는 효과가 있다. (장점)
  • ts server가 없는 환경(github)에서 가독성이 개선된다.
• 그냥 생각나서 적는 파이썬 철학. 명시적인 것이 암묵적인 것보다 낫다.(Explicit is better than implicit.)
• Jetbrain이 자동추론이 너무 잘 되어서 리턴 타입 잘 정의 안하는 편
• hook 정의 시에는 왠만하면 as const 를 정의하는 편
• undefined 가 나오지 않는 케이스가 아닌 이상 웬만하면 타입 정의를 안하는 편

 

Q.캐싱을 하지 않는다면, swr이나 tanstack-query를 사용하는게 더 적합할까요?

현재 swr을 사내에서 사용하고 있습니다. 필요한 시점에 cache clear(창 이동시 무조건 데이터 갱신을 위한 목적인 cache clear)를 위해 여러 곳에서 mutate를 사용하는데 코드가 난잡해지는 느낌을 받고 있습니다. (swr 사용 전에는 useEffect에서 캐싱, swr 사용 시에는 stale-time 지정 못하는 듯)

A.

• swr config에다가 provider를 넣는 방식으로
• invalidate 옵션 존재여부 알아보고 도입해 보는게
• 그 전에 컴포넌트가 의도한대로 동작하고 있는 지부터 확인 해 보는 것도 방법

 

Q.Suspense와 SWR을 같이 사용 하는지

A. 아직 실험적 단계라고 함

react-query 5버전에서 useSuspenseQuery 를 지원한다고 하니 그 옵션을 사용해보는 것도 방법

 

Q. Frontend에서 모노레포를 사용한다면 어떻게 사용하고 계신가요? (패키지 매니저, 구조 설계 등)

A.

- pnpm + turborepo(vercel 스펙에 맞춰서)
- 차라리 npm을 쓰고싶다..
- 큰 규모의 모노레포를 clone하면 트래픽이 터지면서 서버가 죽는 경우가 발생하기도 한다. CI/CD가 일어날 때마다 모노레포가 돌아가서 서버가 매우 느린 경우가 자주 발생하기 때문에 규모가 커질 모노레포는 보수적으로 생각하는 것이 좋은 듯.
- 빌드를 위한 쉘 스크립트 난이도가 매우 높아지고, 복잡한 설정 등의 높은 난이도가 존재한다.