브라우저 확장 프로그램은 종종 '있으면 좋은 것'으로 취급된다. 하지만 최근 dev.to에 올라온 두 개의 빌드 로그—뉴스 리더 Margin과 탭 세션 관리 도구 Tab Session Saver—를 읽으면서 다른 생각이 들었다. 이 두 프로젝트는 기술 구현 이야기이기 전에, 사용자 문제를 어떻게 정의하고 어떤 제약 속에서 UX를 설계했는지를 보여주는 프로덕트 사고의 사례에 가깝다.
문제 정의가 스택 선택보다 먼저다
Margin의 개발자 Mohan이 Side Panel API를 선택한 이유는 단순하다. 뉴스는 '탭을 열고 읽는' 흐름이 아니라, '지금 하던 일 옆에 붙여두고 잠깐 훑는' 흐름에 더 맞는다고 판단했기 때문이다. 크롬이 MV3에서 chrome.sidePanel을 내놓았을 때, 대부분의 개발자가 번역기나 메모 도구에 활용할 때, 그는 콘텐츠 소비 시나리오를 가져왔다. 플랫폼 API의 용도를 다르게 읽는 것—이것 자체가 프로덕트 사고다.
Tab Session Saver의 Paolo는 다른 시작점에서 출발했다. 탭이 30개, 40개, 100개씩 쌓이다 보니 크롬을 닫는 게 두려워졌다. 이 '닫기 버튼 공포증'이라는 아주 구체적이고 개인적인 문제가 프로젝트의 출발이었다. 해결책도 그만큼 명확하다. 한 번의 클릭으로 저장하고, 한 번의 클릭으로 복원하고, 복원 전에 내용을 미리 볼 수 있게 한다. 기능 목록이 아니라 사용자 여정의 불안 지점을 먼저 짚은 설계다.
MV3 제약이 UX를 만든다
기술 제약이 오히려 더 나은 UX를 만드는 역설이 있다. Margin 개발 과정에서 가장 인상적인 부분은 chrome.sidePanel.open()이 사용자 제스처 없이는 호출될 수 없다는 제약을 처리한 방식이다. 설치 직후 패널을 자동으로 열고 싶었지만 크롬이 이를 허용하지 않는다. 이 한 줄의 플랫폼 규칙이 온보딩 전체를 다시 설계하게 만들었다.
해결 방식은 두 단계다. 설치 시 별도 탭을 열어 '아이콘 찾기 → 핀 고정 → 패널 열기'를 안내하고, 해당 페이지의 버튼 클릭이 제스처가 된다. 패널이 처음 열리면 인-패널 웰컴 스크린이 다시 한번 핀 고정을 유도한다. 제약을 우회한 게 아니라 제약 안에서 사용자가 자연스럽게 다음 단계로 이동하는 흐름을 설계한 것이다. 이런 결정은 코드 한 줄보다 '사용자가 처음 이 제품을 만나는 순간'을 먼저 생각했을 때 나온다.
스와이프 인터랙션에서도 비슷한 태도가 보인다. 트랙패드의 빠른 스와이프가 여러 개의 스크롤 이벤트를 연속으로 발생시켜 카드를 두세 장씩 건너뛰는 문제가 있었다. 처음에는 가속도 변화로 제스처를 구분하는 복잡한 휴리스틱을 만들었지만, 결국 버렸다. 스크롤 이벤트 사이의 유휴 간격을 감지하고 방향 전환을 새 제스처로 처리하는 단순한 방식이 더 예측 가능했기 때문이다. '더 영리한 알고리즘'보다 '더 예측 가능한 동작'을 선택한 것—이 판단이 UX 설계에서 자주 놓치는 지점이다.
프라이버시는 제거로 설계한다
두 프로젝트 모두 백엔드가 없다. Margin은 RSS 피드와 기사 페이지를 사용자의 기기에서 직접 퍼블리셔에 요청하고, 설정과 캐시는 chrome.storage.local에만 저장한다. Tab Session Saver 역시 계정도, 클라우드도, 분석 도구도 없이 모든 데이터를 로컬에 둔다. 프라이버시를 '추가하는' 것이 아니라 데이터가 흘러나갈 경로를 처음부터 만들지 않는 설계다.
Margin에서 특히 흥미로운 지점은 온디바이스 AI 요약 기능이다. 크롬의 내장 Summarizer API(Gemini Nano)를 활용해 기사 텍스트가 브라우저 밖으로 나가지 않는다. 그런데 이 기능을 기본으로 켜두면 모델이 아직 준비되지 않은 기기에서 오류가 발생한다. 해결책은 auto | on | off 삼중 상태 설계였다. auto는 기기 지원 여부를 조용히 확인한 뒤 요약을 활성화한다. 사용자에게 불필요한 오류를 노출하지 않으면서 기능을 점진적으로 켜는 방식—이것이 온디바이스 AI를 UI에 붙일 때 필요한 설계 패턴이다.
작게 시작하되, 다음 질문을 준비해두라
Tab Session Saver는 현재 약 250명의 사용자가 쓰고 있다. 작은 숫자지만 개발자는 이미 다음 단계를 묻고 있다. 세션 검색, 태그, 선택적 클라우드 동기화, 공유 워크스페이스. 이 목록이 흥미로운 이유는 기능 나열이 아니기 때문이다. 로컬 우선이라는 현재 원칙을 유지하면서 어느 지점에서 협업과 접근성을 위해 클라우드를 허용할 것인가—이 긴장이 이미 설계 안에 들어와 있다.
두 사례가 함께 가리키는 방향은 명확하다. Chrome 확장은 작은 UI 표면이지만, 그 안에서도 사용자 문제 정의 → 플랫폼 제약 해석 → 점진적 기능 설계라는 프로덕트 사이클이 그대로 작동한다. MV3가 제한을 걸어도, 온디바이스 AI가 기기마다 다른 지원 상태를 가져도, 해결 방향은 결국 '사용자가 이 순간 무엇을 경험하는가'로 돌아온다. 기술 스택은 그 다음 질문이다.