짧았던 프리 프로젝트 기간이 어제부로 끝났다. 우리는 인원 부족으로 프론트엔드 팀원 한 분이 들어오면서 프리 프로젝트가 끝났다.

팀원이 늘어나면서 팀번호가 바껴버려서 팀 번호 럭키 7을 잃었다...🥲

메인 프로젝트 첫날은 OT형식으로 진행되었고 프리 프로젝트에 대한 회고 시간을 가졌다.

 

 

⚡️ 프리 프로젝트 진행하면서 좋았던 부분?

 

프리 프로젝트 진행하면서 좋았던 것, 배웠던 것 참 많았다.

그 중에 가장 좋았던 건 팀원들 이다. 난 운이 정말 좋게도 좋은 사람들만 만나서 팀 내에 커뮤니케이션 문제, 팀원간의 이슈는 없었고 서로에게서 많이 배우고 자극 받는 좋은 관계를 만들 수 있었다. 서로 대화할 때도 쿠션어를 사용하고 비난이나 불만을 표출하지 않고 잘 따라와주었다. 사실 내가 팀장으로 크게 한 일은 없었고 전체적인 일정 관리나 회의 진행하고 의견 하나로 모은 정도가 다였다.

다들 긍정적인 덕분에 매번 즐거웠고 같이 하면서 좋은 에너지를 많이 받을 수 있었다. ⚡️

프리 프로젝트를 하면서 특별한 일이 없으면 매일 2번의 회의를 했다.

우리가 짧은 시간과 적은 인원(3명)으로 사용자 요구사항 명세서(SRS)에 정의한 모든 기능을 모두 완성하진 못했지만 훈훈하게 우리의 작품을 뿌듯해하며 마무리를 하였다.

모두가 일단 가장 좋았다고 뽑은건 팀 분위기, 커뮤니케이션 부분이었다.

 

개인적인 좋았던 부분

  • 기술적으로 이슈들은 항상 바로바로 연락을 하고 깃허브 이슈 탭을 적극 활용한 점이 좋았습니다. 😄
  • 유용한 기능은 혼자 알지 않고 서로 공유해서 너무 좋았습니다.
  • 논의, 토론을 하면서 서로를 존중하고 기분 나쁘지 않게 대화하는 점이 좋았습니다.
  • 팀원분들 통해서 몰랐던 부분이나 헷갈렸던 부분들 많이 배울 수 있었습니다.
  • 열정 넘치고 긍정에너지 넘치는 팀원들을 통해 에너지를 많이 얻을 수 있었습니다.
  • 모두가 적극적으로 의견을 제시해서 팀 전체가 계속 더 좋은 방향으로 나아갈 수 있어서 좋았습니다.
  • 부족한 팀장을 잘 도와주셔서 부담을 많이 덜수 있었습니다. 다들 너무 고맙습니다. 😻

 

개발에 있어서 전체적으로 만족했던 부분

  • 문서 작성을 자세하게 했던 부분 (API 명세서, 화면정의서)
  • 설계 단계에서 다같이 상의한 점
  • 프론트엔드와 백엔드가 각자 코딩하고 모여서 합쳤을 때 동작한 것
  • 서버 단에서 각자 도메인 별로 나눠서 코딩하고 한번의 run 없이 합쳤는데 큰 문제 없이 합쳐진 것
  • 배포할 때 프론트엔드 백엔드 같이 에러를 확인하고 해결해나간 점
  • 배포에 AWS를 사용하면서 aws의 전체적인 흐름과 사용법을 익힐 수 있었던 부분

 

 

☄️ 팀 문화와 팀 룰

 

팀원들과 팀 문화와 팀 룰을 초반부터 정해서 지켜갔는데 이게 팀 분위기를 형성한 데 도움이 된 것 같다. 특히 오버커뮤니케이션을 지향했기 때문에 우리의 슬랙 채널은 항상 뜨거웠고 덕분에 서로 성장하는데 도움이 될 수 있었다.



팀문화 페이지

 

프로젝트 룰 페이지

 

그리고 프리 프로젝트를 마무리하면서 회고 날 전에 우리 팀에서는 이미 팀룰과 팀 문화에 있어서 KPT를 진행하였다. 모두들 팀 룰과 팀 문화에 만족하고 있었고 프리 기간동안 입증이 끝난 상태였다.

팀 룰에서 commit과 git branch 그리고 코딩할 때 코드의 통일성을 맞추기 위해서 coding convention까지 정했었는데 이게 큰 도움이 된 것 같다. 팀원들이 모두 프로그래밍 룰을 잘 지켜준 덕분에 git issue창과 branch가 깔끔하게 정리되었다. 추가로 깃에서 Pull Request의 템플릿을 만들어 기본으로 지정할 수 있는데 이게 PR 글들을 깔끔하게 정리해줬고 PR을 들어가면 자세하게 정리되어 있어서 커밋을 하나하나 찾아볼 필요가 없었다. 😄 깃 관리가 잘 된것 같아 아주 만족했다~

 

 

 

✨ 아쉬웠던 점과 개선할 부분

 

개인과 팀 전체로 나눠서 아쉬웠던 점과 개선할 부분도 같이 회고하였다.

 

개인적인 측면에서 아쉬웠던 부분

  • 시간적 자원과 인적 자원이 모자라서 계획한 것을 100프로 구현하지 못한 점
  • 다른 포지션과의 협업이 처음이라 개발 초반에 프론트엔드와 백엔드의 소통이 부족했던 것 같습니다.
  • 클라이언트와 서버 통신을 미리 테스트 하지 않고 개발이 어느정도 된 상태에서 하니까 급작스럽게 처음보는 문제들을 마주쳤습니다.
  • 시간이 부족하여 기술적인 구현 연습을 충분히 못했습니다..
  • 에러에 대해서 깃헙 이슈에만 남겨놓고 회고로 남겨놓진 못했습니다.
  • 깃헙 액션 사용 못해서 배포 자동화 테스트 못해본것

 

개인적인 측면에서 개선할 부분

  • 다른 포지션 팀원들과의 소통에 더 적극적으로 임할 필요가 있습니다.
  • 개발 초기 단계에 개발 서버에서 클라이언트와 서버 통신이 정상적으로 되는지 확인하면 좋을 것 같습니다!
  • 에러 일지 등 회고 작성하면서 할 필요가 있겠습니다!! 📝

 

팀원 모두가 아쉬웠던 부분

  • 처음 설계하는 거라 빠졌던 내용이 많아서 중간중간 수정이 잦았습니다.
  • API 명세서를 구글 스프레드 시트로만 작성하고 다른 좋은 툴을 활용하지 못했던 부분
  • (백엔드) 서버에 Spring Security를 적용하지 못한 점
  • (백엔드) 테스트를 구현해보지 못한 점
  • 배포 서버 테스트를 미리 하지 않은 부분 → 첫 배포에서 많은 오류를 겪었습니다..
  • 개발 서버와 배포 서버를 분리하지 않고 동일하게 사용한 부분

 

팀원 모두가 개선해야겠다고 생각한 부분

  • 메인 프로젝트 때는 API 명세서를 Swagger로 정리하자
  • (백엔드) 상속 및 확장 관계에 대해 한번 더 생각해보고 설계 및 개발하기(클래스 관계도 다이어그램 미리 그려보기!)
  • (백엔드) 처음부터 시큐리티를 적용하여 프로젝트 진행하기
  • 중간중간 build해서 체크가 필요합니다.
  • 장인 정신 좋지만 시간을 고려할 필요가 있습니다.
  • 배포 서버 테스트를 개발 초기 단계에 미리 해보면 좋겠습니다.
  • 시간적으로 가능하면 배포 서버와 개발 서버를 분리해 봅시다. → AWS 프리 티어 계정 2개로 분리
  • 회고... 기록을 너무 안남겼다... 에러를 잘 적어놓자..

 

 

 

모두가 즐거우면서도 유익한 회고 시간이었다.

팀원 모두가 메인 프로젝트 때는 프리 프로젝트 때보다 더 불태우려는 의지를 보였다! 🔥🔥🔥

우리는 프로젝트에 열정을 담아서 팀명을 24/7로 지었다. ㅋㅋㅋ (블랙기업이냐고 얘기가 나왔다..ㅋㅋㅋ)