하나의 코드베이스로 윈도우와 맥을 동시에 지원해야 하는 웹 애플리케이션 개발자에게 두 플랫폼의 키보드 차이는 사소해 보이지만 반복적으로 버그를 만들어내는 영역이다. 단축키 하나, 수식키 하나의 명칭과 동작이 다르고, 같은 물리 키가 전혀 다른 기능에 매핑되기도 한다. 소프트웨어 품질을 다루는 한 블로그가 오랫동안 축적한 이런 '함정'들을 한곳에 정리했는데, 화려한 서사는 없지만 크로스플랫폼 UI를 만드는 실무자에게는 체크리스트에 가까운 참고 자료다. 핵심은 명칭의 불일치, 수식키 구조의 차이, 그리고 텍스트 입력 영역에서 벌어지는 충돌로 나눠볼 수 있다.
같은 이름, 다른 키
가장 먼저 혼란을 주는 것은 명칭이다. 윈도우의 Backspace를 맥은 Delete라 부르고, 윈도우의 Delete는 맥에서 Forward Delete가 된다. 즉 플랫폼을 밝히지 않고 그냥 'Delete'라고 말하면 서로 다른 키를 가리킬 수 있다. Enter와 Return도 마찬가지다. 윈도우의 Enter는 맥에서 Return이며, 맥에는 숫자 키패드에만 존재하는 별도의 ⌤ Enter가 따로 있다. 물리 Enter 키가 없는 키보드에서는 Fn+Return으로 이를 흉내 낼 수 있다. 대부분의 맥 소프트웨어에서 Enter와 Return은 같은 동작을 하지만, 포토샵은 Return에서 줄바꿈을, Enter에서 확정을 수행하고 큐베이스나 프로툴스 같은 전문 도구도 둘을 구분한다. 다만 이런 구분은 점차 사라지는 추세다.
수식키 하나가 만드는 여유
기능적으로 윈도우의 Ctrl은 맥의 ⌘ Command에 대응한다. 붙여넣기가 윈도우에서 Ctrl+V, 맥에서 ⌘V인 식이다. 그런데 맥에도 Control 키가 따로 존재한다. 원래 터미널용이었으나 요즘 GUI 앱에서는 비중이 낮은 보조 수식키로 쓰인다. 결과적으로 앱이 활용할 수 있는 수식키가 윈도우는 Ctrl·Alt·Shift 셋인 반면, 맥은 Command·Option·Control·Shift 넷이다. 수식키가 하나 더 많다는 것은 단축키를 배치할 공간에 그만큼 여유가 있다는 뜻이기도 하다(OS가 점유하는 윈도우 키나 Globe/Fn 키는 제외한 계산이다).
표기 관습도 다르다. 애플은 키와 메뉴에서 기호에 크게 의존하지만 일관적이지는 않다. 반면 윈도우는 단어를 쓰며 공간이 부족하면 Ctrl, Bkspc, PrtSc, Del, PgUp 같은 축약형을 쓴다. 독일에서는 Ctrl이 Strg로 번역돼 표기되기도 한다. 메뉴에서 조합을 나타낼 때 윈도우는 플러스 기호로 잇지만 애플은 기호를 그냥 붙여 쓴다. 그래서 '윈도우에서 ⌃V가 붙여넣기'라는 식의 표현은 실제로는 쓰지 않는다. 흥미롭게도 애플은 과거 전맥 호환성을 노리던 1980~2000년대에 자사 키보드에 Insert, Del, Print Screen 같은 PC식 표기를 넣기도 했다.
텍스트 입력 영역의 지뢰밭
실무적으로 가장 주의해야 할 지점은 텍스트 필드다. 맥은 ⌥(Option)과 문자 키를 조합하면 특수문자를 출력하는 체계를 갖고 있다. ⌥Q는 œ, ⌥7은 ¶를 내고, ⇧를 더하면 Œ나 ‡ 같은 문자가 나온다. 문제는 이 할당이 키보드 레이아웃(지역)마다 다르다는 점이다. 그래서 텍스트 필드 안에서 ⌥ 기반 단축키를 쓰면 중요한 문자 입력과 충돌할 위험이 크므로 피하는 편이 안전하다. 윈도우에도 비슷한 함정이 있다. 많은 비(非)미국 키보드에서 오른쪽 Alt는 AltGr로 작동해 각 언어에 필요한 글자를 출력한다. 폴란드어에서 AltGr+A는 ą가 되는 식이다. AltGr 키가 없어도 Ctrl+Alt 조합으로 같은 입력을 할 수 있기 때문에, 윈도우에서는 Ctrl+Alt 기반 단축키 역시 조심해야 한다.
문자 입력을 위한 보조 기능도 서로 다르다. 윈도우는 Alt+숫자패드로 문자 코드를 직접 입력할 수 있고(Num Lock 필요, Alt+0128이 €), 맥은 Unicode Hex Input 키보드를 추가해 전환한 뒤 ⌥20AC로 €를 낸다. 맥은 또 아이폰처럼 키를 길게 눌러 악센트 문자를 띄우는 방식을 지원하지만 윈도우에는 없다.
커서 이동과 단축키의 미묘한 차이
동작의 차이도 곳곳에 있다. 맥의 텍스트 필드는 유닉스/리눅스 계열의 Control 기반 단축키 일부를 지원하며 ⇧와 조합해 선택을 확장할 수 있다. 단순 입력 필드에서는 ↑↓가 줄의 처음과 끝으로 이동하는데, 이는 명령행 히스토리나 자동완성 팝업과 자주 충돌한다. 윈도우에는 이 관습이 없고 Home·End가 그 역할을 맡는다. 다시 실행은 맥에서 ⌘⇧Z, 윈도우에서 Ctrl+Y가 일반적이고, 새로고침은 맥의 ⌘R에 대응해 윈도우는 전통적으로 F5지만 함수 키 접근이 번거로워지면서 Ctrl+R을 지원하는 브라우저도 늘고 있다. Tab 이동 역시 윈도우는 모든 요소를 순회하지만 맥은 기본적으로 입력이 필요한 요소로만 이동하며, 시스템 설정에서 윈도우식 동작으로 바꿀 수 있으나 모든 곳에서 잘 지원되지는 않는다.
웹 앱 개발자가 특히 유념할 점은 단축키 선점 경쟁이다. 웹 앱은 OS뿐 아니라 브라우저 자체와도 단축키를 두고 경쟁한다. ⌘S나 ⌘P는 대개 가로챌 수 있지만, 어떤 맥 브라우저도 ⌘Q·⌘W·⌘T는 웹사이트에 내주지 않으며 사파리는 ⌘R를, 아크 브라우저는 ⌘⇧C를 넘겨주지 않는다. 결국 이 정리가 던지는 실무적 메시지는 분명하다. 크로스플랫폼 단축키를 설계할 때는 명칭을 플랫폼과 함께 명시하고, 텍스트 입력 영역에서는 문자 조합과 충돌하는 수식키를 피하며, OS·브라우저가 이미 점유한 조합은 애초에 넘보지 말아야 한다는 것이다. 다만 이 목록은 저자 스스로 밝히듯 완전하지 않고, 지역별 레이아웃이나 앱별 예외까지 모두 담지는 못한다는 한계가 있으므로 실제 대상 환경에서의 검증은 여전히 개발자의 몫이다.