AI 기반 시각화 전문지식 서비스

프로그램개발 · 분야 선택22개 분야

Ver3.0 전체 열람

Ver3.0 🎯 MongoDB 스키마 설계와 컬렉션 최적화

2025.09.30

재능넷

댓글 0 전체 34 페이지

🎯 MongoDB 스키마 설계와 컬렉션 최적화

친구처럼 편하게 배우는 NoSQL 데이터베이스 설계의 모든 것

안녕! 오늘은 MongoDB를 사용하면서 누구나 한 번쯤 고민하게 되는 스키마 설계와 컬렉션 최적화에 대해 이야기해볼까 해. 😊
사실 MongoDB를 처음 접하면 "어? 스키마가 없다고? 그럼 막 넣으면 되는 거 아냐?"라고 생각하기 쉬운데, 실제로는 그렇지 않아.
오히려 자유도가 높은 만큼 더 신중하게 설계해야 나중에 성능 문제나 유지보수 지옥에 빠지지 않을 수 있지.

특히 재능넷 같은 플랫폼에서 다양한 사용자 데이터와 거래 정보를 다룬다면, 처음부터 제대로 된 설계가 정말 중요해.
그래서 오늘은 실무에서 바로 써먹을 수 있는 MongoDB 스키마 설계 원칙부터 컬렉션 최적화 기법까지 차근차근 알아볼 거야. 🚀

📌 이 글에서 다룰 내용

✅ MongoDB의 스키마 설계 철학과 관계형 DB와의 차이점
✅ 임베디드 vs 레퍼런스 패턴 선택 기준
✅ 실전 스키마 설계 패턴과 안티패턴
✅ 인덱스 전략과 쿼리 최적화
✅ 컬렉션 샤딩과 대용량 데이터 처리
✅ 성능 모니터링과 튜닝 팁

🎨 MongoDB 스키마 설계의 철학

먼저 MongoDB의 스키마 설계 철학부터 이해해보자.
관계형 데이터베이스(RDBMS)를 사용해봤다면, 정규화(Normalization)라는 개념에 익숙할 거야.
데이터 중복을 최소화하고, 테이블을 잘게 쪼개서 JOIN으로 연결하는 방식 말이야.

하지만 MongoDB는 애플리케이션의 데이터 접근 패턴을 중심으로 설계해야 해.
"이 데이터를 어떻게 조회할 것인가?"가 가장 중요한 질문이지.
왜냐하면 MongoDB는 JOIN 연산이 제한적이고(lookup은 있지만 성능이 좋지 않아), 읽기 성능을 최우선으로 고려하기 때문이야.

💡 핵심 원칙

1. 함께 조회되는 데이터는 함께 저장하라
관계형 DB처럼 나누지 말고, 자주 같이 읽히는 데이터는 한 문서에 넣어.

2. 애플리케이션의 읽기/쓰기 비율을 고려하라
읽기가 많으면 비정규화를, 쓰기가 많으면 정규화를 고려해.

3. 문서 크기와 성장 패턴을 예측하라
MongoDB 문서는 최대 16MB 제한이 있어. 무한정 커질 수 있는 배열은 주의!

🔄 임베디드 vs 레퍼런스: 영원한 고민

MongoDB 스키마 설계에서 가장 많이 고민하게 되는 부분이 바로 이거야.
"관련 데이터를 문서 안에 넣을까(임베디드), 아니면 별도 컬렉션으로 분리하고 참조할까(레퍼런스)?" 🤔

정답은... 상황에 따라 다르다는 거야! (이게 제일 답답하지? ㅎㅎ)
하지만 명확한 선택 기준이 있으니까 걱정하지 마.

📦 임베디드 패턴 (Embedded Documents)

임베디드 패턴은 관련 데이터를 하나의 문서 안에 중첩시키는 방식이야.
마치 JSON 객체 안에 또 다른 객체나 배열을 넣는 것처럼 말이야.

{
  "_id": ObjectId("507f1f77bcf86cd799439011"),
  "name": "김개발",
  "email": "dev@example.com",
  "address": {
    "street": "테헤란로 123",
    "city": "서울",
    "zipcode": "06234"
  },
  "orders": [
    {
      "order_id": "ORD001",
      "product": "MongoDB 완벽가이드",
      "amount": 35000,
      "date": ISODate("2024-01-15")
    },
    {
      "order_id": "ORD002",
      "product": "Node.js 실전 프로젝트",
      "amount": 42000,
      "date": ISODate("2024-01-20")
    }
  ]
}

✅ 임베디드 패턴을 사용하면 좋은 경우

1. 일대일(1:1) 관계
사용자와 주소처럼 항상 함께 조회되는 데이터

2. 일대다(1:N) 관계 중 "다"가 적은 경우
블로그 포스트와 댓글(댓글이 수십 개 이하일 때)

3. 자식 데이터가 부모 없이 독립적으로 조회되지 않는 경우
주문 항목은 주문 없이 조회할 일이 거의 없지

4. 원자적 업데이트가 필요한 경우
한 번의 쓰기 작업으로 모든 관련 데이터를 업데이트해야 할 때

임베디드 패턴의 가장 큰 장점은 읽기 성능이야.
한 번의 쿼리로 모든 관련 데이터를 가져올 수 있으니까 엄청 빠르지! ⚡
재능넷에서 사용자 프로필과 기본 정보를 보여줄 때, 한 번에 다 가져올 수 있다면 사용자 경험이 훨씬 좋아질 거야.

⚠️ 임베디드 패턴의 주의사항

문서 크기 제한: MongoDB는 문서당 최대 16MB까지만 저장 가능해.
배열이 무한정 커질 수 있다면 임베디드는 위험해!

중복 데이터 관리: 같은 데이터가 여러 문서에 임베디드되면,
업데이트할 때 모든 문서를 찾아서 수정해야 해.

쓰기 성능: 큰 문서를 자주 업데이트하면 성능이 떨어질 수 있어.

🔗 레퍼런스 패턴 (References)

레퍼런스 패턴은 관계형 DB의 외래키(Foreign Key)처럼,
다른 문서의 ID를 참조하는 방식이야.

// users 컬렉션
{
  "_id": ObjectId("507f1f77bcf86cd799439011"),
  "name": "김개발",
  "email": "dev@example.com"
}

// orders 컬렉션
{
  "_id": ObjectId("507f191e810c19729de860ea"),
  "user_id": ObjectId("507f1f77bcf86cd799439011"),
  "product": "MongoDB 완벽가이드",
  "amount": 35000,
  "date": ISODate("2024-01-15")
}

// 조회할 때는 $lookup 사용
db.users.aggregate([
  {
    $lookup: {
      from: "orders",
      localField: "_id",
      foreignField: "user_id",
      as: "user_orders"
    }
  }
])

✅ 레퍼런스 패턴을 사용하면 좋은 경우

1. 다대다(N:M) 관계
학생과 수업, 상품과 카테고리처럼 양방향 관계

2. 일대다(1:N) 관계 중 "다"가 매우 많은 경우
사용자와 로그 데이터(수천~수만 건)

3. 자식 데이터가 독립적으로 자주 조회되는 경우
상품 정보는 주문과 별개로도 자주 조회되지

4. 데이터 중복을 최소화해야 하는 경우
같은 상품 정보가 수천 개 주문에 중복되면 비효율적이야

레퍼런스 패턴의 장점은 데이터 일관성과 유연성이야.
상품 정보가 바뀌면 한 곳만 수정하면 되고, 문서 크기 제한도 걱정 없지.
하지만 조회할 때 $lookup을 사용해야 해서 성능은 임베디드보다 떨어져. 🐢

🎯 실전 팁: 하이브리드 접근법

실무에서는 임베디드와 레퍼런스를 함께 사용하는 경우가 많아!

예를 들어, 주문 문서에 상품 ID는 레퍼런스로 저장하되,
자주 조회되는 상품명과 가격은 스냅샷으로 임베디드해두는 거야.

이렇게 하면 대부분의 조회는 빠르게 처리하면서,
상세 정보가 필요할 때만 상품 컬렉션을 참조할 수 있어.

🎯 실전 스키마 설계 패턴

이제 실무에서 자주 사용되는 스키마 설계 패턴들을 알아보자.
MongoDB 공식 문서에서도 권장하는 검증된 패턴들이야! 📚

🌳 계층 구조 패턴 (Tree Pattern)

카테고리, 조직도, 댓글 스레드처럼 계층 구조를 표현할 때 사용해.
여러 방법이 있는데, 상황에 맞게 선택하면 돼.

1️⃣ Parent Reference (부모 참조)

각 노드가 부모의 ID만 저장하는 방식. 가장 단순하고 직관적이야.

{
  "_id": "MongoDB",
  "parent": "Databases"
}
{
  "_id": "Databases",
  "parent": "Programming"
}
{
  "_id": "Programming",
  "parent": null
}

부모를 찾기는 쉽지만, 자식들을 찾으려면 쿼리가 필요해.
트리를 위에서 아래로 탐색하는 경우가 많다면 다른 패턴을 고려해봐.

2️⃣ Child Reference (자식 참조)

부모가 자식들의 ID 배열을 저장하는 방식.

{
  "_id": "Programming",
  "children": ["Databases", "Web", "Mobile"]
}
{
  "_id": "Databases",
  "children": ["MongoDB", "PostgreSQL", "MySQL"]
}

자식을 찾기는 쉽지만, 자식이 너무 많으면 배열이 커져서 문제가 될 수 있어.

3️⃣ Array of Ancestors (조상 배열)

루트부터 현재 노드까지의 전체 경로를 배열로 저장하는 방식.
특정 노드의 모든 하위 노드를 찾을 때 유용해!

{
  "_id": "MongoDB",
  "ancestors": ["Programming", "Databases"],
  "parent": "Databases"
}

// 특정 카테고리의 모든 하위 항목 찾기
db.categories.find({ ancestors: "Programming" })

💡 재능넷 적용 예시

재능넷의 카테고리 구조를 생각해보자.
"IT/프로그래밍 > 웹개발 > 프론트엔드 > React"

Array of Ancestors 패턴을 사용하면,
"IT/프로그래밍" 카테고리의 모든 하위 재능을 한 번에 조회할 수 있어!
사용자가 카테고리를 탐색할 때 성능이 훨씬 좋아지겠지? 😊

📊 버킷 패턴 (Bucket Pattern)

시계열 데이터나 로그처럼 대량의 데이터를 효율적으로 저장할 때 사용하는 패턴이야.
데이터를 일정 단위로 묶어서(버킷) 저장하는 거지.

// 비효율적인 방법: 각 측정값마다 문서 생성
{
  "sensor_id": "sensor1",
  "timestamp": ISODate("2024-01-15T10:00:00Z"),
  "temperature": 22.5
}
{
  "sensor_id": "sensor1",
  "timestamp": ISODate("2024-01-15T10:01:00Z"),
  "temperature": 22.7
}
// ... 수백만 개의 문서

// 버킷 패턴: 1시간 단위로 묶기
{
  "sensor_id": "sensor1",
  "start_time": ISODate("2024-01-15T10:00:00Z"),
  "end_time": ISODate("2024-01-15T11:00:00Z"),
  "measurements": [
    { "timestamp": ISODate("2024-01-15T10:00:00Z"), "temp": 22.5 },
    { "timestamp": ISODate("2024-01-15T10:01:00Z"), "temp": 22.7 },
    { "timestamp": ISODate("2024-01-15T10:02:00Z"), "temp": 22.6 },
    // ... 60개의 측정값
  ],
  "count": 60,
  "avg_temp": 22.8
}

✅ 버킷 패턴의 장점

문서 수 감소: 수백만 개 → 수만 개로 줄어들어
인덱스 크기가 작아지고 쿼리 성능이 향상돼.

집계 데이터 사전 계산: 평균, 합계 등을 미리 계산해두면
분석 쿼리가 훨씬 빨라져.

메모리 효율: 관련 데이터가 한 문서에 있어서
디스크 I/O가 줄어들어.

재능넷에서 사용자 활동 로그나 거래 통계를 저장할 때 버킷 패턴을 사용하면,
대시보드 성능이 엄청나게 개선될 거야! 📈

🔄 확장 패턴 (Extended Reference Pattern)

레퍼런스 패턴의 단점(조회 시 조인 필요)을 보완하는 패턴이야.
자주 사용되는 필드만 복사해서 저장하는 거지.

// orders 컬렉션
{
  "_id": ObjectId("..."),
  "user": {
    "id": ObjectId("507f1f77bcf86cd799439011"),
    "name": "김개발",  // 자주 표시되는 정보만 복사
    "email": "dev@example.com"
    // 전화번호, 주소 등 상세 정보는 제외
  },
  "product": {
    "id": ObjectId("..."),
    "name": "MongoDB 완벽가이드",
    "price": 35000,
    "thumbnail": "https://..."
    // 상세 설명, 재고 등은 제외
  },
  "order_date": ISODate("2024-01-15"),
  "status": "delivered"
}

이렇게 하면 주문 목록을 보여줄 때 추가 조회 없이 바로 표시할 수 있어.
사용자 이름이나 상품명이 바뀌는 경우는 드물고, 바뀌더라도 주문 내역은 당시의 정보를 보여주는 게 맞으니까 문제없지! 👍

🎯 패턴 선택 가이드

계층 구조: 카테고리, 조직도, 댓글 → Tree Pattern
시계열 데이터: 로그, 센서 데이터, 통계 → Bucket Pattern
자주 조회되는 관계: 주문-사용자, 게시글-작성자 → Extended Reference
다형성 데이터: 여러 타입의 제품 → Polymorphic Pattern
버전 관리: 문서 이력 추적 → Document Versioning Pattern

⚠️ 피해야 할 안티패턴

좋은 패턴만큼 중요한 게 나쁜 패턴을 피하는 것이야.
실무에서 자주 보는 안티패턴들을 알아보자. 🚫

❌ 안티패턴 1: 무한정 커지는 배열

{ "user_id": 1, "activities": [ ... 수천 개 ... ] }

문서 크기 16MB 제한에 걸리고, 배열 끝에 추가할 때마다 전체 문서를 다시 써야 해.
해결: 버킷 패턴이나 별도 컬렉션으로 분리!

❌ 안티패턴 2: 대량의 컬렉션 생성

사용자마다 별도 컬렉션을 만드는 경우 (user_1_orders, user_2_orders...)

네임스페이스 제한에 걸리고, 관리가 불가능해져.
해결: 하나의 컬렉션에 user_id 필드로 구분!

❌ 안티패턴 3: 불필요한 인덱스 남발

"혹시 몰라서" 모든 필드에 인덱스를 거는 경우.

쓰기 성능이 크게 떨어지고, 디스크 공간도 낭비돼.
해결: 실제 쿼리 패턴을 분석해서 필요한 인덱스만 생성!

❌ 안티패턴 4: 관계형 DB 사고방식 그대로 적용

모든 것을 정규화하고 JOIN으로 연결하려는 시도.

MongoDB의 강점을 전혀 살리지 못해.
해결: 애플리케이션의 읽기 패턴을 중심으로 재설계!

❌ 안티패턴 5: ObjectId를 문자열로 저장

{ "user_id": "507f1f77bcf86cd799439011" } (문자열)

인덱스 효율이 떨어지고, 저장 공간도 더 차지해.
해결: ObjectId 타입 그대로 사용!

🚀 인덱스 전략과 쿼리 최적화

스키마 설계가 끝났다면, 이제 인덱스 전략을 세울 차례야.
아무리 잘 설계된 스키마라도 인덱스가 없으면 성능이 형편없거든! 😅

📑 인덱스 기본 원칙

MongoDB의 인덱스는 B-Tree 구조를 사용해.
관계형 DB와 비슷하지만, 몇 가지 MongoDB만의 특징이 있어.

🎯 인덱스 생성 기본 문법

// 단일 필드 인덱스
db.users.createIndex({ email: 1 })  // 오름차순
db.users.createIndex({ created_at: -1 })  // 내림차순

// 복합 인덱스 (Compound Index)
db.orders.createIndex({ user_id: 1, order_date: -1 })

// 고유 인덱스 (Unique Index)
db.users.createIndex({ email: 1 }, { unique: true })

// 부분 인덱스 (Partial Index) - 조건에 맞는 문서만 인덱싱
db.orders.createIndex(
  { status: 1 },
  { partialFilterExpression: { amount: { $gt: 10000 } } }
)

// TTL 인덱스 - 일정 시간 후 자동 삭제
db.sessions.createIndex(
  { created_at: 1 },
  { expireAfterSeconds: 3600 }  // 1시간 후 삭제
)

✅ 인덱스 생성 우선순위

1순위: 고유성 제약이 필요한 필드
이메일, 사용자명 등 → Unique Index

2순위: WHERE 절에 자주 사용되는 필드
user_id, status, category 등

3순위: 정렬(ORDER BY)에 사용되는 필드
created_at, updated_at 등

4순위: 범위 쿼리에 사용되는 필드
price, date 등

🎨 복합 인덱스 설계의 예술

복합 인덱스는 필드 순서가 정말 중요해!
ESR 규칙을 기억하면 쉬워. 📝

💡 ESR 규칙 (Equality, Sort, Range)

E (Equality): 동등 비교 필드를 먼저
{ status: "active" }

S (Sort): 정렬 필드를 두 번째
sort({ created_at: -1 })

R (Range): 범위 조건 필드를 마지막
{ price: { $gte: 10000, $lte: 50000 } }

최적 인덱스:

db.products.createIndex({ status: 1, created_at: -1, price: 1 })

// 쿼리 예시
db.products.find({
  status: "active",
  price: { $gte: 10000, $lte: 50000 }
}).sort({ created_at: -1 })

// 잘못된 인덱스 (비효율적)
db.products.createIndex({ price: 1, status: 1, created_at: -1 })
// Range 필드가 앞에 오면 뒤의 필드들을 제대로 활용 못함!

// 올바른 인덱스
db.products.createIndex({ status: 1, created_at: -1, price: 1 })

🔍 쿼리 성능 분석

인덱스를 만들었다면, 실제로 잘 사용되는지 확인해야 해.
explain() 메서드가 최고의 친구야! 🔎

// 실행 계획 확인
db.orders.find({ user_id: ObjectId("...") })
  .sort({ order_date: -1 })
  .explain("executionStats")

// 주요 확인 사항
{
  "executionStats": {
    "executionTimeMillis": 5,  // 실행 시간 (낮을수록 좋음)
    "totalDocsExamined": 10,   // 검사한 문서 수
    "totalKeysExamined": 10,   // 검사한 인덱스 키 수
    "nReturned": 10,           // 반환된 문서 수
    "executionStages": {
      "stage": "FETCH",
      "inputStage": {
        "stage": "IXSCAN",     // 인덱스 스캔 (좋음!)
        "indexName": "user_id_1_order_date_-1"
      }
    }
  }
}

🎯 성능 지표 해석

COLLSCAN: 컬렉션 전체 스캔 → 나쁨! 인덱스 필요
IXSCAN: 인덱스 스캔 → 좋음!
FETCH: 인덱스로 찾은 후 문서 가져오기 → 정상

이상적인 비율:
totalKeysExamined ≈ nReturned (인덱스 효율 100%)
totalDocsExamined ≈ nReturned (불필요한 문서 검사 없음)

🎪 커버링 인덱스 (Covered Query)

인덱스만으로 쿼리를 완전히 처리할 수 있다면, 문서를 읽을 필요가 없어져서 엄청 빨라! ⚡
이걸 커버링 인덱스라고 해.

// 인덱스 생성
db.users.createIndex({ email: 1, name: 1, status: 1 })

// 커버링 쿼리 (인덱스만으로 처리 가능)
db.users.find(
  { status: "active" },
  { email: 1, name: 1, status: 1, _id: 0 }  // _id: 0 중요!
)

// explain 결과에서 확인
{
  "executionStats": {
    "totalDocsExamined": 0,  // 문서를 하나도 안 읽음!
    "executionStages": {
      "stage": "PROJECTION_COVERED",  // 커버링!
      "inputStage": {
        "stage": "IXSCAN"
      }
    }
  }
}

주의할 점은 _id 필드를 제외해야 한다는 거야.
_id는 기본적으로 포함되는데, 인덱스에 없으면 문서를 읽어야 하거든!

⚙️ 컬렉션 샤딩과 대용량 데이터 처리

데이터가 정말 많아지면 (수억 건 이상), 단일 서버로는 한계가 와.
이때 필요한 게 샤딩(Sharding)이야! 🌐

🗂️ 샤딩이란?

샤딩은 데이터를 여러 서버(샤드)에 수평 분할하는 기술이야.
각 샤드는 전체 데이터의 일부만 저장하고, MongoDB가 자동으로 적절한 샤드로 쿼리를 라우팅해줘.

🔑 샤드 키 선택

샤딩에서 가장 중요한 결정이 샤드 키(Shard Key) 선택이야.
샤드 키는 데이터를 어떻게 분산시킬지 결정하는 기준이거든.

좋은 샤드 키의 조건

1. 높은 카디널리티 (Cardinality): 고유한 값이 많아야 해
❌ 나쁨: status (active/inactive 두 가지뿐)
✅ 좋음: user_id (수백만 개의 고유값)

2. 균등한 분산: 데이터가 특정 샤드에 몰리지 않아야 해
❌ 나쁨: created_at (최근 데이터가 한 샤드에 집중)
✅ 좋음: hashed(user_id) (해시로 균등 분산)

3. 쿼리 패턴과 일치: 자주 사용하는 필터 조건이어야 해
✅ 좋음: 대부분의 쿼리가 user_id로 필터링한다면 user_id를 샤드 키로

// 샤딩 활성화
sh.enableSharding("mydb")

// 해시 샤드 키 (균등 분산에 유리)
sh.shardCollection("mydb.users", { user_id: "hashed" })

// 범위 샤드 키 (범위 쿼리에 유리)
sh.shardCollection("mydb.orders", { user_id: 1, order_date: 1 })

// 복합 샤드 키
sh.shardCollection("mydb.logs", { 
  app_id: 1, 
  timestamp: 1 
})

⚠️ 샤드 키 선택 시 주의사항

한 번 정하면 변경 불가! (MongoDB 5.0 이전)
MongoDB 5.0부터는 resharding이 가능하지만, 엄청난 비용이 들어.

단조 증가하는 키는 피해:
ObjectId, 타임스탬프 같은 값은 최신 데이터가 한 샤드에 몰려.
해시 샤드 키를 고려해봐!

쿼리에 샤드 키 포함:
샤드 키가 없는 쿼리는 모든 샤드를 뒤져야 해서 느려.

📊 청크와 밸런싱

MongoDB는 데이터를 청크(Chunk)라는 단위로 나눠서 관리해.
기본적으로 청크 크기는 64MB이고, 청크가 너무 커지면 자동으로 분할돼.

그리고 밸런서(Balancer)가 백그라운드에서 청크를 샤드 간에 이동시켜서
데이터가 균등하게 분산되도록 관리해줘. 완전 자동이야! 🤖

💡 실전 팁: 밸런싱 윈도우 설정

밸런싱은 I/O를 많이 사용해서 서비스에 영향을 줄 수 있어.
트래픽이 적은 시간대에만 밸런싱하도록 설정하는 게 좋아!

sh.setBalancerState(true)
db.settings.update(
{ _id: "balancer" },

{ $set: { activeWindow: { start: "01:00", stop: "05:00" } } }

)

📈 성능 모니터링과 튜닝

스키마 설계와 인덱스 최적화가 끝났다면, 이제 지속적인 모니터링이 필요해.
시간이 지나면서 데이터 패턴이 바뀌고, 새로운 병목이 생기거든! 👀

🔍 주요 모니터링 지표

1️⃣ 쿼리 성능

db.currentOp() - 현재 실행 중인 쿼리 확인
db.system.profile.find() - 느린 쿼리 로그 분석

느린 쿼리(100ms 이상)를 찾아서 인덱스 추가나 쿼리 개선을 해야 해.

// 프로파일링 활성화 (레벨 1: 100ms 이상 쿼리만 기록)
db.setProfilingLevel(1, { slowms: 100 })

// 느린 쿼리 확인
db.system.profile.find({
  millis: { $gt: 100 }
}).sort({ ts: -1 }).limit(10).pretty()

// 특정 컬렉션의 느린 쿼리
db.system.profile.find({
  ns: "mydb.users",
  millis: { $gt: 100 }
})

2️⃣ 인덱스 사용률

만들어둔 인덱스가 실제로 사용되는지 확인해야 해.
사용되지 않는 인덱스는 쓰기 성능만 떨어뜨리니까 삭제하는 게 좋아!

// 인덱스 사용 통계
db.users.aggregate([
  { $indexStats: {} }
])

// 결과 예시
{
  "name": "email_1",
  "key": { "email": 1 },
  "host": "server1:27017",
  "accesses": {
    "ops": 15234,      // 사용 횟수
    "since": ISODate("2024-01-01T00:00:00Z")
  }
}

// 사용되지 않는 인덱스 찾기
db.users.aggregate([
  { $indexStats: {} },
  { $match: { "accesses.ops": 0 } }
])

3️⃣ 메모리 사용량

MongoDB는 가능한 한 많은 데이터를 메모리에 캐싱해.
Working Set(자주 접근하는 데이터)이 메모리에 들어가야 성능이 좋아!

// 서버 상태 확인
db.serverStatus()

// 주요 메모리 지표
{
  "mem": {
    "resident": 2048,    // 실제 사용 중인 메모리 (MB)
    "virtual": 4096,     // 가상 메모리
    "mapped": 3072       // 매핑된 메모리
  },
  "wiredTiger": {
    "cache": {
      "bytes currently in the cache": 1073741824,  // 1GB
      "maximum bytes configured": 2147483648,      // 2GB
      "pages evicted": 1234  // 캐시에서 제거된 페이지 (낮을수록 좋음)
    }
  }
}

pages evicted 값이 계속 증가한다면 메모리가 부족하다는 신호야.
캐시 크기를 늘리거나, 서버를 증설해야 해! 💪

4️⃣ 연결 수

동시 연결 수가 너무 많으면 성능이 떨어져.
커넥션 풀링을 제대로 설정했는지 확인해봐.

// 현재 연결 수 확인
db.serverStatus().connections

{
  "current": 52,      // 현재 연결 수
  "available": 838808, // 사용 가능한 연결 수
  "totalCreated": 1234 // 생성된 총 연결 수
}

// 연결별 상태 확인
db.currentOp(true)

🛠️ 실전 튜닝 팁

✅ 읽기 성능 개선

1. 적절한 인덱스 생성
자주 사용하는 쿼리 패턴을 분석해서 복합 인덱스 생성

2. 커버링 인덱스 활용
필요한 필드만 projection하고, _id 제외

3. Read Preference 설정
읽기 전용 쿼리는 Secondary에서 읽도록 설정

4. 적절한 배치 크기
cursor.batchSize()로 한 번에 가져올 문서 수 조절

✅ 쓰기 성능 개선

1. 불필요한 인덱스 제거
인덱스가 많을수록 쓰기가 느려져

2. Write Concern 조정
중요하지 않은 로그는 w:0 또는 w:1로 설정

3. Bulk Write 사용
여러 문서를 한 번에 쓰면 훨씬 빨라

4. 문서 크기 최소화
불필요한 필드 제거, 짧은 필드명 사용

// Bulk Write 예시
const bulk = db.users.initializeUnorderedBulkOp();

for (let i = 0; i < 10000; i++) {
  bulk.insert({
    name: `User ${i}`,
    email: `user${i}@example.com`,
    created_at: new Date()
  });
}

bulk.execute();  // 한 번에 실행!

// Write Concern 설정
db.logs.insertOne(
  { message: "User logged in", timestamp: new Date() },
  { writeConcern: { w: 0 } }  // 확인 안 기다림 (빠름!)
)

📊 모니터링 도구

MongoDB를 제대로 모니터링하려면 좋은 도구가 필요해.
무료부터 유료까지 다양한 옵션이 있어! 🛠️

🔧 추천 모니터링 도구

1. MongoDB Atlas (공식, 클라우드)
MongoDB 공식 클라우드 서비스. 모니터링, 백업, 알림 모두 포함!
무료 티어도 있어서 테스트하기 좋아.

2. MongoDB Compass (공식, GUI)
쿼리 성능 분석, 인덱스 관리, 스키마 시각화 등
개발할 때 정말 유용해!

3. Percona Monitoring and Management (PMM)
오픈소스 모니터링 도구. Grafana 기반으로 예쁜 대시보드 제공

4. mongostat / mongotop (CLI)
간단한 실시간 모니터링에 유용
mongostat --host localhost:27017
mongotop --host localhost:27017

🎓 실전 사례: 재능넷 스키마 설계

이론은 충분히 배웠으니, 이제 실제 사례를 보자!
재능넷 같은 재능 공유 플랫폼의 스키마를 어떻게 설계할지 생각해볼게. 🎨

📋 요구사항 분석

핵심 엔티티

• 사용자 (Users)
• 재능 (Talents)
• 카테고리 (Categories)
• 주문/거래 (Orders)
• 리뷰 (Reviews)
• 메시지 (Messages)

주요 쿼리 패턴

• 카테고리별 재능 목록 조회 (읽기 많음)
• 사용자의 재능 목록 조회
• 주문 내역 조회 (사용자별, 판매자별)
• 재능 상세 + 리뷰 조회 (함께 조회)
• 실시간 메시지 (쓰기 많음)

🏗️ 스키마 설계

// 1. Users 컬렉션
{
  "_id": ObjectId("..."),
  "email": "dev@example.com",
  "name": "김개발",
  "profile": {
    "bio": "풀스택 개발자입니다",
    "avatar": "https://...",
    "skills": ["JavaScript", "MongoDB", "React"]
  },
  "stats": {
    "total_sales": 1500000,
    "total_orders": 42,
    "rating": 4.8,
    "review_count": 38
  },
  "created_at": ISODate("2023-01-15"),
  "updated_at": ISODate("2024-01-20")
}

// 인덱스
db.users.createIndex({ email: 1 }, { unique: true })
db.users.createIndex({ "stats.rating": -1 })  // 인기 판매자 조회

사용자 통계(stats)는 임베디드로 저장했어.
프로필 조회할 때 항상 함께 보여주니까 한 번에 가져오는 게 효율적이지!

// 2. Talents 컬렉션
{
  "_id": ObjectId("..."),
  "seller_id": ObjectId("..."),
  "seller_name": "김개발",  // 스냅샷 (Extended Reference)
  "seller_avatar": "https://...",
  "title": "MongoDB 스키마 설계 컨설팅",
  "description": "...",
  "category": {
    "id": ObjectId("..."),
    "name": "IT/프로그래밍",
    "path": ["IT/프로그래밍", "데이터베이스", "MongoDB"]  // 계층 구조
  },
  "price": 50000,
  "delivery_days": 7,
  "tags": ["MongoDB", "스키마설계", "DB최적화"],
  "stats": {
    "views": 1234,
    "orders": 42,
    "rating": 4.8,
    "review_count": 38
  },
  "status": "active",  // active, paused, deleted
  "created_at": ISODate("2023-06-01"),
  "updated_at": ISODate("2024-01-15")
}

// 인덱스
db.talents.createIndex({ seller_id: 1, status: 1 })
db.talents.createIndex({ "category.id": 1, status: 1, "stats.rating": -1 })
db.talents.createIndex({ status: 1, created_at: -1 })  // 최신순
db.talents.createIndex({ tags: 1 })  // 태그 검색
db.talents.createIndex({ 
  title: "text", 
  description: "text", 
  tags: "text" 
})  // 전문 검색

재능 문서에 판매자 이름과 아바타를 스냅샷으로 저장했어.
목록 조회할 때 판매자 정보를 별도로 조회하지 않아도 되니까 빠르지!
카테고리도 경로를 저장해서 "IT/프로그래밍" 하위 모든 재능을 쉽게 찾을 수 있어.

// 3. Orders 컬렉션
{
  "_id": ObjectId("..."),
  "order_number": "ORD-2024-001234",
  "buyer": {
    "id": ObjectId("..."),
    "name": "이구매",
    "email": "buyer@example.com"
  },
  "seller": {
    "id": ObjectId("..."),
    "name": "김개발",
    "email": "seller@example.com"
  },
  "talent": {
    "id": ObjectId("..."),
    "title": "MongoDB 스키마 설계 컨설팅",
    "price": 50000,
    "delivery_days": 7
  },
  "amount": 50000,
  "status": "completed",  // pending, in_progress, completed, cancelled
  "payment": {
    "method": "card",
    "paid_at": ISODate("2024-01-15T10:30:00Z"),
    "transaction_id": "TXN123456"
  },
  "delivery": {
    "started_at": ISODate("2024-01-15T11:00:00Z"),
    "completed_at": ISODate("2024-01-20T15:30:00Z"),
    "files": [
      { "name": "schema_design.pdf", "url": "https://..." }
    ]
  },
  "created_at": ISODate("2024-01-15T10:00:00Z"),
  "updated_at": ISODate("2024-01-20T15:30:00Z")
}

// 인덱스
db.orders.createIndex({ "buyer.id": 1, created_at: -1 })
db.orders.createIndex({ "seller.id": 1, created_at: -1 })
db.orders.createIndex({ status: 1, created_at: -1 })
db.orders.createIndex({ order_number: 1 }, { unique: true })

주문 문서는 스냅샷 패턴을 적극 활용했어.
주문 당시의 재능 정보(가격, 제목 등)를 저장해서,
나중에 재능 정보가 바뀌어도 주문 내역은 그대로 유지돼. 📸

// 4. Reviews 컬렉션
{
  "_id": ObjectId("..."),
  "order_id": ObjectId("..."),
  "talent_id": ObjectId("..."),
  "buyer": {
    "id": ObjectId("..."),
    "name": "이구매",
    "avatar": "https://..."
  },
  "seller_id": ObjectId("..."),
  "rating": 5,
  "comment": "정말 도움이 많이 되었습니다!",
  "images": [
    "https://...",
    "https://..."
  ],
  "reply": {  // 판매자 답변
    "comment": "감사합니다!",
    "created_at": ISODate("2024-01-21T10:00:00Z")
  },
  "created_at": ISODate("2024-01-20T16:00:00Z")
}

// 인덱스
db.reviews.createIndex({ talent_id: 1, created_at: -1 })
db.reviews.createIndex({ "buyer.id": 1, created_at: -1 })
db.reviews.createIndex({ seller_id: 1, created_at: -1 })

리뷰는 별도 컬렉션으로 분리했어.
재능 문서에 임베디드하면 리뷰가 많아질수록 문서가 너무 커지거든!
대신 재능 문서에는 통계(평균 평점, 리뷰 수)만 저장해둬.

// 5. Messages 컬렉션 (버킷 패턴)
{
  "_id": ObjectId("..."),
  "conversation_id": "507f1f77bcf86cd799439011_507f191e810c19729de860ea",
  "participants": [
    ObjectId("507f1f77bcf86cd799439011"),
    ObjectId("507f191e810c19729de860ea")
  ],
  "start_time": ISODate("2024-01-15T10:00:00Z"),
  "end_time": ISODate("2024-01-15T11:00:00Z"),
  "messages": [
    {
      "sender_id": ObjectId("507f1f77bcf86cd799439011"),
      "text": "안녕하세요!",
      "timestamp": ISODate("2024-01-15T10:05:00Z"),
      "read": true
    },
    {
      "sender_id": ObjectId("507f191e810c19729de860ea"),
      "text": "네, 안녕하세요!",
      "timestamp": ISODate("2024-01-15T10:06:00Z"),
      "read": true
    }
    // ... 최대 100개 메시지
  ],
  "message_count": 2
}

// 인덱스
db.messages.createIndex({ conversation_id: 1, start_time: -1 })
db.messages.createIndex({ participants: 1, start_time: -1 })

메시지는 버킷 패턴을 사용했어!
1시간 또는 100개 메시지 단위로 묶어서 저장하면,
수백만 개의 메시지도 효율적으로 관리할 수 있어. 💬

🎯 쿼리 예시

// 카테고리별 인기 재능 조회
db.talents.find({
  "category.id": ObjectId("..."),
  status: "active"
}).sort({ "stats.rating": -1, "stats.orders": -1 }).limit(20)

// 사용자의 주문 내역 조회 (구매자)
db.orders.find({
  "buyer.id": ObjectId("...")
}).sort({ created_at: -1 })

// 재능 상세 + 최근 리뷰 조회
const talent = db.talents.findOne({ _id: ObjectId("...") })
const reviews = db.reviews.find({ 
  talent_id: ObjectId("...") 
}).sort({ created_at: -1 }).limit(10)

// 전문 검색 (제목, 설명, 태그)
db.talents.find({
  $text: { $search: "MongoDB 스키마 설계" },
  status: "active"
}).sort({ score: { $meta: "textScore" } })

// 대화 내역 조회 (최근 10개 버킷)
db.messages.find({
  conversation_id: "..."
}).sort({ start_time: -1 }).limit(10)

💡 설계 포인트 정리

1. 읽기 최적화: 자주 함께 조회되는 데이터는 임베디드 또는 스냅샷
2. 확장성: 무한정 커질 수 있는 데이터는 별도 컬렉션 또는 버킷 패턴
3. 일관성: 주문 같은 중요 데이터는 스냅샷으로 당시 정보 보존
4. 검색 성능: 자주 사용하는 필터와 정렬 조건에 복합 인덱스 생성
5. 유연성: 향후 확장을 고려한 구조 (예: 카테고리 경로 배열)

🎬 마무리하며

와, 여기까지 정말 긴 여정이었어! 🎉
MongoDB 스키마 설계와 컬렉션 최적화에 대해 많은 걸 배웠지?

핵심을 다시 한번 정리해보자면:

1. 애플리케이션의 읽기 패턴을 중심으로 설계하라
관계형 DB처럼 정규화에 집착하지 말고, 함께 조회되는 데이터는 함께 저장해.

2. 임베디드 vs 레퍼런스를 상황에 맞게 선택하라
데이터 크기, 조회 패턴, 업데이트 빈도를 고려해서 결정해.

3. 검증된 패턴을 활용하라
Tree, Bucket, Extended Reference 등 상황에 맞는 패턴을 사용해.

4. 인덱스를 전략적으로 생성하라
ESR 규칙을 따르고, 사용되지 않는 인덱스는 과감히 제거해.

5. 지속적으로 모니터링하고 개선하라
느린 쿼리를 찾아서 최적화하고, 데이터 패턴 변화에 대응해.

🚀 다음 단계

이제 이론은 충분히 배웠으니, 직접 실습해보는 게 중요해!

1. 작은 프로젝트로 시작: 간단한 블로그나 TODO 앱으로 연습
2. explain() 습관화: 모든 쿼리에 explain()을 붙여서 성능 확인
3. 실제 데이터로 테스트: 수만~수십만 건의 데이터로 성능 측정
4. 커뮤니티 활용: MongoDB 공식 포럼, Stack Overflow에서 질문하고 배우기
5. 공식 문서 읽기: MongoDB 공식 문서는 정말 잘 되어 있어!

재능넷 같은 플랫폼을 만들든, 개인 프로젝트를 하든,
MongoDB 스키마 설계는 처음부터 제대로 하는 게 정말 중요해.
나중에 마이그레이션하려면 엄청난 고생을 하거든! 😅

이 글이 MongoDB 스키마 설계에 고민하는 모든 개발자들에게 도움이 되길 바라!
궁금한 점이 있으면 언제든 재능넷 커뮤니티에서 물어봐.
함께 성장하는 개발자가 되자! 💪✨

📚 추천 자료

MongoDB 공식 문서: docs.mongodb.com
MongoDB University: learn.mongodb.com (무료 강의!)
MongoDB Blog: 실전 사례와 베스트 프랙티스
재능넷 지식인의 숲: 더 많은 개발 지식 공유!

Happy Coding! 🎨💻🚀

지식인의 숲 - 지적 재산권 보호 고지

지적 재산권 보호 고지

사용 제한: 재능넷의 명시적 서면 동의 없이 본 컨텐츠를 복제, 수정, 배포, 또는 상업적으로 활용하는 행위는 엄격히 금지됩니다.
데이터 수집 금지: 본 컨텐츠에 대한 무단 스크래핑, 크롤링, 및 자동화된 데이터 수집은 법적 제재의 대상이 됩니다.
AI 학습 제한: 재능넷의 AI 생성 컨텐츠를 타 AI 모델 학습에 무단 사용하는 행위는 금지되며, 이는 지적 재산권 침해로 간주됩니다.

2.6K

서버셋팅 , 서버이전, 마이그레션 해드립니다.

🚀 서버 구축 및 환경 세팅 전문 서비스 기본 운영체제는 CentOS 또는 Ubuntu 입니다. 웹서비스, 백엔드 API, 프론트엔드 배포 환경까지 전체 서버 인프라 구축을 지원합니다. ⚙️ [기본 패키지 구성] (각 5만원) Apache + MariaDB + PHP Nginx + MariaDB + PHP Nginx + MariaDB + Java + Tom

10,000원~

929

리눅스 윈도우 서버 해킹방어 보안, 워드프레스, php, jsp, asp, node js, python

- 원하시는 버전으로 APM을 설치 및 기본 세팅 (Apache, PHP, Mysql) PHP, JSP (Apache Tomcat), Flask, Django, Joomla) 워드프레스, Wordpress, Lalabel, Drupal 등 모든 종류의 서버 구축 디도스 방어 및 해킹 방어 보안 강화 - SSL 설정 (SSL 구매 별도) AWS, Azure

270,000원~ 후기 0개

6년차 AI기업 출신 개발자 | 윈도우 프로그램, 백엔드 API, 업무 시스템 개발

저는 이런 사람입니다! 안녕하세요. 6년차 경력을 가지고 있는 개발자입니다.코스닥 상장 AI 중견기업에서 4년간 재직하며 실무 경험을 쌓고 현재는 프리랜서로 활동하고 있습니다. - 의료 AI 솔루션 개발 - On-device AI LLM Tokenizer 개발 및 Finetuning - 실시간 STT/TTS 음성 처리 시스템 개발 - 대용량 데이터 전처리

5,000원~ 후기 0개

NEW