스키마가 사라진 것이 아니라 자리를 옮겼다

한 줄 요약

문서 데이터베이스는 "스키마가 없는 데이터베이스" 가 아니라 **스키마를
애플리케이션이 들고 있는 데이터베이스**다. 스키마가 사라진 것이 아니라
자리를 옮긴 것뿐이다.

왜 필요한가 — "유연하다" 를 잘못 읽으면

MongoDB 를 처음 쓸 때 가장 흔한 기대는 "컬럼을 미리 안 정해도 되니 빠르게
만들 수 있다" 는 것이다. 맞는 말이지만 그 대가가 어디로 갔는지는 잘 안 보인다.

RDB 에서는 qty 에 문자열을 넣으면 그 자리에서 거절당한다. 문서 DB 에서는
들어간다. 그리고 몇 달 뒤 집계 쿼리가 이상한 값을 뱉을 때 비로소 알게
된다. 그때는 이미 어느 문서가 언제부터 잘못됐는지 알 수 없다.

그래서 실무에서 쓰는 문서 DB 에는 대개 스키마가 있다. $jsonSchema 로 걸거나,
애플리케이션 계층(Mongoose, Pydantic)에서 거른다. 둘 중 하나는 반드시 있다.

그럼 무엇이 진짜 다른가

차이는 스키마의 유무가 아니라 한 번의 조회로 무엇이 함께 오는가 다.

RDB 에서 주문과 품목은 두 표에 나뉘고 조인으로 붙인다. 문서 DB 에서는
품목을 주문 문서 안에 끼워 넣을 수 있다.

{ _id: 1, customer: "김", lines: [ { name: "가방", qty: 2 }, { name: "신발", qty: 1 } ] }

주문 화면이 필요로 하는 것이 정확히 이 모양이면, 조회 한 번으로 끝난다.
조인도 N+1 도 없다. 읽는 모양대로 저장하는 것이 문서 DB 의 값어치다.

현장에서

그래서 판단 기준도 하나로 좁혀진다 — 함께 읽히는가, 따로 바뀌는가.

품목이 늘 주문과 함께 읽히고 주문 밖에서 따로 수정될 일이 없으면 끼워 넣는다.
반대로 상품 정보처럼 여러 주문이 같은 것을 가리키고 값이 바뀌면 모두에게
반영돼야 한다면, 참조로 두고 따로 관리한다. 끼워 넣으면 그 상품명을 고칠 때
그것을 품은 문서를 전부 찾아 고쳐야 한다.

"MongoDB 를 써 봤는가" 를 묻는 면접에서 실제로 듣고 싶어 하는 답이 이것이다.
쿼리 문법이 아니라, 어디까지 끼워 넣고 어디서 끊었는지와 그 이유다.