ADR-T-006

1. 배경 (Context)

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

슬롯, 예약, 사용 확정, 제재 등 명확한 도메인 분리 가능
트랜잭션 중심 로직 존재
향후 확장 시 서비스 분리 가능성 존재

이러한 특성은 CQRS(Command Query Responsibility Segregation)나
마이크로서비스 아키텍처 도입을 유혹한다.

그러나 현재는:

1인 개발
MVP 단계
지역 밀도 검증 전
트래픽 불확실

이다.

아키텍처를 조기에 분리할 경우:

복잡도 증가
배포 및 디버깅 비용 증가
DevOps 부담 증가
실제 필요성이 검증되지 않은 상태에서 구조 고착 위험

이 존재한다.

2. 결정 (Decision)

초기 단계에서는 CQRS를 도입하지 않는다.

마이크로서비스로 분리하지 않는다.

단일 데이터베이스(PostgreSQL) + RPC 중심 구조를 유지한다.

Command와 Query는 코드 레벨에서만 분리하고,
물리적 서비스 분리는 수행하지 않는다.

3. 대안 (Alternatives Considered)

대안 A: 초기부터 CQRS 도입

설명
Command와 Query 모델을 분리하고, 읽기 전용 뷰/리포지토리 별도 구성

장점

확장성 우수
읽기/쓰기 최적화 가능

단점

구조 복잡도 증가
개발 속도 저하
운영 부담 증가

채택하지 않은 이유
MVP 단계에서 과설계에 해당한다.

대안 B: 마이크로서비스 아키텍처

설명
예약/슬롯/제재/결제 등 서비스 단위 분리

장점

서비스 독립 배포 가능
확장 유연성

단점

네트워크 복잡도 증가
트랜잭션 처리 어려움
DevOps 리소스 필요

채택하지 않은 이유
현재 트래픽과 팀 규모에 부적합하다.

대안 C: 모듈형 단일 구조 (채택)

설명
단일 DB + 단일 백엔드 구조 유지하되,
코드 레벨에서 도메인 모듈 분리

장점

복잡도 낮음
추후 분리 가능성 유지
MVP 속도 확보

단점

대규모 확장 시 재설계 필요

채택 이유
현재 단계에 가장 적합하다.

4. 결과 (Consequences)

긍정적 결과

개발 속도 향상
배포 단순화
디버깅 용이
트랜잭션 일관성 유지

부정적 결과

향후 확장 시 구조 재정비 필요
단일 DB에 의존
고트래픽 상황에서 스케일링 제약 가능

5. 영향 범위 (Impact)

기술

Supabase 단일 프로젝트 구조 유지
RPC 중심 트랜잭션 처리
코드 레벨 모듈 분리 유지(슬롯/예약/제재 등)

운영

서비스 간 네트워크 장애 리스크 없음
단일 장애 지점(Single Point of Failure) 존재

확장

일정 트래픽 도달 시 분리 전략 필요

6. 재검토 조건 (Revisit Conditions)

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

서울 전체 밀도 확보 및 DAU 급증
읽기 트래픽과 쓰기 트래픽의 명확한 병목 발생
분석/리포트 서비스가 실시간 운영 로직과 충돌
팀 규모 확대(백엔드 전담 인력 확보)

Buy me a coffee

ADR-T-005 ADR-T-007