[데이터 중심 애플리케이션 설계] 02장

February 28, 2026

book-cover

[DDIA] 2장. 데이터 모델과 질의 언어 (Data Models and Query Languages)

목표: “내 데이터는 어떤 형태로 저장/조회해야 덜 고통스러운가?”를 결정하는 기준 잡기
키워드: 관계형 vs 문서형 vs 그래프, 스키마, 조인/중첩, 선언형 질의

0. 이 장이 던지는 질문

애플리케이션은 결국 데이터를 저장하고(write) 조회해서(read) 의미를 만든다.
그런데 데이터 모델 선택이 바뀌면:

코드 구조(도메인 모델, API 응답 형태)
성능(조인 비용, 네트워크 round trip)
변경 용이성(스키마 변경, 마이그레이션)
기능 한계(관계 탐색, 복잡 질의)

까지 전부 달라진다.

결론적으로 “데이터 모델은 단순 저장 포맷이 아니라, 시스템의 사고방식 자체”다.

1. 데이터 모델이 바뀌어온 이유: “가장 쉬운 방식이 계속 바뀐다”

대표 흐름:

계층형/네트워크형 모델: 레코드 간 포인터 기반(구조는 강하지만 변경/질의가 빡셈)
관계형 모델(Relational): 테이블 + 조인으로 범용 질의 가능(표준 SQL)
문서형 모델(Document): JSON 같은 구조로 “애플리케이션 객체 형태”에 가깝게 저장
그래프 모델(Graph): 관계 탐색이 핵심인 데이터(추천, 소셜, 지식 그래프 등)

2. 관계형 모델(Relational Model): 조인이 강력한 “범용 도구”

2.1 장점

조인(Join) 으로 관계를 자연스럽게 표현 가능
데이터 정규화로 중복을 줄이고 일관성을 유지하기 쉬움
범용적인 선언형 질의(SQL) 지원 (최적화는 DB가 담당)

2.2 “임피던스 불일치(impedance mismatch)” 문제

애플리케이션은 보통 객체(중첩 구조)를 쓰는데, DB는 테이블(평면)을 쓴다.

그래서 자주 등장하는 선택지:

객체를 여러 테이블로 쪼개기(정규화)
JSON/별도 컬럼으로 뭉치기(비정규화/중첩)
OR 매퍼(ORM)로 매핑 자동화(편하지만 숨은 비용/쿼리 파악 난이도)

핵심: 관계형이 “나쁘다”가 아니라, 앱의 데이터 형태와 질의 패턴이 정말 테이블/조인에 잘 맞는지를 봐야 한다.

3. 문서형 모델(Document Model): “한 덩어리”로 가져오기 쉬운 저장 방식

문서 DB는 흔히 JSON 문서 단위로 저장한다. (예: 사용자 프로필 + 주소 + 연락처 등)

3.1 장점

애플리케이션 객체 구조(중첩)에 가까워 직렬화/역직렬화가 자연스러움
“한 엔티티를 한 번에 읽는” 패턴에서 유리
(예: 프로필 화면, 게시글 + 댓글 묶음 등)

3.2 단점/한계: 관계가 많아지면 어려워진다

문서가 “자기완결적(self-contained)”일 때 좋다.
하지만 관계(특히 다대다) 가 많아지면:

문서 안에 중첩으로 다 넣기 → 중복/갱신 지옥
참조 ID만 저장 → 조회 시 애플리케이션에서 여러 번 조회(사실상 조인 수작업)

관계가 많은 도메인이라면 “조인을 DB가 해주는 관계형”이 단순해지는 경우가 많다.

3.3 스키마: Schema-on-write vs Schema-on-read

관계형은 보통 쓰기 시점 스키마 강제(schema-on-write)
→ 데이터 품질/일관성은 좋지만 변경 비용이 큼(마이그레이션)
문서형은 보통 읽기 시점 해석(schema-on-read)
→ 유연하지만, 데이터 형태가 섞이면 애플리케이션 로직이 복잡해질 수 있음

실무적으로는 “스키마가 있냐 없냐”가 아니라:

스키마가 어디에 있냐(DB/앱/계약서)
변경을 누가 감당하냐
를 보는 게 핵심.

4. “관계”를 다루는 3가지 방식 비교(2장에서 가장 중요한 포인트)

4.1 1:N (one-to-many)

문서형: 중첩으로 넣기 쉬움 (예: 게시글 안에 댓글 배열)
관계형: 테이블 분리 후 FK로 연결 (댓글 테이블)

➡️ “항상 같이 읽는가?”가 관건
항상 같이 읽으면 중첩이 간단하고, 따로 읽으면 분리가 낫다.

4.2 N:1 (many-to-one)

예: 여러 게시글이 같은 작성자(user)를 참조

문서형에서 작성자 정보를 게시글 문서에 복사해 넣으면 중복/갱신 문제
보통은 user_id만 저장하고 필요할 때 사용자 문서를 조회

➡️ 이 순간부터 애플리케이션은 “조인 비슷한 작업”을 직접 하게 된다.

4.3 N:M (many-to-many)

예: 학생-수업, 사용자-그룹, 상품-태그
이건 문서 중첩으로 해결하려 하면 거의 항상 복잡도가 폭발한다.

➡️ N:M이 핵심이면 관계형(조인 테이블)이 구조적으로 단순한 경우가 많다.
➡️ 문서형을 쓰더라도 결국 “관계 관리용 별도 컬렉션/테이블”이 등장한다.

5. 그래프 모델(Graph Model): “관계 자체가 1등 시민”인 경우

관계가 데이터의 본질인 경우(탐색/추천/경로/연결성):

소셜 그래프(친구의 친구)
추천(이 상품을 본 사람이 같이 본 상품)
지식 그래프(개체-관계-개체)
네트워크/권한/의존성

그래프의 핵심 아이디어:

정점(Vertex/Node): 엔티티
간선(Edge/Relationship): 관계(방향/속성 포함 가능)

그래프 모델의 강점:

“친구의 친구의 동료…” 같은 다단계 관계 탐색이 자연스럽다
관계가 늘어날수록 문서/테이블보다 표현이 명확해질 수 있다

6. 질의 언어(Query Language): 선언형이 왜 중요한가?

6.1 명령형(Imperative) vs 선언형(Declarative)

명령형: “어떻게(How)” 가져올지 절차를 코드로 작성
선언형: “무엇을(What)” 원하는지 조건을 작성 → 실행 계획은 시스템이 최적화

SQL이 대표적인 선언형 질의다.

선언형의 큰 장점:

DB가 인덱스/조인 순서/실행 계획을 바꾸며 최적화할 수 있음
같은 질의를 병렬화/분산화하기 쉬움
구현 세부사항이 덜 노출되어 유지보수에 유리

6.2 MapReduce는 어떤 포지션인가?

MapReduce 스타일은 “처리 로직을 코드로 제공”한다는 점에서 명령형에 가깝고, SQL보다 유연하지만 일반 개발에선 복잡도가 크다.

➡️ 요점: “유연함 vs 단순함”의 트레이드오프가 존재한다.

6.3 그래프 질의 언어

그래프 DB는 그래프 탐색에 최적화된 질의 언어(예: Cypher, SPARQL, Datalog 계열)를 사용한다. 공통 목표는:

“몇 단계 관계를 타고 가서 조건을 만족하는 노드 집합”을 쉽게 표현하는 것

7. 선택 기준 요약: 어떤 모델이 ‘더 낫다’가 아니라 ‘더 맞다’

7.1 관계형이 잘 맞는 경우

데이터 간 관계(N:M 포함)가 핵심
조인 기반 분석/리포팅/복잡 질의가 많음
스키마/정합성을 강하게 유지하고 싶음

7.2 문서형이 잘 맞는 경우

데이터가 “문서(aggregate)” 단위로 자기완결적
조회가 대부분 “문서 1건 + 약간의 필터링” 형태
스키마 변화가 잦고 유연성이 우선

7.3 그래프가 잘 맞는 경우

관계 탐색(다단계)이 제품 가치의 핵심
관계가 다양하고 자주 확장됨
“연결 구조” 자체가 중요한 도메인

8. 내가 적용해볼 체크리스트

내 주요 화면/API는 “한 엔티티를 통째로” 가져오는가, “관계 조합”이 많은가?
핵심 관계가 N:M인가? 그럼 조인/관계 관리 전략이 명확한가?
스키마 변경은 누가 감당하는가? (DB 마이그레이션 vs 앱의 호환 로직)
선언형 질의(예: SQL)로 표현하면 단순해지는 요구사항이 많은가?
“관계 탐색”이 서비스 가치의 중심인가? (그렇다면 그래프 모델 검토)

9. 5줄 요약

데이터 모델은 저장 포맷이 아니라 시스템의 사고방식이다.
관계형은 조인/정규화/선언형 질의로 범용성이 강하다.
문서형은 자기완결적 aggregate를 한 번에 읽는 패턴에 강하다.
관계(N:M)가 핵심이면 문서형은 결국 수작업 조인/중복 관리가 등장하기 쉽다.
관계 탐색이 본질이면 그래프 모델/그래프 질의 언어가 가장 자연스럽다.