# 왼손잡이 사용자에게만 영향을 준 WordPress 버그

> Clean Markdown view of GeekNews topic #31250. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31250](https://news.hada.io/topic?id=31250)
- GeekNews Markdown: [https://news.hada.io/topic/31250.md](https://news.hada.io/topic/31250.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-09T09:16:05+09:00
- Updated: 2026-07-09T09:16:05+09:00
- Original source: [shkspr.mobi](https://shkspr.mobi/blog/2026/07/a-bug-which-only-affected-left-handed-users/)
- Points: 1
- Comments: 1

## Topic Body

- 모바일에서 스크롤 중 **댓글 답글 상자**가 갑자기 열리는 문제가 있었고, 오른손 엄지로 스크롤하던 사이트 운영자는 재현하지 못했음
- 원인은 페이지 왼쪽의 **reply 링크**와 WordPress의 `touchstart` 처리였으며, 왼손 엄지 스크롤이 의도치 않은 링크 터치로 이어질 수 있었음
- 이 버그는 **7년 전 WordPress Trac**에 이미 보고됐고, 관련 코드는 2017년에 WordPress 개발 저장소에 추가됐음
- 과거에는 터치와 더블탭 줌을 구분하기 위한 **300ms 지연 회피**가 필요했지만, 2013년 Chrome 글과 2015년 FastClick 자료 기준으로 이미 오래된 문제였음
- 수정은 WordPress 코드에서 **몇 줄을 삭제**하는 방식이며, 모바일 스크롤 중 원치 않는 댓글 답글 동작을 줄이는 데 초점이 있음

---

### 블로그 최적화와 댓글 JavaScript
- WordPress 기본 설치 위에 여러 **커스텀 수정**을 적용해 블로그를 최대한 최적화함
- JavaScript 사용량을 최소한으로 줄였고, JavaScript 없이도 기능이 동작하도록 구성함
- 다만 일부 기능에는 JavaScript가 도움을 주며, 가장 눈에 띄는 예가 **댓글 기능**임

### 왼손 스크롤에서만 드러난 문제
- 독자가 사이트 버그를 알려왔고, 페이지를 스크롤하는 중 **댓글 상자**가 갑자기 나타나 탐색을 방해했음
- 사이트 운영자는 자주 스크롤했지만 오른손 엄지를 사용했기 때문에 같은 문제를 발견하지 못함
- 버그를 보고한 사용자는 왼손으로 스크롤했고, 문제가 된 **reply 링크**는 페이지 왼쪽에 있었음
- 오른손 엄지 스크롤에서는 잘 드러나지 않던 터치 이벤트가 왼손 엄지 스크롤에서는 원치 않게 발생할 수 있었음

### WordPress의 `touchstart` 처리
- 이 문제는 [WordPress Trac에서 7년 전 보고](https://core.trac.wordpress.org/ticket/46713)된 적이 있음
- 2017년에 WordPress 개발자가 링크 클릭에 [`touchstart` 리스너를 추가](https://github.com/WordPress/wordpress-develop/commit/14dd35e62e1325ca1c6caef0a8623ce3f02d7da9)함
- 과거 브라우저는 터치 이벤트가 클릭의 시작인지, 더블탭 줌의 시작인지 확실히 구분하지 못했음
- 링크에서 터치가 발생했을 때 이벤트를 먼저 발생시키는 방식은 당시 **300ms 지연**을 피하기 위한 처리로 볼 수 있었음

### 이미 사라진 300ms 지연 문제
- 300ms 탭 지연은 오래전부터 같은 방식의 문제가 아니었음
- [2013년 Chrome 개발자 블로그 글](https://developer.chrome.com/blog/300ms-tap-delay-gone-away)은 해당 지연 문제가 사라졌다는 점을 다룸
- [2015년 FastClick 자료](https://github.com/ftlabs/fastclick) 기준으로도 이 문제는 더 이상 해결해야 할 주요 이슈가 아니었음
- 따라서 2017년에 왼손 스크롤 사용자를 괴롭히는 형태의 코드가 왜 추가됐는지는 분명하지 않음

### 수정 방식과 기대 효과
- 버그 보고 후 7년이 지나 [WordPress 수정 PR](https://github.com/WordPress/wordpress-develop/pull/12168)이 커밋됨
- 수정은 복잡한 변경이 아니라 WordPress 코드에서 **몇 줄을 삭제**하는 방식임
- 이 변경으로 모바일 스크롤 중 reply 링크가 의도치 않게 작동해 댓글 답글 상자가 열리는 문제가 줄어들 수 있음
- `<meta handed="right">` 같은 손잡이별 접근 제한 기능은 존재하지 않으며, 이번 변경은 원치 않는 터치 이벤트를 막는 데 초점이 있음

## Comments



### Comment 61459

- Author: neo
- Created: 2026-07-09T09:16:06+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/oj9lal/bug_which_only_affected_left_handed_users) 
- 세상의 너무 많은 것이 **오른손잡이** 기준임. 펜 광고 문구도 오른손으로 잡아야 읽히는 방향인 경우가 많음  
  그래도 왼손잡이로 살면 타고난 광고 차단 기능이 조금은 있는 셈임
  - 세상에, 펜이나 연필의 글자가 **잡고 있을 때 읽히도록** 배치된 거라는 걸 이제야 깨달음. 왼손잡이식으로 잡으면 항상 거꾸로 보인다는 것도 처음 알았음
  - 그런 설명에 맞는 펜을 떠올려보려 했는데 실패함. 펜 사진까지 찾아봤지만 여전히 잘 모르겠고, 딱 하나가 가까워 보여서 조건에 맞을지도 모르는 **고급 펜** 하나가 떠올랐을 뿐임

- “sinister disposition”이라니 웃김. **sinister**와 **dexterous**(dexter)가 문자 그대로 각각 ‘왼쪽’과 ‘오른쪽’을 뜻한다는 걸 알게 된 날이 기억남  
  규범에서 벗어남 → 악이라는, 우리가 여전히 안고 사는 문화 현상이 지금도 흥미롭다
  - 왼손 우세가 아주 강하지만, 양손으로 할 수 있는 몇몇 일에 대해서는 보통 “ambi-dexterous”라는 표현을 거부하고 스스로를 **omni-sinisterous**라고 부름
  - 여러 **인도유럽어족** 언어에서 “오른쪽”을 뜻하는 단어는 공통 어원을 갖지만 “왼쪽”은 그렇지 않음 [1]  
    아마 왼쪽을 뜻하던 원래 단어가 금기가 되어 새 단어로 대체되고, 그 새 단어도 나중에 다시 금기가 되는 식으로 반복됐기 때문일 가능성이 큼  
    [1]: https://www.reddit.com/r/asklinguistics/comments/cpxwsf/in_indoeuropean_languages_why_does_right_appear/

- 사람들은 보통 **주로 쓰는 손**으로만 휴대폰을 잡나? 왼손잡이지만 휴대폰은 양손을 거의 무작위로 비슷하게 쓰고, 다들 그런 줄 알았음
  - 왼손잡이인데 휴대폰은 거의 항상 **오른손**으로 잡음. 이유는 단순함  
    처음에는 오른손으로 휴대폰을 잡고 왼손으로 조작했는데, 시간이 지나면서 오른손 엄지로 하는 일이 점점 늘어 결국 주된 조작 지점이 됨  
    마우스도 오른손으로 쓰는데, 어릴 때 컴퓨터실 마우스 케이블이 짧아서 왼쪽으로 옮겨 쓸 수 없었기 때문임
  - 표본 하나로, **터치스크린 타이핑**은 확실히 우세손으로 할 때 더 빠름. 양손 모두 가능하긴 하고 손글씨만큼 어렵지는 않지만, 화면을 잠깐 보거나 몇 번 스와이프하는 정도를 넘어서면 우세손이 더 편함
  - 왼손잡이는 어느 정도 **양손잡이 성향**을 갖게 되는 편임. 세상이 우리에게 오른손잡이가 되라고 강하게 요구하기 때문임  
    나도 왼손잡이지만 손글씨처럼 오른손으로 하는 일이 많음. 피아노에서도 오른손이 우세손인데, 대부분의 곡이 쓰인 방식도 분명 영향을 줬을 것임. 휴대폰도 양손을 다 씀
  - 화면을 보는 것 이상을 할 때는 사실상 거의 항상 맞는 손만 씀
  - 오른손잡이인데 양손을 다 씀. 오른손을 조금 더 선호하긴 하지만, 간단히 테스트해보니 휴대폰에서는 오른손보다 **왼손 타이핑**이 더 나은 것 같음  
    다만 두세 문장을 넘기면 양쪽 엄지로 입력함

- 흥미롭게도 다른 거의 모든 일은 오른손으로 하지만, 휴대폰은 **왼손으로 잡고 쓰는 쪽**으로 기울어짐  
  이유는 잘 모르겠지만 휴대폰을 왼쪽 주머니에 넣고 지갑과 열쇠를 오른쪽에 넣어서 그런 것 같음. 열쇠를 쓰고 지갑을 꺼내는 건 우세손으로 하는 게 더 편함. 내가 특이한 건지 궁금함
  - 나도 정확히 그렇게 하고, 이유도 바로 그거임. 휴대폰은 왼쪽 주머니에 들어가니 꺼내면 자연스럽게 **왼손**에 있게 됨  
    결국 스크롤이나 기본 작업은 왼손으로 하지만, 긴 메시지를 입력할 때는 왼손으로 잡은 채 오른손으로 스와이프 입력하는 편임

- 거기서 **`touchstart`** 를 쓴 건 애초에 잘못이었음  
  마우스, 터치, 포인터는 누를 때가 아니라 뗄 때 활성화되지만, 누르기 시작한 지점은 같은 요소여야 함. 키보드 이벤트는 keyup이 아니라 keydown에서 활성화됨. 다만 버튼에서 `Space`가 동작하는 경우는 이상하게도 keyup이고, 마우스와 달리 keydown이 어느 요소에서 일어났는지도 신경 쓰지 않음  
  `data:text/html,<button onclick=this.textContent=Math.random()>One</button><button onclick=this.textContent=Math.random()>Two</button>` 같은 것으로 여러 가능성을 실험해볼 수 있음  
  `touchstart`에서 활성화를 준비하는 것, 예컨대 필요하면 서버에서 데이터를 미리 가져오기 시작하는 정도는 괜찮았을 것임. 하지만 실제 **동작 실행**은 아직 일어나면 안 되는데, `element.addEventListener( 'touchstart', clickEvent );`가 바로 그걸 잘못 처리했음

- 이게 **왼손잡이**와 무슨 관련인지 이해하지 못했음  
  마우스 사용자라서 모르는 터치패드 특유의 동작인가?
  - 왼손잡이 사용자만 마주친 **모바일 터치 이벤트 버그**였음. 오른손잡이는 오른쪽 엄지로 화면을 드래그하므로 손가락이 오작동하는 링크 근처까지 가지 않았음
  - 글에는 명시적으로 쓰이지 않았지만, 연결된 PR을 보면 **터치스크린 사용**에 관한 내용임이 분명함. 아마 스마트폰에서의 상황일 것임