북마크 바 vs. 사이드바 vs. 시작 페이지 대시보드: Chrome의 작동 방식에 실제로 맞는 것은

이 제품을 만들기 시작했을 때 세 가지 UI 패러다임을 모두 선택할 수 있었고, 저는 그중 가장 평범한 것을 골랐습니다. 이 글은 그 이유를 기능 목록 대신 실제 인터랙션 비용 계산으로 설명합니다. “평범함”은 상상력 부족이 아니라 실제 트레이드오프 분석 끝에 나온 의도적인 결론이었기 때문입니다.

시장에 나와 있는 북마크 도구는 — 예외 없이 전부 — 세 가지 형태 중 하나를 선택합니다. 페이지 위에 자리 잡는 바. 페이지 옆에 자리 잡는 사이드바. 새 탭 페이지를 대체하고 사용자가 방문하기를 기다리는 대시보드. 이 셋을 섞어 쓰는 도구는 없습니다. 이 형태는 도구를 쓸 때의 느낌 거의 전부를 좌우하는 근본적인 결정이기 때문입니다. 그러니 이걸 단순한 스킨 선택으로 취급하지 말고, 어떤 형태가 어떤 작업에 맞는지 실제로 따져볼 가치가 있습니다.

세 가지 패러다임

바(Row) — 항상 보이고, 컨텍스트 전환이 없음. Chrome 자체 북마크 바가 바로 이 형태이고, 두 번째 바도 마찬가지입니다. 지금 보고 있는 페이지 위에 항상 자리 잡고 있으며, 그 순간에 사용하든 안 하든 세로 공간을 고정된 만큼 차지합니다.

사이드바(Sidebar) — 상시 노출 패널, 페이지 형태를 바꿈. 콘텐츠 옆에 자리 잡는 세로 패널입니다. 북마크 관리자를 브라우징 화면 옆에 고정해서 열어둔 모습을 떠올리면 됩니다. 바처럼 항상 사용할 수 있지만, 세로가 아니라 가로 공간을 차지하기 때문에 아래에 있는 페이지가 짧아지는 게 아니라 좁아집니다.

대시보드(Dashboard) — 방문해야 하는 목적지. 저장한 링크, 폴더, 세션을 보여주는 시작 페이지 혹은 새 탭 화면입니다. 앞의 둘과 달리 브라우징 중에는 존재하지 않습니다 — 그곳으로 이동해서 사용하고, 다시 다른 곳으로 이동합니다.

이 카테고리의 비교 글 대부분은 곧장 기능 표로 넘어갑니다 — 검색, 태그, 폴더, 동기화에 체크 표시를 매기며, 마치 도구의 형태는 중립적인 그릇이고 기능이 전부인 것처럼 다룹니다. 하지만 그렇지 않습니다. 형태는 도구가 언제 방해가 되고 언제 눈에 띄지 않는지, 그리고 도구는 전혀 신경 쓰지 않고 그저 페이지로 돌아가려는 아흔아홉 번의 검색에서 얼마의 비용을 치르게 되는지를 좌우합니다. 그게 실제로 짚고 넘어갈 가치가 있는 부분입니다.

인터랙션 비용 분석

이걸 정직하게 비교하는 방법은 기능 목록이 아니라, 세 가지 순간 — 저장할 때, 다시 찾을 때, 아예 쓰지 않을 때 — 각각에서 무엇을 치르게 되는지 보는 것입니다.

저장 비용. 바와 사이드바는 이미 화면에 떠 있으니, 저장은 어디로도 이동하지 않고 드래그나 클릭 한 번으로 끝납니다. 대시보드는 새 탭을 열거나(탭을 복제하지 않는 한 지금 보던 탭을 잃습니다), 뒤에서 대시보드의 데이터 저장소에 기록되는 별도 저장 방식을 써야 합니다 — 동작과 결과 사이에 층이 하나 더 끼어드는 셈입니다.

검색 비용. 세 패러다임이 가장 크게 갈리는 지점입니다. 바는 눈길 한 번, 클릭 한 번이면 끝 — 이동이 전혀 없습니다. 사이드바도 비슷하지만, 이미 화면 너비를 차지하고 있으니 이미 보이는 상태이거나 토글 한 번이면 됩니다. 대시보드는 새 탭을 열고, 렌더링을 기다리고, 원하는 걸 찾은 뒤, 거기서 바로 열거나(지금 탭의 맥락을 잃습니다) 링크를 복사해 돌아와야 합니다. 대시보드에서의 검색은 매번 작은 왕복 여정입니다.

쓰지 않을 때의 비용. 사람들이 가장 과소평가하는 부분입니다. 바는 보고 있든 아니든 항상 고정된 세로 공간을 차지하지만, 그 비용은 작고 예측 가능하며 페이지 자체의 레이아웃과 부딪히지 않습니다. 사이드바는 실제 가로 공간을 계속 차지하는데, 넓은 데스크톱 모니터보다 좁은 화면이라면 지금 읽고 있는 페이지의 실제 콘텐츠가 눈에 띄게 좁아지고, 전체 뷰포트 너비를 가정하고 만든 반응형 레이아웃을 시각적으로 깨뜨릴 수도 있습니다. 대시보드는 쓰지 않는 동안에는 비용이 전혀 없습니다 — 애초에 그곳에 가 있지 않기 때문입니다. 이건 대시보드의 실질적인 강점이고, 대시보드가 구조적으로 이기는 유일한 지점입니다.

Chrome이 직접 바를 선택한 이유

이건 우연이 아닙니다. 바는 브라우저 크롬(chrome, 브라우저 자체의 UI 틀)이 이미 작동하는 결에 맞습니다 — Chrome 자체 북마크 바도 바고, 탭 스트립도 바고, 주소창도 바입니다. 이 패턴 위에 두 번째 바를 얹는 건 덧붙이는 방식일 뿐, 사이드바처럼 브라우저의 기존 시각 언어와 부딪히지 않습니다. 사이드바는 “어느 쪽에, 얼마나 넓게, 열었을 때 페이지 자체 레이아웃은 어떻게 되는가”라는 질문에 답해야 하지만, 바는 그런 질문을 애초에 할 필요가 없기 때문입니다.

사이드바를 정직하게 구현하려면 페이지에서 실제 너비를 떼어와야 합니다. 넓은 데스크톱 모니터에서는 사소한 세금 정도지만, 흔한 13~14인치대 노트북이나 작은 화면에서 창을 최대화한 경우라면, 고정된 픽셀 수를 계속 차지하는 사이드바가 웹 앱의 반응형 브레이크포인트를 사이트 제작자가 테스트해본 적 없는 옹색한 상태로 밀어붙일 수 있습니다 — 버튼이 이상하게 줄바꿈되고, 열이 예상보다 일찍 무너지고, 실제로 주어진 것보다 더 넓은 공간을 가정한 레이아웃이 깨지는 식으로요.

제가 매일 쓰는 동일한 웹 앱들을 대상으로 사이드바형 확장 프로그램을 직접 테스트하면서 이런 일을 목격했습니다. 뷰포트가 줄었다고 착각해 자체 사이드바를 아이콘 전용 모드로 접어버리는 프로젝트 관리 보드, 원래 의도하지 않은 방식으로 작성창을 쌓아 올리는 채팅 앱, 모바일 폭 툴바로 전환해버리는 문서 편집기 같은 사례들이었습니다. 이건 사이드바 확장 프로그램의 잘못이라고 딱 잘라 말할 수는 없습니다 — 광고한 만큼의 너비를 실제로 차지하고 있을 뿐이니까요 — 하지만 바 패러다임에서는 애초에 생기지 않는, 실재하고 눈에 보이는 비용입니다. 바는 페이지가 대체로 여유 있게 남겨두는 세로 높이를 가져갈 뿐, 페이지 자체의 레이아웃 로직이 적극적으로 계산하고 있는 가로 폭을 건드리지 않기 때문입니다.

각 패러다임이 정직하게 이기는 지점

그렇다고 바가 언제나 정답인 건 아닙니다. 바는 특정 작업에 맞는 정답이고, 나머지 둘은 각자 다른 작업에 맞는 정답입니다.

• 세션·프로젝트 인계에는 대시보드가 이깁니다. 정리하려는 게 “금요일 기준 프로젝트 X의 상태입니다” 같은 것 — 하나의 묶음으로 다시 열어보거나 동료에게 넘겨줄 탭 모음 — 이라면 목적지 기반인 대시보드 모델이 맞습니다. 하루에 링크 하나를 쉰 번 찾는 게 아니라, 컬렉션 하나를 한 번 여는 상황이니까요. Toby가 이 패턴을 완전히 중심에 두고 만들어진 가장 잘 알려진 도구입니다 — 이 모델이 어디에 유용하고 어디에는 그렇지 않은지는 Toby에 대한 정직한 비교를 참고하세요.
• 레퍼런스 위주의 단일 모니터 작업에는 사이드바가 이깁니다. 열려 있는 탭 열 몇 개를 계속 문서와 대조하는 작업이라면, 컨텍스트를 바꾸지 않고 목록을 작업 옆에 띄워두는 게 그만큼의 너비를 지불할 가치가 있을 수 있습니다 — 특히 너비가 부족하지 않은 충분히 넓은 모니터에서는요.
• 고빈도 검색에는 바가 이깁니다. 실제 패턴이 지원 큐, CRM, 문서 사이트, 디자인 툴처럼 같은 서른 곳을 하루에도 수십 번씩 오가는 것이라면, 바의 거의 제로에 가까운 검색 비용이 누적되어 큰 차이를 만듭니다. 하루 쉰 번의 검색을 거의 비용 없이 하는 쪽이, 매번 사이드바의 지속적인 너비 세금이나 대시보드의 왕복 비용을 치르는 쪽보다 낫습니다.

Second Bookmark Bar가 바를 구현하는 방식

이런 근거로 볼 때 바는 기본값이라서가 아니라 의도적으로 선택한 결과입니다. Second Bookmark Bar는 격리된 iframe 렌더러와, 메뉴·팝업용 상위 오버레이 레이어를 이용해 페이지 위에 두 번째의 컴팩트한 바를 추가합니다 — 그리고 최신 앱 셸 레이아웃에서 자체 공간을 신중하게 확보해서, 채팅 앱의 전송 버튼이나 대시보드 자체의 하단 툴바 같은 요소가 그 아래로 밀려나 화면 밖으로 사라지지 않게 합니다. “그냥 위에 떠 있는 게 아니라 공간을 확보한다”는 이 디테일은 듣기보다 중요합니다. 단순한 오버레이 방식이었다면, 사이드바가 이미 골머리를 앓는 것과 똑같은 종류의 앱 셸 레이아웃과 충돌했을 것입니다.

다만 이 공간 확보 디테일은 렌더링 비용을 해결할 뿐, 검색 비용을 해결하지는 않습니다. 고정된 바에는 위 인터랙션 계산이 포착하지 못한 잔여 비용이 하나 있습니다. 실제로 있는 사이트에 맞지 않는 폴더를 보여줘서, 클릭 한 번이던 검색을 폴더 전환 + 검색으로 바꿔버리는 경우입니다. 두 가지 장치가 바의 비용을 표에 나온 “클릭 한 번”보다 더 낮게 끌어내립니다. 자동 전환(Auto-Switch)은 현재 사이트에 매핑해둔 폴더로 바를 바꿔주는데, 작동했을 때는 슬롯 전환기에 별표가 뜨고 언제든 직접 재정의할 수 있습니다 — 그래서 눈을 들어 확인하기도 전에 알맞은 폴더가 이미 떠 있는 경우가 많습니다. 그리고 “어딘가에 있는데” 하는 놓친 경우는, 위 표에서 대시보드의 비용이던 북마크 관리자 왕복 대신 — 하필 가장 원치 않는 순간에 치러야 하는 그 비용 대신 — 지금 있는 페이지에서 바로 열리는 바 내 검색 패널이 처리합니다. 결과는 폴더와 도메인으로 라벨이 붙습니다.

정직하게 밝혀둘 한계도 있습니다. 나중에 발견하시는 것보다 미리 말씀드리는 게 낫겠죠. Chrome 확장 프로그램은 chrome:// 페이지나 Chrome Web Store 자체에는 바든 사이드바든 어떤 UI도 주입할 수 없습니다. 이건 이 확장 프로그램만의 문제가 아니라 Chrome 플랫폼 자체의 제약이고, 이 글에서 비교한 모든 북마크 도구에 똑같이 적용됩니다. 그런 페이지에서는 Chrome 자체의 단일 바로 돌아가게 됩니다.

북마크 습관이 “매일, 하루 종일 같은 서른 곳”에 가깝다면, 바가 분위기가 아니라 실제 계산으로 이깁니다. “프로젝트를 정리해서 넘긴다”에 가깝다면, 대시보드가 다른 질문에 맞는 제대로 된 일을 하고 있는 겁니다. 같은 프레임워크 안에서 Raindrop 같은 라이브러리형 도구가 어디에 맞는지, 그리고 바를 아예 보이지 않게 하고 싶은 순간을 위한 제외 사이트와 빠른 숨김 기능이 바 모델을 어떻게 보완하는지도 확인해볼 만합니다. 그리고 바를 고려하기도 전에 Chrome이 이미 기본으로 제공하는 모든 방법으로 북마크에 도달하는 클릭·이동 비용까지 똑같이 정직하게 따져보고 싶다면, 그 내역을 숫자로 정리한 글이 있습니다.

같은 논리를 Raindrop, Toby, Chrome 기본 기능 등 도구 이름별로 정리한 표는 나란히 비교하는 페이지들에서 확인할 수 있습니다.