MongoDB 소개와 NoSQL 이해

관계형 데이터베이스의 한계를 넘어 등장한 NoSQL과 MongoDB의 세계를 탐험합니다. 문서 지향 데이터베이스의 개념부터 실무 활용 사례까지, 초급 개발자도 쉽게 이해할 수 있도록 친절하게 안내합니다.

---

목차

1. NoSQL_데이터베이스란
2. MongoDB_탄생_배경
3. RDBMS_vs_MongoDB_비교
4. 문서_지향_데이터베이스_개념
5. MongoDB_사용_사례
6. MongoDB_에디션_종류

---

1. NoSQL 데이터베이스란

어느 날 김개발 씨는 회사에서 새로운 프로젝트를 시작하게 되었습니다. 기획팀에서 넘어온 요구사항을 보니 데이터 구조가 수시로 바뀔 수 있다고 적혀 있었습니다.

"이걸 기존 MySQL로 어떻게 처리하지?" 고민에 빠진 김개발 씨에게 선배가 다가와 말했습니다. "NoSQL을 한번 알아봐요."

NoSQL은 "Not Only SQL"의 약자로, 전통적인 관계형 데이터베이스와는 다른 방식으로 데이터를 저장하고 관리하는 데이터베이스입니다. 마치 서류 캐비닛에 정해진 양식대로만 서류를 넣어야 하는 것이 관계형 데이터베이스라면, NoSQL은 다양한 형태의 서류를 자유롭게 보관할 수 있는 서랍장과 같습니다.

이를 통해 유연한 데이터 구조와 대용량 데이터 처리가 가능해집니다.

다음 코드를 살펴봅시다.

// 관계형 데이터베이스 방식 - 정해진 스키마 필요
// CREATE TABLE users (id INT, name VARCHAR(100), email VARCHAR(100));

// NoSQL 방식 - 유연한 문서 구조
const user1 = {
  name: "김개발",
  email: "kim@example.com",
  skills: ["JavaScript", "Python"]  // 배열도 자유롭게 저장
};

const user2 = {
  name: "박시니어",
  email: "park@example.com",
  department: "Backend",  // 다른 필드도 추가 가능
  projects: [{ name: "API서버", role: "Lead" }]
};

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 지금까지 MySQL만 사용해왔던 그에게 NoSQL이라는 단어는 낯설기만 했습니다.

선배 박시니어 씨가 커피 한 잔을 건네며 이야기를 시작했습니다. "NoSQL이 뭔지 궁금해요?

쉽게 설명해 줄게요." 박시니어 씨는 화이트보드에 그림을 그리기 시작했습니다. "관계형 데이터베이스를 생각해봐요.

마치 엑셀 시트처럼 행과 열이 딱딱 정해져 있잖아요. 사원 테이블이라면 이름, 부서, 입사일 같은 컬럼이 미리 정의되어 있어야 해요." 김개발 씨가 고개를 끄덕였습니다.

"네, 스키마를 먼저 설계하고 테이블을 만들어야 하잖아요." "맞아요. 그런데 문제는 요구사항이 바뀔 때 생겨요." 박시니어 씨가 말을 이었습니다.

만약 기획팀에서 갑자기 "사원마다 보유 기술을 저장해야 해요"라고 하면 어떻게 될까요? ALTER TABLE로 컬럼을 추가하거나, 별도의 테이블을 만들어서 JOIN해야 합니다.

프로젝트가 커질수록 이런 변경은 점점 부담이 됩니다. NoSQL은 이런 문제를 해결하기 위해 등장했습니다.

정해진 스키마 없이 데이터를 저장할 수 있어서, 각 레코드마다 서로 다른 필드를 가질 수 있습니다. "마치 JSON 객체를 그대로 저장한다고 생각하면 돼요." 박시니어 씨가 코드를 보여주며 설명했습니다.

위의 코드를 보면 user1과 user2가 서로 다른 필드를 가지고 있습니다. user1에는 skills 배열이 있고, user2에는 department와 projects가 있습니다.

관계형 데이터베이스였다면 이런 구조는 여러 테이블로 분리해야 했을 것입니다. NoSQL은 크게 네 가지 유형으로 나뉩니다.

문서형(MongoDB, CouchDB), 키-값형(Redis, DynamoDB), 컬럼형(Cassandra, HBase), 그래프형(Neo4j)이 그것입니다. 각각의 유형은 서로 다른 사용 목적에 최적화되어 있습니다.

실제 현업에서는 어떤 경우에 NoSQL을 선택할까요? 데이터 구조가 자주 바뀌거나, 대용량 데이터를 빠르게 처리해야 하거나, 수평적 확장이 필요한 경우에 NoSQL이 좋은 선택이 됩니다.

하지만 모든 상황에 NoSQL이 정답은 아닙니다. 복잡한 트랜잭션이 필요하거나, 데이터 간의 관계가 중요한 경우에는 여전히 관계형 데이터베이스가 더 적합합니다.

김개발 씨가 물었습니다. "그러면 프로젝트마다 어떤 데이터베이스를 쓸지 잘 판단해야겠네요?" 박시니어 씨가 웃으며 답했습니다.

"정확해요. 도구는 상황에 맞게 쓰는 거예요.

NoSQL과 RDBMS는 경쟁 관계가 아니라 상호 보완 관계입니다."

실전 팁

💡 - NoSQL은 "No SQL"이 아니라 "Not Only SQL"의 약자입니다. SQL을 완전히 대체하는 것이 아니라 보완하는 개념으로 이해하세요.

• 프로젝트 초기에 데이터 구조가 불확실하다면 NoSQL을 먼저 고려해보세요.

---

2. MongoDB 탄생 배경

김개발 씨는 NoSQL에 대해 알게 된 후, 그중에서도 가장 인기 있다는 MongoDB에 관심을 갖게 되었습니다. "도대체 MongoDB는 어떻게 만들어진 거예요?" 김개발 씨의 질문에 박시니어 씨가 2007년으로 거슬러 올라가는 이야기를 시작했습니다.

MongoDB는 2007년 DoubleClick 출신의 개발자들이 설립한 10gen(현 MongoDB Inc.)에서 만든 문서 지향 데이터베이스입니다. 대규모 웹 애플리케이션을 개발하면서 기존 관계형 데이터베이스의 한계를 절감한 그들은, 확장성과 유연성을 갖춘 새로운 데이터베이스를 만들기로 결심했습니다.

이름은 "humongous"(거대한)에서 따왔으며, 2009년 오픈소스로 공개되었습니다.

다음 코드를 살펴봅시다.

// MongoDB의 핵심 철학을 보여주는 코드
const { MongoClient } = require('mongodb');

async function connectToMongoDB() {
  // 단일 서버 또는 클러스터에 동일한 방식으로 연결
  const client = new MongoClient('mongodb://localhost:27017');
  await client.connect();

  const db = client.db('myapp');
  // 컬렉션이 없으면 자동 생성 - 유연성의 핵심
  const users = db.collection('users');

  // 스키마 정의 없이 바로 데이터 삽입
  await users.insertOne({ name: "김개발", role: "Junior" });

  console.log("MongoDB에 성공적으로 연결되었습니다!");
}

2007년, 실리콘밸리에서는 웹 서비스의 폭발적인 성장이 일어나고 있었습니다. DoubleClick이라는 온라인 광고 회사에서 일하던 개발자들은 심각한 고민에 빠져 있었습니다.

"데이터가 너무 빠르게 늘어나요. 기존 데이터베이스로는 감당이 안 됩니다." 그들이 마주한 문제는 확장성이었습니다.

관계형 데이터베이스는 수직 확장(더 좋은 서버로 교체)에는 강했지만, 수평 확장(서버를 여러 대로 늘림)에는 한계가 있었습니다. 서버 한 대의 성능에는 물리적 한계가 있기 때문입니다.

Dwight Merriman, Eliot Horowitz, Kevin Ryan 세 사람은 회사를 나와 10gen이라는 스타트업을 설립했습니다. 처음에는 클라우드 플랫폼 서비스를 만들려고 했지만, 그 과정에서 탄생한 데이터베이스 컴포넌트가 바로 MongoDB입니다.

MongoDB라는 이름은 "humongous"라는 영어 단어에서 왔습니다. "거대한"이라는 뜻으로, 대용량 데이터를 다루겠다는 포부가 담겨 있습니다.

개발팀은 몇 가지 핵심 원칙을 세웠습니다. 첫째, 스키마 없이도 데이터를 저장할 수 있어야 합니다.

둘째, 수평 확장이 쉬워야 합니다. 셋째, 개발자 친화적이어야 합니다.

2009년, MongoDB는 오픈소스로 세상에 공개되었습니다. 반응은 폭발적이었습니다.

스타트업들이 빠르게 MongoDB를 도입하기 시작했고, 이후 대기업들도 관심을 보이기 시작했습니다. 위의 코드를 보면 MongoDB의 철학이 잘 드러납니다.

별도의 스키마 정의 없이 바로 데이터를 삽입할 수 있습니다. 컬렉션이 없으면 자동으로 생성됩니다.

개발자 입장에서는 마치 JavaScript 객체를 다루듯 데이터베이스를 다룰 수 있는 것입니다. MongoDB는 C++로 작성되어 성능이 뛰어나면서도, JavaScript 기반의 쿼리 언어를 지원하여 웹 개발자들이 쉽게 접근할 수 있었습니다.

현재 MongoDB는 전 세계 수만 개의 기업에서 사용되고 있습니다. Forbes Global 2000 기업의 절반 이상이 MongoDB를 도입했다고 알려져 있습니다.

김개발 씨가 감탄하며 말했습니다. "개발자들이 직접 겪은 문제를 해결하려고 만든 거군요." 박시니어 씨가 답했습니다.

"그래서 더 개발자 친화적인 것 같아요. 실제 현장의 고통을 알고 만든 도구니까요."

실전 팁

💡 - MongoDB의 공식 문서(docs.mongodb.com)는 매우 잘 정리되어 있으니 참고하세요.

• 10gen은 2013년에 회사명을 MongoDB Inc.로 변경했고, 2017년 나스닥에 상장했습니다.

---

3. RDBMS vs MongoDB 비교

김개발 씨는 이제 MongoDB가 무엇인지 대략 알게 되었습니다. 하지만 여전히 헷갈리는 부분이 있었습니다.

"그러면 기존에 쓰던 MySQL이랑 정확히 뭐가 다른 거예요?" 박시니어 씨가 화이트보드를 지우고 새로운 비교표를 그리기 시작했습니다.

RDBMS(관계형 데이터베이스)와 MongoDB는 데이터를 바라보는 관점 자체가 다릅니다. RDBMS가 정규화된 테이블과 관계를 중심으로 데이터를 구조화한다면, MongoDB는 실제 객체 형태 그대로 데이터를 저장합니다.

마치 레고 블록으로 정해진 설명서대로만 조립하는 것(RDBMS)과 자유롭게 원하는 형태로 조립하는 것(MongoDB)의 차이와 같습니다.

다음 코드를 살펴봅시다.

// RDBMS 방식 - 여러 테이블로 분리 (MySQL 예시)
// users: id, name, email
// orders: id, user_id, total_price
// order_items: id, order_id, product_name, quantity
// 조회 시 JOIN 필요: SELECT * FROM users JOIN orders ON...

// MongoDB 방식 - 하나의 문서에 모든 정보 포함
const orderDocument = {
  _id: ObjectId("507f1f77bcf86cd799439011"),
  user: {
    name: "김개발",
    email: "kim@example.com"
  },
  items: [
    { product: "노트북", quantity: 1, price: 1500000 },
    { product: "마우스", quantity: 2, price: 50000 }
  ],
  totalPrice: 1600000,
  orderDate: new Date("2024-01-15")
};

박시니어 씨가 화이트보드에 두 개의 열을 그렸습니다. 왼쪽에는 "RDBMS", 오른쪽에는 "MongoDB"라고 적었습니다.

"먼저 용어부터 비교해볼게요." 박시니어 씨가 말했습니다. RDBMS에서 테이블이라고 부르는 것을 MongoDB에서는 컬렉션이라고 부릅니다.

**행(Row)**은 **문서(Document)**가 되고, **열(Column)**은 **필드(Field)**가 됩니다. 용어는 다르지만 대응되는 개념이 있어서 이해하기 어렵지 않습니다.

김개발 씨가 끼어들었습니다. "그러면 그냥 이름만 다른 건가요?" "좋은 질문이에요.

핵심적인 차이가 있어요." 박시니어 씨가 설명을 이어갔습니다. 가장 큰 차이는 데이터 모델링 방식입니다.

RDBMS에서는 데이터를 정규화합니다. 중복을 최소화하기 위해 데이터를 여러 테이블로 분리하고, 필요할 때 JOIN으로 합칩니다.

반면 MongoDB에서는 비정규화를 권장합니다. 관련된 데이터를 하나의 문서 안에 모두 넣는 것입니다.

위의 코드 예시를 보면, 주문 정보에 사용자 정보와 주문 항목이 모두 포함되어 있습니다. "이렇게 하면 뭐가 좋은 건가요?" 김개발 씨가 물었습니다.

조회 성능이 좋아집니다. RDBMS에서 주문 정보를 가져오려면 users, orders, order_items 테이블을 JOIN해야 합니다.

MongoDB에서는 문서 하나만 읽으면 됩니다. 디스크 I/O가 줄어들고, 쿼리가 단순해집니다.

하지만 단점도 있습니다. 데이터 중복이 발생할 수 있습니다.

만약 사용자의 이메일이 바뀌면, 모든 주문 문서를 찾아서 업데이트해야 할 수도 있습니다. 스키마 유연성도 큰 차이입니다.

RDBMS에서는 테이블 구조를 먼저 정의해야 합니다. ALTER TABLE로 변경은 가능하지만, 대용량 테이블에서는 부담이 큽니다.

MongoDB는 스키마가 유연해서, 같은 컬렉션 안에 서로 다른 구조의 문서가 공존할 수 있습니다. 확장성 측면도 다릅니다.

RDBMS는 주로 수직 확장(Scale-up)에 의존합니다. MongoDB는 샤딩을 통한 수평 확장(Scale-out)이 기본 기능으로 내장되어 있습니다.

박시니어 씨가 정리했습니다. "결론적으로, 어떤 것이 더 좋다기보다는 상황에 따라 선택해야 해요." 복잡한 트랜잭션이 필요하거나, 데이터 무결성이 매우 중요하다면 RDBMS가 적합합니다.

빠른 개발 속도가 필요하거나, 데이터 구조가 자주 바뀌거나, 대용량 데이터의 빠른 읽기가 중요하다면 MongoDB가 좋은 선택입니다.

실전 팁

💡 - 실무에서는 RDBMS와 MongoDB를 함께 사용하는 경우도 많습니다. 각각의 장점을 살리는 폴리글랏 퍼시스턴스 전략을 고려해보세요.

• MongoDB도 4.0 버전부터 멀티 도큐먼트 트랜잭션을 지원하므로, 트랜잭션이 필요하다고 무조건 RDBMS를 선택할 필요는 없습니다.

---

4. 문서 지향 데이터베이스 개념

김개발 씨는 MongoDB가 "문서 지향 데이터베이스"라는 말을 여러 번 들었습니다. 하지만 여기서 말하는 "문서"가 정확히 무엇인지는 명확하지 않았습니다.

"워드 문서 같은 건가요?" 김개발 씨의 순진한 질문에 박시니어 씨가 빙그레 웃으며 설명을 시작했습니다.

문서 지향 데이터베이스에서 말하는 "문서"는 JSON과 유사한 형태의 데이터 구조를 의미합니다. MongoDB는 내부적으로 BSON(Binary JSON)이라는 형식을 사용하는데, 이는 JSON의 장점을 살리면서 더 많은 데이터 타입과 더 빠른 처리 속도를 제공합니다.

마치 서류철에 관련 서류를 한데 모아두는 것처럼, 연관된 데이터를 하나의 문서로 묶어서 저장합니다.

다음 코드를 살펴봅시다.

// MongoDB 문서(Document)의 구조 예시
const blogPost = {
  _id: ObjectId("507f1f77bcf86cd799439011"),  // 자동 생성되는 고유 ID
  title: "MongoDB 입문 가이드",
  content: "MongoDB는 문서 지향 데이터베이스입니다...",
  author: {                                    // 내장 문서 (Embedded Document)
    name: "김개발",
    email: "kim@example.com"
  },
  tags: ["MongoDB", "NoSQL", "Database"],      // 배열
  viewCount: 1523,                             // 숫자
  isPublished: true,                           // 불리언
  createdAt: new Date("2024-01-15T10:30:00"),  // 날짜
  metadata: {                                  // 중첩 객체
    readTime: 5,
    category: "Tech"
  }
};

"아니요, 워드 문서는 아니에요." 박시니어 씨가 웃으며 대답했습니다. 여기서 말하는 **문서(Document)**는 프로그래밍에서 흔히 사용하는 JSON 객체와 비슷한 것입니다.

키와 값의 쌍으로 이루어진 데이터 구조입니다. "아, JSON이요!

그건 많이 써봤어요." 김개발 씨의 눈이 밝아졌습니다. 맞습니다.

JavaScript 개발자라면 JSON은 매우 익숙할 것입니다. MongoDB의 문서는 이 JSON과 거의 동일하게 생겼습니다.

다만 내부적으로는 BSON이라는 형식으로 저장됩니다. BSON은 "Binary JSON"의 약자입니다.

JSON을 바이너리로 인코딩한 것인데, 몇 가지 장점이 있습니다. 첫째, JSON에는 없는 Date, ObjectId, Binary Data 같은 추가 데이터 타입을 지원합니다.

둘째, 바이너리 형식이라 파싱 속도가 빠릅니다. 셋째, 데이터를 순회할 때 길이 정보가 포함되어 있어 효율적인 탐색이 가능합니다.

위의 코드를 보면 문서의 다양한 특징을 볼 수 있습니다. _id 필드는 모든 문서에 자동으로 생성되는 고유 식별자입니다.

12바이트의 ObjectId로, 타임스탬프, 머신 ID, 프로세스 ID, 카운터를 조합하여 만들어집니다. 전 세계 어디서 생성해도 중복될 확률이 거의 없습니다.

**내장 문서(Embedded Document)**는 문서 안에 또 다른 문서를 넣는 것입니다. 위 예시에서 author 필드가 그렇습니다.

관련된 데이터를 한 곳에 모아둘 수 있어서 조회할 때 JOIN이 필요 없습니다. 배열도 자유롭게 저장할 수 있습니다.

tags 필드처럼 여러 값을 하나의 필드에 담을 수 있습니다. RDBMS였다면 별도의 tags 테이블을 만들고 다대다 관계를 설정해야 했을 것입니다.

문서의 최대 크기는 16MB입니다. 대부분의 경우 이 정도면 충분하지만, 큰 파일을 저장해야 한다면 GridFS라는 별도의 기능을 사용합니다.

김개발 씨가 물었습니다. "그러면 문서마다 구조가 달라도 되는 건가요?" "네, 그게 바로 **스키마리스(Schemaless)**의 장점이에요." 박시니어 씨가 답했습니다.

같은 컬렉션 안에 있는 문서들이 서로 다른 필드를 가질 수 있습니다. 물론 실무에서는 어느 정도 일관된 구조를 유지하는 것이 좋습니다.

MongoDB는 스키마 검증(Schema Validation) 기능도 제공하므로, 필요하다면 문서 구조에 제약을 걸 수도 있습니다.

실전 팁

💡 - 문서 설계 시 "함께 조회되는 데이터는 함께 저장한다"는 원칙을 기억하세요.

• BSON은 JSON보다 약간 더 많은 저장 공간을 사용하지만, 처리 속도는 더 빠릅니다.

---

5. MongoDB 사용 사례

이론은 충분히 배웠습니다. 김개발 씨는 이제 실제로 MongoDB가 어디에서 사용되는지 궁금해졌습니다.

"선배, 실제로 MongoDB를 쓰는 회사들은 어떤 곳이에요?" 박시니어 씨가 노트북을 열어 여러 사례를 보여주기 시작했습니다.

MongoDB는 전 세계 수많은 기업에서 다양한 용도로 활용되고 있습니다. 콘텐츠 관리 시스템, 실시간 분석, IoT 데이터 처리, 모바일 앱 백엔드, 카탈로그 관리 등이 대표적인 사용 사례입니다.

Netflix, Uber, eBay, Adobe 같은 글로벌 기업들이 MongoDB를 핵심 인프라로 사용하고 있으며, 국내에서도 많은 스타트업과 대기업이 도입하고 있습니다.

다음 코드를 살펴봅시다.

// 사용 사례 1: 전자상거래 상품 카탈로그
const product = {
  _id: ObjectId("..."),
  name: "무선 이어폰",
  category: "전자기기",
  price: 150000,
  specs: {                          // 상품마다 다른 스펙 구조
    battery: "24시간",
    bluetooth: "5.0",
    weight: "55g"
  },
  reviews: [                        // 리뷰를 내장 문서로
    { user: "user123", rating: 5, comment: "최고예요!" }
  ]
};

// 사용 사례 2: 실시간 로그 분석
const logEntry = {
  timestamp: new Date(),
  level: "ERROR",
  service: "payment-api",
  message: "결제 실패",
  metadata: { userId: "u123", orderId: "o456", errorCode: "E001" }
};

박시니어 씨가 화면에 여러 회사 로고를 띄웠습니다. Netflix, Uber, eBay, Adobe...

모두 들어본 적 있는 글로벌 기업들이었습니다. "이 회사들의 공통점이 뭘까요?" 박시니어 씨가 물었습니다.

"다... 대용량 데이터를 다루는 곳들이요?" 김개발 씨가 조심스럽게 답했습니다.

"맞아요. 그리고 모두 MongoDB를 사용하고 있어요." 전자상거래는 MongoDB의 대표적인 사용 사례입니다.

상품마다 속성이 다릅니다. 의류에는 사이즈와 색상이 있고, 전자기기에는 스펙이 있습니다.

RDBMS에서는 이런 다양한 속성을 처리하기 위해 EAV(Entity-Attribute-Value) 패턴 같은 복잡한 설계가 필요합니다. MongoDB에서는 그냥 각 상품에 맞는 필드를 넣으면 됩니다.

eBay는 수억 개의 상품 정보를 MongoDB에 저장하고 있습니다. 상품 검색과 추천 시스템에 활용하고 있다고 알려져 있습니다.

**콘텐츠 관리 시스템(CMS)**도 MongoDB와 궁합이 좋습니다. 블로그 포스트, 뉴스 기사, 제품 설명 등 다양한 형태의 콘텐츠를 유연하게 저장할 수 있습니다.

Forbes, MTV, The New York Times 같은 미디어 기업들이 MongoDB를 사용합니다. 실시간 분석에도 MongoDB가 많이 쓰입니다.

위의 코드에서 logEntry 예시처럼, 서버 로그나 사용자 행동 데이터를 수집하고 분석하는 데 적합합니다. 시간 순서대로 빠르게 쓰고, 집계 파이프라인으로 분석할 수 있습니다.

IoT(사물인터넷) 분야에서도 MongoDB의 인기가 높습니다. 수많은 센서에서 쏟아지는 데이터를 저장하고 처리해야 하는데, 센서마다 데이터 형식이 다를 수 있습니다.

유연한 스키마가 빛을 발하는 영역입니다. 모바일 앱 백엔드로도 많이 사용됩니다.

JSON 기반이라 REST API와 자연스럽게 연동되고, 앱 요구사항 변화에 빠르게 대응할 수 있습니다. MongoDB Atlas의 Realm 서비스를 사용하면 모바일 앱과 더욱 쉽게 연동할 수 있습니다.

김개발 씨가 물었습니다. "그러면 MongoDB를 피해야 하는 경우도 있나요?" 박시니어 씨가 고개를 끄덕였습니다.

"물론이에요." 복잡한 다중 테이블 트랜잭션이 빈번한 금융 시스템에서는 여전히 RDBMS가 더 적합할 수 있습니다. 또한 데이터 간의 관계가 매우 복잡하고 다양한 방식의 JOIN이 필요한 경우에도 마찬가지입니다.

하지만 MongoDB도 계속 발전하고 있어서, 이전에는 약점이었던 부분들이 많이 개선되고 있습니다.

실전 팁

💡 - 프로젝트 시작 전에 데이터 접근 패턴을 먼저 분석하세요. "데이터를 어떻게 읽을 것인가"가 모델링의 핵심입니다.

• MongoDB Atlas(클라우드 서비스)를 사용하면 운영 부담을 크게 줄일 수 있습니다.

---

6. MongoDB 에디션 종류

김개발 씨는 이제 MongoDB를 직접 사용해보고 싶어졌습니다. 설치하려고 공식 사이트에 들어갔더니 여러 가지 버전이 있어서 당황했습니다.

"Community? Enterprise?

Atlas? 뭘 선택해야 하는 거죠?" 화면을 보며 고민하던 김개발 씨에게 박시니어 씨가 각 에디션의 차이를 설명해주기 시작했습니다.

MongoDB는 크게 세 가지 에디션으로 제공됩니다. Community Edition은 무료 오픈소스 버전으로 학습과 소규모 프로젝트에 적합합니다.

Enterprise Advanced는 상용 버전으로 보안, 모니터링, 관리 도구가 강화되어 있습니다. Atlas는 MongoDB가 직접 운영하는 클라우드 서비스로, 인프라 관리 없이 바로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

// Community Edition - 로컬 설치 후 연결
const { MongoClient } = require('mongodb');
const localUri = 'mongodb://localhost:27017';

// Atlas - 클라우드 연결 (연결 문자열만 변경)
const atlasUri = 'mongodb+srv://user:pass@cluster.mongodb.net/mydb';

async function connectMongoDB(uri) {
  const client = new MongoClient(uri);
  await client.connect();

  // 어떤 에디션이든 동일한 API 사용
  const db = client.db('myapp');
  const result = await db.collection('users').find({}).toArray();

  console.log('연결 성공! 문서 수:', result.length);
  return client;
}

박시니어 씨가 화이트보드에 세 개의 박스를 그렸습니다. 각각 "Community", "Enterprise", "Atlas"라고 적었습니다.

"하나씩 설명해줄게요." 박시니어 씨가 말했습니다. MongoDB Community Edition은 가장 기본적인 버전입니다.

무료이고 오픈소스입니다. GitHub에서 소스 코드를 볼 수도 있습니다.

핵심 기능은 모두 포함되어 있어서, 학습 목적이나 소규모 프로젝트에는 충분합니다. Community Edition에서 제공하는 기능만 해도 상당합니다.

복제본 세트(Replica Set)를 통한 고가용성, 샤딩을 통한 수평 확장, 집계 파이프라인, 인덱싱 등 핵심 기능은 모두 사용할 수 있습니다. MongoDB Enterprise Advanced는 상용 버전입니다.

Community의 모든 기능에 더해 기업 환경에 필요한 추가 기능이 포함됩니다. 대표적인 것이 보안 기능입니다.

LDAP, Kerberos 인증, 암호화 at rest, 감사 로깅 같은 기능이 있습니다. 금융이나 의료처럼 보안 규정이 엄격한 산업에서 필요한 기능들입니다.

Ops Manager라는 관리 도구도 제공됩니다. 클러스터 배포, 모니터링, 백업, 복구를 GUI로 편리하게 관리할 수 있습니다.

대규모 클러스터를 운영하는 기업에서 유용합니다. 김개발 씨가 물었습니다.

"비용은 얼마나 하나요?" "공식적으로 공개된 가격표는 없고, 영업팀에 문의해야 해요. 보통 노드 수와 계약 기간에 따라 달라집니다." 박시니어 씨가 답했습니다.

MongoDB Atlas는 조금 다른 개념입니다. MongoDB가 직접 운영하는 완전 관리형 클라우드 서비스입니다.

AWS, Google Cloud, Azure 중에서 선택할 수 있고, MongoDB가 모든 인프라를 관리해줍니다. Atlas의 가장 큰 장점은 운영 부담 감소입니다.

서버 설정, 패치, 백업, 모니터링, 확장 등을 MongoDB가 알아서 해줍니다. 개발자는 애플리케이션 개발에만 집중할 수 있습니다.

무료 티어(M0)도 있어서 학습이나 프로토타입에 부담 없이 사용할 수 있습니다. 512MB 스토리지와 공유 클러스터가 제공됩니다.

"개인적으로 처음 배우는 분들께는 Atlas 무료 티어를 추천해요." 박시니어 씨가 말했습니다. "설치할 필요 없이 바로 시작할 수 있거든요." 위의 코드를 보면, 어떤 에디션을 사용하든 코드는 거의 동일합니다.

연결 문자열(URI)만 바꾸면 됩니다. 이것이 MongoDB의 큰 장점 중 하나입니다.

로컬에서 개발하다가 프로덕션으로 옮길 때 코드 변경이 거의 필요 없습니다. 김개발 씨가 고개를 끄덕였습니다.

"저는 일단 Atlas 무료 티어로 시작해볼게요!" "좋은 선택이에요. 나중에 프로젝트가 커지면 그때 유료 플랜으로 업그레이드하면 돼요." 박시니어 씨가 미소를 지었습니다.

실전 팁

💡 - 학습 목적이라면 Atlas 무료 티어(M0)로 시작하세요. 가입 후 5분 안에 클러스터를 만들 수 있습니다.

• Community Edition을 로컬에 설치하고 싶다면 Docker를 사용하면 편리합니다: docker run -d -p 27017:27017 mongo
• Enterprise 기능이 필요한지 확실하지 않다면, Community로 시작해서 필요할 때 마이그레이션하는 것도 방법입니다.

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!