Lv.2 초급MongoDB

2026.05.0725분 읽기Lv.2 초급

시리즈기업이 MongoDB를 선택하는 이유 · 파트 3/4시리즈 허브 보기

기업이 MongoDB를 선택하는 이유 Part 3 — 기술적 이유 심층 분석

Part 2에서 확인한 Wells Fargo, McKesson, Victoria's Secret 등의 성과 뒤에는 구체적인 기술적 근거가 있다. 문서 모델이 관계형 DB의 정규화 부담을 어떻게 줄이는지, 샤딩 기반 수평 확장이 왜 예측 불가능한 성장에 유리한지, 멀티 문서 ACID 트랜잭션이 어떻게 금융·헬스케어의 신뢰를 얻었는지, Atlas Vector Search가 AI 애플리케이션 아키텍처를 어떻게 단순화하는지 — MongoDB 8.x 성능 수치, 보안·컴플라이언스 스택, 개발자 경험(DX)까지 엔지니어 관점으로 압축해 설명한다.

시리즈 구성

• Part 1 — NoSQL 회의론에서 엔터프라이즈 표준으로 (이전 편)
• Part 2 — 산업별 대표 도입 사례 심층 분석 (이전 편)
• Part 3 — 기업이 MongoDB를 선택하는 기술적 이유 (현재 편)
• Part 4 — 레거시 탈출 전략 — RDBMS에서 MongoDB로 (연재 예정)

목차

1. 들어가며 — "좋다"는 건 알겠는데, 왜 좋은가?
2. 기술 이유 ① 문서 모델 — 관계형의 벽을 허물다
3. 기술 이유 ② 수평 확장(Sharding) — 예측 불가능한 성장에 대응하는 법
4. 기술 이유 ③ ACID 트랜잭션 — "NoSQL은 금융에 못 쓴다"는 신화의 종말
5. 기술 이유 ④ Atlas Vector Search — AI 시대의 핵심 무기
6. 기술 이유 ⑤ MongoDB 8.x — 역대 가장 빠른 버전의 탄생
7. 기술 이유 ⑥ 보안·컴플라이언스 — 엔터프라이즈가 신뢰를 주는 이유
8. 기술 이유 ⑦ 개발자 경험(DX) — 속도가 곧 경쟁력이다
9. 종합 비교: MongoDB vs 관계형 DB
10. Part 3 정리 및 다음 편 예고

1. 들어가며 — "좋다"는 건 알겠는데, 왜 좋은가?

Part 2에서 우리는 Wells Fargo, McKesson, Victoria's Secret 같은 기업들이 MongoDB로 극적인 성과를 냈다는 걸 확인했습니다. 그런데 "어떻게"의 이야기는 아직 하지 않았습니다.

결과 뒤에는 반드시 기술적 이유가 있습니다. 관계형 데이터베이스와 무엇이 다르고, 왜 AI 시대에 더 적합한지, 그리고 최신 버전에서는 무엇이 달라졌는지 — 이번 편에서는 엔지니어의 시각으로 MongoDB의 핵심 기술을 낱낱이 살펴봅니다.

2. 기술 이유 ① 문서 모델 — 관계형의 벽을 허물다

관계형 DB의 근본적 문제: 정규화의 저주

관계형 데이터베이스는 1970년대에 설계된 정규화(Normalization) 원칙 위에 세워졌습니다. 데이터 중복을 없애기 위해 정보를 잘게 쪼개 여러 테이블에 분산 저장하는 방식입니다.

보험 계약 하나를 예로 들어보겠습니다. 관계형 DB에서 이 데이터는 계약 테이블, 보장 항목 테이블, 피보험자 테이블, 결제 테이블 등 수십 개의 테이블로 쪼개집니다. 이 데이터를 화면에 렌더링하려면 매번 수십 개의 JOIN 연산을 수행해야 하고, 수정할 때는 다시 쪼개서 저장해야 합니다. 이는 단순히 복잡한 게 아니라 런타임 성능에 직접적인 타격을 줍니다.

MongoDB의 문서 모델: 데이터를 자연스럽게 표현한다

MongoDB는 BSON(Binary JSON) 형식의 문서(Document)로 데이터를 저장합니다. 위의 보험 계약 데이터는 MongoDB에서 단 하나의 문서 안에 중첩(nested) 구조로 표현됩니다. 애플리케이션이 데이터를 조회할 때 JOIN 없이 한 번의 읽기(read)로 모든 정보를 가져올 수 있습니다.

{
  "_id": "order_001",
  "customer": {
    "name": "홍길동",
    "email": "gildong@example.com"
  },
  "items": [
    { "product": "노트북", "price": 1500000, "qty": 1 },
    { "product": "마우스", "price": 35000,  "qty": 2 }
  ],
  "status": "배송중",
  "createdAt": "2026-04-12T09:00:00Z"
}

관계형 DB에서라면 customers, orders, order_items, products 최소 4개 테이블을 JOIN해야 얻을 수 있는 정보입니다.

유연한 스키마(Flexible Schema)의 실전 가치

관계형 DB에서 새 컬럼을 추가하려면 ALTER TABLE 명령으로 스키마를 수정하고, 기존 데이터를 마이그레이션해야 합니다. 테이블이 수억 건이라면 이 작업 자체가 수 시간의 다운타임을 유발할 수 있습니다.

MongoDB에서는 새 필드를 그냥 추가하면 됩니다. 기존 문서는 그대로 두고, 새 문서부터 새 필드를 포함시키면 됩니다. 물론 스키마 검증(Schema Validation) 기능으로 필요한 경우에는 엄격하게 구조를 강제할 수도 있습니다.

이 유연성이 실제로 어느 정도의 차이를 만들어내는가? 관계형 DB에서 MongoDB로 전환한 팀들은 평균적으로 개발 사이클이 30-50% 단축되었다고 보고합니다.

3. 기술 이유 ② 수평 확장(Sharding) — 예측 불가능한 성장에 대응하는 법

수직 확장의 한계

관계형 DB의 전통적인 확장 방식은 수직 확장(Scale-Up)입니다. 서버에 더 좋은 CPU, 더 많은 RAM을 붙이는 것입니다. 이 방식은 단순하지만 두 가지 문제가 있습니다. 첫째, 비용이 기하급수적으로 증가합니다. 둘째, 물리적 한계가 있습니다.

MongoDB의 Sharding: 데이터를 나눠 분산 처리

MongoDB는 샤딩(Sharding)을 통한 수평 확장(Scale-Out)을 기본 설계 철학으로 채택했습니다. 데이터를 여러 서버(샤드)에 분산 저장하고, 트래픽 역시 분산 처리합니다. 이론상 서버를 추가하는 것만으로 무한 확장이 가능합니다.

MongoDB 8.0에서는 샤딩 향상으로 데이터를 샤드 전반에 분산하는 속도가 기존보다 최대 50배 빨라졌고, 샤딩 시작 비용도 최대 50% 절감되었습니다.

실전에서의 증명

Part 2에서 살펴봤듯, 99Minutos는 2년 미만의 기간에 7,500% 성장하는 동안 MongoDB 샤딩 덕분에 시스템을 유지할 수 있었습니다. McKesson은 단 6개월 안에 300배의 트랜잭션 볼륨 확장을 감당했습니다. 이는 수직 확장 방식으로는 물리적으로 불가능한 수준이었습니다.

4. 기술 이유 ③ ACID 트랜잭션 — "NoSQL은 금융에 못 쓴다"는 신화의 종말

ACID란 무엇인가?

ACID는 데이터베이스 트랜잭션이 안전하게 처리되기 위한 4가지 속성입니다.

계좌 이체를 예로 들면, A 계좌에서 100만 원이 빠지고 B 계좌에 100만 원이 들어가는 두 작업이 반드시 함께 성공하거나 함께 실패해야 합니다. 둘 중 하나만 성공하면 데이터가 망가집니다.

MongoDB의 ACID 여정: 2018년의 게임 체인저

초기 MongoDB는 단일 문서(Single-Document) 수준의 원자성만 보장했습니다. 여러 문서에 걸친 복잡한 트랜잭션은 지원하지 않았고, 이것이 금융·의료 등 엔터프라이즈 시장 진입의 가장 큰 장벽이었습니다.

2018년 MongoDB 4.0이 이 모든 것을 바꿨습니다. 멀티 문서 ACID 트랜잭션이 공식 지원되기 시작했고, 이후 버전에서는 샤딩된 클러스터에서도 동일한 ACID 보장이 확장 적용되었습니다.

오늘날 MongoDB는 샤딩된 분산 클러스터 환경에서도 완전한 멀티 문서 ACID 트랜잭션을 제공합니다. Wells Fargo가 신용카드 결제 플랫폼을, Citizens Bank가 실시간 사기 탐지 시스템을 MongoDB 위에 올린 것도 이 신뢰성 덕분입니다.

Queryable Encryption: 암호화된 데이터를 쿼리하다

MongoDB 8.0에서는 Queryable Encryption(QE)이 범위 쿼리(Range Query)까지 지원하도록 확장되었습니다. 이는 데이터를 암호화된 상태 그대로 유지하면서도 해당 데이터를 필터링하거나 비교 연산하는 쿼리를 실행할 수 있음을 의미합니다. 금융·헬스케어 같은 고규제 산업에서 이 기능은 컴플라이언스와 성능을 동시에 충족시키는 핵심 열쇠입니다.

5. 기술 이유 ④ Atlas Vector Search — AI 시대의 핵심 무기

벡터 검색이란 무엇인가?

전통적인 키워드 검색은 정확한 단어가 일치해야 결과를 반환합니다. 반면 벡터 검색(Vector Search)은 의미(Semantic)를 기반으로 유사한 데이터를 찾습니다.

예를 들어 "심근경색 증상"이라고 검색했을 때, 키워드 검색은 정확히 "심근경색"이 포함된 문서만 찾습니다. 벡터 검색은 "가슴 통증", "흉부 압박감", "좌측 팔 저림"처럼 의미상 관련된 문서도 함께 찾아냅니다.

이 기술은 RAG(Retrieval-Augmented Generation) 기반 AI 애플리케이션의 핵심 인프라입니다. LLM이 답변을 생성할 때 필요한 정확한 맥락 데이터를 벡터 검색으로 실시간 조회해 환각(Hallucination)을 방지합니다.

MongoDB Atlas Vector Search의 차별점

MongoDB는 단순히 "벡터 검색 기능을 추가한" 것이 아닙니다. 벡터 데이터를 운영 데이터와 동일한 문서 안에 함께 저장할 수 있게 설계했습니다. 이는 별도의 벡터 DB를 운용할 필요가 없다는 의미입니다. 아키텍처가 단순해지고, 데이터 동기화 문제도 사라집니다.

Atlas Vector Search는 HNSW(Hierarchical Navigable Small World) 알고리즘 기반의 ANN(Approximate Nearest Neighbor) 검색을 지원하며, 최대 4,096 차원의 벡터를 처리할 수 있습니다.

Hybrid Search: 키워드 + 의미 검색의 결합

실전 AI 애플리케이션에서는 키워드 검색과 벡터 검색을 결합한 하이브리드 서치(Hybrid Search)가 가장 강력한 성능을 냅니다. MongoDB Atlas는 두 방식을 하나의 쿼리 파이프라인에서 동시에 실행할 수 있습니다.

Novo Nordisk가 임상 보고서 작성 시간을 12주에서 10분으로 줄인 것도, Sentra가 보안 쿼리 속도를 180배 향상시킨 것도, Atlas Search와 Vector Search의 통합 덕분이었습니다.

Voyage AI 통합: 도메인 특화 임베딩의 정확도

2025년 2월 MongoDB가 인수한 Voyage AI의 임베딩 모델은 금융, 법률, 의료 등 전문 도메인에서 일반 범용 임베딩 모델 대비 월등한 정확도를 제공합니다. 이는 도메인 특화 AI 애플리케이션에서 LLM 환각을 줄이는 결정적 요소로 작용합니다.

6. 기술 이유 ⑤ MongoDB 8.x — 역대 가장 빠른 버전의 탄생

MongoDB 8.0의 성능 도약

MongoDB는 8.0 개발 당시 전사적으로 "성능 군단(Performance Army)"을 결성했습니다. 목표는 단순했습니다. 보안, 내구성, 가용성, 성능이라는 네 가지 엔터프라이즈 요건 모두에서 역대 최고 수준을 달성하는 것이었습니다.

결과는 수치로 증명되었습니다.

MongoDB 자체의 내부 빌드 시스템도 8.0으로 업그레이드했을 때 쿼리 지연 시간이 약 75% 감소했다고 보고했습니다. 독일의 기후 기술 스타트업 OCELL의 CTO Felix Horvat는 8.0 적용 후 일부 쿼리가 이전 대비 2배 빠르게 동작한다고 밝혔습니다.

MongoDB 8.1 / 8.2: 지속적인 개선

MongoDB 8.1에서는 추가적인 성능 향상이 이루어졌습니다.

• 시계열 대량 삽입 처리량 최대 195% 향상
• 매치 필터 쿼리 처리량 최대 40% 향상
• 배열 포함 문서 쿼리 처리량 최대 20% 향상
• CPU 사용률 최대 5% 감소

MongoDB 8.2는 초기 동기화(Initial Sync) 속도 향상과 쿼리 멀티플래닝 비용 감소를 포함한 추가 최적화가 적용된 마이너 릴리즈입니다.

성능 수치는 MongoDB 공식 릴리즈 노트 및 벤치마크 기반으로 작성되었으며, 실제 워크로드에 따라 결과는 달라질 수 있습니다.

7. 기술 이유 ⑥ 보안·컴플라이언스 — 엔터프라이즈가 신뢰를 주는 이유

금융, 헬스케어, 공공기관은 데이터베이스를 선택할 때 성능보다 보안과 컴플라이언스를 먼저 따집니다. MongoDB는 이 요건들을 체계적으로 구축해왔습니다.

보안 기능 스택

역할 기반 접근 제어(RBAC) 는 사용자별로 읽기/쓰기/관리 권한을 세밀하게 제어할 수 있게 합니다. 감사 로그(Audit Log) 는 누가 언제 어떤 데이터를 읽고 수정했는지 추적할 수 있게 합니다.

필드 수준 암호화(Field-Level Encryption, FLE) 는 특정 민감 필드만 암호화해 저장할 수 있습니다. 주민등록번호나 카드번호 같은 데이터는 DB 관리자조차 평문으로 볼 수 없습니다.

Queryable Encryption은 여기서 한 걸음 더 나아갑니다. 암호화된 상태로 저장된 데이터에 범위 쿼리나 비교 연산을 수행할 수 있습니다. 암호화와 쿼리 성능을 동시에 잡은 획기적인 기술입니다.

글로벌 컴플라이언스 대응

유럽의 GDPR, 미국의 HIPAA·DSCSA, 금융 규제 등 다양한 데이터 규제에 대응하기 위해 MongoDB는 AWS PrivateLink와의 통합을 통해 완전 프라이빗 네트워크 연결을 지원합니다.

Deutsche Telekom은 GDPR 준수를 위해 데이터를 유럽 내 서버에만 샤딩하도록 설정했습니다. 이처럼 지역별 데이터 주권(Data Sovereignty) 요건을 유연하게 충족할 수 있다는 점은 글로벌 기업들에게 중요한 선택 기준이 됩니다.

8. 기술 이유 ⑦ 개발자 경험(DX) — 속도가 곧 경쟁력이다

JSON 네이티브: 앱 코드와 DB 구조가 일치한다

현대 웹과 모바일 애플리케이션은 거의 모두 JSON 형식으로 데이터를 주고받습니다. MongoDB의 문서 모델은 JSON과 동일한 구조를 사용하기 때문에, 앱 코드에서 다루는 객체(Object)를 그대로 DB에 저장하고 조회할 수 있습니다. 별도의 ORM(Object-Relational Mapping) 레이어나 복잡한 데이터 변환 로직이 필요 없습니다.

MCP(Model Context Protocol) 지원: AI 개발자의 생산성 폭발

2025년 MongoDB는 MCP(Model Context Protocol) 서버를 공식 출시했습니다. MCP는 Anthropic이 도입한 AI 에이전트와 데이터 시스템 간의 개방형 통신 표준입니다.

이 통합의 의미는 단순하지 않습니다. 개발자가 Cursor, GitHub Copilot, Claude 같은 AI 코딩 도구에서 자연어로 MongoDB 데이터베이스에 직접 질문하고 조작할 수 있게 됩니다. "지난 주 가장 많이 구매된 상품 5개 보여줘"라고 입력하면 AI 에이전트가 적절한 쿼리를 생성하고 실행해 결과를 반환합니다.

MCP 서버 출시 이후 수천 명의 개발자가 매주 MongoDB로 새 프로젝트를 시작하고 있으며, 대형 엔터프라이즈 고객들도 에이전트 AI 스택의 핵심 구성 요소로 MongoDB MCP를 채택하고 있습니다.

Atlas의 운영 자동화: DevOps 부담의 절감

MongoDB Atlas는 클러스터 관리, 자동 백업, 성능 모니터링, 자동 인덱스 제안, 이상 탐지 등을 완전 자동화합니다. 운영 팀의 관리 부담이 크게 절감된다는 보고가 있으며, 이는 개발자가 인프라가 아닌 비즈니스 로직에 집중할 수 있게 해줍니다.

9. 종합 비교: MongoDB vs 관계형 DB

기술적 특성을 기준으로 MongoDB와 전통적인 관계형 데이터베이스를 비교하면 다음과 같습니다.

관계형 DB가 무조건 열등하다는 의미가 아닙니다. 고도로 정규화된 복잡한 관계 데이터나, 오랜 기간 정제된 SQL 쿼리 최적화가 필요한 특정 OLAP 워크로드에서는 여전히 관계형 DB가 강점을 가집니다. MongoDB는 빠르게 변화하는 데이터 구조, 대규모 수평 확장, AI 통합이 요구되는 현대적 애플리케이션 환경에서 강점을 보입니다.

10. Part 3 정리 및 다음 편 예고

이번 편에서 살펴본 MongoDB의 7가지 기술적 강점을 요약하면 다음과 같습니다.

Part 4에서는 이 모든 기술을 실제 현장에 적용하는 방법을 다룹니다. 관계형 DB에서 MongoDB로 마이그레이션할 때 무엇을 준비해야 하는지, 어떤 함정을 피해야 하는지, 데이터 모델링은 어떻게 달라져야 하는지를 실전 가이드 형식으로 정리할 예정입니다.

이 글이 유익했다면 시리즈 전편을 북마크해두세요. Part 4는 곧 업로드됩니다.

참고 자료

• MongoDB 8.0: Raising the Bar
• MongoDB 8.0: Improving Performance, Avoiding Regressions
• Release Notes for MongoDB 8.2
• MongoDB Atlas Vector Search
• Busting The Top Myths About MongoDB Vs Relational Databases
• Why Relational Databases Are So Expensive To Enterprises
• Converged Datastore For Agentic AI — MongoDB
• AI Fraud Detection With MongoDB Atlas and Temporal