어떤 현대식 클라우드 데이터베이스를 선택해야 할까? 기능보다 사용 방식이 먼저다

이 글은 입문용 배포 가이드의 기본값(Supabase, Firestore)을 넘어, 프로덕션 데이터베이스를 직접 고르는 단계에 있는 독자를 위한 심화 가이드입니다. 첫 서비스의 데이터 저장 방식과 비용 구조를 확정하기 전에 읽으면 좋습니다.

AI 코딩 도구 덕분에 웹 서비스 하나를 만드는 데 필요한 시간은 크게 줄었다. 사용자 화면과 서버 기능을 만들고 인터넷에 공개하는 일까지 몇 시간이나 며칠 안에 끝낼 수 있다. 데이터베이스도 목록에서 하나를 골라 연결 정보만 입력하면 일단 작동한다.

문제는 서비스가 실제로 사용되기 시작한 뒤 나타난다.

사용자가 늘자 데이터 조회 비용이 예상보다 빠르게 증가한다. 화면을 자동으로 갱신하는 기능 하나가 수많은 데이터 읽기를 만든다. 동시에 실행되는 서버 기능이 늘면서 PostgreSQL 접속 수가 한계에 도달한다. 글로벌 서비스를 위해 서버 지역을 추가했더니 데이터 복사와 전송 비용이 커진다. 초기에는 편리했던 특정 플랫폼의 기능이 나중에는 이전을 어렵게 만들기도 한다.

그래서 데이터베이스 선택은 “어느 제품이 가장 좋은가?”보다 **“우리 서비스는 데이터를 어떻게 저장하고 얼마나 자주 읽고 쓰는가?”**라는 질문에서 시작해야 한다.

이 글에서 말하는 클라우드 데이터베이스는 인터넷을 통해 이용하는 데이터 저장 서비스를 뜻한다. **서버리스(Serverless)**는 서버가 없다는 뜻이 아니라, 서버 설치·관리·확장을 서비스 제공업체가 대신해 준다는 뜻이다. 개발자는 서버를 직접 관리하는 대신 사용량이나 선택한 용량에 따라 비용을 낸다.

60초 선택 가이드

이 글은 2026-09-02 기준 각 서비스의 공식 문서를 바탕으로 작성했다. 가격과 기능은 계속 바뀌므로 도입 전 반드시 공식 문서에서 다시 확인해야 한다.

이 표는 출발점이지 보편적인 순위가 아니다. 실제 읽기·쓰기 방식, 보안 규칙, 지연시간 목표, 예상 비용으로 선택을 검증해야 한다.

‘가장 저렴하고 확장성 좋은 DB’는 존재하지 않는다

서버리스 데이터베이스는 흔히 서버 관리가 필요 없고 사용한 만큼만 비용을 내는 제품으로 소개된다. 대체로 맞는 설명이지만, 이것만으로는 프로덕션 비용과 성능을 예측하기 어렵다.

제품마다 과금 단위가 다르기 때문이다.

• 어떤 제품은 데이터베이스 서버가 실제로 작동한 시간을 기준으로 과금한다.
• 어떤 제품은 읽고 쓴 문서나 행의 수를 계산한다.
• 어떤 제품은 요청 단위와 데이터 크기를 함께 본다.
• 어떤 제품은 기본 서버 비용에 저장 공간, 백업, 데이터 복사본, 외부 전송 비용을 더한다.
• 인증, 파일 저장소, 실시간 동기화까지 포함하면 DB 단가보다 전체 시스템 비용이 더 중요해진다.

따라서 비용은 대략 다음과 같이 봐야 한다.

월간 데이터 비용 = 기본 사용료 + 서버가 작동한 시간 또는 요청량 + 저장 공간·검색용 색인 + 복사본·백업 + 외부 데이터 전송 + 부가 기능

서버리스라는 이름이 항상 저렴함을 보장하지 않는다. 사용하지 않는 시간이 긴 서비스에는 **쓰지 않을 때 서버 자원을 0에 가깝게 줄이는 방식(scale-to-zero)**이나 요청한 만큼만 내는 방식이 유리하다. 반대로 하루 종일 사용량이 꾸준히 많다면 일정한 서버 용량을 유지하거나 필요한 용량을 미리 확보해 두는 방식이 더 저렴할 수 있다.

먼저 세 가지를 묻자

제품 비교표를 보기 전에 다음 세 질문에 답하는 편이 빠르다.

1. 데이터는 어떤 모양인가

주문, 고객, 계약, 권한처럼 여러 정보의 관계가 중요한가? 결제처럼 여러 데이터 변경을 한 묶음으로 안전하게 처리해야 하는가? 그렇다면 PostgreSQL 같은 관계형 데이터베이스가 자연스럽다. 로그인 상태, 장바구니, 기기 기록처럼 정해진 번호나 이름으로 빠르게 찾는 데이터라면 DynamoDB 같은 키값·문서형 데이터베이스가 잘 맞을 수 있다. 모바일에서 데이터가 곧바로 바뀌고 인터넷이 끊겨도 사용할 수 있어야 한다면 Firestore의 편리한 기능이 큰 가치를 만든다.

2. 사용량은 어떤 모양인가

평소에는 거의 사용하지 않다가 특정 시간에 급증하는가, 아니면 하루 종일 꾸준한가? 읽기가 대부분인가, 쓰기가 많은가? 세계 여러 지역의 사용자와 가까운 위치에서 데이터를 읽어야 하는가? 같은 월간 요청 수라도 사용량이 언제, 어디서 몰리는지에 따라 적합한 요금과 확장 방식이 달라진다.

3. 데이터베이스 밖에서 무엇이 필요한가

로그인과 사용자 관리, 사진·파일 저장, 실시간 업데이트, 모바일 앱 개발 도구, 여러 지역의 데이터 복사본까지 필요한가? 데이터베이스 가격만 비교하면 이런 기능을 따로 만드는 비용을 놓친다. 반대로 편리하다는 이유로 쓰지 않을 기능까지 포함된 플랫폼을 선택하면 비용이 늘고 나중에 다른 서비스로 옮기기 어려워질 수 있다.

플랫폼인지, 데이터베이스인지부터 구분하자

같이 거론되는 제품들은 실제로 다른 계층에 있다. **BaaS(Backend as a Service)**인 Supabase와 Firebase는 데이터베이스에 로그인, 파일 저장소, 실시간 동기화 같은 백엔드 기능을 묶어 판다. DB 플랫폼인 Neon, PlanetScale, CockroachDB는 데이터베이스 자체를 서비스하며 주변 기능은 최소화한다. 엣지·로컬 우선 DB인 D1과 Turso는 데이터를 사용자 가까이 또는 기기 안에서 처리하는 데 초점을 둔다.

• BaaS(Supabase, Firebase): 데이터베이스 + 인증·스토리지·실시간 기능이 묶인 백엔드 전체. 출시 속도가 핵심일 때 유리하다.
• DB 플랫폼(Neon, PlanetScale, CockroachDB): 데이터베이스 자체가 상품. 주변 기능은 직접 구성하는 대신 성능과 비용 구조를 세밀하게 다룬다.
• 엣지·로컬 우선 DB(D1, Turso): 데이터를 사용자 가까이 또는 기기 안에서 처리. 글로벌 읽기 속도나 로컬 우선 동작이 핵심일 때 검토한다.

대부분의 첫 웹앱을 위한 기본값

아직 명확한 이유가 없다면 기본값에서 시작하는 편이 가장 안전하다.

• 일반적인 웹앱 → Supabase: SQL 데이터베이스와 인증, 스토리지, 실시간 기능을 한곳에서 갖춘다.
• 모바일·실시간·오프라인이 핵심인 앱 → Firestore: 클라이언트 동기화와 오프라인 사용을 기본으로 제공한다.

이 기본값은 배포 가이드의 권장과도 일치한다. 다음 조건 중 하나에 해당하면 그때 기본값을 벗어나 이 글의 비교 표를 활용한다.

기본값에서 벗어나야 하는 조건

• PostgreSQL 호환성을 유지하며 scale-to-zero가 필요하다 → Neon
• Cloudflare Workers 기반이라 통합이 중요하다 → D1
• 로컬 우선 동작이나 사용자·에이전트별 격리 DB가 구조의 핵심이다 → Turso
• AWS 생태계와의 깊은 통합, 명확한 키 기반 접근이 필요하다 → DynamoDB
• 대규모 관리형 SQL 운영이나 안전한 DB 분기가 핵심이다 → PlanetScale
• 여러 리전에 걸친 강한 트랜잭션 일관성이 사업 요구사항이다 → CockroachDB Cloud

현대식 데이터베이스를 세 그룹으로 이해하기

1. 일반적인 업무 데이터에 강한 제품: Supabase, Neon, PlanetScale, CockroachDB

고객·주문·상품처럼 서로 연결된 데이터를 다루고 표 형태로 검색하는 SQL 방식이 필요하다면 이 그룹부터 검토하는 것이 합리적이다. 같은 PostgreSQL·SQL 계열이라도 제품마다 강점은 다르다.

Supabase는 PostgreSQL 데이터베이스에 로그인·사용자 관리, 파일 저장, 실시간 업데이트, 서버 기능과 사용자별 데이터 접근 제어를 함께 제공한다. 여러 서비스를 따로 연결하지 않고 제품을 빠르게 출시하려는 팀에 강하다. 데이터베이스 가격만 보면 다른 선택지가 저렴할 수 있지만, 필요한 기능을 만들고 관리하는 전체 비용까지 포함하면 Supabase가 더 경제적일 수 있다.

Neon은 데이터를 보관하는 공간과 실제 작업을 수행하는 서버 자원을 분리한다. 사용하지 않을 때 서버 자원을 줄이고, 사용량이 늘면 자동으로 키우며, 개발 작업별로 별도의 데이터베이스 복사본을 쉽게 만들 수 있다. 가끔 사용하는 서비스나 여러 테스트 환경이 필요한 팀에 특히 잘 맞는다. 다만 하루 종일 사용량이 많은 서비스에서는 서버 작동 시간이 계속 쌓이므로 실제 월 비용을 다시 계산해야 한다.

PlanetScale은 PostgreSQL과 MySQL 호환 방식을 제공하며, 개발용 데이터베이스 복사본을 만들고 변경 사항을 안전하게 적용하는 기능이 강하다. 매우 큰 MySQL 계열 시스템에서는 데이터를 여러 서버에 나누어 저장하는 기능도 활용할 수 있다. 개발용 복사본마다 별도의 서버 비용이 생길 수 있으므로 테스트 환경을 많이 유지하는 팀은 비용 구조를 확인해야 한다.

CockroachDB Cloud는 PostgreSQL용 도구를 활용하면서 여러 지역에 데이터를 나누어 보관해야 하는 서비스에 적합하다. 한 지역에 장애가 생겨도 서비스를 계속하고, 여러 지역의 데이터가 서로 어긋나지 않도록 관리하는 데 강점이 있다. 단순히 ‘글로벌 DB가 멋있어 보여서’ 선택할 제품은 아니다. 여러 지역에 데이터를 복사하고 전송하는 비용을 감수할 분명한 사업 요건이 있을 때 가치가 커진다.

2. 사용자 가까이 또는 기기 안에서 데이터를 처리하는 제품: Cloudflare D1과 Turso

Cloudflare D1은 Cloudflare의 서버 기능인 Workers와 자연스럽게 연결되는 가벼운 SQL 데이터베이스다. 서버가 작동한 시간보다 읽고 쓴 데이터의 줄 수와 저장 공간을 중심으로 비용을 계산한다. 여러 지역에 읽기용 복사본을 두어 사용자와 가까운 곳에서 데이터를 불러올 수도 있다. 데이터를 주로 읽는 가벼운 글로벌 서비스에 매력적이다.

그러나 ‘읽고 쓴 데이터 줄 수에 따른 과금’은 검색 방법이 곧 비용을 결정한다는 뜻이기도 하다. 검색용 색인 없이 데이터 전체를 훑으면 실제 결과가 한 건이어도 많은 데이터 줄을 읽은 것으로 계산될 수 있다. 적절한 검색용 색인은 속도뿐 아니라 비용까지 줄인다.

Turso는 사용자의 기기나 앱 안에서 데이터를 처리하고 클라우드와 맞추는 방식에 강하다. 사용자, 고객사 또는 AI 에이전트마다 작은 데이터베이스를 따로 두는 구조도 만들기 쉽다. 하나의 거대한 중앙 데이터베이스보다 수많은 독립 데이터베이스가 자연스러운 서비스라면 매력적이다. 반면 많은 사용자가 하나의 중앙 데이터베이스에 동시에 자주 기록하는 서비스는 실제 사용 환경에서 성능을 확인해야 한다.

3. 정해진 키로 빠르게 찾는 제품: Firestore와 DynamoDB

Cloud Firestore는 모바일·웹 앱 개발 도구, 데이터가 바뀌면 화면을 바로 갱신하는 기능, 인터넷이 끊겼을 때의 임시 저장과 접근 규칙을 함께 제공한다. 채팅, 협업, 모바일 앱처럼 여러 사용자 화면의 데이터를 바로 맞추는 일이 중요하면 개발 시간을 크게 줄일 수 있다.

비용은 데이터를 저장하고 불러오는 방식의 영향을 직접 받는다. 너무 많은 데이터를 한 번에 찾는 검색, 실시간 화면의 반복 갱신, 인터넷 재연결, 검색을 빠르게 하는 색인과 접근 규칙 확인이 읽기 횟수를 늘릴 수 있다. “한 화면을 여는 데 데이터 문서와 검색용 목록을 몇 개나 읽는가?”를 기능 설계 단계부터 계산해야 한다.

Amazon DynamoDB는 어떤 번호나 이름으로 어떤 데이터를 찾을지 미리 정할 수 있는 대규모 서비스에 강하다. 요청한 만큼 비용을 내는 방식은 필요한 서버 용량을 미리 계산해야 하는 부담을 줄여 준다. AWS의 여러 서비스와도 잘 연결된다. 사용량이 일정해진 뒤에는 필요한 처리 용량을 미리 확보하는 방식이 더 저렴한지 비교할 수 있다.

다만 여러 표를 나누어 저장한 뒤 필요할 때 서로 연결하는 일반적인 관계형 데이터베이스 방식과는 다르다. 앱의 각 기능이 어떤 기준으로 데이터를 찾을지 먼저 정하고, 데이터를 나누어 보관하고 빠르게 검색하는 기준을 그 방식에 맞춰 설계해야 한다. DynamoDB에서는 데이터를 어떻게 저장하느냐가 속도와 비용을 함께 결정한다.

한눈에 보는 선택 지도

이 표는 최종 답이 아니라 후보를 줄이는 출발점이다. 같은 웹서비스라도 데이터 구조, 사용자 지역, 팀의 SQL 경험과 현재 사용 중인 클라우드에 따라 답이 바뀐다.

확장성도 하나의 숫자가 아니다

“이 DB는 확장성이 좋다”는 말만으로는 부족하다. 무엇이 어떻게 확장되는지 나눠 봐야 한다.

• 서버 크기 확장: 사용량이 늘면 CPU와 메모리가 더 큰 서버로 옮길 수 있는가?
• 자동 확장: 사용량에 따라 서버 자원이나 처리 용량이 자동으로 늘고 줄어드는가?
• 서버 수 확장: 읽기용 데이터 복사본이나 데이터를 나누어 저장할 서버를 안전하게 추가할 수 있는가?
• 지역 확장: 여러 지역에서 읽고 쓸 수 있으며 각 지역의 데이터를 어떻게 맞추는가?
• 개발팀 확장: 개발자와 작업이 늘어도 서로 분리된 테스트 데이터베이스를 빠르게 만들고 정리할 수 있는가?

초기 스타트업에는 개발팀이 충돌 없이 빠르게 일하는 능력이 여러 나라에서 동시에 데이터를 쓰는 기능보다 더 중요할 수 있다. 반대로 여러 나라에서 결제나 재고를 동시에 처리한다면 지역마다 데이터가 어긋나지 않게 관리하고 장애에서 복구하는 능력이 핵심이다. 먼 미래의 막연한 확장보다 앞으로 12~18개월에 실제로 필요한 능력을 선택하는 편이 낫다.

비용이 예상보다 커지는 지점

검색을 빠르게 하는 색인

검색용 색인은 데이터를 더 빨리 찾게 해 주지만, 데이터를 저장하고 변경할 때 추가 작업과 공간이 필요하다. D1처럼 실제로 훑어본 데이터 줄 수가 과금에 반영되는 제품에서는 적절한 색인이 비용을 크게 낮출 수 있다. DynamoDB에서도 사용하지 않는 추가 검색용 목록은 쓰기와 저장 비용만 증가시킨다.

화면을 자동으로 갱신하는 기능

Firestore에서 실시간 화면 하나를 구현하는 코드는 간단하지만, 데이터가 바뀔 때마다 클라이언트에 전달되는 문서 읽기가 쌓일 수 있다. 연결 수보다 ‘한 번의 변경이 몇 명의 사용자에게 몇 개의 문서를 다시 읽게 하는가’를 봐야 한다.

개발용 데이터베이스 복사본

기능별로 별도의 개발용 데이터베이스 복사본을 만들면 개발 속도는 빨라진다. 하지만 자동 정리 규칙이 없으면 사용하지 않는 복사본이 계속 남는다. 개발 작업이 끝나면 지울 임시 복사본과 출시 전 점검을 위해 장기간 유지할 환경을 구분해야 한다.

백업과 데이터 복사본

문제가 생기기 전의 원하는 시점으로 되돌리는 기능, 장기 백업, 읽기용 복사본과 여러 지역의 데이터 복사본은 실제 서비스에 필요하지만 무료가 아닐 수 있다. 원본 데이터보다 복사본과 변경 기록이 더 많은 저장 공간을 차지할 수도 있다.

외부 데이터 전송과 서버 위치

앱의 서버 기능과 데이터베이스가 서로 먼 지역에 있으면 속도가 느려지고 데이터 전송 비용도 늘어난다. 여러 지역에 복사본을 두면 사용자와 가까운 곳에서 데이터를 빠르게 읽을 수 있지만, 모든 데이터를 모든 지역에 복사할 필요가 있는지는 따로 판단해야 한다.

제품을 고르기 전에 작게 시험해 보라

홍보 페이지와 가격 계산기만으로는 실제 비용을 예측하기 어렵다. 최종 후보 두 개를 골라 같은 데이터와 대표적인 앱 기능으로 2~4주간 작게 시험해 보는 편이 안전하다.

시험 기간에는 다음 항목을 비교한다.

• 대표 기능의 일반적인 응답시간과 가장 느린 5%·1% 요청의 응답시간
• 한동안 사용하지 않은 뒤의 첫 요청과 갑작스러운 사용량 증가 시 지연
• 앱의 주요 기능 한 번이 읽고 쓰는 데이터와 검색용 목록의 수
• 동시에 접속할 수 있는 앱의 수와 데이터베이스가 실제로 처리하는 연결 수
• 사용자가 없을 때, 평상시, 가장 많이 몰릴 때의 예상 비용
• 사용량이 현재 예상의 세 배가 되었을 때의 비용
• 백업, 특정 시점 복구, 데이터 복사본, 상태 확인 도구와 외부 데이터 전송을 포함한 월 비용
• 다른 데이터베이스로 옮기는 난이도와 특정 클라우드·개발 도구에 대한 의존도

성능 시험에는 실제 서비스와 비슷한 검색과 저장 작업을 사용해야 한다. 정해진 번호로 데이터 한 건을 찾는 단순한 속도 시험만으로는 복잡한 관리자 검색, 실시간 화면, 여러 데이터를 한꺼번에 처리하는 작업의 비용을 예측할 수 없다.

실전 선택 규칙

요구사항이 계속 바뀌고 SQL·인증·스토리지·실시간 기능을 함께 빠르게 만들고 싶다면 Supabase부터 검토한다.

PostgreSQL은 유지하되 사용량이 간헐적이고 개발용 데이터베이스 복사본을 저렴하게 만들고 싶다면 Neon이 자연스럽다.

Cloudflare Workers 안에서 읽기 중심의 가벼운 SQL 서비스를 만든다면 D1, 로컬 실행이나 사용자·에이전트별 소형 DB가 핵심이라면 Turso를 본다.

모바일 앱의 실시간 업데이트와 오프라인 사용이 중요하다면 Firestore, 데이터를 찾는 방식이 명확하고 갑작스러운 사용량 증가를 처리해야 하는 AWS 서비스라면 DynamoDB가 강하다.

대규모 SQL 서비스와 안전한 개발용 데이터베이스 복사, 데이터를 여러 서버에 나누는 기능이 필요하면 PlanetScale을 검토한다. 여러 지역의 중요한 업무 데이터가 항상 정확히 맞아야 한다면 CockroachDB Cloud를 검토한다.

결론: 데이터베이스 선택은 제품 선택이 아니라 비용 구조 선택이다

현대식 데이터베이스는 대부분 훌륭하다. 문제는 좋은 제품을 고르는 것이 아니라 내 서비스와 맞는 제품을 고르는 것이다.

Supabase는 데이터베이스와 여러 서버 기능을 한곳에 모으고, Neon은 사용량에 맞춰 PostgreSQL 서버 자원을 조절한다. D1은 Cloudflare Workers와 쉽게 연결되고, Turso는 기기 안의 데이터와 여러 개의 작은 데이터베이스에 강하다. Firestore는 모바일 데이터를 실시간으로 맞추기 쉽고, DynamoDB는 정해진 키로 대량의 요청을 처리하는 데 강하다. PlanetScale은 안전한 데이터베이스 변경을 돕고, CockroachDB는 여러 지역의 중요한 데이터를 일치시키는 데 강하다.

데이터베이스를 선택하는 순간 팀은 무엇을 기준으로 비용을 낼지, 사용량이 늘 때 어떻게 확장할지, 여러 곳의 데이터를 어떻게 일치시킬지, 개발과 이전은 얼마나 쉬울지까지 함께 선택한다. 그래서 기능표보다 먼저 앱이 데이터를 어떻게 읽고 쓰며 언제 사용량이 늘어나는지 그려야 한다. 그다음 실제와 비슷한 검색과 저장 작업으로 비용과 가장 느린 요청의 속도를 측정해야 한다.

가장 좋은 데이터베이스는 벤치마크에서 1등인 제품이 아니다. 지금의 팀이 빠르게 만들 수 있고, 서비스가 성장해도 비용과 운영을 설명할 수 있으며, 필요한 순간에 다음 단계로 옮겨갈 수 있는 데이터베이스다.

자주 묻는 질문

새 웹앱은 SQL과 NoSQL 중 무엇을 써야 할까?

데이터 관계와 검색 방식에서 시작한다. 계정, 팀, 주문, 구독, 리포팅은 대체로 SQL과 잘 맞는다. 실시간 모바일 상태, 오프라인 클라이언트, 명확한 키 기반 접근이 중요하면 문서형 또는 키-값 데이터베이스가 더 잘 맞을 수 있다.

Supabase는 데이터베이스인가, 백엔드 플랫폼인가?

Supabase는 PostgreSQL을 중심으로 만든 백엔드 플랫폼이다. Auth, Storage, Realtime, 함수가 설정 작업을 줄여주지만, 데이터베이스 전용 서비스와 비교할 때는 주변 플랫폼 기능까지 함께 평가해야 한다.

서버리스 데이터베이스는 언제 더 저렴할까?

사용량이 간헐적이고 유휴 컴퓨팅을 줄일 수 있을 때 경제적일 수 있다. 그러나 읽기, 쓰기, 색인, 복제본, 실시간 구독, 저장 공간, 데이터 전송으로 비용이 커질 수 있으므로 실제 워크로드와 맞는 과금 단위를 계산해야 한다.

작은 제품도 처음부터 멀티리전을 설계해야 할까?

대부분은 아니다. 사용자 위치, 계약, 지연시간, 가용성 목표가 요구할 때만 현재의 사업 요구사항으로 취급한다. 미래의 규모를 추측해 미리 도입하면 가치보다 비용과 운영 복잡도가 먼저 생긴다.

이 글은 2026년 9월 공개 정보를 기준으로 작성했다. 가격, 제한, 제품 기능은 바뀔 수 있으므로 도입 전 각 서비스의 공식 문서를 확인해야 한다.

참고 자료

• Supabase Database
• Supabase Branching
• Neon: Why Neon?
• Neon: Cost Optimization
• Cloudflare D1 Pricing
• Cloudflare D1 Limits
• Turso SDK Overview
• Cloud Firestore Pricing
• Amazon DynamoDB
• PlanetScale: Postgres vs. Vitess
• PlanetScale Postgres Pricing
• CockroachDB Cloud Costs

다음으로

• 배포 가이드로 돌아가기
• 다른 심화 가이드: AI Gateway와 로컬 LLM 선택 가이드
• CS Map 시스템 설계 Part 3 — 서비스 뒤의 시스템 설계 도시 설계도
• 데이터베이스 총정리 — 비개발자를 위한 데이터베이스 기초 시리즈(12편 + 부록)
• Beyond Vibe Coding Stage 0 — 개발 방식의 출발점 점검하기