기술스택

분류	기술 스택
공통
프론트엔드
백엔드
배포
협업

[노션] 기술스택 선택 이유

FE

React

	장점	단점
React	- 컴포넌트 기반 UI 설계로 재사용성이 높음 - 다른 라이브러리와의 높은 호환성 - CSR 방식으로 동적인 페이지 개발 가능 - 초기 설정이 간단함 - 거대한 커뮤니티로 인한 정보 접근성 - Virtual DOM 사용으로 UI 변경 시 성능 최적화	- IE8 이하 버전을 지원하지 않음 - 데이터 모델링, 라우팅, AJAX 등의 기능이 기본 지원되지 않음 - JavaScript와 JSX에 대한 배경지식이 필수 - 빠르게 변하는 프론트엔드 트렌드로 인한 학습 부담 - 상태 관리가 복잡함 - 높은 유연성으로 인해 팀 커뮤니케이션 비용 증가
Vue	- 낮은 러닝커브 (바닐라 JavaScript와 유사) - React보다 빠른 렌더링 속도 (미세한 차이)	- 상대적으로 작은 커뮤니티
Angular	- TypeScript 기본 지원	- 높은 러닝커브 - 설정과 빌드 시간이 비교적 오래 걸림
Next.js	- SSR 방식으로 SEO에 친화적 - Pre-rendering 방식으로 웹페이지 미리보기 가능 - 풀스택 개발 지원	- React에 비해 초기 설정이 무겁고 번들 사이즈가 큼 - React와 Vite만 사용할 경우와 비교했을 때, 오버헤드, 안정성, 유지보수성에 단점 존재 - 러닝 커브 이슈

• 기술적 선택 이유
  • 프론트엔드는 사용성이 중요하기에 SPA(Single Page Application) 라이브러리/프레임워크를 고려
    • React는 JSX로 DOM 조작이 용이
    • 큰 커뮤니티
  • 팀원들이 모두 경험해본 라이브러리로, 생산성 측면에서 좋음
  • 프로젝트의 핵심인 워크스페이스 환경은 private 해야하기 때문에 SEO가 필요 없음
  • Next.js의 장점을 활용할 필요성이 없는 프로젝트
    • 모든 핵심 기능이 워크스페이스에 몰려있으며, 변경사항에 대해 클라이언트 측에서 빠르게 반응해야하기에 정적인 웹사이트를 렌더링 하는 방식인 ssr과는 적합하지 않음
    • 변경사항이 계속 생길 수 있는 동적인 성격의 웹이다보니, 서버에서 렌더링해줄 필요가 없음.

Typescript

	장점	단점
TypeScript	- 정적 타입 검사로 타입 안정성을 제공함 - 컴파일 과정에서 오류를 찾아, 개발 단계에서의 안정성을 높임 - 유지 보수 및 협업에 유리함 - 기존 JavaScript와 완벽하게 호환됨 - 기존 JavaScript 프로젝트에 TypeScript를 점진적으로 적용해서 마이그레이션할 수 있음 - 타입을 미리 체크하기에 JS에 비해 실행 시간이 빠름 - TypeScript는 class에서 private 기능 지원, interface, type 등을 통해 객체 지향 프로그래밍이 더 쉬워짐	- 컴파일 시간이 생겨 빌드 시간이 증가함 - 러닝커브가 있음 (interface, type, enum 등 JavaScript에 없는 기능을 추가로 배워야 함) - any를 남발할 경우 TypeScript의 장점을 활용할 수 없음 - 초기 설정이 복잡함 - 기존 JavaScript 코드에 타입을 선언하고 지정하는 과정에서 코드의 수가 증가함
JavaScript	- 브라우저에서 즉시 실행 가능	- 타입 안전성이 부족함

• 기술적 선택 이유
  • 장기적인 유지보수성 강화: 코드 작성 시 오류를 컴파일 시간에 잡아주고, IDE의 자동 완성 기능으로 코드 품질 향상
  • 데이터 구조 명확화: 타입 명시로 데이터 구조와 형태를 엄격하게 관리하기 때문에 협업 시 코드의 일관성을 유지

Vite

	장점	단점
Vite	- 모든 모듈을 하나의 컨텍스트 기반으로 실행하기 때문에 별도의 평가 과정 없이 빠른 실행을 보장 - 설정이 매우 간편함 - ESM을 사용해서 최신 브라우저에 적합함 - EsBuild를 통해 빠른 속도의 번들링 제공	- Dynamic import를 지원하지 않으며, 모듈 간 순환 참조 문제가 발생할 경우 이를 제어하지 못함 - Webpack에 비해 플러그인이 적음 - 구형 브라우저 지원에 제약이 있음 - Next.js와 직접적으로 호환되지 않음
Webpack	- 각 모듈을 함수로 감싸 스코프를 격리하기 때문에 모듈 간 식별자 충돌을 완벽히 방지 - Module Cache를 통해 순환 참조 문제가 발생해도 캐싱된 모듈을 반환하여 제어 가능 - Vite에 비해 더 많은 로더와 플러그인 지원	- 각 모듈이 런타임에서 실행되고 Module Cache에 추가되기 때문에 실행 속도가 느림 - 유연하지만 초기 설정이 복잡함

• 기술적 선택 이유
  • 설정이 Webpack에 비해 간편함
  • ESM기반 HMR(Hot Module Replacement)로 빌드 속도와 개발 환경이 빠름

tailwindcss

	장점	단점
Tailwind CSS	- 클래스 작명이 불필요함 - 개발 속도가 빠름 - 빌드 타임에 스타일을 적용하고, 불필요한 CSS를 제거하여 초기 로딩 속도가 빠름	- 가독성이 좋지 않음 - 동적 스타일 적용에 대한 유연성이 떨어짐
Styled-Components	- 컴포넌트 기반 스타일링으로 재사용성이 높음 - 동적 스타일링이 용이함 - 스타일 스코프가 지역적이어서 스타일 충돌을 방지	- 런타임에 스타일을 생성하므로 초기 로딩 속도가 Tailwind CSS에 비해 느릴 수 있음

• 기술적 선택 이유
  • 개발 트렌드 + 빠른 생산성 (클래스 작명 및 파일분리 불필요)
  • 런타임이 아니라 빌드타임에 스타일을 적용하고, 불필요한 css는 제거해서 초기 로딩 속도가 빠름

Zustand + Tanstack-Query

	장점	단점
Zustand	- 작은 번들 사이즈 - 낮은 러닝커브 - 간단한 설정 - 선택적 리렌더링 지원 - TypeScript 지원 - 보일러플레이트가 거의 없음	- 서버 상태 관리에 한계 - 작은 커뮤니티 - Redux에 비해 미들웨어 지원 부족 - 공식 디버깅 도구 미지원 (상태 변화 추적 어려움) - 상태 관리가 복잡해지면 어려움 (트리 기반으로 관리하지 않음)
Tanstack Query	- 비동기 데이터 관리에 특화 - 서버 상태 자동 캐싱 및 최신성 자동 유지 - 서버와의 손쉬운 동기화 및 재검증 지원 - 편리한 사용법	- 고급 기능 학습 필요 - 클라이언트 상태 관리에 비효율적 (다른 쿼리키 사용 시 데이터 일관성 깨짐) - 데이터 캐싱 전략 복잡 - 새로고침 시 상태 초기화 (캐싱 메모리 기반) - 러닝커브 존재
Redux	- 거대한 커뮤니티 - DevTools 지원	- 보일러플레이트가 많음 - 러닝커브가 높은 편
Context API	- 기본 제공으로 추가 라이브러리 불필요 - 간단한 상태 관리에 적합	- 성능 최적화 어려움

• 기술적 선택 이유
  • 컴포넌트 개수가 적지 않아 props drilling을 방지하기 위해 상태관리 라이브러리를 도입
  • 클라이언트 상태는 러닝커브가 낮고 효율적인 상태관리를 제공하는 zustand를 선택
  • 서버 상태를 자동으로 캐싱해주고 에러 처리가 용이한 Tanstack-Query를 선택

BE

Express

	장점	단점
Express	- 빠르게 API 서버 구축 및 확장 가능 (간단하고 가벼운 설정) - 간편한 설정과 높은 자유도로 미들웨어와 라우팅 관리 용이 - 경량 서버라 Node.js와 잘 결합되어 응답이 빠름	- 자유도가 높은 만큼 초기 세팅과 컨벤션 맞추기가 어려움 - TypeScript를 기본적으로 지원하지 않음 (별도 세팅 필요) - 대규모 프로젝트에서는 관리가 어렵고 추가 설정이 필요 - 웹소켓을 기본적으로 지원하지 않음 (Socket.IO 등 별도 라이브러리 필요)
Nest.js	- TypeScript가 기본적으로 지원되어 초기 설정 부담이 적음 - RESTful API 서비스 관련 주요 기능 기본 제공 (HTTP 연결, DB 연동, 미들웨어 구축, 인증 보안 등) - 필요한 클래스를 자동 생성해주는 명령어 제공 - Swagger 문서를 자동 연결	- 백엔드에 익숙하지 않은 경우 러닝커브가 있음 - 간단한 서버에서는 비효율적 (다양한 기본 설정들로 인해 프레임워크가 무거움) - 자유도가 낮음

• 기술적 선택 이유
  • NestJS에 비해 러닝커브가 낮음
  • NestJS의 장점을 활용할 필요성이 없는 프로젝트
    • 우선순위로 따져보았을 때, 현재 프로젝트에선 사용자 인증이 크게 중요하지 않음
    • 많은 api가 필요하지 않음
    • 후순위 기능들 개발도 진행하게 된다 해도 백엔드의 볼륨이 크게 커지지 않음

MongoDB + Mongoose

	장점	단점
MongoDB	- JSON 형식의 Document 기반 구조 - 스키마 사전 정의가 필요 없으며 비정형 데이터를 저장하기에 적합 - JavaScript와 연동이 쉬워 확장성이 좋음 - 쿼리 기능이 풍부 - 수평 확장을 지원하여 데이터가 많아질 경우 서버를 쉽게 추가 가능	- 데이터 관계가 복잡하면 스키마를 나누기 어려움 - 복잡한 쿼리에서는 SQL에 비해 제한적 - 트랜잭션 지원이 제한적
Firestore	- 서버를 따로 구축하지 않아도 됨 - 오프라인 지원	- 제한된 쿼리

• 기술적 선택 이유
  • 서버에 저장하는 데이터의 볼륨이 크고, 형태를 정형화 시키기 어려워 NoSQL DB인 MongoDB 선택
  • Node.js 환경에서 MongoDB와 상호작용하기 위한 전용 ORM라이브러리인 Mongoose 선택

배포

Nginx

	장점	단점
Nginx	- SSL/TLS 지원으로 HTTPS 설정 가능 - 단일 서버에서 여러 애플리케이션을 함께 호스팅 가능 (프론트/백엔드 서버 분리 불필요) - 다양한 프록시 기능으로 백엔드와의 통신 최적화 가능 ◦ 정적 파일(HTML, CSS, JS, 이미지)을 캐싱하고 빠르게 제공 ◦ 로드 밸런싱 제공 - 배포 시 속도와 안정성을 높이는 중요한 역할	- 복잡한 설정과 학습 곡선 존재
Apache	- 모듈화된 구조로 커스터마이징 및 확장 가능 - 보안 설정이 용이	- 설정 파일이 복잡하며 성능 최적화가 필요

• 기술적 선택 이유
  • https 설정을 통한 보안 강화
  • 로드 밸런싱을 통해 배포시 속도와 안정성을 보장해줌
  • apache에서 방치되는 프로세스와 컴퓨터 자원을 훨씬 효율적으로 사용하기 때문에 성능이 좋음

docker

	장점	단점
Docker	- 빠른 배포 가능 → 새로운 버전 업데이트에 용이 - 컨테이너 가상 환경 제공 ◦ 호스트 서버에 영향을 주지 않음 ◦ 경량 가상화 - 커뮤니티 활성화 → Docker 이미지를 배포 환경에 맞춰 쉽게 가져와 활용 가능 - 환경을 하나의 이미지로 패키징하여 어디서나 동일한 환경에서 실행 가능	- 네트워크 구성이 복잡할 수 있음

• 기술적 선택 이유
  • 별도의 OS 설치 및 설정이 불필요함
  • 배포가 편리함
  • 경량 가상화

ncp

	장점	단점
NCP	- 네이버에서 지원하는 클라우드 인프라로 서버, 데이터베이스, 네트워크 등 다양한 서비스 제공 - 한국 최적화 + 네이버 클라우드 캠퍼스 무료 제공	- 글로벌 클라우드 서비스에 비해 확장성과 생태계가 한정적임
AWS	- 광범위한 글로벌 인프라와 다양한 서비스 제공 - 큰 규모의 생태계와 커뮤니티 지원	- 높은 비용 - 다양한 서비스로 인해 초보자에게는 학습 곡선이 존재

• 기술적 선택 이유
  • 한국 최적화 + 네부캠 무료

github actions

	장점	단점
GitHub Actions	- GitHub에서 제공하는 자동 배포 서비스 - 코드 저장소에 변경 사항이 발생할 때마다 자동으로 빌드, 테스트, 배포 파이프라인 실행 - 설정해두면 자동화 가능 + GitHub 통합으로 편리함	- 설정이 복잡할 수 있음 - GitHub 레포지토리에 종속적이라 제약이 될 수 있음 - 사용량에 따른 비용 발생 가능
Jenkins	- 광범위한 플러그인 지원 - 높은 커스터마이징 가능 - 대규모 프로젝트에 적합	- 초기 설정이 복잡하고 시간이 소요됨

• 기술적 선택 이유
  • GitHub 레포지토리와 통합되어 있어서 설정이 편리.
  • 대규모 프로젝트가 아니기 때문에 GitHub Actions가 더 효율적이라고 판단.