프로젝트

Spoteditor(팀 프로젝트)

<aside> 💡

배포 페이지 테스트 버전(링크) | 깃허브 저장소(링크)

</aside>

프로젝트 개요

위치 기반 하루 여행 코스를 추천하고 공유할 수 있는 서비스

기술스택

주요 문제와 해결 과정

1. SSR + CSR 캐시 통합으로 데이터 정확성과 반응성 확보

• 문제:
  • 서버 패칭: 초기 렌더링이 빠르지만 인터렉션하지 않음
  • 클라이언트 패칭: 반응성과 상태 관리에 유리하고 인터렉션 하지만, 초기 화면이 비어 있어 로딩 발생
• 해결:
  • 탠스택 쿼리의 dehydrate + HydrationBoundary로 서버 패칭 결과를 클라이언트 캐시에 직접 주입하여 SSR캐시와 CSR캐시를 공유
    • SSR에서 패칭한 데이터를 주입하므로 클라이언트에서 동일 데이터를 따로 다시 패치하지 않아도 됨
    • SSR의 장점인 초기 렌더링 속도를 그대로 유지하면서도 CSR 환경에서의 인터렉션한 관리가 가능해 라이트하우스 지표, UX와 성능 모두 개선

2. 콘텐츠 이미지 업로드 속도개선

• 문제:
  • 프로필 저장 시 3~4초 소요, 그중 이미지 삭제+업로드에만 2.5초
  • 수파베이스 SDK의 서버를 거쳐 업로드 하는 방식을 문제로 지목
• 해결:
  • PreSigned URL을 활용해 브라우저에서 S3로 직접 업로드하도록 개선
  • 업로드 속도 1.28초 → 0.2초로 약 5배 향상, 전체 저장 시간도 3.8초 → 2.3초로 40% 단축
  • 한 번에 많은 이미지를 업로드 할 수록 강점 부각

3. 다국어 콘텐츠 구조 분리

• 문제:
  • 한국어 콘텐츠와 영어 콘텐츠를 완전히 분리하고 싶었지만, 유저 계정은 공유해야 함
  • 단순히 테이블 네이밍(log_en)으로만 구분 시,
    • Prisma 모델이 한곳에 뒤섞여 혼동 발생
    • 권한 제어(RLS), 마이그레이션, 백업 시 관리 복잡도 급상승
  • 수파베이스 프로젝트를 2개로 나누면 유저 인증(auth schema) 공유가 불가능해 로그인 상태 유지 불가
• 해결:
  • 하나의 Supabase 프로젝트 + 다중 스키마(public, en) 구조 채택
  • public 스키마 → 한국 콘텐츠, en 스키마 → 글로벌 콘텐츠, auth 스키마 → 유저 공통
  • Prisma multiSchema 기능으로 prisma.public.*, prisma.en.* 로 분리
  • 스키마 단위 RLS 정책, 권한 설정, 마이그레이션 적용으로 실수 방지 및 유지보수 용이
  • API에서 locale에 따라 해당 스키마만 접근하도록 분기 처리해 데이터 격리와 확장성 확보