기술 스택

결정된 기술 스택

Common:

TypeScript
yarn berry
ESLint
Prettier
dotenv vault

Front-end:

Vite
React
SCSS
(상태관리 논의 중)

Back-end:

Express

DB:

MongoDB

CI/CD:

github Action

Testing:

Jest

기술 스택 선정 이유

공통

TypeScript

세영: 구현체들이 사용하는 인터페이스 타입을 정할 수 있다는 점이 협업할 때 확실히 효율적이에요.
도훈: 협업을 위해서 타입이 필요하다고 느꼈어요. 그리고 인터페이스나 추상클래스를 사용할 수 있다는 점이 js에 비해서 장점이라고 생각해요.
주영: 협업할 때 타입 정해놓는게 좋을 것 같아요. 버그 잡기도 쉬워서 좋아요.

패키지 매니저

yarn berry vs. pnpm

성능과 팀원들의 사용 경험을 고려할 때 yarn berry를 사용하는게 좋겠다고 결정했어요.

성능으로 미뤄 보건데, yarn berry + Plug n Play strict가 가장 설치도 빠르고 디스크 효율적인 모습을 보여주었고, 그다음으로는 pnpm이 뒤를 이었다.

[https://yceffort.kr/2022/05/npm-vs-yarn-vs-pnpm#성능과-디스크-관리의-효율성](https://yceffort.kr/2022/05/npm-vs-yarn-vs-pnpm#%EC%84%B1%EB%8A%A5%EA%B3%BC-%EB%94%94%EC%8A%A4%ED%81%AC-%EA%B4%80%EB%A6%AC%EC%9D%98-%ED%9A%A8%EC%9C%A8%EC%84%B1)

세영: yarn berry 사용해봤는데 자동화 배포 서버에서 설치, 빌드 속도가 빠르다는 점이 강점이었어요. pnpm도 효율적인 방식을 사용하는 것 같지만 (안써봐서)… 이것도 나중에 공부…
도훈: 성능, 디스크 효율성, 속도면에서 뛰어나다고 해요.
주영: 둘다 좋아요.. npm, yarn보다 빠르잖아요 ..

참고

패키지 매니저 비교

pnpm 벤치마킹

Package Manager Benchmarks

Front-end

Vite

속도가 빨라요. CI/CD에 있어서 장점이에요.

세영: 빠른 이유에 대해서 나중에 공부해볼게요. 써보면 공부할 것 같아서 좋아요.
도훈: HMR이 빨라서 개발환경에서 매우 큰 장점이라고 생각해요.
주영: 안써봤지만 빠른 빌드 속도가 탐나서 써보고 싶어요.

CSS

css-in-js

세영: css props 활용할 수 있다는 점이 편해요. 사용한다면 emotion보다는 styled-component가 더 편리하게 스타일을 분리할 수 있는 것 같아요.
도훈: props를 활용할 수 있고, 컴포넌트와 스타일을 같이 작성해서 파일 관리가 비교적 쉽다고 생각했어요. 또 ts의 변수도 같이 공유할 수 있다는 점이 좋아요.
주영: html 태그를 쓰지 않고 스타일 태그를 직접 만들어 쓰는 점이 불편했어요.
- 태그마다 스타일 변수를 만들어 주기는 불편해요. 그렇지 않으면 클래스네임을 써야하는데 css-in-css 와 비교했을 때 큰 장점이 되는지 모르겠어요
- 저희 서비스에 props를 잘 활용할 만한 부분을 잘 모르겠어요. css-in-css 로도 충분히 컬러

css-in-css

주영: 실시간성 서비스이기 때문에 렌더링마다 스타일이 로드되는 css-in-js 보다는 초기에만 로딩되는 css-in-css가 좋을 거 같다는 의견이에요
- css-in-js와 다르게 확장자로 스타일 파일임이 확실히 보여서 좋아요.
- 스타일 변수를 따로 export/import 해주지 않아도 돼서 좋아요.

전역 상태 관리

필요한/필요하지 않은 이유

주영: 전역으로 관리해야할 데이터가 없는거 같아요 사용여부를 고려해봐야 할 거 같아요

Zustand

주영: 써본 경험이 있어서 러닝커브가 줄어들어서 좋아요 + 사용하기 쉬워서 편해요
도훈: flux 패턴이라서 이벤트 흐름을 추적하기 편하다고 생각하고, 곰이 귀여워요.
세영: 써봤는데 배우기 쉬웠고 참고할 자료도 많을 것 같아서 좋아요.

Recoil

주영: 제대로 사용안해봐서 러닝커브가 좀 있다. 아직 정식버전이 아니기 때문에 zustand에 마음이 가요
도훈: 제대로 사용안해봤지만 React 친화적으로 보여서 호감이에요.
세영: 얘도 쓰기 쉽고 React와 함께 사용했을 때 시너지가 있어서 좋아요.

Jotai

도훈: 어감이 별로에요.

서버 상태 관리

필요한 서버 상태

팀 생성, join에 사이드바에 반영되어야 함
새로운 문서 생성되면 목록에 반영되어야 함

필요한/필요하지 않은 이유

주영: 실시간성 서비스에는 캐싱할 데이터가 없기 때문에 서버 상태 관리 라이브러리를 사용한 만큼의 큰 이점을 불러오지 못할 거 같아요. 그냥 데이터 패치에 한번 사용해봤다 정도로 끝날 거 같아요. 실시간이 아닌 데이터는 워크스페이스 추가 정도인 것 같은데 이 기능 하나에 사용하기에는 오버 엔지리어링이 아닐까 생각이 들었어요
세영: 이 결정을 내리기 위해서 소켓 사용과 공유문서 구현 방식에 대한 논의가 필요해요.
- 저희가 기술적으로 중점을 두어야 할 부분이 어디일까요? 저는 공유문서 동시성 제어와 지연시간 최소화 == 효율적인 업데이트 방식과 소켓 서버 설계라고 생각했어요.

@tanstack/react-query

👍 서버 상태가 업데이트 되었을 때 refetch 속도가 빠름

react-query mutate는 캐시를 invalidate하고 다시 fetch하는 형태라서 SWR이 더 빠름

주영: 써본 경험이 있어서 러닝커브가 줄어들어서 좋다 + 사용하기 편해요
세영: 저도 써본 경험이 있어서 편하고, mutate로 컨트롤하기 쉬워서 좋아요

SWR

👍 번들 사이즈가 작음, 빠른 fetch

투표

주영: react-query, zustand

도훈: react-query, zustand

세영: react-query, recoil

Back-end

프레임워크

Nest.js

설계를 프레임워크가 만들어줘서 통일된 구조 위에서 협업할 수 있어요.

swagger 문서를 자동으로 달 수 있어요.

도훈: 구조가 미리 잡혀져 있어서 이 부분에 대해서 부담을 덜 수 있고. 생산성 향상을 기대할 수 있어요. 하지만 새로운 기술을 배워야 한다는게 부담이 돼요.
주영: 사용안해봤지만, 구조가 잡혀있어서 좋다. 배우는 데 조금 걸릴 것 같지만 swagger 달려있어서 좋아요.
세영: 간단한 실습 해봤는데 좋아보이긴하네요.. 사용은 어렵지 않은데 설계를 잘 하려면 공부가 필요할 것 같아요. 테스트 코드나 swagger 등이 이미 달려있어서 편리한 부분도 많아보여요.

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

Express

세영: 다같이 아키텍처 이해만 맞춰두면 러닝커브가 없어요. 자유도가 높아서 어떤 생각으로 설계했는지가 드러날 수 있다는 것도 장점이 될 것 같아요.
주영: 다들 사용해봐서 러닝커브가 없어요. 저도 이거요.
도훈: 러닝커브가 없고 자유롭게 아키텍쳐를 설계할 수 있어요. 설계 과정에서 4명 모두가 이 프로젝트에 대해서 충분히 이해할 수 있을것 같아요.
원희: 저는 이거요

정리

👍 Nest 설계 위에서 함수 단위로만 고민하면 됨

👎 제대로 알고 사용하지 못할 것 같아서, Express 사용할 때와 큰 차이를 모르겠음

오늘의 논란

11/10 16:16 도훈님: “세 명이서 같이 이야기하고”

→ 한명은 누구..?

→ 그러니까요; 그럴리가;;

→ 한명: 백도훈

→ 급포장..

DB

MongoDB

생각나는 데이터들

유저
워크스페이스
기능 블록
회의록

어떻게 저장?

회의록의 구성요소인 블록은 여러가지 타입을 가질 수 있음
엄청나게 자주 바뀌는 데이터임

// 회의록 하나의 데이터

{
	id: 1,
	name: '왭의 회의록',
	blocks: [
		{ type: 'p', content: '어쩌고' },
		{ type: 'h1', content: '이건 제목입니다' },
		{ type: 'vote', category: [], content: [] }
	]
}

결론

RDBMS보다는 key-value를 사용하는게 적합할 것 같아요.

우선 MongoDB를 쓰고 캐싱 DB는 천천히 생각해보기!

의견

세영: 프로젝트 셋업에 꼭 필요한 것들(패키지 매니저, 사용할 기본 프레임워크 등)은 어느정도 정리된 것 같아요. 상태관리 방식은 아직 어떤 상태와 문제상황이 있는지 정리되지 않은 상황에서 이야기하기에 시기상조라는 생각이 들어요. 설계를 해보고 논의하자고 제안하고 싶어요.

wab