[TIL] 차근차근 CS (4) - DB의 역사와 발전 과정

Today I Learned

파일 시스템의 한계와 초기 데이터베이스

DB가 없던 1950년대 후반에서 1960년대 초반의 파일 시스템은 어땠을까. 이 때는 데이터를 HDD 같은 물리적 저장 장치에 파일 형태로 저장했다. 예를 들어 회사를 가정했을 때, 고객이 늘어나면 고객과 관련된 파일을 만들고 고객 정보를 테이블에 기입한다. 뭔가 무식해보이는 방법인데, 실제로 데이터가 늘어나면 (당연히) 문제가 생겼다.

 

일반적인 이상현상이라 불리는 4대 핵심 문제(중복 저장 문제, 데이터 불일치 문제, 검색의 비효율성(당시에는 선형 탐색만 존재했다), 동시 수정 문제)가 발생했고, 이에 아예 데이터를 저장하는 방식을 새로 설계해야 한다는 흐름이 등장했다.

 

이 때 IBM의 주도 하에 계층형 DB가 등장한다. 회사 조직도와 비슷하게 데이터를 위에서 아래로 나무 구조로 저장하는 방식이며, 위아래로만 이동이 가능하다는 특징이 있다. 하지만 당연하게도 현실의 데이터는 이보다 복잡하기에 위아래로만 움직이는 구조는 매우 불편했고, 다대다 관계 표현이나 복잡한 쿼리를 수행하기에 한계가 명확했다.

 

이 다음으로는 데이터가 그물처럼 연결되어 위아래 말고도 옆으로도 연결이 가능한 네트워크 DB가 등장했다. 노드와 엣지를 통해 다대다 관계를 자연스럽게 표현할 수 있었지만, 연결이 많아질수록 코드도 복잡해지고(각 가리키는 포인터를 개발자가 소스코드 수준에서 직접 파악하고 제어해야 했기에) 해답으로 여겨지는 분위기는 아녔다.

관계형 데이터베이스(RDBMS)

1970년대 IBM에서 혁신적인 논문을 하나 발표하는데, RDBMS라는 관계형 데이터 모델에 대한 소개였다. 핵심 아이디어는 매우 단순했다. 데이터를 표로 저장하고, SQL로 데이터를 꺼내고 넣는다. 공통되는 식별자를 통해 테이블 간 연관 관계를 맺는다. (또한 SQL에는 '선언형 언어'라는 특성이 중요한데, 어떤 경로로 디스크를 뒤져서 데이터를 가져오라고 명령하던 기존 방식과 달리 SQL은 어떤 데이터를 원하는지를 선언하면 시스템이 알아서 최적의 경로를 찾아 데이터를 뽑아주는 혁신적인 직관성을 제공했다)

 

또한 정규화를 통한 이상 현상을 방지하는 설계 기법이 등장했고, 1970년대에서 80년대로 넘어가면서 RDBMS를 토대로 한 Oracle(1977; 최초 상용화. 대기업과 금융권 시장 장악), MySQL(1995; 오픈소스를 통해 표준으로 자리잡음), PostgreSQL(1996; 학술용으로 출발, MySQL의 상위호환) 등 여러 소프트웨어가 등장하기 시작했다. ACID와 인덱스 개념이 정립되기 시작했다.

수평 확장과 NoSQL

2000년대 중반에는 새로운 문제에 도달했는데, DB 규모가 늘어남에 따라 확장성 문제가 발생한 것. 원래 RDBMS는 서버 한 대에서 돌리면서 수직 확장을 하는 방식이었지만, 수평 확장이 필수가 된 것. 참고로 RDMBS는 Join 연산과 ACID을 엄격하게 지키기 위해 분산 저장을 구현하는 것이 기술적으로 구조상 매우 까다롭고 무겁다.

 

그래서 이를 해결하기 위해 NoSQL(Not Only SQL)이 등장하게 된다. 정확성 일부를 포기하되 속도와 확장성을 얻는 방식. 중요한 건 꼭 SQL이 아니어도 된다는 점. 표 구조를 버리고 각 서비스에 맞게 형식을 가져가는 방식이다.

 

데이터를 표가 아니라 JSON 형태의 문서(BSON) 구조로 통째로 저장하는 MongoDB(얼마나 유연하냐면 형식이 달라도 그냥 저장한다), 키-값 인메모리를 사용해 비교가 안 될 정도로 빠른 Redis, 와이드 컬럼 스토어 방식을 이용해 엄청나게 많은 양의 데이터를 여러 서버에 나눠 저장하는 데 특화된 Cassandra(대규모 시계열 데이터나 SNS 로그 데이터를 유실 없이 초고속으로 기록한다) 등이 있다. 물론 장단은 있다. 정확성이 중요한 금융권은 여전히 RDBMS가 필수다.

클라우드와 서버리스 환경

클라우드 시대가 열리면서 '서버 사고, DB 설치하고, 설정 관리 업데이트 전부 도맡고, 백업도 하고, 용량 차면 서버 다시 사던' 시대가 점차 바뀌기 시작. 온프레미스에서 들던 공수를 클라우드 기업이 대신 해주기 시작했기 때문. AWS RDS는 백업, 업데이트, 용량 관리를 전부 해주는 서비스. Firebase는 단순 DB를 편하게 쓰는 수준을 넘어 설정도 거의 할 필요 없이 앱에서 바로 DB를 연결할 수 있게 해줬다.

 

이 시기에 관리형 DB와 서버리스 개념이 나온다. 서버리스는 서버가 있기는 하지만 신경 쓰지 않아도 된다는 뜻에서 나온 용어. 쉽게 비유하면 집에 발전소를 둬 전기를 사용하는 게 아닌 콘센트에 전선을 꼽아 전기를 사용하는 시대가 된 것이다.

 

시간이 지나면서 스타트업은 이러한 환경 구축보다 제품 개발 속도에 신경쓰기 시작했다. (옛날만 해도 인증, 로그인 구현은 3~4일이 걸리는 작업이었다) 아이디어를 빠르게 내놓아 시장 반응을 보는 것이 가능해졌기 때문. 이걸 정면으로 돌파한 게 Supabase다. 설명은 추후 서술.

대용량 미디어 시대와 스토리지의 진화

스토리지의 역사는 다음과 같다. 컴퓨터는 원래 파일을 저장하는 도구고, 저장된 파일은 HDD에 쌓인다. 개인 컴퓨터 시대에는 이게 문제가 없었지만 인터넷과 웹이 생기면서 상황이 달라짐. 초기에는 메모장만 해도 충분했는데 바이너리 데이터(0과 1의 조합으로만 이뤄진 데이터로 사람이 읽지 못하는 데이터)로 이뤄진 사진이 들어오고 영상이 들어오기 시작한다.

 

또한 웹 사이트를 통해 사람들이 파일을 올리고 공유하기 시작. 비정형 데이터가 폭발하면서 이미지, 오디오, 동영상, PDF 등 파일들을 서버 환경에서 어떻게 안전하고 효율적으로 격리 및 저장할지가 현대 아키텍처의 거대한 숙제가 됐다.

 

처음에는 파일을 서버 특정 폴더에 저장하고 경로를 외우는 방식이었다. 만약 서버 하드웨어가 고장나면 파일도 날라갔다. 또한 서버 컴퓨터를 5대로 늘려도 1번 서버에 저장된 이미지를 3번 서버에서는 접근할 수 없기에 이미지가 깨지는 동기화 병목 현상이 발생했다. 여기에 대용량 비디오 파일을 백엔드 서버가 직접 바이트 단위로 읽어 클라이언트에 전송하면 서버 네트워크 대역폭과 CPU 자원이 여기에 전부 묶여 정작 비즈니스 로직 연산을 처리하지 못하게 됐다.

객체 스토리지(Object Storage)와 CDN

2006년 AWS S3는 스토리지에 혁신을 가져온 서비스다. 개발자가 파일을 업로드하면 자동으로 (지리적으로 분산된 최소 3개 이상의) 데이터 센터에 분산 복사한 다음, URL을 발급한다. 사용자에게는 URL로 파일이 수신되는 셈이다. 서버 하나가 고장나도 파일에는 이상이 없으며 용량도 사실상 무제한인데다 안정성이 극도로 높다. 즉, 파일 저장을 아예 서버에서 분리한 것이 현대의 스토리지다.

 

여기서 객체 스토리지 개념이 등장한다. 파일을 구조가 아닌 객체로 보는 것. 트리 형태의 중첩된 폴더 디렉토리를 타고 들어가 파일을 찾는 전통적인 파일 시스템이 아니라, 파일에 고유 ID를 부여해 단일 계층의 거대 저장소에 바둑돌처럼 나열하고 바로 찾아내는 방식이다. 즉, 파일 탐색시 폴더는 몰라도 된다. 키 이름만 알면 되는 것.

 

3대 구성 요소는 다음과 같다.

• 버킷: 저장 창고로, 최상위 수준의 독립된 가상 저장 공간이자 격리 구역이다. 하나의 프로젝트 당 하나의 서비스 단위로 버킷을 생성해 관리하는 편.
• 객체: 창고에 들어가는 파일 하나하나로, 순수 파일 데이터(바이너리)와 더불어 파일 크기, 생성일, 확장자 등을 명시한 메타데이터가 한 묶음으로 포장된 스토리지 기본 저장 단위다.
• 키: 객체의 이름으로, users/1234/profile.jpg처럼 생겼다. 여기서 슬래시는 가독성을 위한 도구로, 디렉토리가 아니다! 저 문자열 전체가 하나의 고유 식별자다.

이제 데이터 저장 문제는 해결됐으니 전송 속도만 해결하면 된다. CDN(Content Delivery Network)는 같은 파일을 전 세계 여러 엣지 서버에 미리 복사해 사용자와 가장 가까운 곳에 전달하는 방식이다. 접근 권한도 설정이 가능한데, 시간이 지나면 만료되는 Presigned URL을 설정하는 방식이 대표적이다. (비공개 첨부파일이나 유료 강의 영상 등의 주소를 노출할 때는 보안 서명 토큰을 만들어 유효 기간만 일시 다운로드를 허용하는 암호화 서명이 담긴 특별 URL을 동적으로 만드는 편이다)

스토리지는 즉, 단순 DB 뿐 아니라 저장, 접근, 전달, URL, CDN을 묶어 말하는 용어인 셈이다. 인스타그램을 예로 들면, 사용자가 사진을 업로드하면 사진이 서버로 전송된다. 서버는 파일을 S3 같은 객체 스토리지에 업로드하고, 스토리지로부터 고유 다운로드 고정 URL을 생성해 발급 받는다. 이후 서버는 DB에 이미지 대신 오직 URL 주소(텍스트)만 저장한다. 다른 사용자가 그 게시물을 볼 때 서버는 DB에서 텍스트 URL만 꺼내 프론트엔드에 내려주고, 클라이언트 브라우저가 해당 URL로 이미지를 요청하면 전 세계에 흩어진 CDN 중 가장 가까운 엣지 서버가 이미지를 초고속으로 서빙한다. 결론적으로 이미지는 안전하게 스토리지에 저장되어 있고, DB는 그 위치만 저장하고 있는 셈이다.

Supabase

Firebase는 DB와 스토리지를 한번에 해결하며 인기를 얻었지만, NoSQL인 점이 하나 걸렸다. 데이터를 표 형태로 다루지도 않았고 정교한 쿼리를 짜야할 때는 불편함이 있던 것. 오픈소스도 아니다보니 구글 정책에 종속되는 경향 역시 있었다.

 

2020년 등장한 Supabase의 핵심은 PostgreSQL을 사용한다는 점, 그리고 오픈소스라는 점이었다. S3 기반 구조를 사용하다보니 CDN 연결부터 URL 발급이 용이했고, PostgreSQL 특성상 복잡한 쿼리도 수행이 가능했다. DB에 저장된 권한 설정 역시 가능했다. 누가 어느 파일을 볼 수 있는지 DB 기준에서 자동으로 관리해준 것.

 

또한 Supabase는 PostgreSQL의 강력한 핵심 기능인 RLS(Row Level Security) 정책을 그대로 활용하기 때문에 복잡한 백엔드 보안 코드를 짤 필요 없이 DB 테이블에 '이 행 데이터와 매칭되는 인증 토큰을 가진 유저만 이 스토리지를 읽을 수 있다'는 규칙만 걸어두면 DB와 스토리지가 유기적으로 결합되어 파일 접근 권한까지 자동으로 통제해줬다.

 

테이블 생성시 내부 PostgREST 엔진이 해당 테이블에 접근 가능한 API Endpoint를 자동 생성하고, 웹소켓 기반 실시간 데이터 구독 기능이 내장되어 있어 실시간으로 DB를 변경하면 화면에서도 연동된다.

 

---

Today I Listend to