BACKEND ARCHITECTURE
앱 백엔드 서버, 핵심은 "벤더 락인을 어디까지 감수할 것인가"
10년 넘게 백엔드를 만들고 여러 회사를 컨설팅하면서 가장 자주 들은 질문이 "Firebase랑 Supabase 중에 뭐가 좋아요?"였습니다. 솔직히 잘못된 질문이에요. 신규 앱의 백엔드 선택은 사실 "나중에 떠나기 얼마나 쉬운가"의 문제입니다. 모든 BaaS는 락인이 있고, 그 정도가 곧 자유의 정도예요. 이걸 모르고 시작하면 1~2년 후에 마이그레이션 비용으로 뼈아프게 깨닫게 됩니다.
백엔드 옵션을 크게 나누면 관리형 BaaS(Firebase, Supabase, AWS Amplify)와 자체 구축(Node/Spring/Django + 직접 인프라) 두 갈래입니다. 제가 본 신규 앱의 90% 이상은 BaaS로 시작하는 게 합리적이고, 실제로 그렇게 가더라고요. BaaS 안에서도 선택지가 갈리는데, 결정 기준을 미리 정리하면 이렇습니다.
결론을 미리 말씀드리면, 빠르게 시작하고 NoSQL이면 Firebase, SQL과 자체 호스팅 옵션을 원하면 Supabase, AWS 생태계에 이미 있으면 Amplify, 시니어 백엔드가 풀타임으로 있고 사용자 100만 이상이면 자체 구축. 이게 단순화한 가이드라인이에요. 하지만 이 결정에는 더 깊은 맥락이 있으니 하나씩 풀어보겠습니다.
먼저 본질부터: BaaS는 무엇을 줄이는가
앱 백엔드는 본질적으로 다음 6가지 영역으로 구성됩니다. 자체 구축이면 이 모두를 직접 만들고, BaaS면 대부분 제공돼요. 이걸 직접 다 만들 때 얼마나 시간이 걸리는지 감을 잡으면, BaaS의 가치가 명확해집니다.
앱 백엔드의 6가지 영역
인증 (Auth)
로그인, 가입, 토큰
소셜, OTP, 2FA
데이터베이스
SQL/NoSQL
CRUD, 쿼리, 인덱스
실시간 동기화
채팅, 알림
WebSocket/Pub-Sub
⚡ BaaS는 이 6가지를 통합 제공. 자체 구축은 모두 직접 만들어야 함. 시니어 1명이 안정적인 기반 잡으려면 6개월~1년 작업.
자체 구축은 풀스택 시니어 1명이 6개월은 매달려야 안정적인 기반이 잡혀요. 인건비 환산 5천만원 내외. BaaS는 며칠이면 같은 기능을 만들 수 있고 월 사용료 무료~50만원에서 시작합니다. "BaaS가 비싸다"는 직관은 거의 항상 틀려요. 인건비 + 기회비용 다 따지면 BaaS가 압도적으로 쌉니다. 사용자 수십만 이상이 되면 BaaS 사용료가 자체 구축 인프라 비용을 넘어갈 수 있는데, 그 시점에는 회사도 커져서 자체 구축으로 옮길 여력이 생겨요. 처음부터 자체 구축은 거의 항상 잘못된 결정입니다.
한국 앱이 자주 빠뜨리는 부분: 카카오/네이버 로그인
기술 비교만 하다 보면 한국 특수성을 놓치기 쉬운데, BaaS 선택에서 의외로 큰 변수가 카카오/네이버 로그인 지원 여부입니다. 한국 앱은 거의 무조건 카카오 로그인을 깔게 되는데, BaaS마다 지원 수준이 천차만별이에요.
Firebase: 카카오/네이버 모두 공식 미지원
Cloud Functions로 별도 서버 만들어서 카카오 Access Token을 받고, Firebase Admin SDK로 Custom Token 발급받아 signInWithCustomToken 호출하는 구조 직접 구현해야 합니다. 처음 해보면 1~2주, 익숙해도 4~5일은 걸려요. 게다가 유지보수도 직접 해야 하고요.
Supabase: 카카오 공식 지원, 네이버는 OIDC 커스텀
2024년부터 Supabase가 카카오 OAuth를 공식 지원해요. signInWithOAuth({ provider: 'kakao' }) 한 줄이면 끝. OIDC도 지원돼서 카카오톡 앱 간편 로그인까지 자연스럽게 됩니다. 네이버는 공식 지원은 없지만 OIDC를 통해 우회 구현 가능해요. 한국 앱이 Supabase를 검토할 때 이 부분이 의외로 큰 메리트입니다.
AWS Amplify (Cognito): 카카오/네이버 모두 미지원, OIDC 커스텀 필요
Cognito User Pool에 OIDC Identity Provider를 직접 등록하는 방식이라 설정이 까다로워요. 결국 Custom Lambda + JWT 변환 작업이 필요합니다. 컴플라이언스가 필수가 아니라면 한국 앱이 Amplify를 굳이 고를 이유가 약해지는 지점이에요.
제가 컨설팅했던 회사 중에 Firebase로 시작했다가 카카오 로그인 직접 구현하는 데 2주 쓴 케이스가 있어요. 결국 카카오 로그인만 별도 서버로 분리해서 운영 중인데, Supabase였으면 안 했을 일입니다. 한국 사용자 비중 높은 앱이라면 이 부분 꼭 미리 확인하세요.
한국 개인정보보호법과 데이터 리전
하나 더 짚을 게 한국 개인정보보호법이에요. 의료/금융/공공 카테고리는 사실상 데이터를 한국 리전에 두는 게 의무이고, 일반 앱이라도 개인정보 국외 이전 시 별도 동의 + 이전 위치 고지가 필요합니다.
BaaS별 서울 리전 지원: Firebase는 asia-northeast3(단, Auth 일부는 멀티 리전 강제), Supabase는 ap-northeast-2(AWS), Amplify는 ap-northeast-2(가장 풍부), 자체 구축은 자유.
한국 사용자 데이터라면 처음부터 서울 리전 명시. 기본값(us-east 등)이면 응답 속도 200ms+ 추가되고, 나중에 리전 변경은 데이터 마이그레이션이 필요해서 매우 비싸져요.
4가지 옵션 한눈에 비교
항목
Firebase
Supabase
AWS Amplify
자체 구축
DB 유형
NoSQL (Firestore)
SQL (PostgreSQL)
DynamoDB/Aurora
자유 선택
시작 시간
10분
2분
30분~1시간
3~6개월
초기 비용
무료 → 사용량
$25/월~ + 사용량
사용량 (예측 어려움)
서버비+인건비
카카오 로그인
미지원 (직접 구현)
공식 지원
미지원 (OIDC)
자유
벤더 락인
매우 강함
약함 (오픈소스)
중간
없음
실시간 동기화
강력
강력 (Postgres CDC)
중간 (AppSync)
직접 구현
표만 봐도 각 옵션의 성격이 보입니다. 가장 결정적인 변수는 DB 유형(NoSQL vs SQL), 카카오 로그인 지원, 벤더 락인 강도 세 가지예요. 한국 앱이라면 카카오 로그인이 추가 변수로 들어와서, 글로벌 BaaS 비교 글들과는 다른 결론이 나오는 경우가 많습니다.
옵션별 상세 분석
1. Firebase, 가장 빠른 시작, 가장 강한 락인
Google이 만든 BaaS. SDK 통합이 압도적이고, 10분이면 인증 + DB + 푸시 + 분석까지 모두 붙일 수 있어요. MVP나 초기 스타트업이 가장 많이 선택하는 옵션입니다. 가장 큰 강점은 실시간 동기화예요. Firestore의 onSnapshot 한 줄이면 채팅/협업/라이브 스코어가 됩니다.
단점은 명확해요. NoSQL만 지원이라 관계형 데이터에 약하고, 벤더 락인이 매우 강합니다. 그리고 Firestore의 document 읽기 단가가 진짜 위험. 제가 본 사례 중에 신입 개발자가 무한 스크롤 화면에 limit 안 걸고 쿼리 짠 적이 있는데, 사용자 한 명당 5000개 document를 읽어버려서 하루 만에 100만원 청구된 적 있어요. Budget Alert는 첫날부터 필수예요.
강점 / 약점
강점
SDK 통합 압도적, 실시간 동기화 강력, Google 생태계, 분석 자동, 무료 시작 쉬움
약점
NoSQL만, 카카오 로그인 직접 구현, 사용량 과금 폭발 위험, 락인 강함
실전 팁: Firestore 쿼리는 항상 인덱스 + 페이지네이션 + Limit 걸기. 한국 앱이라면 처음부터 서울 리전(asia-northeast3) 명시. 기본값(us-central1)으로 만들면 한국 사용자 응답 속도 200ms+ 추가됩니다.
대표 사용 사례: 채팅 앱, 실시간 협업 도구, 모바일 우선 앱, MVP, 사용자 100만 이하 일반 앱.
2. Supabase, Postgres 진영의 강자, 락인 최소
Firebase의 SQL 대안. PostgreSQL을 그대로 DB로 사용하기 때문에 SQL과 관계형 데이터 모델이 필요한 일반 비즈니스 앱에 압도적으로 잘 맞습니다. 오픈소스라 자체 호스팅 가능한 것도 큰 차별점이에요. 가격은 Free($0, 500MB DB / 50K MAU / 1GB 스토리지) / Pro($25/월~ + 사용량, 8GB DB / 100K MAU 포함) / Team($599/월). 실제 Pro 운영 비용은 $35~75/월이 가장 많고, 트래픽 큰 앱은 $200/월 안팎까지 갑니다. "$25 고정"이 아니라 "$25 + 사용량"이라는 점 꼭 기억하세요.
강점은 Row-Level Security(RLS)와 이전 자유예요. RLS는 "이 데이터는 이 사용자만"이라는 규칙을 DB 레벨에서 강제할 수 있어 B2B SaaS / 의료 / 금융에 유리합니다. 또 PostgreSQL 표준이라 pg_dump 한 번으로 데이터 전체 이전 가능. AWS RDS든 자체 서버든 거의 코드 수정 없이 옮겨져요. Firebase에서는 절대 불가능한 일이죠.
한국 앱 입장에서 결정적인 강점이 하나 더. 카카오 로그인 공식 지원입니다. 2024년부터 signInWithOAuth 한 줄로 카카오 로그인이 돼요. Firebase에서 1~2주 걸리는 작업이 Supabase에선 30분. 단점은 모바일 SDK 성숙도가 Firebase 대비 떨어지고(오프라인 동기화 직접 구현), 한국 트러블슈팅 자료가 적다는 점입니다.
강점 / 약점
강점
PostgreSQL, 오픈소스, RLS 강력, pg_dump 이전 자유, 카카오 공식 지원
약점
상대적 신생, 모바일 SDK 미성숙, 한국 사례 적음, egress 비용 함정
대표 사용 사례: SQL 모델 필요한 일반 비즈니스 앱, B2B SaaS, 향후 자체 호스팅 옵션 열어두고 싶은 팀, 카카오 로그인 빨리 붙여야 하는 한국 앱.
3. AWS Amplify, 이미 AWS에 있다면
AWS의 모바일 백엔드 솔루션. Cognito(인증), DynamoDB/Aurora(DB), Lambda(함수), S3, AppSync(GraphQL) 등 AWS 인프라를 한 번에 묶어서 제공해요. 이미 AWS에 회사 인프라가 있다면 가장 자연스러운 선택입니다. 엔터프라이즈에서 강력한 이유는 SLA + 보안 인증(SOC 2, HIPAA, PCI DSS) + 한국 정부 CSAP까지 갖춰서, 금융 / 의료 / 공공 서비스에 사실상 다른 선택지가 없거든요.
단점은 학습 곡선이 가파르다는 것. Firebase가 10분이면 시작하는 게 Amplify는 IAM/VPC/CloudFormation을 알아야 1시간. 사용량 과금이라 잘못 설정하면 월 천만원 청구되기도 하고, Amplify 자체가 변동 잦아서 Gen 1 → Gen 2 같은 마이그레이션 작업이 가끔 필요합니다.
현실: 처음부터 Amplify 선택하는 신규 스타트업은 거의 없어요. 이미 AWS에 락인된 회사들이 자연스럽게 사용하는 옵션입니다. 우리 회사가 이미 AWS에 EC2와 RDS 쓰고 있다면 Amplify 검토할 가치 있어요.
대표 사용 사례: AWS 인프라 사용 중, SOC 2/HIPAA/CSAP 등 컴플라이언스 필수 환경, 엔터프라이즈 B2B, 금융/의료/공공.
4. 자체 구축, Node/Spring/Django + 직접 인프라
Express + PostgreSQL + AWS EC2처럼 백엔드 프레임워크와 인프라를 직접 조합하는 방식. 완전한 자유와 통제권이 강점이고, 어떤 락인도 없고 비용도 100% 통제 가능해요. 단, 시니어 백엔드 + 인프라가 풀타임으로 붙어야 안정적이라 인건비 환산 시 BaaS 대비 훨씬 비싸집니다. 6개월~1년 구축 기간 동안 출시 지연되는 기회비용도 크고요.
"확장성을 미리 대비"는 거의 항상 잘못된 직관이에요. 대부분의 서비스는 사용자 100만에 도달하지 못하고, 도달해도 1~2년 걸립니다. 자체 구축이 정당화되는 경우는 (1) 사용자 100만+이고 BaaS 비용이 자체 구축을 넘어서거나, (2) 망분리/국정원 인증 같은 특수 규제가 있을 때. 그 외에는 BaaS가 항상 더 합리적이에요.
강점 / 약점
강점
완전한 자유, 어떤 락인도 없음, 비용 100% 통제, 보안 / 규제 자유
약점
시니어 개발자 필수, 구축 6개월+, 운영 부담 큼, 출시 지연
대표 사용 사례: 사용자 100만+ 또는 특수한 보안/규제 요구사항. 그 외에는 거의 항상 BaaS가 더 나음.
실전 의사결정 플로우
아래 4단계 질문에 답하면 자동으로 답이 나옵니다. Q1부터 차례로 답하세요.
Q1
SQL이 필요한가, NoSQL이면 충분한가?
관계형 데이터(주문-결제, 권한 모델 등) 많음 → Supabase / Amplify(Aurora) / 단순 도큐먼트 위주 → Firebase
Q2
한국 사용자 비중이 높은가? (카카오 로그인 필수?)
YES (한국 70%+) → Supabase 우선 / NO → Firebase / Amplify도 OK
SOC 2 / HIPAA / 정부 데이터 / 금융 규제 / CSAP → AWS Amplify (조달 친화) / 일반 앱 → Firebase / Supabase
Q4
시니어 백엔드 개발자가 풀타임으로 있는가?
없음 → BaaS 무조건 / 있음 → 일반 앱은 여전히 BaaS 권장 (사용자 100만+ 시 자체 구축 검토)
실전: 자주 만나는 실수와 권고
컨설팅하면서 본 자주 만나는 실수들이에요. 이거만 피해도 1년 후에 후회할 일이 크게 줄어듭니다.
⚠️ 실전 권고 5가지
1. 처음부터 자체 구축은 거의 항상 실수
"확장성을 미리 대비"는 잘못된 직관. 사용자 0명일 때부터 100만 명 대비 인프라 만드는 건 시간/돈 낭비. BaaS로 시작하고 한계가 명확해지면 그때 옮기세요. 옮길 시점이 오는 회사가 그렇게 많지 않아요.
2. 비용 알람과 Quota는 첫날부터
Firebase Firestore의 document read 단가, Supabase의 egress 비용, AWS Amplify의 사용량 과금 모두 함정이에요. 일일 비용 알람과 Quota 설정 첫날에 끝내세요. 앞에서 말씀드린 100만원 사고도 Budget Alert만 있었으면 막을 수 있었습니다.
3. 한국 사용자라면 서울 리전 명시
기본값(us-east 등)이면 응답 속도 200ms+ 추가. Firebase는 asia-northeast3, AWS/Supabase는 ap-northeast-2. 한국 개인정보보호법 측면에서도 안전한 선택이에요.
4. 비즈니스 로직은 BaaS에 두지 말 것
DB 트리거나 Cloud Functions에 너무 많은 로직 넣으면 마이그레이션 시 다 다시 짜야 합니다. 핵심 로직은 별도 마이크로서비스로 분리해서 BaaS는 데이터 저장소로만 활용. "BaaS는 인프라, 비즈니스 로직은 우리 코드"가 원칙이에요.
5. 이전 가능성은 코드 작성 단계부터 설계
Repository 패턴 등으로 BaaS SDK를 추상화하면 향후 이전 시 비용이 1/10로 줄어요. 코드 곳곳에 firebase.firestore() 직접 호출하지 말고, UserRepository / OrderRepository 같은 추상 레이어를 두고 그 안에서만 SDK를 쓰세요. 이 작은 설계 결정이 1년 후에 큰 차이를 만듭니다.
시기별 백엔드 마이그레이션 시나리오
실제 회사들이 어떤 시점에 백엔드를 옮기는지 패턴을 정리했어요. 우리 회사가 어디에 있는지 가늠해볼 수 있을 거예요.
사용자 0~10만: BaaS의 황금 시기
Firebase 월 10~50만원, Supabase Pro $35~75/월. BaaS 비용이 자체 구축 인건비 대비 압도적으로 저렴해서 자체 구축 검토조차 시간 낭비. 코드 빠르게 짜고 시장 검증에 집중할 시기예요.
사용자 10~50만: 비용 모니터링 강화
Firebase 월 100~500만원, Supabase $100~300/월 수준. Firestore read나 Supabase egress가 가파르게 오르면 쿼리 최적화로 1차 대응하고, Repository 패턴으로 마이그레이션 옵션 확보해두세요.
사용자 50~100만: 부분 마이그레이션
BaaS 월 1000만원+. 통째로 옮기지 말고, 비용 큰 쿼리(피드, 추천 등)부터 자체 API로 부분 마이그레이션. 하이브리드 전략이 안전합니다.
사용자 100만+: 자체 구축 본격 검토
자체 구축이 비용 + 통제권 + 성능에서 유리. 다만 6개월~1년 마이그레이션 프로젝트가 되고, 시니어 백엔드 + 인프라 엔지니어 풀타임 투입 필요해요.
정리하며
앱 백엔드 선택의 본질은 "속도"와 "자유"의 트레이드오프예요. Firebase는 가장 빠르지만 가장 강하게 묶이고, 자체 구축은 가장 자유롭지만 가장 느립니다. Supabase는 중간에서 균형 잡혀 있고, 한국 앱이라면 카카오 로그인 공식 지원이라는 결정적 장점이 있고요.
제가 컨설팅할 때 가장 자주 드리는 권고는 "처음엔 BaaS, 한계가 보이면 그때 결정"입니다. 사용자 0명일 때 인프라 미리 만드는 건 가장 비싼 조기 최적화예요. 시장 검증이 먼저고, 인프라는 검증된 시장 위에서 결정하세요. 그리고 처음 BaaS를 선택할 때부터 Repository 패턴으로 SDK 호출을 한 곳에 모아두면, 나중에 옮겨야 할 때 일주일 작업으로 끝납니다. 이런 작은 설계 결정이 1~2년 후에 큰 차이를 만들어요.
앱 백엔드 비교 · 아키텍처 가이드
