앱
듀티라운지
카지노 교대 근무자를 위한 앱을 개발·운영하며, Cafe24의 자체 백엔드를 Supabase로 이전하고 일정 조회와 저장의 정합성을 개선했습니다.
주요 성과
서버 고정비 월 11,000원 → 0원
2025년 Cafe24 비즈니스형 가상서버에서 Supabase Free Plan으로 이전한 당시 기준입니다. 연간 132,000원의 가상서버 비용을 줄이고 OS·API 서버·DB의 직접 운영 부담을 낮췄습니다.
자체 API·JWT·MySQL을 Supabase 기반으로 전환
MySQL 데이터를 PostgreSQL 스키마로 변환하고, Axios REST 호출과 자체 인증을 Supabase 클라이언트·Auth로 교체했습니다. 데이터 import 오류와 RLS 적용 후 조회 권한 문제를 해결하며 앱까지 전환했습니다.
50명 그룹의 월별 데이터 조회 101회 → 3회
기존 월별 데이터 요청 1 + 2N회를 멤버·일정·근무 일괄 조회로 변경했습니다. 50명·단일 페이지 모의 데이터에서는 101회 → 3회이며, 인증·가입 확인 요청 3회는 별도입니다. 데이터가 늘면 청크·페이지에 따라 요청 수가 증가합니다.
늦은 조회 응답이 새 저장 결과를 덮는 경쟁 조건 방어
이전 조회를 취소한 뒤 저장 응답을 캐시에 반영하고, 편집 초안을 서버 데이터와 분리했습니다. 느린 이전 응답과 계정 변경 상황을 회귀 테스트로 확인했습니다.
초기 서비스에서 직접 운영할 백엔드 범위 정하기
Cafe24에서 NestJS·Prisma·MySQL과 자체 JWT 인증을 운영했습니다. 초기 사용량에서도 월 11,000원의 고정비가 있었고 OS·API·DB 관리가 기능 개발 시간과 함께 필요했습니다. 현재 규모에 맞춰 직접 운영할 범위를 줄일 수 있는 구조를 검토했습니다.
관계형 데이터를 PostgreSQL로 유지하면서 조회 API와 인증을 함께 사용할 수 있는 Supabase를 선택했습니다. 이전 당시 Free Plan 범위에서 운영할 수 있어 가상서버 고정비는 월 11,000원에서 0원이 됐습니다. 앱의 권한 정책·쿼리 효율·데이터 보존은 계속 직접 다뤄야 하는 범위로 남겼습니다.
데이터 엔진과 사용자 식별 체계를 함께 바꾸기
MySQL 테이블을 PostgreSQL로 옮기는 과정에서 자료형과 날짜 형식이 달랐습니다. 인증을 바꾸면 사용자와 일정·그룹 사이의 참조도 새 식별 체계에 맞아야 해서 파일 이전만으로는 전환이 끝나지 않았습니다.
데이터를 JSON으로 내보내 변환한 뒤 import했습니다. 자료형 변환 오류로 실패한 부분을 수정해 다시 이전했고, 마이그레이션 가이드에는 User를 Auth와 연결되는 profiles로 옮기는 구조와 UUID·관계 참조 변경을 정리했습니다. Axios 호출도 Supabase 클라이언트로 교체하고 인증·세션을 Auth와 연결했습니다.
직접 조회 구조에 맞춰 권한 경계 다시 잡기
앱에서 데이터를 직접 조회하도록 바뀌면서 사용자가 볼 수 있는 행과 수정할 수 있는 행을 DB에서도 제어해야 했습니다. RLS 설정 후 조회가 막히는 문제를 겪었고, 단순히 접근을 열기보다 사용자·그룹 관계에 맞는 정책이 필요했습니다.
Auth 사용자 ID와 그룹 소유·가입 관계를 기준으로 조회와 변경 권한을 구분했습니다. 그룹 소유자의 수정·삭제와 가입자의 조회 범위를 나누고, 필요한 업무는 권한 확인을 포함한 RPC로 연결했습니다.
오래된 화면 값의 원인을 응답 순서와 캐시에서 확인하기
저장 직후 이전 값이 표시돼 캐시 무효화 대기와 낙관적 갱신을 시도했습니다. 전환 후 해당 흐름은 개선됐지만, 이후에는 저장 응답이 반영된 뒤 더 오래된 조회가 도착해 캐시를 덮는 경쟁을 별도로 재현했습니다.
이전 조회를 취소한 뒤 저장 응답을 반영하도록 순서를 바꿨습니다. 계정이 바뀌면 이전 계정의 응답을 적용하지 않도록 하고, 편집 초안은 서버 데이터와 분리했습니다. 느린 이전 조회·계정 변경·초안 보존을 회귀 테스트로 확인했습니다.
멤버 수에 비례하는 요청을 일괄 조회로 바꾸기
그룹 일정은 멤버 목록을 읽고 각 멤버의 일정과 근무를 순차 요청해 월별 데이터 조회가 1 + 2N회였습니다. 요청을 병렬로만 바꾸면 개수는 그대로라 조회 방식 자체를 바꿀 필요가 있었습니다.
멤버 ID 목록으로 일정·근무를 각각 일괄 조회하고 두 요청을 병렬 실행했습니다. 사용자별 Map으로 결과를 조합하고, URL 길이·반환 행 제한을 고려해 50명 청크·100행 페이지 처리를 적용했습니다. 50명·단일 페이지 fixture에서는 데이터 요청 101회가 3회로 줄었습니다. 인증·가입 확인 3회는 별도이며 데이터가 늘면 청크·페이지 요청도 증가합니다.