웹 프런드엔드 개발자로서 사용자가 체감하는 속도를 최적화할 방안을 고민한 경험, 누구나 있으실 겁니다. 그런 점에서 Linear는 우수한 참고 사례가 될 수 있는 제품인데요, 이 글을 통해 어떻게 빠른 사용감을 구현할 수 있었는지 살펴보시는 건 어떨까요? 자체 동기화 엔진을 만들지 않더라도 현업에 적용할 수 있는 개선점과 아키텍처의 트레이드오프도 함께 살펴볼 수 있어 추천드립니다.
Q. 프런트엔드 개발자라면 누구나 사용자에게 더 빨리 제품을 서빙하기 위해 노력할 테고 관심 많겠지요. 그런 측면에서 리니어의 사례는 배울 점도 많고, 부러운 점도 많은거 같아요 (특히 최신 브라우저만 지원하기로 한 결정같은 게요 ㅎㅎ) 여러분들의 경험중에도 특이했던 사례나 ‘이렇게까지 해봤다’하는 사례가 있었는지 궁금해요!
💬. 의견 1
대규모 목록 화면을 최적화하면서 비슷한 고민을 해본 적이 있습니다. 데이터를 미리 가져오고 캐시하며, 수정 결과를 UI에 먼저 반영하는 낙관적 업데이트를 적용했습니다. 목록 가상화와 상태 분리를 통해 값 하나가 변경될 때 전체 목록이 다시 렌더링되는 것도 줄였습니다.
가장 효과가 컸던 것은 복잡한 최적화보다 초기 화면에서 필요하지 않은 기능을 지연 로딩하고, 지원할 브라우저 범위를 줄인 일이었습니다. 다만 Linear처럼 IndexedDB와 동기화 엔진까지 구축하는 것은 유지보수 비용이 크기 때문에, 제품 특성에 따라 캐싱이나 프리페치 정도만 적용하는 것이 더 합리적일 수 있다고 생각합니다.
💬. 의견 2
Linear의 속도가 특정 기술 하나가 아니라, 로컬 퍼스트부터 번들 분할과 프리로드까지 작은 설계 결정들이 쌓인 결과라는 점이 인상적이었습니다. 비슷한 규모의 로컬 퍼스트 구조를 구현해본 경험은 없지만, 번들 최적화와 데이터 prefetch, 목록 가상화처럼 사용자의 대기 시간을 줄이는 방식은 적용해봤습니다.
조금 특이했던 사례라면, 최근 사이드 프로젝트에서 DOM 요소가 계속 누적되는 것을 피하기 위해 많은 요소는 Canvas로 그리고 직접 조작이 필요한 일부만 DOM으로 렌더링한 경험이 있습니다. 성능 문제가 생긴 뒤 최적화하기보다, 데이터가 늘어날 상황을 고려해 처음부터 렌더링 구조를 나눠 설계했다는 점에서 기억에 남습니다.
다룰 내용
브라우저 안의 데이터베이스
Linear의 기술 스택 들여다보기
첫 로딩을 즉각적으로 느끼게 만들기
Linear 번들러의 여정: Parcel, Rollup, Vite, Rolldown
첫 로딩 후 미리 불러오기
속도와 오프라인 기능을 한층 끌어올리는 서비스 워커
벤더 번들 구성
대용량 폰트 파일 불러오기
인라인 앱 셸
먼저 렌더링하고 나중에 인증하기
동기화 엔진
1. 데이터가 이미 존재합니다
2. 변경 작업이 네트워크를 기다리지 않습니다
3. 변경 하나, 셀 하나
세 가지가 맞물려야 하는 이유
속도를 고려한 설계
모든 작업에 단축키가 있습니다
명령 팔레트는 언제나 키 하나면 열립니다
애니메이션
애니메이션을 적용할 프로퍼티는 몇 가지뿐입니다
절제할 때를 알아야 합니다
지속 시간은 짧고 경쾌하게
Linear가 이렇게 빠른 이유
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.