마이크로인터랙션이 UI의 절반을 결정한다

버튼을 누른다. 그러면 0.1초 안에 색이 살짝 어두워지거나, 화면이 살짝 가라앉거나, 손끝에 작은 진동이 닿는다. 이 0.1초를 우리는 거의 의식하지 않는다. 그런데 이 0.1초가 모여서, 어떤 앱은 잘 만든다는 인상, 어떤 앱은 그냥 동작한다는 인상을 받는다.

잘 만든 결제 버튼을 눌러본 적이 있는가. 누르는 순간 버튼이 살짝 가라앉고, 결제 중에는 작은 진행 표시가 흐름을 따라 움직인다. 완료되면 체크 마크가 한 박자 늦게 그려지며 자리에 앉는다. 이걸 의식적으로 알아차린 사람은 거의 없을 거다. 그런데 이 모션이 빠진 결제 화면을 머릿속에 떠올려보라. 아무리 색이 깔끔해도, 아무리 폰트가 예뻐도, 어딘가 차갑게 느껴질 거다.

이걸 디테일이라고 부르긴 어렵다. 디테일이 아니라, 언어다. 사용자는 명시적으로 의식하지 못한다. 그런데 이 작은 동작들이 모여서 제품이 어떻게 느껴지는지를 절반쯤 결정한다. 업계에서는 이걸 마이크로인터랙션(microinteraction)이라고 부른다.

디자이너로서 화면을 보면, 늘 두 가지가 동시에 보인다. 큰 그림, 정보 구조, 타이포그래피, 그리드. 그리고 작은 그림, 버튼이 눌리는 방식, 로딩이 끝나는 방식, 빈 화면이 채워지는 방식. 큰 그림은 예쁘다는 인상을 만들고, 작은 그림은 손에 익는다는 인상을 만든다. 작은 그림이 제대로 갖춰지지 않으면 큰 그림이 아무리 좋아도 어긋난다. 이 글은 그 작은 그림에 대한 글이다.

구체적으로는 마이크로인터랙션이 왜 중요한지, 어떤 기준으로 좋은 모션과 나쁜 모션을 가르는지, Apple과 Google이 어떤 가이드를 가지고 있는지를 다뤄보려 한다. 그리고 마지막에는, 작은 회사에서 이걸 어떻게 시작할 수 있는지도 같이 다루고 싶다.

1. 마이크로인터랙션이란 무엇인가: Saffer의 4구성 모델

좋은 모션과 나쁜 모션을 가리려면 기준이 필요하다. 인터랙션 디자이너 Dan Saffer는 마이크로인터랙션을 Trigger, Rules, Feedback, Loops & Modes라는 네 가지 구성 요소로 분해하는 모델을 제안했다. 이 프레임은 마이크로인터랙션을 설계하고 진단할 때 같은 언어로 이야기할 수 있게 해준다.

Trigger: 누가, 무엇을, 어떻게 시작하는가

마이크로인터랙션은 누군가의 작은 동작에서 시작된다. Saffer는 이 시작점을 트리거(trigger)라고 부른다. 트리거는 누가 일으켰느냐에 따라 둘로 나뉜다. 사용자가 직접 일으키는 경우(버튼 누름, 스와이프, 음성 명령)와 시스템이 먼저 시작하는 경우(푸시 알림, 자동 동기화, 시간 기반 동작)다. 전자에서는 의도가 이미 있으니 짧고 확실하게 끝나야 하고, 후자에서는 주의를 끌어 일으켜야 하므로 모션과 사운드가 더 적극적으로 들어간다.

Rules: 무슨 일이 일어나는가

Rules는 트리거 이후 어떤 일이 일어나는지를 결정한다. 결제 버튼을 눌렀다면 어떤 결제 수단을 보여줄지, 자동 저장이라면 어떤 주기로 저장할지, 모두 Rules의 영역이다. 사용자는 Rules를 거의 의식하지 못한다. 그런데 Rules가 모호하면 인터랙션이 일관성을 잃는다. 같은 버튼을 눌렀는데 화면마다 다른 결과가 나온다면, 사용자는 그 앱을 신뢰하기 어렵다.

Feedback: 사용자가 어떻게 알아채는가

Feedback은 인터랙션의 얼굴이다. 트리거가 발동되었고 Rules가 돌아가고 있다는 신호를 사용자에게 돌려주는 모든 수단이 여기에 속한다. 화면의 작은 변화, 소리, 진동, 색의 미세한 전환, 진행을 알리는 모션이 전부 Feedback이다. 가장 잘 만든 Feedback은 의식하지 못해도 결과가 자연스럽게 전달되는 것이고, 가장 나쁜 Feedback은 정작 중요한 순간에 비어 있는 것이다. 도입부에서 살펴본 결제 버튼의 체크 마크 한 박자 늦게 그려지는 모션도 Feedback의 한 형태다.

Loops & Modes: 반복과 맥락

Loops & Modes는 단발성 인터랙션 너머의 영역이다. Loops는 같은 마이크로인터랙션이 반복되는 방식을 다루고, Modes는 같은 인터랙션이 다른 맥락(시간대, 사용자 상태, 화면 크기)에서 다르게 동작하는 경우를 다룬다. 알림이 같은 패턴으로 반복해서 도착하는 흐름, 사용자가 인터랙션을 잠시 멈췄다가 다시 시작할 때 상태가 매끄럽게 이어지는 흐름까지 모두 여기 속한다. 이 둘을 잘 설계하면 마이크로인터랙션은 단발 이벤트가 아니라 제품의 톤을 지속적으로 만든다.

2. 좋은 모션 vs 나쁜 모션: 기준은 어디에 있는가

4구성 모델은 마이크로인터랙션을 분해하는 도구이지, 좋은 모션과 나쁜 모션을 가르는 기준은 아니다. 같은 트리거, 비슷한 Rules, 같은 형태의 Feedback이라도 결과는 완전히 다를 수 있다. 결국 모션이 왜 필요한지, 얼마나 빨리 진행되는지, 어디서 멈추는지에 대한 기준이 있어야 한다. 기준 없이 만들어진 모션은 디자이너의 취향에 따라 들쭉날쭉해진다.

이 기준을 조금씩 다른 각도에서 정리하면 세 가지로 묶인다. 모션이 사용자의 의도와 맞는지, 시스템 안에서 일관되게 작동하는지, 그리고 그 모션이 빠졌을 때 무엇이 망가지는지. 다음 세 단락은 이 세 가지 원칙을 차례로 풀어본다. 그다음 장에서는 이 원칙을 실제 가이드들이 자기 언어로 어떻게 풀어내는지 같이 본다.

해외 운영체제 가이드: 의도가 먼저, 모션은 그 다음

이 가이드는 모션의 정당성을 가장 분명하게 요구한다. 모션은 화면을 화려하게 만드는 도구가 아니라, 사용자의 의도와 시스템 상태 사이의 간극을 메우는 도구다. 의미 없는 모션은 보여주지 말고, 모션이 꼭 필요한 경우에만 추가하라는 원칙을 담고 있다. 같은 화면이라도 의도가 다르면 같은 모션을 쓰지 않는다. 모션은 사용자가 무엇을 해야 하는지, 무엇이 일어났는지, 어디로 향하는지를 끊김 없이 설명할 때만 살아난다. 이 원칙의 핵심은 단순하다. 장식이 아니라 의도가 먼저고, 모션은 그 다음이다.

다른 운영체제 가이드: 모션이 디자인 토큰이 된 변화

모바일 운영체제의 디자인 시스템은 모션을 색이나 타이포처럼 다룬다. 단순 가이드가 아니라, 화면이 전환되는 속도, 요소가 등장하는 거리, 감속 곡선까지 이름 붙인 값으로 정의한다. 같은 종류의 화면이라면 같은 모션 값을 따라가도록 강제하기 때문에, 디자이너와 개발자 사이의 모호함이 줄어든다. 이 접근의 핵심은 일관성이다. 디자이너가 일일이 손으로 조율하지 않아도, 시스템이 같은 룰을 반복해서 적용한다. 결과적으로 사용자는 앱 안에서 일관된 박자의 모션을 만나게 된다. 모션이 디자인 토큰이 된 시대의 의미가 여기에 있다.

결제 서비스 디자인 원칙: 애니메이션을 빼면 경험이 불완전해진다

결제 흐름을 오래 다듬어온 디자인 팀은 한 단계 더 나아간다. 단순히 의도 적합성만 따지지 않고, 모션이 빠졌을 때 무엇이 망가지는지를 기준으로 삼는다. 결제 버튼의 누름 피드백이 없으면 사용자는 클릭이 먹었는지 확인하려 두 번 누른다. 로딩 표시가 없으면 진행 중인지 멈춘 건지 구분하지 못한다. 완료 신호가 없으면 다음 단계로 넘어가야 할지 망설인다. 이 모두가 모션이 빠진 자리에서 발생하는 실패다. 결국 어떤 모션을 넣느냐가 아니라, 어떤 신뢰를 지킬 수 있느냐가 기준이 된다. 모션이 빠진 자리는 곧 신뢰가 빠진 자리다.

3. 글로벌 표준을 어떻게 읽는가: 해외 인터랙션 가이드 비교

이 장에서는 앞 절에서 정리한 세 가지 원칙을 실제 가이드들이 자기 언어로 어떻게 풀어내는지 본다. 비교 대상으로는 Apple의 Human Interface Guidelines, Google의 Material 3, 그리고 결제 도메인을 오래 다듬어 온 Stripe의 디자인 원칙을 함께 본다. 세 가이드를 같은 격자, 즉 의도와 일관성과 비용이라는 세 축으로 읽으면 어디서 같은 결론에 도달하고 어디서 다른 결론을 내리는지 드러난다. 같은 결론에 다른 무게를 두기 때문에, 같은 화면이라도 어떤 가이드 톤으로 만들지가 결과물을 결정한다.

Apple HIG: 의도가 먼저, 모션은 그 다음

Apple의 Human Interface Guidelines는 모션 챕터의 첫 머리에 “Add motion purposefully"라는 원칙을 내건다. 모션은 사용자가 무엇을 해야 하는지, 무엇이 일어났는지, 어디로 향하는지를 설명하는 도구이며, 그 자체가 목적이 되면 안 된다는 뜻이다. HIG는 권장 곡선으로 ease-in-out을, 권장 길이로 대략 200~500밀리초(ms) 범위를 제시한다. 숫자가 중요한 게 아니라, 그 범위 안에서 모션이 사용자의 인식과 비슷한 박자로 흘러야 한다는 점이 중요하다.

HIG가 다른 가이드와 다른 점은, 모션을 디자인 토큰(token)처럼 강제하기보다 상황별 의도를 먼저 정의하고 거기서 자연스럽게 도출되는 모션을 권장한다는 데 있다. 모달이 화면 안으로 들어올 때, 알림이 위에서 내려올 때, 사용자가 화면을 닫을 때 — 각각의 상황이 의도를 갖고 있고, 그 의도에 어울리는 모션이 따로 있다. 디자이너는 토큰을 골라 쓰는 게 아니라, 상황을 해석한 다음 모션을 선택해야 한다.

대표적인 예로 모달 present/dismiss 모션이 있다. 모달은 화면 위로 올라오면서 사용자의 시선을 자연스럽게 그쪽으로 끌어당기고, 닫을 때는 다시 아래로 가라앉으며 원래 화면으로 시선을 돌려놓는다. 이 흐름이 끊기면 사용자는 자기 단계가 어딘지 잃는다. HIG는 이런 끊김을 모션으로 메우라고 권한다.

Material 3: 모션이 디자인 토큰이 된 변화

Google의 Material 3는 모션을 디자인 토큰으로 다룬다. 색이나 타이포그래피처럼, 모션도 이름 붙인 값으로 정의된다. duration(지속 시간) 토큰은 short1부터 long4까지 짧은 시간부터 긴 시간까지 이름 붙인 값들이고, easing(감속 곡선) 토큰은 standard, emphasized, decelerated, accelerated 같은 이름으로 묶여 있다. 화면 전환 패턴도 네 가지로 나뉘는데, container transform은 리스트 항목이 디테일 화면으로 자연스럽게 이어지는 전환을, shared axis는 탭과 같이 계층이 같은 화면 사이의 이동을, fade through는 관련이 없는 화면 사이의 전환을, fade는 모달처럼 짧게 사라지고 나타나는 전환을 맡는다.

Material이 다른 가이드와 다른 점은, 모션을 시스템 차원에서 강제한다는 데 있다. 같은 종류의 화면 전환이라면 어디서 만들었든 같은 모션 값이 따라간다. 디자이너가 매번 손으로 감속 곡선을 조율하지 않아도, 시스템이 같은 박자를 자동으로 적용한다. 디자인 핸드오프 단계에서 모션이 모호해질 일이 거의 없다. 디자이너가 명세한 토큰이 그대로 코드로 흘러들어가기 때문이다.

다만 이 강력함에는 대가도 따른다. 토큰이 정의한 범위 밖의 모션을 시도하기 어렵고, 그래서 브랜드만의 독특한 박자를 만들려면 토큰을 의도적으로 깨야 한다. 많은 서비스가 Material 3를 기반으로 출발하면서도, 시간이 지나면 자기만의 easing 곡선과 duration을 덧입히는 이유가 여기에 있다.

Stripe: 애니메이션을 빼면 경험이 불완전해지는 순간

결제 흐름을 오래 다듬어온 Stripe는 한 단계 더 나아간다. 단순히 의도 적합성과 시스템 일관성만 따지지 않고, 모션이 빠지면 사용자가 어떤 행동을 잘못하게 되는지를 명시적으로 계산한다. 모션이 빠진 자리에서 발생하는 비용을 줄이는 도구로 모션을 보는 셈이다.

대표적인 사례가 결제 버튼의 누름 피드백이다. 누르는 순간 색이 살짝 어두워지거나 가라앉는 모션이 없으면, 사용자는 클릭이 먹었는지 확인하려 같은 자리를 한 번 더 누른다. 같은 결제가 두 번 진행되거나, 결제 흐름이 꼬일 위험이 그만큼 커진다. 로딩 표시도 마찬가지다. 결제가 얼마나 남았는지 모르면 사용자는 멈춘 건지 진행 중인지 구분하지 못하고, 이탈한다. 완료 신호도 빠질 수 없다. 결제 funnel leak는 대부분 작은 확인의 부재에서 시작된다.

Stripe Dashboard와 Checkout에서 자주 보이는 패턴을 보면, 폼 입력 중에는 inline validation이 실시간으로 들어와 잘못된 입력을 그 자리에서 짚어주고, 결제 완료 시에는 작은 체크 모션이 한 박자 늦게 그려지면서 끝났다는 신호를 부드럽게 전달한다. 에러 상황에서는 무서운 빨간 경고보다, 상황을 설명하는 짧은 문구와 함께 retry 버튼이 자연스럽게 강조되는 흐름을 만든다. 신뢰를 잃지 않으면서 다음 행동을 부드럽게 끌어당기는 균형이다.

Stripe의 원칙을 짧게 요약하면 이렇다. 결제 흐름에서 모션이 하는 일은 신뢰 비용을 줄이는 일이다. 잘 만든 모션은 그 자리에서 사용자가 잘못한 행동을 막고, 결제 흐름이 끊기는 순간을 메운다.

4. 잘 작동한 사례들: 스크린샷으로 배우는 마이크로인터랙션

표준 가이드가 원리를 말해준다면, 실제 사례는 그 원리가 어떻게 작동하는지 보여준다. 결제, 좋아요 같은 작은 액션, 데이터가 비어 있을 때, 그리고 자료를 직접 찾아보는 법까지. 자주 마주치는 네 가지 상황과, 그 안에서 모션이 어떤 일을 하는지를 차례로 본다.

결제 UX: 흐름이 끊기지 않는 결제 화면

좋은 결제 화면은 사용자가 어디서 끊겼는지 모르게 흐름을 이어간다. 카드를 입력하는 동안 어떤 단계에 있는지, 결제 중에는 얼마나 남았는지, 완료 후에는 다음에 무엇을 할 수 있는지 끊김 없이 보여준다. 한 번도 의식하지 못해도 결과가 자연스럽게 전달되는 Feedback이 잘 작동하는 자리다.

결제 수단 선택에서 카드 정보 입력, 인증 단계로 넘어갈 때 화면이 가로로 흐르며 다음 단계로 이동 중임을 부드럽게 표현하는 경우가 많다. 새로고침해도 같은 위치로 돌아오는 진행률 표시가 따라붙고, 결제 실패 시에는 메시지의 무게를 살짝 가라앉는 모션으로 표현한 다음 retry 버튼이 자연스럽게 강조되는 흐름이 만들어진다. 실패를 무겁게만 다루면 사용자는 그 화면을 떠난다. 너무 가볍게 다루면 같은 실수를 반복한다. 그 사이의 균형을 모션이 잡아준다.

좋아요 / 저장 / 공유: 작은 액션이 큰 의미를 만드는 방식

좋아요 버튼을 누르는 순간, 단순히 색이 바뀌고 카운트가 1 올라가는 것을 동시에 본다. 작은 폭발 파티클이 한순간 터지거나, 하트가 살짝 부풀었다가 가라앉는 모션이 따라붙는다. 단순한 토글 이상의 의미가 전달되는 자리다. 누른 사용자에게는 방금 이 콘텐츠에 반응했다는 작은 확인이 남고, 보는 사람에게는 누군가 이미 반응했다는 사회적 신호가 된다.

다만 이런 모션은 0.2초 안에 끝나야 한다. 길면 거슬리고, 짧으면 인지조차 못한다. 작은 액션이 큰 의미를 갖는 조건은, 그 의미가 사용자에게 남는 짧은 시간 안에 전달되는 것이다. 너무 오래 끌면 그저 시끄러운 장식이 된다.

빈 상태 / 로딩 / 에러: 데이터가 없을 때 인터랙션의 시험대

사용자가 처음으로 앱에 들어왔을 때 마주하는 화면이 빈 상태, 즉 empty state다. 이때 아직 기록이 없어요 같은 짧은 문구와 작은 일러스트, 그리고 첫 항목을 만들어보세요 같은 행동 유도가 함께 따라붙는다. 빈 상태에서 인터랙션이 빈약하면, 사용자는 그 앱이 준비되지 않았다고 느낀다.

로딩 상태는 데이터 양과 사용자가 기다릴 만한 시간에 따라 모양이 달라진다. 짧게 끝나는 작업에는 작은 스피너, 길어질 수 있는 작업에는 진행 막대, 콘텐츠가 들어올 자리가 명확한 경우(뉴스 피드, 프로필 카드)에는 skeleton UI가 자주 쓰인다. 콘텐츠 피드를 가진 여러 서비스에서 흔히 보이는 skeleton UI는 콘텐츠의 자리를 미리 보여주기 때문에 로딩이 짧게 느껴진다. 빈 화면 위에 그냥 스피너만 띄우는 것보다 훨씬 자연스럽다.

에러 상태도 비슷하다. 무서운 빨간 X보다는, 상황을 설명하는 짧은 문구와 함께 다음에 무엇을 할 수 있는지 안내하는 흐름이 더 잘 작동한다. 사용자가 잘못을 탓하기보다, 다음 행동을 자연스럽게 떠올리도록 만들어야 한다. 비어 있거나 막혔거나 잘못된 자리에서, 인터랙션이 얼마나 친절하게 다음을 안내하느냐가 제품 전체의 인품을 결정한다.

참고 소스: 사례를 직접 찾아보는 법

사례는 직접 모아야 자란다. Mobbin은 iOS와 Android 앱의 UI 패턴을 스크린샷으로 정리해 둔 라이브러리로, 비슷한 카테고리(결제, 좋아요, 빈 상태 등)의 화면을 한자리에서 비교해 볼 수 있다. Little Big Details는 더 작은 디테일을 매일 한두 개씩 짧게 큐레이션하는 곳으로, 큰 화면이 아니라 한 모션의 결을 따라가 보고 싶을 때 자주 들른다. Prototypr과 Smashing Magazine의 UX 코너는 사례와 함께 그 사례가 어떤 결을 따라 만들어졌는지 짧은 글로 풀어낸다.

직접 모으는 습관도 함께 추천한다. 비슷한 카테고리의 사례를 한 폴더에 모아두고, 정기적으로 돌아보며 왜 이게 잘 작동하는가를 한두 줄로 적어두는 것이다. 사례가 모이면 자기 안에서 작은 패턴이 보인다. 그 패턴이 쌓이면 다음에 무언가를 만들 때, 이건 어디서 본 결이라는 감각이 먼저 작동한다.

5. 어떻게 만드는가: 디자이너가 인터랙션을 정의하는 법

표준을 읽는 것만으로 끝나지 않는다. 그 표준을 자기 화면에 어떻게 적용할지 결정하는 것은 결국 디자이너의 몫이다. 작은 회사에서 마이크로인터랙션을 어떻게 시작하면 좋을지, 세 가지 각도에서 정리한다. 사내 라이브러리, 핸드오프 명세, 그리고 디자이너가 직접 인터랙션 시안을 만드는 도구.

사내 인터랙션 라이브러리의 필요성

디자이너가 매번 새로 모션을 만들면 안 된다. 같은 결제 버튼을 화면마다 다르게 정의하고, 같은 토글 모션을 디자이너마다 다르게 조율하면, 앱 안의 모션이 들쭉날쭉해진다. 기준 없는 모션은 취향의 결과물이 된다.

해법은 사내 인터랙션 라이브러리다. 자주 쓰는 인터랙션 패턴, 즉 버튼 누름, 로딩 표시, 토글, 모달 present, 페이지 전환 같은 동작들을 한곳에 정리해 두고, 새로운 화면을 만들 때 거기서 골라 쓰는 식이다. 새 디자이너가 합류했을 때 빠르게 같은 톤을 익힐 수 있고, 기존 화면을 수정할 때 어떤 모션이 적합한지 빠르게 참조할 수 있다. 라이브러리는 처음부터 완벽할 필요가 없다. 자주 쓰는 패턴 다섯 개만 먼저 정리해도 충분하다.

라이브러리를 만들 때 함께 적어둘 항목은 이렇다. 패턴 이름, 어떤 상황에서 쓰이는지, 권장 duration과 easing, 그리고 짧은 참고 영상이나 시안 링크. 이 네 가지가 함께 적혀 있으면, 다음에 비슷한 화면을 만들 때 어떤 모션이 적합한가를 다시 고민하지 않아도 된다.

디자인 핸드오프 단계에서 모션을 어떻게 명세화하는가

정적인 시안만으로는 모션이 어떻게 흐르는지 전달이 어렵다. 짧은 영상, 짧은 설명, 그리고 명세 항목 몇 개가 함께 따라붙어야 한다. 핸드오프 문서에서 모션 명세에 포함할 항목은 이렇다. 어떤 trigger로 시작되는지, 어떤 일이 일어나는지, duration은 어느 정도인지, easing은 어떤 곡선인지, 그리고 왜 이 모션이 필요한가를 한 줄로.

정적 시안 도구의 자동 전환 기능은 화면 사이의 기본 전환은 어느 정도 보여주지만, 정교한 모션까지는 담아내지 못한다. 더 복잡한 모션이 필요할 때는 짧은 영상을 만들어 첨부하거나, Rive 같은 도구로 디자이너가 직접 인터랙션 시안을 만드는 편이 낫다. 어느 쪽이든, 디자이너가 의도한 모션이 영상으로 남아 있어야 개발자가 그대로 옮길 수 있다.

모션을 길게 명세하기보다, 짧은 영상 한 편과 짧은 설명 한두 줄이 더 효과적인 경우가 많다. 개발자는 영상을 보면서 같은 결을 따라 구현하고, 그 과정에서 디자이너에게 확인이 필요한 부분만 짧게 묻는다. 긴 명세는 읽지 않는다. 짧은 영상은 본다.

Rive로 직접 시안 만들기

Rive는 디자이너가 인터랙션 시안을 직접 만들 수 있는 도구다. 다른 정적 시안 도구의 prototype보다 정교한 모션이 가능하고, 동시에 코드를 짜지 않아도 인터랙션의 핵심을 시연할 수 있다. 결과물을 Lottie 형식의 JSON으로 export하면, 개발자는 그대로 가져다 쓸 수 있다.

작은 회사에서 Rive를 도입하면, 디자이너와 개발자 사이의 모션 핸드오프 비용이 눈에 띄게 줄어든다. 디자이너가 Rive에서 인터랙션을 만들고 export한 JSON을 개발자에게 넘기면, 개발자는 그 결을 그대로 따라간다. 명세와 구현이 맞물리는 왕복이 짧아지고, 의도한 모습이 맞는지 확인하는 메일도 줄어든다.

다만 모든 모션을 Rive로 만들 필요는 없다. 사내 라이브러리에 정리된 표준 패턴은 정적 시안 도구의 자동 전환 기능으로도 충분하다. Rive는 사내 라이브러리에 없는 새로운 모션을 시안으로 만들거나, 결제 같은 복잡한 흐름을 정교하게 시연할 때 쓰는 편이 낫다. 도구는 패턴의 복잡도에 따라 골라 쓰는 것이 효율적이다.

6. 마무리: UI의 절반을 다시 정의한다

도입부에서 살펴본 결제 버튼의 모션을 다시 떠올려 보자. 누르는 순간 살짝 가라앉고, 결제 중에는 작은 진행 표시가 흐름을 따라 움직이고, 완료되면 체크 마크가 한 박자 늦게 그려지며 자리에 앉는다. 이 작은 동작들이 모여서 어떤 앱은 잘 만든다는 인상, 어떤 앱은 그냥 동작한다는 인상을 받는다. 이 글은 그 작은 동작을 어떻게 설계하고 어떻게 읽는지 함께 살펴본 글이다.

글 도입으로 다시 돌아가서

Saffer의 4구성 모델로 마이크로인터랙션을 분해하는 법을 먼저 정리하고, 그다음에는 좋은 모션과 나쁜 모션을 가르는 세 가지 원칙, 즉 의도와 일관성과 비용이라는 축을 살펴봤다. 그 원칙을 Apple HIG, Material 3, Stripe가 자기 언어로 어떻게 풀어내는지를 같은 격자로 읽었고, 실제 사례들에서 그 원칙이 어떻게 작동하는지를 결제, 좋아요, 빈 상태, 로딩, 에러 흐름에서 함께 봤다. 마지막에는 작은 회사에서 이걸 어떻게 시작할 수 있는지, 사내 인터랙션 라이브러리와 핸드오프 명세, 그리고 Rive 같은 도구로 디자이너가 직접 인터랙션을 만드는 법까지 정리했다.

디자이너의 책임에 대해

표준을 안다고 끝이 아니다. 그 표준을 자기 화면에 어떻게 적용할지 결정하는 것은 결국 디자이너의 몫이다. 마이크로인터랙션은 장식이 아니라 제품의 신뢰 비용을 줄이는 도구다. 그리고 그 도구를 다루는 손은 세 축, 사용자의 의도에 맞는지, 시스템 안에서 일관되게 작동하는지, 그리고 빠졌을 때 무엇이 망가지는지를 함께 보는 손이다. 잘 만든 모션은 그 자리에서 사용자가 잘못한 행동을 막고, 흐름이 끊기는 순간을 메운다. 다음에 무언가를 만들 때, 그 화면의 0.1초 모션을 한 번 의식적으로 살펴보라. 거기서 시작된다.

다음에 다룰 주제

이 글에서는 인터랙션의 시각적 측면에 집중했다. 다음 글에서는 그 옆에 있는 두 가지, 즉 햅틱(haptics)과 사운드 디자인이 인터랙션을 어떻게 보완하는지를 함께 다루려 한다. 작은 진동과 짧은 효과음이 시각적 모션과 어떻게 어울려야 사용자가 방금 무슨 일이 일어났다는 신호를 여러 감각으로 동시에 받아들일 수 있는지. 그 신호의 결을 따라가 볼 생각이다.