본문 바로가기
2026년 8월 20일6분 읽기

INP(Interaction to Next Paint) — 웹 성능의 새 기준, 왜 FID를 밀어냈나

YS
김영삼
조회 3
INP(Interaction to Next Paint) — 웹 성능의 새 기준, 왜 FID를 밀어냈나

INP(Interaction to Next Paint)는 사용자가 버튼을 누르거나 화면을 두드렸을 때, 그 반응이 눈에 보이기까지 걸리는 시간을 재는 웹 성능 지표다. 페이지가 처음 뜨는 속도가 아니라 이미 떠 있는 페이지가 얼마나 잘 반응하는지를 측정한다는 점에서, 오랫동안 쓰이던 FID(First Input Delay)를 밀어내고 구글의 핵심 웹 지표(Core Web Vitals) 자리를 차지했다.

바뀐 지 시간이 꽤 지났는데도 현장에서 INP를 제대로 이해하고 대응하는 팀은 의외로 적다. 로딩 속도만 신경 쓰다가, 정작 사용자가 답답함을 느끼는 지점은 놓치고 있는 경우가 많기 때문이다.

FID는 첫 클릭의 '지연'만 봤지만, INP는 방문 내내 일어난
모든 상호작용의 응답성을 본다.

그래서 스크립트가 무거운 대시보드, 필터가 많은 커머스, 자바스크립트로 상태를 관리하는 SPA일수록 기존 점수보다 나빠지기 쉽다. 지표가 엄격해진 게 아니라, 원래 있던 문제가 드러난 것에 가깝다.

200ms
'좋음' 기준
이하면 통과
전체상호작용
첫 클릭만
→ 방문 전체
3구간
입력·처리
·렌더 지연
CWV지표
검색 순위에도
영향 요소

왜 FID를 버렸나

FID의 맹점은 이름에 다 들어 있다. First, 첫 번째 입력만 잰다. 그것도 '지연'만, 즉 브라우저가 이벤트 핸들러를 실행하기까지 기다린 시간만 측정했다. 핸들러가 실행된 뒤에 무슨 일이 벌어지든, 화면이 실제로 바뀌기까지 얼마가 걸리든 FID는 관심이 없었다.

문제는 사용자가 체감하는 답답함이 바로 그 '뒷부분'에 있다는 것이다. 필터를 눌렀는데 목록이 다시 그려지는 데 400ms가 걸리고, 좋아요를 눌렀는데 하트가 채워지기까지 화면이 얼어붙는다. FID는 이걸 전부 놓쳤고, 그 결과 많은 사이트가 FID 점수는 만점인데 실제로는 굼떴다. INP는 이 간극을 메우려고 등장했다.

INP는 세 구간으로 쪼개서 본다

하나의 상호작용을 INP는 세 토막으로 나눠 측정한다. 최적화의 출발점이 여기에 있다.

  • 입력 지연(Input delay) — 사용자가 누른 순간부터 이벤트 핸들러가 실제로 돌기 시작할 때까지. 메인 스레드가 다른 작업으로 꽉 차 있으면 여기서 밀린다.
  • 처리 시간(Processing time) — 핸들러 안의 코드가 도는 시간. 상태 계산, 데이터 가공, 무거운 리렌더 트리거가 몰리는 구간이다.
  • 표시 지연(Presentation delay) — 코드가 끝난 뒤 브라우저가 다음 프레임을 실제로 그려 화면에 반영하기까지. 레이아웃과 페인트 비용이 크면 늘어난다.

세 구간을 나눠 보면 처방이 달라진다. 입력 지연이 크면 메인 스레드를 비워야 하고, 처리 시간이 길면 핸들러 로직을 쪼개거나 미뤄야 하며, 표시 지연이 크면 DOM 구조와 CSS를 손봐야 한다. 뭉뚱그려 "느리다"고 하면 손을 못 대지만, 셋으로 나누면 어디를 고칠지 보인다.

무엇을 어떻게 손보나

실무에서 INP를 낮추는 방법은 화려한 신기술보다 지루한 기본기에 가깝다.

  • 긴 작업 쪼개기 — 50ms를 넘기는 자바스크립트 작업이 있으면 상호작용이 그 뒤에 줄을 선다. 작업을 잘게 나누고, 급하지 않은 일은 브라우저가 한가할 때로 미룬다.
  • 급하지 않은 갱신은 나중에 — 클릭에 대한 시각적 피드백(버튼 눌림, 하트 채움)을 먼저 그리고, 무거운 목록 재계산은 다음 프레임으로 넘긴다. 리액트의 전환(transition) 개념이 노리는 지점이 이것이다.
  • 서드파티 스크립트 다이어트 — 태그 매니저, 채팅 위젯, 광고 스크립트가 메인 스레드를 잡아먹는 경우가 흔하다. INP가 나쁜 사이트를 열어보면 범인이 대개 여기 있다.
  • DOM 크기 줄이기 — 노드가 수만 개인 페이지는 무엇을 바꾸든 페인트 비용이 크다. 가상 스크롤이나 콘텐츠 가시성으로 그리는 양 자체를 줄인다.

지표를 어떻게 읽어야 하나

INP는 '실험실 값'과 '실사용자 값'이 크게 다를 수 있는 지표다. 개발자 도구에서 재는 값은 깨끗한 환경에서 나오지만, 실제 사용자는 저사양 폰에서 탭 여러 개를 켜둔 채 광고까지 로드하며 쓴다. 그래서 실사용자 데이터(필드 데이터)를 봐야 진짜 문제가 보인다.

항목INPFID(과거)
측정 대상방문 중 모든 상호작용첫 입력 하나
재는 것입력→화면 반영 전체핸들러 시작 지연만
'좋음' 기준200ms 이하100ms 이하
체감과의 일치높음낮음(과대평가)

INP로 넘어오면서 많은 팀이 처음으로 "우리 사이트가 사실은 굼떴다"는 걸 데이터로 마주했다. 불편한 경험이지만 건강한 변화다. 로딩만 빠르고 상호작용은 답답한 웹은, 사용자 입장에선 그냥 느린 웹이었으니까.

자주 묻는 질문

INP는 로딩 속도 지표인가요?

아니다. INP는 페이지가 이미 떠 있는 상태에서 사용자의 조작에 얼마나 빨리 반응하는지를 잰다. 초기 로딩 속도는 LCP 같은 별도 지표가 담당하며, 둘은 완전히 다른 문제를 가리킨다.

INP 값이 나쁘면 검색 순위가 떨어지나요?

INP는 핵심 웹 지표에 포함되므로 검색 순위에 영향을 주는 요소 중 하나다. 다만 콘텐츠 품질 등 다른 요인이 훨씬 크게 작용하므로, INP만으로 순위가 결정된다고 보기는 어렵다. 나쁜 응답성은 이탈률을 높여 간접적으로도 손해다.

SPA는 INP가 불리한가요?

구조적으로 불리한 경향이 있다. 자바스크립트로 상태와 렌더링을 직접 관리하다 보니 상호작용마다 메인 스레드 부담이 크기 때문이다. 다만 급하지 않은 갱신을 미루고 작업을 쪼개는 기법으로 충분히 개선할 수 있다.

실험실 점수가 좋은데 필드 값이 나쁩니다. 왜죠?

실험실은 고사양 기기와 깨끗한 네트워크를 가정하지만, 실사용자는 저사양 폰과 서드파티 스크립트, 백그라운드 탭이 뒤섞인 환경에서 쓴다. 개선의 기준은 언제나 실사용자 데이터여야 한다.

댓글 0

아직 댓글이 없습니다.
Ctrl+Enter로 등록