상황 따라 골라 쓰는 데이터베이스

데이터베이스는 구조화된 정보, 즉 데이터를 체계적으로 저장하고 관리하는 공간이다. 쉽게 말해 정보를 모아두는 저장소라고 할 수 있다.

 

그렇다면 모든 서비스에 하나의 데이터베이스만 사용해도 될까?

 

실시간 데이터 처리, 다수의 사용자 요청, 자주 바뀌는 유연한 데이터 구조 등 상황에 따라 요구되는 조건은 각각 다르다. 이처럼 요구사항에 따라 어떤 DB를 선택하느냐는 서비스의 효율성과 안정성에 큰 영향을 미친다.

 

따라서 우리는 언제 어떤 DB를 써야 할지 고민할 수밖에 없다. 그래서 다양한 종류의 데이터베이스가 어떤 특징을 가지고 있는지 알아보고 어떤 상황에 적용해 볼 수 있을지 생각해 보자!

 

RDB, 관계형 데이터베이스

 

RDB(Relational Database)는 데이터를 행과 열로 이루어진 표(테이블) 형태로 저장하는 데이터베이스이다. 그리고 각 테이블 간에는 공통된 키(Primary/Foreign Key)를 기준으로 관계를 맺을 수 있다.

 

 

 

예를 들어, 학교 시스템을 생각해 보면 다음과 같은 테이블이 있을 수 있다.

 

여기서 학생 ID와 과목 ID를 기준으로 성적 테이블을 연결하면, 어떤 학생이 어떤 과목에서 몇 점을 받았는지? 같은 정보를 효율적으로 조회할 수 있다.

 

RDB는 ACID 트랜잭션이라는 중요한 특성을 제공해 준다. 이 특성은 데이터의 정확성, 안정성, 일관성을 지켜주는 강력한 원칙을 말한다.

 

예를 들어, 고객이 장바구니에 담은 상품을 결제하는 순간 결제 정보 기록 → 재고 차감 → 배송 준비 등 여러 단계가 동시에 처리된다.

 

그런데 중간에 하나라도 실패한다면, 예를 들어 결제는 되었고 재고도 차감되었지만 배송 준비가 누락되는 상황이 생길 수 있다.

 

 

이를 방지하기 위해 RDB는 이 모든 단계를 하나의 트랜잭션으로 묶어 처리한다. 모든 단계가 성공해야만 최종적으로 반영하고, 하나라도 실패하면 전체 작업이 취소되어 원래 상태로 되돌린다.

 

다만 RDB에는 분명한 단점도 존재한다.

 

먼저, 데이터를 저장하기 전에 테이블 구조(스키마)를 미리 정의해야 하기 때문에 유연성이 떨어진다. 데이터 형식이나 구조가 자주 바뀌는 환경에서는 대응이 번거롭고 제한적일 수 있다.

 

또한, 데이터가 많아질수록 테이블 간의 복잡한 관계로 인해 수평 확장(여러 서버로의 분산 저장) 이 어렵다. JOIN 연산이 많은 RDB 특성상, 데이터를 여러 서버에 나누어 저장하고 처리하기가 까다롭다.

 

그리고 동시에 많은 요청이 들어오는 상황에서는 트랜잭션과 데이터 정합성을 유지하기 위해 락(Lock) 기반의 잠금 처리가 발생하게 되는데 이로 인해 성능 저하가 생기기도 한다.

 

Columnar 데이터베이스

 

Columnar Database(열 지향 데이터베이스)는 데이터를 열(column) 단위로 저장하고 처리하는 데이터베이스이다. 이는 일반적인 RDB처럼 행(row) 단위로 데이터를 저장하는 방식과는 다르다.

 

 

 

 

예를 들어, 학생들의 성적 데이터를 저장한다고 가정 해보자

 

행 기반(Row-oriented) 데이터베이스는 실제 파일에 데이터를 저장할 때, 한 학생의 모든 과목 점수를 하나의 행(Row) 단위로 묶어 연속적으로 저장한다. 즉, 한 줄에 수학, 영어, 과학 점수가 모두 함께 기록되는 방식이다.

 

반면, 열 기반(Column-oriented) 데이터베이스는 과목별로 모든 학생의 점수를 열(Column) 단위로 나눠 저장한다. 파일에는 수학 점수만 모아서, 영어 점수만 모아서 각각 따로 저장되기 때문에 특정 과목에 대한 전체 학생의 데이터를 빠르게 읽고 분석하는 데 유리하다

 

이러한 저장 방식 덕분에 열 기반 데이터베이스는 특정 칼럼만 선택적으로 읽을 수 있어 특정 항목에 대한 통계나 집계 연산에 매우 뛰어난 성능을 발휘한다. 그래서 대용량 데이터 분석 작업에 특히 적합하다.

 

하지만 단점도 존재한다. Columnar DB는 데이터를 컬럼 단위로 분리해 저장하는 구조이기 때문에, 한 학생의 모든 성적처럼 전체 행을 한 번에 조회해야 하는 경우에는 여러 컬럼에서 데이터를 읽어와 다시 조합해야 하므로 비효율적일 수 있다.

 

또한, 데이터를 자주 수정하거나 삽입하는 환경에서는 매번 컬럼을 분리해 저장하고 다시 정렬해야 하므로, 쓰기 성능이 낮고 실시간 처리에는 적합하지 않다.

 

Document 데이터베이스

 

Document Database는 정보를 JSON 같은 문서 형태로 저장하는 데이터베이스이다.

 

각 문서는 하나의 개체를 표현하고, 필요한 정보만 자유롭게 담을 수 있는 게 가장 큰 특징이다.

 

 

우리가 쓰는 연락처 앱을 예시를 들어보자. 모든 사람이 같은 정보를 가지고 있진 않다.

 

어떤 사람은 이름, 전화번호만 저장할 수 있고, 다른 사람은 이메일, 생일, 회사명 등등까지 적어둘 수도 있다. 또 어떤 사람은 여러 개의 전화번호나 이메일 주소를 가질 수도 있다.

 

관계형 데이터베이스에서는 모든 사람이 동일한 정보를 저장해야 하기 때문에, 다음과 같은 고정된 형태의 표(테이블)를 사용해야 한다.

 

하지만 이 구조는 다양한 속성을 가진 데이터를 유연하게 처리하기 어렵고, 모든 가능한 속성에 대해 열(Column)을 미리 만들어야 하다 보니, 실제로는 많은 열이 비어 있는 비효율적인 구조가 될 수 있다.

 

하지만 Document 데이터베이스에서는 각 사람의 정보를 필요한 만큼만 JSON 형태로 저장 가능하다.

 

이러한 특성 덕분에 불필요한 정보를 저장하지 않아 공간 낭비가 줄어들고, 구조가 유연해 변경이나 확장이 쉬운 장점이 있다.

 

또한, 실제 앱에서 사용하는 데이터 구조(JSON)와 거의 동일한 형식이기 때문에 개발 속도가 빨라지고 생산성도 높아진다.

 

하지만 너무 자유롭게 데이터를 저장할 경우 누가 어떤 정보를 가지고 있는지 파악이 어려워질 수 있으며 검색이나 정렬 같은 작업을 효과적으로 수행하려면 일정 수준의 구조 통일이 필요하다.

 

Vector 데이터베이스

 

Vector Database는 텍스트, 이미지, 음성, 영상 같은 다양한 비정형 데이터를 벡터(숫자의 집합)로 바꿔 저장하는 데이터베이스이다. 이 과정은 임베딩(embedding)이라고 하며, AI 모델이 이 데이터와 비슷한 다른 데이터를 찾을 수 있게 만들어주는 핵심 기술이다.

 

 

벡터 데이터베이스는 이렇게 변환된 벡터들을 효율적으로 저장하고, 벡터 간의 거리 계산을 최적화함으로써 유사한 데이터를 빠르게 찾아주는 검색 기능을 제공한다.

 

이러한 특성을 활용해 넷플릭스는 사용자의 시청 이력을 벡터로 변환해 개인 맞춤형 콘텐츠를 추천하고 있으며, 핀터레스트는 이미지를 벡터로 저장해 비슷한 이미지를 빠르게 찾아주는 기능을 제공하고 있다.

 

최근 Vector Database가 주목받는 이유는 다음과 같다.

 

먼저, ChatGPT와 같은 LLM(Large Language Model)은 사전에 학습된 데이터 외의 정보는 알 수 없고, 때로는 존재하지 않는 내용을 지어내는 문제가 발생하기도 한다.

 

이러한 한계를 극복하기 위해 등장한 기술이 바로 RAG(Retrieval-Augmented Generation) 이다.

 

RAG는 사용자의 질문이 들어오면 먼저 Vector Database에서 관련 정보를 검색하고, 그 결과를 기반으로 LLM이 더 정확하고 근거 있는 답변을 생성하는 방식이다.

 

이처럼 Vector Database는 단순한 검색 엔진을 넘어, LLM의 정확도를 높이고 최신 정보에 기반한 응답을 가능하게 하는 핵심 인프라로 자리 잡고 있다.

 

그 외 데이터베이스

 

 

이외에도 용도에 따라 다양한 형태의 데이터베이스가 존재한다.

 

Graph Database는 데이터 간의 관계를 노드와 간선으로 표현해, 복잡한 연결 관계를 빠르게 탐색할 수 있다. 소셜 네트워크나 추천 시스템처럼 데이터 간 연관성이 중요한 서비스에 많이 활용된다.

 

Key-Value Database는 데이터를 Key-Value(키-값) 쌍 형태로 단순하게 저장하며, 빠른 조회 성능이 필요한 캐시, 세션 저장소 등에 적합하다. 대표적인 예로는 Redis, DynamoDB가 있다.

 

Time Series Database는 시간의 흐름에 따라 수집되는 데이터를 효율적으로 저장하고 분석할 수 있도록 설계되어 있다. 센서 데이터, 서버 로그, 주가 정보 등 시계열 데이터 처리에 특화되어 있으며, 대표적으로 InfluxDB, TimescaleDB 등이 사용된다.

 

마치며

 

이번 글을 통해 다양한 종류의 데이터베이스를 살펴보며 실제 업무에서 요구되는 조건이 무엇인지 파악하고 각 데이터베이스의 장점과 단점을 이해한 뒤, 상황에 맞는 데이터베이스를 선택하는 것이 왜 중요한지 확인할 수 있었다.