우리가 측정하지 않은 곳에서 사용자는 기다리고 있었다
2024년 3월, Google이 INP(Interaction to Next Paint)를 Core Web Vital로 공식 지정했다. 그런데 흥미로운 건 대부분의 팀이 이미 LCP는 초록불이었다는 점이다. 히어로 이미지 최적화, CDN 세팅, preload 태그—로딩 성능 이야기는 슬라이드 한 장으로 설명하기 좋았다. 문제는 그 페인트 이후, 사용자가 실제로 클릭하는 순간들을 아무도 측정하지 않았다는 것이다.
dev.to에 공유된 에이전시 실무 사례("INP in production: what we wish we had measured earlier")는 이 맹점을 정직하게 털어놓는다. 감사 대상 URL은 홈페이지였고, 측정 도구는 PageSpeed Insights와 Lighthouse였다. FID는 거의 항상 통과했기 때문에 "상호작용성은 해결됐다"고 믿었다. 그러나 INP가 실제로 문제 삼는 건 첫 번째 탭이 아니다. 장바구니 단계, 패싯 필터 적용, 멀티스텝 폼 제출—로드 이후 다섯 번째 인터랙션에서 사용자는 비로소 지연을 체감한다.
INP가 드러낸 것: 측정하지 않으면 존재하지 않는 문제
FID가 괜찮아 보였던 이유는 단순하다. FID는 첫 번째 입력 지연만 측정하고, 이후 상호작용은 무시한다. INP는 방문 전반의 모든 인터랙션을 추적한다. 같은 템플릿에 포함된 글로벌 네비게이션, 동의 배너, 챗 위젯—하나의 느린 핸들러가 그것을 포함한 모든 URL의 INP를 망친다. 그리고 대부분의 팀은 "지난 분기에 성능을 고쳤다"는 이유로 그 URL들을 재측정하지 않는다.
특히 주목할 점은 크로스 오리진 iframe 문제다. 서드파티 임베드 내부의 느린 인터랙션은 사용자 경험에는 반영되지만, 개발자의 JavaScript로는 프레임 내부를 들여다볼 수 없다. 이 경우 유일한 증거는 필드 데이터와 DevTools의 프레임 선택뿐이다. Lighthouse의 Total Blocking Time이 좋아 보여도 CrUX가 "needs improvement"를 외칠 때, 그 원인은 거의 항상 히어로 페인트 이후에도 바쁜 JavaScript였다.
이 팀이 결론적으로 바꾼 건 측정 습관이다. 홈페이지 하나가 아닌 실제 사용자 여정을 대표하는 3~6개 URL을 선정하고, 그 중 최소 하나는 로그인 후 영역이나 체크아웃 플로처럼 포스트로드 여정이어야 한다. 모바일과 데스크톱을 분리하고, 태그 매니저나 프레임워크 업그레이드 이후 반드시 재베이스라인을 측정한다. 핵심은 이것이다: 성능 측정의 대상이 '로딩 문제'에서 '상호작용 여정'으로 이동해야 한다.
AI 에이전트가 실사용자 데이터로 홈페이지를 다시 썼다
INP가 "측정하지 않은 상호작용"의 문제를 드러냈다면, 다음 질문은 자연스럽게 이어진다. 측정한 뒤에는 어떻게 고칠 것인가? 그리고 그 판단을 누가, 어떻게 내릴 것인가?
dev.to의 또 다른 사례("My autonomous agent scraped 35 real questions from French renters — then rewrote our homepage")는 이 질문에 대한 급진적인 답을 보여준다. 프랑스 주거권 SaaS인 BailleurVérif의 운영자는 자율 에이전트를 설계했다. 이 에이전트는 2시간마다 깨어나고, 12시간마다 전략적 감사 보고서를 읽은 뒤 처방을 자율 실행한다. 인간의 개입 없이.
감사 26번째 사이클에서 에이전트는 스스로 문제를 발견했다. 홈페이지 카피가 "당신은 아마 임대료가 적법한지 궁금하실 겁니다..."라는 카피라이터의 가설로 가득 차 있다는 것. 처방은 명확했다: Reddit에서 실제 임차인 질문 30개 이상을 수집하고, 그 데이터로 홈페이지 히어로를 교체하라.
에이전트는 Python 스크립트를 작성해 프랑스어 서브레딧 5곳을 대상으로 레이트 리밋을 준수하며 스크래핑했다. 50개 원시 결과에서 질 필터를 적용해 35개를 추렸다—집주인 질문, 상업 임대 질문, 노이즈 키워드를 포함한 15개를 제거했다. 태그별 상위 3개 질문이 선정됐고, 이를 기반으로 776줄의 HTML이 생성됐다. 다음 감사 사이클이 홈페이지 스왑을 처방했고, 에이전트는 index.html의 22줄을 수정해 커밋했다. 전체 사이클: 16시간, 운영자 메시지: 0건.
결과는 단순하지만 강력하다. "당신은 아마 궁금하실 겁니다"라는 문장이 r/paris · 93 upvotes 배지가 달린 실제 임차인 질문으로 교체됐다. 가설이 증거로 대체된 것이다.
루프가 닫히는 순간: 측정 → 분석 → 반영
두 사례를 겹쳐 보면 하나의 흐름이 보인다. INP는 "우리가 측정하지 않았던 상호작용이 실제 사용자 경험을 결정하고 있었다"는 사실을 드러냈다. BailleurVérif의 에이전트는 "우리가 가설로 썼던 카피 대신 실제 사용자 언어가 더 정확하다"는 사실을 증명했다. 둘 다 같은 실수를 가리킨다: 우리는 사용자가 실제로 경험하는 것이 아니라, 우리가 경험할 거라고 믿었던 것을 기준으로 제품을 만들어왔다.
이 루프를 설계하려면 세 가지 레이어가 필요하다. 첫째, 측정 대상을 로딩이 아닌 상호작용 여정으로 재정의하는 것—INP 기준에서라면 포스트로드 URL을 감사 목록에 반드시 포함시키는 것이다. 둘째, 수집된 데이터가 실제 UI 결정으로 이어지는 연결을 만드는 것—BailleurVérif처럼 자동화할 수도 있고, 주간 리뷰 프로세스에 필드 INP 수치와 사용자 질문 데이터를 함께 올려놓는 것으로 시작할 수도 있다. 셋째, 이 사이클의 주기를 명시하는 것—"지난 분기에 고쳤다"는 기억이 측정의 빈도를 대체하는 순간, 루프는 끊긴다.
자율 에이전트가 프로덕트 루프에 들어올 때
BailleurVérif 사례에서 흥미로운 부분이 하나 더 있다. 에이전트가 방문 데이터를 분석하다가 "직접 유입"의 60%가 봇이었음을 발견한 것이다. 159개 세션에서 UA 필터링 후 실제 인간은 63개. 에이전트는 이후 raw 방문 수 대신 direct_humans_after_ua_filter를 별도 지표로 추적하기 시작했다. 측정 기준 자체를 스스로 교정한 것이다.
이것은 단순한 자동화가 아니다. 측정 → 이상 발견 → 기준 재정의 → 반영이라는 루프를 에이전트가 스스로 실행하고 있다. 물론 이 수준의 자율성은 대부분의 팀에 당장 필요하지 않을 수 있다. 하지만 이 사례가 증명하는 것은 분명하다: 루프 자체를 설계해두면, 그것을 실행하는 주체가 인간이든 에이전트든 결과는 수렴한다—사용자가 실제로 경험하는 제품으로.
지금 당장 할 수 있는 것
INP 감사를 시작하려면 복잡한 도구가 필요하지 않다. Chrome DevTools Performance 패널을 열고, 미드티어 폰 프로파일로 실제 사용자가 수행하는 다섯 가지 클릭을 기록하면 된다. 그 결과가 현재 모니터링 목록에 없는 URL을 포함한다면, 지금 팀의 성능 거버넌스는 여전히 로딩 문제만 보고 있는 것이다.
사용자 언어 수집도 마찬가지다. Reddit, 커뮤니티 포럼, 고객 지원 로그—인증 없이 접근 가능한 실사용자 데이터는 생각보다 가까이 있다. 그것을 카피라이터의 가설 위에 덮어씌우는 데 AI가 필요한 건 맞지만, 그 전에 필요한 건 루프를 설계하겠다는 의도다.
측정하지 않은 인터랙션은 존재하지 않는 인터랙션이 아니다. 사용자는 그 사이에서 기다리고 있다.