데이터베이스란? 앱을 만드는 사람을 위한 가이드

데이터베이스는 앱이 저장하고 불러오는 정보를 정리해 둔 저장소입니다. 사용자, 주문, 예약, 메시지 등이 들어갑니다. 브라우저 탭에만 남아 있는 정보와 달리 데이터베이스에 있는 정보는 새로 고침이나 재시작 후에도 남아 있고, 앱을 쓰는 모든 사람이 같은 기록을 봅니다. 대부분의 데이터베이스는 스프레드시트의 시트처럼 데이터를 테이블로 정리하되, 데이터의 일관성을 지키는 엄격한 규칙을 함께 적용합니다.

AI로 만들 때 왜 중요할까요

AI로 앱을 만들 때 가장 흔한 당황스러운 일은, 완성된 것처럼 보이지만 모든 것을 잊어버리는 앱입니다. 고객을 추가하고 페이지를 새로 고치면 사라져 버리죠. 대개 앱이 데이터를 데이터베이스가 아니라 브라우저의 메모리에 보관하고 있었기 때문입니다.

데이터베이스에는 여러분이 인식하지 못해도 중요한 결정들이 담겨 있습니다.

• 무엇을 기록하나요. 예약의 상태를 저장하지 않으면, 어떤 예약이 취소되었는지 보여 줄 수 없습니다.
• 무엇이 어떻게 연결되나요. 한 고객이 여러 예약을 가질 수 있는지, 한 예약에 여러 서비스가 붙을 수 있는지에 따라 앱 전체의 모양이 정해집니다.
• 누가 무엇을 볼 수 있나요. 대부분의 개인정보 실수는 사용자가 어떤 기록을 읽을 수 있는지에서 생깁니다.

데이터베이스를 직접 설계할 필요는 없습니다. 하지만 기본 개념을 이해하면 데이터를 명확하게 설명하고 문제를 일찍 발견할 수 있습니다.

일상 속 비유

작은 사무실의 잘 정리된 서류 캐비닛을 떠올려 보세요.

서랍마다 한 종류의 물건이 들어 있습니다. 한 서랍은 고객, 한 서랍은 예약, 한 서랍은 청구서입니다. 서랍 안의 모든 파일은 같은 양식을 따르고, 같은 항목이 채워져 있습니다. 각 파일에는 고유한 번호가 있고, 청구서가 어떤 고객의 것이라면 고객 파일 전체를 복사하는 대신 청구서에 그 고객의 번호만 적어 둡니다.

이것이 관계형 데이터베이스입니다. 서랍이 테이블, 파일이 행, 항목이 열, 고유 번호가 기본 키, 다른 파일을 가리키는 메모가 외래 키에 해당합니다. 좋은 사무실 관리자는 “날짜 없는 예약은 없다”, “같은 번호의 고객은 둘일 수 없다”는 규칙도 지키는데, 데이터베이스도 똑같이 합니다.

실제 예시: 미용실 예약 앱

AI에게 미용실 예약 사이트를 만들어 달라고 한다고 해 봅시다. 합리적인 데이터베이스에는 네 개의 테이블이 있습니다.

services

staff

customers

bookings

bookings 테이블을 보세요. 모든 예약마다 레나의 이름과 전화번호를 복사해 넣지 않고, customer_id = 101만 저장합니다. 레나가 전화번호를 바꾸면 한 곳만 바뀌고, 모든 예약에 새 번호가 나타납니다. 관계형 데이터베이스의 핵심 아이디어가 바로 이것입니다. 각 사실은 한 번만 저장하고, 필요할 때 연결해서 사용합니다.

같은 구조로 유용한 질문에도 답할 수 있습니다.

• “금요일에 오마르의 빈 시간은 언제인가요?” — 그날 오마르의 예약을 확인합니다.
• “이번 달 염색 시술로 얼마를 벌었나요?” — bookings를 services와 연결해 가격을 더합니다.
• “90일 동안 예약하지 않은 고객은 누구인가요?” — 고객과 그들의 가장 최근 예약을 비교합니다.

자주 쓰는 용어 정리

데이터베이스의 종류

창업자나 소규모 사업자가 처음 만드는 대부분의 앱에는 관계형 데이터베이스가 안전한 기본 선택입니다.

데이터베이스는 앱의 어디에 있나요

방문자는 데이터베이스와 직접 통신하지 않습니다. 방문자의 브라우저에 있는 페이지(프런트엔드)가 서버(백엔드)에 데이터를 요청하고, 보통 API를 통해 이루어집니다. 서버는 요청한 사람이 누구인지, 그 사람이 접근해도 되는지 확인한 다음 데이터베이스를 조회하고, 그 사람이 봐도 되는 것만 돌려보냅니다.

이 중간 단계가 중요합니다. 브라우저가 데이터베이스에 전체 권한으로 직접 질의할 수 있다면, 누구나 개발자 도구를 열어 모든 것을 읽을 수 있게 됩니다.

흔한 실수와 오해

• 데이터를 브라우저에만 저장하는 것. 브라우저 저장소(예: localStorage)는 한 기기, 한 브라우저에만 존재합니다. 기억해 둘 필터 설정에는 괜찮지만, 주문 데이터에는 적합하지 않습니다.
• 모든 것을 하나의 테이블에 밀어 넣는 것. 예약 테이블에 고객 이름, 전화번호, 서비스 가격을 모든 행마다 복사해 넣으면 금방 불일치가 생깁니다.
• 비밀번호를 평문으로 저장하는 것. 비밀번호는 읽을 수 없는 형태로 해시해서 저장해야 합니다. 인증이란 무엇인가를 참고하세요.
• 데이터에 규칙이 없는 것. 필수 항목이나 중복 금지 규칙이 없으면 날짜 없는 예약이나 중복된 고객이 생깁니다.
• 삭제를 고려하지 않는 것. 고객을 삭제하면 그 고객의 예약도 함께 삭제할지, 남겨 둘지, 아니면 삭제 자체를 막을지 정해야 합니다.
• 실서비스 데이터로 실험하는 것. 위험한 변경은 안전한 곳에서 먼저 테스트하고, 백업을 보관하세요.
• 스프레드시트를 영원한 데이터베이스로 여기는 것. 스프레드시트는 시작하기에 훌륭하지만, 여러 사용자가 동시에 쓰거나 권한을 관리할 때 한계가 있습니다. 스프레드시트를 앱으로 바꾸는 방법을 참고하세요.

AI 빌더에 요청할 내용

• “이 정보는 브라우저가 아니라 데이터베이스에 저장해 주세요. 어떤 테이블을 만들지 알려 주세요.”
• “스키마를 간단한 표로 보여 주세요. 각 테이블, 열, 그리고 테이블 간 연결을 포함해서요.”
• “고객 한 명은 여러 예약을 가질 수 있고, 각 예약에는 서비스 하나와 직원 한 명이 정확히 연결되어야 합니다.”
• “고객의 이메일은 필수이며 중복될 수 없도록 해 주세요.”
• “같은 직원의 예약 시간이 겹치지 않도록 막아 주세요.”
• “로그인한 사장님만 모든 예약을 볼 수 있고, 고객은 자신의 예약만 볼 수 있어야 합니다. 이 규칙은 서버에서 강제해 주세요.”
• “서비스를 삭제하더라도 과거 예약은 지우지 말고, 대신 서비스를 비활성으로 표시해 주세요.”

Mythex의 데이터베이스

앱에 데이터를 저장해야 할 때, Mythex는 프로젝트에 전용 Postgres 데이터베이스를 추가합니다. 채팅에서 “대기자 명단 가입 정보를 데이터베이스에 저장해 줘”처럼 요청하거나 /database 명령을 사용하면 됩니다. 연결 정보는 앱에 자동으로 전달되고, 에이전트가 테이블을 만듭니다. 데이터베이스는 5분 동안 활동이 없으면 잠들고, 다음 요청이 오면 깨어납니다. 게시된 앱의 사용량은 데이터베이스가 깨어 있던 시간만큼 청구되며, 빌드할 때와 같은 크레딧 잔액에서 차감됩니다. 무료와 Pro 플랜에서 모두 사용할 수 있습니다. 자세한 내용은 데이터베이스 문서를 참고하고, 데이터 중심의 시작점이 필요하다면 앱 템플릿을 살펴보세요.

자주 묻는 질문