케이스 스터디: Google이 뷰 전환을 사용하여 새로운 AI 모드를 위한 연결된 환경을 만든 방법

게시일: 2025년 8월 28일

Google 검색은 전 세계에서 가장 큰 도달범위를 가지고 있으므로 사용자 환경의 변경사항이 수십억 명의 사용자에게 영향을 미칠 수 있습니다. Google은 오랫동안 더 현대적이고 앱과 같은 웹 환경을 꿈꿔 왔습니다. AI 모드 개발이 시작될 때 Google은 사용자가 표준 검색에서 AI 모드로 전환할 때 원활하고 연결된 느낌을 주는 환경을 만들고자 했습니다. 교차 문서 뷰 전환에 대해 들었을 때 이 기능과 완벽하게 어울린다는 것을 알았습니다. 이 사례 연구에서는 AI 모드 출시와 함께 전환 기능을 추가하면서 얻은 교훈을 공유합니다.

Google 검색에서 검색을 녹화하고 검색 결과에서 AI 모드로 전환합니다. 전환에서 뷰 전환을 사용하고 있습니다.

교차 문서 뷰 전환은 네이티브 브라우저 도구와 관련하여 획기적인 기능이며 앞으로 웹을 어떻게 형성할지 기대됩니다.

Browser Support

  • Chrome: 126.
  • Edge: 126.
  • Firefox: not supported.
  • Safari: 18.2.

Source

현상 유지에서 벗어나기

Google 검색에는 엄격하고 보수적인 브라우저 지원 요구사항이 있습니다. 일반적으로 제한된 기능은 사용할 수 없습니다. 교차 문서 뷰 전환의 경우 폴리필이 불가능한 것으로 확인되었습니다. 주요 차단 요인은 픽셀 스냅샷 API가 없고 전체 뷰포트를 클로닝하면 심각한 성능 문제가 발생한다는 것입니다. 따라서 점진적 개선으로 기능을 사용하는 것이 AI 모드와 함께 출시하는 가장 좋은 방법이었습니다. 뷰 전환으로 생성된 애니메이션은 웹사이트의 기능에 직접적인 영향을 미치지 않으므로 지원되지 않는 트래픽의 경우 전환 애니메이션이 없는 현재 프로덕션 상태와 마찬가지로 사용 중지됩니다.

Google은 먼저 내부 사용자를 대상으로 이 점진적 개선 전략을 테스트했습니다. 이를 통해 초기 의견을 받을 수 있었으며, 의견은 압도적으로 긍정적이었습니다. 또한 성능 문제, 겹치는 스태킹 컨텍스트와 같은 다른 기능과의 의도하지 않은 상호작용 등 버그도 발견되었습니다.

이 전략은 성공적이었으며 앞으로 다른 새로운 브라우저 기능에도 적용해 볼 계획입니다.

발생한 문제 및 해결 방법

지연 시간, 렌더링 차단, 워치독 타이머

전반적으로 MPA 뷰 전환으로 인해 추가되는 지연 시간은 특히 최신 하드웨어에서 99% 의 사용 사례에 대해 무시할 수 있습니다. 하지만 Google 검색은 지연 시간에 관한 기준이 매우 높으며 모든 기기에서 잘 작동하는 사용자 환경을 만들기 위해 노력하고 있습니다. Google에서는 몇 밀리초의 추가 시간도 중요하게 생각하므로 사용자 경험을 해치지 않고 교차 문서 뷰 전환을 올바르게 구현하는 방법을 연구해야 했습니다.

렌더링 차단은 교차 문서 뷰 전환과 잘 어울리는 기법입니다. 수신 문서의 가상 요소 스냅샷은 이미 렌더링된 콘텐츠만 표시할 수 있습니다. 따라서 수신 문서의 콘텐츠를 애니메이션으로 표시하려면 애니메이션으로 표시할 타겟 요소가 렌더링될 때까지 블록을 렌더링해야 합니다. 이렇게 하려면 HTMLLinkElement에서 blocking 속성을 사용합니다. 렌더링 차단에는 단점이 있습니다. 수신 문서의 DOM 트리 끝에 있는 요소를 기다리면 지연 시간이 크게 영향을 받을 수 있기 때문입니다. 이러한 절충안의 균형을 적절히 맞춰 페이지 수명 주기에서 매우 일찍 렌더링되는 요소에만 차단이 렌더링되도록 해야 했습니다.

<!-- Link tag in the <head> of the incoming document -->
<link blocking="render" href="#target-id" rel="expect">
<!-- Element you want to animate in the <body> of the incoming document -->
<div id="target-id">
  some content
</div>

경우에 따라 블록을 렌더링하는 요소를 정확하게 지정하는 것만으로는 충분하지 않았습니다. DOM 트리 시작 부분 근처의 요소에서 렌더링 차단이 발생하더라도 특정 기기나 연결에서는 지연 시간이 추가로 발생합니다. 이러한 사례를 처리하기 위해 일정 시간이 지나면 HTMLLinkElement를 삭제하여 수신 문서의 렌더링을 강제로 차단 해제하는 워치독 타이머 스크립트를 작성했습니다.

이 작업을 실행하는 간단한 방법은 다음과 같습니다.

function unblockRendering() {
  const renderBlockingElements = document.querySelectorAll(
    'link[blocking=render]',
  );
  for (const element of renderBlockingElements) {
    element.remove();
  }
}

const timeToUnblockRendering = t - performance.now();

if (timeToUnblockRendering > 0) {
  setTimeout(unblockRendering, timeToUnblockRendering);
} else {
  unblockRendering();
}

보증 범위 제한

또 다른 문제는 문서 간 뷰 전환 at-rule navigation: auto가 문서 내 전역 수준에서 발생한다는 것입니다. 교차 문서 보기 전환을 특정 클릭 타겟으로만 범위를 지정하는 기본 제공 방법은 없습니다. 이번 변경사항은 매우 큰 변화이므로 Google 검색에서 모든 탐색에 문서 간 전환을 사용 설정할 수 없습니다. 사용자가 상호작용하는 기능에 따라 교차 문서 뷰 전환을 동적으로 사용 설정하거나 사용 중지하는 방법이 필요했습니다. 여기서는 AI 모드로의 모드 변경과 AI 모드에서의 모드 변경에 대해서만 사용 설정했습니다. 클릭하거나 탭한 대상에 따라 탐색 at-rule을 프로그래매틱 방식으로 업데이트하여 이를 구현했습니다.

보기 전환 at-rule을 전환하는 방법은 다음과 같습니다.

let viewTransitionAtRule: HTMLElement | undefined;
const DISABLED_VIEW_TRANSITION = '@view-transition{navigation:none;}';
const ENABLED_VIEW_TRANSITION = '@view-transition{navigation:auto;}';

function getVtAtRule(): HTMLElement {
  if (!viewTransitionAtRule) {
    viewTransitionAtRule = document.createElement('style');
    document.head.append(viewTransitionAtRule);
  }
  return viewTransitionAtRule;
}

function disableVt() {
  getVtAtRule().textContent = DISABLED_VIEW_TRANSITION;
}

function enableVt() {
  getVtAtRule().textContent = ENABLED_VIEW_TRANSITION;
}

버벅거림 및 합성된 애니메이션

뷰 전환 의사 요소에서 자동으로 생성된 애니메이션으로 인해 이전 기기에서 프레임이 삭제되어 사용자에게 제공하려는 깔끔하고 원활한 환경이 손상되었습니다. 애니메이션의 성능을 개선하기 위해 컴포지터에서 실행할 수 있는 애니메이션 기법을 사용하여 애니메이션을 다시 작성했습니다. 키프레임을 검사하여 전후 스냅샷 의사 요소의 크기를 가져오고 행렬 수학을 사용하여 키프레임을 적절하게 다시 작성하면 됩니다. 다음 예에서는 각 보기 전환 의사 요소의 애니메이션을 가져오는 방법을 보여줍니다.

const pseudoElement = `::view-transition-group(${name})`;
const animation = document
  .getAnimations()
  .find(
    (animation) =>
      (animation.effect as KeyframeEffect)?.pseudoElement === pseudoElement,
  );

뷰 전환 적용: 블록이 포함된 스냅샷 처리에서 성능이 우수한 뷰 전환 키프레임을 작성하는 방법을 자세히 알아보세요.

기타 주의사항

더 두드러진 문제 중 하나는 view-transition-name CSS 속성으로 요소를 태그하면 스태킹 컨텍스트 (뷰 전환 사양: 섹션 2.1.1)에 영향을 미친다는 것입니다. 이로 인해 컨테이너 요소의 z-index를 수정해야 하는 여러 버그가 발생했습니다.

또 한 가지 주의할 점은 기본적으로 view-transition-name 값을 요소에 추가하지 않는 것이 좋습니다. Google 검색에는 많은 사람들이 참여하고 있습니다. 요소에 팀에서 설정한 view-transition-name 값이 다른 팀의 사용자가 사용할 수 있는 값과 충돌하지 않도록 특정 뷰 전환 유형이 활성 상태일 때만 조건부로 view-transition-name 속성을 추가하기 위해 뷰 전환 유형을 사용했습니다.

ai-mode의 뷰 전환 유형이 활성 상태일 때만 the-elementview-transition-name를 요소에 추가하는 CSS의 예:

html:active-view-transition-type(ai-mode) {
  #target {
    view-transition-name: the-element;
  }
}

모든 뷰 전환에 대해 이러한 CSS 규칙을 적용한 후에는 pageswappagereveal 이벤트 중에 탐색의 현재 뷰 전환 유형을 동적으로 변경할 수 있습니다.

pageswap 이벤트 중에 뷰 전환 유형을 ai-mode로 업데이트하는 예

function updateViewTransitionTypes(
  event: ViewTransitionEvent,
  types: string[],
): void {
  event.viewTransition.types.clear();
  for (const type of types) {
    event.viewTransition.types.add(type);
  }
}

window.addEventListener(
  'pageswap',
  (e) => {
    updateViewTransitionTypes(
      e as ViewTransitionEvent,
      ['ai-mode'],
    );
  }
);

이렇게 하면 이름 충돌을 방지하고 AI 모드로 전환할 때 스냅샷을 찍을 필요가 없는 요소를 불필요하게 스냅샷으로 저장하지 않습니다.

마지막으로 스태킹 컨텍스트 문제는 뷰 전환 중에만 표시됩니다. 이러한 문제를 해결하기 위해 뷰 전환을 사용할 때 이 문제를 해결하기 위한 유일한 이유로 원래 요소의 z-색인을 임의로 수정하는 대신 생성된 가상 요소의 z-색인을 타겟팅할 수 있습니다.

::view-transition-group(the-element) {
  z-index: 100;
}

다음 단계

브라우저 간에 사용할 수 있게 되면 탐색 API와의 통합을 비롯해 Google 검색에 교차 문서 뷰 전환을 사용할 계획입니다. 앞으로 어떤 기능을 빌드할지 기대해 주세요.