## 들어가며 랜딩페이지에 GSAP ScrollSmoother를 붙였다. 스크롤이 부드러워졌고, 여기까지는 만족스러웠다. ```tsx // SmoothScrollProvider.tsx ScrollSmoother.create({ wrapper: "#smooth-wrapper", content: "#smooth-content", smooth: 1, effects: true, normalizeScroll: true, }); ``` 그런데 잘 동작하던 sticky 섹션이 갑자기 죽었다. ```tsx // StickyFeatures.tsx

{/* 작동 안 함 */}

``` `position: sticky; top: 0`인데 요소가 고정되지 않고 그냥 흘러가버린다. ScrollSmoother를 제거하면 다시 멀쩡하게 동작한다. 코드를 아무리 들여다봐도 sticky 선언 자체에는 문제가 없다. 그렇다면 ScrollSmoother가 뭔가를 바꿔놨다는 건데, 도대체 뭘 바꾼 걸까. ## 직접 확인하기 말로 설명하기 전에 직접 보는 게 빠르다. 아래 두 박스는 완전히 동일한 마크업이고, sticky 바도 똑같이 들어있다. 차이는 단 하나, 콘텐츠가 **어떻게 움직이는가**다. 왼쪽은 평범한 스크롤 컨테이너라 검은 바가 상단에 붙는다. 오른쪽은 ScrollSmoother와 같은 방식으로 컨테이너는 `overflow: hidden`으로 잠그고 콘텐츠를 `transform: translateY()`로 밀어올린다. 검은 바가 sticky 선언을 무시하고 콘텐츠와 함께 사라진다. 오른쪽 박스 아래의 transform 값이 실시간으로 변하는 걸 보면 알 수 있다. **스크롤은 한 픽셀도 일어나지 않았다.** 움직임은 전부 transform이 만든 것이다. ## 우선, sticky는 무엇을 기준으로 붙는가? sticky가 깨지는 이유를 이해하려면 sticky가 애초에 뭘 기준으로 동작하는지 알아야 한다. `position: sticky`는 요소를 **가장 가까운 스크롤포트(scrollport)** 기준으로 고정한다. 스크롤포트란 조상 중 `overflow`가 `visible`이 아닌 가장 가까운 요소다. 그런 조상이 없으면 뷰포트가 기준이 된다. 여기서 중요한 함정이 하나 있다. `overflow: hidden`도 스크롤 컨테이너다. 스크롤바가 없고 사용자가 스크롤할 수 없을 뿐, 명세상으로는 엄연히 스크롤 가능한 박스로 취급된다. 그래서 조상에 `overflow: hidden`이 있으면 sticky의 기준이 뷰포트에서 그 조상으로 **조용히 바뀐다**. sticky의 동작을 한 문장으로 줄이면 이렇다. "기준 스크롤포트가 스크롤될 때, 지정한 오프셋(`top: 0`)을 유지하도록 따라간다." 뒤집어 말하면 **기준 스크롤포트가 스크롤되지 않으면 sticky는 아무것도 하지 않는다.** ## ScrollSmoother가 만드는 구조 ScrollSmoother를 켜면 DOM에 이런 스타일이 자동으로 주입된다. ```css /* ScrollSmoother가 자동 생성하는 스타일 */ #smooth-wrapper { position: fixed; overflow: hidden; height: 100%; width: 100%; } #smooth-content { transform: translateY(...); /* 매 프레임 갱신 */ will-change: transform; } ``` 각 레이어가 sticky에 정확히 어떻게 동작하는지 직접 눌러보자. 이제 sticky가 죽는 메커니즘이 보인다. 내 sticky 요소의 기준 스크롤포트는 `overflow: hidden`인 `#smooth-wrapper`로 바뀌었다. 그런데 wrapper는 `position: fixed`로 박혀서 **절대 스크롤되지 않는다**. 실제 네이티브 스크롤은 body에서 일어나지만, 내 콘텐츠는 fixed wrapper 안에 격리되어 있어서 그 스크롤과 아무 상관이 없다. 기준 스크롤포트의 scrollTop이 영원히 0이니 sticky 오프셋은 한 번도 발동하지 않는다. 브라우저 입장에서는 sticky를 무시한 게 아니라, **고정해야 할 조건이 한 번도 충족되지 않은 것**이다. 참고로 같은 환경에서 `position: fixed`도 죽는데, 이유는 다르다. fixed는 스크롤포트가 아니라 containing block 문제다. `transform`이 적용된 요소는 자손 fixed의 containing block이 되기 때문에, fixed가 뷰포트 대신 `#smooth-content` 기준으로 잡혀버린다. sticky는 "기준 스크롤이 없어서", fixed는 "기준 좌표계가 바뀌어서" 죽는다. 증상은 같아 보여도 원인은 별개다. ## 왜 이렇게 만들었을까? ScrollSmoother가 일부러 sticky를 죽인 게 아니다. 부드러운 스크롤을 구현하려면 이 구조가 거의 필연적이다. smooth scroll의 본질은 "실제 스크롤 위치"와 "화면에 보이는 위치"의 분리다. 사용자가 휠을 굴리면 실제 스크롤 위치는 즉시 변하지만, 보이는 위치는 lerp로 천천히 따라온다. 이 분리를 구현하려면 네이티브 스크롤은 그대로 살려두고(스크롤바, 키보드 내비게이션, 브라우저 관성을 공짜로 얻는다), 콘텐츠만 fixed 컨테이너에 가둬서 매 프레임 transform으로 따라가게 해야 한다. 즉 `position: fixed` + `overflow: hidden` + `transform`은 ScrollSmoother의 버그가 아니라 설계 그 자체다. 그리고 sticky와 fixed는 이 설계의 구조적 비용이다. 브라우저의 레이아웃 시스템에 기대는 모든 "고정"은 이 가상 스크롤 세계 바깥에 있기 때문에 동작할 수 없다. ## 해결: ScrollTrigger pin 브라우저 레이아웃이 못 해주면 JS가 직접 하면 된다. GSAP ScrollTrigger의 `pin`이 정확히 그 역할이다. ```tsx useEffect(() => { const ctx = gsap.context(() => { ScrollTrigger.create({ trigger: containerRef.current, // 스크롤 감지 영역 start: "top top", // 고정 시작점 end: "bottom bottom", // 고정 끝점 pin: pinRef.current, // 고정할 요소 pinSpacing: false, // 추가 공간 생성 여부 }); }, containerRef); return () => ctx.revert(); }, []); ``` pin이 ScrollSmoother 환경에서 동작하는 이유는 단순하다. **sticky와 다른 좌표계를 쓰지 않기 때문이다.** ScrollTrigger는 ScrollSmoother가 쓰는 가상 스크롤 값을 그대로 공유하고, 고정 구간 동안 스크롤된 거리만큼 요소에 `translateY`를 더해서 화면에 머무는 것처럼 보이게 만든다. 실제로 ScrollTrigger에는 `pinType`이라는 옵션이 있는데, 일반 환경에서는 `fixed`를 쓰지만 transform 기반 스크롤러 안에서는 자동으로 `transform` 방식으로 전환된다. 레이아웃 시스템에 기대지 않고 매 프레임 계산으로 고정을 흉내내는 것이다. 아래 데모가 그 원리를 그대로 재현한 것이다. 가상 스크롤(transform) 환경인데도 패널이 고정된다. `pinned` 표시가 켜진 동안 패널에 `translateY(스크롤된 거리)`가 계속 더해지고 있다. 콘텐츠는 위로 흘러가는데 패널만 같은 속도로 아래로 밀리니까 결과적으로 화면에 멈춰 보인다. sticky가 선언으로 얻으려던 것을 pin은 산수로 얻는다. ## 추가 문제: 스크롤 진행률 기반 콘텐츠 전환 고정만 하면 끝이 아니었다. 고정된 패널 안에서 스크롤 진행에 따라 콘텐츠를 전환해야 했다. 처음에는 이렇게 접근했다가 두 번 실패했다. ```tsx // 문제 1: 한 번만 실행됨 useEffect(() => { const index = calculateIndex(); // 마운트 시 1회만 호출 setContentIndex(index); }, []); // 문제 2: 잘못된 계산 const index = Math.floor(clientY / contentHeight); // clientY는 음수가 될 수 있고, 결과가 항상 0 또는 음수 ``` 첫 번째는 스크롤마다 갱신돼야 할 값을 마운트 시점에 한 번만 계산했고, 두 번째는 좌표 기반 계산이라 transform 환경에서 의미 있는 값이 안 나왔다. 둘 다 같은 교훈으로 수렴한다. **가상 스크롤 환경에서 스크롤 상태의 유일한 신뢰 가능한 출처는 ScrollTrigger 자신이다.** DOM 좌표를 직접 읽지 말고 ScrollTrigger가 계산해주는 값을 받아야 한다. 그 값이 `onUpdate` 콜백의 `self.progress`다. ```tsx ScrollTrigger.create({ trigger: containerRef.current, start: "top top", end: "bottom bottom", pin: pinRef.current, pinSpacing: false, onUpdate: (self) => { // self.progress: 0 ~ 1 (고정 구간 내 스크롤 진행률) const newIndex = Math.min( FEATURES.length - 1, Math.floor(self.progress * FEATURES.length), ); setContentIndex(newIndex); }, }); ``` `progress`는 고정 구간의 시작에서 0, 끝에서 1인 정규화된 값이다. 콘텐츠가 4개라면 `progress * 4`를 내림해서 인덱스로 쓰면 된다. 위의 pin 데모에서 `progress: 0.42 → index 1`처럼 실시간으로 표시되는 값이 정확히 이 계산이다. 전환 애니메이션은 모든 이미지를 absolute로 쌓아두고 활성 인덱스만 opacity를 올리는 방식이 깔끔하다. ```tsx

{FEATURES.map((feature, idx) => (

))}

``` ## CSS sticky vs ScrollTrigger pin | 항목 | CSS sticky | ScrollTrigger pin | |------|------------|-------------------| | 고정 방식 | 브라우저 레이아웃 시스템 | 매 프레임 transform 계산 | | ScrollSmoother | 작동 안 함 | 정상 작동 | | overflow: hidden 조상 | 깨짐 | 정상 | | 고정 구간 제어 | 부모 높이만큼 | `start`/`end`로 정밀 제어 | | 진행률 연동 | 별도 구현 필요 | `onUpdate`의 `progress` 제공 | | 비용 | 공짜 (선언적) | JS 실행 + 정리(revert) 필요 | ScrollSmoother가 없는 평범한 환경이라면 sticky가 당연히 낫다. 선언 한 줄이고 브라우저가 알아서 한다. pin은 가상 스크롤 세계에 들어간 순간부터의 선택지다. ## 정리 ScrollSmoother는 `fixed` wrapper + `overflow: hidden` + 매 프레임 `transform`으로 가상 스크롤을 구현한다. 이 구조에서 sticky의 기준 스크롤포트는 절대 스크롤되지 않는 wrapper로 바뀌고, scrollTop이 영원히 0이라 sticky는 한 번도 발동하지 않는다. fixed는 transform이 containing block을 가로채서 별도의 이유로 함께 죽는다. 해결책은 같은 좌표계 안에서 동작하는 ScrollTrigger pin이다. 레이아웃 대신 매 프레임 translateY 계산으로 고정을 만들기 때문에 transform 환경에서 깨지지 않는다. 스크롤 진행률 기반 로직도 DOM 좌표를 직접 읽지 말고 `onUpdate`의 `self.progress`를 출처로 삼아야 한다. ## 관련 링크 - [GSAP ScrollSmoother Docs](https://gsap.com/docs/v3/Plugins/ScrollSmoother/) - [GSAP ScrollTrigger pin](https://gsap.com/docs/v3/Plugins/ScrollTrigger/) - [CSS position: sticky 작동 조건 (MDN)](https://developer.mozilla.org/en-US/docs/Web/CSS/position#sticky)