키보드로 달력을 움직인다

데스크탑 앱은 마우스로 다 됩니다. 달력에서 날짜 선택, 일정 생성, 오늘로 돌아오기 — 모두 클릭 한 번이면 됩니다. 동작이 막히는 건 아닙니다.

그런데 같은 동작을 하루에 여러 번 반복하다 보면 클릭이 길어지는 게 느껴집니다. “오늘로” 버튼 위치를 한 번 찾고, 마우스 움직이고, 누르고, 다시 다른 데로 옮기고. 짧지만 끊깁니다.

데스크탑에서는 키보드가 더 빠를 때가 있습니다.

무엇을 단축키로

전부 다 단축키로 만드는 건 좋은 생각이 아닙니다. 외워야 할 게 늘어나면 결국 쓰지 않습니다. 정말 자주 쓰는 것만 선별했습니다.

• N — 새 일정 생성
• G — 템플릿에서 생성
• T — 오늘로 이동
• ←→↑↓ — 선택한 날짜 이동 (월간뷰: 좌우=하루, 상하=일주일)
• Enter — 선택한 날짜의 상세 보기

이 정도가 한 손으로 외울 만한 분량이고, 달력에서 가장 자주 하는 동작들입니다.

새는 키 막기

단축키를 붙이고 가장 먼저 한 일은 가드를 세우는 것이었습니다.

문제 상황은 뻔합니다. 사용자가 모달을 열고 안에 있는 입력창에 글자를 치는 중인데, “n”을 누르면 달력의 단축키가 발동해서 또 다른 모달이 뜨는 식. 또는 필터 모달의 키워드 입력란에서 ←→ 누르면 커서가 글자 사이를 움직여야 하는데 달력이 다른 날로 점프해 버리는 식.

그래서 핸들러 가장 위에 가드를 두 개 두었습니다. 첫째, 활성 요소가 입력창이거나 편집 가능한 영역이면 무시. 둘째, 어떤 모달이라도 열려 있으면 무시. 단축키는 달력 자체에 포커스가 있는 일반 상태에서만 동작합니다.

이 가드 한 번을 빼먹어서 한참 헤맨 적이 있는 다른 페이지가 떠올라서, 이번엔 처음부터 넣었습니다.

미묘한 점프

다 됐다 싶었는데, 한 가지가 이상했습니다. 5월에서 ←→로 옆날짜를 옮길 때마다 달력이 다음 달로 슥 스크롤됐습니다. 같은 5월 안에서 움직이는데도.

처음엔 “월 경계를 넘으면 그 달로 스크롤한다”는 의도된 동작이 너무 공격적인 줄 알았습니다. 5월 31일에서 →를 누르면 6월 1일이 되고, 그러면 6월로 스크롤되는 게 맞으니까요. 그런데 5월 15일에서 →를 눌러도 같은 일이 벌어졌습니다.

코드를 다시 봤습니다. “현재 보이는 달의 인덱스”와 “다음 날짜의 달 인덱스”를 비교하는 부분이 있었습니다. 그런데 한쪽은 0부터 시작하는 인덱스(JavaScript의 getMonth() 방식), 다른 쪽은 1부터 시작하는 인덱스로 다루고 있었습니다. 그래서 5월(인덱스 4) 안에서 움직이는데도 비교 결과가 항상 “다른 달”로 나왔고, 매번 스크롤이 발동했습니다.

월을 표현하는 방식이 코드 전체에 일관되지 않은 곳이 종종 있었던 게 화근이었습니다. 0부터 셀 때도 있고 1부터 셀 때도 있고. 이번처럼 한 줄에서 두 방식을 섞으면 사라지지 않는 미묘한 어긋남이 생깁니다.

비교 한쪽의 -1과 다른 한쪽의 +1을 빼니 의도대로 동작했습니다. 5월 안에서는 가만히 있고, 6월로 넘어가는 순간에만 스크롤됩니다.

작은 변화의 큰 차이

키보드 네비게이션을 붙이고 나서 달력에서 보내는 시간이 달라졌습니다.

오늘 한 일을 빠르게 훑어볼 때, 클릭으로 돌아다니던 흐름이 키 몇 번으로 줄었습니다. T 한 번 누르면 오늘이고, ←를 두 번 누르면 그저께 일정이 보입니다. 마우스를 옮길 필요가 없으니 시선이 달력 안에 머무릅니다.

데스크탑에서 자주 쓰는 페이지에 단축키 너댓 개. 외울 만한 양이고, 한번 손에 익으면 마우스 동작 수백 번을 줄여줍니다. 큰 기능을 만들지 않아도 흐름은 충분히 부드러워집니다.