[Supabase] Supabase SDK -> Edge function ->서버까지

백엔드는 Supabse 프론트는 SwiftUI로 구성했다.

처음엔 간단히 시작했지만, 예상치 못한 문제들과 함께 백엔드 아키텍처가 몇 번 바뀌게 됐다.

1. Supabase SDK

Swift용 Supabase SDK를 직접 사용해 iOS 앱에서 데이터를 다루었다.

장점

1. 빠른 구현 가능

Supabase 에서 프로젝트를 생성 -> 테이블 설계 -> RLS 설정을 하면 해당 테이블에 대한 배포가 끝난다.
백엔드 서버 작업 없이 DB 접근이 가능하다.
예시 : https://du-sungchan-24k.tistory.com/entry/Swift-Supabase-OAuth-Sign-in-with-Apple

2. OAuth 및 인증 관리

Apple OAuth, Google OAuth 등 인증 플로우가 SDK에 포함되어 있다.
토큰 발급도 갱신도 자동으로 처리된다.

3. 하나의 레포에서 관리

View, Service(Network), Model 등 적절히 분리한다면, 하나의 레포에서 빠르게 개발이 가능하다.

단점

1. 비즈니스 로직 분산 & 서비스 레이어 비대화

Supabase에서 트랜잭션 제어가 어렵기 때문에 복잡한 흐름을 전부 iOS 단에서 처리해야 함
`Service`와 `Repository` 레이어를 구분해도, 결국 Service가 RLS/조건 분기 등으로 인해 지나치게 뚱뚱해짐
예: "이용약관 동의 여부 체크 + 게시글 등록 + 알림 저장" → 클라이언트에서 모두 순차 호출해야 함

2. 테스트/디버깅 어려움

RLS 오류, 인증 문제 등은 Supabase 서버 로그를 직접 보지 않으면 원인 파악이 어려움
개발 초기에는 Apple 개발자 계정이 없어 시뮬레이터에서 테스트했는데, Apple OAuth 테스트가 불가능해 큰 시간 낭비 발생
개인적으로 애플 개발자 계정이 없어서 처음에 시뮬레이터로 했다가 삽질을 많이 했다가 시뮬레이터 문제를 알게됨
테스트 셋을 만들때도 애플 개발자 계정 관련 오류들이 처리 하기 어려웟음

3. 협업 난이도

Xcode의 `.xcodeproj/project.pbxproj`는 Git 충돌이 자주 발생
아예 .gitignore 할 수도 없고, 각 개발자의 개발자 계정 / Build Settings / Target 설정이 올라가 충돌을 자주 일으킴
결국 특정 설정만 따로 추려서 커밋하거나, 매번 커밋 전 diff 체크로 관리해야 하는 번거로웠음

결론

iOS + supabase 조합은 1인 개발에는 좋을 수도 있지만 협업은 어려웠음

2. Edge fucntion 를 통한 추상화

멘토님이 알려주신대로 edge fuction을 통해서 CRUD 을 구현하는 방식이다.

Swift 클라이언트에서 Supabase SDK를 직접 호출하는 방식의 한계를 느낀 후, Supabase Edge Function을 활용한 백엔드 추상화였다. Supabase는 Deno 기반의 서버리스 환경에서 HTTP 함수를 배포할 수 있게 해주며, 이를 통해 DB 접근 로직을 중앙집중식으로 관리할 수 있다.

장점

1. 서버 인프라 불필요

서버 프레임워크를 구성할 필요 없이 `.ts`(Deno) 파일을 작성해서 `supabase functions deploy` 하면 끝
Hosting, routing, key 관리, SSL 등 인프라 구성 없이도 RESTful API 형태로 추상화 가능

2. Supabase 자체의 마이그레이션

마치 데이터베이스 마이그레이션 처럼 Supabase 자체를 로컬로 가져와 도커단에서 실행시킬 수 있다.
Supabase의 DB를 가져오고(pull) 수정하고 올릴 수 있고(push), 마찬가지로 edge function 부분도 동일했다.
로컬에서 확인하고 클라우드 supabase에 바로 올릴 수 있는 점이 좋았다.

3. 키 관리, RLS 보안 신경 덜 씀

DB 접근을 Edge function을 통해서 이루어지기 때문에, Edge function 단에서 검증 및 인증이 가능함
같은 Supabase 공간에서 DB 와 서버리스 함수가 운영되기에 키 관리가 필요없음

4. 로그 용이

Edge Function의 요청/응답, 로그 등이 Supabase Dashboard에서 바로 확인 가능
iOS 내에서 SDK 로그 정보보다 Supabase에서 제공하는 로그 정보가 더 자세하여 도움이 많이 됨

단점

1. 구조가 커지기 시작하니 서버 코딩과 유사

단순 작은 CRUD, 인증, 유효성 검사에서는 정말 좋았지만, 구조가 커지기 시작하니 서버 코딩과 유사
서버 코딩과 유사한데, Spring/Django 같은 백엔드 프레임 워크가 제공하는 각종 기능들 미들웨어, 라우터 분리, DI, Swagger 제공 기능 등 미지원
이러면.. 백엔드 프레임 워크 쓰는게 낫지 않나..? 생각이 듬

2. 테스트 / 디버깅 어려움

단순 검증용으로는 supabase functions serve가 있지만 유닛테스트를 통한 CI 까진 구현이 어려웠음

결론

코드 규모가 커지면 결국 서버 프레임워크가 필요한 상황으로 전환될 수밖에 없었고, 그 결과 다음 단계인 백엔드 전환으로 이어졌음

3. iOS + Backend + Supabase 조합

Supabase SDK → Edge Function 단계를 거치며, 결국 독립적인 백엔드 서버 구현을 했다.

장점

1. 인증/로깅/시각화 부분을 쉽게 가져갈 수 있다.

앞의 경험에서 Supabase에서 좋았던 인증/로깅/시각화 부분을 쉽게 구현할 수 있었다.

2. 아키텍쳐 분리 및 역할 구분

iOS와 백엔드 간의 역할이 잘 구분
Supabase DB는 그대로 사용하되, 모든 로직은 백엔드 서버에서 처리

3. Supabase 의존성

이후 서버리스의 금전적인 이유에서 기존의 데이터베이스를 활용해야 할 시기가 왔을 때, 비교적 쉽게 전환 가능

단점

1. Supabase 핵심 활용을 못함

Supabase 장점은 서버리스 백엔드인데, 결국 백엔드 서버를 따로 구축하면서 Supabase의 핵심을 활용하지 못함
iOS + Supabase 구조의 무서버 구조에서 벗어남

저작자표시 비영리 변경금지 (새창열림)

dev.py