AI 에이전트로 INP 해결하기: 실험실 도구로는 측정할 수 없는 지표

Interaction to Next Paint는 AI 에이전트에게 가장 까다로운 Core Web Vitals입니다. 시뮬레이션이 불가능하기 때문입니다. Lighthouse에는 INP 점수가 없습니다. 실제 사용자 데이터가 없는 AI 에이전트는 어떤 상호작용이 느린지, 누가 그것을 경험하는지, 페이지 수명 주기의 어느 시점에 발생하는지 알려줄 수 없습니다. 필드 데이터가 있을 때 INP를 해결하는 방법은 다음과 같습니다.

최종 검토: Arjen Karel (2026년 3월)

AI 에이전트에게 INP가 다른 이유

INP는 클릭, 탭, 키 누름 등 사용자 상호작용에 사이트가 얼마나 빠르게 반응하는지 측정합니다. 전체 세션에서 가장 최악의 단일 상호작용을 선택합니다. 여기서 핵심 단어는 실제(real)입니다. 사용자가 서드파티 분석 스크립트가 실행되는 동안 제품 페이지에서 필터 드롭다운을 클릭한다고 가정해 보겠습니다. 이때 발생하는 380ms의 지연이 해당 세션의 INP가 됩니다.

어떤 실험실 도구도 이를 재현할 수 없습니다. Lighthouse는 Total Blocking Time을 프록시로 사용하지만, TBT는 페이지 로드 중 메인 스레드 차단을 측정합니다. INP는 세션 내내 예측할 수 없는 순간에 발생하는 상호작용에 대한 응답 시간을 측정합니다. TBT가 0인 페이지라도 백그라운드 타이머가 잘못된 순간에 실행되면 끔찍한 INP를 가질 수 있습니다. 필드 데이터가 없는 에이전트는 이를 전혀 파악하지 못합니다. 실제 사용자가 클릭이 등록될 때까지 400ms를 기다리는 동안에도 에이전트는 TBT만 최적화하고 성공을 선언해버립니다.

세 가지 단계, 세 가지 다른 해결책

INP는 세 단계로 나뉩니다. 각 단계는 다른 해결책을 의미합니다.

Input Delay: 사용자가 상호작용할 때 메인 스레드가 바빴던 상태입니다. 로드(loading) 상태에서는 대규모 JavaScript 번들 실행, 분석 스크립트 초기화 또는 프레임워크 하이드레이션(hydration)이 일반적인 원인입니다. 완료(complete) 상태(페이지가 완전히 로드됨)에서는 백그라운드 타이머, 업데이트를 폴링하는 서드파티 스크립트 또는 서비스 워커 활동이 원인일 수 있습니다.

Processing: 이벤트 핸들러 자체가 너무 느린 경우입니다. 레이아웃 스래싱(Layout thrashing)(루프 내에서 DOM 읽기, DOM 쓰기, DOM 읽기 반복), 핸들러 내부의 동기식 DOM 쿼리, 비용이 많이 드는 리렌더링, 또는 단순히 yield 없이 단일 작업에서 너무 많은 작업을 수행하는 것이 원인입니다.

Presentation: 핸들러가 완료된 후 브라우저가 페인트하는 데 너무 오래 걸리는 경우입니다. 대규모 DOM 트리(스타일 재계산이 필요한 수천 개의 노드), CSS containment 누락, 또는 핸들러의 DOM 변경으로 인해 촉발된 비용이 많이 드는 페인트 작업이 원인입니다.

어떤 스크립트가 페이지를 차단하고 있는가

CoreDash는 실제 사용자 세션에서 Long Animation Frames (LoAF) 기여도를 캡처합니다. 이를 통해 에이전트는 추측하는 대신 실제로 INP를 해결할 수 있습니다.

LoAF는 정확한 JavaScript 파일, 함수 및 소요 시간을 명시합니다. 에이전트는 어떤 스크립트가 메인 스레드를 차단하고 있는지 추측하지 않습니다. CoreDash가 알려줍니다: 결제 페이지 필터 상호작용 중에 gtm-container.js가 메인 스레드를 280ms 동안 차단했다는 식으로 말입니다.

"페이지가 느립니다" 대신 "이 파일, 이 함수, 이 지속 시간"이라는 구체적인 정보를 얻게 됩니다. Total Blocking Time이 450ms라고 알려주면서 30개의 스크립트 중 어떤 것이 원인인지 직접 알아내라고 방치하는 Lighthouse와 비교해 보세요.

에이전트는 파일을 열고 코드를 읽은 다음 수정 사항을 작성합니다: 지연(defer)시키거나, 더 작은 작업으로 나누거나, 아무도 필요로 하지 않는다면 제거해 버립니다.

Loading 대 loaded: 두 가지 다른 문제

상호작용이 loading 상태에서 일어났는지 complete 상태에서 일어났는지에 따라 해결책이 완전히 달라집니다.

loading 상태에서만 INP가 나쁘다면 스크립트 로드 순서가 문제입니다. 페이지가 상호작용하기 전에 너무 많은 JavaScript가 실행되고 있는 것입니다. 해결책은 스크립트 지연(script deferral)에 있습니다. 비핵심 스크립트를 지연시키고, 코드 스플리팅(code-split)을 적용하며, 파서 차단 JavaScript를 줄이세요.

complete 상태에서 INP가 나쁘다면 런타임 JavaScript 문제가 있는 것입니다. 완전히 로드된 페이지의 백그라운드에서 무언가가 실행되고 있습니다. 업데이트를 폴링하는 서드파티 스크립트, 비콘을 전송하는 분석 도구 또는 타이머에 의해 비용이 많이 드는 작업을 실행하는 자체 코드일 수 있습니다.

CoreDash는 모든 INP 측정에 대해 페이지 로드 상태를 추적합니다. CWV Superpowers는 이를 사용하여 스크립트를 살펴보기 전에 원인의 절반을 배제합니다.

INP를 위한 비례적 추론(Proportional reasoning)

결제 페이지의 INP가 350ms입니다. 필드 데이터의 단계별 분석은 다음과 같습니다.

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

Presentation이 병목 지점입니다. 200ms는 단독으로 보면 심각하게 들리지 않을 수 있습니다. 하지만 이는 전체의 57%에 해당합니다. Presentation을 해결하는 것이 Input Delay나 Processing을 합친 것을 최적화하는 것보다 더 큰 효과를 냅니다.

비율이 없으면 에이전트는 70ms가 특정 임계값을 초과한다는 이유로 Input Delay만 쫓게 됩니다. 세부 분석을 보여주면 에이전트는 바로 57%를 향해 직진합니다. 그 결과, 지표를 거의 움직이지 못하는 분산된 3개의 수정 사항 대신 INP를 200ms 아래로 떨어뜨리는 단 1개의 수정 사항을 도출하게 됩니다.

단계별 일반적인 해결책

로딩 중 Input Delay: 비핵심 스크립트를 지연(Defer)시킵니다. 사용하지 않는 JavaScript를 제거(Remove unused JavaScript)합니다. 현재 페이지에 필요한 코드만 로드되도록 코드 스플리팅을 적용합니다.

완료 시 Input Delay: 페이지 로드 후 실행되는 서드파티 스크립트를 감사(Audit)합니다. CoreDash의 LOAF 데이터를 사용하여 문제를 일으키는 스크립트를 찾습니다. requestIdleCallback을 사용하여 유휴 시간(idle time)으로 지연시킵니다.

Processing: scheduler.yield() 또는 setTimeout(0)을 사용하여 메인 스레드에 yield합니다. 긴 이벤트 핸들러를 더 작은 작업으로 분할합니다. 강제 레이아웃(DOM에 쓴 직후에 레이아웃 속성을 읽는 행위)을 피하세요.

Presentation: 폴드 아래의 대규모 DOM 섹션에 content-visibility: auto를 사용하세요(2025년 9월부터 모든 주요 브라우저에서 지원됨). 핸들러의 변경 사항에 영향을 받는 DOM 노드 수를 줄입니다. CSS containment를 사용하여 리페인트를 더 작은 영역으로 격리하세요.

필드 데이터로 검증하기

INP 개선 사항은 실제 트래픽이 발생한 후 하루나 이틀 내에 CoreDash에 나타납니다. 동일한 페이지와 기기 세그먼트를 쿼리하세요. p75 수치가 떨어지고 단계 분포가 이동해야 합니다.

로드 상태 분할도 주의 깊게 살펴보세요. 수정 사항이 loading 상태의 INP를 대상으로 한 경우, complete 상태의 수치가 악화되지 않으면서 loading 상태 수치가 개선되었는지 확인합니다. 필드 데이터는 이러한 세분성을 제공하지만, 실험실 데이터는 그렇지 않습니다.