🎬 10. CSS 애니메이션: '움직임의 미학, 성능은 필수'

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 11분(전체) / 핵심 파트만: 6분

🗺️ 이 문서의 흐름
[Transition vs Animation] → [Keyframes의 정교함] → [GPU 가속과 성능 최적화]

🎯 이 문서를 다 읽으면 할 수 있는 것

• 단순한 상태 변화는 transition으로, 복잡한 시퀀스는 animation으로 구현합니다.
• cubic-bezier를 활용해 기계적이지 않은 자연스러운 움직임을 만듭니다.
• 브라우저의 렌더링 파이프라인을 이해해 끊김이 적은 애니메이션을 설계합니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 (중반부 실무자): "영호 님! 버튼 호버 효과를 넣었는데, 카드가 많은 페이지에서 스크롤과 함께 움직이면 끊김이 보입니다. 어떤 속성을 움직였는지부터 확인해야겠죠?"
• 🦁 영호 (리드): "맞아요. 애니메이션은 장식이 아니라 피드백입니다. 아름답게 움직이는 것만큼 사용자의 CPU/GPU에 무리를 주지 않는 절제가 중요합니다."

🤔 왜 알아야 하는가

애니메이션은 단순한 시각적 효과를 넘어, 유저에게 현재 어떤 동작이 일어나고 있는지 알려주는 중요한 피드백 수단(Micro-interaction)입니다. 하지만 잘못 구현된 애니메이션은 전체 웹사이트의 성능을 떨어뜨리고, 저사양 기기에서 입력 지연이나 스크롤 끊김을 만들 수 있습니다.

영철이가 겪은 끊김 현상은 대부분 Reflow(Layout) 를 유발하는 속성을 애니메이션에 썼기 때문입니다. 5년차 이상의 시니어는 브라우저의 Composite 계층을 활용하기 쉬운 속성을 우선 검토하고, 사양 낮은 스마트폰에서도 자연스럽게 동작하는지 실제 기기나 성능 패널로 확인합니다.

🏎️ 1. Transition vs Animation

• Transition: A 상태에서 B 상태로 변화할 때 씁니다. (예: 호버 시 색상 변경)
• Animation: 더 복잡하고 반복적인 일련의 움직임을 만들 때 씁니다. (@keyframes 필요)

버튼 호버처럼 A 상태에서 B 상태로 바뀌는 효과는 transition이 적합합니다. 이동이나 확대는 레이아웃을 바꾸지 않는 transform으로 처리하는 것이 보통 더 안전합니다.

.btn {
  /* 변하는 속성, 시간, 타이밍 함수를 한곳에 명시합니다. */
  transition: transform 0.3s cubic-bezier(0.4, 0, 0.2, 1);
}
.btn:hover {
  transform: scale(1.1); /* 레이아웃 흐름을 바꾸지 않는 확대입니다. */
}

⚙️ 2. 성능의 골든 타임: Reflow를 피하라

애니메이션을 줄 때 절대 건드리지 말아야 할 속성들이 있습니다.

• 나쁜 예 (Reflow 유발): width, height, top, left, margin, padding
  👉 브라우저가 매 프레임마다 주변 요소의 위치를 다시 계산해야 할 수 있습니다. (반복되면 프레임 드랍 발생)
• 좋은 예 (Composite만 활성화): transform (scale, rotate, translate), opacity
  👉 브라우저의 레이어 합성 단계에서 처리하기 쉬워 반복 애니메이션에 적합합니다.

🐣 영철: "아! 그래서 제가 top을 바꿔서 버튼을 올렸을 때 렉이 걸렸던 거군요! 앞으론 translateY로 바꿔야겠어요!"

🎭 3. 자연스러운 움직임: easing의 미학

물체는 현실에서 일정한 속도로 움직이지 않습니다. linear 대신 ease-in-out이나 커스텀 cubic-bezier를 쓰면 훨씬 생동감 있는 인터랙션이 완성됩니다.

🦁 영호의 디테일:
"애니메이션이 끝나고 원래대로 돌아올 때 뚝 끊기지 않도록 transition을 호버가 아닌 원래 상태에 정의하는 걸 잊지 마세요."

📝 마무리 퀴즈

Q1. transform: rotate(45deg); 애니메이션은 브라우저 렌더링 파이프라인의 어떤 단계만 거치기 때문에 성능이 좋은 것일까요?

1. Layout
2. Paint
3. Composite
4. DOM Construction

✅ 정답: 3. Composite

💡 상세 해설:

• 원리: transform과 opacity는 브라우저가 미리 만들어둔 레이어를 단순히 재배치만 하면 됩니다. 비싼 계산 과정인 Layout이나 Paint를 건너뛰고 GPU에서 바로 처리(Composite)하므로 가장 부드럽습니다.
• 오답 피드백: "영철 님, 브라우저가 땀 흘리지 않게 하는 게 고수의 비결이에요. Composite 단계를 사랑해주세요!"

Q2. CSS 애니메이션의 한 사이클(0%~100%)을 정의하기 위해 사용하는 키워드는 무엇인가요?

1. @animation-steps
2. @keyframes
3. @timeline
4. @motion-path

✅ 정답: 2. @keyframes

💡 상세 해설:

• 원리: @keyframes는 애니메이션이 진행되는 동안 각 지점(Keyframes)에서 요소가 어떤 스타일을 가져야 하는지를 정의하는 설계도입니다.
• 오답 피드백: "영철 님, 시나리오 작가가 장면을 나누듯 @keyframes로 애니메이션의 스토리를 짜보세요."

Q3. [영철이의 테스트 타임: 실무 딜레마]
영철이가 사이드바를 왼쪽에서 오른쪽으로 나타나게 하려고 합니다. 처음에는 left: -300px에서 left: 0으로 옮겼는데, 영호 님이 "반복 애니메이션이라면 Layout을 다시 계산하지 않는 방법부터 검토해보자"라고 리뷰했습니다. 가장 성능에 유리한 구현 방법은 무엇일까요?

✅ 정답: transform: translateX(-100%)에서 transform: translateX(0)으로 부드럽게 이동시킨다.

💡 상세 해설:

• 원리 설명: left 값을 바꾸면 브라우저는 레이아웃(Reflow) 단계를 매번 거쳐야 합니다. 하지만 transform은 이미 그려진 레이어를 GPU가 위치만 옮겨주는 것이라 훨씬 빠르고 부드럽습니다.
• 오답 피드백: "영철 님, left는 레이아웃 위치를 바꾸지만 transform은 합성 단계에서 처리하기 쉽습니다. 움직임은 가능한 한 translate로 표현해보세요."
• 📌 핵심 기억법: "위치 이동은 left가 아니라 translate!"

🐣 영철이의 퇴근 일기

오늘 드디어 CSS 가이드의 중반부인 10장을 마쳤다.
애니메이션이 단순히 화려한 게 아니라, 얼마나 철저하게 브라우저의 성능을 고려해야 하는지 깨달은 게 가장 큰 소득이다.
유저가 "어? 부드럽다"라고 느끼는 0.1초 뒤에 이런 복잡한 렌더링 파이프라인이 숨어 있었다니!

💡 "좋은 애니메이션은 눈을 즐겁게 하고, 위대한 애니메이션은 CPU를 쉬게 한다."

영호 님이 "Reflow가 나쁜 게 아니라, 매 프레임 반복되는 Reflow를 모르고 두는 게 문제"라고 하셨던 말을 기억해야겠다.
내일부터는 애니메이션 PR을 올릴 때 어떤 속성을 움직였는지, 접근성에서 prefers-reduced-motion을 고려했는지까지 같이 적어보려 한다.

🔗 더 알아보기

• MDN: CSS 애니메이션 사용하기
• Cubic-Bezier 커브 생성기