'멋진 기술'보다 '돌아가는 기술' — 바이브 코딩 MVP 스택 가이드 (초보자 용어풀이 포함)

한 줄 결론 — 바이브 코딩(vibe coding: AI에게 자연어로 지시해 코드를 만들게 하는 개발 방식)으로 서비스를 낼 때, 스택(기술 조합)을 고르는 기준은 "가장 멋진 기술"이 아니라 딱 세 가지다 — ① AI가 안정적으로 코드를 짜주는가, ② 내가 이해할 수 있는가, ③ 배포·운영이 너무 비싸지 않은가. 이 글은 그 기준으로 고른 현실적인 조합을 정리하되, 초보자도 읽을 수 있게 용어를 그때그때 풀어 쓴다. (가격·사양은 시점·플랜·지역에 따라 변하니 공식 문서 확인이 전제다.)

멋진 기술보다, 돌아가고 이해되고 안 비싼 기술 — 바이브 코딩 MVP 스택

전제부터 맞추자. 이 가이드는 이런 상황을 가정한다 — 혼자 또는 소규모로 만드는 MVP(Minimum Viable Product, 핵심 기능만 담아 빠르게 검증하는 최소 제품), 초기 트래픽은 낮음, 서버 운영도 어느 정도 배우고 싶음, 민감정보나 고신뢰 결제는 아직 안 다룸. 이 조건이라면 아래 조합이 꽤 실용적이다. (조건이 다르면 답도 달라진다 — 그 경계도 같이 짚는다.)

1. DB는 일단 PostgreSQL을 기본값으로

💡 DB(데이터베이스): 데이터를 저장·검색하는 창고. 회원, 글, 주문 같은 걸 담는다.

PostgreSQL(포스트그레스, 오픈소스 관계형 DB)을 기본값으로 잡는 편이 좋다. 그렇다고 SQLite(에스큐엘라이트)가 나쁘단 뜻은 절대 아니다. SQLite는 서버 프로세스가 따로 없는 임베디드 DB(앱 안에 통째로 들어가는 DB)이고, 단일 파일 하나로 동작한다. 트래픽 낮은 웹사이트나 로컬 앱에선 충분히 빠르고 단순하다 — SQLite 공식 문서도 low-to-medium traffic 웹사이트에서 잘 동작한다고 설명한다. 다만 쓰기가 폭주하는(write-intensive) 서비스, 여러 서버에서 동시에 접근하는 구조, 동시에 쓰는 사람(writer)이 많은 구조에선 PostgreSQL 같은 client/server DB(별도 서버로 도는 DB)가 더 맞는다.

바이브 코딩 기준으로 PostgreSQL을 미는 이유는 성능보다 '구조' 때문이다. 실제 서비스에서 흔히 쓰이고, 나중에 managed DB(관리형 DB — 백업·업데이트를 업체가 대신 해주는 유료 DB)로 옮기기 쉽고, Prisma·Drizzle·SQLAlchemy·pgx·TypeORM 같은 ORM(객체-DB 연결 도구) 생태계와 잘 맞는다. 무엇보다 PostgreSQL은 예제와 문서가 워낙 풍부해서, AI에게 스키마(표 설계)·마이그레이션(DB 구조 변경 관리)·트랜잭션(여러 작업을 한 묶음으로)·인덱스(검색 빠르게 하는 색인)를 설명시키기 좋다.

정리하면: 로컬 앱·개인 도구·읽기 위주 소형 사이트라면 SQLite로 충분하다. 하지만 로그인·결제·관리자·API·모바일 연동이 들어가는 일반 웹서비스라면 PostgreSQL을 기본값으로 두는 편이 안전하다.

SQLite는 파일 하나, PostgreSQL은 별도 서버 — 언제 무엇을

2. 백엔드는 직접 만들고, 초기엔 VPS에 올려도 된다

💡 백엔드(backend): 화면 뒤에서 도는 서버 쪽 코드. 로그인 처리, DB 저장, 결제 같은 걸 담당. / VPS(Virtual Private Server): '남의 컴퓨터 한 조각'을 월세로 빌려 내 맘대로 쓰는 가상 서버. / BaaS(Backend as a Service): 백엔드를 직접 안 짜고 업체가 만들어 둔 걸 갖다 쓰는 것.

BaaS를 무조건 피하란 뜻은 아니다. Firebase·Supabase·Amplify는 MVP를 빠르게 찍어낼 때 여전히 유용하다 — 특히 인증(로그인)·파일 스토리지·권한·리얼타임·서버리스 함수가 필요하고 서버 운영을 배우고 싶지 않다면 BaaS가 더 빠르다.

다만 서버 운영을 배우고 싶고, 작은 실험 서비스를 계속 만들 생각이라면 직접 백엔드를 짜서 VPS에 올리는 방식이 좋다. 초기 저트래픽 실험이라면 월 5~7달러급 VPS 한 대에 백엔드 + PostgreSQL + Redis(초고속 임시 저장소)+cron job(정해진 시각에 자동 실행되는 작업)+간단한 worker(뒤에서 무거운 일 처리하는 프로세스)까지 같이 올릴 수 있다. 단 가격은 업체·지역마다 다르다 — Hetzner는 2026-06-15 이후 유럽 CX23이 월 $6.49, CAX11이 월 $6.99로 조정됐고, DigitalOcean Droplet은 월 $4부터 시작한다.

⚠️ "월 5~7달러"는 서버 본체 가격에 가깝지, 서비스 전체 비용이 아니다. IPv4·부가세(VAT)·스냅샷·백업·원격 object storage·도메인·이메일 발송·LLM API 비용은 전부 별도다. 실제 월 비용은 이걸 다 더해서 잡아야 한다.

운영을 배우려면 관리형 서비스를 클릭 몇 번으로 쓰는 것보다 직접 구성해보는 게 얻는 게 많다. 하지만 실제 고객 데이터가 중요해지는 순간엔 managed DB, 아니면 최소한 자동 백업·복구 테스트·모니터링이 필수다. PostgreSQL 공식 문서도 정기 백업을 전제로 SQL dump·file-system backup·continuous archiving(변경 내역을 계속 아카이브) 같은 방식을 설명한다.

한 가지 더 — DB·앱·Redis를 같은 VPS 한 대에 몰아넣는 구성은 "장애 격리"가 약하다(그 서버가 죽으면 전부 같이 죽는다). 공개 사용자·유료 고객·복구 책임이 생기면, managed DB로 옮기거나 DB 서버를 분리하고 원격 백업을 두는 시점을 미리 정해 두자.

직접 운영한다면 백업을 같은 VPS 디스크에만 두면 안 된다(그 디스크가 죽으면 백업도 같이 죽는다). pgBackRest 같은 도구로 WAL archiving(DB의 모든 변경 기록을 순서대로 보관 — 사고 시점 직전까지 복구 가능)을 켜고, 다른 저장소나 다른 서버에 백업을 두어야 한다. pgBackRest는 PostgreSQL 백업·복구와 WAL archiving의 대표 도구이며, 원격 저장소와 다중 repository 구성이 가능하다.

3. 프로젝트 구조는 monorepo 하나로 충분

💡 monorepo(모노레포): 여러 역할의 코드를 저장소(repo) 하나에 폴더로 나눠 담는 방식. 반대는 저장소를 잘게 쪼개는 것.

처음부터 마이크로서비스(기능마다 서버를 잘게 쪼개는 구조)로 과하게 나눌 필요 없다. 저장소 하나에 역할별 폴더를 두는 monorepo면 충분하다.

vibe-project/
  frontend/     # 실제 웹 앱
  backend/      # API 서버
  landing/      # 랜딩 페이지, 블로그, SEO용 페이지
  infra/        # docker-compose, nginx/caddy, 배포 스크립트
  tools/        # 운영 스크립트, 데이터 정리, 배치 작업
  docs/         # 설계 문서, API 문서, 의사결정 기록
  AGENTS.md     # AI 에이전트용 작업 규칙

frontend·backend·landing을 나눠 두면 나중에 웹 앱·모바일 앱·랜딩을 따로 굴리기 쉬워진다. 처음부터 복잡하게가 아니라, 나중에 커졌을 때 덜 꼬이게 하는 정도로만 잡으면 된다. (AGENTS.md는 AI에게 "이 프로젝트에선 이렇게 짜라"를 알려주는 규칙 파일이다.)

4. 백엔드 언어는 Go · Python · TypeScript 중 하나면 충분

백엔드 언어는 취향을 많이 타지만, 바이브 코딩 기준으로는 Go·Python·TypeScript 중 하나면 무난하다.

개인적으로는 Go + Gin 조합을 추천할 만하다. Gin은 Go 기반 HTTP 웹 프레임워크로, 라우팅(주소→기능 연결)과 middleware(요청이 지나가는 중간 처리 층) 구조가 단순하다. 공식 문서도 Gin을 REST API·웹 앱·마이크로서비스에 적합한 고성능 프레임워크로 설명한다. Go의 진짜 장점은 배포가 단순하다는 것 — 바이너리(실행 파일) 하나로 빌드해 systemd나 Docker로 띄우기 쉽고, 정적 타입(값의 종류를 미리 못박아 컴파일 단계에서 오류를 잡는 방식) 덕에 AI가 만든 코드의 실수를 실행 전에 걸러내기 좋다.

⚠️ 다만 "AI가 Go 코드를 항상 더 잘 만든다"는 식의 일반화는 금물이다. 검증된 사실이라기보다 경험담에 가깝다.

Python FastAPI는 빠르게 만들기 좋고(Python type hint 기반 고성능 API), TypeScript NestJS/Express는 프론트엔드와 언어를 맞출 수 있다는 장점이 있다. 정리하면 — 프론트가 이미 익숙하면 TypeScript, 데이터·AI 파이프라인이 많으면 Python, 배포 단순함·정적 타입·낮은 운영 복잡도를 원하면 Go.

5. 이미지·음성·파일은 Cloudflare R2에

💡 object storage(오브젝트 스토리지): 사진·영상·파일 같은 '덩어리 데이터'를 통째로 넣어두는 전용 창고. DB에 파일을 직접 넣으면 무거워지니 따로 둔다. / egress(이그레스): 저장소에서 데이터가 밖으로 나갈 때 드는 통신 비용. 큰 서비스에선 이게 은근히 비싸다.

이미지·음성·첨부·export 파일은 DB에 넣지 말고 object storage에 넣는 편이 좋다. 이 용도로 Cloudflare R2가 꽤 좋은 선택지다.

정확히 말하면 R2는 "트래픽이 완전 무료"가 아니라 "egress bandwidth 요금이 없다"가 맞다. 저장 용량과 요청(Class A/B operation) 비용은 발생한다 — Cloudflare 공식 가격 문서도 그렇게 설명한다. R2는 S3-compatible API(아마존 S3와 호환되는 방식 — 기존 S3 코드·라이브러리를 거의 그대로 재사용)를 제공한다.

실서비스에선(특히 공개 정적 파일 기준) r2.dev 개발용 주소를 그대로 쓰기보다 custom domain(내 도메인 연결)을 붙이고 Cloudflare Cache(전 세계 edge, 즉 사용자와 가까운 서버에 미리 복사본을 두는 캐시)를 같이 쓰는 게 낫다. custom domain에서 캐시를 켜면 읽기 요청이 R2 본체를 우회해 가까운 edge에서 제공돼 지연이 준다. (반대로 비공개 파일이라면 signed URL 등 접근 제어와 캐시 무효화를 따로 설계해야 한다.) 단, 캐시된 데이터는 즉시 최신을 반영하지 않을 수 있다. 그리고 R2 위치를 두고 "일본에서 가져온다" 같은 표현은 빼자 — R2 버킷은 기본이 Automatic location(생성 요청 위치와 가까운 가용 지역 자동 선택)이고, Location Hint(APAC 등)는 힌트일 뿐 보장은 아니다.

6. LLM은 "가장 싼 모델"이 아니라 "품질 만족하는 가장 싼 모델"

💡 LLM(Large Language Model): ChatGPT·Claude 같은 대형 언어 모델. / token(토큰): AI가 글을 세는 단위(대략 단어 조각). 요금이 토큰 수로 매겨진다. / zero data retention(ZDR): 내가 보낸 데이터를 업체가 저장하지 않는 정책.

LLM 기능을 붙일 땐 처음부터 비싼 모델을 고정하지 말고 저렴한 모델부터 테스트하자. DeepSeek는 가성비 후보다 — 공식 API 기준 deepseek-v4-flash가 100만 토큰당 입력(cache miss) $0.14 / 출력 $0.28, deepseek-v4-pro가 입력 $0.435 / 출력 $0.87이다. 또 기존 deepseek-chat·deepseek-reasoner 모델명은 2026-07-24 15:59 UTC에 deprecated(지원 종료 예정)라고 공지돼 있다.

⚠️ DeepSeek엔 데이터 주의가 필요하다. 개인정보 처리방침상 서버가 중국에 있고, 개인정보를 중국에서 직접 수집·처리하며, 비식별화된 프롬프트가 모델 훈련·최적화 목적으로 이전될 수 있다고 밝힌다. 따라서 개인 식별정보·기업 내부 문서·고객 데이터·결제·의료/법률/금융 민감정보는 기본적으로 보내지 않는 설계를 해야 한다.

OpenRouter는 여러 모델·업체를 API 하나로 다뤄 편하다. 하지만 편의성과 비용·데이터 통제는 다르다 — 기본 라우팅은 가격 우선 load balancing이고, provider.only·order·allow_fallbacks·max_price·data_collection·zdr 설정으로 라우팅과 데이터 정책을 제어할 수 있다. 업체를 지정하지 않고 쓰면 원하는 업체·지연시간·데이터 보관 정책을 정확히 통제하지 못할 수 있다.

정리 — 비용 민감 기능은 DeepSeek 같은 저렴한 모델부터, 품질이 모자라면 OpenAI·Anthropic·Google 계열과 비교, OpenRouter는 provider·data policy를 명시, 개인정보·기밀이 들어가면 ZDR 또는 엔터프라이즈급 업체를 따로 검토.

7. 앱은 Flutter가 여전히 좋은 기본값

💡 cross-platform(크로스플랫폼): 코드 하나로 Android·iOS 등 여러 OS 앱을 만드는 것. 반대는 OS마다 따로 만드는 '네이티브'.

Android와 iOS를 동시에 내야 하고 팀이 작다면 Flutter는 여전히 강한 선택지다(공식적으로 하나의 코드베이스로 mobile·web·desktop·embedded를 만든다). 한국 시장은 반반이 아니다 — 2026년 6월 StatCounter 기준 한국 모바일 OS는 Android 65.79%, iOS 34.19%. 그래도 둘 다 무시 못 할 규모라, 네이티브를 따로 짜기 부담스러운 1인·소규모엔 cross-platform이 합리적이다.

예전 Flutter의 약점이던 "운영 중 코드 업데이트가 어렵다"는, Shorebird가 대안이 될 수 있다. Shorebird Code Push는 앱스토어 심사 없이 Flutter의 Dart 코드 업데이트를 바로 배포하게 해준다. 단, 네이티브 코드·asset·이미지·폰트·pubspec asset 변경은 patch가 아니라 새 스토어 릴리스가 필요하다.

즉 — 양쪽 플랫폼에 빠르게 내야 하면 Flutter를 1순위로, Shorebird로 Dart 코드 수준의 빠른 패치까지. 다만 네이티브 기능이 많은 앱, 플랫폼별 UX가 중요한 앱, 고성능 그래픽·영상·BLE·카메라·결제 SDK 의존이 큰 앱은 React Native나 네이티브 개발도 비교하자.

8. 웹은 landing과 app을 나눈다

💡 SSG/정적 사이트: 미리 만들어 둔 HTML을 그대로 뿌리는 방식 — 빠르고 SEO(검색 노출)에 유리. / SPA(Single Page Application): 페이지를 새로 안 불러오고 화면만 바꾸는 앱형 웹 — 대시보드·관리자에 적합. / CDN: 전 세계에 흩어진 서버로 콘텐츠를 빠르게 배달하는 망.

웹은 둘로 나눠 생각하는 게 좋다. 랜딩·블로그·문서·SEO 중심 페이지는 Astro가 좋다(공식적으로 content-driven website에 최적화, marketing·blog·e-commerce 용도 강조). 로그인 후 쓰는 웹 앱·대시보드·관리자처럼 상호작용 많은 화면은 React SPA로 충분하다. React·Vue·Svelte 다 되지만, 초보자와 AI 코딩 자료 접근성을 기준으로는 React가 무난한 기본값이다.

배포는 Cloudflare Workers/Pages 계열이 편하다 — 프론트 정적 자산을 Cloudflare CDN/캐시로 배포하고, 백엔드 API도 Workers로 만들 수 있다. Workers Paid 플랜은 계정당 월 $5 minimum이며 data transfer/throughput 추가 요금이 없다고 안내한다. 단 요청·스토리지·연산의 사용량 초과와 부가 서비스 과금은 별도다.

9. "무료 티어만" vs "무조건 VPS" — 둘 다 극단이다

바이브 코딩 프로젝트는 실패 확률이 높다. 그래서 무료 티어로 시작하자는 주장은 타당하다(Supabase도 무료 플랜에서 2개 프로젝트, Firebase도 무료 Spark plan 제공). 다만 무료 티어는 어디까지나 '검증용'이지 운영 안정성을 보장하는 선택지가 아니다. 보통 한계가 붙는다 — 프로젝트 수, sleep/pausing(안 쓰면 잠드는 것), 저장·egress·백업·로그 보관·support·SLA(서비스 품질 보장) 제약. Supabase도 Pro 플랜부터 daily backup 7일 보관 같은 운영 기능이 붙는다.

반대로 VPS는 싸지만 운영 책임이 생긴다 — 보안 업데이트·SSH·방화벽·TLS·백업·복구 테스트·모니터링·로그 로테이션·디스크 풀 대응·DB 마이그레이션을 직접 챙겨야 한다.

현실적인 기준 — 처음 1~2개 실험은 BaaS·무료 티어로 빠르게 검증해도 된다. 하지만 여러 서비스를 반복해서 만들고, 서버 운영을 배우고, 공통 인증·결제·관리자 템플릿을 쌓을 생각이라면 VPS 기반 템플릿이 장기적으로 효율적이다.

무료 티어(빠르지만 한계) ↔ VPS(싸지만 운영 책임) — 극단 사이의 현실 기준

10. 최소 운영 체크리스트

MVP라도 외부 사용자에게 공개한다면 아래는 최소한 챙기자.

영역	챙길 것
배포	GitHub Actions 또는 간단한 deploy script · rollback(되돌리기) 가능한 배포 · env/secrets 분리
서버	SSH key 로그인 · password 로그인 비활성화 · 방화벽 · 자동 보안 업데이트 · Caddy/Nginx로 TLS 자동화
DB	migration 관리 · 정기 백업 · 원격 백업 저장 · 복구 테스트 · 디스크 사용량 alert
앱	error tracking · request logging · rate limit(요청 제한) · admin 계정 보호 · 이메일 인증/비번 재설정 · 개인정보 최소 수집
비용	VPS · object storage · LLM API · 이메일 발송 · domain/DNS

⚠️ 백업은 "설정했다"로 끝내면 안 된다 — 실제로 복구되는지 테스트해야 한다. PostgreSQL의 continuous archiving/PITR(Point-In-Time Recovery, 특정 시점으로 되돌리기)도 WAL 파일이 제대로 보존돼야 의미가 있다.

댓글 반박용 Q&A

바이브 코딩 스택 글엔 늘 같은 반박이 달린다. 미리 정리해 두자.

"스택이 너무 무겁다" → 맞을 수 있다. 한 번만 만들 거면 BaaS가 더 빠르다. 하지만 여러 개를 만들 거라면 인증·유저·관리자·결제·파일 업로드·배포·백업을 템플릿화할 수 있어 오히려 빨라진다.
"무조건 무료로 해야 한다" → 일부 맞다. 검증 전엔 무료 티어가 좋다. 다만 월 5~7달러 VPS는 서버 운영을 배우고 여러 실험을 동시에 돌리는 값으로 보면 과하지 않다. 단 IPv4·부가세·백업·object storage·LLM API까지 포함한 실제 비용을 계산하자.
"초보자는 못 한다" → 맞다. 완전 초보라면 서버 없는 로컬 앱·브라우저 확장·정적 사이트·Firebase/Supabase 앱부터가 낫다. 서버가 필요한 서비스를 만들 거면 최소한 Linux·SSH·Docker·PostgreSQL 백업·DNS·TLS 정도는 배워야 한다.
"DHH도 VPS와 Rails를 말한다" → 인용은 조심하자. 정확히는 Rails 8이 "No PaaS Required" 방향으로 Kamal 2(클라우드 VM이나 물리 서버에 컨테이너 앱을 배포하는 도구)를 기본 배포 경로에 넣은 것이다. self-host/VPS 전략과 맞닿지만, 특정 인물 발언을 과장해 인용할 필요는 없다.

흔한 함정 — 멋진 기술 고르다 배포 지옥, 무료 티어 믿다 데이터 증발, 결국 복구 테스트

최종 추천 스택 (한눈에)

영역	추천	메모
DB	PostgreSQL	로컬·소형 읽기 위주면 SQLite
Backend	Go + Gin	대안: Python+FastAPI, TS+NestJS/Express
Hosting	초기 VPS 1대	중요도 오르면 managed DB/플랫폼
Backup	pgBackRest + 원격 object storage	복구 테스트 필수
File	Cloudflare R2	custom domain + Cache, egress 무료지만 저장·요청 비용
LLM	저비용부터 테스트	DeepSeek 비용 강점(단 민감정보 제외 설계 전제), OpenRouter는 provider/data policy 명시
Mobile	Flutter	Shorebird는 Dart 패치에 유용, native/asset 변경은 store release
Web	Landing=Astro / App=React SPA	배포는 Cloudflare Workers/Pages
Repo	monorepo	frontend·backend·landing·infra·tools·docs·AGENTS.md

초보자용 용어 사전 (한 번에 모아보기)

바이브 코딩 — AI에게 자연어로 지시해 코드를 만들게 하는 개발 방식.
MVP — 핵심 기능만 담아 빠르게 검증하는 최소 제품.
스택 — DB·언어·서버 등 기술 조합.
DB / PostgreSQL / SQLite — 데이터 창고 / 서버형 관계형 DB / 파일 하나짜리 임베디드 DB.
ORM — 코드의 객체와 DB를 이어 주는 도구(Prisma·Drizzle 등).
마이그레이션 — DB 구조 변경을 버전으로 관리하는 것.
백엔드 / 프론트엔드 — 화면 뒤 서버 코드 / 사용자가 보는 화면.
VPS — 남의 컴퓨터 한 조각을 월세로 빌린 가상 서버.
BaaS — 백엔드를 직접 안 짜고 갖다 쓰는 서비스(Firebase·Supabase).
managed(관리형) — 백업·업데이트를 업체가 대신 해 주는 유료 방식.
object storage / egress — 파일 전용 창고 / 데이터가 밖으로 나갈 때의 통신 비용.
WAL / PITR — DB 변경 기록 / 특정 시점으로 되돌리는 복구.
LLM / token / ZDR — 대형 언어 모델 / 요금 단위 / 데이터 미저장 정책.
cross-platform / code push — 코드 하나로 여러 OS 앱 / 심사 없이 코드 업데이트 배포.
SSG(정적) / SPA / CDN — 미리 만든 페이지 / 화면만 바꾸는 앱형 웹 / 전 세계 배달망.
monorepo — 저장소 하나에 역할별 폴더로 담는 방식.

정리

스택 기준은 "멋진 기술"이 아니라 "AI가 짜주고 · 내가 이해하고 · 안 비싼가" 세 가지.
기본값: PostgreSQL · Go+Gin · VPS · R2 · Astro/React · Flutter · monorepo. 조건이 다르면(로컬앱=SQLite, 운영 배우기 싫음=BaaS) 답도 바뀐다.
무료 티어 vs VPS는 양극단 — 초기 검증은 무료, 반복·운영학습은 VPS 템플릿.
가장 중요한 한 줄: 백업은 "설정"이 아니라 "복구 테스트"까지 해야 진짜다.

출처·참고 (공식 문서)

DB: SQLite — Appropriate Uses · PostgreSQL 백업/복구 · pgBackRest
호스팅/가격: Hetzner Cloud · DigitalOcean Droplet 가격 (가격은 시점·지역·플랜에 따라 변동)
스토리지: Cloudflare R2 가격 · R2 custom domain/cache
백엔드: Gin · FastAPI
LLM: DeepSeek API 가격 · DeepSeek 개인정보 처리방침 · OpenRouter 라우팅 문서
앱/웹: Flutter · Shorebird Code Push · Astro · React · Cloudflare Workers 가격
BaaS/무료 티어: Supabase 가격 · Firebase 가격
통계/기타: StatCounter 한국 모바일 OS (mobile OS·South Korea·2026-06, 2026-07-03 확인) · Rails 8 / Kamal

※ 이 글의 가격·요금·모델명·점유율·deprecated 일정 등은 시점·플랜·지역에 따라 바뀌며(본문 수치는 2026-07-03 기준), 각 항목은 위 공식 문서를 출처로 한다. 반드시 최신 공식 문서로 재확인할 것. 삽화는 AI로 생성한 개념 이미지다.