1차 프로젝트 회고록

1. 프로젝트를 시작하기 전에

1차 프로젝트를 진행하기에 앞서, 미니프로젝트를 통해 구현해본 기능은
1. 로그인과 회원가입, bcrypt암호화와 jwt
2. 유저별 포스팅과 포스팅에 대한 코멘트, POST, GET
정도 였다. 미니프로젝트가 끝나고 설 연휴가 있었으나, 그 기간은 스스로 코딩한 것이 거의 없이 복습 정도만 진행하였다. 비록 동기들 중 실력적으로 크게 뛰어나지는 않았지만, 나는 개인적으로 위코드 부트캠프를 시작할 때 기준으로는 밑에서 3~5번째에 있었지만 미니 프로젝트가 끝날 즈음에는 중간 정도 수준으로는 올라왔다고 생각했기에, 프로젝트 진행하면서 팀에 방해가 되지는 않을 자신은 있었던 것 같다. 그 이상으로, 팀을 진두지휘하지는 못해도, 기능구현으로 기여하고, 팀원이 어려워하는 부분 있으면 같이 고민하여 문제 해결에 기여한다는 마음으로 있었다. 그리고 1차 프로젝트 웹 사이트는 영양제를 추천하고 구매할 수 있는 care of로 정해졌다.

2. 1차 planning meeting

기능은 다음과 같이 정리할 수 있었다.

1. 상품리스트, 상품 상세. GET
2. 상품리스트와 상품 상세 페이지에서 장바구니 추가. POST
3. 퀴즈를 통한 상품 추천, 장바구니 추가. POST
4. 장바구니에서의 상품 수정과 삭제. PATCH, DELETE

사이트 가입이 제한되어 확인할 수 있었던 기능은 위와 같지만, 회원가입과 로그인, 로그인 데코레이터, 결제, 리뷰, 마이페이지를 추가로 구현하기로 팀과 합의하였다. 그래서 팀의 1주차 목표는 회원가입, 로그인, 상품리스트, 상품상세까지는 필수 구현하기로 하였고, 장바구니를 추가구현사항으로 하였다. 매일 프론트엔드, 백앤드간 전일 작업 진행상황과 당일 작업 예정사항을 맞춰보고, 프론트엔드와 백엔드 상호간에 공유해야 할 내용들을 정리한 뒤, 30분 ~ 1시간 가량의 미팅을 진행했다. 작업 진행 상황 관리는 TRELLO를, 작업은 github에 연동하였고, 프론트엔드와 백엔드간 통신시 맞춰보아야 하는 키값등은 Notion을 이용하여 꼭 대면하지 않아도 확인할 수 있도록 하였다. 그렇게 프론트엔드와 백엔드가 1주일동안 구현해야 할 기능을 정리한 후, 백엔드는 백엔드간의 합의를 도출하였다.

1. 모델링 작업은 3일로 정한다.
2. 모델링 작업을 하는 동안 프론트엔드가 먼저 페이지의 mock data를 만들기 때문에, 백엔드가 데이터의 형식과 키값등을 프론트엔드에 맞추는 것을 원칙으로 한다.
3. 프론트엔드의 일이 상대적으로 백엔드보다 많은 것에 비해 사람수는 1명 적었기 때문에, 기능 구현이 딜레이가 되는 경우 프론트엔드의 일정상 가능한 수준에 맞추어 백엔드의 과업도 조정한다.

모델링에 들어가기 전에 합의한 사항은 위와 같다. 하지만 이후의 백엔드 합의사항 중 팀의 분위기와 성과에 결정적인 영향을 미친 합의사항이 하나 있었는데, 이는 모델링을 회고한 이후 작성하고자 한다.

3. 데이터베이스 모델링

데이터베이스 모델링 결과는 위와 같다. 영양제 하나가 가지고 있는 특성이 여럿 있었기 때문에, ManyToMany 관계로 연결된 테이블이 다른 팀에 비해 많았다고 들었다. 상품, 주문 관련 테이블의 색을 서로 다르게 하여 파악을 쉽게 하였다. 그리고 상품과 주문의 다대다 중간 테이블은 논의결과 장바구니의 역할을 한다는 것을 배울 수 있었다. 그리고 boolean이나 id값이 무언가를 의미하는 경우, 그것이 일대일 관계에 있더라도 데이터베이스 테이블을 따로 지정하여 이름을 지정해주어야 의미를 일일이 외우지 않고도 확인할 수 있기 때문에 반드시 필요하다는 것을 알 수 있었다. 팀원 중 데이터베이스에 대한 이해도가 높은 팀원이 있어, 다른 팀에 비해 수월하게 진행할 수 있었다.

코드 진행 방식에 대한 합의

데이터베이스 모델링이 마무리 된 후, 기능구현을 위한 본격적인 코딩을 어떻게 진행할 것인지에 대해 합의를 하였다. 다른 팀들처럼, 그리고 일반적인 경우처럼 기능별로 분할한 뒤 개인별로 할당하여 각자 코딩을 하자는 의견이 우선 나왔고, 나 또한 그것에 동의했다. 하지만

1. 팀의 작업 진행 상황이 다른 팀보다 빠른 편이기에, 급하게 속도를 낼 필요가 없다.
2. 팀의 백엔드 인적자원이 여유가 있기 때문에, 속도를 조절해가면서 다 같이 발 맞추어갈 여유가 충분히 있다.
3. 작업 진행이 지나치게 느려지면 그 때 가서 방법을 바꾸거나, 기능구현목표를 줄이면 된다.

위의 근거를 토대로, 2명씩 짝을 이루어 기능을 구현하는 방식으로 진행하는 것이 어떻냐는 제안이 있었다. 나는 누구랑 짝이 되든 1인분을 할 자신은 있었고, 그런 방식으로 짝을 구성하면 실력 편차가 있더라도 배우는 점이 분명히 있기 때문에, 그 제안이 더 좋겠다고 의견을 바꾸었다. 그래서 짝을 이루어 진행하되, 모두가 어려워하는 부분은 다 같이 고민해보기로 합의하였고, 이것이 우리 팀의 분위기와 결과물을 좋게 만들어준 가장 큰 이유라고 생각한다.

4. 2차 planning meeting

1주차를 진행한 결과, 팀은 1주차의 목표였던 로그인, 회원가입, 로그인 데코레이터, 상품리스트 페이지, 상품 상세 페이지 기능을 통신까지 완료했고, 장바구니 또한 세부적인 조정이 필요하긴 했지만 구현하는 것에 성공하여, 중간 발표때 코드를 공개할 수 있었다. 그리고 중간 발표 전에는 서로 다른 짝이 구현한 코드를 설명받는 시간을 가져, 팀 전체가 어떻게 코드를 짰고 로직이 어떤지 이해하는 시간도 가졌다. 오전에 있었던 미팅에서는 남은 기간 동안 퀴즈, 리뷰, 마이페이지, 결제를 마저 구현하기로 하였지만, 멘토로부터 '남은 3가지 기능은 백엔드 입장에서도, 프론트입장에서도 크게 도전적인 과업이 없다. 그것보다는 남은 기간 작성한 코드를 수정하는 것이 더 낫다.' 라는 피드백을 받고, 새로 구현하는 기능으로는 퀴즈만을 목표로 하고, 코드를 수정하고 리뷰를 받는 것으로 주간 목표를 수정하였다.

잘한 점과 잘 못한 점. 그리고 2차 프로젝트에의 각오

잘한 점으로는 하루도 빠짐없이 팀에 최소한의 기여를 했다고 느낀 부분이다. 때로는 기능구현을 위한 로직을 내가 짜낸 일도 있었고, 때로는 오류 처리에 도움을 준 일도 있었다. 이런 기여를 바탕으로 잘못하면 겉돌수 있었던 자신이 최종적으로 무리 없이 팀에 녹아들 수 있었다. 또한, 팀 분위기를 유지하기 위해 노력했던 점도 잘한 점으로 꼽아보고 싶다.
잘 못한 점으로는 개인적으로 구현한 로직을 충분히 검증하고 팀에 공개했어야 했는데, 그렇지 못하여 팀 전체가 같이 고민하도록 만든 일이 몇번 있었다. 이는 변명에 여지가 없이 내가 꼼꼼하지 못했기 때문에 벌어진 일로, 팀원 분들이 너그럽게 받아주셔서 정말 다행이고 행운이라 생각한다.
1차 프로젝트가 내부적인 평가로도, 외부의 평가로도 상당히 좋게 끝나서 기분은 좋지만, 팀이 바뀌어 진행하는 2차에서도 잘 해나갈 수 있을지는 걱정이 앞서긴 한다. 그래도, 위코드에서 개발을 처음 배울때 가장 못하는 축에서 현재 충분히 1인분 몫을 하는 사람으로 성장하였듯, 2차에서도 노력하여 1인분 몫을 하는 것은 물론, 팀 분위기를 조정하고 주도해나갈 수 있는 사람이 되어야겠다고 느낀다.