Project Slow-postbox #1 SR 기획

안광의·2021년 11월 11일

[TOY PROJECT] Slow-postbox

목록 보기

1/6

시작하며

코드 스테이츠 두 번째 Section 3가 끝나고 본격적으로 프로젝트를 진행하게 되어서 시작 전에 알아야 할 내용에 대해서 학습하였다. github과 관련된 기능이나 세부적인 기획에 필요한 단계들과 생각보다 많은 기획 자료를 준비해야해서 당황했지만 실제 현업에서 많은 사람들이 함께 프로젝트를 진행하기 위해서는 당연한 단계라는 생각이 들었다. 처음 자체적으로 진행했던 다가치 프로젝트는 테크 스택을 경험하고 코딩하는 과정을 목표로 삼았다면, 코드 스테이츠에서 진행하는 First Project는 실제 현업에서 진행하는 프로젝트를 연습하는 단계라고 생각했다.

SR 기획을 본격적으로 진행하면서 처음에는 개발할 시간도 빠듯한데 이렇게까지 디테일하게 기획을 해야하나라는 생각이 들었는데, 실제로 진행하면서 첫 프로젝트에서 개선해야겠다고 생각했던 부분들이 모두 포함되어 있는 중요한 단계라는 것을 깨달았다.

아이디어 선정

아이디어를 선정하면서 코드 스테이츠 측에서 요구하는 조건과 첫 프로젝트를 하면서 생긴 조건들을 고려해야했다.

최대한 새로운 테크 스택을 피해 학습한 스킬들 위주로 구현 가능한 아이디어
2주 내에 완성할 수 있을 정도로 구현이 복잡하지 않은 아이디어(페이지 수, 데이터베이스 스키마 등)

이번 프로젝트는 2주(사실 상 10일)안에 기획, 구현, 발표 준비까지 끝내야 하기 때문에 비교적 짧은 시간에 완성할 수 있는 프로젝트를 선정해야 했다. 다가치 프로젝트를 진행했을때 목업페이지만 만드는데 1주일 가까이 걸렸기 때문에 구현해야 되는 페이지 수는 적고 기능에 초점을 맞출 수 있는 아이디어가 필요했다. Section 3가 끝나기 일주일전에 프로젝트가 마무리되어서 팀원들과 회의를 통해 내가 예전에 제안했던 느린 우체통을 선정하게 되었다.

테크 스택 및 파트 분배

Position : Full Stack
Stack: node js, express, mysql2, react, redux, axios, aos
Contributions
- Front
  - 상단 고정 네비게이션 바 구현(로그인, 관리자 여부에 따른 표시)
  - 홈 페이지 구현(숫자 카운팅업, 스크롤 애니메이션 포함)
  - 유저 정보 조회(관리자페이지) 페이지 구현(페이지네이션 및 검색 기능 포함)
  - 편지 조회 및 관리(관리자페이지) 페이지 구현(페이지네이션 및 검색 기능 포함)
  - 로딩 페이지 구현
- Back
  - 발송 예정 편지 개수 응답(홈 페이지 사용)
  - 유저 정보 리스트 응답(검색어에 따른 필터링 가능)
  - 편지 리스트 응답(검색어에 따른 필터링 가능)
  - 유저 탈퇴 기능(관리자)
  - 편지 삭제 기능(관리자)
  - 배포 자동화 pipeline 구축
  - 도메인 구입 및 https 연결

기존에 배웠거나 이전 프로젝트에 사용한 스택을 중심으로 선정하였고, Back-end 보다는 Front-end에 시간을 많이 투자해야하는 것을 알기 때문에 4명 모두 Full-Stack을 맡고 기능 혹은 페이지 별로 파트를 분배하였다.

프로젝트 요구사항

Bare minimum requirements

편지 작성 기능(ckeditor 사용)
편지 예약 발송 기능(핵심 feature)
- 예약 날짜 설정
메일 안내 기능
- 편지 예약시, 받는 사람에게 도착 예정 안내 메일이 발송된다.
- 편지 도착시, 받는 사람에게 도착 안내 메일이 발송된다.
보낸 편지함, 받은 편지함 리스트 조회
로그인 기능(로그인, 로그아웃)
회원가입 기능(인증메일 발송)
개인정보 수정 및 탈퇴 기능

Advanced

소셜 인증 로그인 구현
- 네이버, 카카오등 유저들이 많이 사용하는 서비스를 통해 간편하게 로그인
페이지네이션 구현
스케쥴러(node-schedule)에 의한 예약 메일 전송
이미지 첨부 기능 구현(ckeditor)
검색 필터링 기능 구현
반응형 웹사이트 구현
- 모바일, 아이패드를 사용하는 유저도 사용할 수 있다.

Nightmare

음성 메세지 기능
모션 그래픽(홈 페이지 적용)
버튼으로 변경 가능한 다크 모드

너무 쉽지도 않고 구현이 불가능하지도 않은 정도의 목표를 설정하기 위해 회의를 하였는데, 일단 일정은 Advanced까지 구현하는 것을 목표로 삼았고 예상보다 일찍 끝냈을 시에는 Nightmare 단계까지 진행하는 것으로 정하였다.

Team Rule

코드 스테이츠 측의 가이드 없이 자체적으로 첫 프로젝트를 진행했을때 이정도로 팀 룰을 상세하게 정하지 않고 진행해서, 예상치 못한 부분에서 오류가 발생했고 시간을 할애하는 경우가 종종 생겼기 때문에 최대한 상세하게 규칙을 정하기 위해서 노력하였다.

커밋 메시지 규칙

커밋 메시지는 제목과 본문으로 나누어 집니다. 한 줄만 작성해도 설명이 충분하다면 제목만으로도 괜찮습니다. 하지만 어떤 변경 사항이 있는지 맥락과 설명이 필요하다면 본문을 작성할 수 있습니다. 다음은 제목과 본문을 작성하는 규칙입니다.
1. 타입 첫글자를 대문자로 적어주세요.
2. 타입은 명령어로 작성합니다.
3. 제목과 본문을 한 줄 띄워 분리해 주세요.
4. 제목은 50자 이내로 적어주세요.
5. 제목은 명사형으로 작성해주세요.
6. 제목 끝에 . 는 금지합니다.
7. 본문은 50자마다 줄을 바꿔주세요.
8. 본문은 어떻게 변경했는지 보다 무엇을 변경했는지, 왜 변경했는지 에 맞추어 작성하세요.

예시

$ <type>: <subject> -- 헤더
<BLANK LINE> -- 빈 줄
<body> -- 본문 
<BLANK LINE> -- 빈 줄 
<footer> -- 바닥 글

//type 예시
Feat: 새로운 기능을 추가할 경우 
Fix: 버그를 고친 경우 
Design: CSS 등 사용자 UI 디자인 변경 
!BREAKING CHANGE: 커다란 API 변경의 경우 
!HOTFIX: 급하게 치명적인 버그를 고쳐야하는 경우 
Style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우 
Refactor: 프로덕션 코드 리팩토링 
Comment: 필요한 주석 추가 및 변경 
Docs: 문서를 수정한 경우 
Test: 테스트 추가, 테스트 리팩토링(프로덕션 코드 변경 X) 
Chore: 빌드 태스트 업데이트, 패키지 매니저를 설정하는 경우(프로덕션 코드 변경 X) 
Rename: 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우 
Remove: 파일을 삭제하는 작업만 수행한 경우

Feat: 관심지역 알림 ON/OFF 기능 추가(#123)

시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함

opnion0055: 구분 코드 해결: #123

Lint 규칙

semistandard 를 따릅니다.
주요규칙
space는 두 칸, 탭 사용 x
오직 single quote만 사용, 템플릿 리터럴은 표현식 사용할때만 사용하세요.
var 는 사용하지 않습니다.
키워드 다음엔 스페이스 하나를 띄워주세요.
참고링크(https://standardjs.com/rules.html)

브랜치 이름 형식

종류	사용패턴	특징
main	main	프로덕션 스냅샷 가장 최신의 배포된 버전
dev	dev	릴리즈 계획에 따라서 Github에서 기본 브랜치로 지정
feature	feature/이름 feature/branch-name	dev에 병합
hotfix	hotfix/이슈번호 hotfix/#911	메인에 병합

PR형식

코드 컨벤션을 잘 지켜주세요. 컨벤션 오류로 인한 불필요한 코멘트는 시간 낭비이기 때문에 지양하는 것이 좋습니다.
리뷰 가이드라인을 잘 작성해 주세요. 모든 코드 변경사항에는 의도가 필요합니다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야 하고, 줄바꿈과 같이 아주 단순한 변경사항이라도 그 부분을 리뷰어가 볼 필요가 없다면 “Just line change” 와 같은 코멘트를 달아 명시하여 리뷰 시간을 줄여줄 수 있을 것입니다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법입니다.
작업중, 리뷰 가능 여부를 잘 명시해 주세요. 아직 코드를 작성 중일 때에는 [WiP] (Work in Progress) 를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed 태그를 설정할 수 있습니다. 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이 과정을 반복하여 명시해 주세요.
PR 제목

[Client] / #88 / edit: readme

PR 본문

### PR 타입(하나 이상의 PR 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 반영 브랜치
ex) feature/login -> dev

### 변경 사항
ex) 로그인 시, 구글 소셜 로그인 기능을 추가했습니다.

Issue 형식

Issue 제목

[title] / body

### Issue 타입(하나 이상의 Issue 타입을 선택해주세요)
-[] 기능 추가
-[] 기능 삭제
-[] 버그 수정
-[] 의존성, 환경 변수, 빌드 관련 코드 업데이트

### 상세 내용
ex) Github 소셜 로그인 기능이 필요합니다.

### 예상 소요 시간
-[] `0.5h`
-[] `1h`
-[] `1.5h`
-[] `2h`
-[] `2.5h`
-[] `3h`

### 라벨
- 예상 소요 시간: `E: 1h`
- 그룹: `client`, `server`
- 긴급도: `High`, `Middle`, `Low`

변수 이름 - Camel-case

clientLogin

파일 & 생성자 이름 - Pascal-case

ClientSide

node & npm 버전 통일

node: v14.17.6
npm: v6.14.15

프로젝트 진행 규칙

팀원들간 존댓말을 사용하며, 상호 존중하는 마인드를 가지고 커뮤니케이션에 최선을 다한다.
의견이 나눠질 경우 다수결로 결정하며, 2:2로 나뉜 경우 아래의 규칙대로 의사결정한다.
- 충분한 의사소통을 통해 프로젝트에 더 적합한 의견으로 결정한다.
- 의견이 나뉘는 관련 파트의 담당 팀원의 의견으로 결정하되, 다른 팀원의 의견 중 반영할 수 있는 부분은 채택하는 방향으로 결정한다.
미리 약속한 회의 시간을 지키지 않을 경우, 지각비 10분 당 3000원을 팀원을 위해 기쁜 마음으로 기부한다. (줌 접속한 시간 기준)
정규회의 시간:
- 평일 오전 10:00~10:30(현재 진행상황, 오늘 처리할 task 등 브리핑)
- 평일 오후 17:00~18:00(코드리뷰 및 PR Merge, KPT 회고록 작성)

DB schema

기능을 생각하면서 데이터베이스를 짜다보니 생각보다 간단하게 구현이 되서 놀랐다. 처음에 했던 커뮤니티 사이트에 비하면 너무나 간단한 스키마여서 2주 프로젝트에 적합하다고 생각한다. PK를 설정하지 않은 이유는 가입하지 않은 사용자에게도 이메일 주소를 통해 편지를 보내야 하기 때문에 고유한 값인 email을 사용하여 로직을 구현하기로 하였다.

API

https://codeplay-1.gitbook.io/slowpostbox/

처음 프로젝트와 가장 달랐던 점은 기획 단계에서 API를 상세하게 정하였다는 것이다. 필요한 요청과 path 정도만 정해서 router 설정만 해놓고 기능 구현을 하면서 진행하였는데 그래서 백엔드에서 구현해 놓은 서버를 수정하는 경우가 생겼었다. API를 구체적으로 정하는 과정에서 기획 단계에서 놓친 것은 없는지 선택한 테크 스택만으로 구현이 가능한지 다시 한번 체크할 수 있었다.

마치며

SR을 본격적으로 진행하면서 탄탄한 기획이 얼마나 중요한지 느낄 수 있었다. 번거롭고 굳이 해야하는지 의문을 가졌던 단계들도 생각해보면 여러명이서 한 프로젝트 개발을 하기 위해서는 필수적인 사전 작업이라고 생각한다. 진행 중에 불필요한 회의 시간을 줄이고 내가 지금 해야하는 일이 무엇인지를 파악해서 일정대로 프로젝트를 완성도 있게 마치는데 도움이 될 것이라고 생각한다.

안광의

개발자로 성장하기

다음 포스트