살아 있다 우린
꿈을 꾼다 우린
아름다운 우리 여기에 있다 - Beautiful Beautiful, ONF

🥶 Wadiz Clone Project

wadiz를 클론하고 싶었던 이유?

---

나는 프로젝트 아이디어 3개 중 2개를 크라우드 펀딩 사이트로 발표할 정도로 크라우드 펀딩에 관심이 많다. 백엔드로서 크라우드 서비스 사이트 데이터 모델링을 꼭 해보고 싶었고, 그 중 우리나라 대표 크라우드 펀딩 플랫폼 와디즈만의 기능을 꼭 구현하고 싶었다.

와디즈는 하루가 다르게 성장하는 기업이며 펀딩하기 뿐만 아니라, 스타트업 찾기 등 다양한 분야로 계속 가지를 뻗어나가고 있다. 또한 스타트업 및 작은 기업들과 사용자들의 중개 플랫폼이 되어주며 다양한 상품 펀딩뿐만 아니라 스타트업과 투자자의 연결고리까지 되어주는 사이트다. 이 다양한 기능을 하나씩 구현하면 백엔드 개발자로서 공부할 수 있는 부분이 정말 많다고 생각했다. 로그인, 검색, 상품 필터, 카테고리 필터, 회원가입, 펀딩신청, 찜하기, 문의하기, SNS 공유하기, 상품 댓글 작성처럼 다양한 커머스 기능부터 실시간 랭킹 시스템, 펀딩 신청, maker 신청하기 같은 기능도 정말 매력적으로 다가왔다.

🧤 12일 안에 사이트 만들기

눈 떠보니 PM

---

프로젝트 팀 발표 전날 이상하게 잠이 안왔다. 새벽에 집을 나와 위코드 근처 스벅으로 가서 커피 한 잔 마시며 데이터 모델링을 공부했다. 매우 뿌듯한 기분으로 출근했다. (폭풍이 오기 전 바다는 고요한 법)

출근 5분만에 팀 발표가 올라왔고 와디즈가 팀 프로젝트 중 하나로 선정되었다. 그리고 내가 PM이 된 것이다🤯

🖤 WeGotDiz 탄생 🖤

• 팀구성: 프론트엔드 3명, 백엔드 4명
• 프로젝트 기간: 2/15~2/26일
• 프론트엔드 기술 스택: HTML / CSS, JavaScript, React(CRA 세팅), React DOM, React(Router DOM), Sass, Slick-slider, RESTfulAPI, Figma
• 백엔드 기술 스택: Python, Django, MySQL, bcyrpt, pwjwt, RESTfulAPI, AqueryTool
  

공통 Goal

---

3CO

팀원들과 함께 공통 목표를 설정하고 함께 목표를 향해 달렸다!

1. Cooperation
2. Collaboration
3. Communication

🧤 프로젝트 진행 방식

사용한 Material:

---

• Trello
• Slack
• Google Docs
• Google Spread Sheets
• Notion
• Git

1. Trello:
스프린트 중 서로의 workflow를 살피며 큰 그림을 볼 수 있는 Trello로 Backlog, In Progress, Done, 공지사항, This Week, 회의록 및 공유 문서 리스트를 공유하며 각자 맡은 기능을 카드로 상세하게 적어 해당 카드를 리스트에 옮기며 관리했다.

2. Slack:
빠르게 소통하고 시간을 정할 수 있는 슬랙을 활용해 팀원들과 소통했다. 특히 git과 연동시켜 멘토님들께서 코멘트를 남기실 때 빠르게 확인할 수 있어서 유용하게 사용했다.

3. Google Docs, Google Spread Sheets:
전날에 작성한 회의록에 Daily Standup Meeting 때 나눴던 이야기를 Google Docs에 적은 다음 Trello에 올렸다. 나중에 각 기능 담당 별 프론트와 백엔드가 사소하게 나눴던 이야기/ 결정 사항들도 올려달라고 부탁드렸다. 덕분에 회의에서 어떤 결정 사항들이 있었는지, 어떤 내용들을 앞으로 결정해야하는지 등 진행 상황 파악하는 시간을 많이 줄였다. Google Spread Sheets으로 csv 파일 등 파트를 나눠서 진행할 수 있는 내용들을 정리하고 관리했다.

4. Notion:
프로젝트 촤종 발표 때 코드 공유를 위해 노션을 활용해 작성한 코드 및 해당 코드를 어떻게 해결했는지 적었다.

5. Git:
Git을 활용해 기능별로 브랜치를 만들고 main과 merge하는 작업을 진행했다.

SCRUM 방식으로 진행된 프로젝트

---

Daily Standup Meeting

매일 10시반 - 11시 사이에 Daily Standup Meeting을 진행했다.

총 6가지 항목을 중심적으로 회의를 기획했다:

• 공지사항
• 프-백
• 어제 한 것
• 오늘 할 것(Goal Of Today)
• 결정사항
• 공유 링크

1. 공지사항
전날 결정된 주요 사항들을 다시 한번 공유했다.

2. 프-백
기능 담당 프론트-백 짝꿍이 각자 맡은 기능에 대해 어디까지 구현했는지, 등 상황을 공유했다.

3. 어제 한 것
각자 어디까지 구현했고, 언제까지 구현 가능할지, 어디서 막히는지(Blocker)를 공유하며 프론트와 백 사이의 통신이 언제 가능한지에 대한 이야기를 나눴다.

4. 오늘 할 것
각 팀원 모두 오늘의 목표가 무엇인지(Goal Of Today) 발표했다.

5. 결정사항
함께 의논해야 하는 내용(추가 기능 구현 여부) 및 결정해야 하는 사항들을 공유했다.

6. 공유 링크
Google Docs, Google Spread Sheets 등 중요한 링크를 공유했다.

1st Daily Standup Meeting(2/15)

첫 Daily Standup Meeting에서 프론트와 백이 함께 어떤 기능까지 구현할지 의논했다. 필수 구현부터 추가 기능 구현까지 나눠 프로젝트가 빨리 끝날시 어떻게 확장시킬지 함께 고민했다.

[조율 결과] 기능은 총 6가지로 정했다

1. 메인 페이지
2. 프로덕트 페이지
3. 오더, 결제 페이지
4. 마이페이지
5. 로그인
6. 회원가입

🧤 기능 구현 시작

[백엔드의 Workflow]

1. 데이터 모델링, models.py
2. csv, db_uploader
3. 기능 별로 담당 나누기
4. 각자 맡은 기능 구현
5. 기능 별 프론트-백 통신
6. main과 merge되면 conflict 해결하기
7. 기능 n개 합치고 프론트와 통신하기

1. 데이터모델링, models.py

---

백엔드 팀원들과 함께 aquery tool을 활용해 모델링을 시작했다. 모델링만 1주일 걸린다는 멘토님들의 말씀에 '에이 ~ 설마'했지만 역시 설마가 사람을 잡는다. 잘해야 3일 걸리겠다고 자신감 가득했던 우리는 프로젝트 시작하고 9일 이후에도 모델링 수정 때문에 고통 받았다.

고민했던 점:

1. class Order 속 User와 Address의 on_delete에 대해 고민했다. User 즉 사용자가 탈퇴했을 경우를 생각해 models.SET_NULL로 설정하고, Adress는 나중에 통계(data analysis)를 위해 남아있어야 한다고 판단하고 models.PROTECT으로 설정했다.

2. views.py를 작성하다 우리가 profile image, category image field를 추가하지 않았다는 것을 알았다. 호진님의 말씀처럼 백엔드는 생각보다 '보여지는 것'에 더 집중할 필요가 있다.

3. Product 페이지로 들어가면 '스토리', '반환 정책', '새소식', '커뮤니티', '서포터'라는 탭이 있다. 해당 탭을 누를 때마다 URL이 바뀌어야 하는지, 아니면 같은 URL에 진행되어야 하는지 고민했다. 결국 우리는 products_contents이라는 reference table을 만들고 해당 product테이블을 참조하게 만들었다.

4. 와디즈를 보면 총 달성 금액, 총 달성 percentage, 몇명의 서포터 등 실시간으로 값이 변하는 항목들이 있다. 우리는 해당 항목들을 views.py에서 바로 계산해서 보여주는 것이 더 효율적이라고 판단하고 데이터베이스 field에 추가하지 않았다. 하지만 멘토님들과 상의 후 필요한 field라고 판단해 추가했다.

5. Reward - Order 관계 설정할 때 어려웠다. 백엔드끼리 3시간 동안 토론하며 결국 둘은 m2m 관계이며, 중간테이블에 개별 리워드 수량을 체크할 수 있는 quantity field를 추가했다.

6. 월요일에서 금요일까지 모델링만 했는데 또 수정할 항목이 보였다. 더 효율적인 모델링을 위해 물론 모델링 자체도 정말 꼼꼼히 해야 하지만, views.py 로직까지 생각하며 접근해야겠다는 생각이 들었다. 앞서 호진님께서 말씀하신 '보여지는 것'에도 집중해야 한다.

2. 내가 맡은 기능

---

1. [회원가입] 회원가입 엔드포인트 및 유효성 검사 기능 구현
2. [로그인] 로그인 jwt를 활용한 엔드포인트 구현
3. [로그인 데코레이터] jwt을 활용한 로그인 데코레이터 구현
4. [마이 와디즈] My Wadiz 사용자 정보, 좋아요 목록 전체 불러오기 기능 구현
5. [마이 와디즈] My Wadiz 사용자 정보, 펀딩한 목록 전체 불러오기 기능 구현

3. 기억하고 싶은 코드

---

해당 코드에 대한 포스팅을 따로 했다. 설계한 DB 특성상 7개의 테이블을 타고 들어가 정보값을 빼야하는 상황이었다.

해당 코드를 짜며 느낀 점은:
1) list comprehension을 쓰면 코드의 가독성이 올라간다
2) 더 깔끔한 코드를 위해 고민하자

4. 기억하고 싶은 리뷰

---

더 깔끔한 코드 & 수고를 줄이기 위해 django 안에서 제공하는 기능들을 하나씩 배우면서 적용해보자.
해당 리뷰는..처음이자 마지막으로 칭찬받은 리뷰이기도 하다💆

Git에 대한 이해가 부족했다. 바로바로 conflict를 해결하지 않았다. 다른 팀원의 브랜치 merge를 기다리다 최종 발표 전날 급하게 conflict 해결하고 소헌님을 괴롭혔다...(죄송합니다 소헌님..) 프론트와 백이 개별적으로 통신할 때 작동하던 기능들도 합치니 천천히 어긋나기 시작했다. 또한 conflict 해결이 늦어져 뒤늦게 받은 코드 리뷰에서 프론트와 맞춘 키값에 대한 피드백도 받았다. 지금은 데이터베이스 사이즈가 작고 프론트 3분이 할 일이 너무 많고 바쁘셨기 때문에(ㅠㅠ) 프론트 json에 맞춘 키값을 설정하는게 더 효율적이라고 판단했다. 하지만 만일 데이터베이스가 커졌을 때 이것은 엄청 비효율적인 코드임은 분명했다.

프론트는 백엔드를 생각해야 하고, 백엔드는 프론트를 생각해야 한다. 둘은 충분히 서로를 설득시킬 수 있으며 사용자와 데이터베이스를 위해 더 효율적인 방안을 함께 탐구하고 연구할 수 있다.

키값 피드백은 큰 충격을 안겨줬다. 내가 PM 일을 제대로 못해서 프로젝트 발표 전날까지 최종 merge가 안됐다는 생각이 컸는데, 가장 기본적인 키값에서 피드백을 받으니 11일 동안 제대로 한 일이 없다는 생각이 들며 매우 괴로웠다. 하지만 내일은 반드시 오고 우리는 최종 발표를 위해 merge를 진행해야 하며 최종 통신도 해야했다. PM으로서 내 기분이 다운되면 전체적인 팀 사기가 떨어질 것 같아 얼른 정신차리고 최종 발표를 준비했다.

5. Django를 배우며 느낀 점

---

파도 파도 새로운 기능이 나오는 걸보니 정말 대단한 프레임워크다. 그러나 Django가 제공하는 편리한 시스템에 기본적인 공부(SQL, 등)를 소홀히 하면 안된다는 생각도 들었다.

6. 최종 결과

---

WeGotDiz 7명의 뼈와 살을 갈아넣은 결과...

1. 메인페이지(펀딩하기와 통합시킨)

2. 전체 검색 및 카테고리 별 필터, 상세 필터 적용

3. 회원가입/로그인 된 사용자만 좋아요 및 펀딩하기 가능

4. 회원가입/로그인 후 좋아요 및 펀딩하기 가능

5. 필수 Input Field 입력 후 마이페이지 이동하면 펀딩 목록 업데이트 완료

🧤 회고 회의

---

사진 찍어주신 채현님 감사합니다❤️

마지막 Trello card로 회고 회의를 추가했다.

회고 회의는 총 3가지를 중점적으로 진행했다:

1. 다음 프로젝트 때 더 좋은 팀원이 되기 위한 노력이 뭐가 있을까요?
2. 팀 프로젝트 하면서 나한테 아쉬웠던 부분?
3. 내가 장점으로 내세우고 싶은 부분? : 팀원들이 칭찬해주는 시간~💕

🧤 PM으로서 내가 하고 싶은 이야기

나에게 PM이란?

---

✅ PM은 team의 큰 그림을 그리는 사람이다. 팀 전반의 WHO, WHAT, WHEN, WHERE, WHY, HOW를 게속 체크하는 사람이라고 생각하면 된다. 누가, 무엇을, 어디까지, 얼마만큼, 언제까지, 어떻게 진행하는지(진행될지) 계속 체크해야 한다. 또한 팀원들이 어려워하는 부분들(Blocker)을 계속 체크하며 해당 부분들을 어떻게 하면 PM으로서, 그리고 한명의 팀원으로서 해결할 수 있을지 고민해야 한다. 항시 더 효율적인 방안을 모색해야 하며 주도적으로 비상 상황을 해결하거나 도움을 요청해야 한다.

나는 PM으로서 어떤 일을 했나?

---

✅ 나는 우리 팀원들이 개발에만 집중할 수 있는 환경을 만들었다. Daily Standup Meeting 때 보면서 의논할 회의록도 꼭 준비했다. 회의록을 통해 더 효율적으로 팀원들의 상황을 살필 수 있었다. 팀원들도 회의록을 통해 전에 의논했던 사항/항목들을 확인할 수 있었다.

✅ PM은 그냥 계속 '확인'하는 사람이라고 봐도 과언이 아니다. 프론트와 백 팀을 계속 확인하고, 프론트 내 팀원들 및 백 내 팀원들을 확인하며, 팀별 개인별 진행 상태를 계속 확인하는 사람이다.

✅ 중간 발표 때 정확한 피드백을 받기 위해 PPT를 준비했다. (알고보니 우리 7명 팀끼리 하는 발표가 아닌 전체 발표였다... 다른 팀들에게 죄송했다... )

✅ 공지사항 및 결정사항을 공유했다. 다른 팀원들이 제시한 의견들을 적극 수용하고, 더 효율적인 방법을 위해 함께 모색할 수 있는 환경을 만들고 싶었다. 독단적으로 어떤 일을 결정하지 않았으며, 해당 결정 사항에 대해 의논하고 충분히 토론했다.

PM 하면 좋은 점

---

✅ 팀원들과 정말 끈끈해진다. 부족한 PM을 믿고 항상 지지해주고 둥가둥가 해주는 팀원들 덕분에 더 열심히 해야겠다는 생각이 들었다.

✅ 큰 그림을 볼 수 있다. flow를 볼 수 있기 때문에 어디서 어떤 문제를 해결해야 하는지 바로바로 보인다.

✅ 나에 대해서 정말 많이 배운다. 이제는 제법 나에 대해서, 타인에 대해서도 많이 안다고 생각했는데 역시 착각이었다. 나의 한계, 나의 가치관, 나의 잘못된 습관과 버릇들을 확인하고 다시 바로잡는 좋은 시간이었다.

PM 하면서 아쉬웠던 점

---

PM이 하는 일이 너무 많다. PM으로서 할 일이 너무 많아 개발을 거의 못했다. 당시에는 조금 허탈했지만 지금 생각해보면 개발자로서 정말 중요한 소통, 합의, 조율을 배운 시간이라고 생각한다. 코드 로직도 물론 중요하지만 PM이라는 기회로 사람과 사람이 일하는 방법을 배운 것 같아 정말 뜻깊은 시간이었다.

부족한 PM에게 과분한 팀원들

---

✅ 나는 PM으로서 매순간 부족하다고 생각했다. 팀원들 개개인의 역량을 내가 이끌어내지 못하는 느낌도 많이 받았다.

✅ 우리끼리 정신 없이 회의하거나 일을 하고 돌아보면 타 팀들은 다 식사하러 나갔었다. 이런 상황이 반복되다 보니 "내가 비효율적으로 시간을 써서 우리 팀원들이 사서 고생을 하는게 아닌가?" 라는 생각이 들었다.

✅ 프로젝트 시작하고 9일이 지나니 체력적으로, 심리적으로 한계가 왔는데 팀원들 모두 힘내라는 메세지 보내주시고.. 안아주셔서 정말 끝까지 갈 수 있었다. 정말 한 명 한 명 소중한 사람들이고 계속 함께 개발하고 싶다.

✅ 우리 프론트 정말.. 정말 고생 많으셨습니다.. 아.. 눈물이 또... 😭

🧤 내가 되고 싶은 개발자: 2차 프로젝트를 임하는 자세

더 효율적인 코드를 위한 고민

---

효율적인 코드에 대한 고민을 충분히 하지 못했다. 이 부분은 2차 프로젝트 때 꼭 많이 생각하고 고민하며 멘토님들께 깨지고 싶다(?)

프론트에서 받는 자료에 대한 고민

---

프로젝트 발표 전날 프론트-백 소통이 잘 안됐다. 백엔드는 프론트에게 넘겨줄 자료에 대해 먼저 충분히 고민하고, 프론트에게 미리 알려줬더라면... 프론트도 더 효율적으로 컴포넌트를 짤 수 있었고, 백엔드도 더 효율적인 코드를 구축할 수 있었다. 이 점도 2차 프로젝트 때 꼭 보완하고 싶은 부분이다.

프론트 분들이 너무 바빠 보이셔서 이 수고라도 꼭 덜어드리고 싶다.

끊임 없는 소통의 중요성

---

어제 맞춘 이야기도 오늘 또 다시 확인해야 한다. 우리끼리 맞춘 이야기도 공유하고 다른 팀원들과 체크해야 한다. 끊임없이 확인하고 내 기능과 연관되어 있는 모든 팀, 짝꿍에게 공유하고 말해야 한다.

과한 소통은 없다.

모델링의 중요성

---

모델링 할 때 views.py 로직까지 생각하며 접근해야 한다. 호진님 말씀처럼 백엔드는 '보여지는 것'에도 집중해야 한다. 웹페이지로 생각하는 버릇은 버려야 하지만 보여지는 것을 간과하면 안된다.

Git에 대한 이해

---

Git flow를 1차 프로젝트 최종 발표 전날 이해했다. 정말 아쉬움이 많이 남았다.

conflict는 그 때 그 때 해결하고 merge 받자!

🧤 '아닐 수도 있고' 태도의 중요성

---

모 기업의 채용 인재상에 이런 항목이 적혀있었다. '아닐 수도 있고', '내가 틀렸을 수도 있지'.

그렇다. 본인 코드가 정답이 아니라는 마인드가 기본적인 베이스로 깔려 있어야 한다. 내가 틀릴 수도 있고, 팀원이 틀렸을 수도 있다. 하지만 '내 코드가 맞다'면서 남을 설득하려고 할 때 우리는 더 효율적인 코드를 위해 고민하는 태도보다는, 내 코드가 왜 맞는지에 대해 더 적극적인 태도를 보일 가능성이 높다.

즉 더 좋은 코드를 위해 고민해야 하는 시간은 줄어들고, 우리는 비효율적인 코드를 적용할 가능성이 커진다. 항상 내 코드가 정답이 아니라는 태도로, 다른 사람의 의견에도 open-minded 되어야 한다🙏

🧤 빠른 인정

---

위에서 언급한 내용과 연관되어 있다. 내 코드가 정답이 아닐 수 있다. 또는 내가 생각한 로직이 잘못된 방향일 수 있다. 이 때 빠른 사과, 빠른 인정이 얼마나 중요한지 이번에 알았다. 사람은 의외로 작은 한마디에도 쉽게 풀리기 때문이다! 우리 WeGotDiz팀 팀워크의 핵심이 바로 '빠른 사과'가 아닐까 싶다😇

🧤 WeGotDiz 마무리

Team WeGotDiz 화이팅!

울 프둥이들.. 백둥이들 넘 고생많으셨습니다! 위갓디즈 최고!
❤️ 정민님 ❤️ 사랑님 ❤️ 혜성님 ❤️ 동근님 ❤️ 지윤님 ❤️ 호진님❤️ 우리 글로벌 세상에서 만나요!

항상 늦은 시간까지 도와주시는 멘토님들 감사합니다.

프로젝트 발표 전날까지 리뷰해주셔서 감사합니다 소헌님..❤️ 항상 귀찮게 해서 죄송하고 감사합니다 경훈님..🥺 새벽에도 리뷰 남겨주시는 승현님 정말 감사합니다..😊 보고싶어요 지훈님..😭