현재 개발을 공부하고 있는 위코드에서 1차 프로젝트를 진행했습니다. 위코드를 시작한지 27일차부터 39일차까지 약 2주 간 스타일쉐어 클론을 진행했는데요, 저는 당연하게도 백엔드 부분을 맡아서 진행했습니다.
이번 프로젝트는 10대 ~ 20대 여성을 주요 고객으로 가진 SNS & 커머스 서비스인 스타일쉐어를 클론하는 프로젝트였습니다. 처음 하고 싶은 프로젝트를 생각해보는 단계에서 주변 개발자분들에게 문의를 해봤는데, 백엔드 개발자가 되는데 커머스와 SNS를 경험해보는게 좋다고 하더군요. 그래서 제가 아는 서비스 중 이 두 가지를 모두 충족하는 스타일쉐어를 프로젝트 아이디어로 제시하게 되었고, 다행히 선정되어 팀장으로 프로젝트를 진행할 수 있었습니다.
개발 인원은 프론트엔드 개발자 4명, 저를 포함한 백엔드 개발자 2명이었고, 약 2주간 개발을 진행했습니다. 개발 깃허브는 아래에서 확인하실 수 있습니다.
데모 영상은 아래에서 확인하실 수 있습니다.
적용 기술은 아래와 같습니다. 세부 기능 구현은 위의 깃허브에서 확인해보세요! ERD와 API 문서도 확인하실 수 있습니다.
- Python, Django web framework
- Beautifulsoup, Selenium
- Bcrypt
- JWT
- KAKAO social login
- MySQL
- AWS EC2, RDS, S3
- CORS headers
프로젝트에서 맡은 역할
팀에서는 팀장으로서 Scrum 방식으로 프로젝트를 진행하고, 백엔드로서는 대부분의 기능 구현에 참여했습니다.
- Store 브랜드, 상품정보 크롤링(OOTD는 개인정보 이슈가 있어서 크롤링하지 않음)
- 프로젝트 초기 세팅
- 기본 회원가입 / 로그인 모델, 뷰 작성
- 카카오 소셜 로그인
- 데이터 모델링
- 상품을 제외한 모든 모델 작성
- 상품 상세, 로그인 실시간 체크를 제외한 모든 뷰 작성
- Mysql DB 구축 및 데이터 업로더 제작
- AWS EC2 서버 배포
- AWS RDS 구축
- AWS S3 구축 및 이미지 업로더 연결
잘한점
- 데이터 모델링을 프로젝트 초기에 잘 잡아놔서 이후 모델 작성이나 뷰 작성에서 문법적인 문제 말고는 별다른 이슈가 없었음
- 크롤링을 어느정도 선에서 멈춘 것. 프로젝트 자체가 모든 데이터를 그대로 보여주기 위함이 아니라 기능을 구현할 수 있다는 걸 보여주기 위함이므로 특정 카테고리만 크롤링하고 나머지는 진행하지 않았음
- PostMan으로 API 문서를 작성하면서 진행해서 프론트엔드 개발자들과 소통하는데 편리했음
아쉬운점
- 기간 상의 문제로 모든 기능을 구현해보지 못하고 취사선택을 해야했음
- 성능에 대한 부분은 크게 생각하지 못했음. 일단 기능을 구현하는데 신경을 썼고, 실제 쿼리가 돌아가는 속도에 대해서는 select_related, prefetch_related를 고려하는데 그쳤음
- 여러 기능을 작성해보고 싶어서 한 기능에 대해 깊이 들여다보지는 못했음
해결/개선 방법
- 쿼리 속도를 테스트하는 방식을 미리 숙지하고 각 코드를 완성한 후 코드의 효율성에 대해 고려해보겠음
- 프론트와 원하는 기능에 대한 협의를 하고, 정말 제대로 파보고 싶은 기능은 제대로 만들어보겠음
기록하고 싶은 코드/함수/로직
1) 스타일 뷰
가장 공수가 많이 들어갔던 코드가 이 스타일 뷰 였습니다. SNS의 메인 요소이기도 했고, 스타일을 참조하고 있는 여러요소들과의 관계를 생각해서 효율적인 코드를 작성하는게 중요했습니다.
스타일을 참조하고 있는 이미지 URL 리스트, 연관 아이템, 댓글, 컬렉션_스타일들을 처음에는 각각의 테이블에서 시작해 현재의 스타일 아이디를 이용해서 원하는 정보를 가져오는 방식으로 짰었습니다. 하지만 이런 방식으로는 각 정보를 가져올 때마다 새로운 쿼리를 불러와야하고, 말이 관계형 관계지, 효율성은 따지지 못한 관계였습니다.
스타일과 관련된 모든 정보를 스타일 객체를 시작으로 불러올 수 있다는 걸 새삼 깨닫게 되고, 이점을 이용해 코드를 작성했습니다. 특정 스타일 객체를 불러올 때 연관된 테이블 데이터들을 prefetch_related로 캐싱해두고, 각각의 데이터를 불러올 때 사용했습니다.
이렇게 하니 코드도 훨씬 간결하면서 가독성이 좋아지고, 효율성면에서도 좋아졌다고 생각합니다. 앞에서 말했듯이 직접 속도를 측정하면서 하지는 않아서 기회가 되면 실질적인 차이를 비교해봐야겠습니다.
그리고 프로젝트 막바지에 is_like와 is_following이라는 정보를 추가해서 프론트에 제공했는데, 이 정보가 없으면 뷰 자체에서는 현재 유저가 좋아요를 하고 있는지, 팔로우를 하고 있는지 체크는 되지만 정작 프론트에서는 현재 상태에 대한 정보를 알 수 없다는걸 깨달았습니다. DB에서 True, False만 파악하면 되는게 아니라 실제로 프론트에 영향을 미칠 수 있는 정보까지 제공해야한다는 점을 여기서 깨달아서 좋았습니다.
2) 팔로잉 카드 뷰
팔로잉 카드 뷰는 현재 내가 팔로우하고 있는 사람들의 게시물을 최근 순으로 뿌려주는 뷰 입니다. 여기서 만났던 문제점은 팔로우하고 있는 사람들의 리스트는 뽑을 수 있겠는데, 이 사람들이 올린 스타일 카드를 각각 필터링해서 정렬하는 방법을 알지 못했습니다. for 문을 돌려서 각자의 카드 리스트는 뽑아도, 이건 이미 객체로 변환된 다음이라 이 결과물들을 최신순으로 정렬하지 못했습니다.
이런저런 방법을 다 써보다가 어렴풋이 리스트를 기준으로 필터를 할 수 있는 방법이 있지 않을까 하고 찾아봤더니 방법이 있었습니다. 찾고 나서 기쁘기도 했지만 좀 허무하기도...
아직 장고의 모든 기능을 알지 못하다보니 이런 부분에서 막히는 부분이 있는 것 같습니다. 시간이 되는 한에서 문서를 좀 더 읽어보면 이후 프로젝트에서도 도움이 되겠죠!
3) 인기 카드 뷰
여기서 배웠던 부분은 annotate 기능 입니다. 원하는 변수를 주석처럼 ORM 안에서 처리하고, 이 변수를 이후 처리 과정에서 활용할 수 있다는 점이 신선했습니다. ORM을 만든 당신은 천재...
각 계정에 악보를 저장할 수 있게 해서 이런 문제를 해결하고, 위키 형식으로 (Ultimate Guitar에서 여러 악보를 제공하듯이) 사용자가 직접 컨텐츠를 생산할 수도 있게 하고 싶었다.
그렇게 진행하던 와중에 문득 '코드에는 저작권이 없나?' 라는 생각이 들었고...
찾아본 결과 저작권으로 인정된다는 사실을 알게 됐다. 다만 저작권 위반의 경우 친고죄이므로 사실상 현재 공유되고 있는 코드들은 암암리에 공유되는 것이었다. (앞서 언급한 Ultimate Guitar의 경우 직접 음반제작사와 계약을 진행하는 것 같다.)
범죄를 저지를 순 없었다...
그렇게 새로운 아이디어를 떠올려 보았다. 간단한 팀 빌딩 서비스다. 스터디, 해커톤, 토이 프로젝트 등 다양한 IT 프로젝트들의 가장 큰 난관은 바로 함께 할 팀원을 구하는 문제가 아닐까. 최대한 UI UX를 신경써서 빠르게 팀을 구성할 수 있는 서비스를 만들어보고자 한다.
로고 만들기
상단의 기타 모양 로고는 폐기된 아이디어에서 사용할 로고였다. 서비스 이름은 일단 코드 101로 정했다. 그래서 기타 바디 모양을 형상화하여 101이라는 숫자를 자연스럽게 넣어봤다.
하단에 보이는 것들이 이번 프로젝트에서 사용 할 로고를 만들어본 흔적이다. 서비스 이름은 팀빨 (팀 빨리 만든다는 뜻 ㅎ) 이고, 한글 ㅌ과 ㅃ을 이용해서 이것저것 해보다가 우측 하단의 시안으로 결정했다.
와이어프레임 짜보기
피그마로 혼자 와이어프레임을 짜보는건 처음이라서 굉장히 두서없이 손에 잡히는대로 작업중이다. 일단 최대한 간단한 형태로 완성을 시킨 다음 기능을 추가할 생각이다. 아무래도 팀 빌딩이다보니 개인의 프로필을 어떻게 만들것이냐가 중요할 것 같다. 그래서 회원가입 부분의 설계를 고민중이다.
뭘로 만들까
특히 백엔드에서 고민이 많았는데, 일단은 프론트엔드는 React (Next.js) 백엔드는 NestJS (Express)를 사용할 것 같다. 사이드이니만큼 최대한 도전적으로 안써본 것들을 써보려 한다.