본문 바로가기
서비스 웹 서비스 개발 앱 개발 AI 알고리즘 개발 AI 컨설팅 AI 마케팅 프로젝트 인사이트 회사소개 고객게시판
웹 성능 8 MIN READ

관리자 화면은 열렸는데 클릭이 늦다면: INP로 업무 반응 속도 찾기

테이블 필터·탭 전환·검색 입력이 답답한 B2B 관리자 화면에서 INP를 측정하고 긴 작업, 이벤트 처리, 렌더링을 분리해 개선하는 방법.

Category
웹 성능
Published
Read
8분
Author
네이처프랙탈
관리자 화면은 열렸는데 클릭이 늦다면: INP로 업무 반응 속도 찾기 대표 이미지

관리자 화면이 처음에는 빨리 열립니다. 그런데 담당자가 고객 목록 필터를 누르면 반응이 늦고, 두 번 눌렀다가 필터가 다시 해제됩니다. 페이지 로딩 시간만 측정하면 ‘성능 양호’로 보이지만 실제 업무는 답답합니다. B2B 화면은 한 세션에서 검색, 선택, 정렬, 일괄 작업을 반복하므로 최초 로딩 이후의 반응 속도가 특히 중요합니다.

INP(Interaction to Next Paint)는 클릭·탭·키 입력 뒤 다음 화면 변화가 나타날 때까지의 반응성을 살피는 지표입니다. web.dev의 INP 설명처럼 첫 입력만이 아니라 페이지를 사용하는 동안의 상호작용을 봅니다. 다만 INP는 서버 요청 전체 완료 시간을 대신하지 않습니다. 먼저 ‘처리 중’ 표시가 나타났는지와 최종 결과가 언제 왔는지는 함께 측정해야 합니다.

느린 클릭은 세 구간으로 나눠 본다

첫째, 입력 대기입니다. 사용자가 눌렀지만 브라우저 메인 스레드가 이미 긴 스크립트를 실행 중이면 이벤트 처리 자체가 늦게 시작됩니다. 둘째, 이벤트 처리 시간입니다. 필터 클릭 함수 안에서 수천 행 정렬·집계·상태 업데이트를 한 번에 하면 다음 단계로 못 넘어갑니다. 셋째, 표시 지연입니다. 핸들러가 끝나도 큰 DOM 변경과 스타일 계산이 남아 있으면 화면에 변화가 늦게 보입니다.

원인을 모른 채 서버 응답만 최적화하면 효과가 없을 수 있습니다. 개발자 도구의 성능 기록에서 실제 느린 클릭 하나를 재현하고, 입력 대기·핸들러·렌더링 중 어느 구간이 긴지 확인합니다. 실사용 측정에서는 민감한 입력값을 수집하지 않고 화면 종류와 상호작용 유형만 남겨도 병목을 찾는 데 도움이 됩니다.

클릭 뒤 입력 대기, 이벤트 처리, 다음 화면 표시까지 이어지는 반응 지연
INP는 클릭 처리 함수만이 아니라 사용자가 다음 화면 변화를 보기까지의 지연을 본다.

업무 테이블이 흔한 병목이다

관리자 화면은 데이터가 많을수록 한 번에 모든 행을 브라우저에 그리기 쉽습니다. 정렬·검색을 클라이언트에서 처리하더라도 표시할 행만 렌더링하거나 서버 쪽 페이지네이션을 쓰면 작업량을 줄일 수 있습니다. 다만 가상 스크롤은 키보드 탐색, 스크린리더, 선택 상태를 복잡하게 만들 수 있으므로 접근성과 인쇄·다운로드 요구를 함께 검토합니다. 화면에 필요한 열만 먼저 그리고 무거운 상세 패널은 나중에 여는 것도 방법입니다.

필터를 누른 즉시 선택 상태나 로딩 표시를 보여주고, 실제 검색 요청은 비동기로 수행합니다. 메인 스레드에서 꼭 해야 하는 계산은 작게 나누고 필요한 경우 워커로 옮깁니다. web.dev의 INP 최적화 가이드도 이벤트 콜백의 일을 줄이고 긴 작업을 나누는 접근을 권합니다.

긴 메인 스레드 작업을 작은 단계로 나눠 먼저 화면 피드백을 표시하는 비교
즉시 보여야 할 피드백을 먼저 그리고 무거운 작업은 분할하거나 뒤로 미룬다.

체감 개선과 실제 완료를 함께 지키자

로딩 표시만 빨리 띄우고 결과는 20초 뒤에 보여준다면 INP가 개선돼도 업무 경험은 나쁩니다. 필터 결과 완료 시간, 검색 실패율, 중복 클릭률, 타임아웃도 함께 봅니다. 반대로 서버 응답이 0.2초여도 브라우저가 3초 동안 테이블을 그리면 사용자는 느리다고 느낍니다. 이 두 지표를 분리해야 담당 팀도 정확히 정해집니다.

현장 기기와 네트워크도 중요합니다. 개발자 고성능 PC에서만 측정하지 말고 실제 고객의 보급형 노트북, 오래 켜 둔 브라우저, 많은 탭, 확대된 화면을 시험합니다. 클릭 지연의 평균보다 느린 구간의 분포와 어떤 작업에서 발생했는지를 살피는 편이 운영에 유용합니다.

측정 대상 화면을 고를 때는 방문 수만 보지 말고 업무 중요도를 고려합니다. 월말 정산처럼 특정 시기에만 사용되는 화면은 평소 지표에 잘 나타나지 않아도 한 번 느려지면 피해가 큽니다. 검색어 길이, 선택된 행 수, 동시에 켜진 필터 수에 따라 느린 경우도 있으므로 테스트 데이터의 크기를 단계별로 늘려 봅니다. 개선 후에는 스크롤·키보드 조작과 화면 낭독이 여전히 자연스러운지까지 확인해야 합니다.

개선 체크리스트

  1. 느린 업무 상호작용을 하나 골라 성능 추적을 남긴다.
  2. 입력 대기·이벤트 처리·표시 지연을 분리한다.
  3. 데이터량, DOM 수, 긴 작업을 줄인다.
  4. 즉시 피드백과 최종 처리 완료를 각각 측정한다.
  5. 실제 고객 기기와 접근성 동작을 재검증한다.

빠른 업무 화면은 단지 첫 화면을 빨리 여는 화면이 아닙니다. 사용자가 매번 누를 때 확실히 반응하고, 기다림의 이유와 결과를 알 수 있는 화면입니다.

#INP #웹성능 #관리자대시보드 #CoreWebVitals #반응속도 #프런트엔드 #긴작업 #사용자경험 #웹최적화 #B2B웹앱

JavaScript TypeScript 관측성

/ 다음 단계

이런 문제, 직접 겪고 계신가요?

글로 정리한 방법을 실제 환경에 맞춰 적용하는 일까지 함께 하겠습니다.

영업일 기준 3일 이내 회신 · 상담 및 범위 견적 무료