프로그램을 껐다 켜도 정보가 그대로 남아 있으려면, 그 정보는 어딘가에 저장돼 있어야 한다. 그 어딘가가 파일과 DB다.
이 글 3줄 요약
- 정보를 영구히 남기는 방법은 크게 둘이다. 파일은 서랍 속 종이 묶음, DB는 정해진 양식의 장부 캐비닛이다. 적으면 파일, 커지면 DB.
- DB는 어렵게 볼 것 없이 결국 엑셀 표다. 테이블은 시트 한 장, 행은 한 건, 열은 항목, 스키마는 칸과 값의 규칙(장부 양식)이다.
- 파일이냐 DB냐는 건수·동시접속·검색 세 가지로 판단한다. 하나라도 커지면 DB로 가고, Supabase면 코드 없이 클릭으로 시작한다.
이 글은 AI 바이브코딩 강의 12부작 시리즈의 6편이다. 처음 보는 독자는 1편부터 읽으면 흐름이 잡힌다. 바이브코딩이란 코드를 한 줄씩 손으로 치는 대신, 만들고 싶은 걸 말로 설명하면 AI가 코드를 써주는 방식의 개발을 말한다. 이번 편의 주제는 데이터 저장, 즉 만든 것이 사라지지 않게 하는 방법이다.
오늘의 질문 — 방금 입력한 내용은 어디로 사라지나
손님이 방금 입력한 이름과 전화번호가 있다고 하자. 프로그램을 끄면 그 정보는 어디로 갈까.
답은 냉정하다. 잠깐 기억에만 있으면 껐다 켜는 순간 증발한다. 여기서 잠깐 기억이란 메모리를 말하는데, 메모리는 프로그램이 켜져 있는 동안만 정보를 붙잡아 두는 임시 작업대다. 전원을 내리면 작업대 위의 것들이 싹 치워진다. 그래서 정보를 영구히 남기려면 작업대가 아니라 창고에 옮겨 둬야 한다. 그 창고가 바로 파일과 데이터베이스(DB)다. 데이터베이스란 데이터를 체계적으로 쌓고 꺼내주는 전문 창고를 뜻한다.
오늘 가는 길은 세 갈래다. 첫째로 파일과 DB의 차이, 둘째로 언제 무엇을 써야 하는지, 셋째로 실제 클라우드 DB인 Supabase를 눈으로 보는 것까지다.
핵심 비유 — 파일은 서랍 속 종이, DB는 장부 캐비닛
두 저장 방식을 사무실 물건에 빗대면 단번에 감이 온다.
파일은 서랍 속 종이 묶음이다. 정보를 종이 한 장에 적어 서랍에 쌓아두는 방식이다. 여기서 종이에 해당하는 게 txt나 json 같은 파일이다. txt는 글자만 담는 메모지, json은 항목별로 칸을 나눠 담는 메모지라고 보면 된다. 설정값이나 간단한 메모처럼 양이 적을 땐 이 방식이 가장 간단하다. 더블클릭하면 바로 열리는 종이 한 장, 그게 파일이다.
DB는 장부 캐비닛이다. 정보를 정해진 양식의 장부에 칸칸이 기록하는 방식이다. 이 방식은 찾기, 집계, 여러 명이 동시에 쓰기에 강하다. 예를 들어 지난달 가입자 수를 한 줄로 집계하거나, 100명이 동시에 써도 기록이 엉키지 않는 것이 장부 캐비닛의 힘이다.
종이 서랍은 몇 장일 땐 세상 제일 편하다. 하지만 종이가 수천 장이 되면 원하는 한 장을 찾는 일이 지옥이 된다. 바로 그때 필요한 게 장부 캐비닛, 즉 DB다.
DB 안을 열어보면 결국 엑셀 표다 — 테이블·행·열
DB라는 말이 거창해서 그렇지, 뚜껑을 열면 우리가 매일 보는 엑셀 표와 똑같다. 회원 정보를 담은 표를 예로 보자.
| 이름 | 전화 | 가입일 |
|---|---|---|
| 홍길동 | 010-1234 | 07-01 |
| 김영희 | 010-5678 | 07-03 |
| 박철수 | 010-9012 | 07-05 |
이 표 하나에 DB 용어 네 개가 다 들어 있다.
- 테이블(table)은 엑셀 시트 한 장이다. 회원 표, 예약 표처럼 주제별로 하나씩 만든다.
- 행(row)은 가로 한 줄, 곧 한 건이다. 회원 한 명, 예약 한 건이 한 행이다. 위 표에서 홍길동 줄 전체가 한 행이다.
- 열(column)은 세로 항목이다. 이름·전화·가입일처럼 무슨 정보를 담는 칸인지를 가리킨다.
- 칸(cell)은 행과 열이 만나는 값이다. 홍길동이나 010-1234 같은 실제 데이터 한 개다.
엑셀을 한 번이라도 써봤다면 이미 DB의 뼈대를 아는 셈이다. 테이블·행·열이라는 낯선 단어가 각각 시트·줄·항목이었을 뿐이다.
스키마 — 장부의 양식을 미리 정한 규칙
표를 만들기 전에 이 표가 어떤 모양이어야 하는지 규칙을 먼저 정한다. 그 규칙을 스키마라고 부른다. 스키마는 장부의 양식을 미리 정해둔 설계도다. 예약을 받는 표라면 스키마는 이렇게 생겼다.
reservations { // 예약 테이블
id 자동번호
name 글자
phone 글자
date 날짜
created_at 기록시각(자동)
}
이 설계도를 읽는 법은 세 가지만 알면 된다.
첫째, 어떤 열(칸)이 있는가다. 위 스키마의 name·phone·date가 이 표에 담기는 항목의 목록이다. 이름·전화·날짜를 받겠다는 뜻이다.
둘째, 각 칸에 무슨 값만 들어갈 수 있는가다. phone은 글자, date는 날짜 형식만 받도록 정해두면, 엉뚱한 값이 들어올 때 자동으로 막힌다. 장부가 엉망이 되지 않게 지켜주는 양식인 셈이다.
셋째, 스키마를 읽으면 그 프로그램이 무슨 데이터를 다루는지 한눈에 파악된다. 코드를 한 줄도 못 읽어도 칸 이름만 보면 안다.
그래서 AI에게 이 DB 스키마 보여줘 하고 물으면 위와 같은 설계도가 나온다. 칸 이름만 훑어도 어떤 정보가 쌓이는지 읽어낼 수 있으니, 남이 만든 프로그램을 파악할 때도 스키마부터 보면 빠르다.
가장 중요한 판단 — 언제 파일이고 언제 DB인가
이 편에서 딱 하나만 가져간다면 이 판단이다. 파일이면 충분한 경우와 DB로 가야 하는 경우를 나란히 놓으면 이렇게 갈린다.
| 판단 축 | 파일이면 충분 | DB로 가야 함 |
|---|---|---|
| 건수 | 적다 (수십에서 수백 줄 정도) | 많고 계속 쌓인다 (수천 건 이상) |
| 동시접속 | 나 혼자, 한 대에서만 쓴다 | 여러 명이 동시에 읽고 쓴다 |
| 검색 | 그냥 저장하고 불러오기만 한다 | 조건으로 찾기·집계가 자주 필요하다 |
판단 축은 딱 세 개, 건수·동시 사용자·검색이다. 셋 중 하나라도 커지면 DB로 넘어가면 된다. 세 축이 다 작으면 파일 한 장이 더 빠르고 단순하다. 헷갈리면 AI에게 이 정도면 파일이야 DB야 하고 물어도 된다. 규모를 설명하면 어느 쪽이 맞는지 답해준다.
실전에서 이렇게 쓴다 — 수기 정리에서 해방된 신청 접수
말로만 하면 와닿지 않으니 실제로 돌아가는 구조를 하나 보자. 이 블로그를 운영하는 쪽에서 강의 신청을 받는 방식이다. 흐름은 세 단계다.
먼저 홈페이지의 신청 폼에서 손님이 이름과 연락처를 입력한다. 그러면 그 한 줄이 Supabase라는 클라우드 DB에 자동으로 쌓인다. 동시에 슬랙이라는 업무 메신저로 새 신청 왔어요 하는 알림이 즉시 온다.
예전에는 홈페이지로 들어온 신청을 손으로 엑셀에 옮겨 적었다. 놓치기도 하고, 밤에 온 신청은 다음 날에야 확인했다. 지금은 신청 폼을 제출하면 그 한 줄이 DB에 저절로 남고, 알림까지 날아온다. 엑셀 수기 정리는 사라졌다. 데이터는 DB에 안전하게 남고, 사람은 알림만 보면 된다. 이게 데이터를 DB에 둔다는 말의 실제 효용이다.
직접 해보기 — Supabase로 DB를 눈으로 만지기
개념만으로는 손에 안 잡히니 직접 만져보는 게 제일 빠르다. Supabase는 웹브라우저에서 회원가입만 하면 바로 쓰는 클라우드 DB다. 클라우드라는 건 내 PC가 아니라 인터넷 위에 데이터가 있다는 뜻이라, 어느 기기에서 접속해도 같은 데이터를 본다. 무료로 시작할 수 있다.
순서는 네 걸음이다.
- 가입하고 새 프로젝트를 만든다. supabase.com에 가입한 뒤 프로젝트를 하나 생성하면, 내 전용 DB가 인터넷에 하나 생긴다.
- Table Editor에서 표를 만든다. 엑셀처럼 열(이름·전화·날짜)을 정해 표를 만드는데, 이게 앞에서 배운 스키마 정하기다.
- 행을 직접 한 건 넣어본다. 방금 만든 표에 엑셀에 한 줄 적듯 값을 입력하면, 데이터가 실제로 저장되는 걸 눈으로 확인할 수 있다.
- AI에게 이 표에 저장하는 코드 짜줘 하고 시킨다. 그때부터 프로그램이 이 표에 자동으로 쌓기 시작한다. 사람은 표 구조만 정했을 뿐이다.
검증 포인트는 간단하다. 넣은 행이 페이지를 새로고침해도 그대로 남아 있으면 성공이다. 저장됐다는 말을 눈으로 확인한 셈이다.
흔한 오해 두 가지
데이터 저장을 두고 초보자가 자주 하는 착각이 둘 있다.
첫째, DB는 전문가나 쓰는 어려운 것이라는 오해다. 서버 설치와 SQL 문법부터 떠올리면 시작도 전에 겁을 먹는다. 하지만 실제로는 요즘 DB는 엑셀처럼 클릭으로 표를 만든다. 코드는 AI가 쓰고, 사람은 무슨 칸을 둘지만 정하면 된다. Supabase가 바로 그 증거다.
둘째, 데이터는 무조건 DB에 넣어야 안전하다는 오해다. 작은 설정값까지 전부 DB에 넣으면 오히려 번거롭고 느려진다. 작으면 파일 하나가 더 빠르고 단순하다. 건수·동시성·검색이 없으면 파일로 충분하다. 도구는 크기에 맞게 고르는 것이다.
3줄 정리
- 데이터를 남기려면 파일 아니면 DB다. 파일은 서랍 속 종이라 적을 때 충분하고, DB는 장부 캐비닛이라 찾기·집계·동시작업에 강하다.
- DB는 결국 엑셀 표다. 테이블은 시트, 행은 한 건, 열은 항목, 스키마는 칸과 값의 규칙(장부 양식)이다.
- 건수·동시접속·검색, 하나라도 커지면 DB로 간다. Supabase면 코드 없이 클릭으로 시작하고, 사람은 표 구조만 정하고 코드는 AI가 쓴다.
다음 편에서는 오늘 만든 데이터(DB)를 손님이 실제로 보는 화면과 어떻게 연결하고 세상에 내보내는지, 즉 프론트(화면)와 백엔드(뒤에서 일하는 쪽)의 구분과 인터넷에 올린다(배포)는 말의 실제 의미를 다룬다.
다음 편 — 바이브코딩 강의 7편