몽고DB 소개 (Introduction)

원문 출처: MongoDB Manual — Introduction to MongoDB MongoDB 공식 문서를 바탕으로 재해석한 한국어 자료입니다.

MongoDB를 처음 시작할 때 가장 먼저 만나게 되는 질문이 있을 거예요. "몽고DB는 도대체 어디에 설치해서 써야 하지?"부터 시작해서, "내가 만드는 애플리케이션에 맞는 데이터베이스가 이런 구조를 갖고 있긴 한가?" 같은 고민까지요. 이 페이지에서는 그런 궁금증을 하나씩 풀어드릴게요.

MongoDB를 어디에서 쓸 수 있을까요

MongoDB 데이터베이스를 만들 수 있는 환경이 크게 세 가지로 나뉘어요. 어느 쪽이든 본인이 직접 운영할지, 클라우드에 맡길지에 따라 고르면 돼요.

MongoDB Atlas — 클라우드에서 MongoDB를 완전히 관리해 주는 서비스예요. 배포와 운영을 Atlas가 대신 처리해 주니까, 인프라를 신경 쓰기보다 데이터 모델링에 집중하고 싶을 때 잘 맞아요.
MongoDB Enterprise — 구독 방식으로 제공되는, 스스로 관리하는 버전이에요. 엔터프라이즈 기능과 지원이 필요한 조직에서 써요.
MongoDB Community — 소스가 공개되어 있고 무료로 쓸 수 있는 자체 관리 버전이에요. 개인 프로젝트나 학습용으로 시작하기에 부담이 없어요.

검색해 보면 Atlas UI로 데이터베이스를 만드는 과정을 다루는 Get Started with Atlas 문서도 따로 있으니, 클라우드로 바로 시작하고 싶다면 그쪽을 참고하면 돼요.

Document Database — 문서형 데이터베이스

MongoDB의 핵심은 한마디로 문서(document) 단위로 데이터를 다룬다는 점이에요. MongoDB에서 레코드 하나는 곧 문서이고, 이 문서는 필드(field)와 값(value)의 쌍으로 이루어진 데이터 구조예요. 들어가 보면 JSON 객체와 아주 비슷하다는 걸 금방 느낄 수 있어요.

문서 안의 값 구조는 꽤 자유로워요. 단순한 숫자나 문자열일 수도 있고, 다른 문서일 수도 있으며, 배열이나 문서의 배열이 들어갈 수도 있어요. 그래서 우리 애플리케이션 코드에서 쓰는 객체 모델과 똑같은 모습으로 데이터를 표현할 수 있죠. 관계형 데이터베이스에서 필요한 객체-관계 매핑(ORM) 같은 복잡한 중간 작업이 사라지는 이유가 바로 이거예요.

실제 문서 하나를 보면 감이 바로 오실 거예요.

{
  _id: ObjectId("507f1f77bcf86cd799439011"),
  name: "Alice",
  birthdate: ISODate("1990-01-01T00:00:00Z"),
  address: {
    street: "123 Main St",
    city: "Springfield",
    state: "IL"
  },
  hobbies: ["reading", "hiking", "coding"]
}

이렇게 쓰면 사용자 한 명의 주소, 취미 같은 계층적인(hierarchical) 정보가 한 문서 안에 자연스럽게 담겨요. 문서 데이터 모델에서 얻는 실질적인 이점을 정리하면 이렇습니다.

문서가 많은 프로그래밍 언어의 네이티브 데이터 타입과 바로 대응돼요. 코드에서 쓰는 객체를 그대로 저장한다고 생각하면 돼요.
문서 안에 다른 문서나 배열을 **내장(embed)**할 수 있어서, 성능을 떨어뜨리는 비싼 조인(join)이 줄어들어요.
동적 스키마(dynamic schema) 덕분에 같은 컬렉션 안에서도 문서마다 구조가 조금씩 달라질 수 있어요. 이걸 폴리모피즘(polymorphism)이라고 부르는데, 데이터가 비균일해도 유연하게 받아들일 수 있죠.

Collections — 컬렉션

그럼 이런 문서들은 어디에 쌓일까요. MongoDB는 문서를 **컬렉션(collection)**에 저장해요. 컬렉션은 관계형 데이터베이스의 테이블(table)과 비슷한 역할을 하는데, 한 가지 큰 차이가 있어요. 테이블은 미리 정해진 스키마를 강제하지만, 컬렉션은 그런 고정된 스키마를 강제하지 않아요. 그래서 데이터가 변해도 다운타임 없이 모델을 진화시킬 수 있고, 빠르게 반복(iterate)하면서 비균일한 데이터까지 쉽게 다룰 수 있는 거예요.

컬렉션 말고도 MongoDB에는 두 가지 읽기 전용 관점이 더 있어요.

읽기 전용 뷰(Views)
온디맨드 구체화 뷰(On-Demand Materialized Views)

Key Features — 주요 기능

이제 MongoDB가 어떤 특징을 가졌는지 하나씩 볼게요. 데이터를 다루는 방식뿐 아니라, 성능과 가용성, 확장 측면에서 어떤 일을 해주는지가 핵심이에요.

High Performance — 높은 성능

MongoDB는 높은 성능의 데이터 영속성(persistence)을 제공해요. 그 비결을 두 가지만 꼽아보면 이렇습니다.

문서를 내장하는 데이터 모델이 데이터베이스 시스템의 I/O 활동을 줄여줘요. 조인을 피하고 필요한 데이터를 한 번에 읽어오니까 디스크 접근이 덜 생기죠.
**인덱스(index)**가 쿼리를 더 빨라지게 해주고, 인덱스에 내장 문서와 배열의 키도 포함할 수 있어요.

Query API — 쿼리 API

MongoDB의 쿼리 API는 기본적인 **읽기·쓰기 연산(CRUD)**을 지원하고, 여기에 더해 다음 기능도 함께 제공해요.

데이터 집계(Data Aggregation) — 집계 파이프라인으로 데이터를 단계별로 변환하고 요약할 수 있어요.
**텍스트 검색(Text Search)**과 지리공간 쿼리(Geospatial Queries)

SQL에 익숙하다면, MongoDB의 쿼리가 SQL과 어떻게 대응되는지 보여주는 문서가 따로 있어요. SQL to MongoDB Mapping Chart와 SQL to Aggregation Mapping Chart를 보면 개념을 빠르게 매핑할 수 있어요.

High Availability — 높은 가용성

MongoDB의 복제 기능은 **replica set(레플리카 셋)**이라고 불러요. 이 기능이 가져다주는 실질적인 이점은 두 가지예요.

자동 장애 조치(automatic failover) — 주 서버가 문제가 생기면 클러스터가 자동으로 새 primary를 선출해서 쓰기가 계속 가능해져요.
데이터 중복(data redundancy) — 같은 데이터셋을 여러 서버가 나눠 유지하니까 데이터 가용성이 올라가요.

레플리카 셋은 쉽게 말해 같은 데이터를 유지하는 MongoDB 서버들의 그룹이에요. 서버 하나가 죽어도 다른 서버가 그 역할을 이어받으니, 서비스가 끊기지 않도록 도와주는 구조죠.

Horizontal Scalability — 수평 확장

데이터가 계속 커지면 한 대로 감당하기 어려워지는 순간이 오거든요. MongoDB는 **샤딩(sharding)**이라는 기법으로 수평 확장을 기본 지원해요. 샤드 키(shard key)를 기준으로 데이터를 여러 머신에 자동으로 분산시키고, 밸런스된 클러스터에서는 특정 zone에 속한 읽기·쓰기를 그 zone 안의 샤드로만 보내도록 조정해요. 지리적 영역별로 데이터 배치를 제어하는 Zone Sharding에 대해 더 자세히 보고 싶다면 Zones 문서를 참고하세요.

Support for Multiple Storage Engines — 여러 스토리지 엔진 지원

MongoDB는 한 가지 저장 방식에 묶여 있지 않고, 여러 **스토리지 엔진(storage engine)**을 지원해요. 워크로드에 따라 저장 엔진을 고를 수 있다는 뜻인데, 각 엔진의 특성은 Storage Engines 문서에서 자세히 다룹니다.

지금까지 MongoDB가 어떤 데이터베이스인지 큰 그림으로 살펴봤어요. 문서형 구조로 데이터를 자유롭게 모델링하고, 성능·가용성·확장성에서 어떤 선택지를 주는지 감이 잡히셨다면, 다음 단계로 직접 데이터베이스를 만들고 문서를 읽고 써보는 걸 권해드려요.