원문 캡처 · comparegrids.com
원문 캡처 · comparegrids.com

스크롤 중 그리드에 빈 공간이 생기는 이유는 데이터가 아직 도착하지 않았거나, 렌더링이 따라오지 못했거나, 행 높이 측정이 잘못됐거나, 의도된 로딩 표시일 수 있다. 원인에 따라 해결책이 다르므로 데이터 부족, 렌더링 부족, 잘못된 위치에 그려진 콘텐츠를 먼저 구분해야 한다. 스크린샷 한 장만으로는 어느 단계의 문제인지 판단할 수 없다.

제공된 벤치마크에는 빈 행 동작과 스크롤의 부드러움에 대한 수동 평가가 포함돼 있다. 이 평가는 문서화된 설정에서 관찰한 내용이지만 인과관계를 진단해 주지는 않는다. 낮은 점수만으로 네트워크 로딩, 셀의 복잡성, 그리드의 작업 스케줄링 중 무엇이 병목인지 알 수 없다. 해결책을 제안하기 전에 계측을 통해 현상을 재현해야 한다.

데이터 로딩과 렌더링 구분하기

빈 공간이 나타날 때 행 모델과 네트워크 타임라인을 확인한다. 필요한 레코드를 아직 요청 중이라면 서비스 지연 시간, 요청 묶음 처리, 캐시 정책을 살펴본다. 레코드가 이미 도착했다면 메인 스레드 작업과 렌더링을 점검한다. 이 구분을 먼저 해야 데이터가 없는 상황에서 렌더링 버퍼만 키우느라 시간을 낭비하지 않는다.

로딩 플레이스홀더는 의미가 분명해야 한다. 예를 들어 AG Grid는 서버 사이드 모델의 로딩 행을 문서화하고 있다. 관련 문서 이런 상태는 우연히 생긴 빈 화면과 같지 않다. 플레이스홀더가 제때 표시되는지, 올바른 쿼리에 연결돼 있는지, 적절한 레코드로 바뀌는지 평가한다. 요청이 실패했을 때의 동작과 재시도도 확인한다.

응답이 도착해도 데이터 변환이나 파싱이 메인 스레드를 막으면 바로 사용할 수 없을 수 있다. 응답 완료부터 행을 사용할 수 있게 될 때까지 걸리는 시간을 기록한다. 이 단계가 병목이라면 불필요한 변환을 줄이거나 묶음 처리 방식을 바꾸는 방안을 검토한다. 작업을 워커로 옮기면 자동으로 나아진다고 가정하지 말고, 통신과 변환 비용도 측정한다.

렌더링 범위와 셀 작업 점검하기

가상화된 그리드는 뷰포트 주변에 렌더링 영역을 유지한다. 화면 이동이 다음 영역을 준비하는 속도보다 빠르면 콘텐츠가 덜 채워져 보일 수 있다. 버퍼를 키우면 일부 작업 부하에서 위험을 줄일 수 있지만 렌더링 작업과 유지되는 요소도 늘어난다. 가능한 한 큰 값을 고르기보다 실제 셀과 이동 패턴에 맞춰 조정한다.

마우스 휠을 천천히 움직이는 경우, 빠르게 스크롤하는 경우, 스크롤바 손잡이를 끄는 경우, 먼 레코드로 이동하는 경우를 각각 시험한다. 동작마다 요구되는 처리가 다르다. 순차적으로 이동할 때 잘 작동하는 설정도 화면 범위가 갑자기 바뀌면 어려움을 겪을 수 있다. 열이 많은 앱이라면 가로와 대각선 이동도 포함한다.

고정 행과 고정 열은 별도의 렌더링 경로를 사용할 수 있다. 고정 영역과 스크롤 영역의 경계에서 정렬이 어긋나거나 업데이트가 지연되는지 살펴본다. 새로 렌더링된 셀 옆에 고정 열이 이전 레코드를 표시한다면, 잠깐의 빈 공간보다 심각하다. 어떤 값들이 한 레코드에 속하는지 잘못 보여줄 수 있기 때문이다.

진단 실험으로 운영 환경의 렌더러를 일반 텍스트로 바꿔 본다. 증상이 나아지면 서식, 아이콘, 컨트롤을 하나씩 다시 추가한다. 이는 애플리케이션 작업의 영향을 분리하기 위한 실험이지, 일반 텍스트 설정이 제품 요구사항을 충족한다는 뜻은 아니다. 최종 수정안은 사용자가 필요한 정보와 상호작용을 보존해야 한다.

반복되는 계산과 레이아웃 측정도 확인한다. 값 서식 지정은 한 번이면 비용이 적더라도 움직일 때마다 많은 셀에서 반복되면 부담이 될 수 있다. 입력값과 무효화 규칙을 이해한 경우에만 캐시한다. 특히 편집이나 실시간 업데이트가 있는 앱에서는 스크롤을 부드럽게 하려고 오래된 값을 표시해서는 안 된다.

모든 컨트롤을 계속 마운트할 필요가 있는지도 검토한다. 편집을 시작하기 전에는 간단한 값을 보여주고, 활성 셀에만 풍부한 편집기를 만들 수 있다. 일반적인 렌더링 작업을 줄일 수 있지만 포커스와 상호작용 방식이 달라진다. 키보드 입력, 유효성 검사, 편집기 제거를 시험해 새 사용성 문제가 생기지 않는지 확인한다.

행의 크기와 정체성 확인하기

행 높이를 잘못 가정하면 데이터와 렌더러가 빠르더라도 빈 공간이나 갑작스러운 이동이 생길 수 있다. 줄 바꿈 텍스트, 글꼴 로딩, 상세 정보 펼치기, 열 크기 조정을 시험한다. 그리드가 측정된 높이를 지원한다면 콘텐츠가 바뀔 때 측정값이 무효화되는지 확인한다. 고정 높이를 요구한다면 앱이 그 조건을 조용히 어기지 않는지도 살펴본다.

요소를 재활용할 때는 행의 안정적인 식별자가 중요하다. 스크롤 중 정렬이나 필터를 바꾸고 값, 선택 상태, 편집기가 올바른 레코드에 계속 연결되는지 확인한다. 오래된 셀은 렌더링 지연처럼 보일 수 있지만 실제로는 상태 매핑 오류일 수 있다. 진단용 열에 식별자를 표시하면 이런 문제를 관찰하기 쉽다.

그리드뿐 아니라 컨테이너도 살펴본다. 크기가 계속 바뀌는 상위 요소, 숨겨진 탭, 높이 제한이 없는 컨테이너는 초기화와 측정에 영향을 줄 수 있다. 실제 레이아웃에서 문제를 재현한 다음 조건을 조심스럽게 줄여 간다. 문제를 일으키는 조건까지 유지하지 않는다면 최소 재현 사례는 유용하지 않다.

매우 큰 데이터의 스크롤 확인하기

가상화를 사용하더라도 행 수가 매우 많으면 화면상의 위치 계산 문제가 생긴다. AG Grid 문서는 브라우저 높이 제한과 대규모 행 처리를 위한 접근 방식을 설명한다. 관련 문서 구체적인 동작은 구현에 따라 다르다. 수백만 행을 나타내는 스크롤바가 레코드마다 요소 하나를 두는 작은 기본 문서처럼 동작한다고 가정해서는 안 된다.

데이터의 처음, 중간, 끝에 도달할 수 있는지 시험한다. 마지막 레코드에 접근할 수 있는지, 특정 위치로 이동했을 때 의도한 레코드에 도착하는지 확인한다. 인터페이스에 신뢰할 수 있는 검색이나 레코드 이동 기능이 있는지도 살펴본다. 일부 업무에서는 모든 행을 연속으로 스크롤하는 듯한 경험보다 레코드를 찾는 기능이 더 중요하다.

극단적인 동작 하나만으로 제품을 진단하지 않는다. 의도적으로 가속하는 스크롤 방식은 위치의 정밀도를 낮추는 대신 먼 위치까지 빠르게 이동하도록 설계될 수 있다. 실제 사용자가 하는 동작에서 어떻게 작동하는지 기록하면서 경계 조건도 시험한다. 작은 목록의 스크롤바와 다르게 동작하는 모든 경우를 결함으로 취급하지 말고, 그 절충점을 설명한다.

사용자가 보는 현상 측정하기

반복 가능한 이동 순서를 영상이나 추적으로 기록하고, 화면의 빈 공간을 요청 및 긴 작업과 대조한다. 빈 프레임, 로딩 플레이스홀더, 오래된 콘텐츠 오류를 각각 어떻게 정의하는지 정한다. 시간을 보고한다면 관찰 방법과 해상도를 명시한다. 주관적인 시각적 인상만으로 정밀한 수치를 만들어내지 않는다.

반응성과 완전성을 따로 평가한다. 그리드가 포인터를 부드럽게 따라가도 셀이 잠시 비어 있을 수 있고, 모든 셀을 채워도 이동이 끊길 수 있다. 둘 다 사용성에 영향을 주지만 서로 다른 결과다. 이동을 멈춘 직후 레코드가 올바른지, 바로 작업을 수행할 수 있는지도 함께 평가한다.

같은 뷰포트, 데이터셋, 렌더러 복잡성에서 설정을 비교한다. 버퍼 설정과 지연 렌더링 옵션을 기록한다. 공급업체 권장 설정으로 문제가 해결되면 변경 전후 설정을 보관하고 다른 주요 업무 흐름도 확인한다. 스크롤 개선이 편집이나 접근성을 조용히 악화시켜서는 안 된다.

관찰한 병목을 해결하기

유용한 조사는 블록 요청 지연, 렌더러 작업 과다, 잘못된 화면 계산, 불안정한 식별자, 문서화된 스케줄링상의 절충점처럼 범위를 좁힌 설명으로 끝난다. 그 설명에 재현 방법과 근거를 첨부한다. 그러면 팀이 구체적으로 대응할 수 있고 이후 담당자도 같은 문제가 다시 발생했을 때 알아볼 수 있다.

대표성이 있는 저사양 기기와 예상 네트워크 조건에서 다시 시험한다. 작업을 다른 단계로 옮기기만 한 수정은 개발용 컴퓨터에서 성공한 것처럼 보여도 사용자 경험을 바꾸지 못할 수 있다. 처음 진단에 쓴 상황을 회귀 검사로 유지하고, 모든 설정에서 빈 행이 절대 생기지 않는다고 약속하는 대신 지원하는 작업 조건을 보고한다.