데이터베이스 유형: 관계형, 컬럼형, 문서형, 그래프 및 그 외

“데이터베이스 유형”이 실제로 의미하는 것

“데이터베이스 유형”은 단순한 라벨이 아니라 시스템이 데이터를 어떻게 저장하는지, 어떻게 질의하는지, 무엇에 최적화되어 있는지를 압축해서 나타내는 용어입니다. 이 선택은 속도(무엇이 빠른가), 비용(하드웨어 혹은 클라우드 비용), 그리고 기능(트랜잭션, 분석, 검색, 복제 등)에 직접적인 영향을 미칩니다.

왜 “유형”이 중요한가

서로 다른 데이터베이스 유형은 서로 다른 트레이드오프를 만듭니다:

• 관계형 데이터베이스는 데이터가 구조화되어 있고 신뢰할 수 있는 트랜잭션이 필요할 때 좋습니다.
• 컬럼형 데이터베이스는 많은 행을 스캔해 분석 질문에 답할 때 빛을 발합니다.
• 문서형 데이터베이스는 앱의 데이터 형태가 자주 바뀔 때 더 빠르게 움직일 수 있습니다.
• 그래프 데이터베이스는 관계가 많은 데이터에 적합합니다.
• 벡터 데이터베이스는 정확한 일치보다 “유사성”에 초점을 맞춥니다.

이런 설계 선택은 다음에 영향을 줍니다:

• 쿼리 패턴: 작은 조회가 많은가, 복잡한 조인이 많은가, 아니면 대규모 분석 스캔이 많은가?
• 스케일 모델: 하나의 큰 머신을 키울 것인가, 여러 대로 분산할 것인가?
• 데이터 모델: 테이블, 문서, 키-값, 그래프, 벡터, 시계열 포인트 중 무엇인가?

이 가이드에서 배울 것

이 글은 주요 데이터베이스 유형을 설명하고, 각 유형에 대해:

• 무엇에 강한지(그리고 약한지)
• 실제 제품에서의 전형적 사용 사례
• 성능, 비용, 복잡성에 영향을 주는 주요 트레이드오프

“멀티모델” 시스템에 대한 짧은 메모

많은 현대 제품은 경계를 흐리게 합니다. 몇몇 관계형 DB는 JSON 지원을 추가해 문서형과 겹치고, 검색/분석 플랫폼은 벡터 인덱싱을 제공하기도 합니다. 스트리밍과 저장을 결합해 시계열 기능을 제공하는 시스템도 있습니다.

그래서 “유형”은 엄격한 상자가 아닌, 기본 강점과 어떤 워크로드에 적합한지 이해하는 유용한 프레임입니다.

이 가이드를 활용해 후보를 압축하는 방법

주요 워크로드부터 시작하세요:

• 구조화된 데이터와 트랜잭션이 필요하면 관계형 데이터베이스부터 검토하세요.
• 리포팅과 대시보드가 많다면 컬럼형 데이터베이스나 데이터 웨어하우스를 보세요.
• 앱 데이터의 형태가 자주 바뀌면 문서형 데이터베이스를 고려하세요.
• 매우 빠른 키 조회가 필요하면 키-값 저장소가 강력한 후보입니다.

그다음 “올바른 데이터베이스 유형 선택하기” 섹션을 사용해 스케일, 일관성 요구사항, 자주 실행할 쿼리 등을 기준으로 좁히세요.

관계형 데이터베이스(SQL): 구조화된 데이터의 기본

관계형 데이터베이스는 많은 사람이 “데이터베이스”라고 들었을 때 떠올리는 것입니다. 데이터는 테이블로 조직되고, 각 테이블은 행(레코드)과 열(필드)로 이루어집니다. 스키마는 각 테이블의 구조—어떤 열이 있고 타입은 무엇이며 테이블 간 관계는 어떤지—를 정의합니다.

왜 SQL이 널리 쓰이나

관계형 시스템은 일반적으로 **SQL(Structured Query Language)**로 질의합니다. SQL이 인기 있는 이유는 가독성 있고 표현력이 풍부하기 때문입니다:

• 데이터를 필터링하고 정렬할 수 있습니다 (WHERE, ORDER BY).
• 테이블 간 데이터를 결합할 수 있습니다 (JOIN).
• 결과를 요약할 수 있습니다 (GROUP BY).

대부분의 리포팅 도구, 분석 플랫폼, 비즈니스 앱이 SQL을 지원하므로 호환성이 필요할 때 안전한 기본값입니다.

쉬운 설명의 ACID 트랜잭션

관계형 DB는 ACID 트랜잭션으로 알려져 있으며, 데이터 정합성 유지에 도움을 줍니다:

• 원자성(Atomicity): 다단계 변경은 ‘모두 성공’ 아니면 ‘전혀 적용되지 않음’.
• 일관성(Consistency): 변경 후에도 규칙(예: 외래키)이 유지됨.
• 고립성(Isolation): 동시 업데이트가 서로를 망가뜨리지 않음.
• 내구성(Durability): 저장되면 충돌 뒤에도 유지됨.

이는 고객의 이중 청구나 재고 누락처럼 실수가 비용이 큰 경우에 중요합니다.

적합한 워크로드

관계형 DB는 보통 구조화되고 잘 정의된 데이터와 다음과 같은 워크플로에 적합합니다:

• 비즈니스 애플리케이션(CRM/ERP 등)
• 금융, 결제, 청구
• 재고, 주문, 예약

주의할 점

관계형 DB의 구조가 신뢰성을 주지만 마찰을 더할 수 있습니다:

• 경직된 스키마: 데이터 형태가 자주 바뀌면 마이그레이션이 필요합니다.
• 조인 중심의 확장 한계: 큰 테이블에서 많은 조인을 하면, 특히 데이터가 여러 머신에 분산된 경우 느려지거나 비용이 커질 수 있습니다.

데이터 모델이 계속 변하거나, 단순한 접근 패턴으로 극단적인 수평 확장이 필요하다면 다른 유형이 더 적합할 수 있습니다.

컬럼형 데이터베이스: 분석을 위해 설계됨

컬럼형 데이터베이스는 데이터를 ‘행 단위’가 아니라 ‘열 단위’로 저장합니다. 이 하나의 차이가 분석 워크로드에서 속도와 비용에 큰 영향을 줍니다.

행 저장소 vs 컬럼 저장소

전통적인 행 저장소(관계형에서 흔함)에서는 한 레코드의 모든 값이 함께 저장됩니다. 단일 고객/주문을 자주 가져오거나 업데이트할 때는 이 방식이 좋습니다.

컬럼 저장소에서는 같은 필드의 모든 값이 함께 모입니다—모든 price, 모든 country, 모든 timestamp가 각각 따로 저장됩니다. 이는 리포트에 필요한 몇 개의 컬럼만 읽을 때 디스크에서 전체 행을 끌어오지 않아도 되므로 효율적입니다.

분석에서 컬럼형이 빠른 이유

분석 및 BI 쿼리는 종종:

• 많은 레코드를 스캔하고
• 적은 수의 컬럼을 선택하며
• SUM, AVG, COUNT 같은 집계를 계산합니다

컬럼 저장은 읽는 데이터 양을 줄이고, 비슷한 값이 몰려 압축 효율도 좋아 집계가 빨라집니다. 많은 컬럼형 엔진은 벡터화 실행, 스마트 인덱싱/파티셔닝도 사용합니다.

전형적인 쿼리 패턴

컬럼형 시스템은 대시보드와 리포팅에 적합합니다: “주별 수익”, “지역별 상위 20개 제품”, “채널별 전환율”, “지난 30일간 서비스별 오류” 등. 이런 쿼리는 많은 행을 건드리지만 읽는 컬럼은 비교적 적습니다.

트레이드오프: OLTP 스타일 업데이트와 포인트 조회

워크로드가 주로 “ID로 하나의 레코드를 가져오기” 또는 “초당 수십 번씩 한 행을 업데이트”라면 컬럼형은 느리거나 비용이 높게 느껴질 수 있습니다. 쓰기는 보통 배치(append-heavy) 수집에 최적화되어 있고, 빈번한 작은 업데이트에는 적합하지 않습니다.

적합한 경우

컬럼형 DB는 다음에 강합니다:

• BI 및 경영진 대시보드
• 이벤트 및 클릭스트림 분석
• 로그나 거래에 대한 대규모 리포팅

빠른 대량 집계가 우선이라면 컬럼형을 먼저 평가하세요.

문서형 데이터베이스: 앱 데이터에 적합한 유연한 스키마

문서형 DB는 데이터를 “문서”로 저장합니다—JSON과 매우 유사한 자체 포함 기록입니다. 정보를 여러 테이블로 분리하는 대신 관련 필드를 하나의 객체에 함께 보관하는 경우가 많습니다(중첩 배열과 서브오브젝트 포함). 이는 애플리케이션 데이터에 자연스럽게 맞습니다.

문서 모델(비슷한 JSON 레코드)

문서는 사용자, 제품, 기사 등을 나타낼 수 있고, 각 문서는 서로 다른 속성을 가질 수 있습니다. 한 제품은 size와 color를 가지지만 다른 제품은 dimensions와 materials를 가질 수 있으며, 모든 레코드에 단일한 엄격한 스키마를 강요하지 않습니다.

요구사항이 자주 바뀌거나 항목마다 필드 집합이 다를 때 이러한 유연성이 특히 도움이 됩니다.

인덱싱(개괄)

모든 문서를 스캔하지 않기 위해 문서형 DB는 인덱스를 사용합니다—특정 쿼리와 일치하는 문서를 빠르게 찾도록 돕는 데이터 구조입니다. 일반적으로 email, sku, status 같은 자주 조회되는 필드를 인덱스화할 수 있고, 많은 시스템은 address.city 같은 중첩 필드도 인덱스할 수 있습니다. 인덱스는 읽기를 빠르게 하지만, 문서가 변경될 때 인덱스도 갱신되어 쓰기 오버헤드를 추가합니다.

강점과 트레이드오프

문서형은 진화하는 스키마, 중첩 데이터, API 친화적 페이로드에 강합니다. 트레이드오프는 보통 다음 상황에서 드러납니다:

• 여러 엔티티에 걸친 복잡한 조인(관계형보다 덜 자연스러울 수 있음)
• 고스케일의 다중 문서 트랜잭션(많은 제품에서 지원하지만 성능 비용이 발생할 수 있음)
• 엄격한 정규화(읽기를 단순화하기 위해 데이터를 복제하면 업데이트 로직을 신중히 설계해야 함)

일반적 사용 사례

콘텐츠 관리, 제품 카탈로그, 사용자 프로필, 백엔드 API—“페이지/스크린/요청당 하나의 객체”로 데이터가 잘 맞아떨어지는 곳에 강력한 선택입니다.

키-값 저장소: 단순하고 매우 빠른 조회

키-값 저장소는 가장 단순한 데이터 모델입니다: 값(문자열에서 JSON 블롭까지)을 저장하고 고유 키로 검색합니다. 핵심 연산은 “이 키의 값을 줘”이기 때문에 이러한 시스템은 매우 빠를 수 있습니다.

키-값 모델(왜 빠른가)

읽기와 쓰기가 단일 기본 키에 집중되므로 키-값 저장소는 낮은 지연과 높은 처리량에 최적화될 수 있습니다. 많은 제품이 뜨거운 데이터를 메모리에 유지하고 복잡한 쿼리 계획을 최소화하며 수평 확장하도록 설계됩니다.

이 단순성은 데이터 모델링 방식에도 영향을 줍니다: 데이터베이스에 “지난주에 가입한 베를린 사용자 모두 찾기” 같은 질문을 하기보다는, 원하는 정확한 레코드를 가리키는 키를 설계하는 경우가 많습니다(예: user:1234:profile).

캐시와 세션에 인기 있는 이유

키-값 저장소는 캐시로 널리 사용됩니다(느린 주 DB 앞단에). 앱이 반복해서 같은 데이터를 필요로 하면—제품 상세, 사용자 권한, 가격 규칙 등—결과를 키로 캐시하면 재계산이나 재조회 비용을 피할 수 있습니다.

또한 세션 저장소(예: session:<id> -> 세션 데이터)에 자연스럽게 잘 맞습니다. 세션은 자주 읽고 업데이트하며 만료되므로 TTL을 이용해 자동으로 정리하는 경우가 많습니다.

TTL, 축출(eviction), 메모리 vs 디스크

대부분의 키-값 저장소는 **TTL(수명)**을 지원해 데이터가 자동으로 만료되게 합니다—세션, 일회성 토큰, 레이트 리밋 카운터에 이상적입니다.

메모리가 제한적일 때는 시스템이 오래된 항목을 제거하기 위한 축출 정책(예: LRU)을 사용합니다. 일부 제품은 메모리 우선이고, 일부는 내구성을 위해 디스크에 지속화할 수도 있습니다. 메모리냐 디스크냐의 선택은 속도를 최적화할지(메모리) 보존/복구를 최적화할지(디스크)에 달려있습니다.

사전 인지해야 할 트레이드오프

키를 이미 알고 있는 경우 키-값 저장소는 탁월합니다. 반면 자유로운 질문(애드혹 쿼리)에는 부적합합니다.

보조 인덱스 지원은 제품마다 다릅니다: 일부는 제공하고, 일부는 제한적 옵션만 제공하거나 자체 조회 키를 유지하는 것을 권장합니다.

일반적 사용 사례

• 레이트 리밋: 사용자/IP별 카운터 + TTL 윈도우
• 피처 플래그: 사용자/코호트별 빠른 읽기
• 장바구니: 사용자/세션 키로 빠르게 업데이트되는 카트 객체

접근 패턴이 “ID로 가져오기/업데이트”이고 지연 시간이 중요하다면 키-값 저장소가 간단하고 신뢰할 수 있는 속도를 제공합니다.

와이드-컬럼 데이터베이스: 스케일 아웃 운영 스토리지

와이드-컬럼 데이터베이스(종종 와이드-컬럼 스토어라고 불림)는 데이터를 **컬럼 패밀리(column family)**로 조직합니다. 모든 행이 같은 컬럼을 가지는 고정 테이블 대신 관련 컬럼을 그룹화하고 가족 내에서 행별로 다른 열 집합을 저장할 수 있습니다.

와이드-컬럼 vs 분석용 컬럼형

이름이 비슷하지만 와이드-컬럼 DB는 분석용 컬럼형과 다릅니다.

• 컬럼형 데이터베이스는 각각의 컬럼을 따로 저장해 대규모 데이터 스캔에 효율적입니다(분석에 좋음).
• 와이드-컬럼 데이터베이스는 많은 머신에 걸쳐 빠른 읽기/쓰기 성능을 제공하는 운영 워크로드에 적합합니다.

장점이 발휘되는 곳

와이드-컬럼 시스템은 다음에 적합합니다:

• 높은 쓰기 처리량(초당 많은 이벤트 수집)
• 수평 확장(노드를 추가해 트래픽과 데이터를 감당)
• 예측 가능한 저지연 읽기(올바른 키로 조회할 때)

전형적 접근 패턴

가장 흔한 패턴은:

• 파티션 키를 알고 있으며(데이터가 어디에 위치할지 결정)
• 그 파티션 내에서 범위를 읽는 경우가 많음(예: “장치 X의 10:00–10:05 사이 모든 이벤트”)

이 때문에 시계열 데이터와 추가 중심의 워크로드에 강합니다.

이해해야 할 트레이드오프

와이드-컬럼 DB에서는 데이터 모델링이 쿼리 중심입니다: 보통 필요한 정확한 쿼리에 맞춰 테이블을 설계합니다. 이는 서로 다른 접근 패턴을 지원하기 위해 데이터를 여러 형태로 중복 저장해야 할 수 있다는 뜻입니다.

또한 제한된 조인과 애드혹 쿼리 옵션을 제공하는 경향이 있으므로 복잡한 관계를 많이 사용하는 애플리케이션에는 제약이 될 수 있습니다.

일반적 사용 사례

와이드-컬럼은 흔히 IoT 이벤트, 메시징·활동 스트림, 그리고 빠른 쓰기와 예측 가능한 키 기반 읽기가 중요한 대규모 운영 데이터에 사용됩니다.

그래프 데이터베이스: 관계를 1순위로 다룸

그래프 DB는 많은 실제 시스템이 동작하는 방식을 그대로 담습니다: 사물들이 다른 사물들과 연결되어 있다는 모델입니다. 관계를 테이블과 조인으로 억지로 표현하는 대신, 연결 자체가 데이터 모델의 일부입니다.

그래프 모델: 노드, 엣지, 속성

그래프는 보통:

• 노드: 엔티티(사람, 계정, 장치, 제품)
• 엣지: 이들 간의 관계(“팔로우”, “지불”, “속한다”, “배송됨”)
• 속성: 노드나 엣지에 붙는 키-값(타임스탬프, 금액, 라벨)

이렇게 하면 네트워크, 계층구조, 다대다 관계를 스키마를 왜곡하지 않고 자연스럽게 나타낼 수 있습니다.

트래버설이 조인보다 나은 경우

관계가 많은 쿼리는 관계형 DB에서 많은 조인을 필요로 합니다. 조인이 추가될수록 데이터가 커질 때 복잡성과 비용이 늘어납니다.

그래프 DB는 트래버설—한 노드에서 연결된 노드로 이동하고 다시 그 연결로 이동하는 작업—에 최적화되어 있습니다. “2~6단계 내에 연결된 항목 찾기” 같은 질문이 자주 등장한다면 트래버설은 네트워크가 커져도 빠르고 읽기 쉽습니다.

그래프가 특히 잘 답하는 질문

그래프 DB는 다음에 강합니다:

• 경로와 분리도(최단 경로, 도달 가능성)
• 추천(“X를 산 사용자가 함께 산 Y”, “친구의 친구”)
• 사기 연결망과 이상 패턴(공유된 장치, 주소, 결제 수단)

계획해야 할 트레이드오프

그래프는 팀에게 모델링의 변화를 요구할 수 있습니다: 데이터 모델링 방식이 다르고, 쿼리 언어(대개 Cypher, Gremlin, SPARQL)가 생소할 수 있습니다. 모델을 유지하기 위해 관계 유형과 방향에 대한 명확한 관행이 필요합니다.

언제 관계형 모델로도 충분한가

관계가 단순하고, 쿼리가 대부분 필터/집계 중심이며 몇 번의 조인으로 충분하다면 관계형 DB가 더 직관적일 수 있습니다—특히 트랜잭션과 리포팅이 이미 잘 작동하고 있다면 더욱 그렇습니다.

벡터 데이터베이스: AI 애플리케이션을 위한 유사도 검색

벡터 DB는 특정 질문에 답하도록 설계되었습니다: “이 항목과 가장 유사한 항목은 무엇인가?” 정확한 일치(ID나 키워드)가 아니라, AI 모델이 만든 임베딩(텍스트, 이미지, 오디오, 제품의 의미를 수치로 표현) 사이의 거리를 비교합니다. 의미가 비슷한 항목들은 다차원 공간에서 가깝게 모입니다.

벡터가 시맨틱 검색을 여는 이유

일반 검색은 표현이 다르면 결과를 놓칠 수 있습니다(“laptop sleeve” vs “notebook case”). 임베딩 기반 유사도는 의미를 기준으로 하므로 단어가 달라도 관련 결과를 보여줄 수 있습니다.

핵심 연산: 유사도 + 필터

주요 연산은 **최근접 이웃 검색(Nearest Neighbor Search)**입니다: 쿼리 벡터를 주고, 가장 가까운 벡터들을 가져옵니다.

실제 앱에서는 보통 유사도와 함께 필터를 결합합니다. 예:

• 특정 고객의 문서만 보기
• 특정 제품 카테고리나 언어로 제한
• 보관 처리된 항목이나 품질이 낮은 항목 제외

이런 “필터 + 유사도” 패턴이 벡터 검색을 실제 데이터셋에 실용적으로 만듭니다.

적합한 곳

일반적인 사용처:

• RAG(검색 보강 생성): LLM이 답하기 전에 가장 관련성 높은 문단을 가져오기
• 시맨틱 검색: 지식베이스, 지원 티켓, 내부 문서 검색
• 추천: 콘텐츠 유사성 기반 추천

알아둘 트레이드오프

벡터 검색은 특수한 인덱스에 의존합니다. 인덱스 구축과 갱신에 시간이 걸리고 메모리를 많이 쓸 수 있습니다. 또한 더 높은 재현율(진짜 좋은 매치 더 많이 찾기)과 낮은 지연(더 빠른 응답) 사이에서 균형을 선택해야 할 때가 많습니다.

관계형/문서형 저장소와의 페어링

벡터 DB는 주 저장소를 대체하지 않는 경우가 대부분입니다. 일반적인 구성은: 주문, 사용자, 문서 같은 “진실의 원천”은 관계형이나 문서형에 두고, 임베딩과 검색 인덱스는 벡터 DB에 두어 검색 결과를 주 저장소의 전체 레코드와 권한으로 결합합니다.

시계열 데이터베이스: 시간에 따른 지표에 최적화

시계열 DB(TSDB)는 연속적으로 도착하고 항상 타임스탬프와 연결된 데이터에 특화되어 있습니다. 예: 초 단위의 CPU 사용량, 각 요청의 API 지연, 분 단위 센서 값, 초당 변하는 주가 등.

시계열 데이터의 형태

시계열 레코드는 보통 다음을 조합합니다:

• 타임스탬프: 측정이 발생한 시점
• 메트릭/값: 추적하는 수치(지연, 온도, 가격)
• 태그/라벨: 필터와 그룹화에 쓰이는 메타데이터(host=web-01, region=us-east, service=checkout)

이 구조로 “서비스별 에러율” 또는 “지역별 지연 비교” 같은 질문을 쉽게 할 수 있습니다.

TSDB가 주로 사용하는 성능 기능

데이터량이 빠르게 증가하므로 TSDB는 보통 다음에 집중합니다:

• 압축: 긴 수치 시퀀스를 효율적으로 저장
• 보존 정책(retention): 오래된 데이터를 자동으로 만료(예: 원시 데이터 7일, 집계 90일)
• 다운샘플링: 상세를 요약으로 롤업(초 → 분 → 시간)

이 기능들은 수동 정리 없이도 스토리지와 쿼리 비용을 예측 가능하게 만듭니다.

흔한 쿼리 패턴

TSDB는 시간 기반 계산에서 강합니다:

• 이동 평균(예: 5분 이동 평균)
• 백분위수(p95/p99 지연)
• 변화율(초당 요청 수)
• 임계값/이상치에 대한 알림

적합한 곳과 아닌 곳

일반적 사용처는 모니터링, 관찰성(observability), IoT/센서, 금융 틱 데이터입니다.

대신 복잡한 애드혹 관계(예: “사용자 → 팀 → 권한 → 프로젝트”처럼 깊은 조인)가 필요하면 TSDB는 적절하지 않습니다. 그런 경우 관계형이나 그래프 DB가 더 낫습니다.

웨어하우스와 레이크하우스: 조직 규모의 분석

데이터 웨어하우스는 단일 데이터베이스 유형이라기보다 많은 팀이 역사적 대량 데이터를 쿼리해 비즈니스 질문에 답하는 워크로드와 아키텍처입니다(매니지드로 구매할 수도 있지만, 웨어하우스는 중앙화되고 분석적이며 공유된 사용이 핵심입니다).

배치 vs 스트리밍 수집(간단히)

대부분의 웨어하우스는 두 가지 방식으로 데이터를 받습니다:

• 배치 수집: 데이터가 매시간/매일 단위로 들어옴(앱 DB의 야간 덤프 등). 비용이 낮고 간단하지만 실시간성이 떨어집니다.
• 스트리밍 수집: 이벤트가 지속적으로 도착(클릭, 결제, IoT). 더 신선한 수치를 보지만 파이프라인과 모니터링이 더 중요합니다.

빠른 이유: 컬럼형 스토리지, 파티셔닝, 물리화 뷰

웨어하우스는 몇 가지 실용적 기법으로 분석에 최적화됩니다:

• 컬럼형 스토리지: 리포트에 필요한 컬럼만 읽음
• 파티셔닝: 큰 테이블을 시간/지역으로 분할해 스캔량을 줄임
• 물리화 뷰(materialized views): 미리 계산된 결과를 저장해 대시보드 속도를 높임

규모에서 거버넌스는 선택이 아님

여러 부서가 같은 수치에 의존하면 접근 제어, 감사 로그, 계보(lineage)(메트릭이 어디서 왔고 어떻게 변형되었는지)가 필요합니다. 이는 쿼리 속도만큼이나 중요합니다.

레이크하우스가 적합한 경우

레이크하우스는 웨어하우스 스타일의 분석과 데이터 레이크의 유연성을 결합합니다—원시 파일(로그, 이미지, 반구조화 이벤트)과 정제된 테이블을 한곳에 두고 중복을 줄이고 싶을 때 유용합니다. 데이터 양이 많고 형식이 다양하며 SQL 친화적 리포팅이 필요할 때 적합합니다.

핵심 트레이드오프: 일관성, 스케일, 쿼리 패턴

데이터베이스 유형 선택은 ‘어떤 것이 최고인가’가 아니라 ‘무엇이 적합한가’의 문제입니다: 어떤 쿼리를 어떻게, 얼마나 빠르게, 그리고 시스템 일부가 실패했을 때 어떻게 동작해야 하는지에 따라 달라집니다.

OLTP vs OLAP (워크로드에 맞추기)

간단한 규칙:

• OLTP(온라인 트랜잭션): 작은 읽기/쓰기 다발(체크아웃, 로그인, 주문 업데이트). 우선순위: 낮은 지연, 정확한 업데이트, 많은 동시 사용자.
• OLAP(분석): 적지만 무거운 쿼리(대시보드, 트렌드). 우선순위: 빠른 집계, 컬럼형 스토리지, 컴퓨트와 스토리지 분리.

관계형 DB는 OLTP에, 컬럼형/웨어하우스/레이크하우스는 OLAP에 자주 사용됩니다.

CAP를 쉬운 언어로

네트워크 단절이 생겼을 때 세 가지를 모두 가질 수는 없습니다:

• Consistency(일관성): 모두가 즉시 같은 데이터를 봄
• Availability(가용성): 시스템이 계속 응답함
• Partition tolerance(파티션 허용성): 네트워크 분할에도 동작함

많은 분산 DB는 문제가 생기면 가용성을 유지하고 나중에 조정(점진적 일관성)을 선택합니다. 반면 일부는 엄격한 정합성을 우선해 정상 상태가 될 때까지 일부 요청을 거부합니다.

스케일링: 수직, 수평, 샤딩

• 수직 확장: 더 큰 머신—단순하지만 한계가 있음.
• 수평 확장: 여러 머신—더 많은 용량, 더 많은 조정 필요.
• 샤딩: 데이터를 노드에 분할(보통 고객 ID별). 스케일을 높이지만 샤드 간 쿼리와 트랜잭션은 복잡해집니다.

트랜잭션과 동시성 기초

많은 사용자가 같은 데이터를 업데이트하면 명확한 규칙이 필요합니다. 트랜잭션은 단계를 "모두-또는-무(원자성)"으로 묶습니다. 락킹과 격리 수준은 충돌을 막지만 처리량을 줄일 수 있고, 느슨한 격리는 속도를 높이지만 이상 현상을 허용할 수 있습니다.

운영상의 고려사항(놓치지 말아야 함)

초기부터 백업, 복제, 재해 복구 계획을 세우세요. 복원 테스트, 지연 모니터링, 업그레이드 절차 등—이런 데이투(운영 2단계) 세부사항이 쿼리 속도만큼 중요합니다.

올바른 데이터베이스 유형을 선택하는 방법

주요 데이터베이스 유형 중에서 고를 때는 유행이 아니라 데이터로 무엇을 해야 하는지를 기준으로 삼으세요. 실용적 출발점은 쿼리와 워크로드에서 역으로 생각하는 것입니다.

1) 데이터가 아니라 쿼리에서 시작하세요

상위 5–10개의 핵심 작업을 적으세요:

• 가장 자주 무엇을 읽나(단일 레코드 조회, 필터, 조인, 집계, 유사도 검색)?
• 가장 자주 무엇을 쓰나(단일 행 삽입, 이벤트 스트림, 업데이트, 대량 로드)?
• 결과 신선도는 얼마나 필요한가(밀리초, 초, 분)?

이렇게 하면 기능 목록보다 빨리 후보를 좁힐 수 있습니다.

2) 데이터 형태에 맞춰 데이터베이스를 매칭하세요

간단한 형태 체크리스트:

• 구조화되고 일관된 필드 → 관계형 데이터베이스
• 자주 바뀌는 반구조화 JSON → 문서형 데이터베이스
• 깊게 탐색하는 다대다 관계 → 그래프 데이터베이스
• 임베딩과 근접 검색 → 벡터 데이터베이스
• 타임스탬프가 있는 이벤트/메트릭 → 시계열 데이터베이스
• 예측 가능한 접근 패턴의 대규모 분산 테이블 → 와이드-컬럼 데이터베이스
• 매우 단순한 get/set by key → 키-값 저장소
• 대규모 스캔과 집계가 많은 분석 → 컬럼형 데이터베이스(또는 웨어하우스)

3) 지연, 처리량, 비용 요인을 일찍 명확히 하세요

성능 목표는 아키텍처를 정의합니다. p95 지연, 초당 읽기/쓰기, 데이터 보존 기간 같은 대략적 수치를 정하세요. 비용은 보통 다음에 영향을 받습니다:

• 스토리지(원시 데이터 + 복제본)
• 컴퓨트(쿼리, ETL/ELT, 백그라운드 작업)
• 복제(다중 리전, 고가용성)
• 인덱싱(빠른 쿼리 = 더 많은 쓰기 오버헤드)

4) 간단한 결정표

많은 팀은 두 개의 데이터베이스를 사용합니다: 운영용(예: 관계형)과 분석용(예: 컬럼형/웨어하우스). “올바른” 선택은 가장 중요한 쿼리를 가장 단순하고 빠르며 저렴하게 안정적으로 실행하게 하는 것입니다.

제품을 빠르게 개발할 때의 실무적 메모

프로토타이핑이나 빠른 기능 출시 단계에서는 데이터베이스 결정이 개발 워크플로와 연결됩니다. 예를 들어 일부 플랫폼(예: Koder.ai 같은 코드 생성 기반 백엔드 플랫폼)은 기본 백엔드 스택으로 Go + PostgreSQL을 사용합니다. 트랜잭션 정합성과 넓은 SQL 도구 체인이 필요할 때 좋은 출발점입니다.

제품이 성장하면(예: 시맨틱 검색을 위해 벡터 DB를 추가하거나 분석을 위해 컬럼형 웨어하우스를 추가) 특화된 데이터베이스를 더할 수 있습니다. 핵심은 오늘 지원해야 할 워크로드로 시작하고, 쿼리 패턴이 요구하면 “두 번째 저장소를 추가”할 수 있도록 문을 열어두는 것입니다.