2025년 8월 20일·7분
데이터베이스 유형: 관계형, 컬럼형, 문서형, 그래프 및 그 외
관계형, 컬럼형, 문서형, 그래프, 벡터, 키-값, 시계열, 와이드-컬럼 등 주요 데이터베이스 유형을 사용 사례, 트레이드오프와 선택 팁과 함께 비교합니다.
관계형, 컬럼형, 문서형, 그래프, 벡터, 키-값, 시계열, 와이드-컬럼 등 주요 데이터베이스 유형을 사용 사례, 트레이드오프와 선택 팁과 함께 비교합니다.
“데이터베이스 유형”은 단순한 라벨이 아니라 시스템이 데이터를 어떻게 저장하는지, 어떻게 질의하는지, 무엇에 최적화되어 있는지를 압축해서 나타내는 용어입니다. 이 선택은 속도(무엇이 빠른가), 비용(하드웨어 혹은 클라우드 비용), 그리고 기능(트랜잭션, 분석, 검색, 복제 등)에 직접적인 영향을 미칩니다.
서로 다른 데이터베이스 유형은 서로 다른 트레이드오프를 만듭니다:
이런 설계 선택은 다음에 영향을 줍니다:
이 글은 주요 데이터베이스 유형을 설명하고, 각 유형에 대해:
많은 현대 제품은 경계를 흐리게 합니다. 몇몇 관계형 DB는 JSON 지원을 추가해 문서형과 겹치고, 검색/분석 플랫폼은 벡터 인덱싱을 제공하기도 합니다. 스트리밍과 저장을 결합해 시계열 기능을 제공하는 시스템도 있습니다.
그래서 “유형”은 엄격한 상자가 아닌, 기본 강점과 어떤 워크로드에 적합한지 이해하는 유용한 프레임입니다.
주요 워크로드부터 시작하세요:
그다음 “올바른 데이터베이스 유형 선택하기” 섹션을 사용해 스케일, 일관성 요구사항, 자주 실행할 쿼리 등을 기준으로 좁히세요.
관계형 데이터베이스는 많은 사람이 “데이터베이스”라고 들었을 때 떠올리는 것입니다. 데이터는 테이블로 조직되고, 각 테이블은 행(레코드)과 열(필드)로 이루어집니다. 스키마는 각 테이블의 구조—어떤 열이 있고 타입은 무엇이며 테이블 간 관계는 어떤지—를 정의합니다.
관계형 시스템은 일반적으로 **SQL(Structured Query Language)**로 질의합니다. SQL이 인기 있는 이유는 가독성 있고 표현력이 풍부하기 때문입니다:
WHERE, ORDER BY).JOIN).GROUP BY).대부분의 리포팅 도구, 분석 플랫폼, 비즈니스 앱이 SQL을 지원하므로 호환성이 필요할 때 안전한 기본값입니다.
관계형 DB는 ACID 트랜잭션으로 알려져 있으며, 데이터 정합성 유지에 도움을 줍니다:
이는 고객의 이중 청구나 재고 누락처럼 실수가 비용이 큰 경우에 중요합니다.
관계형 DB는 보통 구조화되고 잘 정의된 데이터와 다음과 같은 워크플로에 적합합니다:
관계형 DB의 구조가 신뢰성을 주지만 마찰을 더할 수 있습니다:
데이터 모델이 계속 변하거나, 단순한 접근 패턴으로 극단적인 수평 확장이 필요하다면 다른 유형이 더 적합할 수 있습니다.
컬럼형 데이터베이스는 데이터를 ‘행 단위’가 아니라 ‘열 단위’로 저장합니다. 이 하나의 차이가 분석 워크로드에서 속도와 비용에 큰 영향을 줍니다.
전통적인 행 저장소(관계형에서 흔함)에서는 한 레코드의 모든 값이 함께 저장됩니다. 단일 고객/주문을 자주 가져오거나 업데이트할 때는 이 방식이 좋습니다.
컬럼 저장소에서는 같은 필드의 모든 값이 함께 모입니다—모든 price, 모든 country, 모든 timestamp가 각각 따로 저장됩니다. 이는 리포트에 필요한 몇 개의 컬럼만 읽을 때 디스크에서 전체 행을 끌어오지 않아도 되므로 효율적입니다.
분석 및 BI 쿼리는 종종:
SUM, AVG, COUNT 같은 집계를 계산합니다컬럼 저장은 읽는 데이터 양을 줄이고, 비슷한 값이 몰려 압축 효율도 좋아 집계가 빨라집니다. 많은 컬럼형 엔진은 벡터화 실행, 스마트 인덱싱/파티셔닝도 사용합니다.
컬럼형 시스템은 대시보드와 리포팅에 적합합니다: “주별 수익”, “지역별 상위 20개 제품”, “채널별 전환율”, “지난 30일간 서비스별 오류” 등. 이런 쿼리는 많은 행을 건드리지만 읽는 컬럼은 비교적 적습니다.
워크로드가 주로 “ID로 하나의 레코드를 가져오기” 또는 “초당 수십 번씩 한 행을 업데이트”라면 컬럼형은 느리거나 비용이 높게 느껴질 수 있습니다. 쓰기는 보통 배치(append-heavy) 수집에 최적화되어 있고, 빈번한 작은 업데이트에는 적합하지 않습니다.
컬럼형 DB는 다음에 강합니다:
빠른 대량 집계가 우선이라면 컬럼형을 먼저 평가하세요.
문서형 DB는 데이터를 “문서”로 저장합니다—JSON과 매우 유사한 자체 포함 기록입니다. 정보를 여러 테이블로 분리하는 대신 관련 필드를 하나의 객체에 함께 보관하는 경우가 많습니다(중첩 배열과 서브오브젝트 포함). 이는 애플리케이션 데이터에 자연스럽게 맞습니다.
문서는 사용자, 제품, 기사 등을 나타낼 수 있고, 각 문서는 서로 다른 속성을 가질 수 있습니다. 한 제품은 size와 color를 가지지만 다른 제품은 dimensions와 materials를 가질 수 있으며, 모든 레코드에 단일한 엄격한 스키마를 강요하지 않습니다.
요구사항이 자주 바뀌거나 항목마다 필드 집합이 다를 때 이러한 유연성이 특히 도움이 됩니다.
모든 문서를 스캔하지 않기 위해 문서형 DB는 인덱스를 사용합니다—특정 쿼리와 일치하는 문서를 빠르게 찾도록 돕는 데이터 구조입니다. 일반적으로 email, sku, status 같은 자주 조회되는 필드를 인덱스화할 수 있고, 많은 시스템은 address.city 같은 중첩 필드도 인덱스할 수 있습니다. 인덱스는 읽기를 빠르게 하지만, 문서가 변경될 때 인덱스도 갱신되어 쓰기 오버헤드를 추가합니다.
문서형은 진화하는 스키마, 중첩 데이터, API 친화적 페이로드에 강합니다. 트레이드오프는 보통 다음 상황에서 드러납니다:
콘텐츠 관리, 제품 카탈로그, 사용자 프로필, 백엔드 API—“페이지/스크린/요청당 하나의 객체”로 데이터가 잘 맞아떨어지는 곳에 강력한 선택입니다.
키-값 저장소는 가장 단순한 데이터 모델입니다: 값(문자열에서 JSON 블롭까지)을 저장하고 고유 키로 검색합니다. 핵심 연산은 “이 키의 값을 줘”이기 때문에 이러한 시스템은 매우 빠를 수 있습니다.
읽기와 쓰기가 단일 기본 키에 집중되므로 키-값 저장소는 낮은 지연과 높은 처리량에 최적화될 수 있습니다. 많은 제품이 뜨거운 데이터를 메모리에 유지하고 복잡한 쿼리 계획을 최소화하며 수평 확장하도록 설계됩니다.
이 단순성은 데이터 모델링 방식에도 영향을 줍니다: 데이터베이스에 “지난주에 가입한 베를린 사용자 모두 찾기” 같은 질문을 하기보다는, 원하는 정확한 레코드를 가리키는 키를 설계하는 경우가 많습니다(예: user:1234:profile).
키-값 저장소는 캐시로 널리 사용됩니다(느린 주 DB 앞단에). 앱이 반복해서 같은 데이터를 필요로 하면—제품 상세, 사용자 권한, 가격 규칙 등—결과를 키로 캐시하면 재계산이나 재조회 비용을 피할 수 있습니다.
또한 세션 저장소(예: session:<id> -> 세션 데이터)에 자연스럽게 잘 맞습니다. 세션은 자주 읽고 업데이트하며 만료되므로 TTL을 이용해 자동으로 정리하는 경우가 많습니다.
대부분의 키-값 저장소는 **TTL(수명)**을 지원해 데이터가 자동으로 만료되게 합니다—세션, 일회성 토큰, 레이트 리밋 카운터에 이상적입니다.
메모리가 제한적일 때는 시스템이 오래된 항목을 제거하기 위한 축출 정책(예: LRU)을 사용합니다. 일부 제품은 메모리 우선이고, 일부는 내구성을 위해 디스크에 지속화할 수도 있습니다. 메모리냐 디스크냐의 선택은 속도를 최적화할지(메모리) 보존/복구를 최적화할지(디스크)에 달려있습니다.
키를 이미 알고 있는 경우 키-값 저장소는 탁월합니다. 반면 자유로운 질문(애드혹 쿼리)에는 부적합합니다.
보조 인덱스 지원은 제품마다 다릅니다: 일부는 제공하고, 일부는 제한적 옵션만 제공하거나 자체 조회 키를 유지하는 것을 권장합니다.
접근 패턴이 “ID로 가져오기/업데이트”이고 지연 시간이 중요하다면 키-값 저장소가 간단하고 신뢰할 수 있는 속도를 제공합니다.
와이드-컬럼 데이터베이스(종종 와이드-컬럼 스토어라고 불림)는 데이터를 **컬럼 패밀리(column family)**로 조직합니다. 모든 행이 같은 컬럼을 가지는 고정 테이블 대신 관련 컬럼을 그룹화하고 가족 내에서 행별로 다른 열 집합을 저장할 수 있습니다.
이름이 비슷하지만 와이드-컬럼 DB는 분석용 컬럼형과 다릅니다.
와이드-컬럼 시스템은 다음에 적합합니다:
가장 흔한 패턴은:
이 때문에 시계열 데이터와 추가 중심의 워크로드에 강합니다.
와이드-컬럼 DB에서는 데이터 모델링이 쿼리 중심입니다: 보통 필요한 정확한 쿼리에 맞춰 테이블을 설계합니다. 이는 서로 다른 접근 패턴을 지원하기 위해 데이터를 여러 형태로 중복 저장해야 할 수 있다는 뜻입니다.
또한 제한된 조인과 애드혹 쿼리 옵션을 제공하는 경향이 있으므로 복잡한 관계를 많이 사용하는 애플리케이션에는 제약이 될 수 있습니다.
와이드-컬럼은 흔히 IoT 이벤트, 메시징·활동 스트림, 그리고 빠른 쓰기와 예측 가능한 키 기반 읽기가 중요한 대규모 운영 데이터에 사용됩니다.
그래프 DB는 많은 실제 시스템이 동작하는 방식을 그대로 담습니다: 사물들이 다른 사물들과 연결되어 있다는 모델입니다. 관계를 테이블과 조인으로 억지로 표현하는 대신, 연결 자체가 데이터 모델의 일부입니다.
그래프는 보통:
이렇게 하면 네트워크, 계층구조, 다대다 관계를 스키마를 왜곡하지 않고 자연스럽게 나타낼 수 있습니다.
관계가 많은 쿼리는 관계형 DB에서 많은 조인을 필요로 합니다. 조인이 추가될수록 데이터가 커질 때 복잡성과 비용이 늘어납니다.
그래프 DB는 트래버설—한 노드에서 연결된 노드로 이동하고 다시 그 연결로 이동하는 작업—에 최적화되어 있습니다. “2~6단계 내에 연결된 항목 찾기” 같은 질문이 자주 등장한다면 트래버설은 네트워크가 커져도 빠르고 읽기 쉽습니다.
그래프 DB는 다음에 강합니다:
그래프는 팀에게 모델링의 변화를 요구할 수 있습니다: 데이터 모델링 방식이 다르고, 쿼리 언어(대개 Cypher, Gremlin, SPARQL)가 생소할 수 있습니다. 모델을 유지하기 위해 관계 유형과 방향에 대한 명확한 관행이 필요합니다.
관계가 단순하고, 쿼리가 대부분 필터/집계 중심이며 몇 번의 조인으로 충분하다면 관계형 DB가 더 직관적일 수 있습니다—특히 트랜잭션과 리포팅이 이미 잘 작동하고 있다면 더욱 그렇습니다.
벡터 DB는 특정 질문에 답하도록 설계되었습니다: “이 항목과 가장 유사한 항목은 무엇인가?” 정확한 일치(ID나 키워드)가 아니라, AI 모델이 만든 임베딩(텍스트, 이미지, 오디오, 제품의 의미를 수치로 표현) 사이의 거리를 비교합니다. 의미가 비슷한 항목들은 다차원 공간에서 가깝게 모입니다.
일반 검색은 표현이 다르면 결과를 놓칠 수 있습니다(“laptop sleeve” vs “notebook case”). 임베딩 기반 유사도는 의미를 기준으로 하므로 단어가 달라도 관련 결과를 보여줄 수 있습니다.
주요 연산은 **최근접 이웃 검색(Nearest Neighbor Search)**입니다: 쿼리 벡터를 주고, 가장 가까운 벡터들을 가져옵니다.
실제 앱에서는 보통 유사도와 함께 필터를 결합합니다. 예:
이런 “필터 + 유사도” 패턴이 벡터 검색을 실제 데이터셋에 실용적으로 만듭니다.
일반적인 사용처:
벡터 검색은 특수한 인덱스에 의존합니다. 인덱스 구축과 갱신에 시간이 걸리고 메모리를 많이 쓸 수 있습니다. 또한 더 높은 재현율(진짜 좋은 매치 더 많이 찾기)과 낮은 지연(더 빠른 응답) 사이에서 균형을 선택해야 할 때가 많습니다.
벡터 DB는 주 저장소를 대체하지 않는 경우가 대부분입니다. 일반적인 구성은: 주문, 사용자, 문서 같은 “진실의 원천”은 관계형이나 문서형에 두고, 임베딩과 검색 인덱스는 벡터 DB에 두어 검색 결과를 주 저장소의 전체 레코드와 권한으로 결합합니다.
시계열 DB(TSDB)는 연속적으로 도착하고 항상 타임스탬프와 연결된 데이터에 특화되어 있습니다. 예: 초 단위의 CPU 사용량, 각 요청의 API 지연, 분 단위 센서 값, 초당 변하는 주가 등.
시계열 레코드는 보통 다음을 조합합니다:
이 구조로 “서비스별 에러율” 또는 “지역별 지연 비교” 같은 질문을 쉽게 할 수 있습니다.
데이터량이 빠르게 증가하므로 TSDB는 보통 다음에 집중합니다:
이 기능들은 수동 정리 없이도 스토리지와 쿼리 비용을 예측 가능하게 만듭니다.
TSDB는 시간 기반 계산에서 강합니다:
일반적 사용처는 모니터링, 관찰성(observability), IoT/센서, 금융 틱 데이터입니다.
대신 복잡한 애드혹 관계(예: “사용자 → 팀 → 권한 → 프로젝트”처럼 깊은 조인)가 필요하면 TSDB는 적절하지 않습니다. 그런 경우 관계형이나 그래프 DB가 더 낫습니다.
데이터 웨어하우스는 단일 데이터베이스 유형이라기보다 많은 팀이 역사적 대량 데이터를 쿼리해 비즈니스 질문에 답하는 워크로드와 아키텍처입니다(매니지드로 구매할 수도 있지만, 웨어하우스는 중앙화되고 분석적이며 공유된 사용이 핵심입니다).
대부분의 웨어하우스는 두 가지 방식으로 데이터를 받습니다:
웨어하우스는 몇 가지 실용적 기법으로 분석에 최적화됩니다:
여러 부서가 같은 수치에 의존하면 접근 제어, 감사 로그, 계보(lineage)(메트릭이 어디서 왔고 어떻게 변형되었는지)가 필요합니다. 이는 쿼리 속도만큼이나 중요합니다.
레이크하우스는 웨어하우스 스타일의 분석과 데이터 레이크의 유연성을 결합합니다—원시 파일(로그, 이미지, 반구조화 이벤트)과 정제된 테이블을 한곳에 두고 중복을 줄이고 싶을 때 유용합니다. 데이터 양이 많고 형식이 다양하며 SQL 친화적 리포팅이 필요할 때 적합합니다.
데이터베이스 유형 선택은 ‘어떤 것이 최고인가’가 아니라 ‘무엇이 적합한가’의 문제입니다: 어떤 쿼리를 어떻게, 얼마나 빠르게, 그리고 시스템 일부가 실패했을 때 어떻게 동작해야 하는지에 따라 달라집니다.
간단한 규칙:
관계형 DB는 OLTP에, 컬럼형/웨어하우스/레이크하우스는 OLAP에 자주 사용됩니다.
네트워크 단절이 생겼을 때 세 가지를 모두 가질 수는 없습니다:
많은 분산 DB는 문제가 생기면 가용성을 유지하고 나중에 조정(점진적 일관성)을 선택합니다. 반면 일부는 엄격한 정합성을 우선해 정상 상태가 될 때까지 일부 요청을 거부합니다.
많은 사용자가 같은 데이터를 업데이트하면 명확한 규칙이 필요합니다. 트랜잭션은 단계를 "모두-또는-무(원자성)"으로 묶습니다. 락킹과 격리 수준은 충돌을 막지만 처리량을 줄일 수 있고, 느슨한 격리는 속도를 높이지만 이상 현상을 허용할 수 있습니다.
초기부터 백업, 복제, 재해 복구 계획을 세우세요. 복원 테스트, 지연 모니터링, 업그레이드 절차 등—이런 데이투(운영 2단계) 세부사항이 쿼리 속도만큼 중요합니다.
주요 데이터베이스 유형 중에서 고를 때는 유행이 아니라 데이터로 무엇을 해야 하는지를 기준으로 삼으세요. 실용적 출발점은 쿼리와 워크로드에서 역으로 생각하는 것입니다.
상위 5–10개의 핵심 작업을 적으세요:
이렇게 하면 기능 목록보다 빨리 후보를 좁힐 수 있습니다.
간단한 형태 체크리스트:
성능 목표는 아키텍처를 정의합니다. p95 지연, 초당 읽기/쓰기, 데이터 보존 기간 같은 대략적 수치를 정하세요. 비용은 보통 다음에 영향을 받습니다:
| 주요 사용사례 | 자주 적합한 선택 | 이유 |
|---|---|---|
| 트랜잭션, 송장, 사용자 계정 | 관계형(SQL) | 제약, 조인, 일관성 우수 |
| 형태가 진화하는 앱 데이터 | 문서형 | 유연한 스키마, 자연스러운 JSON |
| 실시간 캐시/세션 상태 | 키-값 저장소 | 키 기반 빠른 조회 |
| 클릭스트림/시간 기반 메트릭 | 시계열 | 높은 수집량 + 시간 기반 쿼리 |
| 대시보드, 대규모 집계 | 컬럼형 | 빠른 스캔 + 압축 |
| 소셜/지식 관계 | 그래프 | 효율적인 관계 탐색 |
| 시맨틱 검색, RAG 검색 | 벡터 | 임베딩 기반 유사도 검색 |
| 대규모 운영 데이터 | 와이드-컬럼 | 수평 확장, 예측 가능한 쿼리 |
많은 팀은 두 개의 데이터베이스를 사용합니다: 운영용(예: 관계형)과 분석용(예: 컬럼형/웨어하우스). “올바른” 선택은 가장 중요한 쿼리를 가장 단순하고 빠르며 저렴하게 안정적으로 실행하게 하는 것입니다.
프로토타이핑이나 빠른 기능 출시 단계에서는 데이터베이스 결정이 개발 워크플로와 연결됩니다. 예를 들어 일부 플랫폼(예: Koder.ai 같은 코드 생성 기반 백엔드 플랫폼)은 기본 백엔드 스택으로 Go + PostgreSQL을 사용합니다. 트랜잭션 정합성과 넓은 SQL 도구 체인이 필요할 때 좋은 출발점입니다.
제품이 성장하면(예: 시맨틱 검색을 위해 벡터 DB를 추가하거나 분석을 위해 컬럼형 웨어하우스를 추가) 특화된 데이터베이스를 더할 수 있습니다. 핵심은 오늘 지원해야 할 워크로드로 시작하고, 쿼리 패턴이 요구하면 “두 번째 저장소를 추가”할 수 있도록 문을 열어두는 것입니다.
“데이터베이스 유형”은 세 가지를 줄여 말한 것입니다:
유형을 고른다는 것은 성능, 비용, 운영 복잡성에 대한 기본값을 선택하는 것입니다.
먼저 상위 5–10개의 핵심 쿼리와 쓰기 패턴을 적어보세요. 그런 다음 이를 데이터베이스 강점에 대응시키면 과도한 고민 없이 결정할 수 있습니다:
운영용 DB와 분석용 DB를 둘 다 써야 한다면(예: OLTP + OLAP), 초기에 두 시스템(운영 DB + 분석 DB)을 염두에 두세요.
다음 상황에서 관계형 데이터베이스가 강력한 기본값입니다:
반대로 스키마 변경이 잦거나 조인 중심의 쿼리를 샤딩된 환경에서 극단적으로 확장해야 할 때는 부담이 될 수 있습니다.
ACID는 다중 단계 변경의 신뢰성 보장입니다:
결제, 예약, 재고 업데이트처럼 실수 비용이 큰 워크플로우에서 가장 중요합니다.
컬럼형 데이터베이스가 분석에서 빠른 이유는 다음과 같습니다:
SUM, COUNT, AVG, GROUP BY 같은 집계를 수행컬럼 단위 저장과 고효율 압축 덕분에 읽어야 할 데이터량이 줄어들어 집계 쿼리가 빨라집니다. 반대로 빈번한 소규모 업데이트나 단일 레코드 조회 같은 OLTP 패턴에는 덜 적합합니다.
문서형 데이터베이스가 SQL보다 더 적합한 경우:
대신 복잡한 조인, 읽기 성능을 위한 데이터 중복, 다중 문서 트랜잭션의 비용 등을 주의해야 합니다.
키-값 저장소를 사용하는 대표적 패턴은:
제한사항으로는 애드혹 쿼리가 약하고 보조 인덱스 지원이 제품마다 다르므로, 보통 키 설계와 별도의 조회 키를 직접 관리합니다.
이름이 비슷하지만 다른 워크로드를 목표로 합니다:
와이드-컬럼은 보통 쿼리 중심의 모델링을 요구하고 SQL식의 자유로운 조인을 제공하지 않습니다.
코어 문제는 유사도 검색(similarity search) 입니다. 벡터 DB는 임베딩(텍스트, 이미지, 오디오, 제품 등의 의미를 수치로 표현)을 저장하고, 주어진 쿼리 벡터와 가장 가까운 항목을 찾도록 설계됩니다. 일반적으로는:
대부분의 경우 벡터 DB는 주 저장소를 대체하지 않습니다. 소스 오브 트루스(사용자/문서 등)를 관계형이나 문서형에 두고, 임베딩과 인덱스를 벡터 DB에 두어 결과를 주 저장소의 전체 레코드/권한과 다시 결합합니다.