[Memoir] 생각이 안 날땐 왔썹!

💭 프로젝트의 시작

개인의 취향대로 재료를 선택하여 먹는 커스텀 푸드가 많이 있다. 하지만 커스텀 푸드를 흔히 접하지 않은 사람들은 본인의 취향보다는 검색을 하여 사먹는 경우가 많다. 이런 상황은 지금 하고 있는 스터디에서도 볼 수 있었다. 서브웨이 주문 전, 많은 친구들이 서브웨이 꿀조합을 검색하거나 다른 친구들의 레시피를 그대로 주문하는 경우가 많았다. 이에 꿀조합 정보들을 가지고 직접 필요성을 느낀 부분과 사람들의 사소한 불편함을 해결하고자 5명(🦦, 🦎, 🍁, 🐋, 🍑: 나)이 서브웨이 꿀조합 Picker프로젝트를 진행하였다.

🤔 프로젝트 목적

• 프론트엔드로서 여러 라이브러리 경험 및 실력 향상
  프론트엔드에는 여러 가지의 라이브러리와 프레임워크가 있다. 그 중 React는 여러 패키지와 레퍼런스가 많은 만큼 프론트엔드로서 성장하기 위해 알고 있어야하는 라이브러리 중 하나이다. 이에 React를 기반으로 타입 오류를 체크하기 위해 Typescript, React 자체 라이브러리 Recoil을 사용하여 전역 상태를 관리, CSS-in-JS 방식의 emotion을 채택하였다.

• 새로운 컨벤션 수립 및 준수 : 집현전 프로젝트
  꿀조합처럼 영어로 변수명을 정하기 어려운 비즈니스 로직에 한글 컨벤션으로 적용하여 개발을 진행했다. 한글을 쓰는 것이 어색했지만 상황에 따라 컨벤션에 적응 및 준수하는 것도 개발자에게 필요한 역량이니 좋은 아이디어라고 생각했다. 하지만 막상 시작했을때 setState, title 등과 같은 경우 영어가 익숙하다보니 변수명을 어떤 걸로 설정할 지 고민이 되었다. 또한 중간중간 팀원들과 비즈니스라고 하긴 애매한 부분까지 한글 컨벤션을 적용시킬지에 대한 논의도 많았었다. 그러다보니 비즈니스 로직을 개발할 때보다 변수명 고민으로 시간을 더 많이 쓰기도 했다. 그렇지만 그 부분 덕에 좀 더 완고한 컨벤션을 수립하고 준수할 수 있었다.

  왔썹 - 집현전 프로젝트 문서 보러가기

🔍 프로젝트에서 배운점 및 좋았던 점

• 타입 오류 체크, Typescript
  이번 프로젝트를 통해서 Typescript 실력이 향상됨을 느꼈다. 인터페이스 타입 확장하여 사용하고 타입과 인터페이스를 사용하는 규칙을 정하여 혼돈이 없도록 하며 event에 대한 타입은 이벤트 타입과 함께 target tag를 명시해줌으로써 코드의 변수, 반환값등에 대해서 더 빠르게 파악할 수 있었다. 아쉬운 점이라면 제네릭을 사용해보지 않았다는 것이다. 하지만 이는 앞으로 프로젝트를 하면서 보충하는 것으로 아쉬움을 달래본다.
  
  

• 직접 부딪히며 알아가는 Webpack 설정 without CRA
  CRA없이 Webpack을 구성하여 React를 실행하고 빌드하는 프로젝트. 기존에 자바스크립트로만 구성된 프로젝트와는 다르게 리액트와 타입스크립트 등 관련 웹팩 설정을 추가해줘야한다. 설정하면서 신기했던 점은 다양한 방법으로 같은 설정을 해줄 수 있다는 것이였다. react를 해석하기위한 설정을 할 때였다. 나는 babel-loader의 presets에 @babel/preset-react를 추가하고 typescript의 컴파일 단계를 웹팩과 통합하기 위한 ts-loader를 사용하고 있었다.

  // webpack.confing.js : babel-loader의 presets부분
  {
    "presets": [
      "@babel/preset-env",
      "@babel/preset-react"
    ]
  }

  하지만 다른 팀원이 짜온 코드를 보는데 "@babel/preset-react" 대신에 ts.confing.json안에서 "jsx": "react-jsx" 이 설정을 해줄 수 있다는 것이였다. 이걸 보면서 참 쉬우면서도 어렵고 어려우면서도 쉽다. 이런 과정과 고민들을 거쳤기에 CRA가 미리 webpack에 대한 설정을 하는 구나라는 생각이 들면서 다시 한번 프레임워크나 라이브러리가 만들어진 이유를 깨닫게 되었고 웹팩의 코드를 분석하면서 여러 방법들을 알아놔야겠다.
  
  

• 웹 서비스를 위한 최적화
  프론트 엔드의 최적화는 웹 서비스를 다양한 사용자에게 빠르게 콘텐츠를 제공하기 위한 성능 향상이라고 생각한다. 최적화하면 사실 이미지 정도로밖에 고려를 못 했었고 아는 것도 그 정도였다. 하지만 웹 접근성과 CSR 방식에 대해 알게 되어 WAI-ARIA를 사용하여 웹 접근성을 높이고 React lazy와 같은 코드 스플리팅, meta 태그에 대한 SEO 등에 대해 배울 수 있었다. 또한 SEO에 대해 찾아보다 react-snap 라이브러리로 pre-rendering하는 방법도 있다는 것을 알게 되었다. (이는 프로젝트에 적용하지 않았지만 나중에 사용해보면 좋을 것 같다) 아래는 lighthouse와 webpack-bundle-analyzer를 사용하여 최적화가 잘 적용되었는지 확인한 결과이다.
  
  최적화 전의 캡처가 없는 점이 아쉽지만 확실히 위의 사진과 같은 방법을 통해 최적화가 잘 이루어진 것을 확인할 수 있었다. 이렇게 다양하게 최적화를 체크할 수 있는 방법을 활용하여 사용자에게 좋은 성능의 서비스를 제공할 수 있도록 공부해야겠다.
  
  

• 협업을 위한 방법론 : BDD & SDD
  

협업시 중요한 점 중 하나는 서비스 기능에 대해서 공통된 이해를 하는 것이다. 브레인스토밍의 일화를 예시로 들자면, 랜덤 추천 기능 논의시 나는 서브웨이 꿀조합 중 하나를 랜덤으로 한다고 생각했는데 다른 팀원은 재료들 모두 랜덤으로 조합해서 추천을 하는 것이라고 생각했다. 이 일화만 보더라도 기능에 대해서 모두가 같은 생각을 할 수 있도록 문서로 기록할 필요가 있었다.
이에 BDD와 SDD에 따라 기능과 데이터로 세분화하여 정의하는 법을 배워 작성였고 서비스에 대해 충분히 이해하는 시간을 가질 수 있었다. 프로젝트를 진행하면서 또 완료된 이후에 기능 테스트에 참고할 수 있어 탄탄하게 점검할 수 있었다. 또 개인적으로는 개인 파트외에는 코드만으로 짐작하기 어려운 로직들이 있었는데 해당 문서를 읽으며 파악하니 쉽게 이해할 수 있었다.

• 팀원들과의 소통 방법
  

이번 프로젝트는 온라인으로 주로 소통을 했었는데 팀원 소통의 1등 공신은 gather와 liveShare라고 생각한다. 공통 컴포넌트 혹은 커스텀 훅을 사용하면서 정기 회의 외에 논의해야했고 장소와 시간의 부족으로 온라인 소통이 필요했다. gather로 팀원과 실시간 소통을, liveShare는 코드를 공유하여 개발의 방향성과 문제점을 파악할 수 있었다. 한달간 개발하면서 오프라인 6번, 온라인 15번 이상이라고 할 정도로 온라인 소통을 활용하여 좋은 결과와 함께 프로젝트를 마무리할 수 있었다. 무엇보다 시간과 공간의 제약이 없어 개발에 집중하고 에너지를 쓸 수 있다는 점이 가장 좋았다.

🚨 시행착오!

• InterSection Observer API 무한스크롤

  • 상황
    • 마지막 li를 observer하여 그 다음 정보를 서버에 요청하도록 처리
  • 문제
    • 첫번째 마지막 li는 observer하지만 그 다음 마지막 li를 observer하지 못함.
    • 위의 문제 해결 후, 서버에 있는 모든 리스트를 불러 왔지만 계속 서버에 요청하는 오류 발생
  • 해결
    • ref를 함수로 넘겨주어 마지막 li가 생길때마다 InterSection Observer API를 생성하여 observer.
    • observer가 서버의 모든 리스트를 불러왔는지 모르기 때문에 생긴 이슈로 서버에서 처음 리스트를 요청할때 전체 count를 알도록 알고 현재 리스트의 수와 비교 후 observer를 중단하도록 코드 수정

• 랭킹리스트 좋아요 버튼 클릭 후, 순위 변경 처리

  • 상황
    • 좋아요 버튼 클릭 -> 좋아요 수 증가 -> 순위 변동
    • 좋아요 수가 서버와 항상 일치하지 않고 어느 정도의 유효 범위를 허용해도 된다고 판단하여 클라이언트단 전역과 서버단의 좋아요 수를 일치하도록 각자 관리
    • 무한스크롤은 사용하여 1번 요청시 서버에 랭킹리스트 10개씩 가져오도록 설정.
  • 문제
    • 랭킹리스트를 10개씩 갖고 오는 상황에서 좋아요 수를 해제했을 때 현재 서버에 요청해서 갖고 온 리스트보다 뒤쪽 순위가 되는 경우
  • 해결
    • 변하지 않는 부분, 즉 순위가 올라가는 경우는 클라이언트단에서 처리, 그 외 순위가 내려가는 겨우에는 서버에서 정보 요청하여 처리.

• 랭킹리스트 좋아요 버튼 광클시 또는 여러명이서 클릭했을시 오류

  • 상황
    • 여러명이서 누르거나 광클시 Firebase 요청 실패
    • 좋아요 숫자가 1이상으로 커지거나 작아지는 가는 현상
  • 문제
    • 여러명 클릭시 Firebase 초당 요청 횟수 제한에 걸려 요청 실패.
    • 커스텀 훅의 좋아요 수를 랭킹 리스트 상태의 좋아요 수로 저장을 하다보니 최신 snapshot을 기준으로 값을 바꾸는 것이 아니라서 나타난 오류.
  • 해결
    • 클라인언트와 서버의 리스트가 매번 같은 상태로 유지되는 것이 아니라 일정 시간이 지났을 경우에만 동일하게 업데이트. 그 외에는 클라이언트 단의 정보 값으로 순위 변경.
    • 커스텀 훅의 좋아요 수가 아닌 랭킹 리스트 상태의 snapshot을 기준으로 증감.

🍑 프로젝트를 마치며

한달간 몰랐던 부분들, 알았던 부분들을 다져가는 시간을 가질 수 있었다. 5명이서 일상 생활에서 아이디어를 얻어 프로젝트를 진행한 만큼 여러 의견을 나누며 프로젝트를 다져간 것이 재미있었다. 그에 따라 결과물도 만족스럽게 나와 뿌듯하였다. 무엇보다도 직접 컨벤션을 세세하게 정하고 배포를 위한 설정을 하나하나 하면서 Typescript와 Webpack에 대해서 많은 공부를 했던 프로젝트여서 의미있는 시간이였다.

😎 직접 사용해본 후기를 전합니다!

프로젝트가 끝나고 친구와 함께 서브웨이를 방문했다. 직접 사용자의 입장이 되어보기로 한 것이다!! 서브웨이를 자주 사용해봤기 때문에 재미를 위해 꿀조합보다는 랜덤 조합으로 메뉴를 결정하기로 했다. 결과는... 두근두근!!!

비엘티 샌드위치에 머스타드와 홀스래디쉬의 조합이였다. 하지만 안타깝게도 허니 머스타드가 SOLD OUT 상태였다ㅠㅠ. 그래서 평소먹던 스위트 어니언으로 대체해서 먹어보았다.

홀스래디쉬가 매콤한 맛이라서 긴장했는데 오히려 단맛과 잘 어우러지고 소스의 느끼한 맛이 없었다. 또 다음번에 홀스래디쉬 소스를 먹어보고 싶다라는 생각이 들었고 왔썹덕에 새로운 맛을 알게 되어서 아주 만족스러운 후기를 적을 수 있었다.

p.s
주문하러가는 길에 랜덤 조합을 여러 번 시도했는데 생각보다 한가지 메뉴가 자주 나오는 것을 느꼈다. Math.random이 고른 경우의 수를 발생시키지 않는다고 하던데 이 부분을 나중에 업데이트할 시점이 온다면 고려해봐야겠다.