2차 프로젝트 후기 - Zigbang Clone

• 데모영상 이미지 클릭

1. 2차 프로젝트 소개

대한민국 대표 주거정보 플랫폼 직방

• 백엔드_ GitHub

• 프론트엔드_GutHub

실제 직방 사이트

https://www.zigbang.com

1) 구성원 👩‍💻 🧑‍💻 👨‍💻

• frontend 3명
• backend 3명

2) 기간 📆
2020.07.06 ~ 2020.07.17(12일간)

2. 프로젝트 목적

• 스크럼 등 실무에서 사용하는 개발 방법론을 통해 협업 방식을 익힌다.

• 데이터 양이 많은 서비스를 클론하면서 데이터를 다루는 방식을 익힌다.

• 위치 정보(좌표) 기반 기능, 필터링, 검색 등 타겟 사이트 핵심 기능을 구현하며 백엔드 개발자로서 역량을 키운다.

3. 적용 기술 🛠

• Python, Django
• MySQL
• JWT, Bcrypt
• CORS Headers
• Haversine
• Unit Test
• Git, GitHub
• AWS EC2, RDS
• Docker

4. 사이트 주요 기능 및 작업 내용

다음은 구현한 사이트의 주요 기능들이다.

1) 📃 회원가입 / 로그인 페이지

• 일반 회원가입/로그인 기능
• KAKAO 회원가입/로그인 기능
• 이메일 및 패스워드 양식 확인 기능
  (이메일 중복검사, 이메일 및 비밀번호 유효성 검사)
• 회원가입시 문자메시지 인증 기능
• 토큰인증, 비밀번호 암호화

2) 📃 메인 페이지

• 찾아보기 칸에서 검색시 검색어가 포함되는 모든 데이터를 전송

3) 📃 지도 페이지

• Frontend로부터 중심좌표를 받아와 주변에 있는 매물들의 데이터들을 전송

4) 📃 매물 리스트 페이지

• 중심좌표를 통해 받은 매물들의 데이터들을 사용자가 보기 쉬운 리스트의 형태로 전송

5) 📃 매물 상세정보 페이지

• 매물 리스트에 나오지 않은 정보인 방들의 세부적인 내용들을 전송

5. 프로젝트에서 맡은 역할 💻

• DB Modeling(Aquery Tool 사용)
• Crawling(방 정보, 전국 지하철 노선정보, 강남구 일대 초중고등 학교 정보)
• Crawling한 정보 db_uploader작성
• 지도에 매물 정보에대한 데이터를 전송해주는 뷰 작성

6. 기억에 남는 코드 📝

• 중심좌표를 기준으로 일정 범위안에 들어오는 데이터들만 거르는 계산식

frontend에서 위도와 경도의 좌표를 전달해 줄때마다 전체 DB에서 주변의 매물들에 대한 정보를 검색하게 된다면 데이터의 양이 많을수록 시간도 오래 걸리고 효율적이지 않을꺼라고 생각했다.
따라서 전달받은 좌표를 중심으로 상하좌우의 좌표값들을 더하고 빼서 한 변의 길이가 약 4km인 사각형의 범위를 정한 뒤 전체 DB에서 그 부분만큼만 미리 정보를 불러온 상태에서 다른 조건들에 맞는 매물들을 필터링해서 보여주는것이 속도도 더 빠르고 효율적일것이라고 생각했다.
만약 좌표값이 들어오지 않는다면 어떤 처리를 해야할지 또한 어떻게 해야 좀 더 효율적일지 고민을 많이 했었던 부분이라 기억에 남게 되었다.

• 일정 범위안에 들어온 데이터들중에서 실제 거리가 2km이하인(지름 4km) 데이터들을 찾아낸 후 필요한 정보들을 출력하는 코드

이 부분은 위와 연결되는 부분이다. 1차 프로젝트를 하면서 select_related와 prefetch_related를 사용하면서 조금 감을 잡았다고 생각했는데 큰 오산이었다. modeling이 달라지니 마치 처음 하는듯이 헷갈리는 부분들이 생겼지만 그때보다는 조금 성장하게 된것인지 shell에서 이방법 저방법 다 시도해보며 답을 찾아 나갔다. 또한 1차 프로젝트때 고통받았던것을 기억하여 좀더 편하고 빠른 코딩을 위해 변수명들을 직관적으로 만들기에 대해 신경을 더 많이썼다.
하지만 변수명에 대해서만 신경을 쓰다보니 일단 값들은 모두 출력이 되는데 너무 복잡하고 효율적이지 않아 보였다.
list comprehension에 대해서도 이해도가 낮아 값이 출력되는 중간중간에 list형식이 끼어 들어가기도 하고 내가 생각했던것과는 완전히 다른 모양으로 데이터가 출력되기도 했다. 그래서 하루는 어떻게해야 좀더 효율적으로 정보를 보내줄 수 있을지 고민하다가 하루종일 코드를 한줄밖에 적지 못한날도 있었다.
그러다가 팀원에게 list comprehension을 2중으로 사용하는 방법을 배우고 난 뒤 점차 출력형식을 다듬어 지금과 같은 내가 원하던 형식으로 데이터를 전달해 줄 수 있게 되었다.

7. 느낀 점 🎞

1) 잘한 점 🙆‍♀️ 🙆 🙆‍♂️

미추어버린 테이블의 수

우선 이 어마어마한 양의 테이블들을 모델링 했다는것만으로도 잘한거라고 생각한다. 물론 우리가 짧은 기간안에 모든 기능을 다 구현할 수 없기 때문에 할수 있는 부분은 하고 없는부분은 기능을 구현하지 않았지만 확장성을 위해 최대한 많은양을 모델링했다. 그 결과 테이블 수가 46개나 됬다. 그리고 현업 개발자 분께 원래 이렇게 모델링이 힘든건가요 라고 질문을 드렸더니 보통 50개는 기본이라고 하셨다.... 눙물..ㅠㅠ
하지만 이렇게 데이터가 많은 사이트는 처음이라 모델링을 하면서 테이블 수가 점점 늘어날수록 우리가 제대로 모델링을 하고 있는것이 맞을까?? 불필요한 테이블이 생겨나고 있는것은 아닐까 고민도 많이 했었지만 불필요 했던 부분들도 몇가지 있어서 없애기는 했지만 필요했던 부분마저 안들어가 있었던 경우도 있었다. 다행히도 프로젝트 중간중간에 바로 확인이 되어서 추가하고 코드를 다시 수정했다.

성장하기위한 도전

이번 프로젝트를 진행 하면서 1차 프로젝트때와는 다르게 모델링에 대한 이해도 빨리되고 크롤링도 혼자 성공하는 등 프로젝트 초반에 높은 성취감을 얻을 수 있었다.
도대체 왜때문이죠...????

분명 1차 프로젝트동안 python이나 django를 많이 이해하게 된 것도 아니고 내가 작성한 코드도 이해 못했는데... 게다가 1차 프로젝트가 끝난지는 2일밖에 지나지 않았는데??

아무튼 내가 어렵다고 생각하던 것들을 하나하나 잘 해결하다보니 1차 프로젝트를 마치고 체력이 회복이 되지도 않은 상태임에도 불구하고 너무너무 재미있어서 별로 힘들게 느껴지지 않았다. 체력적으로 여유가 있는데다가 자신감도 붙어 심리적으로도 안정되니 더욱더 많은것, 어려운 것에 도전을 해 보고 싶은 생각이 들었다. 그래서 자신있게 도전한것이 무려 지도이다!!
하지만 자신있게 외치고 지도에 대해 하나하나 뜯어보기 시작하자마자 바로 좌절에 빠지게 되었다...

도대체 어디서부터 어떻게 구현해야하는것인지 하나도 감이 오질 않았고 너무나도 어려웠다.
직방이 지도와 위치를 기준으로 집을 보여주는데 당연히 쉬울리가 없지..
이 기능을 구현하기위해 구글링도 정말 많이하고 생각도 많이 했다.
그 결과 데이터가 나오기 시작했다!!! 문제는 정말 데이터가 나오기만 한다는 것이다.
가독성과 효율성은 내다버린 코드가 탄생했다(우와!!)
테이블간의 관계때문에 데이터의 형식이 쿼리셋이었기 때문에 for문을 계속 사용해야만 했는데 갑자기 코드 중간에서 사용할수는 없으니 list comprehension 을 사용했는데 갑자기 데이터 출력 중간에 list가 나와서 왜그러는걸까 고민을 많이했는데 이유가 list comprehension 때문이었다. 그 전까지 나는 그냥 for문을 한줄로 사용할수 있게 해주는 편리한 방식이라고 생각했는데 그것도 맞지만 출력형태가 말 그대로 list로 나오는 것이었다. 어떤 기능을 하는지도 모르면서 그냥 막 사용하는 바보같은짓을 하고있었던 것이다.
그래서 list comprehension을 사용하면 안됄것 같아서 그 부분을 다 지우고 그때부터 다시 데이터를 어떻게 출력해야할지에 대해 고민에 빠졌다.
하루는 어떻게 해야할지 고민만 하다가 10시간동안 코드를 한줄밖에 작성하지 못했던 날도 있었다. 물론 그 코드도 원하던대로 나오지 않아 결국 지우게 되었지만...
그렇게 고민하기 2일째에 팀원이 나에게 해결책을 알려주었다. 그것은 아이러니하게도 바로 list comprehension!! 쿼리셋 형태를 풀기위해 테이블에 따라 2중 혹은 3중 for문까지 필요한 상황이 있었는데 list comprehension 안에 2중으로 for문을 사용 할 수 있다는 것을 나에게 알려주었고 그 방법에대해서도 공부하고 적용한 결과 정말로 내가 원하던 깔끔한 형식의 데이터가 출력이 되었다.

2) 아쉬운 점 🙅‍♀️ 🙅 🙅‍♂️

Unit Test

이번 프로젝트를 하면서 유닛테스트에대해 배우고 처음으로 적용하게 되었는데 너무 어렵고 이해가 잘 되지 않았다.
유닛 테스트에 대한 형식이 있는건지 어떤 내용을 테스트 해야하는지 제대로 알지 못한채로 테스트를 작성하게되니 더욱 어렵게 느껴졌던것 같다.
나중에 알게된 내용이지만 원래는 view를 작성하기전에 test코드를 작성하는것이 맞는 순서라는 것을 배웠다. unit test를 기반으로 view를 작성하는거라고 들었는데 사실 그 이야기도 이해가 가지 않는다.
어떤 값이 어떤 형태로 들어가야할지도 모르는 상황일꺼라고 생각하는데 바로 테스트를 한다니.. 아직 감이 오지 않아서 따로 연습을 해봐야 할것 같다.

코드 연산속도

처음에는 약 1600여개의 오피스텔 매물만 db에 저장해서 프로그램을 돌리고 있었고 프론트와의 통신에서도 문제가 없었다. 그런데 생각보다 기능구현에 필요한 코드들이 빨리 나오게 되었고 새로운 기능을 추가하기엔 시간이 모자라서 db의 양을 늘리기로 결정해서 처음의 두배의양인 약 3300개의 데이터들을 가지고 다시 통신을 하기 시작했다.
그러자 문제가 생기기 시작하였다. 나름 효율적이게 코딩을 하려고 노력했다고 생각했는데 데이터가 많아지게되니 데이터들이 업로드 될때 조금씩 렉이 걸리기 시작했다.
사실 비효율적인 연산이 문제인지 아니면 다른것이 문제인지는 정확히 알지 못하지만 내 코드가 아직 효율적이고 수준이 높지 않아서 이런 경우가 생겼다고 생각하는 것일지도 모른다.
이 부분도 역시 공부를 더 하면서 어떻게 해야할지 고민을 많이 해봐야 할 것 같다.