[회고] 유튜브 댓글 분석 서비스 프로젝트 후기
유튜브 댓글 분석 서비스의 이런저런 변화과정을 담은.. 후기!
일단 냅다 사이트 주소부터 올리고 시작합니다
💻 첫 프로젝트
컴퓨터공학과 졸업작품으로 진행하게 된 프로젝트였다. 당시 웹 개발은 처음 접했기에 정말 서투른 점이 많았다. 별도의 프론트 프레임워크없이 VanillaJS + Bootstrap로 개발하였는데.. 결과물은 허접 그 자체였다.
그래도 이 프로젝트는 나에게 웹 개발자라는 진로를 꿈꾸게 해준 나의 미래에 나름 의미있는 프로젝트였다.!
➰ 디벨롭 계기
계기는 간단했다. 첫 프로젝트의 짙은 아쉬움.. 그리고 글로만 읽어보았던 Next를 사용해보고 싶었다.
Next에 대한 블로그 글을 읽었는데 SSR이라는 방식 자체가 생소했고, 어떤 원리로 이루어지는 것인지 직접 경험하면서 느끼고 싶었다.
그래서 프론트엔드만이라도 다시 구현해보자고 마음먹고 디벨롭을 시작하였다.
💻 1차 디벨롭 : Next.js + TailwindCSS
스타일링은 TailwindCSS로 하였다. 공식문서에서 추천하는 css프레임워크이기도 했고, 작은 프로젝트였기에 가볍게 사용하기 좋을 것 같았다.
그리고 AOS 라이브러리를 통하여 스크롤 애니메이션을 간단하게 구현했다. 컴포넌트에 aos 속성을 정의하면 스크롤이 이벤트 발생 위치에 도달했을 때 애니메이션 효과가 나타난다. 정말 쉬운 방법이었다.
그래서 결과물은?
가장 많은 개선은 이룬 부분은 UI였다. 서비스에 대한 이해를 돕기 위한 초기 페이지를 섹션을 나누어 수정하였고, 한눈에 분석결과를 알아보기 쉬운 대시보드를 만들었다.
과정 중 서버 컴포넌트에 대한 이해도가 높아졌다.
관련 글에도 적었지만 처음에는 서버 컴포넌트는 그냥 SSR과 똑같은 것 아닌가 하는 생각이었다.
하지만 SSR은 초기 렌더링을 서버에서 처리하고 클라이언트에서 JS 코드를 추가하는 방식인 반면
서버 컴포넌트는 서버에서 생성된 리액트요소를 직렬화하여 클라이언트로 전송하는 것.. 비슷해보일 뿐이었단 사실
그리고 클라이언트 컴포넌트와의 차이를 잘 알게 되었고, 두 컴포넌트를 적절히 쓰는 것이 중요한 스킬이 되겠다는 생각을 했다.
서버 컴포넌트 관련 내용 정리는 이곳에..!!!
디벨롭 후에도 Next에서 데이터를 다뤄보고 싶은 마음이 남아 있었다. data fetching에도 여러 방법이 있던데 궁금했기 때문이다. api요청을 통한 간단한 데이터 작업이라도 해보고 싶어 2차 디벨롭을 진행하였다.
💻 2차 디벨롭 : data fetching + 인터랙티브 웹
유튜브api를 호출하여 인기 영상 리스트 데이터를 불러왔다. 서버 컴포넌트를 사용하여 서버 측에서 데이터를 fetching 하고 pre-rendering을 가능하게 하였다. 캐싱 옵션은 주지 않아 매 요청마다 새롭게 데이터를 불러올 수 있게 설정하였다.
그리고 AOS 라이브러리 사용을 하지 않고 IntersectionObserver API를 통하여 스크롤 애니메이션을 직접 재구현하였다. 별도의 커스텀 훅을 만들어 대상 요소와 visiblity여부를 받아 직접 구현하며 동작원리를 알 수 있어 좋았다.
하다보니 욕심이 생겨 더 인터랙티브한 웹을 만들어 보고자 했고, 요소별 애니메이션을 다양하게 추가하였다. 이 과정에서 기존 tailwindCSS는 classname에 스타일을 하나하나 정의하다보니 코드의 가독성이 떨어진다고 느꼈다.
그래서 재사용성과 가독성이 좋다고 알려진 SCSS 방식으로의 변경을 선택했다.
처음 사용해봤지만 주로 사용했던 styledComponent 덕분에 ( styledcomponent는 scss문법을 따른다 ) 문법에 익숙하여 금방 적응할 수 있었다. mixins, extends을 잘 사용하면 재사용성을 상당히 많이 높일 수 있을 것 같았다.
그래서 또 결과는?
확실히 섹션별 가시성이 좋아졌다. 인터랙티브한 웹이 사용자 입장에서는 좀 더 컨텐츠에 포커스가 맞춰진다는 것을 느꼈다.
대시보드는 scss로 스타일링 변경을 하는 것외에 손대지 않았는데 디자인이 여전히 아쉽기는 하다ㅜㅜ
🔫 트러블 슈팅 : 그동안 부딪힌 수많은 이슈..
정말 많은 이슈를 겪었다 😭😭 그 중 기록해두고 싶은 이슈 몇가지에 대해 소개해보자면..
클라이언트 컴포넌트 하위 서버 컴포넌트에서의 DataFetching
문제
: 클라이언트 컴포넌트 내부로 data fetching로직이 담긴 서버 컴포넌트를 가져왔는데, 제한이 생겨 data fetching이 불가능했다.
원인
: 서버 컴포넌트에는 서버 전용 코드 ( 데이터베이스, async/await )가 있기 때문에 클라이언트 내부로 import 할 수 없게 되어있다.
해결
: 서버 컴포넌트와 클라이언트 컴포넌트를 다른 서버 컴포넌트로 감싸 서버 컴포넌트를 클라이언트 컴포넌트에 props로 넘겨주며 해결하였다. 이 경우 이미 렌더링 된 상태로 props로 넘어간다.
opacity 애니메이션 깜빡임
문제
: div 하위에 button 요소를 넣은 뒤 div 영역 밖에 위치시켰다. 이때 button은 opacity 0이었다가 div에 hover하면 opacity 1로 요소가 생기는 애니메이션을 구현하였다. 하지만 div에 hover 하기 전에도 hover 애니메이션이 비정상적으로 동작하는 문제를 포착하였다.
원인
: opacity가 0일 때도 보이지만 않을 뿐 요소는 존재하기 때문에 div의 영역으로 인식하고 애니메이션이 나타나는 것이었다.
해결
: opacity 조절이 아닌 visibility를 hidden에서 visible로 변경하여 요소의 영역 자체를 없앴다가 부여하니 정상적으로 동작하는 것을 확인하였다.
setinterval내 state 변경 안됨
문제
: setInterval의 콜백함수로 count state를 변경하는 setCount 함수를 넣어 count가 1씩 증가하도록 하였다. 하지만 count는 첫 타이머에만 1로 증가하고 값이 더이상 변하지 않는 문제를 확인하였다.
원인 : setInterval은 타이머를 직접 갈아주지 않는 이상 첫 렌더의 count 값을 기억하기 때문에 계속 count의 초기값을 집어넣는다.
해결 : useRef를 활용해 콜백함수를 ref의 current로 저장한 뒤 count값이 바뀌어 리렌더링이 발생할 때마다 변화하는 콜백을 setInterval에 반영할 수 있게 하였다.
animation forwards 상태에서 hover 동작 제한
문제
: animation-fill-mode를 forwards로 두고 hover 스타일을 적용하면 hover 시 아무런 변화가 없다.
원인
: animation-fill-mode가 forwards이라는 것은 그 스타일을 계속 적용하고 유지해야 한다는 것을 의미한다. 따라서 우선권을 갖기 때문에 hover 상태의 스타일은 적용되지 않는다.
해결
: 해당 요소에 div태그 하나를 더 입혀 hover 애니메이션을 구현해 우선권을 없앴다. 정상 동작하는 것을 확인하였다.
😊 스스로 잘했다고 느낀 점
새로운 여러 기술들을 직접 사용해본 점
이번 프로젝트에서는 기술에 대해 도전적인 태도를 가지려 했다. 글로 접하는 것과 직접 사용해보는 것은 확실히 다르니까! 매번 익숙하게 사용하던 기술에서 벗어나 새로운 기술의 공식문서를 읽고 다양한 자료로 원하는 기능을 구현하는 것은 꽤 재미있었다ㅎㅎ
기술 해결에서 그치지 않고 더 깊이 있게 공부하려 한 점
서버 컴포넌트에서의 data fetching을 적용하며 리액트 쿼리와 비슷하다는 생각을 해서 두 방법의 차이에 대해서 깊게 찾아보기도 했고, useRef의 타입에러를 마주하며 타입스크립트에서의 useRef을 사용할 때 각 상황에 따라 다른 type 정의에 대한 공부를 했다.
당장의 문제 해결에만 집중하지 않고 문제의 원인과 해결 방법에 대해 좀 더 깊이 있게 공부하려 하다보니 다음번엔 같은 에러를 만들 지 않을 수 있을 것 같은, 혹시 마주친다고 하더라도 쉽게 풀어낼 수 있을 것 같은 자신감이 생겼다.
😥 많은 아쉬움 포인트
버전관리를 하지 못한점
단계적인 디벨롭을 거쳤다고 생각하나 버전관리는 철저하지 못했다. 나름 브랜치 생성-병합을 하며 개발을 진행하였는데 흔한 git-flow처럼 체계적인 브랜치 전략은 따르지 못한 것 같아 아쉬움이 남는다. 협업과정에서는 브랜치 관리의 중요성도 커질텐데 혼자 개발을 진행할 때도 열심히 준수하는 습관을 들여야겠다.
기준이 명확하지 않은 컴포넌트 관리
컴포넌트 관리를 한다고 하긴 했는데 그 기준이 명확하지 못했다. 컴포넌트의 복잡성만 따져 한 컴포넌트 내에서 너무 많은 요소가 들어간다 싶으면 분리를 했다. ( 물론 재사용을 따질 만큼의 컴포넌트가 없기 때문이기도 했다.. )
다음에는 view와 로직을 분리한다거나 state에 따라서 분리한다는 것처럼 컴포넌트 분리 기준점을 잡아 관리를 체계적으로 하고 싶다. 그리고 atomic 디자인 패턴도 적용해보고 싶다. atoms -> molecules -> organism -> template -> page 순으로 확장되는 컴포넌트..!
백엔드의 부재
뭐니뭐니해도 가장 아쉬운 점이다. 백엔드가 필요한 서비스에 백엔드가 빠지니 서비스의 기능을 하지 못한다ㅜㅜ
🌟 최종 정리 및 느낀점
혼자서 개발을 진행하면서 프로젝트의 설계가 중요하겠다는 생각을 했다. 의욕만 앞서 무작정 떠오르는대로 개발 흐름을 잡다보니 헤매기도 하고 시간을 버린 부분도 많다. 자꾸 변경사항이 생기다보니 온전히 개발에 집중을 못 하겠다고 느꼈다. 변경사항을 최소화하기 위해 앞으로 설계는 꼼꼼히 하고 들어가는 걸로!
그리고 애니메이션이 많이 들어간 인터랙티브 웹을 처음 만들어봤는데, 요거 참 재미있었다. 개발 결과가 바로바로 화면으로 보여지기 때문에 더 흥미와 욕심을 느꼈던 것 같다.
여차저차 디벨롭이 끝이 났다. 여전히 아쉬운 부분이 많기 때문에 또 넣고 싶은 기능이나 디자인 아이디어가 생각나면 추가적인 디벨롭을 꾸준히 진행할 예정이다.~~