[Wescanner]2차 프로젝트 회고록

🌱 클론 사이트

Skyscanner

🌱 클론 목적

• 기존의 Skyscanner 사이트를 모티브로 Django를 학습
• RDS, EC2, s3 등 AWS에 대해서 심도있게 학습

---

📍 개발 기간 : 2022년 7월 04일 ~ 2022년 7월 15일(총 11일간)

📍 개발 인원

• 프론트 엔드 : 우혜림, 신지훈, 김보미

• 백 엔드 : 정지민

📍 기술 스택

Backend

• Python
• Django
• Mysql
• Json Web Token
• S3
• AWS
• Boto3

Communication

• Slack
  IP주소 및 실시간 블로커에 대하여 즉각적인 소통

• Notion : 프론트/백 간의 request, response 전달 데이터 건의 및 공유

  • 회의록
    Daily Standup Meeting
    매일 평일 오전 스탠드업 미팅 진행
    👉 다른 팀에 비해 프론트 비율이 적었던 터라 초반에 너무 많은 기능을 구현목표로 잡은 건 아닌지 매일매일의 서로 진도를 확인하며 구현 가능한 정도를 파악

  • 구현 기록
    👉 백엔드에서 기능이 완성되자마자 JsonResponse 데이터를 공유

• Git & Github
  Wescanner 프론트엔드 깃허브
  Wescanner 백엔드 깃허브

📍 ERD 모델링

추가 구현기능 중 리뷰 업로드는 구현했지만 위시 리스트는 구현하지 못함

📍 API Documentation - POSTMAN

---

Behind

🌱 2차 프로젝트 마저 1인 백엔드..

1차 프로젝트를 이어서 2차 프로젝트도 홀로 하게 되었다.
사실 conflict부분이나 merge되는 부분에 있어서 두명이상의 백엔드 개발자가 하나의 프로젝트를 만들 경우 발생되는 상황을 겪어보고 싶었는 데 그 부분이 많이 아쉬웠다.

🌱 프로젝트 시작하기 앞서서..

1차 프로젝트에서는 Aesop을 모티브로 한 간단한 커머스 사이트를 구현했었는 데 2차 프로젝트에서는 내가 선택했던 Skyscanner를 하게 되었다. 본 사이트에는 AWS 배포와 카카오 소셜로그인, s3 이미지 업로드 기능 등 1차 프로젝트에서 구현해보지 않았던 다른 기능들이 많이 있었기 때문에 팀에게 부족하지 않은 백엔드가 되려고 AWS이용하여 1차 프로젝트를 미리 배포해보며 연습하고 카카오 API문서를 익히는 등 최대한 많은 지식을 알고 시작하기 위해 노력했다.

🌱 Wescanner을 진행하면서

아무래도 1차 프로젝트를 진행하면서 프론트와 백 간의 소통을 어떻게 진행해야 효율적일지 서로 알고 있었기 때문에 훨씬 애자일하게 진행할 수 있었지만 2차 프로젝트를 진행하면서 여러 이슈들이 발생했다.

1. 팀원 한분의 어쩔 수 없는 부재
우리 팀 중 프론트 개발자 한분이 프로젝트 진행 일주일정도 됬을 때 갑작스럽게 자가격리를 해야했다. 몸이 많이 안좋았기 때문에 최대한 쉬도록 배려를 해주었고 다른 프론트 팀원 두분이서 힘 써주셨지만 자가격리 중인 팀원분의 대한 현재 구현 상황에 대해 실시간으로 소통하는 것이 어려웠기 때문에 프론트 팀원분들이 불안해하고 본인의 업무외에 다른 기능까지 구현해야될 수도 있을 꺼라는 생각에 다들 조급해진 상황이 있었다. 프론트에서 기능을 구현해줘야 백엔드의 기능을 시각화 할 수 있기 때문에 이 상황을 해결하고 싶었던 나는 애초에 우리는 공부를 위한 프로젝트를 하고 있는 거고 조금이라도 성장하는 게 목표이니 완성도에 신경쓰지말고 페이지 매끄럽게 이어지지 않더라도 각자 맡은 부분에 대해서 최선을 다해보자고 격려해주었고 자가격리중 인 팀원을 위해 최대한 빨리 AWS배포를 해서 멀리서 통신해볼 수 있도록 우선순위를 변경하였다.

2. 뒤늦게 바뀐 엔드포인트
호텔 리스트 페이지에서 quary parameter를 이용하여 조건을 필터링 하는데 프론트와 회의를 통해 결정했던 건 프론트 측에서 요청한 hotels/city_id=1&rating=3&rating=5 이런 식으로 동일 조건 합집합에 경우 옆으로 쌓는 방법으로 하기로 했었다. 그러나 멘토님과 코드 리뷰 후 hotels/city_id=1&rating=[3,5] 이렇게 배열에 넣는 코드르 바뀌었고 프론트에서는 이미 옆으로 나열하는 코드로 구현을 완료하였기때문에 프론트 단에서는 코드의 전반적인 부분을 다 수정해야되는 상황이었다. 리팩토링된 코드는 백엔드입장에서 코드의 가독성이 더 좋아졌지만 프론트와의 통신 관련해서는 매끄럽지 못한 코드였기 때문에 프론트와의 통신을 위해 리팩토링 전의 코드에 필수 구현기능을 추가하여 통신 가능하도록 구현하였다. 좋은 기회로 또 다른 프로젝트를 진행핸다면 리팩토링된 코드를 응용해보고싶다.

3. 발표 전날 카카오 소셜 로그인의 통신오류
우리 팀은 다른 팀에 비해 카카오 소셜 로그인 구현 및 프/백간의 통신을 빠르게 마친 상태였다. 하지만 역시나 프로젝트 마감 1일전 징크스인지.. 내일 발표를 위해 마지막으로 통신체크를 해보았는데 잘되던 코드가 계속 KEY_ERROR가 발생하는 것이다. 프론트,백 멘토님들이 2시간 가까이 전전긍긍하며 프론트, 백엔드 코드를 봐주셨지만 이상한 점을 찾지 못하다가 코드에 오타를 발견하였다..!그 순간 오타때문이면 오히려 다행이라는 생각에 제발 오타이길 바라며 재통신을 했는데 성공적으로 로그인이 되었다..더 큰 문제이지 않을까 걱정이 많았지만 오타로 인한 오류라서 마음편히 발표준비를 마칠 수 있었다.

🌱 Wescanner 이라서 좋았다

아무래도 다른 팀에 비해 적은 프론트엔드 인원과 백엔드 한명으로 진행되는 프로젝트라서 걱정이 많았는데 거기에 프론트 엔드 한분께서 피치못할 사정으로 프로젝트 시작 일주일도 안되서 자가격리를 하게 되시고 격리 해제일이 프로젝트 발표날이었기 때문에 기능 구현과 소통 관련해서 팀 모두 걱정이 많았. 하지만 이러한 이슈들이 있었음에도 불구하고 이렇게 까지 성과율을 낼 수 있었던 건 Wescanner 팀원분들이 무너지지않고 각자 할일을 끝까지 끌고 갔기 때문이라고 생각한다. 물론 팀원 모두 1차에 비해 어려운 기능들이라 초반부터 어수선했고 더불어 자가격리까지 발생하여 다들 불안해 했지만 금방 떨쳐내고 맡은 일을 열심히 해준 프론트엔드 팀원들 덕분에 무사히 마칠 수 있었던 것 같다.

🌱2차 프로젝트 전 가졌던 마음가짐 확인하기

• logger로 SQL확인해가며 DB 성능 고려하여 ORM 사용해보기!
  -> settings.py에 logger기능을 추가하여 데이터 요청이 올때마다 DB성능을 확인해보았다.

• Q객체를 이용하여 좀 더 다양한 조건 사용해보기!
  -> 가격 및 호텔 성급 등과 같은 선택 조건과 저가순, 고가순에 대한 정렬 조건까지 구현해보았다.

• 지도API 사용하여 기능 구현해보기!
  (지도가 필요한 프로젝트에 당첨되야 할 수 있겠지만 아니더라도 추가기능으로 구현해보고싶다!)
  -> 프론트 단에서 구현하는 기능이었다!

• 소셜 로그인이 실제로 가능하도록 구현해보기!
  -> 카카오 API를 이용하여 프론트단에서 받은 Authorization 토큰을 이용하여 우리 API에서 사용할 토큰 부여

• Git,Github를 이렇게 열심히 함부로(?) 다뤄본게 처음이라 브랜치 이름도 엉망이고 기능 구현하기 급급해서 PR도 제대로 사용하지 사용하지 못했다. git과 친해지기 시작한 것도 1차 프로젝트 거의 마무리되어갈 쯤이었기 때문에 2차때는 보기좋고 깔끔하게 사용하기 위해 노력할 것!!
  -> 확실히 1차 프로젝트 보다 더 깔끔하게 git명령어를 사용하였고 1차 프로젝트에서는 git push 후 git merge 를 사용하여 브랜치 history가 지저분해지고 불필요한 commit도 많았었지만 이번 프로젝트에서는 git rebase를 사용하여 commit log가 깔끔하였고 같은 작업을 진행한 commit끼리 모을 수 있어서 관리하기가 용이하였따.

🌱 나는 어떤 개발자가 되어야 할까

나는 1차 프로젝트 후 소통 천재 개발자가 되고 싶다고 말했다. Wesop 팀이 성공적으로 마무리될 수 있었던 이유는 팀원 모두가 서로를 배려할 줄 알고 프/백 간의 언어 장벽을 인지하고 쉽게 전달하기 위해 노력했기 때문에 생각하기 때문이다. 지금도 그러한 생각을 하고 있다. 하지만 지금은 위 생각에 덧붙여서 이슈에 흔들리지 않는 개발자도 되고 싶다. 이번 프로젝트를 통해 예상치 못한 이슈의 발생은 팀 자체의 분위기를 흐리고, 개인의 역량마저 침해할 수 있다는 것을 느꼈다.
1차 프로젝트를 성공적으로 구현한 경험이 있었지만, 2차 프로젝트는 또 다른 느낌이었다. 특히, 겪어보지 못한 이슈에 맞닥뜨렸을 때 그리고 해당 이슈를 해결할 시간이 부족하였을 때는 팀원 모두가 힘들어했다. 그때 나는 팀원들의 불안한 감정들을 씻어내기 위해 노력하였는데, '하나의 기능이라도 자신의 것으로 만들자' 라는 말 한마디였다. 물론 프로젝트 기간동안 많은 기능을 구현하는 것은 중요하다. 하지만 이를 통해 성장하는 것이 더 중요하다고 생각했다. 프로젝트의 기능 구현에만 포커스를 두어 개발자 본인이 이해하지 못하는 코드들을 써 내려가는 것 보단, 하나의 기능이라도 누군가에게 설명할 수 있는 것을 목표로 두고 싶었다. 작은 한 마디였지만 팀원들을 금방 긍정적으로 생각할 수 있게 도와주웠고 그 결과 이러한 멋진 페이지를 구현해낼 수 있었던 것 같다.