2020.12.15(화) 회의록

2020.12.15 (화) 회의록

우리의 서비스가 메인으로 보여주는 페이지는 가계부 거래내역 페이지이다. 유저나 가계부에 따라 차이가 있겠지만 많은 양의 내역이 월별로 렌더링되는 구조를 지니고 있다. 이러한 거래내역이 적다면 상관이 없겠지만 거래내역이 수백, 수천 개로 늘어나게 되면 렌더링 관련 성능 이슈가 발생하게 된다.
따라서 일정 양의 거래내역만 먼저 렌더링해주고 이후 특정한 방식에 따라 추가적으로 렌더링해줌으로써 렌더링 관련 이슈를 해결할 수 있다.

무한스크롤
- 사용자는 별도의 클릭 없이 스크롤하는 것만으로 거래내역을 추가로 확인할 수 있다. 페이지 이동 없이 이전까지 렌더링된 것들을 현재 페이지에서 모두 확인할 수 있다. 시중에 나와있는 금융 관련 서비스 역시 대부분 무한스크롤을 사용하고 있다.
페이지네이션
- 페이지마다 정해진 개수의 거래내역을 보여준다. 사용자의 입장에서는 클릭을 통해 이동해야 한다는 단점이 있을 뿐만 아니라, 이전 페이지의 거래내역을 확인하려면 다시 이전 페이지로 이동해서 확인해야 한다는 단점이 있다.
더보기 버튼
- 더보기 버튼을 눌렀을 때 발생하는 이벤트의 기준을 정하기가 모호하다. 초기에 20개의 거래내역만 보여주고 더보기 버튼을 눌렀을 때 나머지의 거래내역을 보여준다면 이것 역시 거래내역이 많아졌을 때 같은 성능 이슈가 발생한다. 애초에 많은 양의 거래내역이 있을 경우 발생한 문제를 해결하기 위해 토론하기 시작한 주제였기 때문에 우리의 방향성과 맞지 않다.

무한스크롤을 적용하자는 결론을 내렸다.

이전 달의 거래내역, 현재 달의 거래내역, 다음 달의 거래내역을 세션에 key-value(request URL-거래내역) 형식으로 저장하는 방식으로 캐싱이 이루어지고 있다.
무한스크롤의 경우, 초기 렌더링되는 화면에 정해진 개수의 거래내역을 출력한다.이후, 스크롤을 내려서 페이지의 가장 밑에 도달하게 되었을 때 정해진 개수만큼의 거래내역을 추가적으로 출력해준다.

사용자가 머물러있는 페이지에만 무한스크롤 방식으로 거래내역을 렌더링하자는 결론이 도출되었다. 이렇게 되면 기존의 캐싱 관련 로직을 건들지 않고 TransactionView 내에서만 로직을 추가하면 무한스크롤을 구현할 수 있다.

무한스크롤 자체가 데이터가 한꺼번에 많이 렌더링되었을 때 발생하는 이슈를 해결하는 용도로 사용되므로 거래내역이 5000개일 때 성능 테스트를 해보자.
react dev tools의 profier를 사용하여 거래내역이 10개일 때와 5000개일 때의 성능 비교를 진행해보았다.
- 거래 내역을 출력해주는 TransactionView의 렌더링 속도를 비교해봤을 때 수치로도 차이가 있었고, 육안으로 확인하기에도 5000개의 경우 긴 로딩 시간이 있었다.

거래내역 페이지에 무한스크롤을 적용하자는 결론을 내렸다.

스크롤을 위로 이동할때는 렌더링 로직을 거치지 않고, 스크롤이 아래로 이동할 때만 렌더링 로직을 거치게 한다.

디바운스/쓰로틀링 적용
- 디바운싱: 반복적으로 호출되는 함수 중 마지막 함수만 호출한다.
- 쓰로틀링: 마지막 함수가 호출된 후 일정 시간이 지나기 전까지 다시 호출되지 않도록 한다.

현재 페이지 맨 밑에 도달했을 때 호출되는 함수는 거래내역을 추가 렌더링해주는 함수 하나이기 때문에 디바운싱은 필요하지 않을 것 같다.

사용자가 빠르게 스크롤을 내리는 경우를 생각하면 쓰로틀링이 오히려 버퍼링이 생긴 것 같은 불편을 야기할 수 있다.