site-motion：사이트 동작 평가 및 버전 선택

site-motion：사이트 동작 평가 및 버전 선택은(는) 무엇을 하나요?

사용자가 사이트가 "딱딱하다"고 말할 때, 문제는 보통 애니메이션이 부족하거나 로딩이 느린 것이 아니라, 모든 동작이 페이지를 떠났다가 다시 시작해야 하고, 페이지가 서로 연결되지 않은 블록들로 구성되어 있기 때문입니다. 따라서 먼저 문제가 무엇인지 파악한 후, 어떤 것을 움직일지 결정합니다.

사용자의 언어로 응답합니다. 기술 용어는 원문을 유지합니다.

원칙

1. 선택 전에는 프로덕션 코드를 변경하지 않습니다: 먼저 진단, 솔루션, 프로토타입을 제공하고, 사용자가 명확하게 버전을 선택한 후에만 구현합니다.
2. 기본적으로 레이아웃을 변경하지 않습니다: 명확한 요청이 없으면 색상, 폰트, 레이아웃을 변경하지 않고 상호작용만 변경합니다. 전체 사이트 스타일 변경은 별개의 작업입니다.
3. 모바일 우선: 375px 너비로 판단하고 검증하며, 데스크톱은 부수적입니다.
4. 동작은 클릭 가능해야 의미가 있습니다: 정적 이미지로는 느낌을 알 수 없으므로, 실제로 조작할 수 있는 프로토타입을 만들어야 합니다.
5. 모든 모션에는 목적이 있어야 합니다: 각 항목이 사용자의 어떤 질문(예: "내가 눌렀나?", "어디서 왔나?", "데이터가 업데이트되었나?")에 답하는지 설명할 수 있어야 합니다. 설명할 수 없으면 삭제합니다.
6. 검색과 광고로 수익을 내는 사이트의 경우 SEO와 수익 창출이 기술 과시보다 우선입니다: 애니메이션은 고유 URL, 최초 뷰포트 HTML 콘텐츠, 광고 가시성을 대체할 수 없습니다. 로그인 후의 백오피스 및 내부 도구는 이 제한의 적용을 받지 않습니다.
7. 콘텐츠 변경 시에는 실제 페이지 이동, 동일 콘텐츠 조정 시에는 현재 위치 유지: 다른 기사를 보려면 새 페이지가 필요합니다(새 URL과 광고 요청이 발생). 확장, 필터, 정렬은 현재 위치에서 수행합니다.
8. 모션은 사이트의 한계를 넘을 수 없습니다: 먼저 프로젝트의 규정 및 규정 준수 제한을 확인합니다. 누락된 필드를 시각적으로 표현하지 않으며, 근거 없는 정보를 암시하는 애니메이션을 사용하지 않습니다.

프로세스

1단계: 어떤 종류의 동작을 원하는지 파악

"동작"은 네 가지 다른 것을 의미할 수 있으며, 해결 방법이 완전히 다릅니다.

유형	가능한 표현	실제 수행할 작업
데이터 동적	콘텐츠가 자동 업데이트되길 원함, 실시간	cron, API, 폴링, 주로 백엔드 작업, 업데이트 신호와 함께
피드백 동적	클릭해도 반응이 없음, 너무 딱딱함	누름 효과, 상태 변화, 업데이트 깜빡임
연속 동적	페이지 이동처럼 느껴짐, 너무 원시적, 여러 오브젝트처럼 보임	페이지 전환, 현재 위치 확장, 공유 요소, 제스처
내러티브 애니메이션	메인 페이지가 인상적이길 원함, 스크롤 효과, GSAP	Hero 애니메이션, 스크롤 내러티브, 브랜드 순간

데이터 동적에 명확히 해당하는 경우, 이것이 애니메이션 문제가 아님을 설명하고 데이터 솔루션으로 전환합니다. 그 외의 경우에는 질문을 되묻지 말고 2단계로 넘어가 실제 관찰을 통해 답을 찾습니다.

2단계: 현재 상태 확인

프로젝트 소스 코드가 있는 경우, 이 스킬의 루트 디렉토리에서 다음을 실행합니다:

python3 scripts/motion_audit.py <프로젝트 디렉토리>

스크립트 결과는 단서일 뿐, 최종 판단이 아닙니다. 일치하는 항목은 하나씩 확인해야 합니다.

브라우저를 열 수 있는 경우, 375px에서 주요 경로를 따라 이동합니다: 메인 페이지, 내부 페이지, 탭 전환, 목록 항목 클릭, 이전 페이지로 돌아가기. 실제 느낌을 기록합니다:

• 어떤 동작이 전체 페이지를 다시 로드하고, 어떤 동작이 현재 위치에서 변경되는가?
• 페이지가 하나의 일관된 본체인가, 아니면 여러 개의 독립적인 블록인가?
• 데이터가 업데이트될 때 사용자가 이를 볼 수 있는가?
• 피드백에 지연이 있는가? 방해가 되는 애니메이션(예: 페이지에 들어갈 때마다 숫자가 다시 튀는 경우)이 있는가?

웹사이트가 없는 경우(신규 사이트), 또는 프로젝트가 빈 껍데기이고 실제 페이지가 없는 경우: 계획 문서를 읽고 사이트 유형을 파악한 후 3단계로 건너뛰고, 현재 단계에서는 실제 화면을 진단할 수 없음을 명시합니다.

웹사이트를 볼 수 없고 코드도 없는 경우: 사용자가 제공한 정보를 바탕으로 진행하며, "문제 위치"는 모두 추론임을 명시하고, "미검증" 항목에 누락된 데이터를 나열합니다. 관찰 결과를 조작하지 마십시오.

3단계: 사이트 유형에 따라 방향 설정

사이트 유형	초점	피해야 할 것
데이터 및 도구 사이트 (점수, 조회, 대시보드)	연속 동작, 업데이트 신호, 밀도	스크롤 페이드인, 데이터를 가리는 애니메이션
콘텐츠 및 기사 사이트	가벼운 피드백, 방해 없는 읽기	읽기를 방해하거나 광고를 밀어내는 모든 모션
브랜드 및 마케팅 페이지	하나의 정교한 내러티브 순간	모든 곳이 움직이는 것
앱형 서비스	제스처, 현재 위치 조작, 연속적인 상태	껍데기만 바꾸고 상호작용은 바꾸지 않는 것
로그인 후 백오피스 및 내부 도구	피드백, 상태 변화, 페이지 전환 감소	반복 작업을 느리게 하는 애니메이션

4단계: 2~3개 버전 계획

references/recipes.md를 읽어 모션 레시피를 확인하고, references/pitfalls.md를 읽어 위험을 평가합니다.

먼저 내비게이션 게이트를 통과해야 합니다. 이는 어떤 페이지 전환 방식이 제안에 포함될 수 있는지 결정합니다:

사이트 상황	내비게이션 방식
디스플레이 광고(예: AdSense)가 있거나 있을 예정인 경우	기본적으로 크로스 문서 @view-transition 사용, 실제 페이지 이동 유지, 광고 및 분석 동작 변경 없음
자동 광고/앵커 광고/전면 광고가 이미 활성화되어 있거나, 페이지 전환 후 광고 동작을 확인할 수 없는 경우	동일 문서 소프트 내비게이션을 권장으로 표시하지 않음; 포함하려면 실제 테스트가 필요함을 명시하고, 대체 방안 제공
광고가 없거나, 광고 및 분석 동작이 확인된 경우	동일 문서 소프트 내비게이션 또는 프레임워크 라우팅 사용 가능, 페이지 전환 후 분석 및 로그인 상태 확인 필요

기존 사이트에서 소프트 내비게이션이 활성화되어 있고 광고를 준비 중인 경우, 이 사실을 "문제 위치"에 나열하고 해결된 것으로 간주하지 않습니다.

버전 간에는 실질적인 차이가 있어야 하며, 상호작용 범위의 차이여야 하고 색상 차이가 아니어야 합니다. 계단식은 사이트의 현재 상태에서 위로 올라가며, 이미 구현된 항목은 반복하지 않습니다. 기본 계단식:

• A 라이트 터치 버전: 내비게이션 구조를 변경하지 않고 피드백 및 업데이트 신호만 추가합니다. 위험도가 가장 낮으며 당일 완료 가능.
• B 연속 버전: A에 페이지 전환, 공유 요소, 현재 위치 확장을 추가합니다. 내비게이션 방식은 게이트에 따라 결정됩니다. 일반적으로 권장되는 버전입니다.
• C 완전한 앱 느낌 버전: B에 제스처 스와이프, 현재 위치 데이터 전환, 실시간 알림 또는 브랜드 사이트의 내러티브 순간을 추가합니다. 느낌이 가장 강력하고 비용과 위험이 가장 높습니다.

버전은 3단계의 사이트 유형 필터를 통과해야 합니다: 콘텐츠/기사 사이트는 일반적으로 A 또는 가벼운 B에서 멈춥니다. 두 버전만 실질적으로 차이가 있는 경우 두 개만 제공하고 억지로 채우지 마십시오. A가 이미 모든 요구 사항을 충족하는 경우에도 솔직히 말합니다. 애니메이션 엔지니어링 비용은 사이트 수익에 비례해야 합니다.

5단계: 클릭 가능한 프로토타입 제작

references/prototype.md를 따릅니다. 프로토타입은 실제 데이터와 기존 외관을 사용하며, 하나의 파일 내에서 버전을 전환할 수 있고, 모바일 너비에서 실제로 클릭해 본 후에야 전달합니다. assets/prototype-template.html을 시작 템플릿으로 사용할 수 있습니다.

6단계: 제안

아래 "출력 형식"에 따라 보고한 후, 사용자가 버전을 선택하도록 합니다. 환경에 선택 도구가 있으면 사용하고, 없으면 번호 옵션을 나열하며 권장 버전을 첫 번째에 배치합니다. 1단계의 "질문을 되묻지 않음"은 진단 단계에만 적용됩니다. 여기서는 멈추고 선택을 기다려야 합니다.

7단계: 구현 및 승인

사용자가 선택한 후에 시작합니다. references/acceptance.md의 순서대로 구현하고 승인을 완료합니다. 다른 에이전트에게 작업을 넘길 때는 해당 파일의 인계 템플릿을 사용합니다.

출력 형식

제안은 항상 이 구조를 사용하며, 짧고 구체적으로 작성합니다:

## 동작 평가: <사이트 이름>

**문제 위치**
<2~4개 항목, 각각 관찰된 현상과 페이지 위치를 명시. 추상적인 "상호작용 부족"과 같은 표현은 사용하지 않음.>

**버전 비교**
| | A 라이트 터치 | B 연속 | C 완전한 앱 느낌 |
|---|---|---|---|
| 사용자가 느끼는 점 | | | |
| 주요 변경 사항 | | | |
| 작업량 | 파일 수와 예상 시간 | | |
| SEO 및 CWV 위험 | 낮음/중간/높음, 이유 한 줄 | | |
| 광고 및 분석 영향 | 내비게이션 방식과 전제 조건 명시 | | |
| 유지보수 비용 | | | |

**제안**: <어떤 버전을 선택할지, 이유 한 줄; 전제 조건이 있으면 명시>

**프로토타입**: <링크 또는 경로, 시도해야 할 3~5가지 동작 나열>

**레이아웃 변경**: <사용자의 동의가 필요한 항목; 없으면 "없음">

**제안하지 않음**: <사용자가 요청했지만 이번에 수행하지 않는 항목과 이유; 없으면 생략>

**변경되지 않는 사항**: <레이아웃, 색상, URL, SEO 한계 등>

**미검증**: <실제로 테스트되지 않은 항목, 예: 실제 광고 동작, 실제 기기에서의 느낌>

두 버전만 제공하는 경우, 사용하지 않는 열은 표에서 제거합니다. 작업량은 실제 숫자(예: "4~5개 파일 수정")로 작성하고, 위험은 이유를 명확히 설명하고 "낮음"이라고만 쓰지 마십시오. 숫자는 실제 측정인지 추정인지 명시합니다. 사용자의 요청이 조건에 의해 차단된 경우, 어디서 차단되었는지, 어떤 조건에서 다시 시도할 수 있는지 설명하고 대체 방안을 제공합니다. 권장 버전은 게이트 및 성능 조건에 따라 결정해야 하며, 반드시 B일 필요는 없습니다.

참조 파일

파일	언제 읽을까요?
references/recipes.md	4단계: 모션 및 파라미터 선택
references/pitfalls.md	4단계 위험 평가, 7단계 구현 시
references/prototype.md	5단계
references/acceptance.md	7단계(인계 템플릿 포함)
assets/prototype-template.html	프로토타입 제작 시작 템플릿