요약
윈도에서만 생긴 Figma 단축키 버그는 1981년 IBM PC 키보드의 설계에서 비롯됐습니다.
Figma 직원이던 마르친 비하리가 2021년 회사 트위터 계정을 하루 맡아 올린 스레드를 옮긴 글입니다. 키보드 역사책을 준비하던 그는 2019년에 들어온 버그 신고의 뿌리를 수십 년 전 IBM 키보드에서 찾아냈습니다.
왜 중요한가
- 운영체제마다 다르게 동작하는 오류가 실은 오래된 관례를 지키려는 호환성 때문일 수 있음을 보여 줍니다.
- 근육 기억(손에 익은 조작 습관)을 지키려고 남긴 기능이 원래 이유가 사라진 뒤에도 수십 년 동안 살아남았습니다.
핵심 내용
- 윈도에서 숫자 키패드로 누른 Shift+2가 아래 화살표로 읽혀 Figma의 선택 영역 확대 단축키가 먹히지 않았습니다.
- 화살표 키를 숫자 키패드에 겹친 1981년 IBM PC는 Shift를 누르는 동안 Num Lock 모드를 잠깐 뒤집게 했습니다.
- 화살표 키가 따로 생긴 Model M 이후에도 이 규칙은 남았고, MS-DOS를 거쳐 윈도 1.0부터 10까지 이어졌습니다.
- 첫 맥에는 화살표 키와 숫자 키패드가 없었고, 1987년에 둘이 따로 추가돼 Num Lock이 필요 없었습니다.
- 브라우저가 두 입력을 구분할 정보를 주게 되자 Figma는 버그를 고쳤지만, 글쓴이는 애초에 버그가 아니었다고 봤습니다.
HN 반응
- 운영체제마다 결과가 다르면 역사와 상관없이 버그라는 지적에, 사용자가 실제로 누른 것은 키패드의 Shift+아래 화살표였다는 반박이 나왔습니다.
- Shift로 모드를 뒤집는 방식이 기발하다기보다 헷갈린다는 의견과, 첫 맥의 작은 키보드 배열이 요즘 애호가들에게 인기라는 관찰도 있었습니다.
누군가에게는 "기발한" 것이 다른 누군가에게는 "불분명해서 헷갈리는" 것일 수 있습니다. numlock도 아닌 키를 눌렀는데 숫자 패드가 예상한 모드와 다르게 동작한다면, 저는 "우와, 정말 영리하네"라고 생각하지 않을 겁니다. 무슨 일이 일어났는지 몰라 어리둥절할 테고, 그 이상한 동작만 보고 그 기능을 어떻게 쓰는지도 아마 이해하지 못할 겁니다.
우리 상상 속의 피그마(Figma)였나 보네요.
살면서 웹사이트가 핀치 줌을 가로채는 건 처음 겪어 봤어요. 사진 위에서만 핀치 줌이 안 됐는데, 이미지가 먼저 확대된 다음에 그 안에서 또 확대되더라고요.
작성자는 대체 왜 그렇게 만들었을까요? 너무 짜증 나요.
사실 그런 웹사이트가 꽤 많아요. 그래서 안드로이드용 Firefox에는 접근성 설정에 항상 확대 허용 토글이 있는 거고요.
저는 안드로이드의 Firefox에서 잘 되는데요.
윈도 FF에서는 안 돼요.
돌이켜 보면 초대 맥의 키보드가 의도적으로 60% 배열이었다는 점이 흥미롭습니다. 지난 15년 사이 애호가들 사이에서 그 크기가 그만큼 인기를 끌었으니까요(물론 요즘은 완전히 커스터마이즈할 수 있는 보조 레이어가 더해져서 방향키 같은 것도 여전히 쓸 수 있지만요).
정말 좋았어요!
죄송하지만, 70~80년대에 IBM이 키보드로 뭘 했든 상관없어요. Shift+2가 윈도에서 숫자 패드를 쓰는 사용자만 빼고 모두에게 줌을 바꾸는 거라면 그건 버그예요. 기대를 어기는 동작이고, OS마다 다르잖아요.
그리고 이 글쓰기 방식은 대체 뭔가요? 문장마다 번호가 매겨져 있고 트윗하기 옵션이 붙어 있고, 문장 사이사이에 엄청난 여백을 둔 가로줄이 있고, 문장마다 이미지가 한두 장씩 끼어 있어요. 이게 사람이 읽으라고 만든 게 맞기는 한가요?
첫 문단에 나와 있듯이 트위터 스레드를 보관한 사본이에요.
그런데 윈도 사용자는 Shift+2를 누른 게 아니라 Shift+아래 방향키를 눌렀어요. 스레드에 그렇게 나와 있잖아요.