테마
05. 포인터·키보드·입력 이벤트
사용자는 "클릭"만 하지 않는다. 마우스, 터치, 펜, 키보드, IME 입력까지 모두 브라우저 이벤트 모델 안에서 흘러간다.
학습 목표
- Pointer Events가 왜 현대 입력 처리의 기본인지 설명할 수 있다.
focus,blur,focusin,focusout의 차이를 이해한다.keydown,beforeinput,input,keyup,composition*흐름을 구분할 수 있다.- 입력 이벤트를 접근성과 함께 설계해야 하는 이유를 설명할 수 있다.
1. 마우스만 생각하면 이미 절반은 놓친다
원문은 마우스 이벤트를 상세하게 다루지만, 지금은 입력 장치를 통합해서 보는 편이 더 현실적이다.
- 데스크톱 마우스
- 모바일 터치
- 태블릿 펜
- 하이브리드 노트북 포인터
이 입력을 하나의 모델로 다루는 것이 PointerEvent다.
| 기준 | MouseEvent | PointerEvent |
|---|---|---|
| 입력 장치 | 사실상 마우스 중심 | 마우스, 터치, 펜 통합 |
| 세부 정보 | 버튼, 좌표 | 좌표 + pointerType, 압력 등 |
| 현대 실무 우선순위 | 보조적 | 높음 |
즉, 새 UI 인터랙션을 직접 구현한다면 Pointer Events부터 검토하는 편이 낫다.
2. Pointer Events로 통합해 생각하기
대표 이벤트는 아래 정도면 먼저 충분하다.
pointerdownpointermovepointeruppointerenterpointerleavepointercancel
여기서 특히 중요한 값은 event.pointerType이다.
mousetouchpen
이 값이 있으면 동일한 드래그 UI라도 입력 장치에 따라 힌트나 감도를 다르게 줄 수 있다.
3. click과 pointerdown은 다르다
둘은 대체 관계가 아니다.
click: 브라우저가 완성된 활성화 동작으로 판단했을 때pointerdown: 포인터가 눌린 즉시
그래서 아래처럼 목적이 다르다.
- 버튼 동작 실행 ->
click - 드래그 시작, 눌림 상태 추적 ->
pointerdown
너무 이른 단계에서 pointerdown만으로 버튼 의미를 처리하면 키보드 접근성과 충돌하기 쉽다.
4. 포커스 이벤트는 입력 UX의 중심이다
폼과 모달, 메뉴, 검색 UI는 결국 포커스 흐름이 핵심이다.
| 이벤트 | 특징 |
|---|---|
focus | 버블링하지 않음 |
blur | 버블링하지 않음 |
focusin | 버블링함 |
focusout | 버블링함 |
그래서 상위 컨테이너에서 포커스 흐름을 관찰하고 싶다면 focusin/focusout이 더 편하다.
예를 들면:
- 폼 섹션 전체에서 포커스 진입/이탈 추적
- 복합 위젯에서 현재 활성 영역 강조
- 대화상자 내부 포커스 관리
5. 키보드 이벤트는 "글자 입력"과 완전히 같지 않다
keydown과 keyup만으로 텍스트 입력을 다 설명할 수는 없다.
현재는 아래 흐름을 함께 보는 편이 더 정확하다.
keydownbeforeinputinputkeyup
여기에 IME(한글, 일본어 등 조합형 입력)가 끼면 compositionstart, compositionupdate, compositionend가 추가된다.
즉, 텍스트 입력은 "키를 눌렀다"보다 "브라우저 편집 버퍼에 어떤 변경이 확정됐는가"로 보는 편이 낫다.
6. beforeinput과 input을 어떻게 나눠 볼까?
beforeinput
- 실제 값 반영 직전에 발생
- 어떤 편집이 일어날지 미리 볼 수 있다
- 고급 편집기나 입력 제어에서 유용하다
input
- 값이 실제로 바뀐 뒤 발생
- 일반적인 폼 입력 반응 로직에 더 자주 사용된다
대부분의 일반 폼은 input만으로 충분하지만, 사용자 편집 흐름을 세밀하게 다뤄야 하는 경우 beforeinput을 알아 두면 좋다.
7. IME 조합 입력을 무시하면 한글 입력에서 바로 문제가 난다
영문 키보드 기준으로만 테스트하면 잘 안 보이지만, 한국어 입력에서는 조합 과정이 있다.
- 입력 중간 상태를 너무 이르게 확정
keydown만 기준으로 자동 완성 실행- 조합 중인데 검증 메시지를 과하게 띄움
이런 실수는 실제 사용자 경험을 크게 해친다.
그래서 검색 자동완성, 태그 입력, 리치 텍스트 편집기는 composition* 이벤트 존재를 알고 설계해야 한다.
8. 입력 이벤트와 접근성은 같이 가야 한다
포커스 링을 임의로 없애지 않는다
outline: none을 습관적으로 넣으면 키보드 사용자에게 현재 위치가 사라진다.
스타일을 바꾸더라도 대체 포커스 표시를 제공해야 한다.
키보드로도 실행 가능해야 한다
마우스 클릭만 연결된 커스텀 카드, div 버튼 UI는 접근성 문제가 되기 쉽다.
- 가능하면 진짜
button,input,a를 사용 - 커스텀 요소라면 역할과 키보드 조작까지 설계
포커스 트랩은 의도적으로만
모달 안에서 포커스를 가두는 것은 필요할 수 있지만, 닫힌 뒤 원래 위치로 돌려보내야 한다.
9. 실무에서 자주 보는 패턴
드래그 시작 감지
pointerdown으로 시작pointermove로 거리 추적- 일정 임계값 이상일 때 드래그 상태 진입
실시간 입력 검증
input에서 값 반영- 너무 공격적인 에러 표시는 지양
- 제출 시점에는 브라우저 기본 검증과 함께 다시 점검
검색 UI
input으로 현재 값 반영- IME 조합 중에는 즉시 검색을 유보할지 검토
- 포커스 이탈 시 자동 닫기와 키보드 탐색 충돌 여부 확인
10. 흔한 안티패턴
| 안티패턴 | 문제점 | 더 나은 방식 |
|---|---|---|
모든 입력을 click만 기준으로 설계 | 터치·펜·키보드 흐름 누락 | Pointer + 키보드 흐름 함께 설계 |
keydown만 보고 텍스트 입력 처리 | IME, 편집 입력 누락 | beforeinput/input까지 고려 |
focus만 듣고 상위 컨테이너 제어 | 버블링이 안 되어 구조가 불편 | 필요하면 focusin/focusout 사용 |
| 포커스 표시 제거 | 키보드 접근성 저하 | 대체 포커스 스타일 제공 |
11. PR 리뷰 체크리스트
- 새 인터랙션이 마우스 외 입력 장치도 고려하는가
click과pointerdown의 역할을 구분하고 있는가- 입력 로직이 IME 조합 상황에서 깨지지 않는가
- 포커스 이동과 복귀 흐름이 설계되어 있는가
- 키보드만으로도 같은 기능을 수행할 수 있는가
핵심 정리
- 입력 이벤트는 마우스만이 아니라 포인터, 키보드, IME까지 함께 봐야 한다
focusin/out,beforeinput,composition*를 알면 복잡한 입력 UX를 훨씬 정확하게 다룰 수 있다- 현대 UI 인터랙션은 성능과 접근성을 함께 고려해야 완성된다