데이터 그리드 구축의 10단계

MongoDB·PostgreSQL용 데이터베이스 GUI를 만들면서 BSON·JSONB 타입, 중첩 열, 검색, 편집, 고정, 드래그를 지원해야 했고, 이를 위해 약 1년간 양축 가상화와 상태 관리 구조를 최적화함 원본 문서와 별도로 표시 문자열·타입·평탄화 경로·열 순서·검색 결과를 미리 계산하는 섀도 테이블을 만들고, 화면에 보이는 행과 열만 일정한 크기의 DOM으로 렌더링함 스크롤 경로에는 수동적 이벤트 리스너, requestAnimationFrame, 버퍼·히스테리시스, 속도 추적을 적용하고, 레이아웃 속성 대신 transform과 opacity 를 활용해 메인 스레드 작업을 줄임 셀별 아이콘을 공유 SVG 배경 이미지로 바꾸고 편집기는 필요할 때만 마운트했으며, 행과 열을 위치 기준으로 추적하는 DOM 풀링으로 스크롤 중 노드 생성을 없앰 Canvas는 DOM보다 높은 60fps 성능 상한을 제공하지만 텍스트·선택·접근성·기능 확장에 불리해, 실제 텍스트 선택과 빠른 개발을 유지하는 DOM 기반 설계를 선택함 목표와 초기 제약 단순한 2차원 배열과 중첩 반복문으로 시작했지만, 약 1년에 걸친 간헐적 최적화 작업으로 이어짐 데이터베이스 GUI의 표는 표시 전용이 아니라 다양한 상태와 상호작용을 지원해야 했음 MongoDB의 모든 BSON 타입과 PostgreSQL 등의 JSONB를 이해하고 타입별 색상 아이콘을 표시함 문자열 "123"과 정수 123처럼 쿼리 결과가 달라지는 타입을 구분함 중첩 문서를 실제 하위 열로 확장하고, 중첩 경로 전체를 검색해 셀 내부의 일치 부분을 강조함 열 재정렬·크기 변경·고정, 셀 내부 편집, 값·행·열을 시각적 쿼리 빌더로 드래그하는 기능이 필요했음 이런 기능의 상태는 원본 문서에 없으며 스크롤 이후에도 유지돼야 하므로 별도 렌더링 구조가 필요했음 1단계: 모든 항목을 직접 렌더링 행과 필드를 중첩 순회해 모든 셀을 만드는 방식은 100행에서는 동작하지만 대규모 데이터에서 무너짐 10,000행 × 30열은 약 300,000개의 DOM 노드를 만들며, 프레임워크의 변경 감지가 이들을 반복해서 순회함 DOM 노드 하나가 브라우저 내부 구조까지 약 1KB를 소비한다고 보면 실제 데이터 이전에 수백 MB가 필요함 60fps의 프레임 예산은 16.7ms이며 스타일·레이아웃·페인트도 이 시간을 공유함 실제 구현에서는 약 20열을 가진 1,000행을 렌더링하려다 실패함 일부만 렌더링하...