데이터베이스 (Database)
데이터를 체계적으로 저장하고, 필요할 때 빠르게 찾아 쓸 수 있도록 정리해주는 디지털 저장소입니다.
같은 말:DB데이터베이스SQLNoSQL디비
목차
🤔 혹시 이런 경험 있나요?
AI에게 "회원가입 기능 만들어줘"라고 했더니 Supabase, Firebase, Neon 같은 서비스를 연결하라고 합니다. 또는 "데이터베이스 스키마를 설정하세요"라는 안내가 나옵니다. 대체 데이터베이스가 뭐고, 왜 앱을 만들 때마다 필요한 걸까요?
🗄️ 엑셀 스프레드시트의 진화판
가장 쉽게 이해하는 방법은 엑셀 스프레드시트를 떠올리는 것입니다.
엑셀에서 고객 명단을 관리한다고 생각해보세요. 이름, 이메일, 가입일을 열(Column)로 만들고, 한 명씩 행(Row)으로 추가합니다. 데이터베이스도 기본적으로 이와 같은 구조입니다. 다만 엑셀과 다른 점이 있습니다.
- 동시 접속: 수천 명이 동시에 읽고 쓸 수 있습니다.
- 속도: 수백만 건의 데이터에서도 원하는 정보를 빠르게 찾습니다.
- 안정성: 컴퓨터가 종료돼도 데이터가 사라지지 않습니다.
- 규칙 설정: "이메일은 반드시 입력해야 합니다" 같은 제약 조건을 걸 수 있습니다.
📊 SQL vs NoSQL: 두 가지 종류
데이터베이스는 크게 두 가지 종류가 있습니다.
SQL 데이터베이스 (관계형)
엑셀처럼 표(테이블) 형태로 데이터를 저장합니다. 데이터 간의 관계를 정의할 수 있어서 "관계형 데이터베이스"라고 부릅니다.
-- users 테이블
| id | name | email |
|----|--------|--------------------|
| 1 | 홍길동 | hong@example.com |
| 2 | 김철수 | kim@example.com |
-- posts 테이블 (user_id로 users와 연결)
| id | title | user_id |
|----|-------------|---------|
| 1 | 첫 번째 글 | 1 |
| 2 | 두 번째 글 | 1 |"홍길동이 쓴 글 목록"을 찾으려면 user_id = 1인 게시글을 조회하면 됩니다. 대표적인 서비스로 PostgreSQL, MySQL, Supabase, Neon 등이 있습니다.
NoSQL 데이터베이스 (비관계형)
표 대신 JSON과 비슷한 문서(Document) 형태로 데이터를 저장합니다. 구조가 자유로워서 유연하게 사용할 수 있습니다.
{
"name": "홍길동",
"email": "hong@example.com",
"posts": [
{ "title": "첫 번째 글" },
{ "title": "두 번째 글" }
]
}대표적인 서비스로 Firebase, MongoDB 등이 있습니다. 바이브코딩 프로젝트에서는 빠르게 프로토타입을 만들 때 NoSQL을 많이 사용합니다.
🧱 스키마: 데이터의 설계도
스키마(Schema)는 데이터가 어떤 구조로 저장될지 미리 정해놓은 설계도입니다. 집을 짓기 전에 도면을 그리는 것과 같습니다.
users 테이블 스키마:
- id: 숫자 (자동 생성, 고유값)
- name: 문자열 (필수)
- email: 문자열 (필수, 고유값)
- created_at: 날짜 (자동 생성)AI에게 "유저 테이블 만들어줘"라고 하면 이런 스키마를 자동으로 생성해줍니다. 스키마를 잘 설계하면 나중에 데이터가 꼬이는 문제를 예방할 수 있습니다.
본문 개념을 설명하는 학습용 예시입니다. 실제 서비스 화면이 아닙니다. 본문의 users와 posts 예시를 그렸습니다.
🛠️ 바이브코딩에서 자주 만나는 DB 서비스
| 서비스 | 특징 | 적합한 경우 |
|---|---|---|
| Supabase | PostgreSQL 기반, 인증 기능 내장 | 풀스택 앱, 회원 관리 |
| Neon | PostgreSQL, 서버리스 | 가볍고 빠른 프로젝트 |
| Firebase | NoSQL, 실시간 동기화 | 채팅, 실시간 앱 |
| PlanetScale | MySQL 기반, 자동 확장 | 대규모 서비스 |
AI에게 프로젝트를 요청하면 보통 이 중 하나를 추천합니다. 초보자라면 Supabase가 가장 시작하기 쉽습니다. 대시보드에서 테이블을 직접 만들고, 데이터를 눈으로 확인할 수 있기 때문입니다.
⚠️ 바이브코딩할 때 흔한 DB 실수
1. 데이터베이스 연결 정보를 코드에 직접 넣는 실수
데이터베이스 URL, 비밀번호 같은 정보는 반드시 환경 변수(.env)에 저장해야 합니다. GitHub에 올리면 누구나 여러분의 데이터베이스에 접근할 수 있습니다.
2. 백업 없이 데이터를 삭제하는 실수
AI에게 "테이블 다시 만들어줘"라고 했다가 기존 데이터가 모두 사라질 수 있습니다. 변경 전에 항상 "기존 데이터는 유지하면서"라고 명시하세요.
3. 스키마 설계를 건너뛰는 실수
빨리 만들고 싶은 마음에 스키마 설계 없이 시작하면, 나중에 데이터 구조를 바꿔야 할 때 훨씬 복잡해집니다. AI에게 먼저 "이 앱에 필요한 데이터베이스 스키마를 설계해줘"라고 요청하는 것이 좋습니다.
💼 비개발자가 데이터베이스를 만나는 실제 상황
문의 폼으로 들어온 데이터를 확인할 때
AI로 만든 랜딩 페이지에 문의 폼을 붙였다면, 신청자 정보는 데이터베이스에 쌓입니다. Supabase를 쓴다면 대시보드의 Table Editor에서 엑셀처럼 데이터를 확인하고 CSV로 내려받을 수 있습니다. 개발자를 거치지 않고도 "오늘 신청자가 몇 명인지"를 직접 확인할 수 있습니다.
이벤트 대상자를 추려야 할 때
"지난달 가입자 중 마케팅 수신에 동의한 사람"처럼 조건에 맞는 목록이 필요한 순간이 옵니다. 테이블과 열의 구조를 알면 대시보드에서 필터를 걸거나, AI에게 "users 테이블에서 지난달에 가입했고 수신 동의가 true인 행을 뽑아줘"라고 정확히 요청할 수 있습니다. 구조를 모르면 요청 자체가 모호해지고, 잘못된 명단을 받아도 알아차리기 어렵습니다.
AI에게 기능 추가를 요청하기 전
"회원 등급 기능 추가해줘"라고 요청하면 AI는 기존 테이블에 열을 추가하거나 새 테이블을 만듭니다. 이때 기존 데이터가 유지되는지 확인하지 않으면 실제 신청자 데이터가 사라질 수 있습니다. 변경 전에 "기존 데이터는 유지해줘"라고 명시하고, 회원 정보처럼 민감한 데이터라면 인증 설정도 함께 점검하는 것이 안전합니다. 앱과 데이터베이스가 데이터를 주고받는 방식은 REST API 클래스에서 이어집니다.
📋 3줄 요약
-
데이터베이스는 데이터를 정해진 구조로 저장하고 필요할 때 빠르게 찾아 쓰게 만든 저장소입니다.
-
표 형태로 저장하고 자료 사이의 관계를 정의하는 SQL과 JSON에 가까운 문서 형태로 자유롭게 담는 NoSQL로 나뉩니다.
-
스키마는 어떤 값이 어떤 형태로 들어갈지 미리 정해 두는 설계도이고 회원 관리가 필요하면 Supabase, 실시간 앱이면 Firebase가 자주 쓰입니다.
제대로 이해했는지 한 문제로 확인해 볼까요?
답을 고르면 바로 풀이가 나와요.
바이브코딩으로 회원가입 기능이 있는 웹 앱을 만들려고 합니다. AI가 Supabase를 추천했는데, Supabase에서 '사용자 정보를 어떤 구조로 저장할지 미리 정의한 것'을 무엇이라고 할까요?
