<div id="readability-page-1" class="page"><div><h2 id="개요">개요</h2>
<img src="https://velog.velcdn.com/images/dongha1992/post/d67dad9b-60b7-469e-b65c-5d643b32b6dd/image.png">
서비스에서 메인을 관리할 수 있는 어드민 페이지다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/823b67e5-6e71-4e23-99c3-483645bd9ac5/image.png">
중앙에 있는 테이블에 상품을 추가/삭제/변경할 수도 있고, 순서를 변경할 수도 있다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/68d0fa6f-1ef6-4e2f-b7ec-e67a72fabf85/image.png">
순서를 변경하게 되면 오른쪽 화면에 보이느 상품의 순서도 변경되어 서비스에 어떻게 보이는지 미리 알 수 있는 페이지다.
<h2 id="문제">문제</h2>
초기에 단건만 순서이동이 가능했는데, 기획이 추가되면서 다건도 순서 이동이 가능하게 변경되었고 상품 개수도 계속 쌓이다보니 다건을 순서 변경할 때 버벅임이 포착되었다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/7a9ca6bc-3b4d-4fb3-9dfb-7547ef5ba81f/image.png">
4-5개를 선택하고 순서 변경을 해보면 
<img src="https://velog.velcdn.com/images/dongha1992/post/d4cc6a5e-fea6-43ed-bdab-4eb0615a36c6/image.png">
약 110ms의 시간이 소요됐다. 100ms 미만의 UI 응답까지 사용자가 느끼기 쾌적하다고 생각하니 체감상 아주 불편하진 않았지만 안 좋은 네트워크 환경이나 추후에 상품이 더 쌓였을 때 문제가 될 수 있다고 판단하여 개선 작업을 시작했다. 
<h2 id="개발-과정">개발 과정</h2>
크게 2가지로 나눠서 생각했다. 테이블 순서 변경 시 전체 테이블의 리렌더링과 오른쪽 preview에서 컴포넌트의 리렌더링 
<h3 id="starttransition">startTransition</h3>
테이블 순서를 변경하면 오른쪽 preview의 이미지들도 순서가 변경되는데 <code>startTransition</code>으로 우선순위를 낮춰서 테이블 순서가 먼저 변경되고 그리고 preview를 변경하면 버벅임을 해소할 수 있을 것 같았다. 
<pre><code>...
 onAfterSetTableList: (newList) =&gt;
 startTransition(() =&gt; 
	updateItemsOrderForAppRef.current?.(newList)),
 ...</code></pre>
순서 변경 후 오른쪽 preview 업데이트가 발생하는 이벤트에 transition을 걸고 다시 측정해보았다.
<img src="https://velog.velcdn.com/images/dongha1992/post/22f97de9-6985-457e-bd24-1f07a1210b0f/image.png">
transition을 해서 커밋만 늘고 별다른 소득이 없었다. 즉, 긴급한 작업(테이블 변경)이 더 무겁기 때문에 preview의 렌더링 우선순위를 미뤄봤자 차이가 없는 것이다. transition이 효과를 얻기 위해서는 테이블은 즉각(9ms), preview는 나중에(23ms)인 상태가 되어야 한다. 먼저 테이블 최적화가 선행되어야 하니 테이블을 손봤다. 
<h3 id="memo">memo</h3>
테이블 가장 하위에 있는 <code>TableCell</code> 컴포넌트가 몇 번 정도 리렌더링 되는지 <code>console.count</code>로 측정해보았다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/af4c4190-3eeb-413a-b13c-dfe06492fd35/image.png">
176개의 리스트가 있는 12행 테이블 기준으로 총 2,100개 가량의 Cell UI가 있었고
<img src="https://velog.velcdn.com/images/dongha1992/post/45d9f5f0-c4e4-4b6e-bf44-04afe13ca215/image.png">
Cell의 순서 변경을 일으키면 4개의 커밋이 찍혔다.
<img src="https://velog.velcdn.com/images/dongha1992/post/39366efd-92b8-41dc-b1ed-33d65a5fce1d/image.png">
순서 변경 1회(4개의 커밋)에 약 10,000회 정도 렌더링이 일어났다. 즉, 2,100개의 Cell 모두 리렌더링 된다는 뜻이었다. 
<pre><code>//...
const MemoizedTableRow = memo(TableRowComponent) as typeof TableRowComponent;
//...


const TableBody = &lt;T extends Record&lt;string, any&gt;&gt;({
 //...
}: TableBodyProps&lt;T&gt;) =&gt; {
 return (
 //... 
 &lt;MemoizedTableRow ... /&gt;
 //...
 )
</code></pre>
이상한 점은 분명 Row 컴포넌트 쪽에<code>memo</code>를 사용하고 있었는데 메모이제이션이 되지 않았다. 어디선가 memo가 깨졌음을 파악하고 원인을 찾아보았다. 
<h4 id="인라인-함수-props">인라인 함수 props</h4>
<pre><code>// Table.tsx

//...
&lt;TableContainer.Body
 renderCells={(row, cell, index) =&gt; { // ← 매 렌더마다 새 함수 생성
 return &lt;TableContainer.Cell key={index} row={row} cell={cell}/&gt;
 }}
/&gt;</code></pre>
원인은 render props 형태로 Cell을 내려주던 부모(Table Body)에 있었다. Table 내부에 Cell이 페이지마다 조금씩 달라지는 것을 고려하여 render props로 Cell을 받았는데, 그것이 오히려 렌더링마다 새로운 함수를 생성하게 되면서 하위에 있는 Row의 메모를 깨버렸다. 
<h4 id="memo-comparator">memo comparator</h4>
render props를 없애고 값만 넘기기엔 변경 포인트가 너무 많았고, 기존에 Table Body &lt;-&gt; Table ROW, CELL 을 유연하게 조립하기 위해 설계 했던 테이블 UI가 전부 변경되어야 해서 다른 방법을 찾아야 했다. 
결국 상위에서 함수를 새로 생성해도 memo를 제대로 하기 위해서는 하위(Table Row)쪽에서 Row의 original 객체 참조값이 변경이 일어났나 비교하면 된다는 것을 깨닫고 Table Row 를 수정했다. 
<pre><code>...
const MemoizedTableRow = memo(TableRowComponent, (prev, next) =&gt; {
 return (
 prev.row.original === next.row.original &amp;&amp;
 prev.isRowCustomClass === next.isRowCustomClass &amp;&amp;
 );
}) as typeof TableRowComponent;</code></pre>
기존의 <code>MemoizedTableRow</code>에 comparator를 추가하고 실제 original 객체가 변경이 일어났는지를 비교했다. 리액트 리렌더링의 트리거는 순서 변경 이후 배열 참조 자체가 바뀌어서 일어나지만, TableBody에서 각 row를 memo로 비교할 때는 객체의 참조를 보기 때문에 memo comparator가 가능하다. 
<code>rowPropsResult, onClick</code>같은 값은들 상위에서 필요하다면 useCallback이나 useMemo를 해주면 되고 일단 UI 업데이트에 관여하는 값이 아니라 컴페어에서 제외했다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/b4f842e3-9423-4d22-99bb-010281fedd28/image.png">
거의 기적처럼 렌더링 횟수가 줄어들었다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/30ca0cde-3fc1-4053-aa3e-3690618f10bc/image.png">
렌더링 시간도 기적적으로 줄어들었다. 
<h4 id="react-table-v7">react-table v7</h4>
예상치 못한 버그가 발견되었다. 최초 Cell 클릭 시 selected 표시가 안 보이고 순서를 변경한 후에야 표시가 나타났다. 
<img src="https://velog.velcdn.com/images/dongha1992/post/e8abbf48-1d54-4078-9cc6-2ad1b4cee085/image.png">
혹시나 해서 memo compare 부분에 
<pre><code>const MemoizedTableRow = memo(TableRowComponent, (prev, next) =&gt; {
 return (
 prev.row.original === next.row.original &amp;&amp;
 prev.isRowCustomClass === next.isRowCustomClass &amp;&amp;
 prev.row.isSelected === next.row.isSelected
 );
}) as typeof TableRowComponent;</code></pre>
<code> prev.row.isSelected === next.row.isSelected</code>를 추가했는데도 증상은 동일했다. 
무언가 react-table이 select 업데이트 하는 것과 방금 추가한 compare memo 사이에 꼬인 것 같아서 객체의 select 상태를 어떻게 업데이트하나 노드 모듈에 있는 react-table을 살펴봤다. 
<pre><code>//react-table/plugin-hook.js
const selectedFlatRows = React.useMemo(() =&gt; {
 const selectedFlatRows = []

 rows.forEach(row =&gt; {
 // ...
 row.isSelected = !!isSelected

 if (isSelected) {
 selectedFlatRows.push(row)
 }
 })</code></pre>
<code>row.isSelected = !!isSelected</code> 이 부분을 보면 react-table은 내부적으로 select을 하게 되면 row 객체를 새로 만들지 않고 기존 객체를 mutation으로 업데이트한다. 
즉, 렌더링을 하기 위해 compare 하는 시점에선 comparator가 실행되는 시점에 <code>prev.row</code>와 <code>next.row</code>는 같은 JS 객체를 가리킨다.
<code>prev.row.isSelected === next.row.isSelected // 동일하게 true</code> 
결국, 렌더링 시점에 이전 값을 명시적으로 넣어줘야 한다. 
<pre><code> &lt;MemoizedTableRow
 //...
 isSelected={!!(row as ExtendedRow&lt;T&gt;).isSelected}
 /&gt;</code></pre>
isSelected을 props로 주면 
<img src="https://velog.velcdn.com/images/dongha1992/post/9463b804-41a9-4c4b-ba2a-e34eb034d0ff/image.png">
초기에도 선택이 잘 된다. 
<h2 id="마무리">마무리</h2>
개발을 진행하면서 메모이제이션이 필요한 컴포넌트에 메모를 추가했는데, 시간이 지나면서 고도화를 하거나 상위 컴포넌트들을 수정을 하면서 메모가 깨지는 케이스였다. 개발을 하고 테스트코드를 작성하고 잘 돌아가면 해당 기능의 코드를 다시 볼 일이 없는데, 이런 식으로 사이드 이펙트로 인해 성능 악화가 발생할 수 있음을 경험했다. </div></div>

삶도 재입학이 되나요?

개요
서비스에서 메인을 관리할 수 있는 어드민 페이지다. 
중앙에 있는 테이블에 상품을 추가/삭제/변경할 수도 있고, 순서를 변경할 수도 있다. 
순서를 변경하게 되면 오른쪽 화면에 보이느 상품의 순서도 변경되어 서비스에 어떻게 보이는지 미리 알 수 있는 페이지다.
문제
초기에 단건만 순서이동이 가능했는데, 기획이 추가되면서 다건도 순서 이동이 가능하게 변경되었고 상품 개수도 계속 쌓이다보니 다건을 순서 변경할 때 버벅임이 포착되었다. 
4-5개를 선택하고 순서 변경을 해보면 
약 110ms의 시간이 소요됐다. 100ms 미만의 UI 응답까지 사용자가 느끼기 쾌적하다고 생각하니 체감상 아주 불편하진 않았지만 안 좋은 네트워크 환경이나 추후에 상품이 더 쌓였을 때 문제가 될 수 있다고 판단하여 개선 작업을 시작했다. 
개발 과정
크게 2가지로 나눠서 생각했다. 테이블 순서 변경 시 전체 테이블의 리렌더링과 오른쪽 preview에서 컴포넌트의 리렌더링 
startTransition
테이블 순서를 변경하면 오른쪽 preview의 이미지들도 순서가 변경되는데 startTransition으로 우선순위를 낮춰서 테이블 순서가 먼저 변경되고 그리고 preview를 변경하면 버벅임을 해소할 수 있을 것 같았다. 
...
 onAfterSetTableList: (newList) =>
 startTransition(() => 
 updateItemsOrderForAppRef.current?.(newList)),
 ...
순서 변경 후 오른쪽 preview 업데이트가 발생하는 이벤트에 transition을 걸고 다시 측정해보았다.
transition을 해서 커밋만 늘고 별다른 소득이 없었다. 즉, 긴급한 작업(테이블 변경)이 더 무겁기 때문에 preview의 렌더링 우선순위를 미뤄봤자 차이가 없는 것이다. transition이 효과를 얻기 위해서는 테이블은 즉각(9ms), preview는 나중에(23ms)인 상태가 되어야 한다. 먼저 테이블 최적화가 선행되어야 하니 테이블을 손봤다. 
memo
테이블 가장 하위에 있는 TableCell 컴포넌트가 몇 번 정도 리렌더링 되는지 console.count로 측정해보았다. 
176개의 리스트가 있는 12행 테이블 기준으로 총 2,100개 가량의 Cell UI가 있었고
Cell의 순서 변경을 일으키면 4개의 커밋이 찍혔다.
순서 변경 1회(4개의 커밋)에 약 10,000회 정도 렌더링이 일어났다. 즉, 2,100개의 Cell 모두 리렌더링 된다는 뜻이었다. 
//...
const MemoizedTableRow = memo(TableRowComponent) as typeof TableRowComponent;
//...
const TableBody = <T extends Record<string, any>>({
 //...
}: TableBodyProps<T>) => {
 return (
 //... 
 <MemoizedTableRow ... />
 //...
 )
이상한 점은 분명 Row 컴포넌트 쪽에memo를 사용하고 있었는데 메모이제이션이 되지 않았다. 어디선가 memo가 깨졌음을 파악하고 원인을 찾아보았다. 
인라인 함수 props
// Table.tsx
//...
<TableContainer.Body
 renderCells={(row, cell, index) => { // ← 매 렌더마다 새 함수 생성
 return <TableContainer.Cell key={index} row={row} cell={cell}/>
 }}
/>
원인은 render props 형태로 Cell을 내려주던 부모(Table Body)에 있었다. Table 내부에 Cell이 페이지마다 조금씩 달라지는 것을 고려하여 render props로 Cell을 받았는데, 그것이 오히려 렌더링마다 새로운 함수를 생성하게 되면서 하위에 있는 Row의 메모를 깨버렸다. 
memo comparator
render props를 없애고 값만 넘기기엔 변경 포인트가 너무 많았고, 기존에 Table Body <-> Table ROW, CELL 을 유연하게 조립하기 위해 설계 했던 테이블 UI가 전부 변경되어야 해서 다른 방법을 찾아야 했다. 
결국 상위에서 함수를 새로 생성해도 memo를 제대로 하기 위해서는 하위(Table Row)쪽에서 Row의 original 객체 참조값이 변경이 일어났나 비교하면 된다는 것을 깨닫고 Table Row 를 수정했다. 
...
const MemoizedTableRow = memo(TableRowComponent, (prev, next) => {
 return (
 prev.row.original === next.row.original &&
 prev.isRowCustomClass === next.isRowCustomClass &&
 );
}) as typeof TableRowComponent;
기존의 MemoizedTableRow에 comparator를 추가하고 실제 original 객체가 변경이 일어났는지를 비교했다. 리액트 리렌더링의 트리거는 순서 변경 이후 배열 참조 자체가 바뀌어서 일어나지만, TableBody에서 각 row를 memo로 비교할 때는 객체의 참조를 보기 때문에 memo comparator가 가능하다. 
rowPropsResult, onClick같은 값은들 상위에서 필요하다면 useCallback이나 useMemo를 해주면 되고 일단 UI 업데이트에 관여하는 값이 아니라 컴페어에서 제외했다. 
거의 기적처럼 렌더링 횟수가 줄어들었다. 
렌더링 시간도 기적적으로 줄어들었다. 
react-table v7
예상치 못한 버그가 발견되었다. 최초 Cell 클릭 시 selected 표시가 안 보이고 순서를 변경한 후에야 표시가 나타났다. 
혹시나 해서 memo compare 부분에 
const MemoizedTableRow = memo(TableRowComponent, (prev, next) => {
 return (
 prev.row.original === next.row.original &&
 prev.isRowCustomClass === next.isRowCustomClass &&
 prev.row.isSelected === next.row.isSelected
 );
}) as typeof TableRowComponent;
prev.row.isSelected === next.row.isSelected를 추가했는데도 증상은 동일했다. 
무언가 react-table이 select 업데이트 하는 것과 방금 추가한 compare memo 사이에 꼬인 것 같아서 객체의 select 상태를 어떻게 업데이트하나 노드 모듈에 있는 react-table을 살펴봤다. 
//react-table/plugin-hook.js
const selectedFlatRows = React.useMemo(() => {
 const selectedFlatRows = []
 rows.forEach(row => {
 // ...
 row.isSelected = !!isSelected
 if (isSelected) {
 selectedFlatRows.push(row)
 }
 })
row.isSelected = !!isSelected 이 부분을 보면 react-table은 내부적으로 select을 하게 되면 row 객체를 새로 만들지 않고 기존 객체를 mutation으로 업데이트한다. 
즉, 렌더링을 하기 위해 compare 하는 시점에선 comparator가 실행되는 시점에 prev.row와 next.row는 같은 JS 객체를 가리킨다.
prev.row.isSelected === next.row.isSelected // 동일하게 true 
결국, 렌더링 시점에 이전 값을 명시적으로 넣어줘야 한다. 
 <MemoizedTableRow
 //...
 isSelected={!!(row as ExtendedRow<T>).isSelected}
 />
isSelected을 props로 주면 
초기에도 선택이 잘 된다. 
마무리
개발을 진행하면서 메모이제이션이 필요한 컴포넌트에 메모를 추가했는데, 시간이 지나면서 고도화를 하거나 상위 컴포넌트들을 수정을 하면서 메모가 깨지는 케이스였다. 개발을 하고 테스트코드를 작성하고 잘 돌아가면 해당 기능의 코드를 다시 볼 일이 없는데, 이런 식으로 사이드 이펙트로 인해 성능 악화가 발생할 수 있음을 경험했다.

테이블 순서 변경 렌더링 최적화하기

댓글