MongoDB에서 schema를 어떻게 설계하나요?

Question

Accepted Answer

MongoDB schema 설계는 핵심 결정을 중심으로 합니다: **embedding**(연관 데이터를 document 안에 저장) vs **referencing**(연관 데이터를 별도 document/collection에 참조와 함께 저장). SQL의 기본 정규화와 달리 MongoDB 설계는 데이터가 *어떻게 접근되는지*에 최적화합니다.

## embedding — 연관 데이터를 함께 저장

```js
// 연관 데이터를 document 안에 embedding
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded 하위 document
  orders: [                                      // embedded 주문 배열
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → 한 번의 쿼리로 user와 address와 orders를 모두 얻음 (조인 없음)
```

**embedding**은 연관 데이터를 하나의 document에 유지합니다 — 단일 쿼리로 전부 읽음(빠름, 조인 없음). 함께 접근되는 데이터와 "포함" 관계에 좋습니다.

## referencing — 별도 document 연결

```js
// 다른 collection의 document에 대한 참조(id)를 저장
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → userId로 orders 쿼리; 필요할 때 $lookup으로 조인
```

**referencing**은 데이터를 별도로 저장하고 id로 연결합니다(외래 키처럼) — 별도로 쿼리하거나 `$lookup`으로 조인합니다.

## embed vs reference 시점

```text
EMBED 조건:
  ✓ 데이터가 함께 접근됨 (부모를 읽으면 → 자식이 필요함)
  ✓ "포함"/소유 관계 (주소, 주문 항목)
  ✓ embedded 데이터가 제한적임 (무한히 증가하지 않음)
  ✓ 일대소(one-to-few) 관계

REFERENCE 조건:
  ✓ 데이터가 크거나 무한히 증가함 (거대한 document 회피 — 16MB doc 제한!)
  ✓ 데이터가 독립적으로 접근/갱신됨
  ✓ 다대다 또는 많은 일대다
  ✓ 같은 데이터가 여러 document에서 공유/참조됨 (중복 회피)
```

## 접근 패턴에 맞춰 설계 (핵심 원칙)

```text
MongoDB schema 설계는 순수 정규화가 아니라 데이터를 어떻게 쿼리하는지에 의해 좌우됨:
  → 일반적인 쿼리가 효율적이도록 데이터를 구조화 (종종 단일 document 읽기).
  → "함께 접근되는 데이터는 함께 저장되어야 한다."
  → 이는 읽기 효율을 위한 비정규화(일부 중복)를 의미할 수 있음 — MongoDB에서 허용되며
    갱신 복잡성과 트레이드오프됨.
```

## 왜 중요한가

schema 설계는 MongoDB에서 매우 중요합니다 — SQL과 다르고 어쩌면 더 중대한데, MongoDB의 유연한 document 모델이 성능과 유지보수성에 크게 영향을 미치는 선택지를 주기 때문입니다. 따라서 이를 이해하는 것은 효과적인 MongoDB 애플리케이션 구축에 필수적입니다.

핵심 결정 — **embedding vs referencing** — 은 정의적인 MongoDB 설계 선택입니다. **embedding**(연관 데이터를 document 안에 저장)은 연관 데이터의 빠른 단일 쿼리 읽기를 가능하게 하고(조인 없음) 함께 접근되는 데이터와 "포함" 관계에 적합하며, **referencing**(별도 document를 id로 연결)은 크거나 무한한 데이터, 독립적으로 접근되는 데이터, 공유/다수 관계에 적합합니다.

**각각을 언제 쓸지**(제한적이고 함께 접근되며 소유된 데이터는 embed; 크거나 증가하거나 독립적이거나 공유되거나 다수 관계는 reference — 그리고 MongoDB의 16MB document 크기 제한 유념)를 이해하는 것이 핵심 기술입니다.

가장 중요하게, 안내 원칙 — **접근 패턴에 맞춰 설계**(SQL처럼 기본 정규화 대신 *어떻게 쿼리하는지*를 중심으로 데이터를 구조화하여 일반적인 쿼리가 효율적이도록, 종종 단일 document 읽기) — 을 이해하는 것이 좋은 MongoDB schema 설계를 구별 짓습니다.

이는 읽기 효율을 위한 일부 **비정규화**(중복)를 받아들이는 것을 의미할 수 있으며, 갱신 복잡성과의 트레이드오프로 MongoDB에서 허용되고 종종 옳습니다.

schema 설계가 MongoDB 애플리케이션 성능과 유지보수성에 깊이 영향을 미치고(잘못된 embed/reference 선택은 느린 쿼리, 거대한 document, 갱신 복잡성을 초래), 접근 패턴 주도의 embed-vs-reference 접근이 SQL 정규화와 근본적으로 다르므로, MongoDB schema 설계 — embed/reference 결정, 각각의 사용 시점, 접근 패턴에 맞춘 설계 — 를 이해하는 것은 효과적인 MongoDB 애플리케이션 구축에 필수적이고 가치 높은 지식이며, 좋은 document schema를 설계하는 사람과 관계형 설계를 순진하게 이식하는 사람을 가르는 가장 중요하고 독특한 MongoDB 주제 중 하나입니다.