ADR-W-011
## 사용자 웹은 공개 조회 API를 별도로 두고, RLS 기반의 제한된 Read 모델만 허용한다
ADR ID: ADR-W-011
상태: Accepted
작성일: 2026-03-02
작성자: YSY
관련 ADR: ADR-W-001, ADR-T-001
1. 배경 (Context)
사용자 웹은 로그인 없이 조회가 가능하다.
이는 접근성을 높이지만 동시에 다음 리스크를 가진다:
대량 크롤링
전체 슬롯 데이터 수집
발행자 정보 과다 노출
비정상 트래픽 증가
서버 비용 상승
Supabase는 RLS(Row Level Security)를 제공하지만,
웹에서 직접 테이블에 접근하는 구조는 노출 범위 통제가 어렵다.
웹 조회는 “최소 정보”만 제공해야 한다.
2. 결정 (Decision)
사용자 웹은 다음 원칙을 따른다:
공개 조회 전용 API(RPC 또는 View)를 사용한다.
원본 테이블에 직접 접근하지 않는다.
RLS 정책으로 다음을 제한한다:
공개 가능한 필드만 반환
현재 시간 기준 활성 슬롯만 조회
반경 제한 필수 적용
발행자 민감 정보(정확 주소, 연락처 등)는 노출하지 않는다.
웹은 Read-Only 모델만 사용하며,
Reservation/usage_verify 관련 API는 호출하지 않는다.
3. 대안 (Alternatives Considered)
대안 A: 웹에서 Supabase 테이블 직접 조회
장점
구현 단순
빠른 개발
단점
데이터 과다 노출 가능성
크롤링 리스크
RLS 설정 복잡
채택하지 않은 이유
웹은 인증되지 않은 환경이다.
직접 테이블 노출은 위험하다.
대안 B: 별도 서버(API Gateway) 구축
설명
Node/.NET 서버를 두고 웹은 해당 서버를 통해서만 조회
장점
완전한 통제
Rate limit, 캐싱, 보호 로직 구현 가능
단점
인프라 복잡도 증가
MVP 범위 초과
채택하지 않은 이유
초기 단계에서는 Supabase RPC/View로 충분하다.
대안 C: RPC/View 기반 제한 모델 (채택)
설명
DB 레벨에서 공개 전용 View 또는 함수 생성
장점
노출 필드 통제 가능
반경/시간 조건 강제
구조 단순
단점
RPC 로직 증가
복잡한 쿼리 성능 고려 필요
채택 이유
보안과 단순성의 균형을 맞춘 선택이다.
4. 결과 (Consequences)
긍정적 결과
데이터 노출 최소화
크롤링 리스크 감소
서버 비용 통제 가능
정책 일관성 유지
부정적 결과
쿼리 로직이 DB 레벨에 일부 집중
복잡한 조건 확장 시 View 수정 필요
5. 영향 범위 (Impact)
기술
public_get_nearby_slots RPC 필요
반경/시간 필터 서버 강제 적용
rate limit 고려(Cloudflare/Edge 활용 가능)
UX
웹에서 노출 정보는 요약 중심
상세 정보는 앱으로 위임 가능
운영
비정상 트래픽 모니터링 필요
조회 수 급증 시 캐싱 전략 검토
6. 재검토 조건 (Revisit Conditions)
웹 트래픽이 전체의 50% 이상 증가
크롤링/비정상 요청이 빈번
서버 비용 급증
별도 API 레이어 필요성이 명확해질 경우
Buy me a coffee