네이버 통합검색에 도입된 AI Briefing(AIB)은 사용자에게 AI 기반 요약과 브리핑 경험을 제공하며 검색 환경을 혁신하고 있습니다. 하지만 채팅 UI 기반의 애니메이션 인터페이스가 확장되면서 LCP(Largest Contentful Paint) 지표에 예상치 못한 영향을 미치고 있습니다. 이 글에서는 AIB 도입 이후 나타난 성능 지표 변화를 분석하고, 채팅 UI 환경에서 기존 성능 측정 방식이 실제 사용자 경험을 제대로 반영하지 못하는 구조적 한계를 살펴봅니다. 또한 네이버 검색이 TTFT(Time to First Token) 같은 새로운 지표 도입을 검토하는 배경과, 측정 체계 재설계의 필요성을 함께 논의합니다.
채팅 UI의 구조적 특성과 LCP 왜곡 현상
AIB는 2025년 3월부터 네이버 통합검색에 단계적으로 도입되었으며, 초기에는 정적인 요약 형태였으나 2025년 7월 채팅 UI 기반의 애니메이션 인터페이스가 추가되면서 상호작용 요소가 크게 확장되었습니다. 현재 네이버 통합검색에서 LCP로 측정되는 영역 중 AIB 영역이 약 10%를 차지하며, LCP 후보 영역으로 선택되는 빈도 또한 상위권에 위치합니다. 이는 AIB가 더 이상 일부 사용자에게만 노출되는 부가 기능이 아니라, 검색 성능 지표 전반에 영향을 주는 핵심 요소로 자리 잡았음을 의미합니다.
최근 네이버 통합검색의 LCP p95는 약 3.1초 수준으로 관측되며, 이는 목표인 'LCP p95 2.5초 이하'를 상회하는 값입니다. 특히 주목할 점은 AIB 노출량이 증가하는 시점과 LCP p95가 악화되는 시점이 매우 유사한 패턴을 보인다는 것입니다. 분포(distribution) 관점에서도 AIB 도입 이후 Good 구간(LCP < 2.5초)에 해당하는 사용자 비율이 줄고, 상대적으로 느린 구간에 해당하는 사용자 비율이 증가했습니다. 이는 AIB가 전체 LCP 분포의 tail 영역에 영향을 주고 있음을 보여줍니다.
흥미롭게도 구글 검색에서도 2024년 12월 AI Overview 도입 이후 유사한 현상이 관찰되었습니다. 하지만 두 서비스의 악화 양상에는 중요한 차이가 존재합니다. 구글 AI Overview는 비교적 큰 텍스트 블록 단위로 렌더링하며 애니메이션도 블록 단위로 제한적으로 적용됩니다. 반면 네이버 통합검색의 AIB는 텍스트를 어절 단위로 쪼개 점진적으로 표시하는 구조를 채택하고, 노출 애니메이션도 상대적으로 적극적으로 사용합니다. 이러한 렌더링 단위와 애니메이션 적용 방식의 차이는 사용자 경험뿐만 아니라 LCP와 같은 렌더링 기반 성능 지표가 측정되는 방식에도 직접적인 영향을 미칩니다.
비평적으로 보면, 여기서 중요한 질문은 "지표만 왜곡된 것인지, 실제로도 느린 것인지"를 명확히 구분하는 것입니다. AIB는 약 900ms 수준의 스켈레톤 UI 노출과 텍스트 애니메이션을 포함하므로, 측정 왜곡과 별개로 실제 체감 지연도 존재할 가능성이 있습니다. 첫 의미 있는 응답이 사용자에게 보이는 시점과 그 시점의 p75/p95 값, 그리고 애니메이션이 사용자 만족에 주는 효과 대비 비용을 함께 평가해야 전체 그림을 파악할 수 있습니다.
| 구분 | p75 | p95 |
|---|---|---|
| AIB 영역이 LCP인 경우 | 4,573ms | 6,921ms |
| 지도 영역이 LCP인 경우 | 1,270ms | 3,369ms |
DOM 재구성과 어절 단위 렌더링의 함정
AIB 영역의 LCP가 비정상적으로 길게 측정되는 원인을 분석한 결과, 채팅 UI 특유의 DOM 구조와 상호작용 기능이 주요한 영향을 미치는 것으로 확인되었습니다. AIB는 텍스트가 한 글자 또는 어절 단위로 점진적으로 나타나는 텍스트 애니메이션을 포함하며, 특히 PC 환경에서는 각주에 마우스 포인터를 올리면 해당 텍스트가 하이라이트되는 인터랙션을 제공합니다. 이 하이라이트 기능 구현 과정에서 텍스트 애니메이션이 모두 끝난 뒤 AIB 영역의 DOM을 한 번 더 재구성하는 로직이 존재했습니다.
초기 렌더링 이후에 하이라이트에 적합한 구조로 DOM이 다시 변경되면서 LCP 후보가 포함된 영역이 뒤늦게 렌더링되어, LCP의 renderTime이 실제 사용자 경험보다 크게 늦춰진 것입니다. 모바일 환경에서는 하이라이트 기능이 직접적으로 사용되지 않지만, PC와 모바일이 공통 렌더링 로직을 공유했기 때문에 동일한 LCP 지연이 발생했습니다. 즉, AIB 영역의 LCP는 실제로 콘텐츠가 사용자에게 의미 있게 전달된 시점이 아니라, DOM 재구성까지 완료된 시점을 기준으로 측정되고 있었습니다.
하지만 이 DOM 재구성 로직을 제거하거나 수정한다고 해서 문제가 완전히 해결되는 것은 아닙니다. 채팅 UI 특성상 여전히 주의해야 할 구조적 문제가 남아 있기 때문입니다. AIB는 서버로부터 텍스트를 스트리밍 방식으로 전달받아 어절 단위로 DOM에 점진적으로 렌더링하는 방식을 사용합니다. 이 방식은 사용자 입장에서는 자연스러운 대화 흐름을 제공하지만, LCP 측정 관점에서는 새로운 문제를 만들어냅니다.
LCP는 뷰포트 내에서 '가장 큰 텍스트 블록 또는 이미지'를 기준으로 계산됩니다. 텍스트가 어절 단위로 쪼개져 있으면 각 어절이 개별 후보가 되며, 사용자가 인지하는 '하나의 큰 응답 영역'이 아니라 그중 면적이 가장 큰 어절이나 다른 UI 요소가 LCP로 선택될 수 있습니다. 이 경우 AIB가 화면에서 중요한 콘텐츠여도 LCP가 이를 대표하지 못하거나, 상황에 따라 의미가 낮은 요소가 LCP로 선택되는 문제가 생깁니다. 이는 하이라이트 기능을 제거하더라도 피하기 어려운, 렌더링 단위 자체에서 비롯되는 한계입니다.
또한 Chromium 기반 브라우저의 렌더링 파이프라인과 LCP 계산 방식이 채팅 UI의 점진적 렌더링 패턴과 잘 맞지 않는다는 문제도 있습니다. Chromium에서는 LCP 후보가 포함된 요소가 속한 레이어에서 paint invalidation이 발생하면 레이어가 다시 페인트되고, 그 시점에 LCP 후보의 renderTime이 갱신됩니다. 채팅 UI처럼 여러 줄의 텍스트가 순차적으로 추가되는 구조에서는 충분히 인지 가능한 콘텐츠가 이미 화면에 표시된 후에도 하위 텍스트 변경으로 인해 같은 레이어가 반복적으로 다시 그려집니다. 이 과정에서 초기에 그려진 큰 텍스트 블록도 계속해서 '다시 그려진 요소'로 인식되며 LCP renderTime이 프레임 단위로 뒤로 밀리게 됩니다.
이러한 현상은 특정 구현의 버그라기보다는 채팅 UI와 같은 스트리밍·점진적 렌더링 UI가 LCP의 설계 가정과 잘 맞지 않아 발생하는 구조적 한계에 가깝습니다. 여기서 비평적으로 지적할 점은, 글이 측정 지표 전환에 치중한 나머지 구현 레벨의 개선안이 다소 부족하다는 것입니다. 예를 들어 하이라이트를 위해 DOM을 재구성하는 대신 초기부터 하이라이트 가능한 구조로 렌더링하거나, CSS overlay로 처리하는 방법, 어절 단위가 아니라 문장이나 블록 단위 스트리밍으로 전환하되 시각 효과는 유지하는 방법, 레이어 분리나 CSS contain 적용으로 invalidation 범위를 축소하는 방법 등 제품 레벨의 처방이 함께 제시되었다면 실전성이 훨씬 높아졌을 것입니다.
TTFT 도입과 측정 체계 재설계의 필요성
네이버 검색은 채팅 UI의 특성 때문에 발생하는 LCP 왜곡 문제를 해결하기 위해, AIB 영역의 성능을 측정·관리하는 독립적인 기준을 도입할 계획입니다. 이는 단순히 특정 지표를 보정하기 위한 조치가 아니라, 서로 다른 UI 패턴을 동일한 성능 지표로 평가해 왔던 기존 방식의 한계를 인식하고 UI 특성에 맞는 측정 체계를 재정립하려는 시도입니다.
특히 채팅 UI에서는 페이지의 '완전한 렌더링 시점'보다 사용자가 첫 번째 의미 있는 응답을 인지하는 시점이 체감 성능과 더 밀접하게 연결됩니다. 실제로 여러 연구와 사례에서도 채팅 UI 환경에서는 LCP보다 첫 번째 토큰이 사용자에게 도달하는 시점, 즉 Time to First Token(TTFT)이 사용자 경험을 설명하는 데 더 적합한 지표임이 제시되고 있습니다. 이러한 배경을 바탕으로 네이버 검색 역시 AIB 영역에 대해 TTFT를 새로운 핵심 성능 지표로 도입하는 방안을 검토하고 있습니다.
중요한 것은 LCP가 의미 없는 지표라는 뜻이 아니라는 점입니다. 전통적인 검색 결과 페이지나 정적 콘텐츠 중심의 UI에서는 여전히 LCP가 중요한 품질 지표로 기능하며, 검색 전반의 기본적인 속도와 안정성을 판단하는 데 유효합니다. 실제로 AIB 영역을 제외한 LCP 분포를 보면 Good 비율이 약 96% 수준을 유지하는 것으로 확인되었습니다. 즉, 네이버 통합검색의 기본 성능 품질은 안정적이며, 최근 LCP 악화는 특정 UI(AIB 채팅 UI)의 구조적 요인이 크게 작용했다고 해석할 수 있습니다.
핵심은 LCP 하나로 모든 UI를 동일하게 평가하려 하기보다, 각 UI의 특성에 맞는 해석과 활용 방식을 함께 고민하는 것입니다. 기존의 LCP Good 구간(LCP < 2.5초)을 단순히 합격/불합격 기준으로만 사용하는 대신, 구간을 더 세분화해 사용자 체감 성능을 정밀하게 분석하는 접근도 고려할 수 있습니다. 최근 웹 성능 분야에서는 최적화(optimization) 중심의 사고에서 벗어나, 실제 사용자 경험을 더 잘 예측하고 설명하기 위한 지표 해석과 분포 분석의 중요성이 강조되고 있습니다.
비평적으로 보면, TTFT 도입은 분명 올바른 방향이지만 독자 입장에서는 "지표를 바꿔서 문제를 덮는 것 아니냐"는 의구심을 가질 수 있습니다. 이를 해소하려면 "지표는 TTFT로 보완하되, LCP 왜곡을 줄이는 구조 개선도 병행한다"는 메시지가 더 강하게 제시되어야 합니다. 또한 인과관계 증명 측면에서도 보완이 필요합니다. AIB 노출량(QC)과 LCP p95가 유사한 패턴이라는 설명은 좋은 단서지만, 독자를 완전히 납득시키려면 교란 요인 통제가 필요합니다. 같은 기간에 이미지, 광고, 지도, 서드파티 스크립트 변화, 실험 배포, 트래픽 구성(디바이스/네트워크) 변화가 없었는지, 혹은 AIB 노출군과 비노출군의 동일 조건 비교(동일 UA·네트워크·쿼리 클래스)가 있었는지가 중요합니다. "AIB 제외 시 Good 96%"는 강한 주장인데, 이 역시 AIB 제외 방법(측정 필터링 기준)이 무엇인지에 따라 해석이 달라질 수 있어 근거를 조금 더 명확히 보여주면 좋겠습니다.
네이버 검색은 앞으로 이러한 고민을 바탕으로, AIB와 같은 새로운 UI 패턴이 기존 성능 지표에 어떤 영향을 미치는지 지속적으로 관찰하고 지표 설계와 렌더링 구조를 함께 개선해 나갈 계획입니다. 이를 통해 단순히 수치를 개선하는 데 그치지 않고, 사용자 체감 성능과 성능 지표가 보다 일관되게 맞물리는 성능 측정·관리 체계를 고도화해 나가고자 합니다.
네이버 AIB와 LCP 성능 지표 이슈는 AI 시대의 웹 성능 측정이 단순히 기존 지표를 고수하는 것만으로는 충분하지 않음을 보여줍니다. 채팅 UI라는 새로운 패러다임에서는 DOM 재구성, 어절 단위 렌더링, paint invalidation 같은 구조적 요인이 지표를 왜곡할 수 있으며, 이를 해결하기 위해서는 TTFT 같은 UI 특성 기반 지표 도입과 함께 구현 레벨의 개선이 병행되어야 합니다. 측정 체계 재설계는 '지표를 바꿔서 숫자를 좋게 만들기'가 아니라, 실제 사용자 경험을 더 정확히 반영하기 위한 본질적 전환이어야 합니다. 다만 인과 통제, 실제 체감 지표 제시, 구현 개선안 구체화, 수치 산출 기준 명확화가 보강된다면 이 글은 웹 성능 분야의 레퍼런스 문서급으로 더욱 단단해질 것입니다.
자주 묻는 질문 (FAQ)
Q. LCP p95가 3.1초라는 것은 정확히 무엇을 의미하나요?
A. LCP p95는 95%의 사용자가 뷰포트에서 가장 큰 콘텐츠를 3.1초 이내에 보게 된다는 의미입니다. 반대로 5%의 사용자는 그보다 더 느린 경험을 하고 있다는 뜻이며, 구글의 권장 기준인 2.5초를 상회하는 값이므로 개선이 필요한 상태입니다.
Q. TTFT(Time to First Token)는 어떻게 측정되나요?
A. TTFT는 사용자가 요청을 보낸 시점부터 AI가 생성한 첫 번째 토큰(단어 또는 문자)이 화면에 표시되기까지의 시간을 측정합니다. 채팅 UI처럼 응답이 점진적으로 생성되는 환경에서는 전체 응답 완료 시점보다 첫 응답 표시 시점이 사용자 체감 성능에 더 큰 영향을 미치기 때문에 중요한 지표입니다.
Q. DOM 재구성이 LCP에 미치는 영향을 줄이려면 어떻게 해야 하나요?
A. 하이라이트 기능을 위해 렌더링 후 DOM을 재구성하는 대신, 초기부터 하이라이트 가능한 구조로 렌더링하거나 CSS overlay 방식을 활용할 수 있습니다. 또한 레이어 분리나 CSS contain 속성 적용으로 paint invalidation 범위를 축소하면 불필요한 렌더링 재계산을 줄일 수 있습니다.
Q. AIB를 제외한 네이버 검색의 LCP 성능은 어떤가요?
A. AIB 영역을 제외한 네이버 통합검색의 LCP 분포에서 Good 구간(LCP < 2.5초) 비율은 약 96% 수준을 유지하고 있습니다. 이는 기본 검색 성능 품질이 안정적임을 보여주며, 최근 LCP 악화가 특정 UI(AIB 채팅 UI)의 구조적 요인에 기인한다는 분석을 뒷받침합니다.
Q. 구글 AI Overview와 네이버 AIB의 LCP 영향은 어떻게 다른가요?
A. 구글 AI Overview는 큰 텍스트 블록 단위로 렌더링하고 애니메이션도 블록 단위로 제한적으로 적용합니다. 반면 네이버 AIB는 어절 단위로 텍스트를 쪼개 점진적으로 표시하고 노출 애니메이션도 적극 사용합니다. 이러한 렌더링 단위와 애니메이션 방식의 차이가 LCP 측정 결과에 서로 다른 영향을 미칩니다.
[출처]
네이버 D2 - AIB는 LCP를 어떻게 느리게 만드나?: https://d2.naver.com/helloworld/4241703