한달간의 프로젝트가 끝났다.
프리프로젝트를 제외하면 처음하는 제대로된 개발이었고, 그래서 더 긴장되고 두려움이 앞섰던 것 같다.
디스코드에서 아침마다 모여 회의를 진행했고, git과 notion을 이용하여 정보를 공유했다.

준비

• 나는 팀장으로 프로젝트에 참여하게되었고, 우리팀은 신뢰성있는 여행정보를 얻을 수 있는 커뮤니티를 만들고자 했다.

• 하루정도 프로젝트의 주제를 선정하고 다같이 모여서 사용자요구사항 정의서를 작성하였고,
  프론트, 백엔드로 팀을 나누어 각자 할일들을 정하여 진행하도록 하였다.

• 프론트에서는 화면정의서를, 백엔드에서는 테이블 명세서와 ERD를 작성하였다.

• 그리고 다같이 모여 API 명세서 까지 작성을 한 뒤에야 본격적인 개발을 시작할 수 있었다.

• 경험해보니 실제 개발기간은 길지 않았다, 다만 사전에 해야할 것들(사용자요구사항 정의서, API명세서, 화면정의서, 테이블명세서, ERD등)을 정하는데에만 3일정도가 소요됐던 것 같다.

프로젝트

• 우리 프로젝트는 신뢰를 기반으로 하는 여행 커뮤니티이다.

• 그래서 위치기반인증을 사용하기로 했다.

• 또한, 각자 지역에 대한 홍보도 할 수 있게 하기 위해서 블로그를 운영할 수 있게 만들기로했다.

• 여러지역을 나눠서 게시판을 관리하도록 했으며, 해당 지역 게시판에 여행지에 대한 질문을 남기면 위치인증을 받은 현지인만 답글을 달 수 있게 하였다.

• 답글에는 채택기능도 포함되어있는데, 채택이 되면, 답글에 대한 댓글도 달 수 있게 된다.

• 또한, 위치인증을 받은 사람만 글을 쓰고, 블로그를 작성할 수 있도록 권한 설정을 하기로 했다.

keep

• 개인적으로 보안쪽을 담당하게 되었는데, 해당 멤버가 정보를 수정할때나 조회할 때 URl path에 데이터 식별자가 노출되게 된다. 그렇게 되면 회원의 정보도 노출될 수 있기때문에 로그인한 상태에서 토큰을 받아 그 토큰에서 개인정보를 추출하여 사용하기로 했다.

결과적으로 데이터 식별자 노출 없이 로그인만하면 토큰에서 개인정보를 얻어올 수 있기때문에 모든 URl path를 "me"로 통일할수 있게 된었다. (관련블로깅)

• 프로젝트를 시작하기전에 프로젝트 개발관련 규칙을 정하고 시작했다. 어느 프로젝트를 진행하던지 필요한 부분인 것 같다.

• merge하기 전에 pr하고 말해주기
• dev에는 무조건 pr로 merge하기
• branch 지우지 말고 유지
• 코드에 사소한 거라도 주석달아 설명해주기
• 브랜치 전략 : main -> dev -> FE/BE ->기능별, 개인

• Github Action을 이용하여 무중단 배포를 적용했는데, 따로 배포하지 않아도 변경사항만으로 새로 배포되니 효율적으로 일할 수 있었다.

• Github Action에서 두가지 빌드를 이용하여 프론트와 백엔드를 동시에 배포할 수 있었는데 새로알게된 것을 적용할 수 있어서 좋았다. (관련블로깅)

Problem

코드컨벤션

• 코드컨벤션도 통일하고 진행했는데, 우리는 잘 지켜지지 않았던 것 같다. 아무래도 익숙하지 않아서 커밋하는 것에만 집중했던 것 같다.

연락

• 온라인상으로 진행하다 보니 연락이 힘든 경우가 많았다.

칸반보드

• 깃에있는 칸반보드를 이용했는데, 협업의 경우 어느 사람이 어떤 단계에 진행중인지를 알 수 있어서 수월한 기능이었는데, 이것 또한 까먹거나 잘 지켜지지 않았다.

이탈자

• 막바지에 가서 2명의 이탈자가 생기게되었는데, 문제는 이 두명이 평소에 연락이 잘 안됐었다. 그래서 맡은 부분을 잘하고있는지 조차 알수 가 없었는데, 알고보니 거의 진행을 하지 못한 상태였다.

• 우리팀의 경우 인원배정이 많았던 팀이라 여러가지기능을 구현하고자 했는데, 갑자기 2명의이탈자가 생겨서 프론트단에서 구현에 문제가 생겼다.

• 결국 프로젝트를 제기간 안에 완성을 하지 못했는데, 팀원들과 협의 끝에 기간 이후에도 계속 진행하기로 하였다.

느낀점

팀장으로써 부족함을 많이 느끼게된 프로젝트였다.

• 언제까지 봐주고 유하게만 대할 수 없다는 것을 느꼈고, 진짜 이럴줄은 몰랐는데 생각보다 책임감의 문제가 심각하다는 것들을 느꼈다.
• 중간에 멘토님을 통해 연락이 안되는 인원에 대해서 아예 빼고하자는 의견을 주셨는데, 적극적으로 수용하지 못한 것이 후회되는 점이다.
• 우리가 정했던 칸반보드를 성실하게 잘 지켰다면 이런일은 없었을 것 같다. 나조차도 칸반보드를 제대로 하지못했고, 팀원들의 진행상황을 적극적으로 파악하지 못한 내 실수가 가장 컸던 것 같다.

CI/CD에 대한 이해

• 무중단 배포를 처음부터 끝까지 진행해봄으로 써 cors에러에 대한 이해도 높아졌고, 배포에 대한 전반적인 이해도를 높일 수 있었다.

개발 flow에 대한 이해

• 내가 담당한 부분이 멤버쪽과 보안, 그리고 배포라 그런지 전반적으로 개발 flow에 대한 이해도를 높일 수 있었다.

소통의 중요성

• 예를들어 API명세서의 경우 확실하게 정하고 가야함을 느꼈다. 첨음 정할 때 우리프로젝트의 구조에 익숙하지 못하니 중간중간 API가 계속 바뀌게 되었고 불필요한 소통의 시간이 늘어나게 되었던 것 같다.
• 그 외에도 프론트에서 기능을 구현함에 있어서도 서로 가능한 것과 원하는 부분에 있어서 확실하게 주장할 수 있어야 후에 발생하는 이해의 충돌을 면할 수 있을것이다.