회사에서 진행한 업무라 자세하게 쓰긴 좀 그렇고 간단하게 기록할 부분만 기록하려고 한다.
한 일
- SSR -> CSR 전환
- 애니메이션 고도화
주안점을 둔 부분
SSR -> CSR 전환
일단 왜 했는지부터 이야기하면, 해당 부분에 대해 에러가 났다고 해서 페이지 전체가 접속이 불가능해지는 현상을 막기 위해서이다. 해당 피쳐의 쿼리가 꽤 무겁다고 알고 있는데 여기서 에러가 나도 페이지 접속이 가능하도록 CSR로 전환하는 작업을 먼저 진행했다.
작업 자체가 어렵지는 않았는데, 주안점을 둔 부분은 CLS (Cumulative Layout Shift)였다. 뭐 그럴싸해보이는 영어가 섞여서 그렇지 사실은 간단한 사안이다.
기존에는 페이지 전체가 SSR로 그려지기 때문에 접속해서 보고 있는데 갑자기 어느 영역이 뿅! 하고 나타나는 일이 없었지만,
일부 영역을 CSR로 전환하게 되면서 뿅! 하고 나타나게 되었고, 그럼으로 인해 사용자가 보던 / 또는 클릭하려던 영역이 밀려나게 되는 일이 생기게 된다.
이는 매우 안좋은 사용자 경험을 주게 되는데 (개인적으로 필자도 굉장히 극혐하는 UX이다), 해당 현상을 Layout Shift라고 한다.
CLS란 Layout Shift가 얼마나 일어났는지를 판단하는 점수로 웹 바이탈에서 쓰인다.
어쨌든 Layout Shift가 일어나지 않게 하기 위해 다음과 같은 작업을 진행했다.
- 뿅! 하고 나타날 영역의 공간을 미리 확보한다.
- SSR에서 빈 Div를 heigth만 정해서 그려내고, CSR로 바꿔치기 하는 방식이다.
여기서 문제는 해당 영역의 높이가 항상 일정하지 않다는 것이다. 높이가 항상 일정하게끔 디자인이 수정되면 당연히 좋겠지만 (그리고 지금은 그렇게 되었지만) 당시에는 그럴 리소스가 없었으므로 개발에서 커버했다. 때문에 다음과 같이 고려하여 작업했다.
- 비로그인 유저의 경우 항상 고정된 높이이기 때문에, 로그인 여부를 기준으로 분기했다.
- 로그인 유저의 경우 두 가지 케이스가 있고, 새로고침 시 랜덤으로 선택된다.
- 이를 미리 알려면 CSR로 전환하는 의미가 없어지기 때문에, 두 케이스 중 더 빈도수가 높은 케이스로 진행했다.
- 그리고 이후 디자인 작업시 높이를 통일하는 방향으로 개선했다.
처음에 생각으로는 해당 작업은 미리보기 느낌이어서, 뒤이어 할 본체의 개발이 완료되면 한꺼번에 배포하려고 했었다.
그러나 혹시나 에러가 발생한다면 해당 작업과 뒤이어 할 작업 중 어느 작업이 원인인지를 파악하기 힘들어지기 때문에 해당 작업을 미리 배포하는 것이 좋겠다는 피드백을 받았다. (거기까진 생각 못했음)
그래서 결론적으론 해당 작업을 먼저 배포 진행했다.
애니메이션 고도화
시인성을 높이기 위해 애니메이션을 고도화하는 작업이 주요 작업이었다.
총 4가지 영역에 대해 애니메이션이 들어가야 했는데, 애니메이션 작업이 처음이라 그런건지 직접 보면서 미세하게 조정해야 하는 부분들이 많았다. 그러나 우리 서비스의 개발 환경은 그 특성상 핫리로드가 안되고 수정사항이 반영되는 속도가 굉장히 느리기 때문에 그렇게 작업하기가 어려웠다. (극단적으로 말하자면 폰트를 14px에서 15px로 변경하는데 10초 가량을 기다려야 한다) 디자이너분과 공유하기도 까다로웠다.
그래서 선택했던 방법은 코드샌드박스를 활용하는 것이었다. 꽤 애용하는 방법인데, 여기서 데모를 위한 코드 작업을 간단하게 하고 결과물을 렌더링한 링크를 디자이너분께 드렸다. 나는 핫 리로드되는 결과물을 보면서 편하게 개발할 수 있었고, 디자이너 분께도 실시간으로 수정 내역을 보여드리며 커뮤니케이션할 수 있는 좋은 방법이었다고 생각한다.
다만 이 애니메이션 작업이 꽤나 오래걸렸는데 요 부분은 조금 아쉽긴 하다. 아무리 눈으로 직접 보면서 의사소통을 한다 하더라도 코드를 수정하는 사람은 개발자이다 보니까, 디자이너분 입장에서는 디자이너 입장에서 구현한 명확한 데모가 없는 상황에서 개발자에게 원하는 것을 어떻게 말해야할지 부터 어려우셨을 테다. 그걸 듣는 개발자도 디자이너의 의도와 다르게 해석할 여지가 있기 때문에 시간이 배로 걸렸던 듯 하다.