[NUMBLE] 넘블 팀 챌린지 후기

 

1.  챌린지 주제

 

이번 주제는 숏폼(15분미만)영상 서비스 플랫폼 제작이었다. 
이전에 토이프로젝트로 sns를 만들어 보았지만 영상플랫폼을 만들어 보는건 처음이라 굉장히 설레였다

 

 

 

 

 

2.  챌린지 기간

 

 

 

3.  프로젝트

단기목표를 정해서 습관을 들이기 위해 7일동안 숏폼 영상을 올리는 플랫폼입니다.

 

자신이 정한 목표 카테고리에 영상을 올리고 사람들과 공유함
7일 연속 영상을 업로드하면 뱃지(보상)를 받을 수 있고, 혼자 하는 것보다 사람들과 영상을 공유하면서 함께 의지를 다지기위한 목적을 가지고있다.

 

 

 

 

4. 기술스택

    1. Next.js  
    2. Typescript
    3. React-query
    4. React-hook-form
    5. Docker, Docker-compose

 

 

 

 

 

5. 주요로직

- Infinite Scroll

 

처음 무한 스크롤을 offset과 page를 사용하여 구현하였는데 스크롤을 할 때 영상이 중복되거나 건너뛰는 문제가 발생하였다.

문제를 해결하기 위해 찾아보니 sns방식의 최신글이 올라오는 방식에서 offset방식은 맞지 않다는 것이었다. 스크롤되어 다음 영상들을 가져올때 사용자가 글을 쓰거나 삭제를 한다면? 데이터의 순서가 꼬이게 된다.

 

그래서 받아온 마지막 요소의 아이디를 보내는 lastId 방식을 도입하여 문제를 해결하였다.

관심영상리스트 호출

스크롤이 아래로 내려가면 다음 페이지를 호출

react-query를 이용한 infinite scroll 로직

 

- Thumbnail generator

 

숏폼 영상을 업로드 할 때 첫 기획에선 영상을 올리는 부분과 썸네일 올리는 부분을 분리하려 했으나 중간에 기획이 바뀌어 영상업로드와 썸네일추출 그리고 썸네일 변경을 한 div안에서 해결해야 되는 상황이 되었다.

 

 

중간에 기획이 바뀌었다.

 

가장 먼저 사용했던 것은 react-video-thumbnail 라는 라이브러리였다.
 캔버스를 이용하여 비디오의 스냅샷을 찍는 방식으로 동작하는 라이브러리였는데 타입정의 파일이 없어서 불러오는 부분의 타입만 thumbnail.d.ts파일로 정의하여 사용하였다.

 

하지만 문제가 생겼다.
서비스의 기획상 썸네일이 추출되고 나서 사용자가 썸네일을 수정할수도 있어 상당히 많은 커스텀이 들어가야 하는데 라이브러리에서 그정도의 커스텀을 지원하지 않았다.
그래서 직접 canvas를 사용하여 썸네일 추출로직을 구현하기로 했다.

 

 

대충 구현해야할 로직은 아래와 같다.

 

1. 영상을 업로드하면 업로드한 비디오 파일을 video 태그에 넣어 영상 첫화면을 canvas를 이용하여 스냅샷을 찍는다.
2. 스냅샷을 state에 저장하고 비디오 태그를 이미지 태그로 바꾸어 주어 썸네일을 보여준다.
3. 썸네일 클릭시 이미지를 업로드 할수 있는 인풋을 띄워주고 썸네일을 수정할수 있게 한다. 
4. 만약 초기화버튼을 클릭하면 처음 추출한 썸네일을 다시 보여주고 새로운 썸네일을 삭제한다.

 

 

썸네일 추출까지 성공적으로 구현 했지만 여기서 다시한번 문제가 발생하였다.
영상이 완전히 로드가 되어서 화면이 뜨는순간에 스냅샷을 찍어야 하는데 이 시기를 알수있는 방법이 없었다. matadata가 로드되는 이벤트나 seek이벤트후에 찍어도 로드가 되지않아 검은 화면만 찍혔다..

 

 

그래서 선택한 방법은 setTimeout을 주어 강제로 로딩할 시간을 주는 것이었다. 물론 더 좋은 방법이 있을수도 있겠지만 프로젝트 기간이 짧아 당시 할수 있는 최선의 선택이었던거같다..

썸네일 추출로직

 

 

6. 코드 내에서 고려한 특정 유저 행동과 그에 대한 대처

 

구현을 하면서 가장 신경썼던 부분은 중복된 요청을 백엔드에 여러번 보내는 유저행동이었다.
잘못된 클릭으로 의미없이 여러번 백에 요청이 보내진다면 굉장한 리소스의 낭비라고 생각했다.(+aws서버를 사용해서 비용도...)

이러한 상황에 대처하기위해 React-query를 도입하여 isLoading을 이용한 연속적인 요청을 제한하고 한번의 요청이 끝난후에 다시 요청을 보낼수 있도록 구현하였고, 또한 data-caching 을 활용하여 데이터를 재사용 할수 있도록 구현하였다.

 

 

 

7. 프로젝트 회고

 

프로젝트 기간동안 정말 많은 문제들에 부딪쳤다.

직장을 다니면서 하다보니 시간이 너무 없어서 기획단계를 충분히 거치지 못해 구현중에도 기획이 수정되거나 하는 혼란이 있었다.

배포로 도커를 골랐었고 문제가 생길까봐 미리미리 로컬환경에서 도커셋팅후 컨테이너 테스트를 진행하였음에도 aws 리눅스 서버 환경에서 문제가 많이 발생하였다. 또 처음 ec2 인스턴스를 생성할때 t2 micro를 선택했는데 메모리가 1기가밖에 안되다보니 도커 빌드중 서버가 터지는 문제가 빈번히 발생하였다.(두번이나 메모리를 올려 결국 4기가램을 사용하게되었다...)

또 팀원들 모두 비슷한 연차의 개발자들끼리의 협업이 처음이다 보니 소통에 대한 어려움이 많이 있었는데, 매주 토요일에 가능한한 오프라인회의를 진행하여 프로젝트 진행상황을 공유하고 소통하는 시간을 가져 의견차이를 좁히려고 노력했다.

이러한 노력으로 프로젝트를 충돌없이 성공적으로 끝낼수 있었고, 개발자로서 한층 더 성장할수 있는 계기가 되었다고 생각한다.