MongoDB 스키마 설계 가이드

MongoDB 설계에서 가장 흔한 오해는 “스키마가 자유롭다”는 말이 곧 “미리 설계할 필요가 없다”는 뜻처럼 들린다는 점입니다. 실제로는 반대입니다. MongoDB는 관계형 데이터베이스보다 더 일찍 **조회 패턴, 문서 경계, 갱신 단위, 인덱스 전략**을 명확히 해야 합니다.

그림으로 보는 구조

[Access Pattern]
      |
      +--> read together? ---- yes --> [Embed]
      |
      +--> updated independently? -> yes --> [Reference]
      |
      v
[Index + aggregation design]
      |
      v
[document size / query cost / update cost]

MongoDB 스키마 설계의 핵심은 정규화 여부가 아니라, 어떤 데이터가 함께 읽히고 함께 바뀌는지를 기준으로 문서 경계를 잡는 데 있습니다.

임베딩과 참조는 철학이 아니라 조회 패턴의 문제다

임베딩은 거의 항상 함께 조회되고 하위 데이터 개수가 제한적이며 부모 문서 단위 갱신이 자연스러운 경우에 강합니다. 반대로 참조는 하위 데이터 수가 많고 독립적으로 갱신되며 여러 곳에서 재사용될 때 유리합니다.

문서 경계는 트랜잭션 경계이기도 하다

MongoDB에서는 한 문서 안의 변경은 매우 강한 단위 작업으로 다룰 수 있습니다. 그래서 문서 경계를 어떻게 자르느냐는 저장 형식이 아니라 실제 일관성 경계를 정하는 일이기도 합니다.

인덱스는 컬렉션이 아니라 쿼리 패턴에 맞춰 설계해야 한다

MongoDB도 인덱스가 성능을 좌우하지만, “자주 쓰는 필드”에 거는 것이 아니라 조회 조건 + 정렬 + 제한 범위가 함께 맞는 쿼리에 맞춰야 합니다.

집계 파이프라인은 강력하지만 읽기 모델을 대신할 수는 없다

집계 파이프라인은 강력하지만 모든 복잡한 조회를 그 안에 밀어 넣으면 곧 운영 비용이 커집니다. 대형 컬렉션 전체를 자주 스캔하지 않는지, $lookup이 많아져 사실상 조인 DB처럼 쓰고 있지 않은지, 요약 컬렉션이 더 나은지 함께 봐야 합니다.

트랜잭션은 가능하지만 남용할수록 MongoDB의 장점이 줄어든다

MongoDB는 다중 문서 트랜잭션을 지원하지만, 기본 모델은 문서 단위 원자성을 활용하는 쪽이 더 자연스럽습니다. 다중 문서 트랜잭션이 잦아진다면, 스키마 경계가 잘못된 신호일 수도 있습니다.

MongoDB가 특히 잘 맞는 경우

조회 패턴이 문서 중심으로 명확한 경우
일부 필드 구조가 유연하게 변하는 경우
빠른 기능 개발과 문서 단위 읽기 효율이 중요한 경우
이벤트, 로그, 카탈로그, 사용자 설정처럼 관계가 상대적으로 느슨한 경우

실무에서 자주 생기는 안티패턴

모든 관계를 임베딩으로 해결하려 함
반대로 RDB처럼 지나치게 참조만 사용함
조회 패턴 없이 컬렉션 구조부터 정의함
집계 파이프라인으로 운영 통계를 전부 실시간 계산함
다중 문서 트랜잭션이 늘어나는데 스키마는 그대로 둠

마무리

MongoDB 스키마 설계의 핵심은 자유도 그 자체가 아니라, 문서 경계를 조회 패턴과 일관성 경계에 맞게 정하는 것입니다. 임베딩과 참조는 둘 중 하나의 정답이 아니라, 함께 읽는 데이터와 함께 바뀌는 데이터를 어디에 둘지에 대한 선택입니다.

운영 환경에서 어려워지는 지점

MongoDB 스키마 설계는 유연성 비용을 어디에서 치를지 정하는 일이다. 읽기 단순성, 쓰기 증폭, 문서 간 일관성 중 무엇을 선택할지 결정해야 한다.
embed는 우아해 보이지만 문서가 뜨겁고 커지고 업데이트 빈도가 갈라지기 시작하면 금방 어려워진다.
잘못된 스키마도 초기에는 workload가 단순해서 괜찮아 보이기 쉽다.

중요한 아키텍처 결정

추상적인 관계형 습관보다 지배적인 쿼리 패턴과 문서 소유권에서 시작한다.
함께 읽히고 함께 바뀌는 데이터는 embed하고, 성장, 재사용, 갱신 빈도가 다르면 reference한다.
인덱스 설계와 문서 크기 기대치를 함께 본다.

실무 예시

작고 비교적 안정적인 세부정보는 embed하고, 자주 바뀌거나 공유되는 관계는 reference하는 구성이 흔하다.

order {
  orderId,
  shippingAddress, // embedded
  lineItems,       // 크기가 제한될 때 embedded
  customerId       // referenced
}

피해야 할 안티패턴

사용량과 함께 끝없이 커지는 배열을 embed하는 것.
너무 많은 컬렉션 사이에서 수작업 관계형 join을 재현하는 것.
문서 성장과 마이그레이션 전략을 무시하는 것.

운영 체크리스트

문서 크기와 가장 뜨거운 업데이트 경로를 검토한다.
지배적 읽기 패턴에 맞는 인덱스를 검증한다.
스키마 진화를 위한 마이그레이션 절차를 준비한다.
여러 문서를 함께 바꿔야 하는 경우 일관성 전략을 테스트한다.

최종 판단

MongoDB 스키마 설계는 접근 패턴을 정직하게 따를 때 잘 작동한다. 마법 같은 JSON 저장소나 숨은 RDBMS처럼 다루면 대개 좋지 않게 끝난다.

다음으로 읽기 좋은 글

🗄️ Database

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다