사이드바를 위로 옮기다

데스크탑 앱의 첫 버전은 왼쪽에 사이드바가 있었습니다. 다섯 개 탭이 세로로 나란히. 모바일의 하단 탭바를 그대로 회전시킨 모양이었습니다.

당장 동작하는 데는 문제가 없었습니다. 하지만 며칠 쓰다 보니 어색함이 쌓였습니다. 사이드바가 가로 폭을 차지하는데, 데스크탑 화면에서 가로는 가장 귀한 자원입니다. 그리고 데스크탑 사용자들은 보통 위쪽에서 메뉴를 찾습니다 — 운영체제, 브라우저, 거의 모든 데스크탑 앱이 그렇게 생겼으니까요.

모바일에서 잘 통하던 패턴이 데스크탑에서는 어긋납니다.

위로 올리는 일

탭을 위로 옮기는 결정 자체는 단순했습니다. 화면 상단에 가로로 긴 바를 두고, 거기에 로고와 다섯 개 탭을 배치하면 됩니다. 사이드바를 빼니 본 콘텐츠가 가로로 더 넓어졌습니다.

하지만 이걸 하면서 한 가지 더 풀어야 할 문제가 떠올랐습니다. 사이드바 시절, 각 페이지에는 자기만의 보조 메뉴가 있었습니다. 달력 페이지에는 “루틴 관리”, “회고 보기” 같은 메뉴가 있고, 라이브러리에는 “정렬”, “필터” 같은 게 있었습니다. 사이드바가 사라지면 이 메뉴들은 어디로 가야 할까요.

페이지가 자기 메뉴를 들고 다닌다

전역 사이드바에 모든 페이지의 보조 메뉴를 다 모아 두는 방법도 있었습니다. 하지만 그렇게 하면 다른 페이지에 있을 때도 안 쓰는 메뉴가 항상 눈에 들어옵니다. 메뉴가 페이지의 맥락을 벗어나면 의미가 약해집니다.

그래서 페이지마다 자기 메뉴를 직접 들고 다니게 했습니다. 화면 상단 오른쪽 모서리에 햄버거 아이콘을 두고, 누르면 그 페이지가 등록한 메뉴가 떠오릅니다. 달력 페이지에 있을 땐 달력의 메뉴가, 라이브러리에 있을 땐 라이브러리의 메뉴가 그 자리에 나타납니다.

페이지가 마운트될 때 자기 메뉴 정보를 전역 상태에 등록하고, 언마운트될 때 비웁니다. 상단 바는 그 상태를 그대로 읽어 렌더합니다. 코드가 단순해졌고, 새 페이지에 메뉴를 추가하는 비용도 한 줄로 줄었습니다.

이 패턴 덕분에 메뉴가 항상 자기 페이지 옆에 있습니다. 사용자가 어디 있는지에 따라 손에 닿는 메뉴가 달라집니다.

메뉴가 큰 영역으로 이어질 때

메뉴 항목 중에는 단순한 토글이나 짧은 액션도 있지만, “루틴 관리”나 “회고 모음”처럼 자기만의 화면이 통째로 필요한 것들도 있습니다.

이런 항목은 메뉴에서 누르면 풀스크린 오버레이가 떠오르도록 했습니다. 새 라우트로 이동하지 않습니다. 달력 위에 큰 모달이 덮이는 식으로 그 화면이 펼쳐지고, 닫으면 원래 달력으로 돌아옵니다.

이렇게 한 이유는 흐름의 연속성입니다. 사용자가 달력에서 “루틴 관리”를 잠깐 보고 닫는다면, 그건 달력 작업의 일부지 별도의 여행이 아닙니다. 라우트가 바뀌어 버리면 브라우저 뒤로가기 같은 동작이 어색해지고, 닫았을 때 원래 어디 있었는지 다시 찾아야 합니다. 오버레이는 그 맥락을 깨지 않습니다.

모바일을 키운 게 아니다

이 작업을 하면서 생각이 정리됐습니다. 데스크탑 버전은 모바일 앱을 더 큰 화면에 옮긴 게 아닙니다. 다른 환경, 다른 사용 패턴, 다른 관습입니다.

모바일에서는 엄지가 닿는 하단이 황금 자리입니다. 데스크탑에서는 시선이 위에서 아래로 흐릅니다. 모바일 화면은 세로가 길고, 데스크탑은 가로가 깁니다. 모바일 사용자는 한 손으로 잡고 들여다보고, 데스크탑 사용자는 멀찌감치서 키보드와 마우스로 다룹니다.

같은 코드베이스에서 시작했어도, 인터페이스의 결은 다르게 잡아야 합니다. 사이드바를 위로 올린 건 그 인식의 작은 출발점이었습니다. 이번 결정을 계기로, 데스크탑 버전 곳곳에서 “원래 모바일에서는 어땠지”가 아니라 “이 환경에서는 어떻게 두는 게 자연스러운지”를 먼저 묻기 시작했습니다.

같은 앱이지만, 손에 잡히는 감각은 다를 수밖에 없습니다.