---

SpaceX Clone Project

---

프로젝트 소개🤖

민간 우주기업 Space X 웹사이트 클론 프로젝트

팀원
Backend : 김기욱👈, 이지연
Frontend : 송다슬, 황연욱, 이호현
Github [BackEnd] - Repository

기간
2020년 08월 18일 ~ 2020년 08월 28일 (10일)

적용기술🦾

[공통]

• HTTP
• Git
• Linux
• VScode
• Trello : 프로젝트 스크럼툴
• AWS : EC2, RDS, S3 활용
• PostMan : API 테스트 및 결과 내용 공유

[백엔드]

1. Python

• BeautifulSoup : 웹 크롤링 및 파싱
• Selenium : 내장 기능을 활용해 다수의 웹 데이터를 효율적으로 크롤링
• List comprehension : 코드실행 효율 향상
• Pandas : 간편한 csv파일 저장 및 열람
• ast : list_eval 기능 사용

2. Django

• Bcrypt, PyJWT : 회원가입 시 기입한 비밀번호 암호화 및 토큰 발행
• UnitTest : 클래스 단위 코드 디버깅
• LoginDecorator : 발행한 토큰을 통한 등록회원 인증/인가

3. MySQL

• 데이터 업로더를 통해 DB구축

내가 맡은 역할💁‍♂️

• 데이터모델링(공통)
• 홈페이지 상품 페이지 크롤링
• 데이터 업로더 작성
• MySQL DB구축
• 상품 메인페이지 뷰
• 상품 상세페이지 뷰
• 상품 뷰에 대한 유닛테스트 구현

무엇을 잘 했나?🙆‍♂️

함께했던 모델링

위코드 11기의 경우 백엔드가 숫자가 적었기 때문에 모든 팀에 백엔드가 2명만 배치 되었다. 그렇기때문에 모델링의 경우에도 한 명이 다 맡은 경우도 있었는데, 우리팀의 경우에는 그렇게하진 않았고 백엔드 두 명이 함께 모델링을 진행했다.

모델링만 이틀 잡아도 된다고 말을 하시길래 처음에는 "모델링 짜는데 뭘 그렇게까지 투자하지?"라고 의문이였는데, 프로젝트를 진행하다보니 왜 그렇게 모델링의 중요성을 강조하셨는지 뼈저리게 느꼈다. 크롤링이나 DB업로드를 할 때 모든 과정들은 모델링에 따라 구축된다.

그 뿐만 아니라 프로젝트 웹사이트에서 프론트엔드와 연결을 할 때도 렌더링하기 쉬운 명료한 데이터를 보내주기 위해서는 모델링이 굉장히 중요했다. 누군가 그랬었다 "백엔드는 넓게 봐야된다" 처음엔 그 말의 의미를 잘 이해하지 못 했는데, 모델링 단계부터 프론트엔드에게 보낼 Json Data까지 생각했어야 함을 프로젝트에서 깨달았었다.

우리팀 같은 경우에는 두 명이서 함께 모델링을 진행했기에 구축과정에서 참조관계 오류나 테이블명등을 바라볼 때 세세하게 확인 할 수 있었고, 실제 모델링 피드백을 받았을 때도 큰 수정사항 없이 패스할 수 있었다. 물론 후에 실제 상품페이지에 구현하기 더 쉬운 방향으로 모델을 수정을 하긴 했지만, 전반적으로 큰 수정사항 없이 프로젝트를 마칠 수 있었다.

흔들리지 않았던 아침운동

사소하지만 나 스스로 대견했던 점이다. 프로젝트가 시작되고 퇴근시간이 11시반이 넘어갈 때도 다음날 아침운동을 거르지않으려 노력했고 일주일에 4-5일정도는 무조건 운동을 했다. 위코드에 들어가면서 운동을 놓지 않았던 이유는 두 가지다.

첫 번째로 위코드는 이틀짜리 해커톤이 아닌 세 달에 걸친 부트캠프기 때문이다. 모든 체력을 극히 짧은 시간에 쏟아부어야 하는 해커톤이 아닌 부트캠프는 단거리달리기가 아닌 마라톤이라고 생각했다. 그리고 집중력을 지구력있게 유지하기 위해선 무조건 체력이 뒷받침 되어야 한다고 생각했다.

두 번째로 일정한 생활패턴을 만들어내고 싶었다. 위코드 시작 전 퇴직 후 공백기간이 꽤 길었기 때문에 내 생활패턴은 꽤나 불규칙적이였다. 기상시간도 매일 달랐었고, 기상하고 나서 시간이 많으니 으레 유튜브 등을 보면서 쓸데없이 시간을 많이 낭비하곤 했다. 이런 생활에서 벗어나고 싶었다. 무조건 늦어도 7시에는 기상하고 7시반까진 헬스장에 도착해서 1시간 운동후 9시20분까지 아침식사를 하고 위코드로 출발했다. 아침의 시간이 정확하게 짜여지니 하루의 시작부분에서부터 낭비되는 시간이 줄어들었고, 더불어 전체적인 하루의 스케쥴링이 반듯해졌다. 만약 운동을 하지 않았다면, 아침의 시간이 넉넉하고 여유로웠을 것이다. 하지만 여유로운 시간을 나는 결국 유튜브로 소비해버리지 않았을까?

라스트 백엔드

나는 프로그래밍을 위코드에서 처음 시작했고, 나 스스로 전공을 했었거나, 현업경력이 있던 동기들에 비해 많이 부족하다고 생각했다. 그래서 아침운동때문에 아침에 일찍 올 순 없으니, 저녁시간이라도 30분씩 더 하자라는 생각을 가지고 프로젝트에 임했다.

결론적으로 프로젝트 기간 거의 대부분 마지막 백엔드는 내가 장식했었다. 새벽까지 시간을 무자비하게 갈아넣는 프론트엔드분들까지는 따라잡진 못 했지만, 백엔드 그룹 내에선 그래도 조금 더 했다라는 생각에 나름대로 뿌듯함을 가지고 퇴근을 했었고, 실제로 그 30분 더 늦게라는 시간이 조금이나마 내 성장을 촉진시켜줬지 않았나라는 생각을 한다.

좋은건 빨리

결국 모든 백엔드분들이 다들 멋지게 구현하셔서 의미가 퇴색했지만, prefetch와 querystring을 배우고나서 거의 1,2등으로 빠르게 코드에 구현했었다. Unit Test의 경우에도 대부분 더미데이터 구축이 필요없는 로그인/회원가입 페이지에 PostView를 대상으로 구현했지만 나는 GetView에 직접 더미데이터를 만들어가며 구현했다.

항상 남들 진도를 따라가기 바빴던 나였지만 이번 프로젝트의 경우 내가 먼저 구현한 코드가 있다는 사실이 너무 기뻤었다.

무엇을 못 했나?🤦‍♂️

너무나 늦었던 M..e..r..ge

부끄럽게도 나는 Origin Master로부터 9일동안 merge를 받지 못했는데, 이유는 두 가지였다. 우선, 부분부분 완성될때마다 PR(Pull Request)를 올리는 동기들과 달리 바보같게도 나는 모든 코드를 다 완성하고 올려야겠다는 마인드로 임했고, 결론적으로 다른 동기들보다 PR 요청이 훨씬 늦어지고 피드백도 늦게서야 받고 그제야 부랴부랴 여러 곳을 수정해야되서 시간이 더욱 늦어지게 되었다.

두 번째로는 코드가 속된말로 '더러웠다'
일단 기능구현에만 열을 올리다보니 코드의 길이자체도 길었고, 하나의 뷰에서 충분히 처리할 수 있었던 기능을 뷰를 두 개로 나눴었으며, 역참조를 쓰면 보다 명료하고 깔끔하게 정리될 구문을 정참조를 써서 보는이로 하여금 어리둥절할 코드를 작성했었다.(쓸데없는 if문 사용은 덤...)

그렇기에 첫 번째 주차에 상품페이지 모든 기능을 구현했음에도 내 프로젝트 두번째 주차는 코드리팩토링을 하는데 대부분의 시간을 소모하게 되었다. 기능구현 하나를 더 하고, 빨리하는게 중요한게 아니라, 클린코드, 효율적인 코드, 누구나 알아보기 쉬운 코드의 작성이 얼마나 중요한지 이번 프로젝트에서 정말 누구보다도 여실히 깨달았던 것 같다.

부족했던 소통

핑계로 들릴 수 있겠지만 나 스스로의 실력이 잘하는것이 아니다라고 생각했었고, 내가 맡은 부분에만 신경쓰느라 같은 백엔드 팀원인 지연님과 충분히 소통하지 못하고 팀원이 도움이 필요할 때 제깍제깍 도와주지 못한 점이 너무 아쉽다. 팀 프로젝트란 함께 호흡하며 저어 나가는 보트같은 건데 이번 팀 프로젝트에는 그냥 내 노젓기에만 바빴던 것 같다.

사실 상경계열을 학사로 다니면서 스스로 커뮤니케이션에는 나름 자신 있다고 생각했었는데 내 전공도 아니고, 조금은 낯선 방식의 팀 프로젝트를 진행을 하다보니 금세 밑천이 드러났던 것 같아 조금은 부끄럽다. 다음 프로젝트에서는 '팀 프로젝트'의 의미를 항상 되새기며 팀원간에 호흡 맞추기에 집중을 해볼까한다.

부족했던 기능구현

앞서 말했듯이 너무 길었던 코드 리팩토링과 부족했던 소통때문에 웹사이트 내에서 더 구현해볼 수 있었던 '검색'기능이나 '최근 본 페이지' 등을 구현 못했던 점은 정말 아쉽다.

겁쟁이에게 내려진 깃의 철퇴

PR도 늦었고, Merge도 늦었기에 남들이 이미 겪었던 Git의 꽃인 conflict를 늦게서야 겪었는데 사실 이전에 이미 충분히 겪을 수 있던 점을 컨플릭트를 피한 답시고 Git clone과 손merge만을 썼던 내게 내려진 철퇴가 아니였나 싶다. 이번 프로젝트 기간 내 꽤나 많은 인원들이 홍역을 겪듯이 깃의 철퇴를 맞아 절망을 하곤 했는데 나 역시 이를 벗어나지 못했던 점이 아쉽다.

해결 및 개선방안🧑‍💻

늦더라도 옳은 길로

코드에서 잔머리를 굴리는것은 옳지 않다는 점을 다수의 리팩토링을 하며 깨닫게 되었다.
DB업로드때도 "이렇게 해도 상관없지않나?"라는 생각에 리스트째로 집어넣고 했는데 이는 나중에
DB에서 데이터를 불러올 때 더티코드를 양산하는 주범이 되었고, 결국 DB업로드부터 다시 짜게 되었다.

결론은 "늦더라도 옳은길로" 가는게 더 빨리 "도착지점"에 갈 수 있다는 것을 이번 프로젝트에서 깨달았기 때문에 다음부터는 모델링, 크롤링, DB업로드 일련의 과정에서 정확한 로직을 짜는데 더 많은 시간을 투자 할 것이다.

최적의 코드를 위한 노력

프로젝트를 마치고 팀 별로 프로젝트 내용을 발표했을 때, 백엔드분들 중 건규님과 태현님이 직접 비슷한 기능의 코드 두 가지를 실행시간을 측정한 자료를 보여줬는데 개인적으로 정말 감명이 깊고 반성을 하게 되었던 것 같다.

나 같은 경우는 그냥 포스트맨에 측정된 시간만 보면서 "프리페치를 적용하니 좀 빨라졌구나" 생각했던게 다 였는데 직접 파이썬 내에서 시간측정은 물론이고 비슷하겠거니 생각했던 select related와 prefetch의 속도차이, elastic search와 ìcontains의 속도차이를 실제로 궁금증을 가지고 측정했다는 점이 더 나은 효율을 위해 코드를 짜는 '백엔드 마인드'에 대해 다시 생각하게 되었다.

동기들의 이런 좋은 점들을 본받아 다음엔 단순한 코드작성에서 끝나는게 아니라 내가 구현한 코드가 실제로 빨라졌는지, 더 나은 코드를 위해 비슷해보이지만 다른 기능과의 비교를 해보며 최적의 코드를 위해 항상 생각(Thinking)을 멈추지 말아야겠다.

배려와 소통

진부한 이야기지만 결론적으로 팀 프로젝트의 핵심은 배려와 소통에 있다는 것을 1차프로젝트를 마치며 다시 한번 느꼈다. 부족한 소통은 결국 시간적으로 쫒기게 만들었고, 약간은 아쉬운 결과물로 돌아왔던 것 같다. 팀 프로젝트는 나 혼자만 해결하면 끝나는 Assignment가 아닌 함께 만들어가는 GroupActivity라는 점을 항시 되새겨야겠다.

기록하고 싶은 코드 ✍️

URL로 가볍게 필터링하자 쿼리스트링

초기에 티셔츠뷰, 아웃도어뷰 거의 비슷한 코드를 두개나 만들어 if문으로 바보같이 쪼개놨던 나에게 한줄기 빛과같이 다가온 쿼리스트링이다.

외부에서 sub_category_id값에 해당하는 1,2만 넣어줌으로써 Url number값으로 항목 구분부터 filtering까지 한 번에 가능하게 만든 쿼리스트링, 검색기능에도 굉장히 많이 쓰인다는 것도 알게되어 더욱 사랑하게 된 기능이다.

Prefetch부터 to_attr까지

DB히트를 줄이기 위한 노력으로 prefetch를 사용했다. 사용하다보니 관심이 생겨서 옵셔널한 기능인 to_attr도 쓰게되었다. 이미 캐시된 데이터라 DB히트수는 변함 없지만 to_attr인자에 프리페치 연산결과를 할당해 놓음으로써 쿼리셋에 접근할 때마다 발생하는 쿼리질의 중복을 막아낼 수 있었다. 크게 어렵지 않은 옵셔널한 기능이였지만 코드의 길이단축과 쿼리효율증가를 동시에 꾀할 수 있는 멋진 기능이였다.

리스트컴프리헨션에 빠지다

코드길이단축에에 연산효율성까지 파이써닉한 대표 코드 중 하나인 리스트 컴프리헨션, 처음에는 뭣도 모르고 기능구현에만 신경쓰느라 for문으로 줄줄, 코드길이도 듬뿍 늘어났던 나에게 깔끔한 코드란 무엇인지, 파이써닉한 코드가 무엇인지 그 기초를 알려준 리스트 컴프리헨션, 이제는 리스트 컴프리헨션 없이 살 수 없는 몸이 되어버렸다.

Unit test

set_up부분까지는 더미데이터라 너무 길어서 마지막에 view_test부분만 잘라 붙였다. 현업에서는 클래스나 함수 단위에서 꼭 유닛테스트를 실행해, 혹시 모를 에러를 미연에 테스트로 방지하며 에러코드를 사전에 검증해 전체적인 코스트를 줄인다고 했다.

비록 미흡했지만 내가 구현한 전체페이지/상세페이지 뷰에 Get함수에 대한 유닛테스트를 구현했고 성공적으로 검증을 해냈다.

소회 🧐

쏜살같이 한달이 지났고, 그 보다 더 빠르게 2주가 지나갔다.
내가 지금까지 해보지 못했던 것, 남보다 훨씬 못 하는 '개발/프로그래밍'이라는 공부를 하며 느꼈던 점은 사람은 누군가의 도움이 필요한 존재라는 점이다.

내 코드 역시 에러가 났을 때 동기들에게 물었고, 구현하고싶은 기능이 막혔을때도 누군가에게 계속 물어가며 고쳤다. 모두가 바쁘고 정신없던 시간일텐데도 짜증이나 화내는일 없이 잠깐 잠깐 내 코드를 봐줬던 모든 이들에게 이 자리를 빌어 감사의 말을 전한다.

부족한 내 코드를 조금이나마 멋지게 변신할수 있게 도와주었던 위코드 11기 동기들, 그대들이 너무너무 고마웠다.