웹에서 애니메이션을 만들다 보면 “어떤 애니메이션은 왜 부드럽고, 어떤 건 버벅이지?”라는 궁금증이 생길 때가 있다. 그리고 약간 복잡한 애니메이션을 재생할 때 'will-change'라는 css속성을 넣으면 좀 빨라진다는 조언을 들은 적이 있는가? 나는 있다.. 클로드가 여러번 제안해주더라..

일단 will-change가 GPU 활성화를 시키는 속성이라고만 알고 있었다. 그냥 애니메이션 주다가 약간 버벅이면 넣는 수준으로만 취급하고 있었는데, 사실 실제 will-change를 어떨 때 써야하는지, 언제 써야하는지 알고 쓰는게 장기적인 이해도를 위해 좋을 것이다. 그리고 이를 위해선 브라우저가 화면을 그리는 과정(렌더링 파이프라인)을 알아야 한다.

이 과정을 transform이나 opacity처럼 애니메이션에 유리하다고 알려져있는 속성들이 왜 빠른지, 그리고 will-change 속성이 어떤 원리로 부드러운 애니메이션을 만드는지도 알아보도록 하자.

일단 브라우저 렌더링의 3단계(Layout → Paint → Composite)와 애니메이션에 유리한 속성, will-change의 효과와 원리를 정리해보겠다.

1. 브라우저 렌더링 단계

브라우저가 새로운 페이지를 초기화 할때는 DOM/CSSOM 생성, JS와 함께 렌더 트리 생성 => 레이아웃 => 페인팅 => Compositing의 과정을 거친다.

그런데 페이지가 로드된 이후에는 브라우저는 화면을 매 프레임마다 새롭게 그리는 것이 아니라, 필요할 때만 필요한 단계만 수행한다. 핵심 단계는 다음과 같다.

1) Layout(Reflow)

레이아웃 단계는 요소의 위치와 크기를 계산하는 단계다. DOM 구조, 부모/자식 관계, CSS 박스 모델에 따라 전체 레이아웃을 계산한다.

Layout을 발생시키는 속성 예시

width, height

margin, padding

top, left

display

font-size

DOM 추가/삭제

innerText 변경

*보통 Layout 애니메이션을 발생시키는 애니메이션을 실행할 때 위 이미지에서 DOM/CSSOM 생성까지 다 하는지 궁금할 수도 있다. 그러나 말했듯이 처음부터 다시 생성하진 않는다. RenderTree는 변경된 요소의 “Dirty(더럽다)” 플래그가 붙고, 관련 부분만 재계산한다. 즉, Layout이 변해도 DOM/CSSOM은 손대지 않는다.

그럼에도 Layout은 가장 비용이 큰 작업이다.

2) Paint(Repaint)

Paint는 레이아웃이 끝난 요소들의 픽셀을 실제로 칠하는 단계다.

Paint를 발생시키는 속성 예시

background-color

box-shadow

border

color

text-decoration

Paint는 Layout보다는 가볍지만 여전히 비용이 큰 편이다. 주로 컬러나 border, decoration 등에 대한 요소들이 포함되어있다.

3) Composite(Compositing)

Composite는 GPU가 레이어를 합성하여 최종 프레임을 만드는 단계다. 특정 요소가 GPU 레이어로 분리되어 있다면 transform이나 opacity 애니메이션을 Composite 단계에서 빠르게 처리할 수 있다.

Composite-only로 처리되는 속성

transform

opacity

will-change로 GPU 레이어가 생성된 경우

Composite는 3단계 중 가장 빠르고 가벼운 단계다. 보통 Layout 자체를 건드리는 속성(top, left, width, height, ...)보다 transform이나 opacity에 애니메이션을 주는게 유리한 이유 중 하나이다. transform은 레이아웃은 그대로 놔둔 채, 렌더되는 방식만 수정하기 때문에 layout단계를 다시 실행시키지 않는다.

2. 왜 어떤 속성은 애니메이션이 빠르고, 어떤 속성은 느릴까?

애니메이션 성능은 어떤 렌더링 단계가 발생하는가에 따라 달라진다.

아래 표는 속성 변경에 따른 브라우저 작업 단계를 정리한 것이다.

속성	Layout	Paint	Composite
width/height	✔	✔	✔
top/left	✔	✔	✔
background-color	❌	✔	✔
box-shadow	❌	✔	✔
transform	❌	❌	✔
opacity	❌	❌	✔

결론

width/height 등 Layout 기반 애니메이션 →가장 느림

background-color 등 Paint 기반 애니메이션 →중간

transform/opacity 등 Composite-only 애니메이션 →가장 빠르고 부드러움

그래서 웹 애니메이션에서 transform과 opacity가 “금과옥조”처럼 강조되는 것이다.

3. will-change의 역할과 원리

will-change는 다음과 같은 의미를 가진 CSS 속성이다.

“브라우저야, 이 요소의 특정 속성이 곧 바뀔 거니까, 관련 최적화를 미리 해둬.”

즉, 브라우저에게 앞으로 있을 변화에 대한 힌트를 주어 렌더링 성능을 최적화하게 하는 것이다.

3-1. will-change가 실제로 하는 일

1) GPU 합성 레이어로 미리 승격(Promote)

transform이나 opacity처럼 GPU에서 빠르게 처리할 수 있는 속성은 브라우저가 “필요할 때 레이어를 생성”하는데, 이 과정이 애니메이션 첫 프레임에서 **튐(jank)**을 만들 수 있다.

will-change는 이 레이어 생성 과정을 애니메이션 시작 전에 미리 해둔다.

2) 첫 프레임 렉 제거

레이어 생성, 캐싱, 텍스처 준비 등의 비용을 미리 처리하므로 애니메이션이 부드럽게 시작된다.

3) 스크롤 기반 애니메이션에도 이점

패럴랙스 효과처럼 스크롤 이벤트가 빠르게 발생할 때 transform 기반 애니메이션은 will-change로 미리 레이어를 분리해두면 훨씬 부드러워진다.

3-2. will-change의 한계와 주의점

❌ Layout이나 Paint를 “건너뛰게 만드는 속성”은 아니다

width에 will-change를 준다고 Layout이 없어지지 않는다.

background-color에 will-change를 줘도 Paint는 발생한다.

will-change가 강력한 이유는 **Composite-only 속성(transform/opacity)**에서 가장 크게 효과를 발휘하기 때문이다.

❌ 남용하면 오히려 성능이 나빠진다

GPU 레이어는 메모리를 많이 차지한다. 너무 많은 요소에 will-change를 붙이면:

GPU 메모리 낭비

모바일 발열 증가

성능 저하

오히려 전체 프레임이 떨어짐

브라우저 개발팀(크롬/파이어폭스)에서 공식적으로 “남용 금지”를 경고하고 있다.

3-3. will-change는 언제 사용해야 할까?

✔ transform/opacity 애니메이션이 자주/길게 반복될 때 ✔ 애니메이션 첫 프레임에서 튀는 느낌이 있을 때 ✔ 스크롤 기반 패럴랙스나 모달/오버레이 등 큰 요소가 움직일 때 ✔ Canvas/WebGL과 함께 사용하는 복잡한 애니메이션 요소일 때 ❌ 가벼운 호버 애니메이션, 짧은 transition에는 필요 없음 ❌ width/height/top 같은 Layout 기반 애니메이션에는 의미가 거의 없음 ❌ 페이지 전체 요소에 남발하면 성능 악화

4. 결론

브라우저의 렌더링 단계는 Layout → Paint → Composite의 3단계로 구성되어 있다. 속성 변경이 어떤 단계를 발생시키는지에 따라 애니메이션 성능이 크게 달라진다.

Layout을 발생시키는 속성 → 가장 무겁다

Paint만 발생시키는 속성 → 중간 수준

Composite-only 속성(transform/opacity) → 가장 빠르고 부드럽다

will-change는 이러한 렌더링 과정을 미리 준비하게 하여 특히 transform/opacity 애니메이션에서 부드러운 첫 프레임과 안정적인 성능을 보장하는 강력한 도구다.

하지만 남용은 금물이다.

will-change는 특정 조건에서만 써야 효과가 있으며, 지속적으로 적용하면 오히려 성능을 해칠 수 있다.