1. 프로젝트 기간
⌚️ 2022.08.29 ~ 2022.09.23 (26일)
- 1주차: 프로젝트 기획
- 2주차: 1차 기능 구현
- 3주차: 2차, 3차기능 구현
- 4주차: 리팩토링 및 버그수정
2. 팀원
| 포지션 | 이름 | 역할 | 담당 |
|---|---|---|---|
| Backend | 염준호 | 팀장 | 로그인, 카페 게시판, 리뷰, 마이페이지, 카페 예약, 찜 |
| Backend | 정승현 | 발표, 깃관리자 | 결제, 검색, 이미지 업로드, 커뮤니티 게시판, 좋아요, 댓글, GCP 배포 |
| Frontend | 정재인 | 노션 관리자 | 로그인, 회원가입, 마이페이지, Mobile Layout, AWS 배포 |
| Frontend | 정예은 | 발표자료 제작 | 랜딩페이지, 카페 게시판, Web Layout |
| Frontend | 김성연 | 깃 관리자 | 카페 테이블 페이지, 댓글, Web Layout |
3. 사용한 스택
| 포지션 | 사용한 스택 |
|---|---|
| Backend | Javascript, Typescript, Nest.js, node.js, Redis, Elasticsearch, Logstash, TypeORM, MySQL, GraphQL |
| Frontend | Javascript, Typescript, ESLint, React, Apollo, Next.js, GraphQL, Recoil, Toast UI, Prettier, |
| 협업, Dev | Github, Docker, Trello, Notion, Google Cloud, Dischord |
4. 구현한 기능
- 로그인 기능(일반 및 소셜 로그인)
- 마이페이지
- 게시판 CRUD
- 좋아요 기능
- 댓글 기능
- 결제
- 검색 기능(title, content)
- 카페 예약 기능
5. 내가 맡은 역할
- 팀장
- 각종 문서 제작
- 로그인
- 카페 게시판 CRUD
- 리뷰 기능
- 예약 기능
- 찜 기능
6. 좋았던것
프론트엔드와 함께 결과물을 만들어낼 수 있었던것
- 백엔드 혼자만으로는 실제로 사용자에게 보여지는 부분을 구현하지 못하기 때문에 아쉬운 부분이 있었다. 하지만 백엔드, 프론트엔드를 함께 팀으로 구성하여 프로젝트를 진행하면서 내가 만든 API가 이렇게 쓰이는구나 라고 직관적으로 알 수 있게 되어 좋았다.
SQL의 필요성을 느끼다
- DB의 다양한 Data를 보내주기 위해서 특히
다대다 관계에서SQL과 TypeORM에 대해서 더 공부해봐야 겠다는 생각을 하게 되었다.
7. 아쉬웠던것
7-1. 프로젝트 관련
- 체력 부족
프로젝트를 진행하면서 체력 관리에 많은 어려움을 겼었다. 2개월 정도의 기간동안 나름 체력 관리를 잘 했다고 생각했는데 프로젝트 초기에 한번 몸살을 앓았다.
아플때 참고 주어진 프로젝트 기능을 구현하려고 했지만, 정해진 목표치를 달성할 수 없었다.
- 제공하려는 서비스의 기획
기존에 있는 많은 서비스들 보다 매력적인 서비스를 만드는 것이 쉽지 않았다.
우리가 생각해본 많은 아이디어들은 이미 서비스되고 있는 경우가 많았다.
- DB 및 ERD 구조 설계
초기 설계한 ERD를 점검 받으며 3번정도 수정하게 되었다.
가장 아쉬웠던 것은 계속되는 ERD의 수정으로 프로젝트 속도가 느려졌던 점이다.
하지만, 끊임없이 ERD구조에 대해서 팀원 및 동기들과 이야기하며 수정함으로써,
그동안 확실하지 않았던 관계들에 대해 더 명확하게 알수 있게 되었다.
- 서비스에 필요한 필수 기능 및 주요 기능 설계
프로젝트가 진행될 수록 결과물이 구체화 됨에 따라서 불필요한 기능과,
필요했는데 기획하지 못했던 기능이 많이 보였다.
특히, 마이페이지와 예약 관련 기능들은 프론트엔드 팀원에게 빨리 만들어서 전해주기 위해 만들었기 때문에, 프로젝트가 종료된 이후 많은 리팩토링 소요를 만들었다.
- 일정에 맞춘 개발
팀장으로써 가장 아쉬웠던 부분이다.
프론트엔드 팀원들의 작업 내용과 작업에 필요한 시간에 대한 이해도가 낮았고,
팀장으로써 프로젝트 일정과 작업 진행도를 지속적으로 비교하며 작업속도에 대한
피드백을 더 적극적으로 주었어야 했다고 생각했다.
또한 팀원들이 특정 기능을 구현하기 위해서 너무 오랜 시간이 걸리는 경우가 있었는데
이를 더 빨리 파악해서 필수 기능이 아닌 경우 후순위로 미루거나,
해결할 수 있는 팀원을 배정 했어야 했지만,
이에 대한 대응이 늦어 프로젝트 일정이 조금씩 늦어지는 원인이 되었다고 생각한다.
- 백엔드와 프론트엔드의 이해
프론트엔드와 백엔드 팀의 개발 속도가 많이 달랐다.
다른 팀들과 달리 디자이너를 영입하지 않고,
프론트엔드 팀원들이 직접 디자인을 하며, 코드 작업도 함께 진행했기 때문이다.
- 소통의 중요성(어떻게 내용을 전달 할 것인가)
API Docs를 작성하고, 소통하려고 노력했지만,
API를 변경한 이후에 프론트엔드에 이야기해주는 것을 잊거나,
변경사항을 전달해주었지만, 프론트엔드에서 작업 우선순위에 밀려 잊혀진 경우도 있었다.
변경사항을 더 적극적으로 문서화하여 전달할 수 있는 방법을 고민해 보았다면,
더욱 명확한 소통을 할 수 있었을텐데 라는 아쉬움이 있었다.
7-2. 코드와 기능 구현관련
- 커밋 컨벤션
신세원님의 Git | git 커밋 컨벤션 설정하기
conventional commit
프로젝트를 진행하면서 커밋 컨벤션에 맞춰서 commit 기록을 작성해야지 라는 목표를 가지고 있었는데, 이거 생각보다 쉽지 않았다.
제목은 내용을 포함해서 어디에 작성하라는거지...?
이런 작업은 얼마나 상세하게 작성해야 하는거지...? 라는 물음이 아직 떠나지 않는다.
벨로그와 conventional commit 사이트를 통해 내용은 어느정도 이해했지만, 어떻게 적용해야 하는지에 대한 의문이 아직 떠나지 않는다.
해당 내용은 나의 지식으로 이해하고나면, 벨로그 글로 작성하여 남길 예정이다.
- 테스트코드
백엔드를 구현하는 입장에서 테스트코드를 구현 하는 것을 목표로 했지만,
다른 기능구현에 우선순위가 밀려 작성하지 못했다.
벨로그 작성으로 기초적인 부분을 조사한 후에,
프로젝트 코드에 테스트코드를 적용시키는 작업을 할 계획이다.
- 타입스크립트
API 수준에서는 타입스크립트를 사용했지만, service.ts에서는 함수 인자와, 리턴값에 타입을 지정하지 않았다.
타입을 명확하게 지정해 주어 타입스크립트의 장점을 더 확실히 사용하고싶다.
또한 인터페이스를 사용하는 방법에 대해서 더 깊이 알아보고, 리팩토링에 반영하고 싶었다.
- DB (트렌젝션)
가장 필수적인 결제 기능에만 트렌젝션을 구현하였다.
하지만 실제 서비스에서는 더 짧은 시간 안에 더 많은 요청들이 처리된다.
더 적극적으로 트렌젝션을 사용하여 DB에 데이터가 안정적으로 저장될 수 있도록 하고싶다는 생각을 했다.
- 구현하지 못한 기능들
채팅, 쿠버네티스를 이용한 배포, 대댓글, 관리자페이지등 구현을 계획했지만,
구현하지 못한 기능들을 리팩토링을 진행하며 구현하고 싶다.
- API이름과 변수이름(최악의 이름 우승작 후보)
최악의 API 이름이라고 생각했던 후보를 일부 가져왔다.
부끄럽게도 내가 작명했다.
fetchUserMyBoardNumber // 유저가 작성한 게시글 조회
fetchUserFavoriteCafe // 유저가 찜한 카페 조회
- DB의 Column과 API이름은 프론트엔드와 협업하는데 있어 매우 중요했다.
충분히 고민하지 않고 만들어진 API와 Column은
추가적인 설명을 필요하게 만들었다.
프로젝트가 진행될 수록 이름으로 의미를 알기 힘든 API는
수많은 API들중에서 어떤 기능을 했는지 다시 확인하고 프론트팀원과 소통해야 했다.
API이름과 Column을 수정할 경우 프론트와 백엔드 모두 두번 작업해야 하는 비효율을 만들어냈고.
결과적으로 엄청난 비효율을 만들어 냈다.
특히 프로젝트의 마지막주에 시간에 쫓기다 보니 이름에 대해서 충분히 고민하지 못했고,
많은 리팩토링 소요가 발생했다.
8. 개선방안
- 부족했다고 생각하는 부분 조사해서 벨로그 글 작성하기
- 커밋 컨벤션
- 테스트 코드
- 타입스크립트
- 리팩토링하기
- Typescript
- 트랜젝션
- API이름, 변수 이름
- 커밋 번벤션
9. 프로젝트를 마무리하며
기획부터 배포까지의 모든 과정을 경험할 수 있다는 것은 정말 좋은 경험이었다.
초기 기획단계부터 ERD를 설계하고, 필요한 기능을 고민하면서,
기획의 중요성을 많이 느끼게 되었다.
프로젝트의 주제를 선정하고난 뒤에는 Business Model이 과연 매력적인지,
좋은 Business Model을 만들기가 얼마나 힘든지, 얼마나 중요한지 알게 되었다.
또한 배포의 도구로써 GCP를 사용하면서, VM이 얼마나 우리의 서버를 편리하게 구축할 수 있게 도와주는지 알게 되었다.
항상 켜놓을 수 있고, 높은 수준의 가용성을 보장하는 서비스가 확실한 이점을 제공한다는 것을 느꼈다.
ERD 작성과 수정을 지속하면서 ERD의 중요성을 다시 한번 깨닫게 되었다.
ERD를 작성하고, 이에 따라 엔티티가 모두 작성되고, 관계가 만들어진다.
잘못 만들어진 ERD는 결국 프로젝트를 제자리 걸음 하게 만들며, 효율성을 저하시킨다.
나는 프로젝트라는 경험을 통해서 배운것도 많지만,
가장 중요한 것은 내가 어떤 것을 보완해야 하는지를 알게 되었다는게 가장 큰 소득이라고 생각한다.
사실 좋았던것 보다는 아쉬운점이 훨씬 많았던 프로젝트였기 때문에,
내가 느꼈던 아쉬움을 피드백하고, 기록하고, 이를 새로운 경험으로 만들어 더 발전해 나가고 싶다.
