466. 도큐먼트 DB (Document DB) - MongoDB

⚠️ 이 문서는 "게시글 테이블 따로, 댓글 테이블 따로 만들고 조인(JOIN)하기 귀찮아!"라는 개발자들을 위해, **연관된 데이터를 하나의 거대한 JSON 문서(Document) 덩어리로 통째로 묶어서 저장해 버리는 '도큐먼트 지향 NoSQL'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 데이터를 엑셀 같은 표(Table)가 아니라, **JSON(또는 BSON)**이라는 자유로운 계층형 텍스트 문서 형태로 저장하는 NoSQL 데이터베이스다.
  2. 가치: 스키마(Schema)가 없어서 나이 컬럼을 안 넣어도, 갑자기 취미 컬럼을 추가해도 에러가 안 난다. 데이터 구조가 수시로 바뀌는 스타트업이나 애자일 개발 환경에서 엄청난 속도를 낸다.
  3. 기술 체계: **MongoDB(몽고DB)**가 압도적인 1위이며, 조인(JOIN)을 하지 않기 위해 데이터를 중복해서 저장하는 '비정규화(Denormalization)'를 기본 철학으로 삼는다.

Ⅰ. 개요: 표(Table)를 찢어버려라 (Context & Necessity)

"사용자 정보에 '블로그 주소'랑 '유튜브 주소'를 추가해 줘!"

  • RDBMS (MySQL): ALTER TABLE Users ADD column... (테이블 락 걸리고 서버 버벅거림) "어? 어떤 사람은 주소가 3개네? 별도 테이블로 빼서 1:N 조인 걸어야겠다..." (머리 아픔)

  • Document DB (MongoDB): 그냥 프론트엔드에서 날아온 JSON 데이터를 그대로 DB에 꽂아버리면 끝이다.

    {
  "name": "김철수",
  "sns": ["blog.com", "youtube.com"] // 배열(Array)도 한 칸에 그냥 들어감!
}

이처럼 도큐먼트 DB는 '프론트엔드/백엔드가 쓰는 데이터 구조(JSON)'와 'DB에 저장되는 데이터 구조'가 100% 일치하기 때문에, 개발자가 데이터를 변환(ORM)하느라 쏟는 에너지를 0으로 만들어버린다.

📢 섹션 요약 비유: RDBMS가 칸막이가 쳐진 **'약통'**이라면, 도큐먼트 DB는 **'서류 봉투'**와 같습니다. 약통에는 칸마다 정해진 알약 1개씩만 넣어야 하지만, 서류 봉투에는 종이를 1장 넣든, 구겨서 10장을 넣든, 봉투 크기(16MB 제한)만 안 넘으면 내 마음대로 자유롭게 다 집어넣을 수 있습니다.

Ⅱ. 도큐먼트 DB의 핵심 철학: 비정규화 ★

RDBMS는 중복을 혐오해서 테이블을 쪼개는 '정규화'를 한다. (396번 문서) 하지만 도큐먼트 DB는 **조인(JOIN)을 극도로 혐오해서 데이터를 합쳐버리는 '비정규화(Denormalization)'**를 선호한다.

"게시판과 댓글을 어떻게 저장할까?"

  • RDBMS 방식 (참조 - Reference)
    • 게시글 테이블과 댓글 테이블을 따로 만든다.
    • 조회할 때 두 개를 조인해서 가져온다. (안전하지만 무겁다)
  • MongoDB 방식 (내포 - Embedding)
    • 게시글 JSON 문서 안에 comments라는 배열을 파고, 거기에 댓글 내용을 다 때려 박는다.
    • 장점: 글을 읽을 때 DB를 한 번만 찌르면 댓글까지 한 뭉텅이로 튀어나온다. (조회 속도 빛의 속도)
    • 단점: 댓글 쓴 사람의 프로필 사진이 바뀌면, 이 댓글이 박혀있는 모든 게시글 JSON 문서를 다 찾아다니며 사진을 업데이트해 줘야 한다. (갱신 이상 발생)

Ⅲ. BSON (Binary JSON)과 MongoDB

MongoDB는 JSON을 좋아하지만, 문자열 텍스트인 JSON을 하드디스크에 그대로 쓰면 용량이 너무 크고 검색이 느리다. 그래서 디스크에 저장할 때는 컴퓨터가 읽기 편하게 **BSON(Binary JSON)**이라는 0과 1의 바이너리 형태로 압축해서 저장한다.

  • 장점 1 (데이터 타입 추가): 일반 JSON에는 '날짜(Date)' 타입이 없어서 글자로 써야 하지만, BSON은 내부적으로 날짜, 이진 데이터(Binary) 등 풍부한 데이터 타입을 지원한다.
  • 장점 2 (인덱스 지원): BSON 구조 덕분에 MongoDB는 NoSQL임에도 불구하고 RDBMS와 거의 똑같은 B-Tree 인덱스를 완벽하게 지원하여 엄청나게 빠른 검색 성능을 자랑한다.
┌──────────────────────────────────────────────────────────────┐
│           RDBMS의 조인(JOIN) vs MongoDB의 내포(Embedding) 비교 시각화 │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🏢 RDBMS (MySQL) ]           │ [ 🍃 Document DB (MongoDB) ]│
│                                │                             │
│ ┌─ 게시글 ─┐   ┌─ 댓글 ─┐         │ {                           │
│ │ id: 1   │──▶│ 글id:1 │         │   "_id": 1,                 │
│ │ 제목: 안녕 │   │ 내용:굿 │         │   "제목": "안녕",             │
│ └─────────┘   └────────┘         │   "댓글": [                   │
│ (두 개의 테이블을 JOIN 해야 함)        │     {"내용": "굿!"},         │
│                                │     {"내용": "반가워!"}        │
│                                │   ]                         │
│                                │ }                           │
│                                │ (문서 1개만 읽어오면 끝! 초고속🚀)    │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"스키마 리스(Schema-less)는 자유가 아니라 책임의 전가다." 도큐먼트 DB를 쓰는 초보 개발자들은 "DB 스키마를 안 짜도 되니까 너무 편하다!"라고 착각한다. 하지만 DB가 데이터의 규칙을 검사해주지 않으면, 그 쓰레기 데이터(Garbage)를 걸러내는 로직은 고스란히 백엔드 소스 코드(Java, Node.js)에 if문으로 도배되어야 한다. 도큐먼트 DB는 트래픽이 쏟아지고 데이터 모델이 수시로 변하는 게임이나 쇼핑몰 카탈로그 시스템에는 최고의 무기지만, 돈이 오가고 무결성이 생명인 금융 시스템에서는 재앙이 될 수 있음을 명심해야 한다.

📌 관련 개념 맵

  • 관련 데이터베이스: MongoDB, CouchDB, Amazon DocumentDB, ElasticSearch(문서 기반 검색)
  • 대척점 철학: 정규화 (Normalization - 중복 최소화)
  • 데이터 모델링: Embedding (내포) vs Referencing (참조)
  • 동시성 제어: MongoDB도 최근 버전(4.0 이후)에서는 다중 문서 ACID 트랜잭션을 지원함.

👶 어린이를 위한 3줄 비유 설명

  1. RDBMS(관계형 DB)는 칸칸이 나뉜 '약통'이에요. 아침 칸에는 무조건 아침 약 1알만, 저녁 칸에는 저녁 약만 예쁘게 넣어야 하죠.
  2. 도큐먼트 DB는 커다란 '지퍼백'이에요. 지퍼백 하나에 약통, 처방전, 영수증, 밴드 등 내가 원하는 걸 모양 상관없이 다 쑤셔 넣을 수 있어요.
  3. 병원에 갈 때 지퍼백(도큐먼트) 딱 하나만 들고뛰면 되니까 엄청 편하지만, 나중에 그 안에서 반창고만 찾으려면 속을 다 뒤집어야 해서 조금 귀찮을 수 있답니다!