요약
본 프로젝트는 한 번 제대로 서비스를 만들어 보자는 취지로 시작되는 프로젝트이다. 최종적인 목표는 회의나 휴식 전 팀원들의 커피 주문을 받기 위한 서비스를 만들어보는 것이며 커피 주문에 필요한 기능(중복 주문 누적 표시, 주문 합계, 특정 시점 주문 종료)을 고려하여 커피타임(이벤트), 주문, 참가자, 음료에 관한 기본적인 CRUD API를 제작하고, 불편사항을 개선하여 리팩토링하는 것까지 전 과정을 수행할 것이다.
본 프로젝트는 프로그래머스의 실무와 가까워지는 Node.js 백엔드 개발 스터디 1기 (유료)를 참여하면서 수행하게 되었다. 물론 이 카테고리의 글을 작성하는 것은 스터디에서 블로그 글을 작성하면 주는 브랜드 키트를 얻기 위한 흑심이 없는 것은 아니지만 해당 스터디에서 배운 내용을 정리하기 위한 목적도 있음을 밝힌다.
그리고 언급해야 할 것은 이 카테고리의 글에서 강의 내용을 완전히 담지는 못했다는 것이다. 이 스터디가 유료 강의다 보니 프로그래머스에서 블로그 글 작성 시 모든 강의 전체 내용을 그대로 공유하지 말라고 가이드라인을 주었기 때문이다. 그래서 당연히 소스코드는 없으며, 내용도 가이드라인에 맞추려고 간략하게 정리된 부분이 있으므로 참고바란다.
프로젝트 배경
보통 점심을 먹고 다들 커피를 마시게 되는데 경우에 따라 팀장님 또는 누군가 커피를 사는 경우가 있을 수 있다. 이 때, 주문을 취합하기 위해 메신저 등을 사용하게 되는데 스터디 리더의 경우 다음 룰을 따라 주문을 받았다고 한다.
- 자신이 원하는 메뉴가 있으면 🤚 이모지를 클릭한다.
- 없으면 자신이 메뉴명을 적고 🤚 이미지를 클릭한다.
그러나, 이 경우 다음과 같은 문제점들이 생길 수 있다.
- 사용방법을 전파받지 못해 어떻게 주문하는지 알지 못한다.
- 주문하는 사람은 전체 몇 잔인지 하나씩 계산
- 주문 완료 후에 메뉴를 바꾸는 일 발생.
- 수령 후 누구의 주문인지 확인 어려움.
이런 문제들을 해결하기 위해서 다양한 방법이 있을 수 있겠지만 이 프로젝트에서는 따로 식당의 주문서와 같은 것을 만드는 방향으로 접근하였다. 간단하게 떠오르는 최소요구사항들을 정리하면 다음과 같다.
- 같은 메뉴(음료)는 누적해서 표시
- 총 몇 잔인지 합계 표시
- 특정 시점에서 주문을 종료하면 주문 변경 불가
데이터베이스
모든 웹 서비스는 어딘가에 데이터를 저장하고 다시 읽어 들여 보여주는 것이 기본이다. 따라서, 서비스를 개발하면서 어떤 데이터베이스를 사용할지 결정하는 것이 필요하다.
전통적으로 데이터베이스는 관계형 데이터베이스를(Relational Database, RDB) 사용하였다. 이 데이터베이스는 표 형태와 같이 정형화 되어있고 SQL이라는 쿼리언어를 사용하여 쉽게 데이터를 조회할 수 있다. 이미 예전에 배운 내용이기도 하고 이 글에서 다 설명하기는 어려우므로 RDB에 대해 더 자세한 설명은 생략한다.
그리고, RDB에 반하여 NoSQL(Not only SQL)이라는 데이터베이스도 있다. 이름에서도 유추할 수 있듯이 NoSQL은 RDB 형태를 따르지 않거나 RDB 외 여러 유형의 데이터베이스를 사용하는 데이터베이스를 총칭한다. 보통 Key-Value 형태나 JSON 형태를 따르는 것이 많이 알려져 있지만 트리 구조나 그래프 등 다른 구조도 많이 사용한다.
이 프로젝트에서는 Firebase의 Cloud Firestore를 사용한다. 이것을 사용하는 이유는 특별한 이유는 아니고 무료로 RDB서버를 구축하기가 쉽지 않지만 Cloud Firestore는 소규모의 경우 무료로 제공해주기 때문이다. 결국 돈 때문이라고 할 수 있지만 그 외에도 NoSQL 데이터베이스 중에서 항상 온라인으로 접속 가능하고 UI가 잘 되어 있어 데이터 조작 및 관리가 쉽다는 장점도 있다.
스터디에서는 데이터 구조에 대해서 샘플을 제공해 주었지만, 해당 내용을 그대로 공개하기도 그렇고 기능들이 구체화 되면 데이터 구조를 변경해야 할 수도 있으므로 대략적으로 필요한 정보만 아래와 같이 정리하였다.
기본적으로 이벤트, 주문, 구성원, 메뉴 4개의 핵심요소에 대한 콜렉션이 있으며 이벤트에는 주문에 대한 리스트, 그리고 주문에는 구성원과 메뉴가 포함되게 된다.
개발 언어
Node.js를 사용하는 만큼 사용하는 언어는 Javascript를 사용해야 할 것이다. Javascript 자체만으로도 좋은 언어이고 Node.js에 의해 서버 개발이 가능하지만 Javascript 자체가 난해한 언어이기도 하고 변수의 타입이라는 개념이 없기 때문에 개발 후 디버깅 과정에서 코드 추적이 쉽지 않다는 문제가 있다. 이러한 문제는 협업할 때도 그렇고 본인의 코드 조차도 시간이 지나면 코드를 어떻게 그리고 왜 그렇게 작성했는지 까먹을 때도 있어 이러한 상황에서 변수에 어떠한 값이 들어가야하고 어떤 형태인지 알기 힘든 경우가 많이 발생하게 된다.
Typescript는 Javascript에 타입이라는 개념을 추가해줌으로서 이런 문제를 방지해줄 수 있다. 추가로 에디터에서 자동으로 타입체크를 해줄 수도 있으므로 디버깅 시간을 훨씬 단축시켜 줄 수도 있다. 그리고 Javascript의 슈퍼셋(Superset)이므로 타입스크립트를 쓴다고 해서 Javascript의 코드를 못 쓰는 것이 아니다. 물론 Typescript는 이 외에도 다른 많은 장점들을 가지고 있지만 예전에 배운 내용도 있고 해서 더 자세하게 적지는 않는다.
어쨌든, 최근의 대세는 Javascript 대신 Typescript를 사용하는 것이 대세이기도 하므로 본 프로젝트에서는 Typescript를 사용하여 서비스를 개발한다.