스티키 및 플로팅 UI 시스템

스티키 및 플로팅 UI 시스템은(는) 무엇을 하나요?

목적

스티키 및 플로팅 UI 시스템은 지속적이고, 뷰포트에 고정되며, 스크롤에 반응하는 인터페이스 컴포넌트를 설계하기 위한 방법론을 제공합니다. 이를 통해 기본 탐색, 전환 유도 행동 유도(Call-to-Action, CTA), 상황별 유틸리티 위젯, 빠른 작업 버튼과 같은 중요한 컨트롤이 활발한 스크롤 상태에서도 쉽게 접근 가능한 상태를 유지하도록 보장합니다.

잘 설계된 스티키 및 플로팅 시스템은 즉각적인 작업 가능성과 주요 콘텐츠 소비 사이의 공간적 긴장을 해결합니다. 레이아웃 피로를 방지하고, 뷰포트가 과도한 시각적 혼란으로부터 보호하며, 모바일 물리적 안전 영역(예: 기기 노치 및 시스템 홈 인디케이터)을 존중하고, 키보드 포커스 가림 오류(WCAG 2.2 SC 2.4.11)를 엄격히 완화합니다.

사용 사례

• 프로그레시브 탐색 헤더: 스크롤 다운 시 숨겨져 읽기 영역을 최대화하고, 스크롤 업 시 나타나 탐색을 즉시 사용 가능하게 하는 헤더.
• 모바일 영구 하단 도크: 모바일 레이아웃을 위해 기본 전환 작업(예: "장바구니에 담기", "지금 예약", "신청하기")이 포함된 플로팅 또는 고정 하단 바.
• 스티키 사이드바 위젯: 기본 콘텐츠 영역과 함께 스크롤되지만 구조적 경계에 도달하기 전에 고정되는 상황별 하위 탐색, 공유 바 또는 제품 구매 설정.
• 플로팅 액션 버튼(FAB): "맨 위로 가기" 탐색, 직접 지원 채팅 또는 장바구니 서랍과 같은 빠른 고빈도 작업을 위한 뷰포트 고정 트리거.
• 앵커 및 읽기 진행률 표시줄: 뷰포트 완료율을 추적하거나 페이지 본문의 하위 섹션에 대한 직접 링크를 제공하는 스티키 요소.

사용하지 말아야 할 경우

• 데이터 밀집 SaaS 대시보드: 테이블 형식 데이터, 작업 캔버스 또는 뷰포트 고정 패널로 인해 화면 공간이 매우 제한된 경우 dashboard-layout-system을 사용하세요.
• 짧은/단일 뷰포트 페이지: 전체 페이지 콘텐츠가 단일 화면 보기에 맞고 스크롤 없이 접근할 수 있는 경우.
• 내러티브 중심 실험적 사이트: 표준 탐색 유용성보다 의도적인 시각적 혼란 또는 몰입형 3D 공간 흐름이 선택된 경우.
• 키보드 중심 양식: 스티키 버튼이 모바일 가상 키보드에서 열린 입력 필드를 겹치고 덮는 다중 필드 양식으로 페이지를 과부하시키는 경우.

입력

1. 콘텐츠 및 내러티브 구조: 스티키 요소가 활성화되어야 하는 시점과 위치를 이해하기 위한 페이지의 와이어프레임 시퀀스(section-composition-system에서).
2. 기기 뷰포트 제약 조건: 고정 바와 플로팅 측면 컨테이너 간의 레이아웃을 조정하기 위한 대상 모바일, 태블릿 및 데스크톱 중단점.
3. 기본 및 보조 CTA: 지속적인 가시성이 필요한 전환 목표 식별.
4. Z-Index 스태킹 전략: 시각적 겹침 충돌을 방지하기 위해 elevation-and-depth-system에서 설정된 스태킹 관계 및 계층.
5. 시스템 안전 영역 메트릭: 기기 크롬 겹침을 방지하는 데 필요한 하드웨어 안전 영역 삽입(env(safe-area-inset-bottom), 노치).

출력

1. 스티키 동작 사양: 스크롤 트리거, 애니메이션 임계값 및 진입/종료 전환 공식에 대한 명시적 정의.
2. 모바일 하단 도크 레이아웃: 대상 크기, 안전 영역 오프셋 및 대비 요구 사항을 자세히 설명하는 모바일 화면용 공간 최적화 레이아웃 청사진.
3. 가림 완화 맵: 스티키 오버레이가 포커스된 요소를 차단하지 않도록 유지하는 방법을 보여주는 설계 정의(WCAG 2.2 SC 2.4.11).
4. 데스크톱 사이드바/위젯 고정 사양: 스크롤 측면 요소가 스냅인 및 잠겨야 하는 경계 규칙(헤더, 푸터, 섹션 끝점).

워크플로우

1. 뷰포트 영역 설정 및 공간 예산 수립

영구 레이어를 배치하기 전에 콘텐츠 가독성이 유지되도록 "시각적 안전 영역"을 정의합니다.

• 15% 예산 규칙: 스티키 요소는 어떤 기기 화면에서도 전체 세로 뷰포트의 15%를 초과하여 사용해서는 안 됩니다.
• Z-Index 할당: elevation-and-depth-system 계층을 사용하여 명확한 스태킹 값을 할당합니다.
  • 프로그레시브 헤더: z-index: 100 (레벨 3: 스티키)
  • 모바일 하단 도크: z-index: 150 (레벨 3: 스티키/플로팅)
  • 플로팅 액션 버튼: z-index: 200 (레벨 3: 플로팅 트리거)
• 스택 겹침 방지: 스티키 헤더와 스티키 하단 바가 화면을 좁게 만드는 경우 동시에 정적으로 유지되지 않도록 합니다. 충분한 여유 공간을 확보하거나 특정 상태에서 숨깁니다.

2. 프로그레시브 헤더 동작 설계

정적 스티키 헤더는 귀중한 세로 픽셀을 차지합니다. "프로그레시브" 모델을 구현합니다:

• 기본 상태: 페이지 배경과 일치하는 투명 또는 통합 헤더.
• 스크롤 다운(임계값 >100px): 헤더를 위로 부드럽게 이동하여 보기에서 숨깁니다(transform: translateY(-100%)). 콘텐츠 스캔 영역을 최대화합니다.
• 스크롤 업(델타 >15px): 헤더를 즉시 또는 부드럽게 다시 보기로 되돌리고, 단색 또는 흐릿한 표면 배경(backdrop-filter: blur(8px))과 미묘한 그림자를 적용하여 페이지 본문 텍스트와의 분리를 나타냅니다.
• 경계 중지: 스크롤바가 뷰포트 상단(scrollY < 50px)으로 돌아오면 스크롤 업 전환을 비활성화하고 헤더를 원래 정적 레이아웃으로 되돌립니다.

3. 모바일 영구 하단 도크 엔지니어링

하단 영구 바는 모바일 전환의 주요 동인이지만 물리적 및 시각적 간섭이 발생하기 쉽습니다.

• 물리적 안전 영역: 항상 CSS 환경 변수를 사용하여 도크의 하단 가장자리를 고정합니다: padding-bottom: calc(var(--base-padding) + env(safe-area-inset-bottom)). 이렇게 하면 대화형 트리거와 겹치지 않으면서 iOS 홈 인디케이터 및 Android 탐색 표시줄 위에 깔끔하게 배치됩니다.
• 진입 스크롤 트리거: 초기 히어로 뷰포트에는 모바일 하단 도크를 표시하지 마십시오. 사용자가 히어로 섹션의 주요 인라인 CTA를 지나 스크롤할 때까지 기다린 후(임계값 > 100% VH) 하단에서 도크를 밀어 올립니다(transform: translateY(0), translateY(100%)에서).
• 레이아웃 분할: 도크를 단일 기본 작업 버튼(예: "장바구니에 담기")과 하나의 보조 유틸리티 버튼/배지(예: "가격" 또는 "저장")로 제한하여 탭 대상을 매우 깔끔하게 유지합니다.

4. 데스크톱 스티키 사이드바 및 위젯 구조화

사이드바 위젯은 깊은 기본 콘텐츠 열과 함께 스크롤하는 동안 뷰포트 포커스에 고정된 상태를 유지해야 합니다:

• 컨테이너 분리: 사이드바는 기본 콘텐츠 영역의 높이와 일치하는 열 컨테이너 내에 있어야 합니다.
• Position Sticky 사양: position: sticky; top: calc(var(--header-height) + var(--space-l));로 위젯 스타일을 지정합니다. 이렇게 하면 위젯이 기본 탐색 표시줄 뒤로 미끄러지거나 겹치는 것을 방지할 수 있습니다.
• 푸터 경계 잠금: 스티키 위젯의 상위 열에 overflow: visible이 있는지(또는 그리드 플렉스 래퍼 내에 적절히 포함되었는지) 확인하여 브라우저가 위젯이 전역 푸터 또는 하단 섹션과 겹치는 것을 자연스럽게 중지하도록 합니다.

5. 키보드 포커스 가림 방지 (접근성 핵심)

가장 빈번한 웹 디자인 접근성 실패 중 하나는 키보드 탭 사용자가 링크에 포커스를 맞추었지만 해당 링크가 스티키 헤더나 하단 도크 아래에 숨겨져 있는 경우입니다(WCAG 2.2 SC 2.4.11 포커스 가림 방지 위반).

• 스크롤 여백 상단: 모든 대상 섹션, 제목(h2, h3) 및 주요 대화형 대상에 전역 scroll-margin-top을 적용합니다:

  :target, [id] {
    scroll-margin-top: calc(var(--header-height) + var(--space-m));
  }
  

• 포커스 패딩: 대화형 요소가 키보드 포커스를 받으면 브라우저 뷰가 스크롤되어 요소가 지속적인 스티키 오버레이 경계 밖에서 완전히 보여야 합니다.
• 탈출구: 스티키 요소에서 모달 또는 드롭다운이 열리면 포커스를 트랩하고(focus-trap-implementation 사용) 배경 페이지 콘텐츠를 inert로 만듭니다.

6. 플로팅 액션 버튼(FAB) 및 맨 위로 가기 트리거 설계

FAB는 뷰포트의 하단 모서리에 위치하여 빠르고 보조적인 전역 유틸리티를 제공합니다.

• 임계값 기반 진입: 사용자가 최소 두 개의 전체 뷰포트(scrollY > 200% VH)를 스크롤할 때까지 "맨 위로 가기" 트리거를 숨깁니다. 트리거되면 페이드 인 및 스케일 인(transform: scale(1); opacity: 1;, scale(0.8); opacity: 0;에서).
• 뷰포트 오프셋: 데스크톱에서는 뷰포트 오른쪽 가장자리에서 최소 24px, 모바일에서는 16px 떨어진 곳에 FAB를 유지합니다.
• 대상 차단 방지: FAB를 기본 콘텐츠 읽기 라인과 수평으로 반대쪽에 배치합니다. 페이지 하단으로 스크롤할 때 푸터의 링크, 소셜 아이콘 또는 인라인 탐색을 차단하지 않도록 합니다.

의사 결정 규칙

• 정적 vs. 프로그레시브 헤더: 사이트가 작업 중심 웹 포털이나 전자상거래 상점(검색 및 필터링이 지속적으로 사용됨)인 경우 정적 스티키 헤더를 사용하십시오. 기사 레이아웃, 콘텐츠 마케팅 또는 세로 읽기 영역이 우선시되는 판매 랜딩 페이지의 경우 프로그레시브 스티키 헤더를 사용하십시오.
• 하단 도크 vs. 인라인 CTA: 모바일에서 페이지에 가입 또는 구매와 같은 단일 고가치 전환 목표가 포함된 경우 하단 도크 CTA를 사용하십시오. 페이지에 동등한 우선순위의 여러 작업이 있는 경우 하단 도크를 사용하지 마십시오.
• FAB 크기 및 터치 영역: 플로팅 트리거가 원형 또는 둥근 카드인지 확인하십시오. 시각적 요소는 직경이 최소 48px 이상이어야 하며 실제 대화형 탭 컨테이너는 엄지손가락으로 쉽게 접근할 수 있도록 최소 44x44px(WCAG 2.2 권장)의 공간을 확보해야 합니다.
• 프로그레시브 블러 vs. 단색: 완전 불투명 배경 대신 약간 투명한 색상(예: rgba(255, 255, 255, 0.8))과 함께 backdrop-filter: blur(8px)를 사용하십시오. 이는 시각적 깊이 감각을 유지하고 사용자가 스티키 프레임 뒤에서 스크롤 진행 상황을 인지할 수 있도록 합니다.

제약 조건

• 접근성(WCAG AA 최소):
  • SC 2.4.11 포커스 가림 방지(최소): 고대비 포커스 링이 스티키 요소 뒤에 숨겨져서는 안 됩니다. 요소가 헤더나 푸터에 의해 차단되지 않고 깔끔하게 탭 이동될 수 있는지 확인하십시오.
  • SC 2.5.8 대상 크기(최소): 스티키 바 및 FAB의 모든 대화형 대상은 최소 24x24px 이상이어야 하며, 모바일 하단 도크의 기본 엄지 트리거는 44x44px가 선호됩니다.
  • 탭 트랩 없음: 키보드 사용자는 표준 Tab / Shift+Tab을 사용하여 스티키 바 컨트롤 안팎으로 탐색할 수 있어야 합니다.
• 반응성(레이아웃 안정성):
  • 스티키 레이어는 절대 가로 뷰포트 오버플로를 유발해서는 안 됩니다. 백분율 기반 너비 또는 left: 0; right: 0; 레이아웃을 정확한 box-sizing 제약 조건과 함께 사용하십시오.
  • 모바일에서는 데스크톱 스티키 사이드바를 단순한 인라인 패널로 전환하거나 하단 서랍에 통합하십시오.
• 레이아웃 이동 완화(CLS):
  • 원래 공간 볼륨을 예약하지 않고 요소의 position을 static에서 fixed로 동적으로 변경하지 마십시오. fixed로 전환하면 즉시 원래 컨테이너 높이가 축소되어 심각한 누적 레이아웃 이동(CLS)이 발생합니다. 대신 position: sticky(레이아웃 볼륨을 예약함)를 사용하거나 미리 예약된 컨테이너 내에서 스타일을 전환하십시오.

일반적인 실패 패턴

• 포커스 차단 베일: 키보드 사용자가 페이지를 탭 이동하지만 포커스 링이 스티키 헤더 아래에 완전히 숨겨진 링크에 도달하여 볼 수 없게 됩니다.
• iOS 홈 인디케이터 겹침: env(safe-area-inset-bottom)을 추가하지 않고 모바일 하단 바를 도킹하면 기본 OS 스와이프 바가 "구매" 버튼 바로 위에 놓이게 됩니다.
• 떨림 스크롤 루프: 경계선에서 정확히 트리거되는 JavaScript를 사용하여 스크롤 전환을 설정하면 스티키 바가 빠른 시각적 떨림으로 표시 및 숨김 상태를 반복하게 됩니다.
• 뷰포트 샌드위치: 작은 모바일 기기에서 두꺼운 스티키 헤더와 두꺼운 스티키 하단 바가 동시에 활성화되어 읽을 수 있는 화면 공간이 작은 40% 창으로 줄어듭니다.
• CLS 스냅핑 붕괴: 스크롤 시 헤더를 fixed로 전환하면 기본 페이지 콘텐츠가 즉시 80px 위로 스냅되어 사용자 방향 감각을 잃게 합니다.

검증 기준

• 뷰포트 영역 확인: 스티키 요소가 데스크톱 또는 모바일에서 세로 뷰포트의 15%를 초과하여 차지하지 않습니다.
• 포커스 보호(SC 2.4.11): 키보드 포커스된 모든 요소가 지속적인 스티키 요소의 경계 밖에서 완전히 보입니다. 전역 scroll-margin-top이 구성되었습니다.
• 모바일 안전 영역 정렬: 모바일 하단 도크가 명시적으로 env(safe-area-inset-bottom)을 활용하여 기기 컨트롤 겹침을 방지합니다.
• 트리거 임계값 논리: 모바일 하단 도크가 초기 히어로 뷰포트에서 숨겨져 있다가 히어로 CTA를 지난 후에만 페이드/이동됩니다.
• 레이아웃 이동 방지: 프로그레시브 헤더와 스티키 사이드바 위젯이 position: sticky를 사용하여 스타일이 지정되거나 사전 측정된 컨테이너 내에 배치되어 CLS(누적 레이아웃 이동)가 전혀 발생하지 않도록 보장합니다.
• 겹침 충돌 없음: 스태킹 컨텍스트 z-index가 명확하게 매핑되고 문서화되어 시각적 겹침 오류를 방지합니다.
• 대상 크기: 모바일 도크 트리거와 FAB가 44x44px 터치 대상 선호도를 충족합니다.