데이터베이스 모델 이해: DDIA Chapter 2

발행: 20시간 전 (2026년 1월 16일 오전 01:01 GMT+9)

10 min read

I’m happy to translate the article for you, but I need the full text of the post (the part you’d like translated). Could you please paste the content here? Once I have it, I’ll provide a Korean translation while keeping the source link, markdown formatting, and any code blocks or URLs exactly as they are.

개요

이 장은 Designing Data‑Intensive Applications에서 다양한 데이터베이스 모델과 애플리케이션 데이터를 구조화하는 전략을 탐구합니다. 이러한 개념을 이해하는 것은 현대 소프트웨어 개발에서 정보에 입각한 아키텍처 결정을 내리는 데 매우 중요합니다.

애플리케이션 관점에서의 데이터 흐름

수집 실제 세계 데이터를.
모델링 데이터 구조와 API를 사용하여.
저장 데이터베이스에, 이는 JSON/XML 문서, 관계형 테이블, 그래프 모델을 사용할 수 있으며 최종적으로 디스크에 바이트 형태로 영속화됩니다.

관계형 vs. NoSQL

우리는 다양한 데이터 모델에 대해 논의할 것이지만, 관계형 모델이 가장 탄력적이며 여전히 널리 사용되고 있습니다. 현대 애플리케이션은 특정 요구 사항을 충족하기 위해 관계형 데이터베이스와 비관계형 데이터베이스를 결합하는 경우가 많습니다(다중 저장소 지속성, polyglot persistence).

NoSQL의 장점

대규모 데이터셋에 대한 높은 확장성 및 쓰기 처리량
더 많은 오픈소스 옵션 제공
관계형 데이터베이스에서는 불가능한 쿼리 지원
덜 제한적인 스키마
특정 사용 사례에서 더 나은 성능, 애플리케이션 데이터 구조와 보다 밀접하게 일치

Impedance Mismatch and ORMs

대부분의 애플리케이션 코드는 객체지향 프로그래밍을 사용하여 데이터를 객체로 표현합니다. 그러나 관계형 데이터베이스는 데이터를 테이블, 행, 열에 저장하므로 임피던스 불일치라고 불리는 어색한 변환 계층을 만들게 됩니다.

객체‑관계 매퍼(ORM)는 수동 SQL 쿼리를 없애는 데 도움을 주지만, 근본적인 문제를 실제로 해결하기보다는 주로 추상화를 제공합니다.

문서 모델 (NoSQL)

문서 모델은 데이터를 고정된 행과 열이 아니라 유연하고 반구조화된 문서(JSON/XML) 형태로 저장합니다. MongoDB가 대표적인 예시입니다.

일대다 예시

한 사용자가 여러 직무를 가진 LinkedIn 프로필을 생각해 보세요. 초기 SQL 데이터베이스는 행당 여러 값을 저장하도록 설계되지 않아 이러한 관계를 처리하기 어려웠습니다. 개발자들은 직무를 별도의 테이블로 만들었지만, 현대 SQL 데이터베이스는 이제 다중값 필드를 지원합니다.

문서 모델은 JSON이 다중 테이블 스키마보다 더 나은 지역성을 제공하기 때문에 이를 우아하게 처리합니다. 여러 테이블에 걸쳐 여러 쿼리를 실행하는 대신, 단일 쿼리로 모든 관련 데이터를 가져올 수 있습니다.

정규화 및 ID 참조

사용자 입력(도시, 조직, 대학 등)을 저장할 때 원시 문자열 대신 ID 참조를 사용합니다(예: org_id = 5 대신 org = "Microsoft"). 이 접근 방식:

다대일 관계를 자연스럽게 모델링합니다(다수 사용자, 하나의 조직)
드롭다운을 통한 깔끔한 데이터 검증을 가능하게 합니다
중복된 이름으로 인한 모호성을 제거합니다
유지보수성을 향상시킵니다(한 번 업데이트하면 전체에 반영)
수천 개 레코드를 일일이 수정하지 않고도 중앙에서 변경할 수 있습니다

정규화 및 스키마 설계에 대한 더 깊은 탐구는 데이터베이스 정규화에 대한 제 자세한 블로그를 참고하세요.

Joins

조인은 관계형 데이터베이스에서 서로 다른 테이블의 필드를 결합합니다. SQL에서는 직관적이지만, 문서 모델은 조인 지원이 약하거나 전혀 없습니다. 데이터베이스 수준의 조인이 없으면 애플리케이션 코드에서 이를 에뮬레이션해야 하며, 이는 성능 오버헤드를 발생시키고 복잡성을 저장소 계층에서 애플리케이션으로 옮기게 됩니다.

SELECT * FROM animals WHERE family = 'Sharks';

역사적 데이터 모델

계층 모델

첫 번째 데이터베이스 모델인 IBM의 IMS는 단일 부모를 가진 트리 구조를 사용했으며, 일대다 관계에 이상적이었습니다.

제한 사항

다대다 관계 지원 없음
비정규화 결정이 어려움

네트워크 모델

계층 모델의 제한을 해결하기 위해 만들어진 네트워크 모델은 다중 부모를 허용하여 다대일 및 다대다 관계를 지원했습니다.

치명적 결함: 레코드가 “액세스 경로”를 통해 프로그래밍 포인터처럼 연결되었습니다. 이러한 액세스 경로는 쿼리와 업데이트를 매우 복잡하게 만들어 다중 관계 지원의 이점을 무효화했습니다.

관계형 모델 성공

데이터를 간단한 테이블(행과 열)로 저장합니다
복잡한 액세스 경로를 제거합니다
다중 관계를 우아하게 지원합니다
외래키에 대한 고민 없이 행을 삽입할 수 있습니다

게임 체인저는 쿼리 옵티마이저의 도입이었으며, 이를 통해 효율적인 쿼리 작성을 간단하게 만들었습니다.

Declarative vs. Imperative Queries

Imperative code는 컴퓨터에게 모든 단계를 알려줍니다: 리스트를 순회하고, 조건을 검사하고, 배열에 푸시하는 등—마치 길 안내를 하나하나 제공하는 것과 같습니다.
Declarative queries(예: SQL)는 무엇을 원하는지 지정하고, 어떻게 얻을지는 지정하지 않습니다. 데이터베이스가 최적의 실행 계획을 결정합니다.

Declarative 언어는 실행 순서가 프로그래머에 의해 강제되지 않기 때문에 자연스럽게 병렬화가 가능하며, 데이터베이스가 작업을 여러 코어에 자동으로 분산시킬 수 있습니다.

Key Takeaways

관계형 데이터베이스는 여전히 지배적이지만 특정 사용 사례에 대해 NoSQL과 함께 잘 작동한다.
문서 모델은 일대다 관계에서 데이터 지역성을 향상시킨다.
ID를 사용한 정규화는 데이터 중복을 방지하고 유지 관리를 용이하게 한다.
선언적 쿼리는 데이터베이스 수준 최적화 및 병렬화를 가능하게 한다.
역사적 모델(계층형, 네트워크)을 이해하면 현대 솔루션을 감상하는 데 도움이 된다.