백엔드·인프라 개념 1

About this offer

백엔드·인프라 개념 1 배포 인프라를 고르다 보면 마주치는 IaaS/PaaS/BaaS 같은 용어부터, AWS/GCP/Azure 같은 클라우드, 그리고 쿠버네티스/데브옵스까지 — 처음엔 다 비슷해 보이는데 정리해두면 확실히 구분됨. IaaS / PaaS / SaaS / BaaS — "얼마나 직접 관리하는가"의 스펙트럼 모델 정체 내가 관리하는 것 제공자가 관리하는 것 비유 IaaS 인프라(서버, 네트워크)만 임대 OS, 런타임, 앱, 데이터 전부 물리 서버, 네트워크, 가상화까지만 빈 땅 임대 — 건물은 내가 지음 PaaS 개발 플랫폼 자체를 제공 코드, 데이터만 OS, 서버, 배포 파이프라인까지 인테리어까지 된 상가 임대 SaaS 완성된 소프트웨어를 그냥 사용 아무것도 안 함 (사용만) 전부 다 완성된 프랜차이즈 매장 BaaS 백엔드 기능(DB, 인증, 스토리지)만 API로 제공 프론트엔드 코드, 비즈니스 로직 일부 DB 서버, 인증 시스템, 스토리지 인프라 주방을 통째로 빌려주는 것 실제 서비스에 대입하면: AWS EC2 = IaaS (가상 서버만 받고 나머지 다 직접 설치) Vercel = PaaS (Git push만 하면 배포 끝, 서버 관리 없음) Supabase, Firebase = BaaS (DB+인증+스토리지를 API로 바로 사용) GCP, Azure, Oracle Cloud = IaaS/PaaS를 다 포함하는 종합 클라우드 AWS/GCP/Oracle 같은 종합 클라우드는 그 안에 IaaS도 있고 PaaS도 있고 BaaS급 관리형 서비스(RDS 등)도 다 있음. Vercel/Supabase는 그중 특정 레이어만 딱 잘라 쉽게 만든 전문 서비스. 배포 인프라 종류 비교 구분 대표 서비스 특징 난이도 PaaS (프론트/풀스택 특화) Vercel, Netlify, Railway, Render Git push만 하면 자동 배포 매우 쉬움 BaaS Supabase, Firebase DB+인증+스토리지 관리형 제공 쉬움 클라우드 종합 AWS, GCP, Azure 확장성/커스터마이징 최강, 대신 직접 설정할 게 많음 어려움 컨테이너 기반 Docker + Kubernetes 대규모 MSA에 적합 매우 어려움 전통 VPS 자체 서버 서버를 통째로 빌려서 직접 세팅 어려움 3대 종합 클라우드: AWS / GCP / Azure (+ Oracle) [종합 클라우드 - IaaS/PaaS 다 포함] AWS --- GCP --- Azure --- Oracle Cloud (점유율 1위) (AI/데이터 강점) (기업통합 강점) (DB 전통 강자) Azure Microsoft의 종합 클라우드, AWS/GCP와 동급인 3대장 Windows Server, Active Directory, .NET, Office 365 같은 Microsoft 생태계 통합이 강점 한국에서는 금융권/대기업/공공기관 쪽에서 AWS 다음으로 많이 쓰임 (Java+SI형 시장과 자주 겹침) AWS와 비슷한 구조의 가입 크레딧, 12개월 무료 티어, Always Free 서비스가 있음 Cloudflare 원래는 CDN + DNS + 보안(DDoS 방어) 전문 회사 최근엔 Workers(서버리스 함수), Pages(정적 사이트 호스팅), D1(DB), R2(스토리지)로 PaaS/BaaS 영역까지 확장 중 강점은 전 세계 엣지 네트워크 — "어디서 접속해도 빠름"이 핵심 무기 무료 티어가 넉넉한 편으로 유명함 (Vercel보다 후하다는 평가도 있음) Vercel과 비슷한 포지션으로 최근 경쟁 구도 (Cloudflare Pages vs Vercel) Firebase vs Supabase 둘 다 BaaS지만 내부 구조가 다름. Firebase Supabase DB 종류 NoSQL (Firestore) PostgreSQL (SQL) 오픈소스 아님 (Google 종속) 오픈소스 SQL 지식 활용 안 됨 SQL 지식 그대로 활용 가능 데이터 마이그레이션 Google 생태계에 묶임 Postgres라 다른 곳으로 이전 쉬움 Firebase는 실시간 DB, 인증, 푸시 알림, 호스팅까지 올인원으로 제공하는 Google의 BaaS로, Supabase의 원조격 존재. 둘 다 무료 티어(Firebase는 Spark 요금제)가 있음. SQL vs NoSQL — Firebase/Supabase 선택의 핵심 기준 SQL (MySQL, PostgreSQL 등) NoSQL (Firestore 등) 데이터 구조 표(Table) - 행/열로 정형화 문서(Document) - JSON처럼 자유로운 구조 스키마 미리 정의해야 함 스키마 없음, 문서마다 필드 달라도 됨 관계 표현 JOIN으로 테이블 간 관계 연결 관계 개념 자체가 약함 쿼리 언어 SQL (표준화됨) 제품마다 다른 API 적합한 경우 데이터 간 관계가 명확하고 정합성이 중요할 때 구조가 자주 바뀌거나 대용량 실시간 데이터 처리 MySQL과 PostgreSQL은 둘 다 SQL 계열이라 문법이 거의 비슷해서 갈아타는 데 큰 무리가 없음. 반면 NoSQL(Firestore)은 아예 다른 사고방식이라 별도로 새로 배워야 하는 개념에 가까움. 쿠버네티스 · 데브옵스 · 클라우드 네이티브 — 하나의 흐름 클라우드 네이티브 (철학/목표) "클라우드에 최적화된 방식으로 서비스를 만들자" ↓ 컨테이너(Docker) + 쿠버네티스 (도구) "서비스를 컨테이너 단위로 쪼개고, 자동으로 관리하자" ↓ 데브옵스 (문화/프로세스) "개발자가 배포·운영까지 같이 책임지고, CI/CD로 빠르게 순환시키자" 쿠버네티스(K8s) : 컨테이너를 수십~수백 개 띄워야 할 때 자동으로 배치·확장·복구해주는 오케스트레이션 도구. 대규모 서비스(Netflix급)에서 진가를 발휘하고, 개인/소규모 프로젝트에는 사실상 오버스펙. 서버리스(Vercel 등)는 애초에 컨테이너 관리를 신경 안 써도 되게 만든 방식이라 K8s가 하는 일 자체가 필요 없어짐. 데브옵스 : 핵심 도구는 CI/CD(GitHub Actions, Jenkins 등) — 코드 push하면 자동 테스트·빌드·배포되는 파이프라인. Vercel에 GitHub 연동해서 push하면 자동 배포되는 것 자체가 CI/CD의 가장 간단한 형태. 클라우드 네이티브 : 특정 기술이 아니라 방향성/철학. "이런 관점이 있다" 정도로 알아두면 충분한 개념.