video note · 44
44. 여기까지 알면 비개발자 바이브코더도 풀스택 개발자 만큼 아는거에요 (DB와 스토리지)
배울 내용
상품명, 가격, 주문 상태처럼 검색하고 관계를 맺을 값은 데이터베이스에 저장합니다. 사진과 영상처럼 큰 파일은 스토리지에 저장하고, 데이터베이스에는 파일 주소와 소유자·설명·생성 시각을 남깁니다. 두 저장소의 역할을 나누면 백업과 접근 권한도 따로 설계할 수 있습니다.
Supabase는 이 구성 요소를 한곳에서 시작할 수 있게 돕는 도구 사례입니다. 특정 도구 이름보다 구조화된 값, 파일 원본, 사용자 권한, 전달 주소 네 항목을 먼저 구분합니다.
시간대별 정리
| 구간 | 영상 흐름 | 배울 내용 |
|---|---|---|
| 00:00:00–00:00:56 | 인트로: 데이터베이스와 스토리지를 함께 보는 이유 | 서비스가 글·숫자와 사진·영상을 함께 다루므로 구조화된 데이터와 파일 저장을 한 흐름으로 보겠다고 안내합니다. |
| 00:00:56–00:01:34 | 데이터베이스가 없던 시절: 파일로 관리하던 데이터 | 고객·주문 정보를 각 파일에 직접 적고 읽던 초기 방식을 소개합니다. |
| 00:01:34–00:02:42 | 파일 관리 방식의 4가지 문제 | 같은 값의 중복, 파일 사이 불일치, 느린 검색, 여러 사람이 동시에 고칠 때의 충돌을 문제로 듭니다. |
| 00:02:42–00:03:24 | 계층형 데이터베이스의 등장 | 부모와 자식 형태로 데이터를 정리해 파일보다 빠르게 찾으려 했지만, 여러 관계를 표현하기 어려웠다고 설명합니다. |
| 00:03:24–00:03:55 | 네트워크형 데이터베이스와 한계 | 한 데이터가 여러 데이터와 연결되도록 확장했지만 구조가 복잡하고 변경하기 어려웠다고 설명합니다. |
| 00:03:55–00:04:22 | 관계형 데이터베이스의 탄생 | 데이터를 표로 나누고 공통 값을 기준으로 연결하는 관계형 모델이 구조 변경과 조회를 단순하게 했다고 소개합니다. |
| 00:04:22–00:05:07 | 테이블, JOIN, SQL의 기본 개념 | 테이블은 행과 열로 된 데이터 표, JOIN은 관련 표 연결, SQL은 조회와 변경 명령을 적는 언어로 설명합니다. |
| 00:05:07–00:05:46 | 정규화: 중복을 줄이는 설계 | 같은 값을 여러 표에 반복하지 않고 역할별 표로 나눠 한곳의 수정이 전체에 반영되게 하는 설계를 소개합니다. |
| 00:05:46–00:06:47 | Oracle, MySQL, PostgreSQL의 등장 | 관계형 모델을 실제 제품으로 구현한 주요 데이터베이스와 상용·오픈소스 생태계의 확산을 설명합니다. |
| 00:06:47–00:07:36 | ACID와 인덱스 개념 | ACID(Atomicity, Consistency, Isolation, Durability; 원자성·일관성·격리성·지속성)는 데이터 변경을 안전하게 묶는 네 성질이며, 인덱스는 모든 행을 읽지 않고 값을 빠르게 찾는 보조 구조라고 설명합니다. |
| 00:07:36–00:08:46 | 인터넷 폭발과 관계형 DB의 한계 | 데이터와 접속자가 늘면서 한 서버를 크게 만드는 방식만으로 처리량을 늘리기 어렵고, 엄격한 표 구조가 일부 서비스에 부담이 됐다고 설명합니다. |
| 00:08:46–00:10:07 | NoSQL의 등장과 확장성 문제 해결 | 문서·키값처럼 유연한 구조와 여러 서버에 데이터를 나누는 방식을 택해 대규모 트래픽을 처리하는 NoSQL의 등장을 소개합니다. |
| 00:10:07–00:11:38 | 클라우드 DB와 서버리스의 흐름 | 서버 설치·백업·확장을 클라우드 제공자가 맡고 사용량에 맞춰 운영하는 관리형 데이터베이스가 늘었다고 설명합니다. |
| 00:11:38–00:12:54 | 개발 속도가 중요해진 시대 | 작은 팀이 인증·API·데이터베이스를 각각 설치하는 시간을 줄이는 통합형 백엔드 서비스 수요가 커졌다고 연결합니다. |
| 00:12:54–00:13:24 | Supabase가 등장한 배경 | PostgreSQL을 중심으로 인증·스토리지·API를 함께 제공해 초기 제품 구성을 줄이는 Supabase를 사례로 소개합니다. |
| 00:13:24–00:14:03 | 스토리지의 시작: 모든 것은 파일이었다 | 문서와 프로그램을 컴퓨터 디스크의 파일로 저장하던 기본 구조에서 설명을 시작합니다. |
| 00:14:03–00:14:58 | 웹과 이미지·영상 파일의 증가 | 텍스트 중심 웹에 이미지와 영상이 늘면서 파일 크기와 전송량이 중요한 운영 문제가 됐다고 설명합니다. |
| 00:14:58–00:15:28 | 사용자가 파일을 올리기 시작하다 | 운영자가 준비한 파일뿐 아니라 사용자가 올린 프로필 사진과 첨부 파일을 지속해서 보관해야 하는 요구가 생겼다고 설명합니다. |
| 00:15:28–00:16:08 | 서버에 직접 파일을 저장하던 방식 | 애플리케이션이 실행되는 서버의 디스크에 업로드 파일을 함께 저장하던 방식을 소개합니다. |
| 00:16:08–00:16:47 | 서버 저장 방식의 3가지 한계 | 서버 교체 때 파일을 옮겨야 하고, 서버를 여러 대로 늘리면 파일이 나뉘며, 디스크 장애가 서비스 파일 손실로 이어질 수 있다고 설명합니다. |
| 00:16:47–00:17:57 | 클라우드 스토리지와 Amazon S3의 등장 | 애플리케이션 서버와 파일 저장소를 분리하고 필요에 따라 용량을 늘리는 Amazon S3 같은 클라우드 스토리지를 소개합니다. |
| 00:17:57–00:19:12 | 객체 스토리지: 버킷, 객체, 키 | 버킷은 파일을 담는 공간, 객체는 파일과 정보 묶음, 키는 객체를 찾는 고유 경로로 설명합니다. |
| 00:19:12–00:20:43 | CDN의 등장: 저장보다 빠른 전달 | 원본 파일을 사용자와 가까운 서버에 임시 저장해 지연과 원본 서버 부하를 줄이는 CDN을 설명합니다. |
| 00:20:43–00:22:52 | 현대 웹 서비스에서 파일이 움직이는 흐름 | 사용자가 업로드 권한을 받고 파일을 객체 스토리지에 보내면, 서비스가 파일 주소를 저장하고 CDN 주소로 전달하는 흐름을 설명합니다. |
| 00:22:52–00:24:57 | DB에는 파일이 아니라 위치를 저장한다 | 큰 파일 자체를 DB에 넣기보다 스토리지에 두고, DB에는 주소·소유자·설명·생성 시각 같은 정보를 저장하는 구성을 권합니다. |
| 00:24:57–00:25:12 | Supabase가 제공하는 기능들 | 데이터베이스, 사용자 인증, 파일 스토리지, API, 실시간 변경 알림을 한 서비스에서 제공한다고 요약합니다. |
| 00:25:12–00:26:18 | PostgreSQL, 인증, 스토리지, API, 실시간 기능 | 각 기능이 사용자 계정과 접근 권한을 공유하므로 별도 서비스를 연결하는 작업을 줄인다고 설명합니다. |
| 00:26:18–00:27:06 | DB·스토리지·인증이 하나로 묶이는 이유 | 사용자별 데이터와 파일 권한을 같은 기준으로 관리하고 초기 개발 속도를 높이기 위해 통합된 구성이 쓰인다고 설명합니다. |
| 00:27:06–00:28:08 | 전체 정리: DB와 스토리지의 흐름 | 파일 기반 데이터에서 관계형·NoSQL·클라우드 DB로, 서버 디스크에서 객체 스토리지와 CDN으로 발전한 흐름을 요약합니다. |
| 00:28:08–00:28:29 | 마무리 및 다음 강의 예고 | 웹 서버와 배포를 다룰 다음 강의를 알리고 구독과 알림 설정을 요청합니다. |
학습 포인트
- 글·숫자·상태처럼 검색할 값은 DB에, 사진·영상 원본은 스토리지에 둡니다.
- DB에는 파일 자체보다 스토리지 주소, 소유자, 파일 종류, 생성 시각을 기록합니다.
- 사용자가 파일을 올릴 때는 저장뿐 아니라 업로드 권한과 읽기 권한도 함께 설계합니다.
따라 하기
- 상품 3개를 대상으로
products표와 이미지 저장 구조를 설계합니다.id,name,price,image_url,owner_id,created_at의 예시 값을 적고, 스토리지에는 어떤 파일명이 남는지db-storage-map.md에 그립니다.