[회고] 2차 데이터 분석 웹 프로젝트 회고

오늘 막 발표가 끝난 따끈따끈한 후기

생각이 드는 부분을 얼른 메모하고 정리하면서 회고해야겠다.

프로젝트 주제

데이터 분석이 큰 주제였지만 사실상 초점에 맞춰진 것은 웹 사이트 제작이었다.

데이터 분석은 해당 웹 사이트에 대한 정당성을 부여하기 위한 수단임에 불과했다.

질문을 통해 사용자의 관심사를 뽑아내는 작업도 한 다른 팀들도 있었는데, 그 부분은 AI 부분에 가까워서 우리 팀은 시작 페이지에 그래프를 추가하는 것으로 마무리했다.

프로젝트 이전 3주간 파이썬과 pandas, matplotlib을 살짝 건든 정도 밖에 안돼서 할 수 있는 게 별로 없었다.

데이터 셋도 kaggle로 한정돼 있어서 실용적이고, 최신의 것을 반영하기도 어려워 1주차에는 그 부분이 참 아쉬웠다.

우리 팀의 경우 식약처의 데이터만 이용할 수 있었다면, 한국 웹 사이트를 만들 수 있었을텐데 그렇게 할 수가 없어서 영미권을 타겟층으로 삼았다.

그런 한계를 전부 고려하여 기획하고 개발한 것은

사용자가 섭취한 음식과 한 운동을 기록하면 칼로리를 추가, 차감하여 트래킹하는 웹사이트

언제 닫힐 지 모르지만 일단 달아놓는 링크

13팀 웹 사이트

KEEP

• 현재 만족하고 있는 부분
• 계속 이어갔으면 하는 부분

1. 짧은 주기의 스크럼

이전 프로젝트는 오전 10시 한 번의 스크럼을 진행했다가, 이번에는 오전 10시, 오후 7시 하루 두 번의 스크럼을 진행했다.

개인적인 성향으로, 자주 만나던 실시간 채팅으로던 각자의 상황을 공유하는 것이 중요하다고 생각하여 택하게 됐다. 물론 팀원분들께서도 이에 적극 동의하고 매 시간마다 열심히 참여해주셨다.

그래서 어느 한 쪽의 문제가 발생하면 그 문제가 이틀 이상 간 적이 없었다. 문제를 까먹고 전달을 못하는 일도 없고, 다른 포지션끼리 문제 상황을 빠르게 공유할 수 있어서 좋았다.

스크럼 때에는 주로 '이전 회의부터 지금까지 했던 것'-'발생한 문제점과 논의해야할 점'-'다음 회의 전까지 할 것'을 다뤘는데,

발생한 문제점과 논의해야할 점을 그때그때 기록해 남겨두니
계속해서 리마인드해줄 수 있고, 빠르게 해결된 것이 장점이었다.

2. 다양한 시도

이전 프로젝트는 포트폴리오 웹 사이트 제작으로 한정지어서 개발하여 CRUD가 정해져 있고, 하나의 것을 복사 붙여넣기하는 수준이었는데,

이번에는 단위 변환, 사용자의 칼로리 트래킹, 조건 달성 뱃지와 같은 새로운 기능을 구현했다.

처음에는 단위 변환 함수를 내가 직접 짜게되었는데, 잘 작동될 때 매우 뿌듯했다. 그런데 중간 오피스아워 때 백엔드 코치님께서 이런 건 라이브러리를 써도 좋다며 npm converts-unit을 알려주셨다.

결국엔 내가 쓴 함수 중 절반은 라이브러리로 교체되었다. 슬프지만 라이브러리를 써보는 것이 매우 중요하다고 강조하셔서 익숙해지려 했다.

하지만 이 라이브러리가 처음부터 최종 배포 전까지 말썽을 피울지는 아무도 몰랐지...

처음에는 npm install convert-units로 설치하니 convert가 제대로 import되지 않는 문제가 발생하여 npm의 github에서 beta 버전(npm install convert-units@beta --save)으로 나온 것으로 다시 설치하니 제대로 됐다.

또한 막바지에는 양방향 단위 변환 중 어느 하나에서 상수는 괜찮은데 변수가 들어가면 0이 나오는 에러가 있었는데, 결국엔 자바스크립트 자료형 문제인 것으로 밝혀졌다.

그니깐 자바스크립트에서 문자열 변수에다가 아무 수학 연산자를 적용하면 숫자형이 된다.(이때 처음 알았다)

import configureMeasurements, { mass, length } from "convert-units";
const convert = configureMeasurements({ mass, length });

const { ... weight, ... } = req.body;
convert(weight).from('lb').to('kg') // 0
convert(weight*1).from('lb').to('kg') // kg으로 변환된 몸무게
// 또는
convert(Number(weight)).from('lb').to('kg')

이외에도 npm dayjs가 우리나라 실시간 시간대를 쓰지 않는 것을 최종 배포 직전에 깨달은 점이 인상깊었다. 그 당시 새벽에 팀원들이랑 함께 화면 공유하면서 테스팅하던 중, 분명 자정이 지나서 5월 8일이 되었는데, DB에는 당당하게 5월 7일로 들어가 다같이 '엥?'을 외쳤던 게 기억난다. 그래서 임기응변으로 <date+9시간>로 수정했다.

백엔드 코치님께서 알려주신 프로젝트에서 좋은 퀄리티의 기준!

PROBLEM

• 불편하게 느끼는 부분
• 개선이 필요하다고 생각되는 부분

1. 팀장으로서 작업 배분

팀장을 할 깜냥이 되지 않아 처음엔 하고 싶지 않았지만 얼떨결에 하게 됐다. 된 김에 최선을 다했지만 팀장으로서 최선을 다하려다 보니 개인적인 역할에 있어서 아쉬움이 가장 컸던 것 같다.

우선 개인적으로 백엔드 역량이 많이 부족하여 기능 구현에 많은 비중을 차지하지 못한 것은 사실이다. 큼지막하게 운동과 뱃지 스키마 설계, 전체 DB 가공, bucket 이미지 관리, 기능 테스팅, 에러 핸들링, 배포를 했는데, 확실한 것은 주요 기능에 크게 기여하지 못했다.

다행히 다른 백엔드 팀원들덕분에 많은 기능을 무사히 구현했지만 만약 개인적으로 실력이 더 좋았다면, 고도화 기능으로 넘기고 구현하지 못한 관리자 승인, pro version, 보상 시각화, 구글로그인을 구현할 수 있지 않았을까 싶다.

또한 팀장으로서 전반적인 개발 흐름을 파악하고 우선순위를 지정하는 데에 집중했는데, 이 부분이 팀원분들에게는 다소 부담이 되었을 수도 있었을 것 같다는 생각이 든다. 개인적으로 구현에 집중하고 싶은 부분과 기획에 맞게 구현하는 것에 있어서 괴리가 생겨서 전자가 뒤로 밀리는 경우가 있었기 때문이다.

이 부분은 끝나고 나서도 고민에 있다. 결국엔 이 프로젝트도 자신의 개발 능력 향상에 도움이 되기 위한 과정인데, 거창한 기획보다 개인적으로 하고 싶은 것을 하는 게 맞는 걸까라는 생각도 든다.

하지만 또 개개인만의 욕심이 합쳐지면 웹 사이트 자체가 산으로 갈 수 있다는 위험이 있기에 섣불리 동의하긴 아직까지 쉽지 않다.

2. 에러 핸들링 및 validation

이 부분은 사실 초기부터 정해야 하는 부분이었으나 그렇게 하지 못해 기능 테스트 때 많은 시간을 낭비했던 것 같다.

만약 각 요청 및 메서드마다 에러 처리를 하고, 요청 바디 및 쿼리에 validation을 했더라면 에러를 보고 빠르게 오류를 해결할 수 있었을 것 같다.

TRY

• Problem에 대한 해결책
• 당장 실행 가능한 것

1. 에러 핸들링

마지막에는 결국 해결하지 못한 에러가 있는데, 코드리뷰를 하고 리팩토링을 하면서 제대로 찾아보고 싶다.

2. mongoDB 공부

몽고DB 완벽 가이드

만약 몽고DB에 대해 식견이 좀 더 있었더라면 기능을 구현하는 게 수월했을텐데 지금은 우회한 느낌이 없지 않아 있다.

그래서 mongoDB 쿼리나 작동 방식에 대해서 기초부터 다져서 하나씩 개선해보고 싶다.

느낀 점

• 두려움이 줄었다.
  처음에 VM으로 배포해야했을 때 오래된 내 컴퓨터로 하다가 다 망치면 어떡하지라는 두려움이 있었는데, 지난 새벽동안 몇 번의 재배포도 다져진 지금은 front build하면서 백준 문제를 푸는, 여유가 생겼다!

• 포지션을 정하는 기준을 어떻게 해야 하지
  지금까지 프론트 한 번, 백엔드 한 번을 본격적으로 했고, 원래는 잠정적으로 백엔드를 포지션으로 정하려 했으나 이젠 모르겠다. 프론트에서는 상태관리를 어렵지만 스타일 라이브러리 쓰는 것이 재밌고, 백엔드는 몽고DB는 어렵지만 DB 구조와 MVC 로직을 짜는 게 재밌다. 이제는 하나로 정해야 할 때인데, 확답을 내리지 못했다.

• DB, MVC 모델 설계의 중요성
  첫 백엔드 오피스아워 때 코치님에서 강조하셨던 부분이다. 사실 처음에는 의아했다. 지난 프로젝트 때는 이런 과정이 없었기 때문이다.(당연함 엘리스에서 다 짜줌) 개발하면서 추가되는 부분이 있으면 그때마다 더하면 되는 것이지 않나라는 생각을 했다.
  그런데 이게 진짜진짜진짜 중요하단 것을 기능 추가하면서 깨달았다.
  특히나 업적 관련 DB를 구성하는데, 단순히 user_id와 달성한 업적을 number로 단계를 넣어놨는데, 이 부분은 뱃지가 업그레이드되면 이전 단계의 것에 덮어쓰기하는 것으로 이해하여 미리 짠 것인데, 사실 그게 아니여서 후에 프론트에 보내줄 때 복잡해지는 문제가 발생했다.
  

• MVC도 마찬가지였다. 유저의 트래킹 목록을 업데이트 하는 데에 있어서 처음에는 수정할 것을 가져오고 복사한 다음, 수정한 뒤 기존 것을 삭제하고 새로 등록하는 방식을 취했는데, UX적으로 어색하여 변경했다.
  
  이 부분도 mongoDB 쿼리 이것저것 적용해보면서 공부하는 시간도 가졌다.
  

• API 문서 작성
  13팀 무지개발자 swagger
  엘리스에서 쓰면 편하다고 한 스웨거인데 갈수록 쓰는 방법을 몰라 불편했던 게 기억난다. 지금은 익숙해져서 어느 정도 쓸 수는 있지만 언젠간 import하여 스웨거로 api test도 해보고 싶다.

• mongoDB랑 조금 친해진 듯
  아주 조금!

마치며

아무튼 끝나지 않을 것만 같으면서도 쏜살같이 지나갔던 지난 3주.
많은 것을 배웠기도 하고 익숙해졌다.
이렇게 하나씩 경험을 해보면서 불편했던 것들이 편해지는 과정을 많이 겪고 싶다.

첫 프로젝트 때와 달리 이제는 git merge할 때 안 떨린다!

첫 프로젝트 때와 달리 이제는 VM 배포 안 무섭다!