사용자별 데이터 = 드라이브 연결 방식? Supabase와 비슷한가?

2026-07-27 · 개념 Q&A

Q. 현재 사용자별 데이터는 구글드라이브를 연결해서 적용하는 방식이라고 보면 되나? Supabase 데이터 연결하는 것과 비슷한 방식인가?

A. 절반은 맞다. "사용자별 데이터를 드라이브 연결로 적용한다"는 정확하고, 로그인하면 내 데이터가 계정을 따라다니는 사용자 경험은 Supabase를 붙인 것과 동일하다. 하지만 구조는 정반대다 — 중앙 DB가 아니라 각 사용자 소유의 저장소를 쓰는 BYO 스토리지 · 제로-DB 모델이다.

구조 비교

	Supabase 방식 (중앙 DB · BaaS)	현재 방식 (BYO 스토리지 · 제로-DB)
데이터 위치	운영자의 Postgres 프로젝트 한곳에 전체 사용자 데이터가 모임	각 사용자의 구글드라이브에 자기 데이터만 존재
운영자 열람	가능 (관리 권한)	불가능 — 서버·DB 없음, 토큰은 사용자 브라우저에만
운영 책임·비용	운영자 부담 (DB 요금·백업·보안·RLS)	0원 — 사용자 자신의 드라이브 용량 사용
데이터 형태	진짜 DB — 쿼리·인덱스·관계·서버 로직·실시간 push	JSON 파일 1개를 통째로 읽고 쓰는 파일 동기화 (쿼리 없음 · push 대신 폴링)
사용자 격리	운영자가 RLS 정책으로 구현해야 함	계정 격리가 구조적으로 자동 — 남의 드라이브 접근 자체가 불가

💡 비유 — Supabase는 "은행 금고": 모두의 데이터를 운영자 금고에 넣고 칸막이(RLS)로 나눈다. 현재 방식은 "각자 집 금고": 앱은 금고 여는 방법만 제공하고, 데이터는 처음부터 각자 집에만 있다.

어느 쪽이 맞는 선택인가

지금 서비스에는 현재 방식이 의도된 설계 — 개인 러닝 기록(1인 데이터·소량·기기 간 동기화)에 충분하고, 운영 비용과 개인정보 리스크가 0. "제로-DB 플랫폼"(운영 서버·DB 없이 사용자 저장소만 쓰는 구조)이 이 앱의 기본 원칙이다.
중앙 DB(Supabase 등)가 필요해지는 시점 — 사용자 간 상호작용이 생기는 순간: 랭킹·피드 공유, 크루 기능, 운영자 통계 대시보드 등. 각자의 드라이브만으로는 남의 데이터를 볼 수 없으므로 불가능한 기능들이다.
공존 가능 — 개인 정본은 드라이브에 유지하고, 공유용 집계만 중앙 DB에 올리는 하이브리드도 자연스러운 진화 경로다.