“유행 DB” 말고 “내 데이터”부터: 데이터 형태 기반 DB 선택 가이드

Bro's Insights
1

DB를 고를 때 “요즘 핫한 제품”부터 찾다 보면, 정작 우리 서비스의 데이터와 액세스 패턴에 맞지 않아 고생하는 경우가 많습니다. 이 글에서는 **데이터 형태(Structured/Semi-structured/Unstructured)와 사용 방식(트랜잭션/분석/검색/캐시)**을 기준으로 DB를 고르는 실전 프레임을 정리합니다.

왜 DB 선택은 ‘인기’가 아니라 ‘데이터와 사용 방식’의 문제인가

제가 여러 자료를 보면서 공통으로 느낀 결론은 하나였습니다.
DB는 만능 도구가 아니라, 데이터 모델과 액세스 패턴이 요구하는 트레이드오프를 각자 다른 방식으로 최적화한 결과물이라는 점입니다.

결국 DB 선택은 아래 질문에 답하는 과정입니다.

  • 데이터는 정형(Structured) / 반정형(Semi-structured) / 비정형(Unstructured) 중 무엇에 가까운가?
  • 읽기/쓰기는 어떤가?
    • 단건 조회가 대부분인가, 범위 조회/집계가 핵심인가?
    • 키 기반 조회인가, **검색(텍스트)**인가, 관계 탐색인가?
  • 일관성은 얼마나 필요한가?
    • 강한 트랜잭션(ACID)이 필수인가, 어느 정도의 지연/최종 일관성을 허용하는가?
  • 데이터 볼륨과 성장 속도는 어떤가?

이 질문들을 무시하고 “한 번에 다 되는 DB”를 고르려 하면, 성능/운영/비용 중 어딘가에서 결국 대가를 치르게 됩니다.

데이터 특성 + 접근 패턴 + 일관성 요구로 DB를 매칭하라는 것입니다. 대표적인 매칭은 아래처럼 정리할 수 있습니다.

  • 관계형(Relational, OLTP): 정합한 트랜잭션, 복잡한 조인, 다대다 관계, 무결성이 중요할 때
  • 컬럼형(Columnar, OLAP): 대규모 집계/분석/리포팅(읽기 중심, 스캔/집계 최적화)
  • 키-값(Key-Value): 단순 키 기반 초고속 조회, 세션/토큰/간단한 상태 저장
  • 인메모리(In-memory): 캐시, 랭킹, 실시간 카운터 등 “지연시간”이 핵심일 때
  • 문서형(Document): JSON 중심, 스키마가 자주 바뀌고 엔티티 단위로 읽고 쓰는 패턴이 많을 때
  • 와이드 컬럼(Wide-column): 매우 큰 스케일에서 “정해진 키/파티션 기준”으로 빠르게 읽고 쓸 때
  • 그래프(Graph): 관계 탐색(친구 추천, 경로 탐색)처럼 “연결을 타고 들어가는 질의”가 핵심일 때
  • 시계열(Time-series): 시간 축 이벤트/메트릭/모니터링 데이터(다운샘플링, 보관정책 등)
  • 오브젝트 스토리지(Object Storage): 이미지/영상/첨부파일 같은 대용량 바이너리(내구성/비용/확장)
  • 텍스트 검색(Text Search Engine): 역색인 기반 키워드 검색, 랭킹, 형태소 분석 등

여기서 중요한 뉘앙스는, 한 시스템에 DB 하나로 끝내기보다 폴리글랏 퍼시스턴스(Polyglot Persistence)—용도별로 여러 저장소를 조합하는 선택—이 현실적인 해법일 수 있다는 점입니다.

“데이터 형태 → DB 유형”으로 시작하는 선택 트리는 의사결정 트리에 가깝습니다. 핵심 흐름은 다음과 같습니다.

1) Structured(정형) 데이터라면: OLTP vs OLAP부터

  • 스키마가 안정적이고 테이블/컬럼 중심이면 보통 관계형(DB) 또는 **컬럼형(DB)**로 이어집니다.
  • 즉, “거래(트랜잭션)가 핵심인가?” vs “분석(집계/리포팅)이 핵심인가?”를 먼저 나눕니다.

2) Semi-structured(반정형) 데이터라면: ‘무슨 일을 하느냐’로 세분화

JSON, 이벤트, 유연한 스키마처럼 형태가 변하거나 중첩이 많은 데이터는 다음처럼 분기합니다.

  • 문서형(Document): JSON 문서 단위 CRUD가 중심
  • 키-값/인메모리(KV/In-memory): 초저지연 조회, 세션/캐시/핫데이터
  • 와이드컬럼(Wide-column): 대규모에서 패턴화된 키 기반 읽기/쓰기
  • 그래프(Graph): 관계 탐색/추천/연결 분석
  • 지리공간(Geospatial): 좌표, 반경, 폴리곤 등 공간 질의
  • 불변 로그(Immutable log): append-only 이벤트 스트림(이벤트 소싱/스트리밍의 기반)

여기서 암묵적 가정은 “반정형 데이터는 조인 중심보다는, 특정 접근 패턴(키 기반 조회, 관계 탐색 등)에 최적화된 저장소가 더 자연스럽다”는 것입니다.

3) Unstructured(비정형) 데이터라면: 저장과 검색을 분리

이미지/영상/문서/PDF 같은 비정형 원본은 보통

  • 블롭/오브젝트 스토리지에 저장하고,
  • “내용을 찾는 것”은 텍스트 검색 엔진(역색인)으로 해결하는 형태가 많습니다.

즉, **저장(내구성/용량)**과 **검색(인덱싱/랭킹)**은 역할이 다르다는 메시지가 들어 있습니다.

“이 트리가 정말로 맞을까?”

“요즘 DB들은 기능이 계속 추가되는데, 첨부한 이미지와 같은 분류가 여전히 맞나?”

결론적으로, 소스 2는 **정답표라기보다 여전히 유효한 휴리스틱(경험칙)**에 가깝습니다.

  • 기술은 진화해서 경계가 흐려졌습니다.
    • 관계형 DB가 JSON 타입, 전문 검색, 벡터 검색까지 흡수하기도 합니다.
    • 문서 DB도 트랜잭션을 강화하면서 “예전보다 훨씬 넓은 영역”을 커버합니다.
  • 하지만 트레이드오프는 크게 사라지지 않습니다.
    • 조인/트랜잭션/무결성 vs 수평 확장/유연한 스키마
    • 역색인 기반 검색의 비용과 운영 난이도
    • 대용량 파일 I/O의 특성(스토리지 계층 분리 필요성)

그래서 저는 아래와 같이 이렇게 쓰는 게 가장 건강하다고 봅니다.

  • 1) 시작점: “내 데이터는 어디에 가까운가?”를 빠르게 분류한다.
  • 2) 안전장치: 반례(실패 시나리오)를 미리 적어둔다.
    • 예: 문서형으로 갔는데 조인이 폭증한다
    • 예: DB 내장 검색으로 버티려다 검색 트래픽이 폭발한다
    • 예: 최종 일관성으로 설계했는데 강한 정합성이 필요해진다
  • 3) 최종 결정: 요구사항 + 운영비용 + 팀 역량까지 포함해 결정한다.

구체적 사례: “사용자 프로필 + 검색 + 첨부파일”을 한 번에 설계해보면

가상의 서비스 예로, 흔히 등장하는 요구사항을 DB 유형에 매칭해보겠습니다.

요구사항

  • 사용자 프로필(이름/설정/주소 등)을 저장하고 빠르게 조회하고 싶다.
  • 사용자를 이름/키워드로 검색하고 싶다.
  • 프로필 이미지 같은 파일을 저장해야 한다.
  • 로그인/세션은 초저지연이 필요하다.

매칭(폴리글랏 퍼시스턴스)

  • 사용자 프로필
    • 강한 정합성과 관계(예: 조직/권한/결제)까지 커질 가능성이 있으면 관계형 DB
    • JSON 중심으로 문서 단위 업데이트가 대부분이면 문서형 DB
  • 키워드 검색
    • “LIKE 검색”으로 시작할 수는 있지만, 검색 품질/성능이 중요해지면 텍스트 검색 엔진
  • 프로필 이미지 파일
    • DB에 BLOB로 넣기보다 보통 오브젝트 스토리지
  • 세션/캐시
    • 인메모리/KV

아래는 “DB 선택 로직”을 팀 내 합의를 위해 간단히 코드처럼 적어보는 예시입니다(실제 코드는 아니고 의사결정 템플릿에 가깝습니다).

if data is Unstructured (image/video/pdf):
  store in Object Storage
  if need to search content:
    add Text Search Engine

else if data is Structured:
  if workload is OLTP with transactions/joins:
    choose Relational DB
  else if workload is OLAP (aggregation/reporting):
    choose Columnar DB

else if data is Semi-structured (JSON/events):
  if access is key-based hot reads/writes:
    choose Key-Value / In-memory
  else if main unit is document CRUD:
    choose Document DB
  else if queries traverse relationships:
    choose Graph DB
  else if append-only event stream is core:
    choose Immutable Log

이렇게 적어두면 “왜 이 DB를 선택했는지”가 팀 문서로 남고, 나중에 요구사항이 바뀌었을 때도 어떤 가지로 이동해야 할지 판단이 쉬워집니다.

제가 얻은 인사이트: “하나만 고르는 게 아니라, 핵심 액세스 패턴 하나부터 확정합니다”

대화에서 나온 열린 질문(“우리 시스템의 핵심 액세스 패턴 한 가지를 꼽는다면?”)이 사실 가장 실전적입니다.
저는 DB 결정을 크게 흔드는 요인이 ‘데이터 형태’보다도 가장 자주/가장 비싼 액세스 패턴이 무엇인지라고 생각합니다.

  • 단건 조회(키 기반)가 핵심이면 KV/캐시 계층이 효과가 큽니다.
  • 조인과 트랜잭션이 핵심이면 관계형이 안전합니다.
  • 집계/리포팅이 핵심이면 컬럼형이 체감 성능을 바꿉니다.
  • 검색이 핵심이면 검색 엔진이 사실상 “주 DB급”이 됩니다.
  • 관계 탐색이 핵심이면 그래프는 다른 DB로 대체하기 어렵습니다.

이미지 트리는 그 “첫 출발점”을 빠르게 잡아주고, “용도별로 어떤 DB가 잘하는지”를 깔끔하게 보완해준다고 느꼈습니다.

마무리

DB 선택은 결국 Data 형태와 핵심 Access 패턴을 정직하게 파악하는 것에서 시작합니다. DB 선택의 분류 Tree기준은 :compass:방향을 잡아주고, 용도 매칭은 “왜 이 선택이 합리적인지”를 나름 설명을 해주니 한번 확인해보세요!

#클라우드브로 지식주권 #db선택

800×1000 173 KB

1개의 좋아요