Lighthouse 점수는 유동적이지만, 기준은 고정되어야 한다

최근 홈 화면 구조와 interaction primitive를 조금씩 정리하면서 Lighthouse 측정도 함께 확인하고 있다. 흥미로운 점은 같은 화면이어도 측정 시점마다 수치가 조금씩 달라진다는 것이다. 예를 들면: * Performance 90 → 93 * Speed Index 2.0s → 1.6s * Total Blocking Time 110ms → 50ms 같은 빌드에서도 이런 변화는 충분히 발생할 수 있다. 브라우저 상태, 캐시, CPU 순간 부하, DevTools 상태, 측정 타이밍 같은 요소들이 모두 영향을 준다. 그래서 Lighthouse 점수 자체를 절대값처럼 바라보기 시작하면 운영 방향이 흔들리기 쉽다. 현재 기준은 조금 다르다. 우리는 지금: * CLS 0 유지 * layout shift 제거 * responsive primitive 정규화 * hover interaction 통일 * bundled source 중심 lifecycle 유지 * active template 직접 수정 금지 같은 구조적 안정성을 우선 기준으로 두고 있다. 이번 hover interaction 정리도 같은 맥락이다. "추천 공간" 영역의 hover 반응이 "아카이브 하이라이트"와 다르게 움직이고 있었고, 실제 움직임은 outer card가 아니라 내부 content/action affordance의 미세한 translate 효과였다. 이를 shared primitive 기준으로 다시 통일했다. 결과적으로 지금 화면은, * card 자체는 흔들리지 않고 * CLS는 계속 0을 유지하며 * 내부 interaction만 아주 작게 반응하는 상태 로 정리되고 있다. 운영 화면에서 중요한 것은 "100점"보다: * 읽기 안정성 * 흐름 유지 * 시각적 피로 감소 * 구조 일관성 * 유지보수 가능성 에 더 가깝다. Lighthouse는 방향을 확인하는 도구로는 매우 유용하지만, 운영 기준 자체가 되어서는 안 된다고 보고 있다.