🗂 기술 스택

목차

• 공통 기술스택
• 프론트엔드 기술스택
• 백엔드 기술스택

공통 기술스택

JavaScript, TypeScript

• 프론트엔드-백엔드 작업을 나누어 하더라도, 코드리뷰 등 협업을 위해 프론트엔드에서 사용하는 JavaScript 언어를 사용하려고 생각했습니다.
• 하지만 JavaScript 는 동적 타이핑 언어기 때문에 컴파일 단계에서 타입 오류를 발견하기 어렵습니다.
• 그래서 검증에 필요한 시간과 노력을 줄이기 위해 TypeScript 를 선택했습니다.

프론트엔드 기술스택

React

• 기획한 프로젝트가 SNS 형식으로, 특정 부분만 다시 그리는 작업이 많을 것 같아서 SPA에 적합한 라이브러리를 고민했습니다.
• 짧은 시간 내에 기획한 요구사항을 모두 만족시켜야 하기 때문에 라이브러리를 학습하는 시간도 고려해야 했습니다.
• 기존에 React 경험이 있는 팀원이 있고, 커뮤니티가 크기 때문에 검색에 유리하다고 생각해서 React 를 사용하기로 결정했습니다.

Vite

• CRA 를 사용해서 개발했을 때 배포 시 빌드 속도가 너무 느렸던 경험이 있어서 이를 개선하고자 고민했습니다.
• Vite 는 내부적으로 dev 환경에서는 ES Build 를 사용하여 매우 빠른 번들링 속도를 가지고 있습니다.
• 또한 production 환경에서는 RollUp 을 사용하여 웹팩보다 빠른 번들링 속도를 가지고 있습니다.
• Vite 가 SSR에 약점을 가지고 있는데, 이번 프로젝트에서는 CSR을 기획했기 때문에 문제가 없다고 생각했습니다.
• 관련 문서 : Vite: CRA vs Vite

React Query

• 프로젝트 기획 단계에서 포스트 정보, 리뷰 정보, 좋아요/북마크/팔로우... 여부 등 클라이언트보다 서버에서 받아와는 상태가 많다고 생각했습니다.
• 클라이언트 상태로 관리하게 되면 서버 요청을 위한 코드, 동기화, 캐싱 등을 위한 코드 등 보일러플레이트가 많아질 것이라고 판단했습니다.
• 그래서 서버 상태관리를 위한 라이브러리 도입을 시도했고, React Query 와 SWR 중 사용 경험이 있고, 공식적으로 DevTools 를 지원하는 React Query 를 선택했습니다.
• 관련 문서 : React Query: 서버 상태관리 라이브러리

Zustand

• 클라이언트에서 관리하는 상태가 많고 컴포넌트의 depth가 깊어져 전역 상태 관리 도구가 필요했습니다.
• 보일러 플레이트가 적고 핵심 소스코드가 오직 42줄이기 때문에 러닝커브가 적어 빠른 시간 내에 학습하여 적용하기에 용이했습니다.
• 또한 Provider로 감싸지 않고도 사용할 수 있기 때문에 더욱 간결하게 사용할 수 있었습니다.
• Redux Devtools를 사용할 수 있어 디버깅이 용이했습니다.
• 관련 문서 : Zustand: 전역 상태관리 라이브러리

SASS

• Nesting 을 이용하여 BEM 방법론을 적용했을때의 사용성을 높여줍니다.
• CSS-IN-JS 에 비해 높은 성능을 보여줍니다.
• mixin 을 이용하여 css의 중복을 줄여줍니다.
• CSS 문법과 완벽하게 호환됩니다.

MSW

• 프로젝트 시작 이후 도입된 라이브러리로, 클라이언트-서버의 개발 속도 차이로 클라이언트에서 API를 사용하는 기능을 테스트 함에 어려움을 겪었습니다.
• 이를 해결하기 위해 테스트를 위한 소스코드 변경 없이, 여러가지 조건을 주면서 테스트할 수 있는 MSW 라이브러리를 도입하게 되었습니다.
• 관련 문서 : 클라이언트에서 API 테스트를, MSW.js 도입기

백엔드 기술스택

NestJS

• 이번 프로젝트를 통해 성능을 개선해나가는 과정을 경험하고 싶었습니다.
• 그러기 위해 핵심 로직을 제외한 단순한 작업들을 빠르게 마무리하고 싶어 NestJS를 선택했습니다.
• 러닝커브가 높다는 단점이 있지만, 백엔드를 맡은 팀원 모두 Spring 을 사용한 경험이 있습니다.
• 따라서 사용경험이 유사한 NestJS를 빠르게 학습할 수 있겠다고 판단했습니다.
• 성능을 개선해나가는 과정에서 프로젝트의 규모가 점점 커질 텐데, 잘 설계된 구조 위에서 작업하는 것이 확장에 용이할 것이라고 생각했습니다.

Jest

Jest vs Mocha

• Jest의 자료가 더 많아 학습이 용이할 것으로 판단했습니다.
• Jest가 속도가 더 느리다는 단점이 있지만, 사용자들의 속도를 저해하는 요소는 아니라 Jest를 사용하기로 했습니다.

ElasticSearch

• 검색 성능 최적화를 위해 선택했습니다.
• MySQL에서 70만개의 데이터를 넣고 검색 테스트 결과, Full Text Search 외에는 방법이 없다 판단했습니다.
• 직접 Full Text Query를 구현하려 했지만, 한국어의 형태소 분석을 하기에는 시간이 한정되어 Elastic Search를 도입했습니다.

Logstash

배포가 진행되어 게시글이 작성된 이후, ElasticSearch를 도입하였습니다. 따라서 기존의 데이터를 유지할 필요가 있었습니다. MySQL에서 Elastic Search로 데이터를 가져오기 위해 Logstash를 사용했습니다.

MYSQL

• 개발 생산성을 위해 익숙한 MySQL을 사용했습니다.

관계형 데이터베이스 선택 이유

• 우선 저희 프로젝트는 이미지를 포함한 게시글이라는 정형 데이터를 다룹니다.
• 그리고 엔티티들의 관계가 명확하기 때문에, 관계형 DB를 사용하는 것이 맞다고 판단했습니다.

Mongo DB

• 검색 조건이 다양하기 때문에 검색어를 NoSQL에서 관리하는 게 적절하다고 판단했습니다.

TypeORM

• TypeORM, Sequalize, Prisma 중 타입스크립트를 사용하는 관계로 궁합이 좋은 TypeORM을 사용했습니다.

ORM vs Native SQL

• ORM을 쓰면 개발할 때 테이블들을 객체로 다루기 때문에 직관적으로 테이블간 관계를 파악하기 쉽습니다.
• 또, SQL 문장을 그대로 쓰면 개발 편의성이 좋지 않습니다.
• 복잡한 쿼리를 처리해야 한다는 단점이 있지만, ORM에서 지원하는 QueryBuilder를 사용하면 된다고 판단했습니다.