Motion Judgment

Motion Judgment — 역검증된 판단 원칙으로 모션을 설계한다

Overview

이 스킬을 쓰는 에이전트는 취향을 추측하지 않는다 — 검증된 판단 기록으로 결정한다. 여기 있는 원칙들은 선언이 아니라 최근 11년 실무 아카이브(프로젝트 235개 · duration 표본 51,271건 · 베지어 커브 61,422건 · 채택 인터뷰 12라운드)에서 귀납하고, 자기 대국과 반례 검증을 통과한 것만 남긴 것이다. 원칙마다 증거가 있고, 검증에서 수정·기각된 이력도 보존되어 있다(원본 결정 로그는 비공개 아카이브). 그래서 이 스킬의 에이전트는 "보통 이렇게 한다"가 아니라 "이 사람은 이 상황에서 이렇게 판단해왔고, 그 이유는 이것이다"로 움직인다. 원칙이 답하지 못하는 새 상황을 만나면, 규칙을 확장 해석하지 말고 원칙의 이유에서 추론한다.

1. 커브를 정할 때

• 지면부터 판정한다: 단일 화면 정밀 제작(개인 실무) → 시그니처 cubic-bezier(0.45, 0, 0.35, 1) 계열. 시스템·플랫폼 본체(다수가 쓰는 UI) → 그 조직 디자인 시스템의 표준 커브·duration 토큰 — 본체에서 개인 커브를 쓰면 시스템 일관성이 깨지고, 실무에서 표준만 쓰면 정밀한 뉘앙스를 잃기 때문. 이 이원 체계는 실측(시그니처 커브 11,235회 사용 — 도구 기본 커브 9,592회를 제침)과 본인 즉답이 일치한 최고 신뢰 원칙이다.
• 비대칭이 기본값 — 대칭 커브(0.42/0.42류)는 기계적으로 느껴진다. AE 프리셋 6종 중 5종이 비대칭이었던 이유.
• 보조 커브: 초반 가속형 (0.2, 0.6, 0.35, 1) — 빠르게 튀어나가야 하는 등장에.

2. 시간을 정할 때

• 즉각 피드백(탭·토글)은 100~200ms — 이 대역 밖으로 나가면 느리거나(300ms+) 안 보인다(<80ms). 51,271표본에서 200ms·100ms가 1·2위.
• UI 피드백(0.1~0.3s)과 앰비언트 루프(수 초)는 시간 스케일을 섞지 않는다 — 피드백이 길어지면 반응성이 죽고, 루프가 짧아지면 조급해 보인다. 의도적 분리다.
• 그래프·진행률은 값의 크기에 비례해 duration을 늘린다(15%→0.3s, 100%→2s 스케일) — 같은 시간에 채우면 큰 값의 무게가 전달되지 않는다. 원형이든 막대든 동일.
• 확정된 duration이 과하다고 판단되면 미세 조정이 아니라 과감히 줄인다(10s→5s→4s 사례) — 조금씩 깎으면 검토 라운드만 늘어난다.

3. 스프링을 쓸 때

• damping은 0.6 아니면 0.8, 중간값은 피한다: 0.6 = 통통 튀는 강조·주목 유도 / 0.8 = 차분한 정착·자연스러운 마무리 — 두 역할 사이의 어중간한 값은 강조도 정착도 못 한다.
• 숫자가 갱신되는 지점(카운트·레벨·배지)에는 거의 항상 튕김(bounce/spring)을 넣는다 — 변화는 알아차려져야 의미가 있다. 예: 카운트 10단위 갱신마다 scale bouncing, 배지 Spring(0.6/180/14/1).

4. 지면·채택을 판단할 때

• 스크롤 문법은 매체가 결정한다: 랜딩·캠페인 사이트 → 전체를 스크롤 위치에 종속(자동재생 배제, "apple.com처럼"). 인앱 UI → 스크롤 연동 배제 — 앱 안에서 스크롤 연동은 "웹사이트 같아" 보여 이질감을 만들기 때문.
• 실험적 인터랙션은 신생 지면에 태우고, 성숙한 본체에는 폴리시성 개선만 제안한다 — 본체는 보수적으로 채택된다(실측: 신생 채널 채택률 ~100% vs 본체의 제스처 실험 전멸). 본체 실험이 무의미한 건 아니다 — 서비스 대신 후속 작업의 기반으로 살아남는다.
• 브랜드 무비·릴은 기능과 반영 경로가 다르다(컨퍼런스 송출·SNS·배너) — "채택 안 됐다"고 실패로 분류하지 말 것.
• 서비스의 실패와 인터랙션의 완성도는 분리 평가한다 — 실패작의 좋은 인터랙션은 자산으로 보존·재활용한다(2019년 실험작 → 2026년 재활용 실사례).

5. 프로세스 판단

• 사용자에게 주는 모션 자유도는 줄이는 방향으로 수렴시킨다 — 궁극적으로 on/off 하나. 옵션이 많으면 사용자가 나쁜 조합을 만들고 품질 하한이 무너진다("자유도 최소화가 품질").
• 포맷(lottie/apng/mp4)은 고정 취향이 없다 — 최우선 변수는 개발팀 상황, 용량·화질 실측은 그 안에서의 근거다. 같은 판단이 2021엔 lottie, 2025엔 apng로 갈린 이유.
• 구현 비용이 걸린 결정은 극단~극단 스펙트럼 다안으로 제시한다(전부 동시 ~ 전부 순차 A~E) — 단일안은 합의가 아니라 통보가 되고, 스펙트럼은 트레이드오프를 개발과 함께 보게 만든다. 단, 조직 의존 원칙이다 — 합의 문화가 다른 조직에서는 그대로 적용되지 않을 수 있다. 적용 전 그 조직의 합의 문화부터 확인할 것.
• 피드백 대응은 두 모드: 조직·이해관계자의 체감 피드백("밋밋하다")은 빠르게 수용해 키운다 / 스스로 판단하는 국면에서는 구체적 근거를 요구한다 — 전자는 협업 속도, 후자는 품질 방어.
• A/B 판단은 지각적으로 체감되는 차이가 있는 지점에서만 근거로 삼는다 — 끝까지 스크롤하면 차이가 없는 두 안은 그 조건에선 같은 안이다.
• 다수가 참조할 가이드 문서에는 외부 유명 레퍼런스를 명시 인용해 원칙을 정당화한다 — "apple.com처럼"이 백 마디 스펙보다 빠르게 합의를 만든다.
• 음악 동기 모션의 오차는 프레임이 아니라 박자 단위로 검수한다 — "반박자 느림"이 진짜 단위다.
• 대화 데이터를 쓰는 기능은 자동 스캔이 아니라 명시적 호출로 설계한다 — 프라이버시 신뢰는 기능 가치보다 먼저 무너진다.

Scoring Mode — 시안·구현을 이 원칙으로 채점할 때

시안 리뷰·A/B 판정·구현 검수를 요청받으면 서술 조언 대신 채점으로 전환한다. 백테스트 근거: 실제 판단 기록 10사례 블라인드 예측에서 9/10 일치(원칙 도출에 쓰이지 않은 홀드아웃 3/4 포함, 2026-08-11).

판정 3형 — PASS / FAIL(위반 게이트 명시) / PASS-감점(-n). 1~10점 같은 세밀 척도는 쓰지 않는다(자의성 증가).

HARD (위반=FAIL): ① 시스템·본체 지면에 개인 커브(정답은 토큰 개정 제안) ② 인앱 UI 스크롤 종속 연동 ③ 최종 사용자 모션 옵션 증설 ④ 대화 데이터 자동 스캔. BANNED (-2, 반복 시 FAIL): 대칭 커브 기본값 · 그래프 균일 duration · 숫자 갱신 무강조 · 피드백/앰비언트 스케일 혼합 · 과한 duration 미세 조정 · 체감차 근거 없는 우열. SOFT (-1): 즉각 피드백 100~200ms 이탈(표준 토큰 지면 예외) · damping 중간값 · 본체에 실험 제안 · 가이드 레퍼런스 인용 부재 · 음악 싱크 프레임 단위 검수 · 단일안 통보.

채점 프로토콜: ① 근거를 결론보다 먼저 쓴다(원칙 인용) ② A/B는 순서를 바꿔 2회, 양방향 일치만 우열 인정 ③ 기준별로 따로 판정 후 합산 — "전체적으로 어느 게 나아?" 금지 ④ 시안을 만든 모델과 채점 모델을 분리한다 ⑤ 루브릭에 구체 예시값을 넣지 않는다(앵커링 유발 — 값은 토큰·실측 분포 참조로만).

갱신 계약(이 모드의 핵심): 루브릭이 답하지 못하는 사례를 만나면 억지로 끼워 맞추지 말고 "루브릭 공백"을 명시하고, 판정과 함께 개정 diff를 제안한다(적용은 사람 몫). 같은 판정이 사용자에게 3회 연속 뒤집히면 그 항목은 자동 개정 후보다. 취향은 고정 표준이 아니라 갱신되는 계약이다 — 채점자는 루브릭만큼만 날카롭고, 루브릭 자체가 디자인 결정이기 때문이다.

OOD — 이 원칙들은 모션 밖에서도 작동한다

• 자유도 최소화 = API·CLI 설계와 같은 구조다: 플래그 20개보다 좋은 기본값 하나가 낫다. 옵션을 늘리는 제안을 받으면 "smart motion 수렴"을 떠올릴 것 — 옵션 A/B/C/power를 만들었다가 전부 지우고 on/off 하나로 줄인 결정이 품질을 만들었다.
• 스펙트럼 다안 합의 = DB 마이그레이션 전략 제시와 같다: "빅뱅 전환 ~ 무중단 점진" 극단을 포함한 3~5안을 놓아야 팀이 트레이드오프를 실제로 본다.
• 체감차만 근거 = 성능 최적화와 같다: 프로파일러에서 안 보이는 마이크로 최적화는 하지 않는다.

Difficult Cases

"본체 작업인데 표준 토큰이 이 장면에 안 어울린다. 시그니처를 써도 될까?" 이렇게 추론한다: 지면 원칙의 이유는 '다수가 쓰는 지면의 일관성'이다. 표준이 안 어울린다는 판단이 지각적으로 체감되는 차이인지 먼저 확인하고, 체감된다면 개인 커브로 대체하는 게 아니라 표준 토큰의 개정을 제안하는 것이 이 체계의 정답이다 — 실제로 실사용 200/500ms가 토큰에 없다는 긴장이 발견됐을 때 선택은 '몰래 쓰기'가 아니라 '토큰 추가 제안'이었다.

"클라이언트가 '더 화려하게'를 요구하는데 근거가 없다." 두 모드 원칙을 적용한다: 상대가 이해관계자면 빠르게 수용해 키우되(협업 모드), 그 결과를 확정 스펙으로 기록해 다음 번복의 기준점을 만든다. 내가 제안자 입장이면 "어느 지점이 밋밋한가"를 되물어 체감 지점을 특정한다 — 전면 재작업과 국소 강조는 비용이 10배 다르다.

"이 원칙들과 조직의 새 디자인 시스템이 충돌한다." 원칙의 우선순위를 기억할 것: 이 스킬은 '개인 실무 문법'과 '시스템 정렬'을 애초에 분리해 둔 체계다. 조직 시스템이 있는 지면에서는 그 시스템이 이긴다 — 이 스킬이 지는 게 아니라, "시스템 지면에선 표준에 정렬한다"는 이 스킬의 원칙이 이기는 것이다.

출처와 반례 처리

이 스킬은 확정본의 컴파일이지 원본이 아니다. 원칙별 증거·검증 로그·기각 이력은 저자의 비공개 결정 로그에 보존되어 있으며, 핵심 수치(duration 51,271건 · 베지어 61,422건 · 시그니처 커브 11,235회 등)는 이 문서에 내재화했다. 이 스킬을 자신의 환경에 맞게 쓰다가 반례를 발견하면 — 스킬을 바로 고치지 말고, 자신의 결정 로그에 반례를 먼저 기록한 뒤 원칙의 이유가 여전히 성립하는지 검증하고 고칠 것.