소개
네이버 부스트캠프 7기 프로젝트로 진행한 6주간의 짧은 프로젝트이다.
첫 웹 프로젝트로, 짧은 기간안에 기획, 개발, 배포까지 모두 경험할 수 있었다.
팀 구성은 FE 2명, BE 2명으로 이루어졌고 팀원 전부 서울권에 가까워서 역삼역에 공유 오피스를 빌려 오프라인으로 만나서 진행할 수 있었다.
📝 기획
1.
주제정하기..!
주제는 엄청 빨리 정해졌다. (기간이 짧다보니 빨리빨리 하게되었다.) 팀원들 각자 어떤 프로젝트를 하고 싶은지 생각해왔고 어떤게 좋은지 투표로 결정했다. 주제로 Slack, Discord와 비슷한 실시간 채팅 서비스를 개발하기로 결정했다. 그리고 기술적인 도전으로 안 읽은 채팅에 대한 알림을 구현하기로 했다.
2. 주제를 정했으면 이제는 기능..! (
백로그작성)
사용자가 어떤 행위를 할 수 있는지를 기준으로 백로그를 작성하였다.
그 후, 중요도와 우선순위를 추가하여 작업의 순서를 알 수 있게 하였다.
백로그와 더불어 어떤 작업을 할 것인지 테스크를 추가로 작성하였다. 이렇게 작성하니 서로 어떤 것을 하고 있는지 한 눈에 볼 수 있었다.
3. 어떤 기능이 있는지 알겠어. 그러면
UI를 작성해야겠지..!
Figma를 활용하여 다음과 같이 디자인하였다. 자세한 것은 아래 링크에서 확인할 수 있다.
https://www.figma.com/file/rMLRLD7pVWItjgqOIq5tga/Asnity-Design
4. 팀 프로젝트의 규칙은..?
Ground Rule
우리팀의 그라운드 룰은 여기에 있다.
가장 도움이 되었던 그라운드 룰은 데일리 스크럼 작성이다.
일과를 시작하기 전에 서로 어떤 것을 했고 어떤 것을 할지 작성하였다. 예시는 여기 에 있다.
데일리 스크럼을 진행하면서 다음과 같은 장점이 있어 이번 프로젝트에서 가장 잘한 일 중 하나라고 생각한다.
- FE, BE 서로 개발 어느정도 진행되었는지 또 오늘 어떤 작업을 할 건지를 팀원 모두 어느정도 인지하고 있는 것은 소통하는데 중요하다.
- 오후 10시 30분에 퇴근하기 전 5F 회고를 하였는데 서로 어떤 것을 했고 또 어디서 힘들어 하고 있는지 알 수 있었고 서로 도움을 줄 수 있었다.
또 매주 KPT 회고도 진행하였는데 한 주를 돌아보며 어떤 부분을 계속 이어갈지(Keep), 어떤 문제가 발생했는지(Problem), 어떤 노력을 할 것인지(Try) 를 서로 얘기를 나누는 시간도 가졌다.
5. Github를 사용할건데
Branch 전략은 어떻게..?
다음과 같은 Branch 전략을 택했다.
main(master) branch에 병합되면 배포 서버로 자동 배포되도록 하였.
dev, FE/BE branch로 병합되면 개발 서버로 자동 배포되도록 하였다. CI/CD 툴로는 Github Action을 활용하였다.
6. 이제 개발을 바로 앞뒀는데 코드를 짜기전에
Convnetion을 정해야 겠지..?
Coding Convention과 Commit Convention을 다음과 같이 정했다.
🧑💻 개발하기에 앞서
1. FrameWork는 어떤걸로..?
JavaScript를 활용하여 개발하기로 하여 활용할 수 있는 프레임워크로 Express, koa, NestJS 등이 있었다.
Express는 많은 자료가 있다는 장점이 있어 사용을 고려하였다. 하지만 프로젝트를 하기 전에 진행했던 학습 스프린트(8주) 동안 사용하면서 구조가 달라 코드 리뷰할 때 구조를 먼저 파악해야하는 불편함이 존재하였다. 그래서 팀 프로젝트에서는 어느정도 코드 구조의 자유성을 제한하여 코드 구조를 통일하는 것이 좋다고 생각하여 NestJS를 사용하게 되었다. 또 NestJS가 Spring 구조와 비슷하다고 하여 나중에 Spring을 공부할 때도 구조를 파악하는데 도움되겠다 생각하여 결정한 것도 있다.
2. DB 는 어떤걸로..?
DB는 mongoDB를 선택하였다. 우선 우리 서비스의 데이터 구조를 먼저 생각해보면 채팅 메시지 데이터가 저장될 것으로 대용량 데이터 처리에 용이한(scale-out에 편리) DB가 적합하다고 생각했다. RDBMS 보다 NoSQL을 활용하기로 하였다.
NoSQL 중에 정보(튜토리얼)가 많아서 사용하기 비교적 쉽고 또 데이터를 Document 형식 관리하는 것이 우리 서비스에 적합하다고 판단하여 mongoDB를 사용하기로 결정하였다.
마치며
여기까지 프로젝트 개요에 대한 내용이다.
프로젝트 하면서 어떤 고민을 하였는지는 추후 블로그 포스팅을 하도록 하겠다.
