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

팀원이 늘어나면서 팀번호가 바껴버려서 팀 번호 럭키 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로 지었다. ㅋㅋㅋ (블랙기업이냐고 얘기가 나왔다..ㅋㅋㅋ)

😜 프로젝트를 위한 Github 사용법 학습

오늘은 팀 프로젝트에서 GitHub를 어떻게 활용할 수 있는지 배웠고 사용법을 자세히 배웠다.

프로젝트 기간이지만 내일 낮까지는 프로젝트를 위한 학습이 진행된다.

Github를 개인 코드 저장소로만 이용해서 다른 사람과 같이 관리해본 적이 없어서 오늘 내용을 최대한 집중해서 익혔다.

🔎 칸반 보드?

오늘 배운것 중에 가장 생소한 단어였다.

영어 같진 않아서 찾아보니까 일본어이다. (看板, 칸반)

칸반 보드 생긴 걸 보니까 많이 봤던 거다.

할일과 진행 중인 프로세스, 그리고 끝난 프로세스를 한눈에 시각화 하는 가상 보드이다.

칸반 보드를 실무에서는 Jira(지라)같은 툴을 이용한다고 한다.

지금은 Github Project 탭이랑 노션을 잘 활용하면 충분할 것 같다.

🏃‍♂️ 운동은 꾸준히...

지금까지 나름 컨디션 관리를 잘 했다고 생각했다.

지금까지 밤에 적게 자고 학습이 가능했던건 전적으로 운동 덕분인 것 같다.

그런데 일주일 동안 프로젝트 전에 복습하겠다고 운동을 안했더니 몸이 많이 쳐졌다..

운동을 꾸준히 했을 때랑 쉬었을 때의 차이는 낮에 공부할 때 많이 느낀다. 🥱

체력이 떨어지면 오래 앉아서 작업하기가 힘들다.

계속 졸음이 쏟아지고 몸이 여기저기가 뻐근하다. 🫠

그래서 오늘부터 다시 저녁 운동을 시작했다.

이제 프로젝트 동안 최소 일주일에 3회 운동해서 체력을 보존해야 겠다.

🌱 주말동안 깃 프로필을 꾸며보았다.

저번 주말동안 그동안 미뤄왔던 Git 프로필 ReadMe.md 파일을 커스텀 해보았다.

인터넷에 검색해가면서 대충 했는데 나름 예쁘게 된 것 같다.

오늘 보니까 뱃지도 2개나 더 늘었다. pull shark랑 quickdraw 이다.

둘다 혼자 실습하다보니까 자동으로 생겼다. ㅋㅋㅋ

회고 카테고리를 만들고 처음으로 회고록을 작성한다.

프로젝트 들어가면서 아무래도 있었던 일이나 소프트 스킬 부분을 정리할 필요가 있겠다고 생각했다.

오늘은 드디어 학습을 마치고 Main-Project 전에 Pre-Project 를 시작했다.

첫날부터 코딩이나 설계같은 걸 하진 않았고 일단 오리엔테이션으로 하루가 지나갔다.

이제 팀으로 진행하기 때문에 커뮤니케이션에 대해서 하루종일 설명을 들었는데 오랜만에 쉬는 타임이라 편하고 즐거웠다.ㅋㅋㅋ

팀 매칭이 되서 드디어 2달의 대장정을 함께할 팀원이 발표되었다.

우리 팀은 나를 포함해서 총 5명인데 7팀이라서(행운의 7) 시작전부터 뭔가 느낌이 좋았다.

팀 매칭이 되고 팀원들과 첫 회의를 하는 시간을 가졌다.

다들 열정으로 가득하신 것 같아서 다행이었다.

지금은 프로젝트에 대한 걱정보단 기대가 많이 큰것 같다.

앞으로의 여정이 기대된다.

팀의 팀장을 맡게 되었다. 🥸

먼저는 팀장의 역할을 정하고 팀장을 정했다.

어쩌다보니 내가 팀장이 되었다.

일단 맡게 되었으니 운명이라 생각하고 최선을 다해서 최고의 결과물을 내야겠다,,,!

우리는 팀장의 역할을 이렇게 정했다.

• 회의 주제를 미리 선정 및 준비 : 회의 10분 전에 미리 화상채팅방 준비하기
• 커뮤니케이션 조율 : 의견 충돌 시 중재

그리고 앞으로 연락할 커뮤니케이션 툴과 화상회의를 할 툴에 대해서 의논했다.

slack 이라는 디스코드와 비슷한 툴이 있는데 커뮤니케이션 툴은 그걸로 결정했다.

아무도 슬랙을 써본적이 없었지만 현업에선 많이 사용한다고 해서 경험해볼겸 일단 써보기로 했다. (써보고 불편하면 디코로 옮기기로 했다.ㅋㅋㅋ)

그리고 게더타운을 화상회의 툴로 결정했는데 이것도 아무도 사용해본 적이 없었다.

모두들 새로운 기술에 적극적이라 감사했다.

팀의 룰의 대략적 뼈대를 만들었다.

코드스테이츠에서 여러 자료를 제공해주기도 했고 팀원분이 좋은 자료를 준비해주셔서 룰을 만들때 여러 의견들이 나왔다. 일반 규칙과 개발 관련 규칙으로 나눠서 정했다.

일반 규칙은 회의 시간, 회의할 때 순서대로 발언하기, 상시연락 가능 시간(책상앞에 있는 시간)을 정했다.

개발 관련규칙엔 "혼자 알지 않기" 와 "혼자 모르지 않기"를 추가했다. 

지금까지는 혼자 생각하면 됐지만 처음으로 팀으로 움직이는 거라 사소한것 하나까지도 공유해야 하고 오버커뮤니케이션이 필요하다.

회의 시간은 오전과 오후로 나눠서 작업 전후로 회의를 가지기로 했다.

오전에는 전날 작업했던 내용의 대략적 정리와 오늘 할 내용을 간단하게 공유하기로 했고

오후엔 그날 한 작업에 대한 리뷰와 정리, 회고를 하기로 했다.

우리는 회고를 KPT(Keep, Problem, Try) 형식으로 진행하기로 결정했다.

화상회의가 끝난 후에 감사하게도 적극적으로 의견과 피드백이 오가서 난 팀운이 굉장히 좋다고 생각했다. 사실 개인적으로 코딩 스킬보다 커뮤니케이션 스킬이 좋은 팀원을 만나고 싶었는데 참 다행이고 감사하다.

앞으로의 프로젝트 대장정을 위해 프로젝트 들어가기 전까지 준비를 많이 해야겠다.