Pickle을 만들며 고른 기술들 (01) - 작은 저장 문제에서 제품 구조까지

Pickle은 웹에서 본 문장, 링크, 북마크를 더 빨리 저장하고 싶다는 생각에서 시작했습니다. 그런데 만들다 보니, 진짜 문제는 저장보다 저장 이후에 더 많이 기다리고 있었습니다.

들어가며

Pickle은 브라우저에서 보고 있던 내용을 조금 더 쉽게 저장하고 다시 꺼내보기 위해 만든 사이드 프로젝트입니다. 서비스 소개만 놓고 보면 단순해 보일 수 있습니다. 웹에서 본 문장이나 링크를 저장하고, 나중에 다시 찾을 수 있게 만드는 일처럼 보이기 때문입니다.

저도 처음에는 그렇게 생각했습니다. 브라우저 익스텐션 하나를 만들고, 저장 버튼을 조금 더 편하게 만들면 어느 정도 해결될 문제라고 봤습니다.

그런데 실제로 만들고 나니 문제는 훨씬 넓었습니다. 저장은 시작일 뿐이었고, 그다음에는 정리, 검색, 동기화, 로그인 상태, 데이터 구조, 공개 웹과 실제 앱의 분리 같은 문제가 연달아 따라왔습니다.

이 글은 그 전체를 기술 문서처럼 설명하려는 글은 아닙니다. 오히려 Pickle이 어떤 불편에서 시작했고, 왜 단순한 익스텐션을 넘어서 여러 기술 선택을 하게 되었는지를 먼저 정리하는 시리즈의 첫 글에 가깝습니다.

시작은 저장 마찰을 줄이고 싶다는 생각이었습니다

웹에서 글을 읽다가 문장을 저장하고 싶을 때가 있습니다. 링크만 남기기에는 맥락이 너무 많이 사라지고, 메모 앱을 따로 열어 정리하기에는 흐름이 끊깁니다. 북마크를 눌러도, 나중에 왜 저장했는지 기억나지 않을 때가 많습니다.

이 불편은 작아 보이지만 꽤 자주 반복됩니다. 그리고 이런 종류의 마찰은 한 번 크게 불편하다기보다, 계속 쌓이면서 사람을 지치게 만듭니다.

Pickle은 그 지점을 줄이고 싶다는 생각에서 출발했습니다. 지금 보고 있는 문장이나 링크를 가능한 한 짧은 동선으로 저장하고, 나중에 다시 찾을 수 있게 만들고 싶었습니다.

처음 문제의식은 여기까지였습니다. 그래서 초반에는 "빠르게 저장할 수 있는 도구"에 더 가까웠습니다.

그런데 저장만 잘된다고 끝나는 문제는 아니었습니다

실제로 만들면서 가장 먼저 느낀 것은 저장 자체는 생각보다 빨리 구현된다는 점이었습니다. 진짜 어려운 부분은 그다음부터였습니다.

• 지금 보고 있는 페이지에서 바로 저장할 수 있어야 합니다.
• 나중에 저장한 내용을 다시 찾을 수 있어야 합니다.
• 단순 링크가 아니라 제목, URL, 북마크, 메모 같은 맥락이 같이 남아야 합니다.
• 한 기기에서 저장한 내용이 다른 기기에서도 이어져야 합니다.

여기서부터 프로젝트의 성격이 조금 바뀌었습니다. 처음에는 저장 버튼을 만드는 문제처럼 보였는데, 금방 저장 이후의 흐름을 관리하는 문제로 옮겨갔기 때문입니다.

예를 들어 저장된 데이터가 조금만 쌓여도 사용자는 다시 찾으려고 합니다. 그러면 검색이 필요해집니다. 저장된 내용을 기기와 환경을 넘어서 이어서 보려면 동기화가 필요합니다. 익스텐션에서 로그인한 상태가 웹에서도 자연스럽게 이어져야 한다면 인증 흐름도 다시 설계해야 합니다.

결국 Pickle은 "저장 기능" 하나로 설명하기 어려운 프로젝트가 되기 시작했습니다. 저장과 탐색, 인증과 동기화, 공개 웹과 실제 앱이 함께 움직여야 하는 구조로 바뀌었기 때문입니다.

그래서 브라우저 익스텐션 하나로는 설명이 부족해졌습니다

이 지점부터는 익스텐션만 잘 만든다고 해결되지 않았습니다.

• Pickle이 어떤 서비스인지 보여주는 공개 웹이 필요했습니다.
• 실제로 저장한 내용을 정리하고 찾는 클라이언트 앱이 필요했습니다.
• 브라우저 안에서 바로 저장을 시작하는 익스텐션이 필요했습니다.
• 그리고 이 셋이 같은 데이터와 같은 사용자 상태를 바라보게 해야 했습니다.

이 과정에서 Pickle은 단순한 저장 도구보다, "웹에서 저장한 내용을 다시 다루는 구조"에 가까워졌습니다. 그리고 저에게도 흥미로운 부분은 기능 추가보다, 그 구조를 어떤 기준으로 정리하게 되었는가였습니다.

구조는 자연스럽게 모노레포로 갔습니다

Pickle은 하나의 앱만 있는 프로젝트가 아니었습니다. 공개 웹은 Next.js 기반으로 두고, 실제로 저장한 내용을 정리하고 탐색하는 쪽은 별도 클라이언트 앱으로 운영했습니다. 저장을 시작하는 진입점은 브라우저 익스텐션이었고, 데이터 저장과 인증은 Supabase를 중심으로 붙어 있었습니다.

즉 처음부터 구조가 이렇게 나뉘어 있었습니다.

• 공개 웹
• 실제 클라이언트 앱
• 브라우저 익스텐션
• 공통으로 바라보는 데이터와 인증 계층

이 상태에서 모노레포를 택한 이유는 비교적 분명했습니다. 프로젝트 안에 Supabase, 익스텐션, 클라이언트가 함께 있었고, 이 셋이 같은 타입과 데이터를 공유하게 될 가능성이 처음부터 높았기 때문입니다. 그래서 시작 단계부터 "나중에 재사용이 필요해질 것"을 염두에 둔 구조를 택했습니다.

이 판단은 단순히 저장소를 보기 좋게 정리하려는 의도와는 조금 달랐습니다. 익스텐션과 클라이언트는 같은 Note, 같은 사용자 상태, 같은 워크스페이스 개념을 다루게 될 것이 분명했고, Supabase를 기준으로 데이터 구조도 함께 맞물릴 수밖에 없었습니다. 그렇다면 처음부터 코드를 흩어놓기보다, 공통으로 쓰일 타입과 스키마를 함께 관리할 수 있는 구조가 더 낫다고 봤습니다.

실제로 프로젝트가 커질수록 이 선택은 더 자연스러워졌습니다. 공개 웹, 실제 클라이언트 앱, 익스텐션이 각자 다른 역할을 갖고 움직이더라도, 아래에서는 같은 계약과 같은 데이터 모델을 바라보는 편이 훨씬 안정적이었기 때문입니다.

그래서 Pickle에서 모노레포는 나중에 따라붙은 정리 방식이 아니라, 초기에 재사용과 공통 관리를 염두에 두고 선택한 아키텍처에 더 가까웠습니다.

더 복잡했던 것은 기능보다 예외와 연결이었습니다

Pickle을 만들며 더 오래 붙잡고 있던 것은 화려한 기능보다 예외 상황이었습니다. 웹은 생각보다 단순하지 않았고, 저장 흐름도 한 군데에서만 끝나지 않았기 때문입니다.

iframe 안에서도 같은 경험을 줘야 했습니다

익스텐션은 사용자가 보고 있는 페이지 위에서 동작합니다. 그런데 웹은 생각보다 단순하지 않습니다. 네이버 블로그처럼 실제 콘텐츠가 iframe 안에 들어 있는 경우도 있고, 사용자가 어느 프레임에 포커스를 두고 있는지도 제각각입니다.

그래서 Pickle 익스텐션은 모든 프레임에서 이벤트를 감지하되, 오버레이 UI는 항상 최상위 프레임에서만 렌더링하도록 정리했습니다. 감지는 분산되고, 제어는 중앙에 모이는 구조입니다. 이런 종류의 결정은 겉으로는 작아 보이지만, 실제 사용감을 크게 좌우합니다.

인증은 기능보다 먼저 안전해야 했습니다

익스텐션에서 로그인한 상태를 웹 대시보드와 연결하는 문제도 비슷했습니다. 여기서는 해시 프래그먼트를 이용해 토큰을 넘기고, 클라이언트가 세션을 설정한 뒤 즉시 URL을 정리하는 방식을 택했습니다.

이런 설계는 화려해 보이지 않습니다. 하지만 실제 제품에서는 이런 종류의 안전장치가 먼저 있어야 합니다. "동작한다"보다 "어떤 경로로 전달되고 어디에서 정리되는가"를 설명할 수 있어야 하기 때문입니다.

검색은 결국 데이터 모델 문제였습니다

저장된 내용이 늘어나면 사용자는 반드시 다시 찾으려고 합니다. 이때 검색은 부가 기능이 아니라 핵심 흐름이 됩니다.

처음에는 제목이나 링크 기준으로만 찾아도 충분할 것처럼 보입니다. 하지만 실제로는 그렇지 않았습니다. 저장한 내용이 조금만 늘어나도, 사용자는 "무엇을 저장했는지"보다 "어떤 맥락에서 저장했는지"를 같이 떠올리며 찾게 되기 때문입니다.

그래서 검색은 나중에 덧붙이는 편의 기능이라기보다, 데이터가 쌓일수록 처음부터 다시 설계해야 하는 흐름에 가까웠습니다. Pickle을 만들며 저도 저장 서비스는 결국 탐색 서비스가 된다는 점을 계속 확인하게 되었습니다.

사이드 프로젝트라도 흐름을 진지하게 다루기 시작하면 기준이 달라집니다

Pickle을 만들면서 어느 순간부터는 기능 하나를 더 붙이는 일보다, 이 프로젝트를 계속 유지할 수 있는 상태를 만드는 일이 더 중요하다고 느끼게 됐습니다. 저장은 되는데 로그인 흐름이 어색하면 안 됐고, 화면은 뜨는데 검색이 느리면 안 됐고, 기능은 있는데 공개 웹과 실제 앱의 역할이 흐리면 설명하기 어려웠습니다.

그러다 보니 자연스럽게 몇 가지 기준이 남았습니다.

• 저장 순간보다 저장 이후의 흐름을 더 먼저 봐야 합니다.
• 표면이 여러 개로 늘어날수록 공통 데이터 계약이 중요해집니다.
• 웹에서는 예외를 우회하는 기술보다 예외를 설명 가능한 구조가 더 오래 갑니다.
• 사이드 프로젝트라도 사용자 흐름을 진지하게 다루기 시작하면, 제품과 크게 다르지 않은 문제를 만나게 됩니다.

이 기준이 생겼다고 해서 Pickle이 다 만들어졌다는 뜻은 아닙니다. 오히려 반대에 가깝습니다. 아직 손봐야 할 부분이 많기 때문에, 이제는 무엇을 먼저 판단해야 하는지가 이전보다 더 중요해졌다고 느끼고 있습니다.

마치며

Pickle은 처음부터 큰 제품을 만들겠다는 생각으로 시작한 프로젝트는 아니었습니다. 다만 작은 저장 문제를 계속 따라가다 보니, 자연스럽게 제품 구조와 운영 기준까지 생각하게 되었습니다.

지금 돌아보면 이 프로젝트가 남긴 가장 큰 배움은 기능 목록보다 흐름과 구조에 가깝습니다. 브라우저 익스텐션을 만든다고 생각했지만, 실제로는 저장, 동기화, 탐색, 권한, 배포를 하나의 흐름으로 묶는 법을 배우고 있었습니다.

아직 Pickle은 진행 중인 프로젝트입니다. 그래도 적어도 지금은 이렇게 말할 수 있습니다. 작은 문제에서 시작한 프로젝트라도, 사용자가 다시 돌아오는 흐름을 진지하게 다루기 시작하면 그 순간부터는 더 이상 작은 구조로 설명할 수 없게 됩니다.

이 시리즈에서는 여기서 한 걸음 더 들어가 보려고 합니다. 다음 글부터는 왜 모노레포를 택했는지, 브라우저 익스텐션은 왜 일반 웹 앱과 다른 구조가 필요했는지, 로그인과 세션을 어떻게 연결했는지, UI 격리와 디자인 시스템은 어떤 기준으로 정리했는지를 하나씩 나눠서 적을 생각입니다.

참고

• Pickle GitHub 저장소: 현재 저장소 구조와 제가 정리해 둔 구현 기록, 커밋 흐름을 함께 볼 수 있습니다.
• Pickle 크롬 웹스토어: 실제 배포된 익스텐션 페이지입니다.
• Pickle 랜딩 페이지: 현재 서비스 메시지와 공개 베타 페이지입니다.