역시나... 1차때와 마찬가지로 첫번째 게시물 다음이 바로 회고록 😆 이번에는 정신적으로 좀 지칠뻔했던적들이 많았던?? 프로젝트였다!! (almost 번아웃)

---

0. Wanted (원티드)

채용 플랫폼

• 채용 공고
• 이력서 작성 & 직접 작성한 이력서 (pdf) 업데이트
• 직군별 연봉 확인

등... 정말 다양한 item이 있는 사이트라고 생각한다!! 오늘의 집에 이어서 원티드가 된것은 정말.. 좋았다.. 😃😭

이중에서 우리가 초점을 맞춘 부분은 역시나 Flow
채용사이트다 ? 메인이 뭘까! 싶을때 생각나는것은 채용정보, 이력서, 지원현황 이다. 따라서 이 부분을 필수구현으로 지정하였다.

---

I. Wantus

모두가 우리를 원한다!! WantUs 일단 이름 합격

1. 팀 구성

FrontEnd 3명 / BackEnd 3명

2. 프로젝트 기간

2021.03.02 ~ 2021.03.12 (11일간)

3. BackEnd 기술 스택

• python
• Django
• MySQL
• Git
• AQueryTool
• Bycrypt / JWT
• RESTful API
• AWS
• S3
• unittest

4. BackEnd 구현 기능

🔥 : (공통)참여 & 내가 맡은 부분

modeling

• 🔥 AQueryTool modeling
• 🔥 models.py 작성

user app

• 🔥 kakao API를 통한 social login

posting app

• 🔥 회원 유저에게 보이는 main page의 posting
• 전체 채용 list 조건별 정렬&filtering(다중 조건 filtering)
• 상세 채용공고와 연관 list 나열
• 갖고있는 이력서 혹은 새로 upload하는 이력서로 지원하기
• 채용공고 북마크 & 좋아요 구현
• 🔥 Pagination

resume app

• 🔥 user의 이력서 list
• 🔥 기본제공 이력서 새로 작성과 삭제
• 🔥 이력서 상세 내용 확인
• S3를 통한 파일 uploade (pdf 형식)

apply app

• 🔥 로그인 유저의 지원 현황 확인
• 🔥 로그인 유저의 북마크 & 좋아요 한 채용정보 확인
• 로그인 유저의 개인 정보 수정

-------------------------------------

II. 초석

2차때 처음 팀원발표가 났을때 들었던 생각은 "와... 진짜 장난아니다...." 였다.
다들 실력이 정말정말정말정말x100000000 좋으신 분들이었기 때문!!!! 저..는..누구..나는 왜 여기.....ㅠ? 싶을 정도..

1. 팀의 목표 : 정확한 목표 설정

1주차때는 목표설정 기간을 프로젝트기간과 동일한기간으로 잡았다!
이에 비해 이번 프로젝트는 1주차와 2주차로 기간을 나눠 1주차에는 필수구현을, 2주차에는 필수구현 refactoring과 추가구현을 진행하는 것으로 목표를 잡았다

"멋있어"

위에서 적었듯 우리가 초점맞춘 부분은 채용공고, 이력서, 지원현황 에 대한 부분이었다.

사실... 백엔드끼리 먼저 회의했을때 우리는 이력서는 빼고 직군별연봉부분을 갖고가는 것으로 얘기했었다. 뭔가 그래프도 있고 더 멋있어 보였기 때문?! 그리고 1차때랑 완전히 다른 로직으로 구현할수 있을거라 생각했다. BUT 우리는 백엔드야.. 보이는걸로 현혹되지 말고 로직을 생각해... 그리고 사이트의 중심요소 파악해야지! 채용사이트니까!! 따라서 직군별연봉 부분은 추가구현으로 빼두었다!

2. 개인의 목표 : 상태 돌보기

1차 프로젝트가 끝나고 이러저러 것들을 구경하닥 보게된 것이 있다.

"여유는 체력에서 나온다"

아주.. 공감하는 말이다. 내가 왜 1차프로젝트 내내 컨디션이 좋았을까? 라고 생각해 보았다.
평소 내 체력으론 그럴수가 없는 상황이었는데 이상했기 때문...

집-위코드 왕복시간이 10분이었기 때문이었다!!!!!!!! 아주 중요한 부분 🙌

확실히 체력적으로 덜 지치니까 그만큼 마음에 여유도 생긴 듯 했다! 아주 좋은선택이었어.. 라온 GOOD! 방식이 어떻든 체력관리에 도움이 된 선택을 한것 같아서 칭찬한다. 나.😆😆

하지만 지난 한달차에서도 3주차때부터 체력이 딸리는 것을 경험한것으로 보아 2주차때는 더 힘들지 않을까 싶었다. 그리고 맞았다

최대한 스스로의 상태를 돌보면서 프로젝트를 진행하고자 했다!

그리고.. 1차때에 했던 것에서 벗어나 좀더 다양하고 능숙하게 코드를 짜고 싶었다! 이번에는 AWS나 S3, unit test 등 아주 새로운 것들을 공부하고 바로 적용시켜야 했기 때문에

내가 이미 알고있고 할수 있는 부분은 혼자만의 타임어택처럼 빠르게 작성하고자 했다!

3. 진행 방식 : Slack, Notion, Trello, Standing meeting

이번에는 1차때와 달리 모든 방식을 잘 지켰던것 같다! 이걸 Agile 방식이라구 하나? 후후

1) Slack

우리팀 전용 채널을 만들고 역시나 git과 연동해 서로의 PR내역을 실시간 알람으로 확인할 수 있었다. 우린.. comment와 review 내용도 연동시켜 아주~ 실시간으로 리뷰받는걸 확인할 수 있었다😃😃👍

Wantus backend github repo 주소

2) Notion

지난 1차때 Notion으로 API document를 작성했듯이 이번에도 이를 적극 활용하였다. 그리고 정리왕 샘솔님🥰 덕에 좀더 깔끔하게 관리할 수 있었고 이에 질수없다던 PM 성준님께서 회의록을 chart로 깔끔하게 정리해주셨다!

3) Trello

1차때를 반성하며.. Trello를 적극 활용하였다. card 제목은 View 이름으로 하고 checklist를 통해 구현 과정을 세분화 하였다! 이렇게 하니 나한테도 좋고, 팀원들에게도 좋더라🥰🥰

4) Standing meeting

시간은 큰 일이 없는 한 오전 11시로 정해두었다! 회의 흐름은 각자가 아래의 내용을 말하는 것으로 진행되었다.

• 내가 어제 한 것
• 내가 오늘 할 것
• 현재 내가 하는 일의 blocker가 있다면?
• 나의 컨디션
• 특이사항

특이사항으로 자리를 비우는 시간도 공유... 딱히 다른 이유가 있는건 아니고!! 통신을 해야한다거나 할때!! 알면 편하니까!!!! 확실히 이렇게 하니까 내가 오늘 어디까지는 다 해야겠구나! 라는걸 다시한번 상기시킬수 있어서 좋았다

-------------------------------------

III. 프로젝트 진행

1. modeling (by AQueryTool)

WantUs도 역시나 구조가 쉽지 않았다. User와채용공고그리고 이력서가 아주~ 긴밀하게 연관되어 있어서 M to M 관계의 table을 어떤 app에 위치시킬지, 상세정보를 어떤 table과 연결시킬지 고민하는 시간이 있었다. 그래도 1차때에 비해선 빠르게 1차 모델링 결과가 나왔다!

modeling 결과 총 4개의 app이 나왔다 (User, Posting, Resume, Apply) 이번에 다들 새로운 개념(Social login같은)들이 있어서 처음엔 app 별로 담당자를 나누지 않고 함께 구현할 것에 초점을 맞춰 시작했다.

2. 로직 작성 : 공통

모두가 1차때도 social login은 해보지 않았다. 때문에 이부분은 3명이서 공통으로 작업했다. 카카오에서 제공하는 social login 공식문서와, googling을 통해 우리가 작성해야 하는 로직을 찾을 수 있었고, 그중에서도 우리에게 필요한 "유저의 이름 / 프로필 사진 / email" 부분을 특정지을 수 있었다.

2. 로직 작성 : 개인

AWS와 social login 그리고 S3를 모두 공통담당으로 잡아놓고 시간을 보내다 보니 그 외의 로직들이 계속 미완성 상태였다! 시간은 점점 가는데! 때문에 기본이력서와 마이페이지 부분을 얼른 맡아서 진행하기로 했다. 둘다 여러정보가 하나로 모여 보여지는 로직이었기 때문에 많은 table을 거쳐와야 했다.

ex) 유저가 북마크 한 posting에 대한 정보 보여주기
필요정보 : 채용공고 이름 / 채용공고 낸 회사의 이미지&이름&위치 / 채용공고의 카테고리 / 채용공고에 해당하는 tag들

위 정보를 모두 갖고오기 위해 거쳐야 하는 table들이다. 정참조와 역참조를 잘 구분해야 했다. 성능도!

3. 소통! Good!

구현 ver.

1차때의 경험으로 data 형식은 BE가 좀더 빨리 뽑아낼수 있다는 것을 알게 되었다. 그래서 작성된 view로 data를 출력해 그 형식을 Notion에 기록하였고, 담당 프론트분이 확인하신 뒤 수정이 필요한 부분은 함께 수정하는 식으로 진행했다!
그리고 나는 key 이름을 정하는데 나름의 기준을 세웠다.

"Camel case로 하되 이름은 내가 짓던 방식인 직관적인 방식"

_형식으로 key이름을 짓고 그걸 프론트 분의 코드에 넣어놓으니 코드가 길어지고, 받는 정보가 많아지니 가독성이 조금 떨어지는 듯 했다. 그리고! 내 로직에도 _가 다른 방식으로 사용되어야 했기 때문에 이름에서는 사용을 자제하는것이 좋았다. win-win 🥰

목표 ver.

뭔가 다들 여유가 있었다. 흔한 짬....?
FE에서는 기능구현까지 다 되었는데 BE에서 로직이 없다거나 / BE에서는 로직이 완성되었는데 FE에서는 보여줄수 있는 페이지가 없다거나 하는 부분이 분명 있었다!

하지만 우리는 서로 안맞는 부분을 맞추려고 애쓰지 않고, 오로지 필수구현항목에 집중하고자 했다. 다른건 다 추가구현! 추가구현 사항에서 맞지 않는 것은 이후에 생각할 부분이었다. 그리고 우린 충분히 맞출 수 있다고 생각했다!🥰

-------------------------------------

IV. 기억에 남는 코드

1. 중첩 for문 => __로 접근하기

마이페이지에서 유저가 북마크 한 채용공고에 대한 정보를 보내야 하는 로직을 작성하는데 효율적인 부분을 생각하기가 어려웠다.

우리 db 형태가 조금.. 복잡했기 때문?

ex) posting의 사진이 곧 company의 사진인데 posting과 연결된 것은 company_detail이고, 여기서 company를 FK로 갖고 있으며 company는 companyimage에서 FK로 존재한다.

1) 로직 구상

마이페이지의 GET 요청시 나에게 주어지는 정보는 오직 token에 담긴 유저의 정보 뿐으로 이를 통해 모든 정보를 가져와야 했다.

유저가 북마크 표시한 posting의 list를 가져와 for문을 돌리면서 companyimage들 중 첫번째 사진을 갖고와야 했으며, company와 tag의 중간 table인 companytag 테이블에서 해당 posting을 낸 회사의 tag리스트를가져와야 한다.

2) 첫번째 로직

먼저 주어진 정보인 user로 접근하여 역참조 관계인 bookmark 테이블의 posting_id 값을 가져오고자 했다.

mark_posting_id_dict_total = user.bookmark_set.values('posting_id')
>>> <Queryset[{'posting_id' : 1}, {'posting_id' : 2}]>

그리고 주어진 list의 dictionary 속 value인 id값으로 부터 posting instance가 담긴 Queryset을 구했다.

mark_posting_list = [Posting.objects.get(id=posting_id_dict['posting_id']) for posting_id_dict in mark_posting_id_dict_total]
>>> <Queryset[Posting 1, Posting 2]>

이렇게 완성된 posting list를 다시한번 for문을 통해 각각의 posting에 대한 정보를 구했다. 아래는 완성된 로직이다. (좋아요 표시한 게시물에 대한 로직도 동일하다)

3) 리뷰 받은 후

user로부터 접근하지 않고 바로 Posting에서 접근하는 방법을 찾는다면 더 효율적으로 될것 같았다! 경훈님의 고뇌...... "일단 쉘 켜보죠" 예...!!

Posting에서 bookmark한 짝꿍이 token으로 부터 받은 user인 것만 찾으면 되었다.

postings = Posting.objects.filter(bookmark__user=user)

1차프로젝트때부터 나오던 더블언더바의 출현이다.
bookmark 테이블의 user가 토큰으로부터 받은 user인 것을 필터링으로 삼아 postings을 선언해 주었다.!!!

그리고 수정하면서 미처 손대지 않았던 db 성능도 생각해 select_related와 prefetch_related를 사용해 주었다. (db hit 87개 => 35개)

받은 정보가 오직 user에 대한것이라고 해서 user로만 모든걸 접근하려하지 말았어야 했다! 감사합니다 경훈님!🥰🥰 이제 저 이상한 mark_posting_id_dict같은 변수들은 삭제...!!

구현 영상이다! 참고로 기존의 wanted 사이트에서는 북마크와 좋아요한 게시물의 UI가 동일하다. 하지만 우리생각에 북마크를 했다는 것은 그 채용공고를 더 자세히 기억하고 싶다는 뜻이라 생각해서 좀더 많은 정보를 보여주고자 했다!

그래서 추가적으로 회사의 태그와 카테고리 등에 대한 정보를 보내주었다.

2. unit test

unit test에 관한 것은 처음부터 끝까지 모두 기억하고 싶다!! 그래서 글도 따로 남겼다! 좀더 효율적인 unit test를 위해 알아야 할 것들이 더 많기 때문에 계속 공부해야 한다!

-------------------------------------

V. 진짜 회고

1. 아쉬운 점

1. 체력 관리

학원 내에 있을때는 괜찮았는데 집에만 가면 1시에 체력 전원이 꺼지더라... 그냥 노트북 껴안고 잠들었다 나름 따듯하니 좋았다
아무래도 누적된 피로때문인거같은데...!! 이부분이 조금 아쉽기도 하고.. 그렇다고 억지로 버티면서 코딩했다간 더 큰 피로가 쌓였을거란 생각에 제때제때 자서 다행인것 같기도 하다!!

2. 시간 관리

새로 습득하는 개념들이 많은데 이를 바로 적용해야 했어서 공부하랴 적용하랴 정말 정신없었다! 게대가 기업협업까지...!! 번아웃 비스무리.. 하게 온듯 하면서 하루종일 손에 아무것도 안잡힌 날이 있었다. 그래서 정말 많이 돌아다녔다 ㅋㅋㅋㅋㅋ 카페도 가고~ 지친 멘탈을 다그치지 않고 조금 풀어주려고 했던 것 같다.
그래도 끝나고 보니 그 시간들을 좀더 잘 통제했더라면 조~금 더 효율적인 코드가 나올수 있지 않았을까! 하는 후회가 든다!

이력서 상세 페이지에서 기본 이력서 내 내용 추가를 구현하지 못했기 때문에 (물론 추가구현 사항이었다) 계속 아쉬움과 후회가 남는것 같다
이력서 구현 부분!

3. 업무 관리

확실히.. 새로운 것들을 배워서 바로 적용하려 하니 누구 한명이 도맡아 하기가 많이 부담스러웠던것들이 있었다. 그러다 보니 일단 같이 시작하기로 한 기능들이 점점 많아졌고 시간을 많이 소모했던것 같다. 그렇게 다른 부분을 챙기지 못한것들이 있었고 이런 미흡한 점을 알게되었던게 거의 프로젝트 마감 3일전....? 나름 소통도 잘 하고 했던것 같은데 모두가 다같이 간과하고 있던 부분이 있었던것 같다!

그리고 기능 구현을 단일 flow 단위로 할수도 있지만 앱 단위로 생각할수도 있다는것.. "그부분..제가.. 챙겼어야 했던 거였나요......?" 싶은 적이 한번 있었다! app과 app 사이를 연결짓는 로직이라 미쳐 생각하지 못했던것 같다.😭 이 과정을 해결해나갈때 답답함도 있었고 왜 미리 생각하지 못했을까.. 하는 후회도 있었다. 이렇게 성장해 나가나 보다!

2. 잘한 점

우리팀의 회의 방식이 정말 효율적이고 좋았다고 생각한다!
Notion 활용 덕에 협업의 효율을 극대화 시킬 수 있었고 매일 회의로 자세한 상황을 공유하면서 진행 속도를 맞출 수 있었다!
우리 백엔드는

한가지 기능이 구현되면 통신과 동시에 무조건 unit test 진행, 최대한 빠르게 merge 되도록 하기

에 초점을 맞췄다. 덕분에 프론트 분들과도 수시로 통신할 수 있었다.🥰
한번 프로젝트 해보니 나 혼자 구현했을때랑 실제 통신으로 동작했을때 다르다는것, PR은 미루지 말아야 한다는 것을 알게 되었다.. 그래서 위 방식대로 착착! 진행되도록 했다.

덕분에 매 순간 힘겨웠다. unit test의 늪 ... 그래도 하다보니 할만 하더라!😆😆 unit test보다 어려운게 더 많거든!

3. 개인적으로 미흡했던 점

1. 미약한 성장?

개인적인 느낌으로.. 1차때 성장한 것에 비해 조금 덜 성장하지 않았나 싶다!! 상대적으로 상대적으로..! ㅠ.....

1차때는 "뭘 해야 하는지도 모르겠고.. 어떻게 하는지도 모르겠고.." 싶어서 하나를 알게 되었을때의 만족감이 엄청났다!
하지만 2차때는 일단 "뭘 해야하는진 알겠어! 근데 어떻게 하지?!" 였다.

내가 어느 부분을 놓치고 있는지 좀더 명확하게 보였기 때문에 개인적으로 조금 아쉬움이 많이 남는 기간이었다! 😭 개인공부로 충분히 매꿀수 있어! 빠샤🔥

2. 놓칠뻔한 성능

막바지에 건들이지 않았던 view를 맡아서 하느라 성능은 제외하고 로직에만 신경썼었다. 마음이 급했다는것.. 물론 로직 다 짜고 refactoring 해주었긴 하다!
하지만 이렇게 진행하지 말고, 미리 시간분배를 잘 해서 차분하게 코드를 작성해야 겠다고 느꼈다. 나는 실수가 잦은 편이니까!(아마도?)🥰

4. 리뷰받은 것!

1. a.k.a 디펜스게임

label 디펜스 게임... 경훈님에겐 PR 디펜스 게임... 대면 리뷰 너무 감사했습니다🥰🥰

2. 마지막!! PR의 주인공!!

은 바로 나!

감사합니다 승현님! 😆😆 우리팀 백엔드 마지막 MERGE ~!!

-------------------------------------

❤️ Thanks to.

먼저우리 WantUs팀!!! 다들 어디선가 모르게 나오는 여유로움, 안정감 덕에 저도 차분해질수 있었어요!!! 1차때는 마냥 편하고, 즐겁고, 활기찬 저였다면 2차때는 거기에 + 안정감! 이 있었음을 느낄수 있었습니다. 다들 너무 든든했어요!!

특히나 우리 공장장님들 프론트분들!!😭😭😭 전날 얘기한 부분을 다음날 완성해 오시다니요..... 신나게 돌아가야 할 공장에 우리 연료들(백엔드)이 속도 잘 못맞췄던거 같아 미안합니다! (물론 프론트분들은 우리가 더 빠른거 같다고 하셨지만 제가..보기엔............)

공장장 풀가동 하신 샘솔님 ㅠㅠㅠ!!!!!!! 저도!! 따라잡을라고!! 열심히!!

그리고 "머지....해주세요..." 라고 메아리 치는 우리 wantus 백엔드팀 열심히 리뷰해 주신 경훈님 !! 너무너무 감사드립니다!! 저녁도..거르셨던....ㅠ 감사했습니다!!🙌😆

-------------------------------------

👩🏻‍💻 구현 영상

wantus 클론코딩 시연 영상

언제나 환영이야 200ok!

-------------------------------------

🎉 이후의 시간

두달차 회고록에 작성할지 모르겠지만 일단... 기업협업을 나가게 되었다!! 그와 동시에 정 많이들었던 동기들과 잠깐동안 헤어짐? 을 겪어야 한다.

이제 막 적응하려나 싶었는데 바로 둥지탈출하는 기분!!?!?!? 저! 살아남을수 있을까요?!?

나 기업이랑 라온이랑 위워크 다 가까우니까 퇴근하고 뛰어올께요..나...만나줘......😭😭