같은 Shift+2인데, Windows 숫자패드는 왜 다르게 움직일까?

Shift가 숫자패드의 역할을 잠시 바꾼다

Windows에서 숫자패드의 2는 숫자 입력과 아래 방향 이동이라는 두 역할을 갖는다. Num Lock을 켰더라도 Shift를 함께 누르면 방향 이동으로 해석될 수 있다. 키에 같은 숫자가 인쇄돼 있다는 이유로 상단 숫자열과 똑같은 단축키가 된다고 생각하면 여기서 어긋난다.

이 동작은 현재 공개된 Rust 창 관리 라이브러리 winit의 Windows 입력 코드에도 설명돼 있다. Shift를 누른 채 숫자패드를 쓰면 Num Lock이 꺼진 것처럼 처리되며, 이 과정에서 앱에 Shift를 뗀 것 같은 이벤트가 전달될 수 있다는 내용이다. 앱 개발자가 실제 입력 이벤트를 살펴야 하는 이유다.

Figma의 확대 단축키는 왜 아래 방향키가 됐나

Marcin Wichary가 2021년에 소개한 Figma 사례가 이 차이를 잘 보여 준다. 2019년에 들어온 신고에서 일반 숫자열의 Shift+2는 선택 영역 확대였지만 숫자패드 조합은 아래 방향으로 해석됐다. 그는 브라우저가 제공하는 정보로 두 입력을 구별해 수정했다고 설명했다.

Wichary가 따라간 배경은 IBM PC 키보드다. 숫자와 방향키가 같은 자리를 쓰자 Num Lock으로 모드를 바꾸고 Shift로 잠시 반대 역할을 쓰게 했다. 이후 방향키가 분리돼도 사용자가 익힌 조작은 남았다. 오래된 키보드 관습이 새 디자인 도구까지 이어진 사례다.

같은 화면에서 상단 숫자열과 숫자패드를 나눠 본다

현재 사용하는 앱에서 비슷한 증상이 있다면 먼저 입력 조건을 좁히는 편이 빠르다. 선택한 오브젝트와 화면 상태를 그대로 둔 채 상단 숫자열로 눌렀을 때와 숫자패드로 눌렀을 때를 비교한다. 이어 Num Lock 상태와 Shift 조합을 나눠 보면 숫자가 입력되는지, 방향 이동이 일어나는지 구분할 수 있다.

Figma의 키보드 레이아웃도 별도로 확인할 항목이다. 공식 도움말에 따르면 기본 매핑은 US QWERTY이며 Korean을 포함한 다른 배열을 선택할 수 있다. 메뉴의 Preferences → Keyboard layout 또는 단축키 패널의 Layout 탭에서 바꾼다.

이 설정은 배열에 맞는 단축키를 고르는 기능이다. Windows의 숫자패드 모드 전환을 없애는 스위치는 아니다. 시스템의 키보드 배열을 바꿨다면 Figma 설정도 맞추고, 숫자패드에서만 달라지는 현상은 따로 기록해야 한다.

문자값, 물리 키, 키 위치는 서로 다른 정보다

웹 개발자는 이벤트가 전달한 값을 나눠 볼 수 있다. key는 Shift와 입력 배열이 반영된 값이고, code는 물리 키를 식별한다. location은 숫자패드 같은 위치를 구분한다.

예를 들어 사용자가 입력한 문자를 다루는 기능과 게임의 고정 위치 조작은 필요한 기준이 다르다. code만 읽고 화면에 그대로 키 이름을 표시하면 다른 배열 사용자에게 엉뚱한 문자를 안내할 수 있다. 반대로 문자값만 비교하면 두 물리 위치의 차이를 놓칠 수 있다.

단축키의 숫자가 같아도 실제 키 위치와 운영체제의 해석은 다를 수 있다. 입력을 확인할 때 이 두 조건을 함께 남겨야, 앱의 단축키 매핑을 고칠지 키보드 배열을 맞출지 판단할 수 있다.