마이크로인터랙션 설계 가이드: 사업 홈페이지와 SaaS 화면에서 신뢰를 만드는 애니메이션 기준
답부터 말하면, 마이크로인터랙션은 화면을 ‘예쁘게 움직이는’ 작업이 아니라 사용자가 지금 무엇을 눌렀고, 시스템이 어떤 상태이며, 다음에 무엇을 해야 하는지 알려주는 신뢰 신호입니다. 사업 홈페이지, SaaS 랜딩, 관리자 화면에서 먼저 손봐야 할 곳은 화려한 히어로 애니메이션이 아니라 CTA 버튼, 폼 제출, 저장·승인 처리, 로딩, 성공·오류 피드백, 화면 전환처럼 사용자의 불안이 생기는 지점입니다.
특히 2026년 현재 실무에서는 마이크로인터랙션을 Core Web Vitals와 분리해서 볼 수 없습니다. LCP는 첫 핵심 콘텐츠 노출, INP는 상호작용 후 다음 페인트까지의 지연, CLS는 예상치 못한 레이아웃 이동을 봅니다. 좋은 애니메이션은 이 지표를 방해하지 않으면서 상태 이해를 돕고, 나쁜 애니메이션은 클릭 후 반응을 늦추거나 요소를 밀어내 사용자가 다시 누르게 만듭니다. web.dev 기준에서 LCP는 2.5초 이하, INP는 200ms 이하, CLS는 0.1 이하를 좋은 경험의 기준으로 제시하며, 현장 데이터는 75번째 백분위로 보는 것이 권장됩니다. ([web.dev](https://web.dev/articles/lcp?hl=en&utm_source=openai))
AgentMit은 마이크로인터랙션을 프론트엔드 장식 항목이 아니라 전환·운영·접근성·성능을 함께 다루는 컴포넌트 정책으로 봅니다. 이 글은 대표, PM, 마케터, 디자이너, 비개발 의사결정자가 개발팀과 같은 언어로 논의할 수 있도록 우선순위, 설계 기준, 성능 예산, 접근성 체크리스트를 정리합니다.
1. 마이크로인터랙션의 목적: 감탄보다 안심
사용자가 버튼을 눌렀는데 아무 변화가 없으면 세 가지 의심이 생깁니다. ‘눌린 건가?’, ‘중복 제출되는 건가?’, ‘오류가 났는데 내가 모르는 건가?’ 이 의심이 문의 폼, 결제, 견적 요청, 관리자 저장, 권한 승인 같은 화면에서 발생하면 전환 손실이나 운영 실수로 이어질 수 있습니다.
실무 기준으로 좋은 마이크로인터랙션은 사용자의 질문에 1초 안에 답합니다. 눌렸는가, 처리 중인가, 성공했는가, 실패했다면 무엇을 고치면 되는가.
반대로 브랜드 인상을 위해 긴 진입 애니메이션, 패럴랙스, 자동 재생 일러스트를 넣는 것은 우선순위가 낮습니다. 사용자가 구매·문의·가입·승인 과업을 수행하는 화면에서는 움직임이 목적을 앞서면 안 됩니다. ‘멋있다’보다 ‘실수하지 않겠다’가 B2B 서비스 신뢰에 더 직접적입니다.
2. 어디에 먼저 적용할까: 화면 유형별 우선순위
마이크로인터랙션은 전체 화면에 고르게 뿌리는 작업이 아닙니다. 전환 또는 운영 리스크가 큰 접점부터 적용해야 합니다. 아래 표는 사업 홈페이지, SaaS 랜딩, 관리자 화면에서 우선순위를 정할 때 사용할 수 있는 기준입니다.
| 화면/컴포넌트 | 사용자 불안 | 우선 적용할 피드백 | 피해야 할 모션 |
|---|---|---|---|
| 메인 CTA 버튼 | 클릭이 되었는지 모름 | pressed 상태, 짧은 로딩, 완료 후 다음 단계 안내 | 버튼 위치가 움직이는 효과, 긴 흔들림 |
| 문의·가입 폼 | 입력 오류와 제출 상태가 불명확함 | 필드별 검증, 제출 중 비활성화, 성공/실패 메시지 | 오류 메시지가 늦게 나타나거나 화면 아래로 밀림 |
| SaaS 온보딩 | 다음에 무엇을 해야 할지 모름 | 단계 진행률, 완료 체크, 다음 행동 강조 | 전체 화면 튜토리얼을 강제 재생 |
| 관리자 저장/승인 | 중복 저장, 승인 누락, 권한 실수 | 저장 중, 저장됨, 실패, 되돌리기, 감사 로그 링크 | 처리 완료 전 모달이 닫히는 효과 |
| 데이터 로딩 테이블 | 멈춘 것인지 기다리면 되는지 모름 | 스켈레톤, 빈 상태, 재시도 버튼, 부분 로딩 | 의미 없는 무한 스피너만 표시 |
정부지원사업 MVP나 초기 SaaS에서는 전체 브랜드 모션을 만들기보다 데모와 검수에서 자주 보이는 핵심 흐름에 집중하는 편이 낫습니다. 예를 들어 ‘신청서 작성 → 파일 업로드 → 관리자 검토 → 승인 알림’ 흐름이 있다면, 각 단계의 상태 피드백이 히어로 애니메이션보다 우선입니다.
3. 마이크로인터랙션은 네 단계로 설계한다
좋은 마이크로인터랙션은 감으로 만들지 않습니다. 최소한 트리거, 규칙, 피드백, 다음 행동을 문서화해야 합니다.
| 구성 요소 | 질문 | 예시 |
|---|---|---|
| 트리거 | 무엇이 움직임을 시작하는가? | 버튼 클릭, 필드 blur, 토글 변경, 라우트 이동 |
| 규칙 | 어떤 조건에서 어떤 상태가 되는가? | 네트워크 요청 중 disabled, 오류 시 재시도 가능 |
| 피드백 | 사용자는 무엇을 보고 상태를 이해하는가? | pressed 색상, progress, toast, inline error |
| 다음 행동 | 사용자가 이어서 무엇을 해야 하는가? | 대시보드로 이동, 입력 수정, 되돌리기, 담당자 문의 |
버튼: hover보다 pressed와 loading이 중요하다
마케팅 페이지에서 hover 효과만 신경 쓰는 경우가 많지만, 모바일 사용자는 hover를 경험하지 않습니다. 실제 전환에 가까운 것은 tap/pressed, loading, success, error 상태입니다. CTA 버튼은 기본, 포커스, hover, pressed, disabled, loading, success 이후 상태를 모두 정의해야 합니다.
- pressed: 누른 즉시 색상·음영·scale을 아주 작게 바꿔 입력이 접수되었음을 보여줍니다.
- loading: 중복 제출을 막고, 버튼 라벨을 ‘전송 중’, ‘저장 중’처럼 동사형 상태로 바꿉니다.
- success: 버튼만 초록색으로 바꾸는 것보다 다음 화면, 확인 메시지, 메일 발송 여부를 함께 알려줍니다.
- error: ‘실패했습니다’만 보여주지 말고 원인과 해결 행동을 연결합니다. 예: ‘파일 용량이 큽니다. 10MB 이하로 다시 올려주세요.’
폼: 오류 애니메이션보다 오류 위치가 먼저다
폼 UX에서 흔한 실수는 오류를 토스트로만 띄우는 것입니다. 사용자는 어느 필드를 고쳐야 하는지 바로 알아야 합니다. 오류 메시지는 필드 가까이에 표시하고, 긴 폼에서는 첫 오류 필드로 포커스를 이동하거나 요약 영역을 제공합니다. 관련 내용은 디자인 시스템 접근성 통합 가이드의 포커스·키보드 기준과 함께 보는 것이 좋습니다.
- 입력 중 매 타이핑마다 빨간 오류를 띄우지 말고, 필드 이탈 후 또는 제출 시점에 검증합니다.
- 서버 검증이 필요한 사업자번호, 쿠폰, 초대코드는 ‘확인 중’ 상태를 따로 둡니다.
- 성공 메시지는 자동으로 너무 빨리 사라지지 않게 하고, 중요한 결과는 페이지 안에 남깁니다.
로딩: 스피너 하나로 모든 대기 상황을 처리하지 않는다
로딩은 길이보다 예측 가능성이 중요합니다. 짧은 처리에는 버튼 내부 spinner와 라벨 변경이 충분합니다. 데이터 목록처럼 레이아웃이 예상되는 화면은 스켈레톤이 적합합니다. 파일 변환, AI 분석, 대량 업로드처럼 시간이 길어질 수 있는 작업은 진행 단계, 예상되는 다음 상태, 백그라운드 처리 여부를 알려야 합니다.
| 상황 | 권장 피드백 | 운영 메모 |
|---|---|---|
| 버튼 클릭 후 짧은 요청 | 버튼 내부 loading, 중복 클릭 방지 | 요청 실패 시 원래 라벨과 재시도 상태 복원 |
| 카드·목록 데이터 로딩 | 스켈레톤, 영역 높이 예약 | CLS를 만들지 않도록 공간을 먼저 확보 |
| AI 생성·파일 처리 | 단계형 진행 메시지, 취소 또는 나중에 확인 | 작업 큐와 알림 정책까지 함께 설계 |
| 권한 부족·빈 데이터 | 빈 상태 설명, 다음 행동 버튼 | ‘데이터 없음’과 ‘접근 불가’를 구분 |
토스트와 알림: 사라져도 되는 정보만 자동으로 사라진다
토스트는 가벼운 성공 피드백에는 좋지만, 결제 실패, 저장 실패, 권한 오류처럼 사용자가 조치해야 하는 정보에는 부적절할 수 있습니다. 자동으로 사라지는 알림은 놓칠 수 있기 때문입니다. 중요한 오류는 화면 안에 남기고, 토스트에는 보조 정보를 담는 것이 안전합니다.
화면 전환: 맥락 유지가 목적일 때만 쓴다
상품 목록에서 상세로 이동하거나, 대시보드 카드에서 세부 차트로 들어갈 때의 전환 애니메이션은 사용자가 맥락을 잃지 않도록 돕습니다. View Transition API는 SPA의 DOM 상태 전환과 MPA의 문서 간 전환을 더 쉽게 구현할 수 있는 수단을 제공하지만, 브라우저 지원과 동일 출처 조건, fallback을 프로젝트 기준으로 확인해야 합니다. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API?utm_source=openai))
로그인, 결제, 권한 승인, 개인정보 수정처럼 결과 확신이 중요한 화면에서는 화려한 전환보다 명확한 확인 단계가 우선입니다. 전환 애니메이션이 사용자의 기억을 돕는지, 아니면 처리 완료를 늦게 보이게 하는지 구분해야 합니다.
4. 성능 예산: 움직임은 렌더링 비용을 먹는다
프론트엔드에서 애니메이션은 무료가 아닙니다. width, height, top, left, margin 같은 속성을 애니메이션하면 layout과 paint를 유발할 수 있고, 이는 모바일에서 버벅임과 INP 악화로 이어질 수 있습니다. web.dev는 고성능 애니메이션에서 transform과 opacity 중심의 구현을 권장하며, layout이나 paint를 유발하는 속성은 꼭 필요한 경우가 아니면 피하라고 설명합니다. ([web.dev](https://web.dev/articles/animations-guide?utm_source=openai))
| 결정 항목 | 권장 기준 | 주의점 |
|---|---|---|
| 움직일 속성 | transform, opacity 우선 | height 자동 펼침은 max-height 편법보다 레이아웃 비용을 측정 |
| 지속 시간 | 버튼·토스트 120~240ms, 모달·페이지 전환 180~320ms부터 검토 | 브랜드 모션을 이유로 500ms 이상을 기본값으로 두지 않기 |
| easing | 진입은 빠르게, 종료는 안정적으로 | bounce, elastic은 B2B 관리자 화면에서 신뢰감을 해칠 수 있음 |
| 동시 모션 수 | 한 시점에 주요 모션 1~2개 | 카드 여러 개가 순차 등장하면 저사양 기기에서 체감 지연 발생 |
| will-change | 곧 움직일 요소에 제한적으로 사용 | 상시 남겨두면 메모리 사용이 늘어날 수 있음 |
구현 기술은 ‘무엇이 더 최신인가’가 아니라 상태 로직과 성능 예산으로 고릅니다.
| 방식 | 적합한 경우 | 검토할 위험 |
|---|---|---|
| CSS transition/keyframes | 버튼, 토스트, 드롭다운, 단순 모달 | 상태가 많아지면 클래스 관리가 복잡 |
| Web Animations API | JS 상태와 애니메이션 제어가 함께 필요할 때 | 브라우저 지원과 팀 숙련도 확인 |
| 프레임워크 모션 라이브러리 | 복잡한 컴포넌트 전환, mount/unmount 애니메이션 | 번들 크기, SSR/CSR 경계, hydration 영향 |
| Lottie | 브랜드 일러스트, 온보딩의 짧은 설명 모션 | 파일 크기, 반복 재생, 저사양 모바일, 동작 줄이기 대응 |
| View Transition API | 목록-상세, 탭, 라우트 전환의 맥락 유지 | 지원 브라우저 fallback, 동일 출처 조건, 과도한 snapshot |
이미 Core Web Vitals가 고민이라면 마이크로인터랙션을 별도 프로젝트로 보지 말고 Core Web Vitals 최적화 가이드의 LCP·INP·CLS 점검과 함께 묶어야 합니다. 애니메이션을 추가한 뒤 PageSpeed Insights 점수만 보는 것으로는 부족하고, 실제 사용자 플로우에서 버튼 클릭 후 피드백이 늦는지, 목록이 밀리는지, 모바일에서 프레임이 끊기는지 확인해야 합니다.
5. 접근성: 동작 줄이기 설정은 선택 기능이 아니라 기본 배려다
모든 사용자가 움직임을 편하게 느끼는 것은 아닙니다. MDN은 prefers-reduced-motion 미디어 기능이 사용자의 기기 설정에서 비필수 움직임을 줄이려는 선호를 감지하는 용도라고 설명합니다. 또한 W3C WCAG 2.2.2는 자동으로 시작되고 5초 이상 지속되는 움직임·깜빡임·스크롤·자동 업데이트 정보에 대해 사용자가 일시정지, 중지, 숨김 또는 빈도 제어를 할 수 있어야 한다고 봅니다. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/%40media/prefers-reduced-motion?utm_source=openai))
실무 적용은 간단한 원칙에서 시작합니다.
- 큰 이동을 줄입니다. 화면 전체 슬라이드, 확대/축소, 패럴랙스는 opacity 전환이나 즉시 전환으로 대체합니다.
- 반복 모션을 멈춥니다. 무한 회전, 깜빡임, 자동 캐러셀은 정지 버튼 또는 정적 대체 상태를 제공합니다.
- 정보는 움직임에만 의존하지 않습니다. 성공은 색상과 체크 아이콘, 텍스트를 함께 사용하고, 오류는 명확한 문장으로 설명합니다.
- 키보드와 스크린리더 흐름을 확인합니다. 모달 전환 후 포커스가 어디로 가는지, toast가 보조 기술에 전달되는지 점검합니다.
예를 들어 CSS에서는 기본 애니메이션을 정의한 뒤 @media (prefers-reduced-motion: reduce) 조건에서 duration을 매우 짧게 하거나 transform을 제거할 수 있습니다. 핵심은 사용자가 요청한 환경을 존중하면서도 상태 피드백은 사라지지 않게 하는 것입니다.
6. 디자인 시스템으로 관리하지 않으면 화면마다 말투가 달라진다
팀이 커질수록 마이크로인터랙션은 개인 취향의 문제가 됩니다. 어떤 디자이너는 버튼을 튀게 만들고, 어떤 개발자는 스피너만 붙이고, 관리자 화면은 아무 피드백 없이 저장됩니다. 이를 막으려면 모션을 디자인 토큰과 컴포넌트 상태로 관리해야 합니다. 색상과 간격만 토큰화하는 것이 아니라 duration, easing, distance, opacity, z-index, feedback copy까지 기준화하는 것이 좋습니다.
| 토큰 예시 | 용도 | 초기값 예시 |
|---|---|---|
| motion.duration.fast | 버튼 pressed, 작은 hover | 120ms |
| motion.duration.base | 토스트, 드롭다운 | 180ms |
| motion.duration.slow | 모달, 페이지 일부 전환 | 280ms |
| motion.easing.standard | 일반 UI 이동 | ease-out 계열 |
| motion.distance.sm | 토스트·드롭다운 진입 거리 | 4~8px |
이 값은 절대 규칙이 아니라 출발점입니다. 중요한 것은 모든 팀원이 같은 이름으로 같은 의도를 말하는 것입니다. 토큰 운영 방식은 디자인 토큰 관리 가이드와 함께 정리하면 Figma와 코드의 차이를 줄일 수 있습니다.
컴포넌트 문서에 반드시 들어갈 상태
- Button: default, hover, focus, pressed, disabled, loading, success, destructive
- Input: empty, focus, filled, validating, valid, invalid, disabled, readonly
- Toast: success, info, warning, error, undo 포함 여부, 자동 닫힘 시간
- Modal: open, closing, focus trap, backdrop click, escape, reduced motion
- Table: loading, empty, filtered empty, partial error, row saving, bulk action progress
Storybook이나 내부 컴포넌트 문서에서 이 상태를 직접 눌러볼 수 있어야 합니다. 문서에 ‘부드러운 전환’이라고 적는 것보다, 실제 상태별 스크린샷과 인터랙션을 제공하는 편이 개발·QA·외주 협업에서 훨씬 안전합니다.
7. 전환율 검증: 예쁜지 묻지 말고 과업이 줄었는지 본다
마이크로인터랙션의 성과를 ‘디자인이 좋아 보인다’로 평가하면 의사결정이 흐려집니다. 다음과 같은 질문으로 검증해야 합니다.
- CTA 클릭 후 중복 클릭이나 rage click이 줄었는가?
- 문의 폼에서 오류 발생 후 수정 완료까지 시간이 줄었는가?
- 로딩 중 이탈이 줄었는가?
- 관리자 저장 실패 후 재시도 성공률이 개선되었는가?
- 모바일 INP와 CLS가 악화되지 않았는가?
트래픽이 충분한 랜딩페이지라면 A/B 테스트를 검토할 수 있습니다. 다만 초기 B2B 서비스, 정부지원사업 MVP, 사내 관리자 화면처럼 표본이 적은 경우에는 A/B 테스트보다 과업 기반 사용성 테스트, 세션 리플레이, 이벤트 로그 비교가 더 현실적입니다. ‘가격 문의 버튼을 눌러 상담 신청을 완료해보세요’ 같은 과업을 주고, 사용자가 멈칫하는 지점과 재클릭하는 지점을 기록하면 우선 개선할 마이크로인터랙션이 드러납니다.
8. 피해야 할 안티패턴
- 긴 첫 진입 애니메이션: 첫 화면의 핵심 메시지와 CTA를 늦게 보여주면 브랜드보다 대기감이 먼저 남습니다.
- 클릭 후 위치가 변하는 버튼: 사용자가 다시 누르려는 순간 버튼이 움직이면 실수와 불신을 만듭니다.
- 무한 스피너: 처리 중인지 실패인지 알 수 없습니다. 일정 시간이 지나면 재시도, 문의, 백그라운드 처리 옵션을 제공해야 합니다.
- 성공 토스트만 표시하고 결과가 사라짐: 중요한 저장·결제·신청 결과는 화면 내 상태로 남겨야 합니다.
- 접근성 설정 무시: reduced motion 사용자를 고려하지 않은 패럴랙스와 확대 모션은 일부 사용자에게 실제 불편을 줄 수 있습니다.
- 디자인 시안에는 있지만 개발 예외가 없는 모션: 네트워크 실패, 권한 오류, 빈 데이터 상태가 정의되지 않으면 운영 화면에서 바로 깨집니다.
9. 2주 파일럿으로 시작하는 적용 로드맵
마이크로인터랙션은 전체 리뉴얼을 기다릴 필요가 없습니다. 작은 범위에서 측정 가능한 파일럿으로 시작하는 편이 안전합니다.
- 1~2일차: 핵심 플로우 선정 - 문의, 가입, 결제, 저장, 승인 중 하나를 고릅니다.
- 3~4일차: 상태표 작성 - 버튼, 폼, 로딩, 성공, 오류, 빈 상태를 표로 정리합니다.
- 5~7일차: 토큰과 컴포넌트 구현 - duration, easing, reduced motion, ARIA 메시지를 포함합니다.
- 8~10일차: 모바일 실기기 테스트 - 저사양 안드로이드, iOS, 느린 네트워크, 키보드 탐색을 확인합니다.
- 11~14일차: 로그와 사용성 테스트 - 클릭 후 피드백, 중복 클릭, 제출 완료율, 오류 수정률을 비교합니다.
AgentMit/BizMit 프로젝트에서는 SaaS, 관리자 대시보드, 업무 자동화, AI 기능 화면을 만들 때 마이크로인터랙션을 별도 장식 작업으로 분리하지 않습니다. 기획 단계에서 상태표를 만들고, 디자인 토큰과 컴포넌트 구현, 프론트엔드 성능 측정, 접근성 점검을 한 묶음으로 다룹니다. 이미 운영 중인 서비스라면 전체 리뉴얼보다 핵심 전환 플로우 1개를 골라 시범 적용하는 방식이 비용과 리스크를 줄입니다.
출시 전 체크리스트
- 주요 CTA에 pressed, loading, success, error 상태가 있는가?
- 폼 오류가 필드 근처에 표시되고 키보드 포커스가 자연스러운가?
- 로딩 상태가 스피너, 스켈레톤, 단계형 진행 중 상황에 맞게 구분되어 있는가?
- 모션이 transform과 opacity 중심으로 구현되어 있는가?
- 애니메이션 추가 후 INP와 CLS가 악화되지 않았는가?
prefers-reduced-motion에서 큰 이동과 반복 모션이 줄어드는가?- 중요한 오류와 완료 정보가 자동으로 사라지지 않는가?
- 모바일 실기기와 느린 네트워크에서 버벅임이 없는가?
- 디자인 토큰과 컴포넌트 문서에 상태별 기준이 남아 있는가?
FAQ
Q1. 마이크로인터랙션은 모든 버튼과 화면에 넣어야 하나요?
아닙니다. 전환에 가까운 CTA, 제출 버튼, 결제·문의·가입 폼, 관리자 승인/저장 상태처럼 사용자가 불안을 느끼는 지점부터 적용하는 것이 좋습니다. 장식 목적의 전체 화면 애니메이션보다 조작 결과를 즉시 알려주는 피드백이 우선입니다.
Q2. SaaS 랜딩페이지에서 전환율에 도움이 되는 마이크로인터랙션은 무엇인가요?
주요 CTA의 눌림·로딩·완료 상태, 가격표나 기능 비교의 선택 상태, 데모 신청 폼의 인라인 검증, 스크롤 후에도 맥락을 잃지 않는 섹션 전환이 우선입니다. 단, 효과는 업종마다 달라서 클릭률·폼 완료율·이탈 구간을 함께 측정해야 합니다.
Q3. CSS 애니메이션, JavaScript, Lottie 중 무엇을 써야 하나요?
버튼, 토스트, 드롭다운, 모달 같은 UI 반응은 CSS transition이나 Web Animations API로 충분한 경우가 많습니다. 복잡한 브랜드 일러스트는 Lottie를 검토할 수 있지만 파일 크기, 반복 재생, 모바일 성능을 반드시 확인해야 합니다.
Q4. prefers-reduced-motion을 적용하면 애니메이션을 전부 없애야 하나요?
전부 제거할 필요는 없습니다. 큰 이동, 확대/축소, 패럴랙스, 반복 회전처럼 불편을 줄 수 있는 비필수 모션을 줄이거나 opacity 전환, 즉시 상태 변경, 짧은 하이라이트로 대체하는 방식이 현실적입니다.
Q5. 마이크로인터랙션 설계 성과는 어떻게 검증하나요?
주요 버튼의 클릭 후 피드백 시간, 폼 오류 수정률, 제출 완료율, rage click, 모바일 INP, CLS, 세션 녹화의 이탈 지점을 함께 봅니다. 트래픽이 적은 초기 서비스는 A/B 테스트보다 과업 기반 사용성 테스트와 로그 비교가 더 실용적일 수 있습니다.
참고 자료
이 글은 공개 문서와 브라우저 플랫폼 자료를 참고해 작성했습니다. 프로젝트별 브라우저 지원, 트래픽, 디바이스 분포, 디자인 시스템 성숙도에 따라 적용 우선순위는 달라질 수 있습니다.
- web.dev LCP, INP, CLS 문서: Core Web Vitals 기준과 측정 관점 참고. ([web.dev](https://web.dev/articles/lcp?hl=en&utm_source=openai))
- web.dev 애니메이션 성능 문서: transform·opacity 중심 구현과 렌더링 비용 판단 참고. ([web.dev](https://web.dev/articles/animations-guide?utm_source=openai))
- MDN prefers-reduced-motion, W3C WCAG 2.2.2: 동작 줄이기와 반복 모션 접근성 기준 참고. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/%40media/prefers-reduced-motion?utm_source=openai))
- MDN 및 Chrome View Transition 문서: SPA·MPA 전환 구현 가능성과 fallback 판단 참고. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API?utm_source=openai))
