버튼의 일은 딱 하나다: 눌렀으면 실행돼야 함

• 버튼의 일은 단순함. 눌렸으면 동작해야 함.

  • 글쓴이는 아이폰과 Nothing Phone에서 사진 회전 버튼을 빠르게 8번 눌러봄.
  • 90도 회전을 8번 하면 두 바퀴를 돌아 결국 원래 방향으로 돌아오는 ‘아무 변화 없음(no-op)’ 상태가 되어야 함.

• 아이폰은 사용자의 빠른 탭을 기억해두고 순서대로 처리함.

  • 첫 번째 회전 애니메이션이 도는 중에 두 번째 탭이 들어와도 버리지 않음.
  • 애니메이션이 끝나면 대기 중이던 다음 회전이 이어짐.
  • 결과적으로 사용자는 “내가 누른 만큼 처리됐다”는 확신을 얻음.

• 반대로 Nothing Phone 쪽 동작은 꽤 짜침. 탭 피드백은 주는데, 실제 회전은 무시될 수 있음.

  • 햅틱과 사운드로는 “눌렸다”는 확인을 줌.
  • 그런데 이전 회전 애니메이션이 아직 끝나지 않았으면 그 탭은 그냥 사라짐.
  • 사용자 입장에서는 버튼이 반응한 것처럼 느껴졌는데 결과는 안 바뀌는 이상한 상태가 됨.

• 이게 단순한 “사진 회전 버튼 버그”로 끝나지 않는 이유는, 캐주얼한 기능도 어느 순간 빡센 작업 도구가 되기 때문임.

  • 스마트폰 카메라는 보통 사진 방향을 잘 맞추지만, 아래쪽을 찍거나 문서를 찍을 때는 방향을 헷갈릴 수 있음.
  • 예를 들어 가로 문서를 여러 장 찍었다면, 사용자는 사진 수십 장을 하나씩 돌려야 할 수 있음.
  • 그때 버튼을 세 번씩 빠르게 누르면 알아서 처리되는 UI와, 애니메이션 끝날 때까지 기다려야 하는 UI의 피로도 차이는 꽤 큼.

• 글쓴이는 이걸 접근성의 ‘상황적 장애(situational disability)’와 비슷하게 봄.

  • 접근성은 특정 사용자만을 위한 별도 기능이 아니라, 누구나 특정 상황에서 필요해질 수 있는 기본 품질이라는 관점임.
  • 마찬가지로 ‘파워유저’도 특정 직업군만의 얘기가 아님.
  • 충분히 많은 사용자와 충분히 긴 사용 시간을 놓고 보면, 평범한 기능도 언젠가는 반복 작업 도구처럼 쓰이게 됨.

• 그래서 저자가 제안하는 규칙은 꽤 명확함. 애니메이션 때문에 사용자를 기다리게 하지 말라는 것.

  • 꼭 입력 버퍼링만 정답은 아님.
  • 새 탭이 들어오면 현재 애니메이션을 중단하거나 빠르게 끝내는 방식도 가능함.
  • 중요한 건 사용자가 원하는 속도보다 UI 장식이 우선하면 안 된다는 점임.

---

기술 맥락

• 이 글의 핵심 선택지는 입력을 버퍼에 쌓을지, 아니면 진행 중인 애니메이션을 끊고 새 상태로 넘어갈지예요. 둘 다 목표는 같아요. 사용자가 이미 의도를 표현했는데, UI가 “잠깐만요” 하면서 그 입력을 없던 일로 만들지 않게 하는 거예요.

• 사진 회전 같은 기능은 상태가 단순해서 더 티가 나요. 90도씩 네 번 돌면 원위치라는 규칙이 명확하거든요. 그래서 빠른 탭 8번이 최종적으로 원래 방향으로 돌아오지 않으면, 사용자는 즉시 “내 입력이 씹혔다”고 느껴요.

• 애니메이션은 상태 변화를 이해시키려고 넣는 장치예요. 그런데 반복 작업 상황에서는 같은 애니메이션이 오히려 입력 처리량을 막는 병목이 돼요. 이때는 애니메이션 완주보다 입력의 신뢰성이 더 중요해져요.

• 프론트엔드에서 이런 문제를 줄이려면 버튼 클릭 핸들러, 상태 큐, 애니메이션 완료 콜백이 서로 어떤 우선순위를 갖는지 분명해야 해요. 특히 모바일처럼 햅틱이나 사운드 피드백까지 붙는 UI에서는 “피드백을 줬다”는 사실 자체가 사용자와의 약속이 되거든요.