BE 기술 스펙

Typescript

• 프론트엔드/백엔드에 상관없이 코드리뷰를 할 때, 프론트엔드에서 주로 사용하는 Javascript를 사용하는 것이 맞다고 판단했습니다.
• 하지만 Javascript는 동적 타이핑 언어라서 컴파일 단계에서 타입 오류를 발견하기 힘듭니다.
• 검증에 필요한 시간과 노력을 줄이기 위해 TypeScript를 선택했습니다.

NestJS

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

RDBMS

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

ORM vs Native SQL

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

Jest vs Mocha

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

ElasticSearch

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

---

MySQL vs PostgreSQL

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

TypeORM, Sequalize, Prisma

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