데이터베이스
앱이 데이터를 어디에 어떻게 저장하는지 이해하면 AI가 짜준 코드도 훨씬 잘 다룰 수 있습니다. 스프레드시트와 무엇이 다른지부터 스키마, 마이그레이션, 접근 권한까지 데이터베이스를 실전 관점에서 다룬 글입니다.
GitHub Actions로 운영 DB 마이그레이션 자동화하기
개발용과 운영용 데이터베이스를 나눈 뒤에는 검토한 마이그레이션 파일을 운영 DB에도 적용해야 해요. Drizzle과 GitHub Actions를 예로 들어 secret 등록부터 main push 후 자동 실행까지 설명합니다.
RLS 뜻: 데이터베이스의 ‘행 단위 보안’을 쉽게 설명하면
RLS는 Row Level Security의 약자로, 같은 데이터베이스 테이블에서도 사용자마다 조회·추가·수정·삭제할 수 있는 행을 다르게 만드는 보안 기능이에요. 로그인은 사용자가 누구인지 확인하고 RLS는 그 사용자가 접근할 데이터를 정합니다.
바이브코딩에서 개발을 배운다는 건 논리 흐름을 이해하는 일입니다
바이브코딩에서 개발을 배운다는 것은 문법을 외우기보다 사용자의 행동이 화면·서버·데이터베이스·배포 환경을 거치는 논리 흐름을 이해하는 일이에요. 정상 순서를 적고 증거로 처음 끊긴 경계를 찾은 뒤 한 가지씩 고쳐 같은 행동으로 검증하세요.
로그인 기능을 만들려면 무엇이 필요할까요? 회원가입·세션·권한 이해하기
로그인 기능은 버튼 하나가 아니라 계정 생성, 본인 확인, 세션 유지와 서버의 권한 검사가 함께 작동하는 흐름이에요. 소셜 로그인을 붙여도 사용자가 볼 수 있는 데이터와 할 수 있는 일은 서비스가 별도로 제한해야 합니다.
파일과 이미지는 데이터베이스에 저장하면 안 되나요?
이미지·영상·PDF 같은 파일 자체는 보통 파일 스토리지에 두고, 데이터베이스에는 파일 경로·소유자·형식·공개 여부를 저장해요. 공개 파일과 비공개 파일의 읽기·업로드·삭제 권한을 따로 설계하고 두 저장소가 어긋나는 실패도 처리해야 합니다.
관리자 페이지는 왜 필요할까요? 처음 만들 때 넣어야 할 기능
관리자 페이지는 운영자가 고객·주문·문의와 콘텐츠를 서비스 규칙 안에서 안전하게 처리하는 업무 화면이에요. 처음에는 매일 반복하는 목록·검색·상세·상태 변경부터 만들고 관리자 권한, 변경 이력과 위험 작업의 복구 수단을 함께 준비하세요.
내 웹 애플리케이션에 온라인 결제를 붙이려면 무엇이 필요할까요?
웹 애플리케이션에서 실제 결제를 받으려면 상품과 금액을 정하고 주문을 먼저 기록한 뒤 PG사의 결제 결과를 서버에서 승인해야 해요. 테스트 연동만으로 끝나지 않으며 계약·심사, 취소·환불과 실패 처리까지 준비해야 합니다.
구글 스프레드시트로 하던 업무, 웹앱으로 자동화하려면 어디서부터 시작할까요?
구글 스프레드시트 업무를 웹앱으로 바꿀 때는 시트 화면을 그대로 복제하지 말고 입력·저장·상태 변경·후속 알림·결과 확인의 흐름부터 그리세요. 사람이 기억해 옮기는 단계 하나를 골라 처음부터 끝까지 자동화하는 것이 첫 버전입니다.
배포할 때 .env를 그대로 넣어도 될까요? 개발·운영 데이터베이스를 나눠야 하는 이유
로컬과 배포 환경이 같은 데이터베이스를 사용하면 테스트·삭제·스키마 변경이 실제 고객 데이터에 영향을 줄 수 있어요. 개발용과 운영용 DB를 나누고 같은 환경변수 이름에 환경별 다른 값을 설정해 운영 데이터는 보호해야 합니다.
배포했는데 왜 느릴까요? 서버·데이터베이스 Region 이해하기
첫 화면은 빠른데 로그인·예약·검색만 느리다면 서버와 데이터베이스가 서로 먼 Region에서 실행되는지 확인하세요. 요청 경로와 구간별 시간을 측정한 뒤 사용자의 위치, 데이터베이스와 외부 서비스까지 고려해 가까이 둘 대상을 정해야 합니다.
서버에서 DB에 직접 연결할 건데, 바이브코딩에 Supabase를 추천하는 이유
Next.js 서버가 PostgreSQL에 직접 접근하는 구조에서도 Supabase는 관리형 DB·데이터 확인 화면·연결 풀러·백업과 운영 도구를 함께 제공해 유용해요. Prisma나 Drizzle을 그대로 쓰면서 필요할 때 Auth와 Storage를 붙일 수 있지만 모든 프로젝트의 정답은 아닙니다.
웹 애플리케이션의 기본 구조: 화면·서버·데이터베이스 이해하기
웹 애플리케이션은 보통 사용자 입력을 받는 프론트엔드, 요청과 규칙을 처리하는 애플리케이션 서버, 계속 남을 정보를 보관하는 데이터베이스로 나뉘어요. 버튼 한 번도 이 세 부분이 요청과 응답을 주고받아야 완성됩니다.
데이터베이스 vs 구글 스프레드시트, 내 앱에는 무엇이 맞을까요?
소수의 담당자가 표를 직접 편집하는 단순 업무라면 구글 스프레드시트로 충분할 수 있어요. 여러 사용자가 로그인하고 데이터 관계·권한·동시 수정·결제 같은 정확성이 필요하면 애플리케이션용 데이터베이스가 더 적합합니다.
RLS가 무슨 뜻인가요? Supabase가 설정하라는 규칙
RLS는 로그인한 사용자가 테이블의 어떤 행을 읽고 추가·수정·삭제할 수 있는지 데이터베이스에서 검사하는 규칙이에요. 켜기만 하면 기본적으로 전부 막히므로 각 동작에 필요한 정책을 따로 만들어야 합니다.
Supabase를 연결하는 방법: 서버 접근을 추천하는 이유
결제·예약·관리자 기능처럼 권한과 업무 규칙이 복잡한 앱은 브라우저가 Supabase Data API를 직접 호출하기보다 서버가 요청을 확인하고 DB 작업을 실행하는 구조가 관리하기 쉬워요. 단순 앱은 SDK와 RLS로 빠르게 시작할 수 있지만 두 방식 모두 권한 검사가 필요합니다.
데이터베이스를 연결했더니 AI가 Prisma나 Drizzle을 설치했어요. 이게 뭔가요?
Prisma와 Drizzle 같은 ORM은 데이터베이스가 아니라 서버 코드가 DB를 일관된 방식으로 조회·저장하고 스키마 변경을 관리하도록 돕는 도구예요. 패키지 설치만으로 연결이 끝나지 않으므로 DB 주소·스키마·마이그레이션과 서버 전용 실행 여부를 확인해야 합니다.
데이터 타입이란? 바이브코딩에서 타입이 중요한 이유
데이터 타입은 어떤 값을 허용하고 그 값으로 어떤 계산·정렬·검사를 할 수 있는지 정하는 규칙이에요. 값의 겉모양보다 의미와 용도를 기준으로 문자열·숫자·날짜·불리언 등을 고르고 화면부터 데이터베이스까지 변환 지점을 맞춰야 합니다.
관계형 데이터베이스와 NoSQL, 내 앱에는 무엇이 맞을까요?
예약·주문·회원처럼 여러 데이터가 서로 연결되고 조회 조건이 다양한 앱이라면 관계형 데이터베이스부터 시작하는 편이 안전해요. 문서형 NoSQL은 함께 읽고 쓰는 데이터 모양이 분명하고 관계가 단순할 때 잘 맞으며, 어느 쪽이 항상 더 빠른 것은 아니에요.
스키마와 마이그레이션이란? 바이브코딩하다 만나는 데이터베이스 용어
데이터베이스 스키마는 테이블·컬럼·관계 같은 현재 구조이고, 마이그레이션은 그 구조를 바꾸는 실행 절차와 기록이에요. 마이그레이션 파일을 만들었다고 실제 DB가 바뀐 것은 아니므로 적용 대상과 기존 데이터 영향을 확인한 뒤 실행해야 해요.
바이브코딩으로 만든 앱, 데이터는 어디에 저장할까요?
화면에 입력한 내용이 보인다고 저장된 것은 아니에요. 한 기기에서만 쓰는 간단한 도구는 localStorage로 충분할 수 있지만, 여러 기기·사용자가 같은 데이터를 오래 보관하려면 데이터베이스가 필요해요.
