[비개발자 사고법 08강] 데이터베이스는 '창고'입니다 — 새로고침하면 다 사라지는 진짜 이유·테이블·CRUD·SQL vs NoSQL 한 방 정리

왜 비개발자가 '데이터베이스'까지 알아야 할까

비개발자가 코딩을 포기할까 말까 하는 지점은 프론트엔드가 아닙니다. 프론트엔드는 눈에 보이니까 "예쁘게 고쳐줘"라고 하면 되거든요. 진짜 고비는 화면엔 멀쩡히 떴는데, 새로고침하면 다 사라질 때입니다. 로그인 페이지까지 만들었는데 아이디·비밀번호를 쳐도 안 들어가지고, 메모를 적었는데 다시 켜면 텅 비어 있어요.

요즘 AI 에이전트(클로드 코드 등)는 안 시켜도 데이터베이스까지 알아서 잡아 줍니다. 그래서 작업하다 보면 이런 질문을 받게 돼요 — "데이터베이스를 넣어 드릴까요? 구글 파이어베이스에 연결해 드릴까요? 수파베이스에 연결해 드릴까요?" 이때 얼타지 않고 "어, 그래. 파이어베이스로 해줘"라고 자연스럽게 받아치려면 개념을 알아야 합니다. 김지백 강사에 따르면, 데이터베이스를 알아야 비로소 나만의 앱·나만의 프로젝트를 만들 수 있고, 회사에서 ERP 같은 프로젝트를 할 때도 내일도, 내일모레도 계속 쓸 수 있는 시스템이 됩니다.

🍽️ 화면은 식탁, 저장은 창고 — 왜 사라지는가

AI에게 "보여줘"라고 하는 건 식탁에 차리는 일입니다. 보기엔 그럴듯하지만, 치워 버리면(새로고침하면) 끝이에요. 반면 "저장해줘"는 창고에 넣는 일입니다. 창고에 넣은 물건은 다음 날 가게 문을 다시 열어도 그대로 있죠. 지난 두 시간 동안 배운 주방(백엔드)과 알바생(API) 이야기에서 빠지지 않고 등장했던 "주방 한 켠의 거대한 창고이자 냉장고" — 오늘은 그 창고 안으로 직접 들어가 봅니다.

그런데 창고에 물건을 그냥 아무렇게나 쌓아 두면 어떻게 될까요? 이사할 때 박스에 내용물을 안 적어 두면 나중에 아무것도 못 찾는 것처럼, 데이터도 정리해 두지 않으면 컴퓨터도 못 찾습니다. 줄을 맞춰 정리해 두면 1초 만에 꺼낼 수 있어요. 그 "줄 맞춰 정리하는 법"이 지금부터 나옵니다.

📦 창고 안은 이렇게 생겼다 — 테이블·행·열

데이터베이스를 한마디로 하면 잘 정리된 거대한 엑셀 표입니다. 엑셀이나 노션 표를 보신 적 있다면 이미 절반은 아는 거예요. 회원 명단을 예로 들어 볼게요.

여기서 딱 세 단어만 잡으면 됩니다. 맨 윗줄의 항목들(이름·이메일·가입일)처럼 세로 방향 한 칸 한 칸이 열(컬럼, column) — "어떤 정보를 담을지"입니다. 홍길동 씨의 정보 가로 한 줄이 행(레코드, record) — 데이터 하나하나죠. 회원 한 명이 가입하면 표에 한 줄이 추가되는 겁니다. 그리고 이런 표 전체를 테이블(table)이라고 불러요. 회원 테이블, 상품 테이블, 주문 테이블처럼 잘 짜인 표들이 모여 하나의 데이터베이스가 됩니다.

🏷️ 스키마 — 칸마다 '들어갈 수 있는 형식'이 정해져 있다

테이블을 짤 때 정말 중요한 것이 스키마(schema)입니다. 어렵게 들리지만, "이 칸에는 어떤 형식의 값만 들어갈 수 있다"는 규칙이에요. 이름 칸에는 텍스트, 가입일 칸에는 날짜, 휴대폰 번호 칸에는 숫자 — 이렇게요.

사실 여러분은 이미 스키마를 겪어 봤습니다. 구글 폼이나 네이버 폼에서 전화번호 칸에 이름을 쓰면 "숫자를 입력하세요"라고 거절당하죠? 그 칸의 스키마가 '숫자'로 되어 있어서 텍스트를 인식하지 못하는 겁니다. 형식이 안 맞는 값을 넣으면 데이터를 제대로 읽지 못하는 사고가 나요. 다행히 스키마는 AI가 거의 다 잡아 줍니다 — 다만 이런 개념이 있다는 걸 알아야, AI가 "가입일 컬럼은 date 타입으로 잡을게요"라고 할 때 고개를 끄덕일 수 있습니다.

🧺 AI가 못 해 주는 단 한 가지 — "무슨 데이터를 모을까"

화면도, 테이블도, 스키마도 AI가 다 만들어 줍니다. 그런데 딱 하나, AI가 대신 정해 줄 수 없는 게 있어요. "입력단에서 어떤 데이터를 수집할 것인가" — 이건 사장님(여러분)의 결정입니다. 물론 이것도 AI에게 물어보며 정할 수 있습니다:

한 가지 주의할 점 — 수집 항목은 처음에 잘 정하는 게 좋습니다. 입력 항목 7개로 회원 100명을 모은 뒤에 4개를 추가해 11개로 늘리면, 먼저 가입한 100명과 나중 가입자의 데이터가 달라서 충돌이 생길 수 있어요. 요즘 AI가 이런 변경도 곧잘 처리해 주지만, "처음 설계가 중요하다"는 감각은 사장님이 갖고 있어야 합니다.

🔁 창고 안에서 하는 일은 딱 4가지 — CRUD

창고에서 하는 일은 결국 네 가지뿐입니다. 넣고, 꺼내고, 바꾸고, 버리고. 이 네 동작의 앞글자를 딴 말이 CRUD(크러드)예요. 우리가 쓰는 거의 모든 앱이 이 네 가지를 끊임없이 반복합니다.

지난 API편에서 배운 GET·POST·PUT·PATCH·DELETE가 바로 이 CRUD와 정확히 연결됩니다. 알바생(API)에게 "가져와(GET)·등록해(POST)"라고 시키면, 그 주문의 끝점에서 창고(데이터베이스)가 수정되고 고쳐지고 지워지는 것이죠. 이 연결이 보이면 백엔드가 어느 정도 잡힌 겁니다.

🗄️ 창고의 종류 — 반듯한 SQL vs 자유로운 NoSQL

창고에도 두 종류가 있습니다. 하나는 SQL(에스큐엘) — 반듯한 엑셀 표 방식입니다. 칸이 미리 딱 정해져 있어서 이름 칸엔 이름만, 가입일 칸엔 날짜만 들어가는 정형 데이터죠. 규칙이 엄격하고 표들끼리 연결도 되기 때문에("이 주문은 저 회원 것") 은행·쇼핑몰처럼 돈과 중요한 정보를 다루는 곳에 안전합니다.

다른 하나는 NoSQL(노에스큐엘) — 메모지나 서류 봉투처럼 자유롭게 담는 방식입니다. 어떤 데이터는 항목이 많고 어떤 건 적어도 괜찮아요(비정형 데이터). 상품 리뷰를 생각해 보세요 — 사람들이 규격에 맞춰서 씁니까? 아니죠. 이렇게 형식이 자유롭거나, 데이터가 빠르게 변하고 양이 엄청날 때 NoSQL이 유리합니다.

참고로 요즘 구글 파이어베이스에는 NoSQL(Firestore)뿐 아니라 SQL 커넥트(PostgreSQL)까지 추가되어 둘 다 쓸 수 있고, 사진·동영상 같은 파일은 데이터베이스가 아니라 스토리지(Storage)라는 자료실에 따로 보관합니다. 중요한 건 둘 중 뭐가 더 좋은 게 아니라 용도에 따라 골라 쓴다는 것 — 이 감각만 있으면 AI가 "Firestore로 할까요?"라고 물을 때 자신 있게 답할 수 있습니다.

한눈에 보는 데이터베이스 7단어 정리

사장님처럼 AI에게 시키는 법 — "저장해줘"를 콕 집어서

데이터베이스를 모르면 이렇게 시킵니다 — "메모 적는 기능 만들어줘." 요즘 AI가 똑똑해서 알아서 잡아 주기도 하지만, 창고 없이 식탁만 차려 주면 새로고침하는 순간 텅 빕니다. 이제는 이렇게 시키세요:

Firebase 프로젝트 등록, SDK·키 설정 같은 초기 세팅도 겁낼 필요 없습니다. 클로드 코드에게 브라우저(Playwright)를 켜서 직접 해 달라고 하면 아이디·비밀번호 입력 정도만 빼고 대부분 잡아 줍니다. 필요한 건 코딩 실력이 아니라 티키타카할 약간의 인내심이에요.