앱에 데이터베이스를 추가하는 방법 (나중에 데이터를 잃지 않도록)

앱에 데이터베이스를 추가하려면 관리형 관계형 데이터베이스를 고르세요(보통은 Postgres가 기본 선택이에요). 연결 문자열은 서버 측 시크릿에 보관하고, 저장할 대상의 종류마다 테이블을 하나씩 만들고, 브라우저가 아니라 백엔드가 데이터베이스를 읽고 쓰도록 하세요. AI 앱 빌더를 쓴다면 "이 내용을 데이터베이스에 저장해 줘"라고만 말해도 에이전트가 테이블과 코드를 설정해 주는 경우가 많아요. 여러분이 할 일은 데이터를 명확하게 설명하고, 실제로 저장되는지 확인하는 거예요.

이 가이드에서는 데이터베이스가 언제 필요한지, 주요 선택지, 데이터를 설명하는 방법, 그리고 데이터가 유실되거나 유출되는 원인이 되는 실수를 다뤄요.

앱에 데이터베이스가 필요한 경우

페이지를 닫은 뒤에도 무언가를 기억해야 하거나, 사람들끼리 데이터를 공유해야 할 때 데이터베이스가 필요해요. 대표적인 신호는 다음과 같아요:

• 방문자가 양식, 가입, 예약, 주문 같은 내용을 제출할 때
• 사용자가 자신만의 저장 콘텐츠를 가진 계정을 가질 때
• 관리자가 다른 사람이 만든 내용을 보거나 수정해야 할 때
• 시간에 따라 리포트나 집계가 필요할 때

모든 방문자에게 같은 내용을 보여 주는 정적 사이트(포트폴리오나 간단한 랜딩 페이지 등)라면 데이터베이스는 필요하지 않아요. 데이터베이스가 정확히 무엇인지 잘 모르겠다면 먼저 데이터베이스란 무엇인가를 읽어 보세요.

선택지

대부분의 작은 규모에서 중간 규모의 웹 앱에는 Postgres 같은 관계형 데이터베이스가 적합해요. 데이터 간 관계(고객 한 명이 여러 주문을 가지는 것 등)를 잘 표현하고, 데이터 일관성을 지키며, 나중에 SQL로 질문에 답할 수 있게 해 주기 때문이에요. 쉬운 설명이 필요하다면 Postgres란 무엇인가를 참고하세요.

데이터를 만들기 전에 설명하기

가장 유용한 일은 앱이 저장할 대상과 그것들이 어떻게 연결되는지 적어 보는 거예요. 데이터베이스 전문 용어는 필요 없어요. 예약 앱이라면 이렇게 정리할 수 있어요:

• 고객: 이름, 이메일, 전화번호
• 서비스: 이름, 소요 시간, 가격
• 예약: 어느 고객인지, 어느 서비스인지, 시작 시간, 상태(대기, 확정, 취소)

이렇게 세 개의 테이블이 나와요. "어느 고객인지"와 "어느 서비스인지"는 테이블 사이의 연결(외래 키)이 돼요. 실제 데이터가 쌓인 뒤에 데이터의 구조를 바꾸는 것은 페이지 레이아웃을 바꾸는 것보다 훨씬 어려우니, 이 부분을 일찍 제대로 정하는 것이 어떤 기술을 고르는 것보다 중요해요.

몇 가지 기본 원칙이 있어요:

• 대상 하나에 테이블 하나. 고객 항목 안에 주문을 텍스트 열로 욱여넣지 마세요.
• 모든 행에 ID와 생성 시각을 두세요. 나중에 꼭 필요해져요.
• 적절한 타입을 쓰세요. 날짜는 날짜로, 금액은 정수(센트 단위)나 소수 타입으로 저장하고, 텍스트로 저장하지 마세요.
• 필수 항목은 필수로 표시하세요. 잘못된 데이터를 양식만이 아니라 데이터베이스가 거부하게 하세요.

프롬프트 예시

한 번에 전체 스키마를 던지기보다 기능 하나씩 시작하세요:

이 앱에 데이터베이스를 추가해 줘. 고객 이름, 이메일, 서비스, 시작 시간, 상태(대기, 확정, 취소, 기본값은 대기)를 담은 bookings 테이블을 만들어 줘. 예약 양식에서 제출된 내용을 여기에 저장하고, 성공 메시지를 보여 주고, 최신순으로 예약을 보여 주는 관리자 페이지를 추가해 줘.

그다음 확장하세요:

services 테이블(이름, 소요 시간(분), 가격(센트))을 추가해 줘. bookings의 자유 입력 서비스 항목을 services와의 연결로 바꾸고, 기존 예약은 삭제하지 말고 마이그레이션해 줘.

그리고 보안을 조였어요:

모든 데이터베이스 읽기와 쓰기는 서버에서 일어나야 해. 브라우저가 데이터베이스 연결 문자열을 받으면 안 돼. 데이터를 넣기 전에 서버에서 이메일과 시작 시간을 검증해 줘.

단계별 진행

1. 데이터 목록 작성. 위에서 한 것처럼 대상, 항목, 연결을 적어요.
2. 데이터베이스 만들기. AI 빌더라면 채팅으로 요청하세요. 그 밖의 환경이라면 관리형 Postgres 인스턴스를 만들고 연결 문자열을 복사하세요.
3. 연결 문자열을 시크릿으로 저장. 서버의 환경 변수로 두고, 코드에는 절대 넣지 마세요. 자세한 내용은 환경 변수와 시크릿이란 무엇인가를 참고하세요.
4. 테이블 만들기. 스키마 변경을 반복 가능하고 되돌릴 수 있도록 마이그레이션(스키마를 버전 단위로 바꾸는 스크립트)을 사용하세요.
5. 서버 라우트 만들기. 행을 생성, 조회, 수정, 삭제하는 라우트(CRUD)를 만드세요. 브라우저는 이 라우트를 호출하며, 데이터베이스에 직접 접근하지 않아요.
6. UI 연결하기. 저장되는 양식, 불러오는 목록, 데이터가 없을 때의 빈 상태 화면을 라우트에 연결하세요.
7. 저장 여부 테스트. 무언가를 제출하고, 페이지를 새로고침하고, 다른 브라우저에서 열어 보세요. 거기에 데이터가 없다면 데이터베이스에 저장되지 않은 거예요.
8. 접근 권한 확인. 두 번째 사용자로 로그인해서 첫 번째 사용자의 데이터를 보거나 수정할 수 없는지 확인하세요.
9. 공개 후 다시 테스트. 공개된 실제 URL에서 다시 확인하세요. 공개된 앱은 미리보기와 다른 연결을 쓸 수 있기 때문이에요.

흔한 실수

• 브라우저에 저장하고 저장됐다고 생각하기. localStorage는 잘 되는 것처럼 보이지만, 다른 기기에서 앱을 열면 데이터가 없어요. 항상 두 번째 브라우저에서 테스트하세요.
• 프런트엔드 코드에 연결 문자열 넣기. 프런트엔드 코드는 누구나 읽을 수 있어요. 그러면 데이터베이스 전체를 내주는 셈이에요.
• 접근 검사 없음. "내 주문 보기"는 UI가 아니라 서버에서 로그인한 사용자 기준으로 필터링해야 해요. AI로 만든 앱에서 가장 흔한 보안 구멍이며, AI로 만든 앱을 위한 보안 체크리스트에서 자세히 다뤄요.
• 파괴적인 스키마 변경. "테이블 이름을 바꿔 줘"나 "구조를 바꿔 줘"는 테이블을 지우고 다시 만들 수 있어요. 실제 데이터가 있다면 "기존 행을 마이그레이션하고 아무것도 삭제하지 마"라고 분명히 말하세요.
• 데이터베이스에 파일 저장하기. 이미지와 PDF는 파일 스토리지에 두고, 테이블에는 URL이나 키만 저장하세요. 자세한 내용은 앱에 파일 업로드를 추가하는 방법을 참고하세요.
• 백업 없음. 고객을 받기 전에 플랫폼이 데이터를 어떻게 백업하는지, 어떻게 복구하는지 미리 알아 두세요.

체크리스트

• 저장 대상마다 ID와 생성 시각을 가진 테이블이 있어요
• 필수 항목과 타입을 데이터베이스가 강제해요
• 연결 문자열은 서버 측 시크릿에만 있어요
• 모든 읽기와 쓰기는 서버 라우트를 거쳐요
• 각 사용자는 자신의 행만 읽고 수정할 수 있어요
• 새로고침과 다른 브라우저에서도 데이터가 남아 있어요
• 스키마 변경은 마이그레이션으로 하고 기존 행을 유지해요
• 백업과 복구 방법을 알고 있어요
• 공개한 뒤 실제 앱에서도 테스트했어요

Mythex에서 데이터베이스 추가하기

Mythex에서는 Free와 Pro 모두에서 프로젝트마다 전용 Postgres 데이터베이스를 받을 수 있어요. 보통 별도의 "연결" 버튼을 누를 필요가 없어요. 채팅에서 "대기자 이메일을 데이터베이스에 저장해 줘"처럼 요청하거나 /database를 입력하면, 연결 정보가 작업 공간과 공개된 앱에 주입돼요. 프로젝트 설정에서 데이터베이스가 활성화되어 있는지 확인할 수 있어요.

데이터베이스는 5분 동안 유휴 상태이면 잠들고, 다음 요청이 오면 깨어나요. 공개된 앱의 사용량은 실제로 깨어 있던 시간만큼 과금되며, 앱을 만들 때 쓰는 것과 같은 크레딧 잔액에서 차감돼요. 이미 공개한 뒤에 데이터베이스를 추가했다면, 공개된 앱이 이를 반영하도록 다시 공개하세요.

자세한 내용은 문서의 데이터베이스와 CRUD 앱 만들기 레시피를 참고하세요. 사용자별 데이터의 로그인 부분은 앱에 로그인을 추가하는 방법을 읽어 보세요.

자주 묻는 질문