Data/Backend/Frontend · 개인 프로젝트

ClipSpace

개인, 팀을 위한 온라인 클립보드

개인 클립은 로컬에 남기면서, 필요한 자료만 공유하려면?

프로젝트
ClipSpace
기간
2026.06
담당 역할
제품 설계 · Full Stack · 보안 경계 (1인 개발)

저장 경계

복사한 모든 내용을 서버로 보내지 않았습니다.

개인 클립은 브라우저에 남기고, 공유를 선택한 자료만 팀 보드로 보냈습니다.

01 · 기본값개인 클립

브라우저에만 저장 · 로그인 없이 시작

02 · 선택할 때팀 공유

사용자가 고른 자료만 서버로 전송

03 · 공유 경계API → Supabase

공유 데이터만 원격 저장

문제 상황

API key와 개인 메모까지 기본 동기화하면 저장 위치를 통제하기 어려웠습니다.

내가 바꾼 것

개인 저장과 팀 공유를 기본 동작부터 분리했습니다.

01 / 문제 정의

다시 찾으려고 반복 검색하던 링크·코드·메모에서 시작했습니다.

  • 01

    공부와 개발 중 복사한 링크, 코드, 메모와 이미지는 빠르게 흩어졌고, 다시 찾기 위해 같은 검색과 복사를 반복했습니다.

  • 02

    클립보드에는 API key나 비밀번호처럼 민감할 수 있는 문자열도 섞입니다. 동기화의 편의만 보고 모든 내용을 서버에 올리는 방식은 제품의 신뢰와 맞지 않았습니다.

  • 03

    개인 자료는 가볍게 시작하고, 협업할 자료만 명시적으로 팀 보드에 올리는 두 가지 사용 맥락을 한 화면 안에서 구분해야 했습니다.

기능보다 저장 경계를 먼저 정했습니다.
데이터의 성격에 따라 저장 경계를 나눴습니다공개 저장소 구현 기준
개인 보드

로그인 없이 브라우저 IndexedDB에 저장하고 기본 동작에서는 서버에 보내지 않습니다.

팀 보드

사용자가 공유를 선택한 데이터만 Next.js API를 거쳐 Supabase에 저장합니다.

민감 항목

정규식 기반으로 표시하고 저장 전 확인합니다. 오탐과 미탐이 가능한 보조 장치입니다.

02 / 내 결정

개인은 로컬에, 선택한 자료만 서버에

판단 기준

개인 보드는 IndexedDB에 저장하고, 팀 보드를 선택할 때만 서버(Supabase)를 사용했습니다. 민감정보 표시는 저장 전 판단을 돕는 장치로 두었습니다.

간단 아키텍처

개인 클립 · 서버 전송 없이 보관

  1. 01클립 입력개인 코드·메모·민감 정보
  2. 02IndexedDB브라우저 내부 저장소
  3. 03대시보드 / PiP작업 중 조회와 활용

팀 공유 · 검증된 요청만 저장

  1. 01공유 요청공유할 데이터
  2. 02Next.js APIShare Token 검증
  3. 03Supabase팀 공유 데이터 저장

03 / 해결 과정

개인 클립은 로컬에, 선택한 팀 자료만 서버에 두었습니다.

  1. 01

    로그인 없이 시작하는 개인 보드는 IndexedDB에 저장하고, 기본 동작에서는 저장된 클립을 서버로 전송하지 않습니다.

  2. 02

    팀 보드는 Next.js API를 서버 경계로 두고 Supabase와 연결했습니다. 공유 링크에는 보드 ID와 접근 키를 AES-256-GCM 토큰으로 감쌉니다.

  3. 03

    민감 문자열은 정규식으로 표시해 저장 전 확인하고, 이미지는 PNG·JPEG·WebP·GIF만 허용했습니다. 별도 살균이 필요한 SVG는 MVP 범위에서 제외했습니다.

  4. 04

    작업 중 바로 꺼내 쓰도록 Document Picture-in-Picture 미니 창을 제공하고, 미지원 환경에서는 작은 팝업 창으로 전환합니다.

구현 중 마주한 문제

편리한 동기화가 개인 클립까지 서버로 보내는 문제
발생한 상황

모든 보드에 같은 저장 방식을 적용하면 구현은 단순하지만, 민감한 복사 내용과 개인 메모도 사용자의 명시적 선택 없이 서버로 이동합니다.

바꾼 부분

개인 보드는 IndexedDB를 기본값으로 고정하고 팀 보드에서만 원격 API를 사용했습니다. 화면에도 현재 저장 위치와 공유 범위를 구분해 표시했습니다.

클립 하나의 수정이 팀 보드 전체 전송으로 이어지는 문제
발생한 상황

초기 동기화는 작은 변경에도 전체 보드와 이미지 데이터를 다시 전송해 데이터가 늘수록 비용과 충돌 위험이 커졌습니다.

바꾼 부분

변경·삭제 ID를 따로 추적해 증분 저장으로 바꾸고, 서버 변경과 미처리 로컬 변경이 함께 있을 때는 자동 덮어쓰지 않고 사용자가 갱신을 적용하도록 했습니다.

공유 링크의 사용 권한과 삭제 권한이 같아지는 문제
발생한 상황

팀원이 쓰는 공유 링크만으로 보드 삭제까지 허용하면 링크 유출의 피해 범위가 커집니다.

바꾼 부분

공유 토큰과 별개로 관리 PIN을 두고 scrypt 해시만 저장했습니다. PIN 확인 실패는 15분 동안 5회로 제한했으며, 분산 배포 전 공용 저장소로 옮겨야 한다는 한계를 남겼습니다.

04 / 회고

이 선택을 돌아보며.

신뢰는 저장 방식의 이름보다 저장 위치·공유 시점·복구 한계를 보여줄 때 생긴다고 배웠습니다.