[Data] RDB vs 문서 DB vs 그래프 DB — 스키마 변동성과 데이터 지역성 관점에서

📌 데이터베이스 깊이 파기 시리즈 — 1편 들어가며

---

데이터베이스를 선택할 때 "그냥 RDB 쓰면 되지 않나?"라고 생각하기 쉽습니다. 실제로 대부분의 경우 RDB는 훌륭한 선택입니다. 하지만 요구사항에 따라 문서 DB나 그래프 DB가 확실한 이점을 가지는 영역이 있습니다.

 

이번 글에서는 그 중에서도 스키마 변동성과 데이터 지역성 두 가지 관점에 집중해서 세 종류의 DB를 비교해보겠습니다.

 

---

먼저 각 DB를 간단히 짚고 가겠습니다

RDB (관계형 데이터베이스)는 테이블 기반의 정형 데이터 저장소입니다. MySQL, PostgreSQL 등이 대표적이고, 스키마를 사전에 정의하고 데이터 간의 관계를 외래 키로 표현합니다.

 

문서 DB는 JSON이나 BSON 같은 문서 단위로 데이터를 저장합니다. MongoDB, CouchDB 등이 있고, 하나의 문서 안에 관련 데이터를 중첩해서 담을 수 있습니다.

 

그래프 DB는 노드(Node)와 엣지(Edge)로 데이터 간의 관계 자체를 일급 시민으로 다룹니다. Neo4j, Amazon Neptune 등이 대표적입니다.

 

---

1. 스키마 변동성 — 문서 DB와 그래프 DB의 강점

RDB의 스키마는 "미리 확정"해야 합니다

RDB는 테이블을 만들 때 컬럼명과 타입을 정의해야 합니다. 이후에 필드를 추가하거나 변경하려면 ALTER TABLE을 실행해야 하는데, 데이터가 수백만 건 이상이면 이 작업 자체가 상당한 부담이 됩니다.

-- 나중에 phone_number가 필요해졌다면?
ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);

운영 중인 서비스에서 스키마 마이그레이션은 늘 긴장되는 작업입니다. 테이블 락이 걸리거나, 마이그레이션 스크립트가 꼬이거나, 롤백이 어려운 상황이 생길 수 있습니다.

 

문서 DB — 스키마리스의 유연함

문서 DB는 기본적으로 스키마리스(schemaless) 또는 유연한 스키마(flexible schema) 를 지원합니다. 같은 컬렉션 안에 서로 다른 구조의 문서가 공존할 수 있습니다.

// 사용자 A — 기본 정보만 있음
{
  "_id": "user_001",
  "name": "김철수",
  "email": "cs@example.com"
}

// 사용자 B — 나중에 추가된 필드들이 있음
{
  "_id": "user_002",
  "name": "이영희",
  "email": "yh@example.com",
  "phone": "010-1234-5678",
  "preferences": {
    "theme": "dark",
    "language": "ko"
  }
}

새로운 필드가 필요하면 그냥 해당 문서에 넣으면 됩니다. 기존 문서를 건드릴 필요가 없습니다. 이 특성은 초기 스타트업처럼 요구사항이 빠르게 바뀌는 환경에서 특히 유용합니다.

 

그래프 DB — 관계 구조가 자유롭게 진화합니다

그래프 DB 역시 고정된 스키마 없이 노드와 엣지에 자유롭게 속성(property)을 붙일 수 있습니다. 하지만 그래프 DB에서 스키마 변동성이 빛나는 진짜 이유는 관계의 유연성에 있습니다.

 

RDB에서 새로운 관계를 표현하려면 조인 테이블을 추가하거나 외래 키를 변경해야 합니다. 그래프 DB에서는 그냥 새로운 엣지를 연결하면 끝입니다.

// "김철수"가 "이영희"를 멘토링하는 관계를 추가
CREATE (a:User {name: "김철수"})-[:MENTORS {since: "2024-03"}]->(b:User {name: "이영희"})

새로운 관계 유형이 필요할 때마다 테이블 설계를 다시 할 필요가 없습니다. 소셜 네트워크처럼 관계가 계속 복잡해지는 도메인에서 이 장점이 극대화됩니다.

 

정리하면: RDB는 스키마가 안정적인 도메인에 강하고, 문서 DB와 그래프 DB는 스키마가 자주 변하거나 초기에 확정하기 어려운 도메인에서 유리합니다.

 

---

2. 데이터 지역성 — 문서 DB의 결정적 장점

데이터 지역성이란?

데이터 지역성(Data Locality)이란, 연관된 데이터가 물리적으로 얼마나 가까이 저장되어 있는가를 의미합니다. 가까이 있을수록 디스크 I/O가 줄어들고, 한 번의 읽기로 필요한 데이터를 모두 가져올 수 있습니다.

 

RDB의 문제 — 조인은 비쌉니다

RDB에서 "사용자 프로필 페이지"를 렌더링한다고 생각해보겠습니다. 사용자 기본 정보, 주소, 주문 내역, 최근 리뷰를 모두 보여줘야 한다면 어떨까요?

SELECT u.*, a.*, o.*, r.*
FROM users u
JOIN addresses a ON u.id = a.user_id
JOIN orders o ON u.id = o.user_id
JOIN reviews r ON u.id = r.user_id
WHERE u.id = 123;

이 쿼리는 4개의 테이블을 조인합니다. 각 테이블은 디스크의 서로 다른 위치에 저장되어 있으므로, 여러 번의 디스크 접근이 필요합니다. 데이터가 커질수록 이 비용은 점점 더 커집니다.

 

문서 DB — 한 문서에 다 담습니다

 

문서 DB에서는 관련 데이터를 하나의 문서 안에 중첩(embed)해서 저장할 수 있습니다.

{
  "_id": "user_123",
  "name": "김철수",
  "email": "cs@example.com",
  "address": {
    "city": "서울",
    "district": "강남구",
    "detail": "테헤란로 123"
  },
  "recent_orders": [
    { "order_id": "ord_001", "item": "키보드", "amount": 89000 },
    { "order_id": "ord_002", "item": "모니터", "amount": 350000 }
  ],
  "recent_reviews": [
    { "review_id": "rev_001", "content": "배송이 빨라요", "rating": 5 }
  ]
}

이 문서는 디스크 상에서 하나의 연속된 블록으로 저장됩니다. 조회 한 번이면 사용자에 대한 모든 정보를 가져올 수 있습니다. 조인도 없고, 디스크 탐색(seek)도 최소화됩니다. 이것이 바로 데이터 지역성의 이점입니다.

 

그래프 DB는 지역성 측면에서는?

그래프 DB는 노드와 엣지가 분산 저장되는 구조입니다. 관계 탐색(traversal) 성능은 뛰어나지만, "한 엔티티에 관련된 모든 정보를 한 번에 읽는다"는 측면에서의 데이터 지역성은 문서 DB만큼 강하지 않습니다. 그래프 DB의 진짜 강점은 지역성이 아니라 관계 탐색 속도에 있습니다.

 

---

3. 그러면 언제 뭘 써야 할까요?

판단 기준	RDB	문서 DB	그래프 DB
스키마가 안정적이고 명확하다	✅ 최적	⚠️ 가능	⚠️ 가능
스키마가 자주 바뀌거나 유동적이다	❌ 불리	✅ 유리	✅ 유리
한 엔티티의 연관 데이터를 한 번에 읽어야 한다	❌ 조인 필요	✅ 최적	⚠️ 보통
복잡한 트랜잭션이 필요하다	✅ ACID	⚠️ 제한적	⚠️ 제한적
데이터 간 관계가 핵심이다	⚠️ 조인 비용	❌ 비정규화	✅ 최적
다대다 관계 탐색이 빈번하다	❌ 불리	❌ 불리	✅ 최적

 

---

마무리

정리하자면 이렇습니다.

 

스키마 변동성 측면에서 문서 DB와 그래프 DB는 RDB 대비 확실한 장점이 있습니다. 문서 DB는 필드 수준의 유연성을, 그래프 DB는 관계 수준의 유연성을 제공합니다. 반면 RDB는 스키마가 안정적이고 데이터 정합성이 중요한 도메인에서 여전히 최선의 선택입니다.

 

데이터 지역성 측면에서는 문서 DB가 독보적입니다. 연관 데이터를 하나의 문서로 묶어 저장하기 때문에 디스크 I/O가 최소화되고, 조인 없이 한 번의 읽기로 필요한 데이터를 모두 가져올 수 있습니다. 다만 이 장점은 "읽기 패턴이 하나의 엔티티 중심으로 일어나는 경우"에 한합니다. 여러 엔티티를 교차 조회해야 하는 패턴에서는 오히려 비정규화의 단점이 부각될 수 있습니다.

 

물론 세상에 만능 DB는 없습니다. RDB의 트랜잭션 안정성, 문서 DB의 지역성, 그래프 DB의 관계 탐색 성능 — 각각의 강점이 빛나는 상황이 다릅니다. 중요한 것은 "내 도메인에서 가장 빈번한 연산이 무엇인가" 를 먼저 파악하고, 그에 맞는 DB를 선택하는 것입니다.

 

 

→ 다음 편: 2편: SQL vs MapReduce vs 그래프 질의 언어 — 선언형과 명령형 사이에서

[Data] SQL vs MapReduce vs 그래프 질의 언어 — 선언형과 명령형 사이에서

 

 

---

레퍼런스

데이터 중심 애플리케이션 설계 - 마틴 클레프만

 

 

---

읽어주셔서 감사합니다. 잘못된 내용이나 보완할 점이 있다면 댓글로 알려주세요!