MongoDB에서 schema 검증은 어떻게 동작하나요?

Question

Accepted Answer

MongoDB는 기본적으로 유연하지만, 데이터베이스 수준에서 **schema 검증**을 지원합니다 — document가 만족해야 하는 규칙(필수 field, 타입, 값 제약)을 정의합니다. 이는 (애플리케이션 코드뿐 아니라) MongoDB 자체 *안에서* 데이터 무결성을 추가하여 유연성과 일관성의 균형을 맞춥니다.

## 검증 규칙 정의

```js
// collection 생성(또는 수정) 시 JSON Schema validator 추가
db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "email"],            // 필수 field
      properties: {
        name: { bsonType: "string" },
        email: { bsonType: "string", pattern: "^.+@.+$" },   // 타입 + 패턴
        age: { bsonType: "int", minimum: 0, maximum: 120 }   // 범위
      }
    }
  }
});
// → 이를 만족하지 않는 document는 insert/update 시 거부됨
```

MongoDB는 **JSON Schema**를 사용하여 검증 규칙(필수 field, 타입, 패턴, 범위)을 정의하며, document가 삽입되거나 갱신될 때 데이터베이스가 강제합니다.

## 검증 수준과 동작

```js
db.runCommand({
  collMod: "users",
  validator: { $jsonSchema: { ... } },
  validationLevel: "moderate",     // "strict"(전체) 또는 "moderate"(유효한 기존 doc만)
  validationAction: "error"        // "error"(거부) 또는 "warn"(기록하되 허용)
});
```

`validationLevel`은 어떤 document를 검사할지 제어하고, `validationAction`은 위반이 오류(거부)인지 단순 경고인지 제어합니다.

## 왜 데이터베이스에서 검증하나 (앱에서만이 아니라)?

```text
✓ 데이터베이스 수준 보장 — 어떤 앱/코드가 데이터를 쓰든 강제됨
  (여러 서비스, 스크립트, 수동 변경) → 일관된 데이터 무결성
✓ 애플리케이션 검증이 우회되거나 버그가 있어도 안전망
→ SQL 제약과 유사한 논리: DB가 무결성의 최후 방어선.
```

## 유연성과 구조의 균형

```text
MongoDB의 유연성은 가치 있지만, 통제되지 않은 유연성 → 일관되지 않은 데이터.
schema 검증은 필요한 곳에 구조를 추가하게 함:
  → 핵심 field/타입을 강제하면서 다른 곳은 유연하게 유지
  → 유연하게 시작하고 schema가 안정되면 검증 추가
(종종 검증은 앱 계층에서도/대신 수행됨, 예: Mongoose schema.)
```

## 왜 중요한가

MongoDB schema 검증을 이해하는 것은 **MongoDB의 유연성과 데이터 무결성의 균형**에 가치가 있으므로, 신뢰할 수 있는 MongoDB 애플리케이션 구축에 유용한 지식입니다.

MongoDB의 schema 없는 유연성은 주요 이점(변화하고 다양한 데이터에 적합)이지만, **통제되지 않은 유연성은 일관되지 않은 데이터**(누락 field, 잘못된 타입, 유효하지 않은 값)로 이어질 수 있습니다 — 데이터 품질에 대한 실제 우려입니다.

schema 검증은 규칙(JSON Schema를 통한 필수 field, 타입, 패턴, 범위)을 **데이터베이스 수준**에서 강제하게 하여 이를 해결하므로, document가 이를 만족해야 합니다.

**데이터베이스 수준 검증**의 핵심 가치(애플리케이션 수준만이 아니라)는 어떤 애플리케이션, 서비스, 스크립트, 수동 연산이 데이터를 쓰든 강제된다는 것입니다 — 일관된 무결성 보장과 애플리케이션 검증이 우회되거나 버그가 있어도 안전망을 제공합니다(SQL 제약과 동일한 논리: 무결성의 최후 방어선으로서의 데이터베이스).

**검증 수준과 동작**(어떤 document를 검사하고 위반이 거부인지 경고인지 제어)을 이해하면 유연한 채택이 가능합니다.

가장 중요하게, **유연성과 구조의 균형**을 맞추는 방법 — 일관성이 중요한 곳에 검증을 추가하면서 다른 곳은 유연하게 유지하고, 종종 유연하게 시작하여 schema가 안정되면 검증을 추가 — 을 이해하는 것은 핵심 데이터 무결성을 희생하지 않고 유연성의 이점을 얻는 성숙한 MongoDB 사용을 반영합니다.

검증이 종종 앱 계층에서도 수행된다는 것(예: Mongoose schema)을 아는 것도 관련이 있습니다.

유연한 데이터베이스에서도 데이터 무결성이 중요하고, MongoDB의 schema 검증이 유연성을 보존하면서 필요한 곳에 구조를 강제(강한 보장을 위해 데이터베이스 수준에서)하게 하므로, schema 검증 — 그 동작, 데이터베이스 수준 강제의 이점, 유연성과 구조의 균형 — 을 이해하는 것은 데이터 품질을 유지하는 MongoDB 애플리케이션 구축에 가치 있고 실질적으로 관련된 지식이며, 유연한 schema 데이터베이스에서 일관되지 않은 데이터라는 흔한 우려를 해결하는 유용한 능력입니다.