MongoDB 완전 정복: '스키마가 없는 DB'가 세계에서 가장 인기 있는 NoSQL이 된 이유

들어가며: "ALTER TABLE이 무서워요"

관계형 DB를 쓰다 보면 반드시 만나는 공포:

ALTER TABLE users ADD COLUMN phone_number VARCHAR(20);

사용자 테이블에 전화번호 열을 추가한다. 단순해 보이지만:

• 테이블에 1억 행이 있으면? → 수 분~수십 분 락(Lock) 발생
• 락이 걸리면? → 그 테이블에 대한 모든 읽기/쓰기가 중단
• 프로덕션에서? → 서비스 장애

그리고 이런 상황도 있다. 초기 스타트업이 MVP를 만든다. 데이터 구조가 매주 바뀐다. "사용자에게 주소가 필요해" → ALTER TABLE. "주소에 위도/경도도 넣자" → ALTER TABLE. "위시리스트 기능 추가" → 새 테이블 + JOIN...

"데이터 구조를 미리 정하지 않아도 되는 DB는 없을까?"

이것이 문서형 데이터베이스(Document Database) 의 핵심 아이디어이고, 그 대표가 MongoDB다.

1. MongoDB의 탄생: 광고 플랫폼에서 시작된 혁명

DoubleClick에서의 좌절

MongoDB의 창시자 Dwight Merriman과 Eliot Horowitz는 2000년대 초반 DoubleClick(인터넷 광고 플랫폼, 현재 Google Ad Manager)을 운영했다.

DoubleClick은 하루에 수십억 건의 광고 노출 이벤트를 처리해야 했다. 관계형 DB에서 이 규모를 처리하려니:

• 스키마 변경이 너무 어렵다 (광고 메타데이터가 자주 바뀜)
• 수직 확장에 한계가 있다 (더 큰 서버를 사는 것만으로는 부족)
• 수평 확장(샤딩)이 관계형 DB에서는 매우 복잡하다

2007년, 두 사람은 10gen이라는 회사를 설립하고 이 문제를 해결하기 위한 새로운 DB를 만들기 시작했다. 이름은 MongoDB — "humongous"(거대한)에서 따왔다. 거대한 규모의 데이터를 처리하겠다는 의지.

2009년: 오픈소스 공개

2009년 2월, MongoDB를 오픈소스로 공개했다. 핵심 설계 원칙:

• 문서(Document) 모델: 데이터를 JSON(BSON) 형태로 저장. 스키마 없음
• 수평 확장: 처음부터 샤딩을 핵심 기능으로 내장
• 개발자 경험: SQL 대신 직관적인 쿼리 API. JSON in, JSON out

2. 문서 모델: 왜 JSON으로 저장하는가

관계형 모델 vs 문서 모델

사용자와 주문 데이터를 저장한다고 하자:

관계형 DB (RDS/Aurora):

3개 테이블, JOIN으로 연결:

-- users 테이블
| id | name    | email           |
| 1  | 김개발  | kim@example.com |

-- addresses 테이블
| user_id | type | city   | detail      |
| 1       | home | 서울   | 강남구 ...  |
| 1       | work | 판교   | 삼평동 ...  |

-- orders 테이블
| id | user_id | product  | amount |
| 1  | 1       | 노트북   | 150만  |
| 2  | 1       | 키보드   | 15만   |

사용자 정보 전체를 가져오려면 → 3개 테이블 JOIN.

MongoDB:

하나의 문서에 모든 것:

{
  "_id": "user_1",
  "name": "김개발",
  "email": "kim@example.com",
  "addresses": [
    { "type": "home", "city": "서울", "detail": "강남구 ..." },
    { "type": "work", "city": "판교", "detail": "삼평동 ..." }
  ],
  "orders": [
    { "product": "노트북", "amount": 1500000 },
    { "product": "키보드", "amount": 150000 }
  ]
}

사용자 정보 전체를 가져오려면 → 한 번의 조회. JOIN 없음. 관련 데이터가 하나의 문서에 내장(embedded).

"스키마가 없다"의 진짜 의미

MongoDB에 "스키마가 없다"는 것은 DB가 스키마를 강제하지 않는다는 뜻이지, 스키마 없이 개발해도 된다는 뜻이 아니다.

3. MongoDB의 핵심 개념

용어 매핑

CRUD 기본

// 생성 (Create)
db.users.insertOne({
  name: "김개발",
  email: "kim@example.com",
  skills: ["Python", "MongoDB", "AWS"],
  joined: new Date("2026-01-15")
});

// 조회 (Read)
db.users.find({ skills: "MongoDB" });

// 수정 (Update) — 스키마 변경 없이 새 필드 추가!
db.users.updateOne(
  { name: "김개발" },
  { $set: { phone: "010-1234-5678" } }  // phone 필드가 없었어도 OK
);

// 삭제 (Delete)
db.users.deleteOne({ name: "김개발" });

핵심: $set: { phone: "..." } — 테이블에 phone 열이 없었는데, ALTER TABLE 없이 그냥 추가. 다른 문서에는 phone 필드가 없어도 상관없다.

인덱스

MongoDB도 인덱스가 있다. 관계형 DB의 인덱스와 개념은 같다:

// 단일 필드 인덱스
db.users.createIndex({ email: 1 });

// 복합 인덱스
db.orders.createIndex({ userId: 1, orderDate: -1 });

// 텍스트 인덱스 (풀텍스트 검색)
db.products.createIndex({ name: "text", description: "text" });

4. MongoDB 보안: 역사상 가장 많이 해킹된 DB

"인증 없이 인터넷에 노출"

MongoDB는 OpenSearch 글에서 다룬 Elasticsearch와 함께 역사상 가장 많이 해킹된 데이터베이스 중 하나다. 이유: 초기 버전의 기본 설정에 인증이 없었다.

5. 라이선스 전쟁: MongoDB vs 클라우드 사업자

OpenSearch와 같은 스토리

OpenSearch 글에서 다룬 Elastic vs AWS 갈등과 거의 동일한 패턴이 MongoDB에서도 벌어졌다. 그리고 MongoDB가 먼저 행동했다.

2018년 10월, MongoDB는 라이선스를 AGPL에서 SSPL(Server Side Public License) 로 변경했다. OpenSearch 글의 Elastic(2021년 SSPL 전환)보다 2년 앞선 결정.

이유: AWS, Azure, GCP가 MongoDB를 관리형 서비스로 제공하면서, MongoDB Inc.의 Atlas 사업과 직접 경쟁. MongoDB의 코드를 무료로 가져다 쓰면서 수익은 클라우드 사업자가 가져가는 구조.

AWS의 대응: Amazon DocumentDB

2019년 1월, AWS는 Amazon DocumentDB를 출시했다. "MongoDB API와 호환되는" 관리형 문서 DB. 하지만 MongoDB의 코드를 사용하지 않고 자체 구현.

6. MongoDB Atlas: 관리형의 시대

Atlas란

MongoDB Atlas는 MongoDB Inc.가 운영하는 완전 관리형 MongoDB 서비스. AWS, Azure, GCP 위에서 실행되지만, MongoDB Inc.가 직접 관리한다.

핵심 기능:

• 자동 샤딩, 복제, 백업
• Atlas Search: Lucene 기반 풀텍스트 검색 (OpenSearch 없이도 검색 가능)
• Atlas Vector Search: AI 벡터 검색 (RAG 파이프라인에 활용)
• Atlas Data Federation: S3, Atlas, HTTP 소스를 SQL로 통합 쿼리
• Serverless Instances: 사용량 기반 과금, 유휴 시 비용 최소

MongoDB vs DynamoDB: 언제 무엇을

이 시리즈의 DynamoDB 글과 비교:

7. MongoDB 실전 활용

활용 1: 콘텐츠 관리 시스템 (CMS)

블로그, 뉴스, 상품 카탈로그처럼 다양한 형태의 콘텐츠를 저장하는 데 MongoDB가 이상적이다. 블로그 글은 텍스트+이미지, 상품은 가격+스펙+리뷰 — 각각 구조가 다르지만 같은 컬렉션에 저장 가능.

활용 2: IoT 데이터

센서마다 보내는 데이터 구조가 다른 IoT 환경. 온도 센서는 {temp: 25.3}, GPS 센서는 {lat: 37.5, lng: 127.0}, 가속도계는 {x: 0.1, y: -0.3, z: 9.8} — MongoDB의 유연한 스키마가 빛나는 영역.

활용 3: 게임 데이터

게임 캐릭터 데이터는 매우 복잡하고 중첩된 구조: 인벤토리(아이템 목록), 스킬 트리, 퀘스트 진행 상태, 업적... 관계형 DB로는 수십 개의 테이블과 JOIN이 필요하지만, MongoDB에서는 하나의 문서에 모든 것을 담을 수 있다.

활용 4: AI/ML — 벡터 검색

MongoDB Atlas Vector Search는 2023년부터 벡터 검색을 네이티브로 지원한다. 별도의 벡터 DB(Pinecone, Weaviate) 없이, 데이터가 이미 있는 MongoDB에서 직접 유사도 검색이 가능하다.

// Atlas Vector Search
db.products.aggregate([
  {
    $vectorSearch: {
      queryVector: [0.12, -0.34, 0.56, ...],
      path: "embedding",
      numCandidates: 100,
      limit: 10,
      index: "vector_index"
    }
  }
]);

8. MongoDB를 쓰지 말아야 할 때

9. 실제 사례

eBay: 상품 카탈로그

eBay는 수십억 개의 상품 리스팅을 MongoDB에 저장한다. 각 상품의 속성이 카테고리마다 완전히 다르기 때문에(전자제품 vs 의류 vs 자동차), 유연한 스키마가 필수.

Forbes: 콘텐츠 관리

Forbes.com의 콘텐츠 관리 시스템은 MongoDB 기반이다. 기사, 비디오, 갤러리, 인포그래픽 — 형태가 다른 콘텐츠를 하나의 시스템에서 관리.

Toyota: 커넥티드 카

Toyota는 수백만 대의 차량에서 발생하는 텔레매틱스 데이터를 MongoDB에 저장한다. 차량마다 센서 구성이 다르고 데이터 구조가 빈번히 변경되므로, 유연한 스키마가 핵심.

한국 기업 사례

• 카카오: 일부 서비스의 메타데이터 저장에 MongoDB 활용
• 네이버: LINE 메시지의 일부 메타데이터를 MongoDB에 저장
• 쿠팡: 상품 카탈로그의 유연한 속성 관리에 문서 DB 패턴 활용
• 당근마켓: 중고 거래 상품의 다양한 카테고리별 속성을 유연하게 저장

10. MongoDB 비용

MongoDB Atlas 가격

Amazon DocumentDB 가격

마치며: 모든 데이터가 테이블에 맞는 건 아니다

이 시리즈에서 다룬 데이터베이스 전체를 최종 정리하면:

MongoDB의 위치는 관계형 DB와 DynamoDB 사이다. 관계형보다 유연하고, DynamoDB보다 쿼리가 풍부하다. "테이블 구조가 답답하지만, DynamoDB처럼 단순하지는 않은" 워크로드에 최적이다.

코어닷투데이의 AI 서비스에서도 MongoDB의 유연한 문서 모델은 가치가 있다. AI 모델의 메타데이터(버전별로 구조가 다름), 사용자 피드백(자유 형식), 추론 결과(모델마다 출력 구조가 다름) — 이런 데이터는 관계형 DB에 넣으려면 매번 ALTER TABLE이 필요하지만, MongoDB에서는 그냥 저장하면 된다.

ALTER TABLE의 공포에서 벗어나는 것 — 그것이 MongoDB를 선택하는 가장 솔직한 이유다.