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

Wecode Bootcamp 2nd Project

이제는 개발을 하면서 협업을 하는 방법을 알았습니다.

이번 2차 프로젝트에서는 외부 라이브러리를 사용하고, 소셜로그인을 구현해보면서
좀 더 난이도가 있는 팀 프로젝트를 진행하였습니다.

아직은 Scrum 방식의 업무가 익숙지 않은 점도 있었습니다.

하지만 총 두차례에 걸친 프로젝트를 경험을 통해
어떻게 하면 더 쉽게 설명할 수 있을까?
어떤 부분을 공유해야 빠르고 효율적인 개발을 할 수 있을까? 에 대한 답을 얻은 것 같습니다.

이번에는 PM으로 참여하였던 2차 프로젝트의 회고를 시작해보겠습니다.

✅ 프로젝트 소개

---

프로젝트 개요

위코드 부트캠프의 두번째 팀 프로젝트입니다.

이번 프로젝트 기간은 2022-07-04 ~ 2022-07-15까지 총 2주의 기간을 가졌습니다.

Airbnb라는 숙소 호스팅 및 예약 사이트를 모티브로 하여 웹사이트에서 필요한 다양한 기능을 구현해보았습니다.

저작권 문제를 고려하여 프로젝트에 필요한 이미지는 pixabay의 이미지를 사용하였습니다.

프로젝트 목표

1. Python의 Django 프레임워크를 활용한 백엔드 서버 구축하기.

2. MySQL을 활용하여 데이터베이스를 구축하고, Django의 ORM 최적화 방식 이해 및 적용하기.

3. 다양한 협업 툴을 사용하여 커뮤니케이션 역량 강화 및 발휘하기.

4. Scrum 방식 업무를 토대로 서비스를 배포하기 위한 빠른 개발 업무 해보기.

역할 분담

Front-end 개발자 4명, Back-end 개발자 1명으로 프로젝트를 진행하였습니다.

[김상웅][sangwoong03](https://github.com/sangwoong03)

• PM
  1) 전세계를 대상으로 서비스 중인 airbnb는 전세계 고객을 대상으로 합니다.
  기간과 동료들의 개발 능력을 고려하여 프로젝트에서는 지역을 제주도로 한정하였습니다.
  2) 2주간 구현할 수 있는 필수 구현 사항과 추가 구현 사항을 구분하여 프로젝트 미팅을 진행하였습니다.
  3) Stand-up meeting 간 Trello를 활용하여 Sprint 목표 진행 정도를 파악하고 업무를 재분담하였습니다.

• dbdiagram을 활용한 모델링

• Django 프로젝트 초기 설정

• 카카오 소셜 로그인 API 구현

• 숙소 전체/상세페이지 API 구현

• 후기 등록 및 조회 API 구현

• 예약 등록 및 조회 API 구현

• AWS (EC2, RDS) API 서버 배포

✅ 협업 Tool

---

📌 Git / Github

협업 툴 중 버전을 관리하기 위해 Git과 Github을 사용하였습니다.

이번 레포지토리는 혼자 사용하지만 git rebase 명령어를 사용하고 쓰임의 목적에 대해 이해할 수 있었습니다.

Github 레포지토리는 다음과 같습니다:

Front-end 레포지토리 바로가기

Back-end 레포지토리 바로가기

Trello

1, 2주차의 Sprint 목표와 업무 진행을 파악하기 위한 Tool로 Trello를 사용했습니다.

backlog 프로젝트 미팅을 하며 전체 업무를 기능별로 세분화하여 전체 티켓을 발행했습니다.

Sprint Goal 일주일을 기준으로 진행해야 할 업무 티켓을 가리킵니다.

In progress 현재 개발 중인 업무 티켓을 가리킵니다.

In review Github에 PR을 올리고 리뷰와 merge 대기를 하는 작업을 가리킵니다.

Done merge가 완료되고 정상적으로 작동하는 기능을 가리킵니다.

Blocker 개발의 속도가 더디거나, 해결해야하는 문제들을 가리킵니다.

📌 Notion

업무 간 반복되는 소통을 줄이고 정보를 공유하기 위해 Notion을 사용했습니다.

매일 진행되는 미팅의 내용을 기록하고 통신에 필요한 데이터 정보를 공유하기 위해 사용했습니다.

📌 Postman

Postman API Document

혼자 백엔드 개발을 하면서 소통과 개발과 로컬 서버 가동을 동시에 해야하는 경우가 있었습니다.

이런 경우 개발 속도가 지체되거나 소통에 집중을 할 수 없는 상태가 되어, 필요한 API 정보를 postman을 활용하여 문서로 소통하였습니다.

필요한 부분에 대해서만 회의를 하거나, 의사소통을 나눌 수 있어 효율적인 개발을 할 수 있었습니다.

✅ 기술 스택

---

이번 프로젝트에서 사용한 기술 스택은 다음과 같습니다.

Language	Framwork	Database	ENV	HTTP	Deploy

✅ 구현 기능

---

이번 프로젝트에서 구현한 필수 구현 사항은 엔드포인트로 나누어 보았을 때,
크게 4가지로 볼 수 있습니다.

1. 카카오 - 소셜 로그인 API

• 카카오 API를 통해 소셜로그인을 구현했습니다. (Kakao Developers 문서 참조)

• 클라이언트(FE)로부터 카카오 로그인 인가 코드를 받아옵니다.

• 받아온 인가코드를 통해 카카오 서버에 카카오 토큰을 요청합니다. requests.get

• 받아온 카카오 토큰을 통해 다시 한번 카카오 서버에 유저 정보를 요청합니다. requests.get

• 받아온 유저 정보에 접근하여 필요한 데이터를 DB상에 저장합니다.

• 로그인을 성공적으로 수행했을 경우 서버에서 발행한 토큰을 클라이언트에게 발급합니다.

2-1. 숙소 전체리스트 API

• 메인페이지 url로 접근 시 숙소의 전체 리스트를 제공합니다.

• 지역, 예약 날짜, 인원수에 따라 숙소를 필터링합니다. (Query Parameter)

• 유형, 카테고리, 가격범위를 통해 숙소를 필터링합니다. (Query Parameter)

(ORM 최적화를 통해 필터링과 필요한 정보를 효율적으로 제공하기 위한 노력..)

2-2. 숙소 상세페이지 API

• 메인페이지에서 특정 숙소의 정보를 요청하고 해당 정보를 제공합니다. (Path parameter)

• 상세 정보에는 숙소의 정보, 리뷰, 호스트, 예약 내역을 함께 제공합니다.

3. 후기 API

• 로그인을 한 유저에 한하여 숙소의 후기를 작성할 수 있습니다.

• 숙소의 상세페이지로 접근하면 숙소의 전체 리뷰, 개수, 평점을 확인할 수 있습니다.

++ 보완사항

• 숙소를 실제로 이용한 유저에 한하여 후기를 작성할 수 있도록 수정이 필요합니다.

4. 예약 API

• 로그인을 한 유저에 한하여 숙소를 예약할 수 있습니다.

• 예약 정보는 체크인/체크아웃 날짜, 인원 수, 가격, 숙소의 정보를 필요로합니다.

++ 보완사항

• 현재는 로그인을 한 유저에게 포인트를 제공하여 숙소의 가격만큼 차감하는 방식으로 결제를 진행합니다.

• 마찬가지로 소셜 결제 API를 사용하여 보완할 수 있겠습니다.

✅ 후기

---

📍 긍정적인 부분

1. 팀 PM으로서 초기 프로젝트 방향을 잘 잡은 것 같습니다.

전세계를 대상으로 서비스하는 에어비앤비를 제주도로 축소하였습니다.

개발을 진행하면서 공부해야하는 사항들은 부족함이 없었던 것 같습니다.

2. 1차 프로젝트에서 못했던, 웹의 전체 구조를 분석하고 데이터 모델링을 진행하였습니다.

필수 구현 사항에만 집중하게 되면 확장 개발을 해야할 경우에 문제점이 있었습니다.

이번에는 기존 웹 전체 구조를 분석하고 모델링하면서 확장성으로 발생하는 문제점이 없었습니다.

3. 카카오 API를 통해 소셜 로그인을 구현해보는 것이 재밌었습니다.

백엔드 서버를 개발하면서 요청을 받는 행위 위주로 코드를 작성하였으나,
카카오 서버와의 통신 간 외부 API에 요청을 하여 통신하는 것이 새롭고 재밌었습니다.

4. Postman을 통한 API document를 작성하여 팀원들과 공유하였습니다.

1차 프로젝트를 진행할 때에는 개발을 하기에도 급급하여 제대로 된 API 문서를 공유하지 못했습니다.

이번에는 Postman을 통해 API 문서에 다음 내용을 포함하여 작성하였습니다:
요청 시 필요한 IP주소 포트번호 endpoint key parameters

작성 시 단순 공유를 목적으로 작성하지 않았습니다.

실제 내 API가 배포되었을 때 사용하는 사람이 있다면, 읽기 쉽고 사용하기 쉽도록 작성하는 것에 중점을 두었습니다. (계속 수정을 해야할 것 같습니다.)

5. 프로젝트 기간 내 AWS를 통한 배포와 S3를 활용한 개발을 진행했습니다.

AWS의 RDS와 EC2를 사용하여 데이터베이스를 구성하고 가상 서버를 통해 API서버를 배포까지 완료했습니다.

S3를 통해 이미지를 업로드하는 기능은 현재 구현 중에 있으며, 수정 사항이 완료되면 Github 레포지토리에 반영될 예정입니다.

📍 배운 점

1. 팀의 방향을 잡아야되는 PM의 역할을 이해하고, 미팅을 어떻게 진행해야하는지 경험할 수 있었습니다.

Trello라는 툴을 활용하여 티켓을 세세하게 나누는 것도 중요하지만,
Blocker가 무엇인지, 개발 속도가 더딘 이유가 무엇인지 확인하는 것도 중요한 요소인 것을 배웠습니다.

또한 팀원 중 하나로서, 내가 겪고 있는 "blocker와 문제가 무엇이고, 개발 속도가 더뎌질 것이다."라는 말도 커뮤니케이션 중 일부이며 필요한 소통 능력이라고 느끼게 되었습니다.

2. Django 프레임워크를 사용하면서 ORM 최적화에 대해 배울 수 있었습니다.

views.py에 엔드포인트 로직을 작성하면서, 데이터베이스와 통신하는 ORM 코드를 어떻게 하면 효율적으로 작성할 수 있을까에 대한 고민을 할 수 있었습니다.

select_related()와 prefetch_related(), annotate() 메서드 등을 활용하여 기존 DB와 수차례 통신하던 코드를 1회 혹은 그 횟수를 줄일 수 있었습니다.

3. 테스트코드의 필요성과 작성

이번 프로젝트를 하면서 테스트 코드를 같이 작성하였습니다.

기존에는 Integration test 방식 중 하나인 postman을 활용한 테스트를 진행하였습니다.

Unit Test 코드를 작성하고 실행해보면서 views.py에 문제가 있는지 확인할 수 있었습니다.

또 내 코드를 통해 어떤 결과가 도출될지 예상할 수 있었습니다.

확신을 갖고 개발을 할 수 있게 도와준 Test code에 고마움을 표합니다...

Test 코드를 먼저 작성하고 엔드포인트의 로직을 처리하는 코드를 작성하는 문화도 있다고 하는 만큼 테스트 코드를 많이 작성해보고 연습해보고 싶습니다.

📍 아쉬운 점

1. 인프라에 대한 이해

AWS를 활용하여 배포를 진행하였지만, AWS의 다른 서비스와 구조를 완벽히 이해하지 못했습니다.

부트캠프 기간 중 Docker에 대한 세션도 있었으나, 프로젝트를 진행하면서 Docker 단계에 접근조차 하지 못했습니다.

이후에도 1, 2차 프로젝트의 추가 구현사항을 보완해가면서 Docker를 활용할 수 있도록 계속 발전시키고 싶습니다.

++ Infra와 Network에 대한 공부를 해보자

2. 리팩토링 시간 부족

• 카카오 소셜 로그인 코드는 분명 다른 모듈이나 앱에서도 필요한 코드일 수 있습니다.

따로 모듈로 분리하여 관리하고 필요할 때 그 모듈을 불러와 사용하는 것이 더 효율적일 것입니다.

• 요청에 대한 응답 중 상태코드를 다시 고려해볼 필요가 있을 것 같습니다.

이 부분은 1차 프로젝트에도 해당됩니다.

++ 리팩토링은 차후 일정에 반드시 진행할 예정입니다.

3. 회의 기록 페이지를 통일 시켜보자

Notion 페이지를 활용하여 매일 진행하는 미팅 내용을 기록해두었습니다.

하지만 날짜를 구분하고 언제 어떤 회의를 했는지 한눈에 알아보기 힘들었던 것 같습니다.

이로 인해서 Front-end 개발자 분들이 개발하는 내용과 API를 개발하는 방향이 어긋났던 경험이 있습니다.

회의록을 꼼꼼하게 보지 못했던 제 잘못이었고 다시 소통을 통해 방향을 맞췄습니다.

회의 내용을 누적시켜 이전 기록을 확인할 수 있는 방식으로 빠르게 바꿨다면 불필요한 시간을 줄일 수 있었을 것 같습니다.

++ 좋은 방안은 무조건 공유해서 바꿀 수 있으면 바꾸자!!

4. 추가 기능 구현

1, 2차 프로젝트 모두 초기에 기획했던 필수 기능은 구현했습니다.

욕심을 내서 추가 기능까지 구현해보고 새로운 기능을 공부해보고 싶습니다.

---

독학을 할 때와 달리 협업과 업무 방식, 문제를 해결하는 방벙에 대해 배울 수 있었습니다.

한달이라는 짧지만 긴 시간 동안 개발자 커리어로의 걸음을 시작한 만큼,

때로는 전력질주 할 수 있는 개발자가 되기 위해 꾸준히 걷고 뛰어야겠습니다.

---

내 행동에 책임을 지고 설명을 할 수 있는 개발자
왜? 에 대한 질문은 항상 옳다