ADR-T-001

1. 배경 (Context)

플랫폼은 1인 개발 기반으로 MVP를 빠르게 출시해야 한다.
현재 단계의 목표는 인프라 완성도가 아니라 구조 검증이다.

초기 단계에서 자체 서버(.NET, Node 등)를 구축할 경우:

인증/권한/DB/배포 환경을 모두 설계해야 함
DevOps 부담 증가
초기 개발 속도 저하
과설계 가능성

본 플랫폼은 다음 특성을 가진다:

관계형 데이터 구조 (슬롯, 예약, 사용 확정, 제재 등)
트랜잭션이 중요한 도메인 (Redeemed 시 수량 차감)
RLS 기반 접근 제어 필요
인증 시스템 필수

이 요구사항을 충족하면서 개발 속도를 확보해야 한다.

2. 결정 (Decision)

초기 백엔드는 Supabase 기반으로 구축한다.

구성 요소:

PostgreSQL (관계형 데이터 모델)
RLS(Row Level Security) 기반 권한 제어
RPC(Function) 기반 트랜잭션 처리
Supabase Auth
Edge Functions는 최소 사용

자체 서버로의 이전은 초기 단계에서 고려하지 않는다.

3. 대안 (Alternatives Considered)

대안 A: .NET 기반 자체 서버 구축

설명
ASP.NET Core + PostgreSQL + 자체 인증 구조

장점

장기 확장성 우수
아키텍처 통제력 높음
CQRS 등 구조 확장 용이

단점

초기 개발 속도 저하
DevOps 관리 부담 증가
과설계 위험

채택하지 않은 이유
현재 단계는 구조 검증이 목표이며,
인프라 완성도가 우선순위가 아니다.

대안 B: Firebase

설명
Firebase Auth + Firestore 기반

장점

빠른 초기 개발
모바일 친화적

단점

관계형 모델에 부적합
복잡한 조건 매칭 쿼리에 제약
트랜잭션 처리 한계

채택하지 않은 이유
타임슬롯 조건 매칭과 수량 차감 트랜잭션에는
관계형 DB가 적합하다.

대안 C: Node.js 기반 경량 서버

설명
Express/Fastify + Postgres

장점

유연성
비교적 빠른 구축 가능

단점

인증/RLS/권한 직접 설계 필요
운영 부담 증가

채택하지 않은 이유
Supabase가 제공하는 기본 기능을 직접 구현할 이유가 없다.

4. 결과 (Consequences)

긍정적 결과

개발 속도 향상
인증 및 권한 구조 즉시 사용 가능
관계형 데이터에 적합
RPC로 트랜잭션 로직 처리 가능
1인 개발에 적합

부정적 결과

벤더 종속성 존재
비용 증가 가능성
복잡한 비즈니스 로직은 RPC에 의존
서버 레이어 커스터마이징 제약

5. 영향 범위 (Impact)

기술

데이터 모델은 PostgreSQL 중심 설계
트랜잭션 로직은 RPC로 구현
RLS 정책이 핵심 보안 장치

운영

비용 모니터링 필수
DAU 증가 시 비용 시뮬레이션 필요

확장

마이크로서비스/분리 아키텍처는 초기 단계에서 미도입
DB 이전 전략은 별도 ADR에서 정의

6. 재검토 조건 (Revisit Conditions)

다음 조건 중 하나 이상 충족 시 재검토:

DAU 증가로 비용이 급격히 상승
고급 분석/서비스 분리 필요성 증가
서울 전체 밀도 확보 후 전국 확장 단계 진입
Supabase 구조적 제약이 도메인 확장을 제한하는 경우

Buy me a coffee

ADR-T-002