API 아키텍처 선택 비교: 개인 개발에서 테스트한 여섯 가지 설정에 대한 기술적 평가

Source: Dev.to

개인 프로젝트를 처음 시작했을 때는 앱이 대부분 독립적으로 동작할 수 있을 것이라고 생각했습니다.
하지만 데이터 공유, 사용자 인증, 다중 앱 확장 등과 같은 요구사항이 늘어나면서 적절한 백엔드(API)와 서버리스 인프라를 선택해야 할 필요성이 생겼습니다.

Swift‑only, Firebase, FastAPI, 직접 Supabase 접근, Next.js 등 여러 구성을 평가한 결과, React Native × Hono × Cloudflare Workers × Supabase가 최적의 아키텍처라는 결론에 도달했습니다.

이 글은 각 옵션의 특성을 객관적으로 정리하고, 채택 또는 배제된 기술적 이유를 설명합니다.

선택 기준

API 아키텍처는 다음 요구 사항을 기준으로 평가되었습니다.

기능 요구 사항

• iOS와 Android 모두에서 사용할 수 있는 API
• 비회원(게스트) 사용자와 인증된 사용자를 지원
• 영구 데이터 저장소 (RDB 필요)
• 여러 작은 애플리케이션이 공유하는 API

비기능 요구 사항

• 장기 개인 개발에 비용 효율적
• API 수준에서 무단 접근 방지
• 멀티테넌트 / SaaS 사용을 위한 확장성
• 낮은 운영 및 유지보수 부담
• 서버리스 아키텍처 선호

Evaluated Architectures

각 후보 아키텍처를 아래에서 검토하고, 요구 사항을 얼마나 잘 충족하는지 평가합니다.

2‑1. Swift (iOS Only)

Overview
Swift만을 사용해 네이티브 iOS 앱을 구축하고, 데이터를 로컬에 저장합니다.

Evaluation

Result: → 요구 사항 미충족으로 인해 거부

2‑2. Swift + Firebase

Overview
Firebase Authentication과 Firestore를 백엔드로 사용합니다.

Evaluation

Result: → RDB 및 확장성 제약으로 인해 거부

2‑3. React Native + Firebase

Overview
크로스‑플랫폼 React Native 앱이 Firebase Authentication과 Firestore에 직접 연결됩니다.

Evaluation

Result: → 보안 아키텍처 부족으로 인해 거부

2‑4. React Native + FastAPI + AWS

Overview
FastAPI(Python)를 API 레이어로 사용하고, AWS RDS, Lambda, VPC 등 서비스를 활용합니다.

Evaluation

Result: → 비용‑성능 균형이 맞지 않아 거부

2‑5. React Native + Supabase (Direct Client Access)

Overview
React Native가 Supabase(PostgreSQL + RLS)에 직접 연결됩니다.

Evaluation

Result: → 보안 및 아키텍처 제한으로 인해 거부

2‑6. React Native + Next.js (Vercel) + Supabase

Overview
Next.js API Routes와 Vercel Edge를 이용해 API를 구축하고 KV 캐싱을 사용합니다.

Evaluation

Result: → 비용 효율성 우려로 인해 거부

2‑7. React Native + Hono + Cloudflare Workers + Supabase (Final Choice)

Overview
Hono가 Cloudflare Workers에서 API 레이어로 동작합니다. Supabase(PostgreSQL + RLS)를 주요 데이터스토어로 사용하고, Workers KV를 캐시로 활용합니다.

Reasons for Adoption

1. 보안 요구 사항 충족

   • API 레이어에서 JWT 검증, 요청 서명, 속도 제한 구현
   • Supabase RLS와 중첩된 방어 체계 제공
   • 앞단에 Cloudflare WAF 배치 가능
   • 클라이언트에 Supabase anon 키를 배포할 필요 없음

2. 저비용

   • Workers는 지속적인 비용이 거의 없으며, 사용량 기반 과금 구조로 예산을 효율적으로 관리할 수 있음

3. 확장성 및 유지보수성

   • 서버리스 환경으로 자동 스케일링 지원
   • Hono와 Workers의 경량 구조가 빠른 배포와 업데이트를 가능하게 함

4. 개발 생산성

   • TypeScript 기반으로 기존 React Native 코드와 일관된 개발 경험 제공
   • Supabase의 자동 생성 API와 RLS 정책을 활용해 백엔드 로직을 최소화

Result: → 최종 선택

free under ~100 k requests/month

• KV and caching reduce Supabase query volume
• Zero fixed operational cost

3. High Scalability

• API modularization suitable for multi‑app expansion
• Hono provides Express‑like ergonomics with high performance
• Serverless scaling removes infrastructure concerns

4. High Development Efficiency

• Workers + Hono are optimized for API‑only use
• Simple middleware composition
• Smooth integration with Supabase

Result: → Adopted as it best satisfies both technical and non‑functional requirements

아키텍처 다이어그램

[ React Native App ]  [ Cloudflare Workers (Hono) ]  [ Supabase (PostgreSQL + RLS) ]
                                   |
                                   v
                               [ Workers KV (cache) ]

상세 다이어그램

] 
        |
      HTTPS
        |
[ Cloudflare Workers (Hono API) ]
        |
        +--> JWT Verify -----> [ Supabase Auth ]
        |
        +--> SQL + RLS ------> [ Supabase PostgreSQL ]
        |
        +--> Rate Limit -----> [ Workers KV ]

비교 표

보안, 비용, 확장성은 이 프로젝트의 가정에 기반한 주관적 평가입니다.

요약

이 글에서는 개인 개발 프로젝트를 위해 여러 API 아키텍처를 비교하고, 각 옵션을 기능적 및 비기능적 요구사항에 따라 평가했습니다.

최종 선택인 React Native × Cloudflare Workers × Hono × Supabase는 다음과 같은 이유로 돋보였습니다:

• 강력한 API 수준 보안 제어
• Supabase와 행 수준 보안(RLS)을 활용한 안정적인 관계형 데이터베이스 지원
• Cloudflare Workers를 통한 뛰어난 비용 효율성
• 유연한 서버리스 확장성
• 다중 앱 확장에 적합한 구조