2026-09-10: 설명과 코드 예시를 보완했습니다. 아래 예시는 글의 설계 의도를 전달하기 위한 것이며, 원 프로젝트에 반영된 변경 내역과는 구분합니다.
한글을 입력하다 포커스를 옮겼는데 이전 조합이 남았다. 값을 비웠는데 다음 입력에 영향을 주기도 했다. 화면에 글자가 보인다고 입력이 끝난 것은 아니었다.
커스텀 키보드와 인풋을 만들기 시작한 출발점은 이 조합 중간 상태였다.
조합 중인 입력과 확정된 입력
IME는 여러 키 입력을 하나의 문자로 조합한다. 브라우저에서는 compositionstart, compositionupdate, compositionend로 그 과정을 관찰할 수 있다. InputEvent.isComposing은 입력이 조합 구간에 있는지 확인하는 단서다. MDN isComposing
다만 input 이벤트가 항상 조합 종료 뒤에만 발생하는 것은 아니다. 조합 중에도 발생할 수 있고, OS·브라우저·IME 조합에 따라 이벤트 순서와 값 갱신을 확인해야 한다. React의 onChange 역시 네이티브 change와 단순히 같은 시점이라고 볼 수 없다.
내가 관찰한 문제
앞에서 말한 현상을 처음에는 macOS와 Windows의 예로 나누어 설명했다. 하지만 재현 환경과 버전을 남기지 않은 상태에서 각 OS가 늘 그렇게 동작한다고 일반화할 수는 없다.
이런 현상을 확인할 때는 입력값뿐 아니라 조합 이벤트, 포커스 이동, 상태 갱신 순서를 함께 기록해야 한다. preventDefault도 이벤트가 취소 가능한지와 처리 시점에 따라 적용 범위가 다르다.
직접 만든 입력 시스템을 실험한 이유
조합 중인 값을 바꾸거나 포커스를 옮길 때마다 운영체제와 브라우저 사이의 처리를 함께 생각해야 했다. 그렇다면 입력 과정을 직접 만들어보면 어떨까. 조합 규칙과 커서 위치를 스스로 관리하는 프로토타입은 그렇게 시작했다. “안 되면 직접 만든다”는 쪽이었다.
일반적인 폼이라면 네이티브 입력을 유지하고 조합 중의 값 변경이나 포커스 처리부터 검토하는 편이 범위가 작다. 내 관심은 거기서 한 걸음 더 들어가, 조합 과정 자체를 어디까지 직접 다룰 수 있는지 확인하는 데 있었다.
직접 구현하면 선택 영역, 복사·붙여넣기, 실행 취소, 모바일 입력, 접근성도 함께 맡아야 한다. 조합 문제 하나를 다루려다 입력 시스템 전체를 만들게 될 수도 있다. 이 프로젝트는 모든 OS의 기본 입력을 대체하는 완제품이 아니라, 그 범위를 확인해보는 실험으로 두고 있다.
다음 글에서는 스타일과 입력 표면을 분리하려던 첫 시도, 그리고 키보드를 여러 인풋과 공유하도록 바꾼 구조를 다룬다. 직접 만들기로 했으니, 이제 정말 만들어볼 차례다.
Assisted by AI
© uiwwsw · 본인 소유의 글·이미지에 대한 무단 복제·재게시를 허용하지 않습니다. 개인 열람·원문 링크 공유·검색 색인과 제한적인 미리보기는 허용합니다. 법령상 이용 예외, 기존 이용 허락, 코드·제삼자 자료의 기존 라이선스는 유지합니다. 콘텐츠 이용 안내