특화 프로젝트도 반년만에 돌아왔다.
싸피에서 코치를 한 것도 벌써 3개월이 지나고 있다.
공통프로젝트를 성공적(?)으로 마치고 특화 프로젝트를 진행하고 있는 중, 특화 프로젝트도 이제는 정리할 때가 오지 않았나 생각되어 회고를 정리해보려 한다.
팀빌딩
지난 공통 프로젝트에서 예상과는 너무 달랐던 3등을 하고, 팀원들 모두 1등을 하겠다는 강한 의지가 있었다. 이 생각 때문인지 특화 프로젝트도 같은 팀원들로 진행하게 되었다. 물론 팀장도 그대로였다.
공통프로젝트 회고
결국 1등을 하지 못했기 때문에 더 나은 프로젝트를 만들겠다는 생각으로 공통 프로젝트에서 더 나아질 부분과 잘했던 부분을 고민했다.
잘했던 부분
- 반응형 웹
- 다크모드
- JPA
- S3
싸피의 특성상 특히 반응형 웹이 반응이 좋았다. 또, 다크모드를 적용하면서 큰 호응을 얻을 수 있었다.
백엔드에서는 다양한 기술 스택을 처음으로 접해볼 수 있었다. NGINX나 S3, JPA가 그랬다.
더 나은 프로젝트 만큼이나 더 많은 경험을 원했기 때문에 이번 프로젝트에서도 다양한 기술스택들을 사용하길 원했다.
더 나아질 부분
- 발표
- 기획/설계
팀원들은 발표에 대해 매우 호평했지만, 우리가 고생한 것들을 잘 보여주지 못했다는 생각이 계속 들었던 것 같다. 우리가 진행한 프로젝트를 더 효과적으로 보여주려 노력했다.
또, 기획은 좋았지만, 이에 대한 당위성을 얻기 힘들었고, 설계 과정에서 볼륨을 적절하게 조절하지 못해 전체적인 일정에서 무리가 컸다.
트랙 선택
공통 프로젝트였던 챌림픽에서 사용자별 맞춤 추천을 구현하려 했으나, 데이터도 부족했고 기술도 정확히 알지 못했다. 그래서 "추천 시스템을 제대로 만들어보자!"라는 생각으로 [빅 데이터 추천] 트랙을 선택하게 되었다.
기획
다만, 주제에 대해 생각할수록 기존의 주제를 더 발전시키기에는 어려움이 많았다. 추천을 위한 데이터가 턱없이 부족하다는 것이 특히 그랬다.
주제를 먼저 정하고 데이터를 찾으면 없는 경우가 부지기수였고, 데이터를 먼저 찾으면 마땅히 차별점 있는 주제를 만들기가 어려웠다.
결과적으로 선택된 주제는 "보드게임 추천"이였다.
크롤링을 통해 Board Game Geek이라는 유명 사이트에서 사용자의 별점 데이터를 가져올 수 있었고, 보드게임을 "추천" 해주는 사이트는 없었기 때문이다.
이렇게 크롤링을 진행하면서 총 300개의 보드게임에 대한 30만명의 유저, 580만개의 별점 데이터, 250만개의 리뷰데이터를 확보할 수 있었다.
(이후 코치를 하면서 다른 반에서 보드게임 추천을 주제로 정했다는 얘기를 들었으니... 그다지 특색은 없었을지도...)
설계
이전 프로젝트에서 반복적인 CRUD 때문에 고생했기에 잘 드러나지 않는 부분은 과감하게 제거하려 노력했다. 특히 프론트엔드에서 너무 많은 페이지와 컴포넌트로 고생했기에 핵심 페이지 위주로 구현할 수 있도록 설계했다.
또, 백엔드에서는 Django를 통해 추천 시스템을 만드는데 집중할 수 있도록 했다.
개발
다행히도 이번 설계는 규모를 잘 잡았던 것인지 큰 무리없이 개발을 진행할 수 있었다.
두번째 프로젝트여서인지 개발 속도 또한 눈에 띄게 빨라진 모습을 볼 수 있었다. 중간에 추석이 있었음에도 큰 무리없이 일정에 맞춰 개발을 진행할 수 있었다.
다만...
최종발표 이틀전,
문제가 발생한다. 이전까지 잘 동작하던 메인 페이지가 갑자기 1분이 넘는 정도의 어마어마한 시간이 걸리기 시작한 것.
해당 문제가 발생하는 원인을 다음과 같이 생각할 수 있었다.
- 사용자들이 별점을 줄 때마다 새로 추천 데이터를 만들게 된다.
- 새로 적용한 알고리즘 중 하나가 너무 오래 걸린다.
- 프론트엔드에서 모든 API를 호출하여 데이터를 받은 후(await) 출력하기 때문에 전체 페이지를 로드하는데 너무 오랜 시간이 소요된다.
결국 이를 해결하기 위해 다음과 같은 해결 방안들을 생각하게 된다.
- 메인페이지에서 데이터를 한번에 가져오는 것이 아닌, 각각의 데이터를 따로 가져오도록. 먼저 불러온 데이터를 먼저 제공하여 데이터 로딩 체감을 줄이자.
- 너무 로드가 많이 걸리는 추천 방식을 과감하게 제거
- 추천 데이터를 매핑하여 DB에 저장하고, 이를 불러오는 방식으로 구현
- 스케줄링
- 하둡과 스파크를 통한 분산 시스템 구현으로 속도 최적화
이 방법들 중 1,2,3,4번을 적용하여 문제를 해결할 수 있었는데, 각각
- 모든 데이터가 불러와진 후에 로딩을 멈추고 전체 데이터를 출력하던 것을 수정하여 우선적으로 불러와진 데이터를 먼저 제공하였습니다. 비교적 시간이 오래 걸리는 데이터의 경우 하단에 제공하여 로딩에 대한 체감을 줄일 수 있었습니다.
- 추천 데이터 중 평점/별점수로 데이터를 제공하였는데, 해당 연산이 생각 이상으로 오래걸려 제거하고, 평점만으로 데이터를 전달하였습니다.
- 제공하는 게임의 수를 300개로 제한하였기에, 각 게임에 대한 추천 게임들을 매핑할 수 있었습니다. 모든 게임에 대한 추천 게임들을 20개씩 매핑하여 저장하였고, 이를 Springboot에서 바로 전달받아 제공하였습니다.
- 사용자가 평점을 주는 시점이 아닌, 관리자가 일정 시점에 사용자 추천 데이터를 갱신하는 api를 호출하여 데이터를 갱신한다.
아쉽게도 프로젝트 기한이 많이 남지 않은 상황이였기에 하둡이나 스파크 같은 기술은 사용하지 못했다.
또한 스케줄링을 통해 자동으로 갱신하는 것도 완성할 수 없었다.
하지만 이 과정에서 스프링 스케줄러에 대해 배울 수 있었고, 스프링 배치의 필요성 또한 알 수 있었다.
스프링 스케줄러를 통해 사용자의 추천 데이터를 한번에 처리할 수도 있겠지만, 스프링 배치를 활용해서 서버에서 한번에 처리하는 호출을 지정하고, 순서대로 처리할 수 있게 한다면 사용자의 입장에서도 더 편리하게 서비스를 사용할 수 있을 것이다.
배포
지난 프로젝트에서 손수 수동으로 배포하면서, 특히 프로젝트의 후반부에서, 백엔드 개발은 거의 신경쓰지 못하고 배포 기계처럼 시간을 뺐겼던 기억이 있었다. "이번엔 안되지"하는 생각과 "더 좋은 기술!"을 외치며 이번에는 자동배포를 구현하겠다 천명하게 된다.
거기서부터 문제였나...?
도커로 배포 환경을 로컬에서도 적용하며 배포 과정에서 별다른 추가사항 없이 빌드할 수 있도록 구현하려 했으며, 젠킨스를 통해 자동으로 빌드 및 배포하여 배포에 대한 로드를 최소화 할 수 있었다.
배포와 관련한 내용은 이전 아티클에서 자세히 다루었다.
발표
이전 발표가 너무나 아쉬웠던만큼 발표에 더 많은 시간을 할애했다. 더 각잡고 장표를 만들고, 팀원들에게 수십번, 프로님, 컨설턴트님, 코치님에게 몇번을 피드백 받으며 팀원들이 고생한 내용들을 어필하기 위해 노력했다.
특히나 피드백을 받은 부분들은 큰 도움이 되었다.
발표를 만들면서 시선이 둔해지고, 결국 내부적인 피드백으로는 잡을 수 없는 영역이 만들어진다. ppt의 구성들이 대표적인 예시라고 생각한다.
외부의 시선으로 발표의 퀄리티를 굉장히 크게 높힐 수 있다.
이걸 크게 느끼는 부분이 교육생들의 발표 피드백을 하고 이후 발표를 볼 때인데, 피드백을 받은 팀과 받지 않은 팀의 차이가 눈에 띄게 벌어진다.
같은 피드백을 받은 교육생의 입장에서도 자신들이 피드백 받은 부분들이 고쳐지지 않은 발표를 보았을 때 당연히 평가가 박해질 수 밖에 없다.
(그러니까... 혹시라도 교육생이 본다면... 제발 피드백 요청좀 해줬으면 좋겠다.)
결과
아니왜????
이번에도 1등은 실패했다. 분명히 더 좋은 프롲게트를 만들었다고 생각했는데, 아쉽게도 2등이라는 결과를 받을 수 밖에 없었다.
여전히... 음... 특화 프로젝트 결과는 받아들이기 어려운 것 같다.
회고
결과적으로는 2등이지만, 팀 내에서 상당히 만족스럽게 만들었던 프로젝트라고 생각한다. 전반적으로 완성도도 높일 수 있었고, 드디어 도커를 사용해보면서 자동 배포를 성공했을 때 그 짜릿함을 잊을 수 없다.
내새끼 2호다.
코치로서
글을 쓰는 시점으로 아직 특화 프로젝트가 끝나지 않았지만, 처음 접하는 기술 스택을 알려줘야 한다는 것이 굉장히 큰 부담이다.
아주 간단하게나마 블록체인을 경험해보았고, 빅데이터는 추천이긴 하지만 어떻게 되지 않을까? 하던 생각은 이미 지워지고 질문이 들어오면 같이 찾기 바쁘다.
그래도... 여러 기술을 접하는 것 자체는 굉장히 좋은 느낌이다.
특히 이전에는 새로운 기술을 배우기 위해 블로그를 찾고 있었다면, 최근에는 공식 문서를 찾으면서 더 빠르고 확실하게 답변을 찾아가고 있다.
