# 버튼이라면 할 일은 하나뿐 > Clean Markdown view of GeekNews topic #31157. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31157](https://news.hada.io/topic?id=31157) - GeekNews Markdown: [https://news.hada.io/topic/31157.md](https://news.hada.io/topic/31157.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-06T09:02:51+09:00 - Updated: 2026-07-06T09:02:51+09:00 - Original source: [unsung.aresluna.org](https://unsung.aresluna.org/if-youre-a-button-you-have-one-job/) - Points: 5 - Comments: 2 ## Topic Body - 사진 회전처럼 단순한 버튼도 **빠른 반복 입력**을 어떻게 처리하느냐에 따라 사용자 경험이 크게 달라짐 - iPhone은 여러 번 누른 **90도 회전** 입력을 기억해 애니메이션이 끝나는 대로 다음 회전을 이어서 실행함 - Nothing Phone/Android는 햅틱과 소리로 탭을 확인해 주지만, 회전 애니메이션 중 들어온 **후속 탭은 무시**함 - 문서 사진을 여러 장 돌려야 하는 상황에서는 캐주얼한 사진 편집 UI도 더 빠르고 예측 가능한 조작을 요구받음 - 버튼은 사용자를 애니메이션 종료까지 기다리게 하기보다, 탭 버퍼링이나 애니메이션 중단·가속으로 입력을 받아야 함 --- ### 사진 회전 버튼이 반복 입력을 처리하는 방식 - 사진 회전 버튼은 한 번 누르면 보통 **반시계 방향 90도 회전**하고, 다시 누르면 같은 동작을 반복하는 표준적인 컨트롤임 - 회전 애니메이션은 사진 방향이 바뀌는 과정을 보여줘 사용자가 방향 감각을 잃지 않도록 도와줌 - 빠르게 90도 회전을 **8번** 누르면 엔지니어가 말하는 “no op”처럼 이미지가 두 바퀴 돌고 원래 방향으로 돌아와야 함 - iPhone에서는 이 기대가 실제로 맞아떨어짐 - 빠른 탭 입력을 기억함 - 이전 회전이 끝나면 대기 중인 다음 회전을 실행함 - Nothing Phone/Android에서는 다른 결과가 나옴 - 버튼은 햅틱과 소리로 탭 확인을 제공함 - 이전 회전 애니메이션이 끝나지 않았으면 새 탭을 무시함 ### 캐주얼 UI도 반복 작업에서는 더 강한 입력 처리가 필요함 - [상황적 장애](https://accessibility.education.gov.uk/training/accessibility-inclusion/page-10)는 장애가 일부 사람에게만 생기는 것이 아니라, 누구나 특정 상황에서 효과적으로 장애를 겪을 수 있다는 개념임 - 사진 촬영은 대체로 캐주얼한 사용에 가깝지만, 휴대폰 카메라는 아래쪽을 향해 찍을 때 사진 방향을 혼동할 수 있음 - 여러 장의 가로 문서 사진을 찍은 뒤 각각 회전해야 한다면, 사용자는 사진을 하나씩 **수십 장** 돌려야 할 수 있음 - 이런 상황에서는 버튼을 원하는 속도로 세 번 눌러도 예측 가능하게 동작하는 편이 더 즐겁고 덜 번거로움 - 충분히 긴 시간이나 큰 사용자 집단을 놓고 보면, 캐주얼 인터페이스도 더 진지하게 다뤄야 하는 순간을 만남 - 이런 “상황적 파워 유저성”은 휴대폰 사진 편집이나 [GarageBand](https://unsung.aresluna.org/the-surprising-richness-of-garageband/) 같은 사례에서도 나타남 - 해결책이 반드시 탭 버퍼링일 필요는 없음 - 인터럽트성 탭이 들어오면 애니메이션을 멈추거나 가속할 수도 있음 - 핵심은 **사용자가 애니메이션 종료를 기다리도록 강제하지 않는 것**임 ## Comments ### Comment 61305 - Author: neo - Created: 2026-07-06T09:36:21+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48790689) - 사용자가 실수로 너무 많이 클릭하거나, 첫 클릭이 등록되지 않았다고 믿는 경우는 어떻게 해야 할까? Steve Jobs가 새 macOS에서 PDF 문서 표시가 얼마나 빨라졌는지 시연하던 키노트가 아직도 떠오름. 엔지니어들이 PDF를 화면에서 스크롤하는 버튼을 만들어뒀는데, Jobs가 실수로 한 번 넘게 눌렀고 “두 번 끝까지 스크롤하려나?” 하고 말했더니 실제로 **동작이 버퍼링**됨. 결국 위로 다시 올라가 두 번째 스크롤이 끝날 때까지 기다려야 했음 Jobs는 “두 번째로 문서를 훑는 시간까지 포함해도 이전 OS의 PDF보다 빠르다”고 말하며 수습함 - **디바운싱**은 이유가 있어서 존재함. 버튼을 두 번 눌렀을 때 두 번 실행해야 할 때도 있고, 그러면 안 되는 때도 있음. 어느 상황에서 어느 쪽이 나은지 구분하는 건 간단하지 않음 최소한 어떤 상황에 어떤 처리가 맞는지 고민해야 함. UI 안에서 어떤 버튼은 한쪽이 명백하고, 다른 버튼은 반대가 명백하지만, 일부는 애매해서 두 동작 모두 방어 가능하다면 결국 **일관성 없는 UI**가 됨 좋은 해결책은 잘 모르겠음 - 글에 따르면: > The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap if a previous rotation is still animating. 이게 문제임. 앱이 버튼 입력이 등록됐다고 식별해 준 횟수와 실제 수행된 동작 수는 같아야 함. **디바운싱**은 좋은 관행이지만, 쓰려면 디바운싱된 탭에는 **피드백**을 내면 안 됨 - “사용자가 실수로 너무 많이 클릭하거나, 첫 클릭이 등록되지 않았다고 믿는 경우는?”이라는 부분에서 접근성 얘기가 나와서 꽤 혼란스러웠음. 바로 손 떨림이 있는 사람이 한 번만 누르려다 **두 번 누르는 경우**가 떠올랐기 때문임 그리고 모든 버튼을 더블클릭하는 사람들도 있음. 이런 경우를 처리하려고 `onclick`에서 제출 버튼을 비활성화하는 건 매우 흔함 - 예전처럼 Apple/Mac/Jobs 팬보이는 아니지만, 멋진 걸 보여주고 싶어 하는 사람이 진행하는 것 같던 **Apple 발표**는 그립다 최근 Apple 발표는 너무 딱딱하고 비인간적이며 양복 입은 사람들이 운영하는 느낌이라 끝까지 보지도 못했음. 모두가 신성한 대본에서 벗어나면 해고될까 봐 감정과 인간미를 숨기는 로봇처럼 보임 주제에서 벗어났을 수는 있지만, Jobs의 다소 지저분한 즉흥 발표조차 얼마나 즐거웠는지 떠오름 - “그럼 이런 경우는?”이라고 하기엔 이 상황은 명백히 아님. 이유는 두 가지임: 1. “The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]” 2. 이 버튼을 **연속으로 3번 누를 좋은 이유**가 있음 - 다른 곳에서 나온 “디바운싱은 어쩌고?”라는 논지는 지지하고 싶고, 글쓴이가 그냥 무시해서는 안 됨 하지만 **you had one job** 밈도 싫고, 생각 없이 쓰는 것에 반대하고 싶음. 대부분 이 밈은 틀렸고, 버튼에서도 대체로 마찬가지임. 일반적인 사용자 인터페이스에서 특정 버튼은 다음 역할 중 여러 개를 동시에 가짐: * 버튼을 누르면 어떤 동작이 일어나는지 전달 * 때로는 시스템 일부의 현재 상태를 전달, 예를 들어 모드를 켜고 끄는 버튼이 현재 모드를 시각적으로 보여줌 * 클릭 시 의도한 동작 실행 * 때로는 명령을 받았고 실행 중임을 전달, 예를 들어 원문 사례처럼 회전 애니메이션 중 버튼을 비활성화해 혼란을 피할 수 있음 - **you had one job** 밈 뒤에는 거의 항상 “내가 네 일의 실제 복잡성을 고려하기를 거부했기 때문에”가 붙을 수 있음 - 좋은 지적이고, 특히 사람마다 **버튼**이 무엇이고 무엇이 아닌지에 대한 기대가 다르다는 점을 강조해서 좋음. 각각의 포인트는 라벨이 있는 버튼, 토글이 있는 버튼, 실제 버튼, 진행 표시기를 설명함. 사용자에 따라 이 모든 것이 “버튼”일 수 있음 - “디바운싱은 어쩌고”라면, 버튼 기능을 **터치 시작**이 아니라 **터치 해제**에서 실행하면 되지 않을까? - 버튼에 “일 하나”라는 표현은 잘 맞지 않음. 버튼은 클릭 가능하다는 것 하나만이 아니라 여러 일을 해야 하기 때문임 클릭됐을 때의 피드백, 마우스를 올렸을 때의 피드백, 로딩 상태, 비활성 상태, 이 모든 것의 조합이 있음. 이게 매우 답답하게 느껴지기도 함. 예를 들어 백엔드 서비스에 연결된 버튼을 누르는데 아무 시각 피드백이 없으면 그 버튼이 눌렸는지 알 수 없음. **로딩 상태**도 없다면 뒤에서 뭔가 처리 중인지 알 수 없어 계속 여러 번 누르게 됨 - 글쓴이는 어떤 속도로든 세 번 클릭하면 항상 같은 기능이 수행되길 원함. 사진을 빠르게 넘기며 예측 가능하게 각각 회전시키고 싶은 것인데, 그건 타당함 > And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you. 글쓴이는 접근성을 근거로 듦 다만 완전히 반대편 주장도 상상할 수 있음. 예를 들어 운동 장애나 파킨슨병이 있는 사람은 이미 의도가 확정됐을 때 **과도한 클릭이 무시되는 동작**을 더 좋아할 수 있음 이런 걸 제대로 만들기는 까다로움 - iOS에는 **Ignore Repeats**라는 접근성 옵션이 있는데, 시스템 전체 설정이라 더 나은 접근으로 보임. 이런 보정이 필요한 사람은 화면 키보드 같은 곳에서도 적용받을 수 있고, 다른 모든 사람이 타이핑을 느리게 할 필요도 없음 - 모든 UI 위젯이 이런 것까지 생각해야 한다고 보지는 않음 기기 전체 설정으로 처리할 수 있을 것 같음. 예를 들어 서로 50px 이내에 있는 탭이 100ms 안에 반복되면 무시하는 식임 - 완전히 동의함. 파킨슨병까지 가지 않더라도, 아주 고령은 아니지만 나이가 있는 사람들이 휴대폰과 터치스크린을 쓰는 걸 보면 작은 버튼을 정확한 위치에서 누르고 “내가 눌렀다”는 느낌을 얻는 게 자주 어렵다는 걸 볼 수 있음 그래서 접근성 관점에서는 **Nothing Phone의 동작**이 훨씬 더 잘 맞을 것 같음. 그런 사용자들은 이미지를 특정 위치에 두려고 숫자를 세며 6번 클릭하지 않음. 게다가 현재 위치로 정확히 되돌아가기 위해 미리 8번 클릭한다는 것도 별로 말이 안 됨 이 경우의 사고방식은 “클릭하고 기다린 뒤, 원하는 위치인지 비교하고, 다시 클릭”에 가까움. 반대로 입력을 버퍼링하는 민감한 버튼은 지나치게 가고, 다시 너무 돌아오는 식의 오버슈팅을 만들 가능성이 큼. 목록에서 원하는 지점으로 스크롤하려다 계속 빗나가는 상황과 비슷함 iPhone 방식은 기다리지 않고 빠르게 처리하고 싶은 젊은 사람이나 기술 애호가에게 더 적합함. 컴퓨터 키보드에서도 지연 때문에 첫 글자가 화면에 나타나기 전에 여러 글자를 미리 입력할 수 있는 것과 같음 - 예전에 물리 버튼이 달린 기기를 쓴 적이 있는데, 누르면 삐 소리가 나고 시간에 30초가 추가되는 버튼이었음. 그런데 어떤 때는 삐 소리는 나지만 30초가 추가되지 않았고, 어떤 때는 소리 없이 30초가 추가됐음. 그래서 항상 어두운 표시창을 찡그려 보며 동작했는지 확인해야 했음 이건 유난히 나쁜 설계라고 생각했는데, 그 이후 순수 소프트웨어 버튼들에서도 이 고장 난 동작을 그대로 재현하는 경우를 셀 수 없을 만큼 봄. 화면에서 버튼 색이 바뀌는지와 요청한 동작이 실제로 수행되는지가 느슨하게만 연결돼 있음. 왜 그런 걸까? 대체 어떻게 구현했길래? - 이걸 **두 가지 일을 하는 문제**라고 부름 명령형 코드를 작성해 두 명령을 내리는데, 둘 다 독립적으로 실패할 수 있음 이걸 “처리했다”고 가장하는 방법은 많음 우선 테스트는 전부 통과할 테니 대부분의 개발자는 바로 생각을 멈출 수 있음 예외를 잡아 로그만 남기면 된다고 생각할 수도 있지만, 고쳐지지는 않음 운영 환경에서 한동안 돌려보고 문제가 생기는지 볼 수도 있음. 결국 문제가 생기면 개발자는 다시 시도해 볼 것이고, 두 번째엔 아마 동작할 테니 또 생각을 멈출 수 있음 며칠 전 **아웃박스 패턴**에 대한 큰 토론도 있었음. 첫 번째 일을 두 절반으로 쪼개 원자적으로 처리하고, 두 번째 일은 독자에게 맡기는 식임 현실에서 이 문제가 계속 나타나는 이유는 개발자들이 “그런 일은 안 일어남”, “내가 고쳤음”, “고칠 수 없음”이라는 양자 중첩 상태에 있기 때문이라고 봄 - 이건 대부분의 UI 프레임워크가 공유하는 두 설계 특성 때문에 정말 흔함: 버튼 색을 바꾸는 코드는 “버튼” 컴포넌트의 내부 동작이라, 모든 버튼마다 따로 구현하지 않아도 됨. 하지만 이는 실제 동작을 수행하는 코드와 어느 정도 분리된다는 뜻임. `on click` 처리기에 원문처럼 “회전 애니메이션 중이면 이미지를 회전하지 않음” 같은 최후의 검사가 있으면, 버튼에게 색 변경을 취소하라고 알려줄 방법이 없는 경우가 많음. 반대로 색 변경 애니메이션이 제대로 재생되지 않아도 `on click` 처리기는 실행될 수 있음 버튼은 보통 마우스 버튼을 눌렀을 때 색이 바뀌지만, 동작은 마우스 버튼을 뗄 때 수행함. 이 방식은 누른 채로 버튼 밖으로 드래그해 마지막 순간에 취소할 기회를 의도적으로 주기도 하고, 모바일에서는 상호작용을 클릭이 아니라 스크롤로 재해석하기도 함. 다른 때는 색이 이미 바뀐 뒤 동작을 막는 일이 생길 기회만 더 늘림 - 엘리베이터에서 이걸 꽤 꾸준히 봄. 버튼을 아주 짧게 누르면 누르는 동안 불은 들어오지만 실제로는 **버튼 입력이 등록되지 않음** - 버튼 색 변화는 누르기에 성공했다는 걸 보여줌. 이걸 즉시 하지 않으면 대부분의 사람은 다시 시도하도록 조건화돼 있음. 특히 운동 제어가 약한 사람에게 중요함 이는 현재 소프트웨어 상태에서 그 누름이 유용한 입력인지와는 완전히 독립적임. 잘 작성된 소프트웨어라면 입력을 받을 수 없다는 걸 알고 버튼을 비활성화했어야 하고, 적당히 잘 만든 소프트웨어라도 동작을 처리 중이거나 취소됐다는 **거의 즉각적인 피드백**을 제공해야 함 - 테스트 부족과, 동작 실패가 너무 드물어서 고려할 가치가 없다는 가정 때문일 듯함. 하지만 이런 패턴은 인터페이스를 신뢰하고 효율적으로 쓰기 어렵게 만듦 - 사람들은 **애니메이션**이 순전히 보조 역할이며, 애니메이션 자체가 목적이 아니라는 점을 자주 잊음 애니메이션은 로딩 시간을 가리고 한 상태에서 다른 상태로 부드럽게 넘어가게 하려고 존재함. 그래서 쓰는 것임 이 지식이 결국 사라졌고, 이제는 애니메이션이 끝날 때까지 기다려야 하는 코드가 생김 놀라운 화물 숭배의 또 다른 예임 - “로딩 시간을 가리고 한 상태에서 다른 상태로 부드럽게 넘어가게 한다”는 설명을 더 확장하고 싶음. 잘 쓰면 사용자의 특정 행동 때문에 **상태 변화**가 직접 일어나고 있음을 보여주고, 그것을 되돌리거나 수정하는 방법도 암시함 사실 “가린다”는 표현에는 동의하지 않음. 뭔가가 왜 나타났는지 힌트 없이 즉시 나타나는 건 터치스크린에서 분명한 안티패턴임 - 애니메이션은 순전히 그 용도만은 아님. 앱을 사용할 때의 **느낌**에도 창의적으로 기여함 - Apple은 예전엔 이걸 알고 있었음. 항목이 사라진 뒤에는 애니메이션을 넣었지만, 항목을 보여주기 전 애니메이션은 피했음 옛 Apple은 디자인이 예쁘게 만드는 것 이상이라는 걸 이해했음. 요즘의 유리 느낌 Apple은 데모에서 어떻게 보이느냐가 전부임 - 애니메이션은 거의 항상 불필요하게 느껴짐. 앱이나 시스템이 허용하는 모든 경우에 꺼 둠 - Android에서 모든 애니메이션을 꺼뒀고 훨씬 좋게 느껴짐. 특히 과도하게 스크롤하려고 하면 화면 전체가 늘어나는 그 **오버스크롤 애니메이션**이 정말 싫음 - 첫 번째 비교를 봤을 때, 솔직히 문제는 iPhone 예시에 있다고 생각했음. 회전 버튼을 누를 때마다 이미지 아래의 버튼과 슬라이더가 사라졌다가 다시 페이드인하는데, iOS 여러 앱에서 본 동작이고 끝없이 거슬림. 특히 **Screenshot 앱**이 개인적으로 큰 불만임 어떤 상호작용 전후에 모두 조작할 수 있는 UX 요소라면, 변환이든 처리든 그 동안 계속 보이게 둬야 함. iPhone에서 회전 중 이 버튼들을 숨기면 어떤 UX 이득이 있나? 더 좋아 보이지도 않음. 물론 최근 Apple 소프트웨어는 실제 UX 개선을 외형이라는 제단에 희생해 왔지만 다만 이런 탭은 애니메이션과 독립적으로 처리돼야 한다는 글쓴이 주장에는 동의함 - 소프트웨어 앱에도 컴퓨터 칩처럼 **테이프아웃 규칙**이 있으면 좋겠음. 칩을 설계할 때는 프로그램이 설계를 검토하고 “X 금속과 Y 금속의 배선은 Z 거리 이내에 있으면 안 됨” 같은 300쪽짜리 규칙과 비교함 UX에도 비슷한 걸 만들 수 있음. 잘 알려진 UX 흠이 있는 상태로 출시하려 하면 경고를 띄우는 디자인 패턴 제약 모음 같은 것임 - 예전에 아기가 쓸 수 있도록 만든 **BabyButton**을 구현했던 때가 떠오름. 일반적인 클릭 동작 대신 `touchdown` 이벤트를 썼는데, 그러면 아이가 뭔가 일어났다는 걸 바로 볼 수 있고, 버튼을 너무 오래 누르거나 누른 채 손가락을 움직여도 문제가 없었음 그런 연령대를 위한 시스템을 만들어야 하는지는 완전히 다른 주제지만, 사용자 필요에 맞는 것을 설계하는 좋은 도전이었다고 느낌 - GUI 버튼이 마우스 버튼을 놓을 때만 실행되고, 누른 채 버튼 영역을 나갔다 들어오는 등의 특정 동작을 하는 데 우리가 얼마나 익숙해졌는지 흥미로움 현실의 버튼은 99% 이상 누르는 즉시 일을 함. 하지만 GUI에서 그렇게 동작하는 버튼은 이상하게 느껴질 것임 - 글쓴이가 말하려는 핵심에 더 가까운 진짜 글은 이쪽임: [https://aresluna.org/show-your-hands-honor/]() - 통화 중에 iPhone의 화면 켜기/끄기 버튼을 누르면 어떤 때는 통화가 종료되고, 어떤 때는 그냥 화면만 꺼지는 경우가 있나? 아직도 패턴을 모르겠지만, iPhone을 주머니에 넣기 전에 그 버튼을 눌렀다가 가끔 실수로 **통화를 끊은 적**이 있음 - 스피커폰/핸즈프리 모드일 때는 화면만 꺼짐. 귀에 대고 있을 때는 화면이 자동으로 꺼지니 잠금 버튼을 누르지 않을 거라고 가정하는 듯함. 문제는 가끔 버그 때문에 화면이 계속 켜져 있거나, 조용한 방에서는 핸즈프리처럼 쓰는 경우도 있다는 것임 ### Comment 61301 - Author: neo - Created: 2026-07-06T09:02:53+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/zhizsf/if_you_re_button_you_have_one_job) - 가벼운 빈정거림이지만, 좋은 UI/UX를 논한다면 **컨트롤도 표시도 없는 동영상 임베드**는 최악임 자동 재생을 기본으로 꺼두는 사람이 많고, 거의 같은 이미지 두 장을 보면서 “그래서 뭐가 다르지?” 하고 한참 있었음 - “동영상이 있었어?”라고 생각했는데, 나도 놓친 듯함 - 왜 “최악”인지 모르겠음. 아래로 조금 내려서 문제 설명을 읽지 않고 계속 “그래서 뭐?”라고만 생각한 건가? - 이 주제라면, **GitHub**가 애니메이션 GIF에 재생 컨트롤을 보여주는 건 인정해야 함. 다른 곳에서는 거의 못 봄 - 브라우저 차이일 수도 있음. Android의 Vivaldi에서는 큰 재생 버튼과 진행 막대가 보였음 - “애니메이션이 끝날 때까지 사용자를 절대 기다리게 하지 말라”에 전적으로 동의함 앱이라면 예쁘게 보이는 것보다 **사용자 명령**이 항상 우선이어야 함 - 이 원칙은 게임에도 적용된다고 봄. 어떤 게임은 메뉴를 연 뒤 입력이 등록되기까지 아주 짧은 지연이 있음 화려한 메뉴 애니메이션이 있는 게임에서 일시정지와 아래 방향키를 빠르게 누르면, 메뉴가 뜬 뒤 두 번째 항목이 선택돼 있어야 하는가 같은 문제임 게임에서 **입력 버퍼링**은 미묘한 주제지만, 메뉴 조작에서는 대체로 나쁘게 느껴지는 경우가 드묾 - 동영상이 정보를 전달하는 방식이 별로였음. 버튼을 여러 번 연속으로 누르는 순간을 알아차리려면 집중해서 봐야 했음 본론으로 가면, Android 폰이 정말 잘못하고 있는지도 애매함. 빠르게 8번 눌러 원하는 결과를 얻고 싶은 답답함은 이해하지만, 데스크톱 OS의 **실수 더블클릭 감지**가 떠오름 결국 제조사가 생각하는 사용성과 사용자가 느끼는 편의성의 차이에 가까워 보임. 굳이 따지자면 iPhone이 애니메이션 중에도 “Done” 버튼을 보여주는 쪽이 더 산만하게 느껴짐 - Android가 완전히 틀렸다고 보긴 어려움. 느리게 반응하는 UI 때문에 동작을 **실수로 두 번 실행**한 적이 있음 최선은 애니메이션이 끝날 때까지 버튼을 비활성화하는 방식일 수 있음 - 그러면 글에서 보여준 문제가 그대로 생김. 화면을 보지 않고 **시계 반대 방향 90도 회전**을 하기가 거의 불가능해짐 “세 번 클릭”이 통하지 않고, 애니메이션 중 추가 클릭이 무시됨. 클릭하고 화면을 보며 애니메이션이 끝나길 기다리고, 다시 클릭하고 또 기다리는 과정은 느리고 사용자의 주의를 많이 요구함 더 나은 해법은 UI에서 즉각적인 피드백을 주는 것 같음. 클릭이 처리됐다는 버튼 상태를 바로 렌더링하거나, 느린 전체 애니메이션이 나오기 전 임시로 빠르게 화면을 다시 그려 현재 진행 상황을 보여줄 수 있음 - 글 전체에 강하게 동의함. 이건 애니메이션이 **히포크라테스 선서**를 어긴 문제라고 표현하고 싶음 애니메이션의 제1원칙은 “먼저 해를 끼치지 말라”, 즉 “먼저 사용자 입력을 방해하지 말라”여야 함 - 따라오지 못하는 **로터리 인코더**를 겪어본 적 있는가? 내 헤드폰 앰프의 볼륨 노브는 너무 빨리 돌리면 아무 일도 일어나지 않음 하루만 대통령이 된다면… - 이런 걸 볼 때마다 내 GUI 툴킷이라면 어떻게 될지 생각함. 내 툴킷은 Windows 플랫폼에서 빌려온 동작처럼 빠른 두 번의 클릭을 더블클릭으로 처리하는데, 이게 가끔 미치게 함 더블클릭 자체는 흔한 관례이고 클릭과 구분되는 가치가 있음. 이상적으로는 클릭 이벤트를 멱등적으로 만들어 두 번 발생해도 문제가 없게 해야 함. 예를 들어 클릭은 항목 선택, 더블클릭은 기본 동작 실행이라면 같은 항목을 두 번 선택해도 해롭지 않음. 하지만 현실이 항상 그렇진 않음 문제는 버튼을 아주 빠르게 클릭하면 버튼이 한 번만 실행되고, 그다음은 더블클릭 이벤트로 가서 아무것도 안 할 수 있다는 것임. 그래서 빠르게 누르면 클릭의 절반이 무시되는 동작이 생김 이 문제 때문에 `triggersOnMultiClick`이라는 불리언을 만들었고, `true`로 설정하면 더블클릭 같은 빠른 다중 클릭에서도 트리거 이벤트를 내보내게 했음. 다만 이전 호환성 때문에 기본값을 `false`로 뒀는데, 새 메이저 릴리스를 낼 때가 됐으니 글의 주장이 타당하다고 보고 기본값을 지금 `true`로 바꾸려 함 “2021년 7월 2일 추가, 기본값 `false`. 2026년 7월 5일(v13.0)에 기본값을 `true`로 바꿔 버튼의 모든 클릭이 기본적으로 트리거되게 함. 예전 동작을 원하면 더블클릭 이벤트를 오버라이드하거나 상위 생성자 호출 뒤 `triggersOnMultiClick = false`를 설정하라”는 식으로 남길 수 있음 애니메이션 구현 쪽에서도 비슷한 동작이 우연히 생길 수 있음. 객체 안에 애니메이션 위치 변수를 두고 클릭 때 값을 설정한다면, 두 번 클릭했을 때 선택지는 대략 둘임. 남은 애니메이션을 건너뛰고 다음 내부 상태로 바로 넘어가거나, `if(animationCounter) return;`처럼 시각적 부드러움을 지키려고 이벤트를 무시하는 것임. 글의 Android 개발자는 후자를 택한 듯함 Apple 쪽은 아마 세 번째 방식, 즉 **대기 중인 애니메이션 큐**를 두고 이벤트를 거기에 넣는 방식을 쓴 것 같음. 궁금한 건 내부 상태가 큐에 넣을 때 바뀌는지, 완료 시점에 바뀌는지, 아니면 실제로 이미지를 애니메이션으로 회전시키는지임. 중간에 애니메이션을 끊고 저장하면 45도 회전된 이미지가 나올 수도 있는가? 내가 한다면 EXIF를 원자적으로 90도 갱신하고 전환 애니메이션은 별도로 돌릴 것 같음 구현 단순성, 시각적 충실도, UI 동작 사이에서 합리적인 선택지가 여러 가지 있을 수 있음. 개인적으로는 두 번째 누름이 애니메이션을 기다리지 않고 새 상태로 즉시 스냅되는 방식도 마음에 듦. 애니메이션 큐까지 만들지는 않을 것 같음 비슷한 시기에 코드를 바꾸는 게 웃김. 지난번 수정도 7월 2일이었고 이번은 우연히 7월 5일임. 이런 이력을 문서 주석에 바로 써두는 걸 좋아함. 나중에 변경할 때 추억 삼아 읽을 수도 있어서 좋음 Apple은 아마 기본 애니메이션 큐를 제공할 것 같지만, 상태 변경 시점은 여전히 별도 문제임. 웹에서는 상태를 원자적으로 갱신하고, CSS `transform` 전환 같은 시각 전용 애니메이션을 별도로 둘 것 같음. 레이아웃 재계산도 피할 수 있어 구현이 쉽고 효율적일 듯함. 애니메이션보다 빠르게 클래스 이름을 바꾸면 점프할지 큐잉될지는 나중에 실험해보고 싶음 - 나이가 들어서 그런지, **실수로 두 번 탭**했을 때 이런 동작이 짜증났던 적이 몇 번 있음 같은 위치의 버튼이나 더블탭을 확인 수단으로 삼는 건 끔찍함. 정말 확인이 필요하다면 실수로 확인이 쉽게 일어나게 만들면 안 됨 다만 이 예시에서는 빠른 연속 입력을 받아주는 게 좋은 생각 같음. 다른 경우에는 그렇지 않을 수 있음. 물리 버튼 중에는 무언가가 “끝날” 때까지 두 번 누르는 걸 의도적으로 막는 것들이 있고, 항상 의식적인 설계는 아니어도 때로는 맞는 선택임 버벅이는 기기나 고장난 기기를 써야 하는 사람도 많고, 손이나 손가락 떨림 같은 건강 문제가 있다면 입력을 제한하는 데 이점이 있을 수 있음 이 예시는 양쪽 모두 괜찮다고 볼 수 있는 사례 같음. 기다려야 해서 더 짜증나는 예도 있고, 애니메이션이든 다른 조건이든 **입력 제한**이 있었으면 싶은 예도 분명 있음 - 모바일 브라우저 검색 결과가 손가락 밑에서 갱신되며 내가 누르려던 선택지를 다른 위치로 밀어내는 일이 정말 끊임없이 짜증남 더 기다리도록 스스로를 훈련하긴 했지만, UI 상호작용이 수신 상태 때문에 완료 시간이 흔들리는 **백그라운드 비동기 작업**에 민감해야 한다는 건 말이 안 됨