구축기 1편 · 프로젝트 개요/아키텍처 (Vite + React + Supabase)

구축기 개요 · 아키텍처

Vite + React + Supabase로 상담신청 기능이 있는 인테리어 사이트 구축기

인테리어 업체 사이트에서 “상담신청 폼”이 진짜 매출로 이어지는 핵심이라, UX보다 먼저 입력 → 저장 → 알림 파이프라인을 단단하게 잡는 데 집중했어요. 프론트는 Vite + React + TypeScript로 민첩하게, 백엔드는 Supabase(DB + Edge Functions)로 “최소 운영”을 목표로 구성했습니다. 운영 알림은 최종적으로 SMS 중심으로 가는 흐름이고요.

Vite 번들/개발 속도

React + TS 컴포넌트/안정성

Supabase DB + Edge Functions

SMS 알림 운영 즉시 확인

Git push 배포 프론트 자동

요약(핵심 3~5줄)
1) 상담신청은 “저장 누락 0”이 목표라, DB 원장을 먼저 두고 알림은 뒤에서 트리거로 처리했어요.
2) 프론트는 Git push 기반 자동 배포로 수정 대응을 빠르게, Supabase 쪽은 Edge Functions로 알림/외부연동을 맡겼습니다.
3) Edge Functions 덕분에 키/토큰을 프론트에 노출하지 않고 SMS 연동이 가능했지만, 배포가 분리돼 운영 체크포인트가 생겼습니다.
4) 이번 글은 구조/선택 이유/트레이드오프만 정리하고, 구현 디테일은 다음 글에서 다룹니다.

프로젝트 목표와 요구사항

목표(운영 기준)

상담신청 데이터 안정 저장 (알림 실패해도 원장 남기기)
신청 즉시 관리자 인지 (최종은 SMS 중심)
프론트는 민첩한 배포로 전환율/문구/UX 개선을 빠르게

요구사항(기능)

상담신청 폼: 필수값 검증, UX(로딩/성공/실패 메시지)
DB 적재: 신청 즉시 저장 + 관리자 조회 가능
알림: 신청 발생 시 관리자에게 알림(우선순위 SMS)

결론적으로
“알림이 실패해도 데이터는 남아야 한다”가 기준이었고, 그래서 DB 원장과 알림 트리거를 분리하는 아키텍처로 갔습니다.

전체 아키텍처 흐름

흐름은 단순하지만, 운영에서 터지는 포인트(알림 실패, 배포 누락, 스팸/중복 요청)를 기준으로 책임을 분리했어요.

사용자 가 상담신청 폼 작성 후 제출
프론트(Vite + React + TS) 가 1차 검증 후 Supabase로 요청 전송
- 프론트는 UX에 집중(로딩/성공/실패), 알림 키/토큰은 절대 들고 있지 않음
Supabase DB(Postgres) 에 상담신청 레코드 저장(원장)
- 알림이 실패해도 “신청 자체”는 DB에 남아 운영자가 확인/재처리 가능
Supabase Edge Functions 가 알림 트리거 실행 → 외부 SMS 연동 호출
- 비밀키/연동 토큰은 함수 환경에만 보관
- 추후 이메일/카톡 등 채널 추가도 함수 쪽에서 확장
관리자 가 SMS로 즉시 인지 → 상담 처리

왜 Supabase Edge Functions를 썼는지

얻는 것(장점)

보안: SMS API 키/토큰을 프론트에 노출하지 않음
운영 분리: UI 변경과 알림/연동 로직을 분리
확장성: 채널 추가(이메일/카톡 등) 시 함수만 확장
장애 대응: “DB 저장 vs 알림” 원인 분리가 쉬움

대신 감수(트레이드오프)

배포 2트랙: 프론트 자동 배포 ≠ 함수 반영 완료
체크리스트 필요: 폼 필드 변경 시 DB/함수 파싱도 같이 확인
관측/로그: 알림 실패 사유를 남기는 에러 처리 설계가 중요

저는 “상담신청처럼 운영이 중요한 기능”은 프론트에 책임을 얹기보다, 서버리스 함수로 비즈니스 트리거를 모으는 쪽이 결과적으로 더 안전하다고 판단했어요. 대신 배포/테스트 흐름을 팀이 감당할 수 있게 만드는 게 핵심 포인트였습니다.

프론트 자동 배포 vs 함수 별도 배포 (운영 포인트)

프론트: Git push 기반 자동 배포

문구/레이아웃/전환 UX 개선이 빠르게 반영
운영 요청(오타/버튼 위치/안내문) 대응 속도 상승

Edge Functions: 별도 deploy 필요

프론트 반영됐다고 끝이 아님(알림 로직은 따로)
폼 필드 변경/검증 변경 시 함수 로직도 함께 배포 체크
롤백 시 “프론트만 롤백”으로는 데이터 포맷 불일치 가능

운영 팁(현실 버전)
“상담신청 관련 변경”은 프론트/DB/함수를 한 세트로 보고 배포 체크리스트를 두는 게 제일 안전했어요.

정리

이번 프로젝트는 거창한 백오피스보다도, 상담신청이 안정적으로 들어오고 운영자가 놓치지 않는 것이 목적이었어요. 그래서 프론트는 빠른 개발/배포 사이클로 민첩하게, 백엔드는 Supabase로 DB + Edge Functions를 묶어 운영 부담을 최소화했습니다.

가장 만족했던 선택은 DB 저장(원장)과 알림 트리거(Edge Functions)를 분리한 구조예요. 알림이 한 번 삐끗해도 “신청 데이터”는 남고, 운영에서 대응이 가능해졌거든요. 대신 배포가 2트랙이라서, 변경 시 체크 포인트를 습관화하는 게 필수였습니다.

이 블로그 검색

TechVerse

추천 가젯