데이터베이스와 스토리지의 역사 — 파일 저장부터 Supabase 올인원 시대까지

데이터를 어디에, 어떻게 저장할 것인가? 이 단순한 질문이 60년간 기술의 방향을 바꿔왔습니다.

오늘날 우리는 앱 하나를 만들 때 데이터베이스, 파일 스토리지, 인증, API를 당연하듯 함께 사용합니다. 하지만 이 기술들은 하루아침에 등장한 것이 아닙니다. 각각의 기술은 이전 방식의 치명적인 한계를 돌파하기 위해 등장한 해결책이었고, 최근에는 이 모든 것을 하나로 묶는 올인원 플랫폼으로 수렴하고 있습니다.

파일 저장의 시대부터 Supabase까지, 데이터 관리 기술의 진화를 따라가 보겠습니다.

1. 데이터베이스(DB)의 역사와 진화

📁 파일 저장 방식의 한계 (1950~60년대)

초기에는 엑셀이나 메모장 같은 단순 파일로 데이터를 관리했습니다. 규모가 작을 때는 문제가 없었지만, 데이터가 쌓이면서 4가지 치명적인 문제가 드러났습니다.

문제	설명
중복 데이터	여러 파일에 같은 정보가 반복 저장됨
데이터 불일치	파일마다 정보가 달라 어느 것이 정확한지 알 수 없음
검색 비효율	원하는 데이터를 찾으려면 파일 전체를 처음부터 끝까지 읽어야 함
동시 수정 충돌	여러 명이 동시에 수정하면 덮어씌워져 데이터 유실 발생

이 네 가지 문제를 해결하기 위해 데이터베이스라는 개념이 탄생하게 됩니다.

🌲 초기 데이터베이스의 등장 (1960년대 초반)

파일의 한계를 극복하기 위해 두 가지 구조가 처음으로 시도되었습니다.

계층형 DB: 조직도처럼 위→아래(나무 구조)로 데이터를 연결합니다. 단순하지만, 현실의 복잡한 데이터 관계를 표현하기에는 구조가 너무 경직되어 있었습니다.
네트워크형 DB: 그물처럼 옆으로도 연결할 수 있어 유연해졌습니다. 하지만 프로그래머가 연결 경로를 일일이 지정해야 해서 코드가 지나치게 복잡해지는 문제가 생겼습니다.

두 방식 모두 "데이터의 물리적 저장 구조를 프로그래머가 직접 알아야 한다"는 근본적인 한계를 안고 있었습니다.

🏛️ 관계형 데이터베이스의 혁명 (1970년대)

1970년, IBM의 에드거 F. 코드(Edgar F. Codd)가 혁명적인 논문을 발표합니다. 핵심 아이디어는 단순했습니다. 데이터를 '표(Table)' 형태로 저장하자는 것이었습니다.

이 아이디어에서 세 가지 핵심 개념이 탄생했습니다.

조인(Join): 여러 표를 연결해 원하는 정보를 조합하여 꺼내는 기술
SQL: 데이터를 넣고 뺄 때 쓰는 영어 문장처럼 직관적인 질의 언어
정규화: 중복을 없애기 위해 데이터를 한 곳에만 저장하고, 다른 곳에서는 참조만 하는 설계 원칙

이후 70~80년대 황금기를 맞이하며 오라클(기업용), MySQL(오픈소스), PostgreSQL(학술/안정성) 등이 등장했고, 정확성·일관성·인덱스(색인) 등의 기술이 완성되었습니다. 관계형 DB는 이후 수십 년간 데이터 관리의 절대적 표준으로 자리 잡았습니다.

🚀 NoSQL의 등장 (2000년대 중반)

인터넷의 폭발적 성장으로 하루 수십억 건의 데이터가 발생하는 시대가 열렸습니다. 관계형 DB에게 새로운 한계가 찾아왔습니다.

핵심 문제는 수평 확장(서버 늘리기)의 한계였습니다. 관계형 DB는 정교한 조인과 트랜잭션을 보장하는 구조 특성상, 여러 서버에 표를 나눠 담고 조인하는 것이 매우 어려웠습니다.

이에 대한 해결책으로 NoSQL(Not Only SQL)이 등장합니다.

전략: 정확성(일관성)을 조금 포기하는 대신, 속도와 확장성을 극대화
방식: 표 구조를 버리고 스키마리스(유연한 구조) 방식을 채택
대표 기술: MongoDB(문서형), Redis(키-값 캐시), Cassandra(분산 DB) 등

☁️ 클라우드 DB와 서버리스 시대 (2010년대)

과거에는 DBA(데이터베이스 관리자)가 직접 서버를 구매하고 DB를 설치·관리해야 했습니다. 이 운영 부담을 클라우드가 해결합니다.

관리형 DB (AWS RDS 등): 클라우드 기업이 백업, 업데이트, 용량 관리를 대신 수행합니다. 개발자는 DB를 "사용"만 하면 됩니다.
Firebase: 구글이 만든 서버리스 플랫폼으로, 서버 코드를 거의 짜지 않고도 앱에서 바로 DB를 연결해 쓸 수 있게 되면서 편의성이 극대화되었습니다.

2. 스토리지의 역사와 진화

💾 웹 서버 저장의 한계

초기 웹은 텍스트 위주라 파일 크기가 작았습니다. 하지만 SNS 시대가 열리면서 사용자가 직접 무거운 이미지나 영상(바이너리 데이터)을 업로드하기 시작했고, 웹 서버 컴퓨터의 폴더에 직접 파일을 저장하는 방식은 세 가지 치명적인 문제를 드러냈습니다.

서버 장애 = 데이터 유실: 서버가 죽으면 파일이 전부 날아감
확장 불가: 서버를 여러 대로 늘리면 파일을 어디에 저장할지 혼란 발생
성능 저하: 파일 요청 트래픽 때문에 서버가 핵심 비즈니스 로직을 처리하지 못함

파일 저장을 웹 서버에서 완전히 분리해야 할 필요성이 분명해졌습니다.

🪣 클라우드 스토리지의 등장 (2006년)

2006년, 아마존이 S3(Simple Storage Service)를 출시하며 파일 저장을 서버에서 완전히 떼어냈습니다. 이것이 바로 객체 스토리지 개념입니다.

기존 방식: 서버 → 폴더 → 하위 폴더 → 파일 (계층 구조)
객체 스토리지: 버킷(창고) → 객체(파일) + 키(이름) (플랫 구조)

이 단순한 구조 덕분에 파일을 서버 수천 대에 쉽게 분산 저장할 수 있게 되었습니다. 파일을 S3에 업로드하면 안전하게 보관되고, 접근 가능한 URL이 자동으로 발급됩니다.

🌐 전달 속도 해결과 권한 관리

클라우드 스토리지가 등장한 뒤에도 두 가지 과제가 남았습니다.

① CDN(콘텐츠 전달 네트워크) 서버가 물리적으로 멀리(예: 미국) 있으면 지연 시간이 발생합니다. CDN은 전 세계 엣지 서버(사용자와 가까운 곳)에 파일을 캐싱(미리 복사)해두고 빠르게 전달하여 이 문제를 해결합니다.

② 파일 권한 관리 파일을 퍼블릭(누구나 접근)과 프라이빗(인증 필요)으로 나누고, 특정 사용자에게 시간제한이 있는 프리사인드 URL(미리 서명된 URL)을 발급하여 보안을 유지합니다.

💡 핵심 원칙: 무거운 이미지·영상 파일은 스토리지에 저장하고, DB에는 오직 그 파일의 URL 위치만 저장해야 합니다.

3. DB와 스토리지의 통합 — Supabase

Firebase의 한계

현대 개발자들은 DB, 스토리지, 인증을 일일이 세팅하기보다 제품 개발 속도 자체를 더 중요하게 생각하게 되었습니다.

이를 처음 해결한 것이 구글의 Firebase였습니다. 매우 편했지만, NoSQL 기반이라는 구조적 한계가 있었습니다.

데이터 관계가 복잡해지면 쿼리가 비효율적
정교한 SQL 쿼리(JOIN, 집계 등)를 사용할 수 없음
벤더 종속(Vendor Lock-in) 문제

Supabase의 등장 (2020년)

2020년, Supabase가 등장합니다. Firebase처럼 쓰기 편하지만, 내부는 강력하고 안정적인 PostgreSQL(관계형 DB) 기반인 오픈소스 도구입니다.

Supabase가 한 번에 제공하는 5가지 핵심 기능은 다음과 같습니다.

기능	설명
데이터베이스	완벽한 관계형 DB(PostgreSQL) 및 SQL 사용 가능
인증(Auth)	이메일·소셜 로그인을 단 몇 줄의 코드로 구현
스토리지	S3 기반 파일 저장 + CDN 지원. DB의 사용자 정보와 연동(RLS)하여 파일 접근 권한 자동 관리
API 자동 생성	DB에 테이블만 만들면 백엔드 API가 자동 생성됨
실시간 DB	채팅 앱처럼 데이터 변경 사항이 즉시 화면에 반영

특히 스토리지와 인증이 DB와 연동된다는 점이 Supabase의 가장 강력한 차별점입니다. PostgreSQL의 RLS(Row Level Security) 정책을 통해, "이 파일은 업로드한 본인만 볼 수 있다"와 같은 권한 제어가 SQL 한 줄로 가능해집니다.

📝 정리

데이터 관리 기술은 60년 넘게 "이전 방식의 한계를 극복하는 방향"으로 꾸준히 진화해 왔습니다.

[x] 파일 → 관계형 DB: 중복·불일치·검색 비효율 문제를 표(Table) 구조와 SQL로 해결
[x] 관계형 DB → NoSQL: 수십억 건 데이터의 수평 확장 한계를 스키마리스 구조로 돌파
[x] 온프레미스 → 클라우드 DB: DBA의 운영 부담을 관리형 DB와 서버리스로 제거
[x] 서버 저장 → 객체 스토리지: 파일 유실·확장·성능 문제를 S3 + CDN으로 해결
[x] 개별 서비스 → Supabase 올인원: DB·스토리지·인증·API·실시간을 하나로 통합하고 권한까지 연동

과거에는 AWS, GCP 등에서 각 서비스를 따로 가져와 조립해야 했지만, 이제는 Supabase처럼 DB, 스토리지, 인증이 하나로 통합되어 서로 권한 관리까지 연동되는 시대가 되었습니다. "어떻게 만들 것인가"보다 "무엇을 만들 것인가"에 집중할 수 있는 환경이 마련된 것입니다.